Update draft-ietf-taps-interface.md

draft-ietf-taps-interface.md

@@ -126,26 +126,27 @@ informative:
 
 --- abstract
 
-This document describes an abstract programming interface to the transport
+This document describes an abstract programming interface (API) to the transport
 layer, following the Transport Services Architecture. It supports the
 asynchronous, atomic transmission of messages over transport protocols and
 network paths dynamically selected at runtime. It is intended to replace the
-traditional BSD sockets API as the lowest common denominator interface to the
-transport layer, in an environment where endpoints have multiple interfaces
-and potential transport protocols to select from.
+traditional BSD sockets API as a common interface to the
+transport layer, in an environment where endpoints can
+select from have multiple interfaces
+and multiple potential transport protocols.
 
 --- middle
 
 # Introduction
 
-This document specifies a modern abstract programming interface atop the
+This document specifies a modern abstract programming interface (API) atop the
 high-level architecture for transport services defined in
 {{I-D.ietf-taps-arch}}. It supports the
 asynchronous, atomic transmission of messages over transport protocols and
 network paths dynamically selected at runtime. It is intended to replace the
-traditional BSD sockets API as the lowest common denominator interface to the
-transport layer, in an environment where endpoints have multiple interfaces
-and potential transport protocols to select from.
+traditional BSD sockets API as a common interface to the
+transport layer, in an environment where endpoints can select from multiple interfaces
+and multiple potential transport protocols.
 
 As applications adopt this interface, they will benefit from a wide set of
 transport features that can evolve over time, and ensure that the system
@@ -161,11 +162,11 @@ properties and supported transport features from the analysis provided in
 {{I-D.ietf-taps-transport-security}}. The design encourages implementations 
 underneath the interface to dynamically choose a transport protocol depending on an 
 application's choices rather than statically binding applications to a protocol at 
-compile time. We note that transport system implementations SHOULD provide
+compile time. We note that transport system implementations should provide
 applications a way to override transport selection and instantiate a specific stack,
 e.g. to support servers wanting to listen to a specific protocol. This specific
-transport stack choice is discouraged for general use, as it comes at the
-cost of reduced portability.
+transport stack choice is discouraged for general use, because it can 
+come at the cost of reduce the portability.
 
 # Terminology and Notation
 
@@ -210,8 +211,8 @@ Action(param0, param1?, ...) / Event<param0, param1, ...>
 Actions associated with no Object are Actions on the abstract interface
 itself; they are equivalent to Actions on a per-application global context.
 
-How these abstract concepts map into concrete implementations of this API in a
-given language on a given platform is largely dependent on the features of the
+The mapping of these abstract concepts into concrete implementations of this API in a
+given language on a given platform mostly dependends on the features of the
 language and the platform. Actions could be implemented as functions or method
 calls, for instance, and Events could be implemented via event queues, handler
 functions or classes, communicating sequential processes, or other asynchronous