Draft: draft-pauly-taps-arch

Commentary: seeing no comment ... :) 
 Sorry , looks good =) Busy week over here ! 
 See thread at Suggested resolution : implementation must have a deterministic tiebreaker , current recommendation is that path properties take precedence . API should note expected behavior . There should be additional text on candidate selection and ordering . 
 Give example for path candidate gathering and sorting ( get selection properties , get available paths in system preferred order , walk through them cancelling out the prohibited ones , and ranking preferences ; get ultimate list ) . Do the same for protocols likely . 
 Added text to API and Implementation drafts on branch " conflicting - policies " . API has an example , implementation still needs one . Feel free to add , otherwise I 'll come back to it later today or tomorrow . 
 I guess that works for -00 For -01 , we might want to integrate the resolution a little bit more into the decision process . 
 Resolved by PR 
 The Sec Con section contains a large number of unexpanded abbreviations . Compared to the remainder of the document this requires much more knowledge of these terms , suggest we expand them here . 
 The sentence reads : Beyond these , if the API for the system remains the same over time , new protocols and features may be to the system 's implementation without requiring significant changes in applications for adoption . However , this kind of suggests that some small change is needed to apps . That 's not necessarilly true , and I think the key point is the converse ( i.e , 3.1 below ) . Can I suggest : Beyond these , if the API for the system remains the same over time , new protocols and features may be to the system 's implementation without requiring changes in applications for adoption .
Mailing list commentary: Hi , I made this comment in the past in QUIC when discussing migration . One policy may be prefer wifi over cellular network , Second policy prefers quic cove TCP Now I walk into my house and my cellphone has HTTP over QUIC . At home will switch to wifi but quic is not supported on the wifi so will fall back to TCP . This contradicts the second policy . So two options wifi TCP or cellular QUIC , how to decide ?
Paragraph (version A):
Many APIs to perform transport networking have been deployed, perhaps
the most widely known and imitated being the BSD socket() interface.
The names and functions between these APIs are not consistent, and
vary depending on the protocol being used.  For example, sending and
receiving on a stream of data is conceptually the same between
operating on an unencrypted TCP stream and operating on an encrypted
TLS stream over TCP, but applications cannot use the same socket
send() and recv() calls on top of both kinds of connections.
Similarly, terminology for the implementation of protocols offering
transport services vary based on the context of the protocols
themselves.  This variety can lead to confusion when trying to
understand the similarities and differences between protocols, and
how applications can use them effectively.
Paragraph (version B):
Many APIs to perform transport networking have been deployed, perhaps
the most widely known and imitated being the BSD socket() interface.
The names and functions between these APIs are not consistent, and
vary depending on the protocol being used.  For example, sending and
receiving on a stream of data is conceptually the same between
operating on an unencrypted Transmission Control Protocol (TCP)
stream and operating on an encrypted Transport Layer Security (TLS)
I-D.ietf-tls-tls13 stream over TCP, but applications cannot use the
same socket send() and recv() calls on top of both kinds of
connections.  Similarly, terminology for the implementation of
protocols offering transport services vary based on the context of
the protocols themselves.  This variety can lead to confusion when
trying to understand the similarities and differences between
protocols, and how applications can use them effectively.
Paragraph (version A):
There are several degrees in which a Transport Services system can
offer flexibility to an application: it can provide access to
multiple sets of protocols and protocol features, it can use these
protocols across multiple paths that may have different performance
and functional characteristics, and it can communicate with different
Remote Endpoints to optimize performance.  Beyond these, if the API
for the system remains the same over time, new protocols and features
may be added to the system's implementation without requiring
significant changes in applications for adoption.
Paragraph (version B):
There are several degrees in which a Transport Services system can
offer flexibility to an application: it can provide access to
multiple sets of protocols and protocol features, it can use these
protocols across multiple paths that may have different performance
and functional characteristics, and it can communicate with different
Remote Endpoints to optimize performance.  Beyond these, if the API
for the system remains the same over time, new protocols and features
may be added to the system's implementation without requiring changes
in applications for adoption.
Paragraph (version B):
Transport Services APIs will expose similar functionality.