Fix PR comments

Signed-off-by: Nick Young <nick@isovalent.com>

site-src/geps/gep-713.md

@@ -6,12 +6,12 @@
 ## TLDR
 
 This GEP aims to standardize attachment of one Kubernetes object to another in
-Gateway API by establishing a pattern which defines how metaresources such as
+Gateway API by establishing a pattern which defines how _metaresources_ such as
 `Policy` API types can have their relevant effects applied to network traffic.
-Metaresources are a type of object that _augments_ the behavior of an object
-in a standard way.
+_Metaresources_ are a type of object that _augments_ the behavior of an object
+in a standard way. ReferenceGrant is an example of this general type of metaresource.
 
-"Policy Attachment" is a specific type of metaresource that controls how policy
+"Policy Attachment" is a specific type of _metaresource_ that controls how policy
 can flow _across_ multiple objects in a hierarchy.
 Individual policy APIs (e.g. `TimeoutPolicy`, `RetryPolicy`, etc) must include a
 common `TargetRef` field in their specification to identify how and where to
@@ -50,16 +50,16 @@ portable.
 
 ## Background and concepts
 
-One of the things we’ve found when making Gateway API is that we often need to be
-able to represent information _about_ objects _outside of_ those objects. That is,
-sometimes we need ways to be able to affect how an object is interpreted in the
-API, without representing the description of those effects inside the spec of the
-object.
+When designing Gateway API, one of the things we’ve found is that we often need to be
+able change the behavior of objects without being able to make changes to the spec
+of those objects. Sometimes, this is because we can’t change the spec of the object
+to hold the information we need ( ReferenceGrant, from GEP-709, affecting Secrets
+and Services is an example), and sometimes it’s because we want the behavior change
+to flow across multiple objects (this is what Policy Attachment is for).
 
-Sometimes, this is because we can’t change the spec of the object to hold the
-information we need ( ReferenceGrant, from GEP-709, is an example), and sometimes
-it’s because we want the information we need to flow across multiple objects
-(this is what Policy Attachment is for).
+To put this another way, sometimes we need ways to be able to affect how an object
+is interpreted in the API, without representing the description of those effects
+inside the spec of the object.
 
 This document describes the ways we design objects to meet these two use cases,
 and why you might choose one or the other.