docs: NGF release 2.3 docs

content/ngf/how-to/data-plane-configuration.md

@@ -272,6 +272,44 @@ of a few arguments. {{< /call-out >}}
 
 ---
 
+## Configure the data plane log format
+
+NGINX records client requests immediately after each request is processed. You can use the `NginxProxy` resource to dynamically configure the access log format.
+
+The following command creates a basic `NginxProxy` that defines a custom log format `$remote_addr - [$time_local] "$request" $status $body_bytes_sent`:
+
+```yaml
+kubectl apply -f - <<EOF
+apiVersion: gateway.nginx.org/v1alpha2
+kind: NginxProxy
+metadata:
+  name: ngf-proxy-config
+spec:
+  logging:
+    accessLog:
+      format: $remote_addr - [$time_local] "$request" $status $body_bytes_sent
+EOF
+```
+
+You can disable access logging entirely with the following configuration:
+
+```yaml
+kubectl apply -f - <<EOF
+apiVersion: gateway.nginx.org/v1alpha2
+kind: NginxProxy
+metadata:
+  name: ngf-proxy-config
+spec:
+  logging:
+    accessLog:
+      disable: true
+EOF
+```
+
+{{< call-out "note" >}} File destinations in `logging.accessLog` are not currently supported it is always set to `/dev/stdout`. {{< /call-out >}}
+
+---
+
 ### Run NGINX Gateway Fabric with NGINX in debug mode
 
 To run NGINX Gateway Fabric with NGINX in debug mode, during [installation]({{< ref "/ngf/install/" >}}), follow these additional steps:
@@ -327,12 +365,11 @@ kind: NginxProxy
 metadata:
   name: ngf-proxy-config
 spec:
-  config:
-    rewriteClientIP:
-      mode: ProxyProtocol
-      trustedAddresses:
-      - type: CIDR
-        value: "76.89.90.11/24"
+  rewriteClientIP:
+    mode: ProxyProtocol
+    trustedAddresses:
+    - type: CIDR
+      value: "76.89.90.11/24"
 EOF
 ```
 
@@ -364,8 +401,6 @@ spec:
         terminationGracePeriodSeconds: 90
       replicas: 2
     service:
-      annotations:
-        service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
       type: LoadBalancer
       loadBalancerIP: "192.87.9.1"
 EOF

content/ngf/overview/gateway-api-compatibility.md

@@ -22,7 +22,7 @@ Learn which Gateway API resources NGINX Gateway Fabric supports and to which lev
 | [TLSRoute](#tlsroute)                 | Supported           | Not supported          | Not supported                         | v1alpha2    | Experimental        |
 | [TCPRoute](#tcproute)                 | Not supported       | Not supported          | Not supported                         | v1alpha2    | Experimental        |
 | [UDPRoute](#udproute)                 | Not supported       | Not supported          | Not supported                         | v1alpha2    | Experimental        |
-| [BackendTLSPolicy](#backendtlspolicy) | Partially Supported | Supported              | Partially supported                   | v1alpha3    | Experimental        |
+| [BackendTLSPolicy](#backendtlspolicy) | Partially Supported | Supported              | Partially supported                   | v1          | Standard            |
 | [Custom policies](#custom-policies)   | N/A                 | N/A                    | Supported                             | N/A         | N/A                 |
 {{< /table >}}
 
@@ -73,6 +73,7 @@ NGINX Gateway Fabric supports a single GatewayClass resource configured with the
           a different GatewayClass name is provided to the controller via the command-line argument.
     - `SupportedVersion/True/SupportedVersion`
     - `SupportedVersion/False/UnsupportedVersion`
+  - `supportedFeatures` - supported.
 
 ### Gateway
 
@@ -107,7 +108,10 @@ See the [controller]({{< ref "/ngf/reference/cli-help.md#controller">}}) command
   - `addresses`: Valid IPAddresses will be added to the `externalIP` field in the related Services fronting NGINX. Users should ensure that the IP Family of the address matches the IP Family set in the NginxProxy resource (default is dual, meaning both IPv4 and IPv6), otherwise there may be networking issues.
       - `type`: Partially supported. Allowed value: `IPAddress`.
       - `value`: Partially supported. Dynamic address allocation when value is unspecified is not supported.
-  - `backendTLS`: Not supported.
+  - `TLS`:
+    - `frontend`: Not supported.
+    - `backend`:
+      - `clientCertificateRef`: Supported.
   - `allowedListeners`: Not supported.
 - `status`
   - `addresses`: Partially supported (LoadBalancer and ClusterIP).
@@ -322,7 +326,7 @@ Fields:
 {{< table >}}
 | Resource         | Core Support Level  | Extended Support Level | Implementation-Specific Support Level | API Version | API Release Channel |
 |------------------|---------------------|------------------------|---------------------------------------|-------------|---------------------|
-| BackendTLSPolicy | Partially Supported | Supported              | Partially Supported                   | v1alpha3    | Experimental        |
+| BackendTLSPolicy | Supported           | Supported              | Partially Supported                   | v1          | Standard            |
 {{< /table >}}
 
 Fields:
@@ -348,6 +352,10 @@ Fields:
     - `conditions`: Partially supported. Supported (Condition/Status/Reason):
       - `Accepted/True/PolicyReasonAccepted`
       - `Accepted/False/PolicyReasonInvalid`
+      - `Accepted/False/NoValidCACertificate`
+      - `ResolvedRefs/True/ResolvedRefs`
+      - `ResolvedRefs/False/InvalidCACertificateRef`
+      - `ResolvedRefs/False/InvalidKind`
 
 {{< call-out "note" >}} If multiple `backendRefs` are defined for a HTTPRoute rule, all the referenced Services *must* have matching BackendTLSPolicy configuration. BackendTLSPolicy configuration is considered to be matching if 1. CACertRefs reference the same ConfigMap, or 2. WellKnownCACerts are the same, and 3. Hostname is the same. {{< /call-out >}}