Address comments

debug/README.md

@@ -8,13 +8,35 @@
 * [gNOI Repository](https://github.com/openconfig/gnoi)
 * [gNOI `Debug` service](https://github.com/openconfig/gnoi/tree/master/debug)
 
-For all legacy devices that provided a CLI on box, providers  have leveraged this CLI through services to provide users with the ability to interact with device CLI's to both get information as well as set operational state on devices.  This interaction is very vendor specific and requires significant overhead to maintain the vendor specific bindings throughout the operational life cycle of a device.
-
-With the introduction of g* services, the goal has been to remove vendor specific data formats from the view operators.  This lets operators have standard models for interacting with any number of vendor devices consistently. There however are gaps between those endpoints versioning and the ability to troubleshoot specific data on a device before APIs can be updated.  This proposal is to enable a lightweight interface via gRPC to still access shell level interactions on the device in a secure, maintainable way.
+Traditional network devices provide a CLI, which providers have leveraged for
+configuration and retrieval of operational state. The implementation of these
+CLIs is vendor-specific, and requires specific per-vendor client code and
+logic. Programmatic use of the CLI is fragile -- being based on parsing
+unstructured strings designed for human consumption, rather than structured
+machine-friendly data.
+
+With the introduction of g* services, the goal has been to remove vendor
+specific data formats from the view operators. This lets operators have
+standard models for interacting with any number of vendor devices consistently.
+There however are gaps between those endpoints versioning and the ability to
+troubleshoot specific data on a device before APIs can be updated. This
+proposal is to enable a lightweight interface via gRPC to still access shell
+level interactions on the device in a secure, maintainable way.
+
+It is expected that where structured data is identified to be useful for an
+operator the suite of g* services, and/or underlying data models
+(e.g., OpenConfig) are extended to cover these use cases. However, it is
+critical to recognise that these APIs are not the "native" device APIs, and
+hence upgrading them requires some new software to be introduced.
 
 ## Architecture
 
-The service will run on a specified port. This service upon recieving a command the server will validate the user has access to the service via Authz check. If user has access the server will then parse the request and check if the user has both the acccess to run the command and if provided act as the role user. If the user is allowed the device will then open "shell" in the mode requested and execute the command in that mode. 
+The service will run on a specified port. This service upon recieving a command
+the server will validate the user has access to the service via Authz check. If
+user has access the server will then parse the request and check if the user
+has both the acccess to run the command and if provided act as the role user.
+If the user is allowed the device will then open "shell" in the mode requested
+and execute the command in that mode.
 
 ## User Experience