Draft: draft-ietf-taps-interface

Commentary: I think the intro currently does n't fit well the content of the document as any motivation for this work should be in the  doc . If we want to retain the text that I deleted we can maybe add it to the Intro or background section in the  doc ... ? Note that the second paragraph I 've is stolen from the intro of the  doc . 
 I ca n't see how the existing text that proposed to delete could reasonably be merged with the intro text of the architecture doc ? and the text that 's there now motivates  just as nicely , IMO . I would be inclined to just delete the text and do the update exactly as proposes here . 
 I agree with , I like the new text much better and I do not think we should add the removed text to arch . 
 I think the text did its duty and it 's time to let go ... 
 I do n't have a strong opinion on this , for me it 's fine to have some motivation in this document as well . However , if we delete the motivation from this document , let 's put it in the -architecture , please - I would really like us to keep this text so dies the last text from the original post sockets paper ; ( lgtm :) I like this ; I think it improves the flow of the text , and I agree that the prior text is too motivational in style for this document . Even stealing a paragraph from the arch draft wo n't matter , I think . I really like this new intro and would like to have it irrespectively of moving the text as proposed in
Paragraph (version A):
The BSD Unix Sockets API's SOCK_STREAM abstraction, by bringing
network sockets into the UNIX programming model, allowing anyone who
knew how to write programs that dealt with sequential-access files to
also write network applications, was a revolution in simplicity.  The
simplicity of this API is a key reason the Internet won the protocol
wars PROTOCOL-WARS of the 1980s.  SOCK_STREAM is tied to the
Transmission Control Protocol (TCP), specified in 1981 RFC0793.  TCP
has scaled remarkably well over the past three and a half decades,
but its total ubiquity has hidden an uncomfortable fact: the network
is not really a file, and stream abstractions are too simplistic for
many modern application programming models.
Paragraph (version A):
In the meantime, the nature of Internet access, and the variety of
Internet transport protocols, is evolving.  The challenges that new
protocols and access paradigms present to the sockets API and to
programming models based on them inspire the design principles of a
new approach, which we outline in principles.
Paragraph (version A):
This document builds a modern abstract programming interface atop the
high-level architecture for transport services defined in I-D.ietf-
taps-arch.  It derives specific path and protocol selection
properties and supported transport features from the analysis
provided in RFC8095, I-D.ietf-taps-minset, and 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 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.
Paragraph (version B):
This document specifies a modern abstract programming interface 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.
Paragraph (version B):
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 changes to the applications.  This flexibility enables
faster deployment of new features and protocols.  It can also support
applications by offering racing and fallback mechanisms, which
otherwise need to be implemented in each application separately.
Paragraph (version B):
It derives specific path and protocol selection properties and
supported transport features from the analysis provided in RFC8095,
I-D.ietf-taps-minset, and 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 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.