Docs review

Author: JackStromberg

articles/application-gateway/for-containers/alb-controller-release-notes.md

@@ -27,7 +27,7 @@ Instructions for new or existing deployments of ALB Controller are found in the
 
 | ALB Controller Version | Gateway API Version | Kubernetes Version | Release Notes |
 | ---------------------- | ------------------- | ------------------ | ------------- |
-| 1.2.3| v1.1 | v1.26, v1.27, v1.28, v1.29, v1.30 | Gateway API v1.1, gRPC support, frontend mutual authentication, readiness probe fixes, custom health probe port and tls mode  |
+| 1.2.3| v1.1 | v1.26, v1.27, v1.28, v1.29, v1.30 | Gateway API v1.1, gRPC support, frontend mutual authentication, readiness probe fixes, custom health probe port and TLS mode  |
 
 ## Release history
 

articles/application-gateway/for-containers/custom-health-probe.md

@@ -68,7 +68,7 @@ When the default health probe is used, the following values for each health prob
 
 In both Gateway API and Ingress API, a custom health probe can be defined by defining a [_HealthCheckPolicyPolicy_ resource](api-specification-kubernetes.md#alb.networking.azure.io/v1.HealthCheckPolicy) and referencing a service the health probes should check against.  As the service is referenced by an HTTPRoute or Ingress resource with a class reference to Application Gateway for Containers, the custom health probe is used for each reference.
 
-In this example, the health probe emitted by Application Gateway for Containers sends the hostname contoso.com to the pods that make up _test-service_.  The requested protocol is `http` with a path of `/`. A probe is emitted every 5 seconds and wait 3 seconds before determining the connection has timed out. If a response is received, an HTTP response code between 200 and 299 (inclusive of 200 and 299) is considered healthy, all other responses are considered unhealthy.
+In this example, the health probe emitted by Application Gateway for Containers sends the hostname contoso.com to the pods that make up _test-service_.  The requested protocol is `http` with a path of `/`. A probe is emitted every 5 seconds and waits 3 seconds before determining the connection has timed out. If a response is received, an HTTP response code between 200 and 299 (inclusive of 200 and 299) is considered healthy, all other responses are considered unhealthy.
 
 ```bash
 kubectl apply -f - <<EOF

articles/application-gateway/for-containers/grpc.md

@@ -54,25 +54,25 @@ gRPC has four [rpc life cycles](https://grpc.io/docs/what-is-grpc/core-concepts/
 
 In the unary life cycle, a request is made to the gRPC server and a response is returned.
 
-![Diagram depicting unary gRPC life cycle.](./media/grpc/agc-grpc-unary.png)
+![Diagram depicting unary gRPC life cycle.](./media/grpc/grpc-unary.png)
 
 ### Client streaming RPC
 
 In the client streaming life cycle, a request is made to the gRPC server, and then the client streams a sequence of additional messages to the server without the need for the server to return additional responses.
 
-![Diagram depicting client streaming gRPC life cycle.](./media/grpc/agc-grpc-client-streaming.png)
+![Diagram depicting client streaming gRPC life cycle.](./media/grpc/grpc-client-streaming.png)
 
 ### Server streaming RPC
 
 In the server streaming life cycle, a request is made to the gRPC server, and then the server streams a sequence of messages back to the client without the need for the client to return additional responses.
 
-![Diagram depicting server streaming gRPC life cycle.](./media/grpc/agc-grpc-server-streaming.png)
+![Diagram depicting server streaming gRPC life cycle.](./media/grpc/grpc-server-streaming.png)
 
 ### Bidirectional streaming RPC
 
 In the bidirectional streaming life cycle, a request is made to the gRPC server, and both the client and server send a sequence of messages, operating independently from each other.
 
-![Diagram depicting bidirectional streaming gRPC life cycle.](./media/grpc/agc-grpc-bidrectional-streaming.png)
+![Diagram depicting bidirectional streaming gRPC life cycle.](./media/grpc/grpc-bidrectional-streaming.png)
 
 ## gRPC implementation in Application Gateway for Containers
 

articles/application-gateway/for-containers/how-to-frontend-mtls-gateway-api.md

@@ -24,11 +24,11 @@ Mutual Transport Layer Security (MTLS) is a process that relies on certificates
 
 See the following figure:
 
-![A diagram showing the Application Gateway for Containers frontend MTLS process.](./media/how-to-frontend-mtls-gateway-api/frontend-mtls.png)](./media/how-to-frontend-mtls-gateway-api/frontend-mtls.png)
+[![A diagram showing the Application Gateway for Containers frontend MTLS process.](./media/how-to-frontend-mtls-gateway-api/frontend-mtls.png)](./media/how-to-frontend-mtls-gateway-api/frontend-mtls.png#lightbox)
 
 The valid client certificate flow shows a client presenting a certificate to the frontend of Application Gateway for Containers. Application Gateway for Containers determines the certificate is valid and proxies the request to the backend target. The response is ultimately returned to the client.
 
-The revoked client certificate flow shows a client presenting a revoked certificate to the frontend of Application Gateway for Containers. Application Gateway for Containers determins the certificate is not valid and prevents the request from being proxied to the client. The client will receive an HTTP 400 bad request and corresponding reason.
+The revoked client certificate flow shows a client presenting a revoked certificate to the frontend of Application Gateway for Containers. Application Gateway for Containers determines the certificate is not valid and prevents the request from being proxied to the client. The client will receive an HTTP 400 bad request and corresponding reason.
 
 ## Prerequisites