rewording

Author: maleck13

geps/gep-2627/index.md

@@ -10,7 +10,7 @@ For gateway infrastructure to be valuable we need to be able to connect clients
 ## Goals
 * Allow cluster operators to declaratively express which DNS service they want to use with a particular Gateway or Gateway Listener.
 * Provide a mechanism to allow the DNS configuration to be delegated to a chosen controller.
-* Provide a standard CRD-based API as an alternative to the need for "loose" APIs such as annotations.   Support an easily extended, standardized, versioned, and status-reporting API.
+* Provide a standard CRD-based API with expressive status reporting and remove the need for "loose" APIs such as annotations.
 * Increase portability and supportability between Gateway API implementations and third party controllers offering DNS integration.
 
 ## Non-Goals
@@ -19,7 +19,7 @@ For gateway infrastructure to be valuable we need to be able to connect clients
 
 ## Use Cases
 
-As a cluster administrator, I manage a set of domains and a set of gateways. I would like to declaratively define which DNS provider to use to configure connectivity for clients accessing these domains and my gateway so that I can see and configure which DNS provider is being used and limit which domains can be used.
+As a cluster administrator, I manage a set of domains and a set of gateways. I would like to declaratively define which DNS provider to use to configure connectivity for clients accessing these domains and my gateway so that I can see and configure which DNS provider is being used.
 
 As a cluster administrator, I would like to have the DNS names automatically populated into my specified DNS zones as a set of records based on the assigned addresses of my gateways so that I do not have to undertake external automation or management of this essential task.
 
@@ -32,7 +32,7 @@ As a cluster administrator, I would like the DNS records to be setup automatical
 Initial draft will not offer an API yet until the use cases are agreed. Some thoughts worth thinking about: 
 - I think it is important that we try to move away from APIs based on annotations which, while convenient, are not a full API and suffer from several limitations. An example: I want to configure a listener with a domain I own that is in a different provider than the domains of the other listeners. I want to add a new option to configure a particular weighting and so on. Soon you end up with a large set of connected annotations that often grow in complexity that really should be expressed as an API.
 
-- It is also important that this API can be delegated to controllers other than the Gateway provider. This is because there are existing solutions that may want to support whatever API decided upon. It should not **have** to be a gateway provider that has to integrate with many DNS providers. 
+- It is also important that this API can be delegated to controllers other than the Gateway API provider/implementor. This is because there are existing solutions that may want to support whatever API decided upon. It should not **have** to be a gateway provider that has to integrate with many DNS providers. 
 
 ## Conformance Details