Add telemetry mention for ProxySettingsPolicy

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:

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 >}}
 

content/ngf/overview/product-telemetry.md

@@ -29,7 +29,7 @@ Telemetry data is collected once every 24 hours and sent to a service managed by
 - **Image Build Source:** whether the image was built by GitHub or locally (values are `gha`, `local`, or `unknown`). The source repository of the images is **not** collected.
 - **Build OS:** the base operating system the image was built on (values are currently `alpine` or `ubi`). 
 - **Deployment Flags:** a list of NGINX Gateway Fabric Deployment flags that are specified by a user. The actual values of non-boolean flags are **not** collected; we only record that they are either `true` or `false` for boolean flags and `default` or `user-defined` for the rest.
-- **Count of Resources:** the total count of resources related to NGINX Gateway Fabric. This includes `GatewayClasses`, `Gateways`, `HTTPRoutes`,`GRPCRoutes`, `TLSRoutes`, `InferencePool`, `Secrets`, `Services`, `BackendTLSPolicies`, `ClientSettingsPolicies`, `NginxProxies`, `ObservabilityPolicies`, `UpstreamSettingsPolicies`, `SnippetsFilters`, and `Endpoints`. The data within these resources is **not** collected.
+- **Count of Resources:** the total count of resources related to NGINX Gateway Fabric. This includes `GatewayClasses`, `Gateways`, `HTTPRoutes`,`GRPCRoutes`, `TLSRoutes`, `InferencePool`, `Secrets`, `Services`, `BackendTLSPolicies`, `ClientSettingsPolicies`, `NginxProxies`, `ObservabilityPolicies`, `UpstreamSettingsPolicies`, `ProxySettingsPolicies`, `SnippetsFilters`, and `Endpoints`. The data within these resources is **not** collected.
 - **SnippetsFilters Info** a list of directive-context strings from applied SnippetFilters and a total count per strings. The actual value of any NGINX directive is **not** collected.
 - **Control Plane Pod Count** the count of NGINX Gateway Fabric Pods.
 - **Data Plane Pod Count** the count of NGINX data plane Pods.

content/ngf/traffic-security/secure-backend.md

@@ -15,15 +15,9 @@ In this guide, we will show how to specify the TLS configuration of the connecti
 
 The intended use-case is when a service or backend owner is managing their own TLS and NGINX Gateway Fabric needs to know how to connect to this backend pod that has its own certificate over HTTPS.
 
-## Note on Gateway API Experimental Features
-
-{{< call-out "important" >}} BackendTLSPolicy is a Gateway API resource from the experimental release channel. {{< /call-out >}}
-
-{{< include "/ngf/installation/install-gateway-api-experimental-features.md" >}}
-
 ## Before you begin
 
-- [Install]({{< ref "/ngf/install/" >}}) NGINX Gateway Fabric with experimental features enabled.
+- [Install]({{< ref "/ngf/install/" >}}) NGINX Gateway Fabric.
 
 ## Set up
 
@@ -200,7 +194,7 @@ curl --resolve secure-app.example.com:$GW_PORT:$GW_IP http://secure-app.example.
 <body>
 <center><h1>400 Bad Request</h1></center>
 <center>The plain HTTP request was sent to HTTPS port</center>
-<hr><center>nginx/1.25.3</center>
+<hr><center>nginx/1.29.2</center>
 </body>
 </html>
 ```
@@ -262,7 +256,7 @@ Next, we create the Backend TLS Policy which targets our `secure-app` Service an
 
 ```yaml
 kubectl apply -f - <<EOF
-apiVersion: gateway.networking.k8s.io/v1alpha3
+apiVersion: gateway.networking.k8s.io/v1
 kind: BackendTLSPolicy
 metadata:
   name: backend-tls
@@ -291,21 +285,21 @@ Name:         backend-tls
 Namespace:    default
 Labels:       <none>
 Annotations:  <none>
-API Version:  gateway.networking.k8s.io/v1alpha3
+API Version:  gateway.networking.k8s.io/v1
 Kind:         BackendTLSPolicy
 Metadata:
-  Creation Timestamp:  2024-05-15T12:02:38Z
+  Creation Timestamp:  2025-11-13T23:28:36Z
   Generation:          1
-  Resource Version:    19380
-  UID:                 b3983a6e-92f1-4a98-b2af-64b317d74528
+  Resource Version:    1288
+  UID:                 d7e3f026-afe3-44d1-aed5-c168e954b52f
 Spec:
   Target Refs:
-    Group:
-    Kind:       Service
-    Name:       secure-app
+    Group:  
+    Kind:   Service
+    Name:   secure-app
   Validation:
     Ca Certificate Refs:
-      Group:
+      Group:   
       Kind:    ConfigMap
       Name:    backend-cert
     Hostname:  secure-app.example.com
@@ -317,8 +311,15 @@ Status:
       Name:       gateway
       Namespace:  default
     Conditions:
-      Last Transition Time:  2024-05-15T12:02:38Z
-      Message:               BackendTLSPolicy is accepted by the Gateway
+      Last Transition Time:  2025-11-13T23:28:37Z
+      Message:               All CACertificateRefs are resolved
+      Observed Generation:   1
+      Reason:                ResolvedRefs
+      Status:                True
+      Type:                  ResolvedRefs
+      Last Transition Time:  2025-11-13T23:28:37Z
+      Message:               The Policy is accepted
+      Observed Generation:   1
       Reason:                Accepted
       Status:                True
       Type:                  Accepted