Last Call Review of draft-ietf-taps-transports-11
review-ietf-taps-transports-11-genart-lc-sparks-2016-09-06-00

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?