I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-taps-transports-11
Reviewer: Robert Sparks
Review Date: 6 Sep 2016
IETF LC End Date: 9 Sep 2016
IESG Telechat date: not yet scheduled

Summary: Ready (with very small nits) for publication as an 
Informational RFC

Please consider a light touch to the Introduction and perhaps the 
Abstract making the point of this survey explicit. I can figure it out 
from reading the TAPS charter - I shouldn't have to go that far. The 
Abstract touches (too) briefly on this being background for determining 
a common set of transport services, but the message is lost in the 
roll-call of protocols that dominate the text. I don't think listing the 
surveyed protocols in the abstract is going to help anyone in the future 
- consider leaving the list for the body of the text.

Please also make it more clear that this is _only_ background for input 
into the next task of converging on a common core set of transport 
services. It would be a disservice to the community if someone in the 
future could argue "That service wasn't identified in 
draft-ietf-taps-transport so it's out of scope for anything the working 
group should be targeting". It looks like a lot went into this survey to 
try to make sure it provided a comprehensive overview of existing 
services, but I don't think that it's intent was to provide the 
definitive, exhaustive, list.

Should 3.7 acknowledge the state of work on TLS 1.3?

I find a list of things that have RTP and ICMP as peers to be 
unsettling.  I don't think it's worth the delay to ask the group to 
rationalize what's in the list and what isn't, or to restructure the 
psuedo-transports and the helpfully-related-protocol into different 
sections (questions like "why didn't you give FECFRAME its own section?" 
aren't going to help with the work this is supposed to inform). Perhaps 
the touch to the abstract and introduction requested above can say 
something like "The protocols listed here were chosen to help expose as 
many potential transport services as possible, and are not meant to be a 
comprehensive survey or classification of all transport protocols." With 
that thought, I challenge "classifies" in the Abstract - I think the 
document would serve just as well (and maybe avoid introducing 
controversy) if it doesn't claim to classify things.

I'm not finding the tables in Section 5 illuminating and they're 
potentially distracting and may not be right (why isn't reliability for 
RTP "Poss"  for example?). Please consider just removing the tables.

Nits:

The last paragraph of 3.3.1 was particularly hard to parse.

Searching the existing RFCs for "back-up" I don't find it used the way 
this document uses it. Should it use "back-off" instead?