Transport Services
charter-ietf-taps-02

Wow, nearly every word of this text has changed since the IESG saw it
last!

I continue to have no objection to the formation of this WG, but I 
have some wordwmithing suggestions.

---

You have two tones of the word "provided" in the following...

  We use the term "Transport 
  Service" to mean an end-to-end facility provided by the 
  transport layer that can only be correctly provided with 
  information from the application. This information may be 
  provided at design time, compile time, or run time and may 
  include guidance from the application on whether the facility 
  in question is required or simply a preference by the application.

"...provided with information" means "...given information". This
is reinforced by the next sentence saying "This informaiton is provided",
but you mean that it is the service that can only be correctly provided
if...

Furthermore, it is the service that is provided not the layer!

I suggest...
  We use the term "Transport 
  Service" to mean an end-to-end facility provided by the 
  transport layer. That service can only be provided correctly if 
  information is supplied from the application. This information may be 
  supplied at design time, compile time, or run time and may 
  include guidance from the application on whether the facility 
  in question is required or simply a preference by the application.

Finally, it is not clear what is being deisgned, compiled, or run. I
think you need to clarify that as well. 

---

   Four examples of Transport Services are reliable delivery, no 
   guarantee of order preservation, content privacy to in-path 
   devices, and minimal latency.

Hmmm, "no guarantee" is a service? Where can I sign up for that?
I think it is a service level. The service is "ordered delivery of
data".

---

I think you have to decide whether you want to consider HTTP as a 
transport protocol or an application protocol (or call it out as
both). Currently you have...

   Many firewalls only pass TCP 
   and UDP and some only support HTTP over TCP.

...implying HTTP is a protocol carried by a transport protocol. An
impression reinforced by not including it in the previous list of
transport protocols.

But then...

   Applications, 
   therefore, must always be able to fall back to TCP or UDP, or even 
   HTTP in many cases, and once the application programmer has committed 
   to making an application work on TCP or UDP or HTTP, there is little 
   incentive to try other transport protocols before falling back.

...with "fall back to ... HTTP" implying HTTP is a transport protocol.

---

   how to 
   discover which protocols are available for a given connection.

I wonder whether "connection" is the right word. I think you probably
mean "for the selected service between a given pair of end points."

---

   TAPS is not chartered to perform detailed analysis of the security 
   aspects of transport protocols

This is fine, but will people lose track of the fact that security is
a transport service?

1) Define a set of Transport Services, prioritizing those provided by 
   existing IETF protocols and congestion control mechanisms. As a 
   starting point, the working group will consider services used 
   between two endpoints.

What does "prioritizing" mean in the above sentence? 
If I take your 4 examples (reliable delivery, no guarantee of order preservation (*) content privacy to in-path devices, and minimal latency.), how can you prioritize those? You can't, it's purely an application programmers choice.

Or maybe I missed something?
Don't you mean "identifying" instead of "prioritizing", or maybe "identifying the most common ones"

(*) btw, same remark as Adrian wrt "no" guarantee of order preservation as a service