fix formatting/linking

geps/gep-1651.md

@@ -147,22 +147,22 @@ type GatewayInfrastructure struct {
 }
 
 type GatewayStatus struct {
-	// Addresses lists the IP addresses that have actually been
-	// bound to the Gateway. These addresses may differ from the
-	// addresses in the Spec, e.g. if the Gateway automatically
-	// assigns an address from a reserved pool.
+  // Addresses lists the IP addresses that have actually been
+  // bound to the Gateway. These addresses may differ from the
+  // addresses in the Spec, e.g. if the Gateway automatically
+  // assigns an address from a reserved pool.
   //
   // Implementations that support Gateway routability MUST include an address
   // that has the same routable semantics as defined in the Gateway spec.
-	//
+  //
   // Implementations MAY add additional addresses in status, but they MUST be
   // semantically less than the scope of the requested scope. For example if a
   // user requests a `Cluster` routable Gateway then the list of addresses
   // MUST NOT have a routability of `Public` or `Private`.
   //
-	// +optional
-	// +kubebuilder:validation:MaxItems=16
-	Addresses []GatewayStatusAddress `json:"addresses,omitempty"`
+  // +optional
+  // +kubebuilder:validation:MaxItems=16
+  Addresses []GatewayStatusAddress `json:"addresses,omitempty"`
   // ...
 }
 
@@ -322,26 +322,26 @@ We could introduce additional `AddressTypes` (ie. `ClusterLocalIPAddress`) but
 this would lead to a combinatorial explosion as new dimensions (ie. IPv6) are
 introduced.
 
-From: https://github.com/kubernetes-sigs/gateway-api/pull/1653#issuecomment-1451246877
+From: [https://github.com/kubernetes-sigs/gateway-api/pull/1653#issuecomment-1451246877](https://github.com/kubernetes-sigs/gateway-api/pull/1653#issuecomment-1451246877)
 
 > Although this makes sense in isolation, I'm worried about the long term impacts this could have. In my opinion, ClusterLocal is a modifier, not exactly an address type. For example, it's possible in the future that we'll have a way to provision cluster-local DNS names, we may want to use the same kind of mechanism to request a ClusterLocal DNS name for the Gateway.
 >
 > It's also possible that users will want to explicitly request an IP Families (v4, v6, or both). I'd really hate to get into a situation where we have the following options:
 >
->   IPAddress
->   IPv4Address
->   IPv6Address
->   ClusterLocalIPAddress
->   ClusterLocalIPv4Address
->   ClusterLocalIPv6Address
+> - IPAddress
+> - IPv4Address
+> - IPv6Address
+> - ClusterLocalIPAddress
+> - ClusterLocalIPv4Address
+> - ClusterLocalIPv6Address
 >
 > For each dimension we avoid adding a separate field for and instead try to embed into a single name, we risk this kind of name explosion. Of course none of the above even begins to cover my idea of NetworkLocal which could further complicate this.
 
 ### Scope/reachability/routability field on GatewayAddress
 
 This would allow Gateways to have multiple scopes.
 
-From: https://github.com/kubernetes-sigs/gateway-api/pull/1653#issuecomment-1486271913
+From: [https://github.com/kubernetes-sigs/gateway-api/pull/1653#issuecomment-1486271913](https://github.com/kubernetes-sigs/gateway-api/pull/1653#issuecomment-1486271913)
 > The obvious application for multiple scopes seems to be saving on boilerplate, which is a win, but are there are any other advantages to allowing one Gateway to have multiple scopes?
 >
 > Multiple scopes Pros:
@@ -388,6 +388,7 @@ Additionally, if more attributes are added to GatewayClass to constrain Gateways
 form this leads to a combinatorial number of GatewayClassNames. For example, `foo-public` and
 `foo-cluster` are two GatewayClasses surfacing the values of a single attribute `routability`.
 Let's say we want to enforce address types to just IP then our `gatewayClassName` would be:
+
 - `foo-public-ipv4`
 - `foo-public-ipv6`
 - `foo-cluster-ipv4`
@@ -401,8 +402,8 @@ As howardjohn mentioned [here](https://github.com/kubernetes-sigs/gateway-api/pu
 
 ## References
 
-- Knative - Private Services - https://knative.dev/docs/serving/services/private-services/#configuring-private-services
-- Initial Gateway GitHub Discussion - https://github.com/kubernetes-sigs/gateway-api/discussions/1247
-- Istio Support for Private Gateways - https://istio.io/latest/docs/tasks/traffic-management/ingress/gateway-api/#automated-deployment
-- Envoy Gateway Support for Private Gateways - https://gateway.envoyproxy.io/latest/api/config_types.html#kubernetesservicespec
+- [Knative - Private Services](https://knative.dev/docs/serving/services/private-services/#configuring-private-services)
+- [Initial Gateway GitHub Discussion](https://github.com/kubernetes-sigs/gateway-api/discussions/1247)
+- [Istio Support for Private Gateways](https://istio.io/latest/docs/tasks/traffic-management/ingress/gateway-api/#automated-deployment)
+- [Envoy Gateway Support for Private Gateways](https://gateway.envoyproxy.io/latest/api/config_types.html#kubernetesservicespec)