Draft: draft-ietf-taps-arch

Commentary: Thanks for these fixes ! I did a bit of reworking of the abstract , but it keeps the main part of the changes you made . 
 Regarding the sentence you removed , that was an adaption of an existing sentence , which I believe aimed to mention the words implementation and API to implicitly refere to the other docs ( which was probably too subtle for anybody to notice anyway ) . However , the other change I made to that sentence was to mention one of the benefits / deployment incentives for taps ( dynamic protocol and path selection ) . I was n't sure about the wording here , but I think it would be good to ( re-)add a sentence to the abstract saying why taps is so great and that everybody should deploy it . 
 Yes , the original second sentence was aimed at mentioning that there were two other documents , API and Implementation , that would be based on this one . I liked how in your revision , it did try to make things clearer than just saying " flexible transport networking services " , but I felt that the specific example of dynamic path and protocol selection was a bit too specific for that one line . ( I was chatting with about this as I was editing , btw ) . My thought was that the list of features that you in right after that , which go through the top - level bullet points of the advantages , do a more comprehensive job of summarizing the benefit .
Paragraph (version A):
This document provides an overview of the architecture of Transport
Services, a system for exposing the features of transport protocols
to applications.  This architecture serves as a basis for Application
Programming Interfaces (APIs) and implementations that provide
flexible transport networking services.  It defines the common set of
terminology and concepts to be used in more detailed discussion of
Transport Services.
Paragraph (version B):
This document provides an overview of the architecture of Transport
Services, a model for exposing transport protocol features to
applications for network communication.  In contrast to what is
provided by most existing Application Programming Interfaces (APIs),
it is based on an asynchronous, event-driven interaction pattern; it
uses messages for representing data transfer to applications; and it
assumes an implementation that can use multiple IP addresses,
multiple protocols, multiple paths, and provide multiple application
streams.  This document further defines the common set of terminology
and concepts to be used in definitions of APIs and implementations.
Paragraph (version A):
The goal of the Transport Services architecture is to provide a
common, flexible, and reusable interface for 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 providing the interface can optimize its behavior based on the
application requirements and network conditions.
Paragraph (version A):
This document is developed in parallel with the specification of the
Transport Services API I-D.ietf-taps-interface and Implementation I-
D.ietf-taps-impl documents.
Paragraph (version B):
The goal of the Transport Services architecture is to provide a
common, flexible, and reusable interface for 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 providing the interface can optimize its behavior based on the
application requirements and network conditions, without requiring a
change to the application.  Further, this flexibility does not only
enable faster deployment of new feature and protocols, it can also
support applications with racing and fallback mechanisms which today
usually need to be implemented in each application separately.
Paragraph (version B):
This document is developed in parallel with the specification of the
Transport Services API I-D.ietf-taps-interface and Implementation I-
D.ietf-taps-impl documents.  Although following the Transport
Services Architecture does of course not mean that all APIs and
implementations have to be identical, agreeing on a common minimal
set of features and representing them in a similar fashion improves
the ability to easily port applications from one system to the
another.