Transport Services
charter-ietf-taps-02

Is it really necessary to begin the charter with an adverb, and one that every non-native speaker will need to look up in  a dictionary before trying to parse the sentence and work out to what it applies?

I think this is ready for external review, but I have a question that I think should be addressed before this group gets chartered. There is no indication in the charter of the criteria that will be considered when selecting the subset of services that need to be supported by TAPS-capable endpoints. That seems to leave things quite open-ended and susceptible to arguments that most every service needs to be supported. If there is some existing notion that the subset will be tailored based on some criteria, it would be good to explain that in the charter.

I believe the charter text improved a lot.
Thank you for addressing my BLOCK.

I am tempted to ask that it be made explicit that this be ipv6 only.

I think that's an important concession for recognizing the ipv4 internet has substantially ossified to the point that stack inovation that is  generally useful is confined being above transport.

likewise interactions that involve transition technologies should be off the table.

I'm interested to see Stephen's and Alissa's questions answered, but have nothing else to add.

[Fixing a typo]

This could go for external review as-is. Some things to consider, either now or during external review:

I am not as concerned as Benoit that his clarifications need to be made; they won't hurt, but I don't think they're strictly necessary. That said, I do think I'd like to see the word "applications" occur sometime in the work items and the section on coordination. :-)

Can someone describe for me the difference between providing a set of "transport services" and providing a "session layer"? Does such a description need to go in here?

Also along the lines of Alissa's comment, I'd be interested in 
whether and how the security properties of transports are to
be handled here. I hope they are, but it'd be good for a final
charter to mention that. One specific instance of that that'd 
be useful to consider could be tcpinc. That might lead to 
tricky timing, but OTOH, it'd be a pain if tcpinc were ignored 
here.

Many applications actually fall back to (or just stick with) HTTP
for the reasons stated here, I don't know if it makes sense
to de-scope those applications here or not, but hope that 
that's discussed during chartering (maybe it has been already?).

Stupidly, I find paragraphs and sentences that start with 
an adverb, comma are harder to read. Annoyingly, for me, 
this charter does that. Politely, I'd ask you to consider fixing 
that:-)