Last Call Review of draft-ietf-avtext-rtp-grouping-taxonomy-06
review-ietf-avtext-rtp-grouping-taxonomy-06-genart-lc-sparks-2015-05-14-00

Request Review of draft-ietf-avtext-rtp-grouping-taxonomy
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2015-05-18
Requested 2015-05-07
Authors Jonathan Lennox, Kevin Gross, Suhas Nandakumar, Gonzalo Salgueiro, Bo Burman
Draft last updated 2015-05-14
Completed reviews Genart Last Call review of -06 by Robert Sparks (diff)
Genart Telechat review of -07 by Robert Sparks (diff)
Secdir Last Call review of -06 by Paul Hoffman (diff)
Opsdir Last Call review of -06 by Menachem Dodge (diff)
Assignment Reviewer Robert Sparks
State Completed
Review review-ietf-avtext-rtp-grouping-taxonomy-06-genart-lc-sparks-2015-05-14
Reviewed rev. 06 (document currently at 08)
Review result On the Right Track
Review completed: 2015-05-14

Review
review-ietf-avtext-rtp-grouping-taxonomy-06-genart-lc-sparks-2015-05-14

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

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

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-avtext-rtp-grouping-taxonomy-06
Reviewer: Robert Sparks
Review Date: 14 May 2015
IETF LC End Date: 18 May 2015
IESG Telechat date: Not currently scheduled

Summary: This draft is on the right track, but has open issues.

This draft has clearly helped progress conversations across several 
working groups,
particularly around grouping streams. It's good that it was put 
together. I worry
a little about the timing of publishing it as an RFC now (is that driven 
by other
documents wanting to reference this normatively?) rather than keeping 
most of it
as a living document somewhere. That said, I don't think publishing it 
as an RFC
is going to hurt anything, but since future readers aren't going to be 
focusing
so hard on the current conversations, I want to check on a couple of things:

Major issues:

I'm surprised that there is no mention of how SRTP fits into the 
vocabulary this
document builds. Would it be a mistake for someone to think of SRTP as what
this document calls a transformation? Are there any consequences of 
using SRTP
on one or more of the streams being associated that impact how you would 
talk about
the association? (There are certainly consequences about which elements 
can see
into the various streams).

Minor issues:

The title says this document is about grouping. While conversations around
grouping motivated the document, the text goes well beyond describing 
grouping.
The abstract and introduction don't contain the word 'grouping'; 
instead, they cast
the document as being about describing sources, but the document goes 
well beyond
a taxonomy of sources. It suggest reworking these sections to reflect 
what the
document ended up being.

Nits/editorial comments:

In more-or-less document order:

The document call out the possibility of loops, but no discussion shows 
the use
of one. What motivated calling out the possibility?

The use of "Characteristics" is inconsistent across the sections. Sometimes
the bullets list things that could be used to classify a thing, and 
sometimes
they appear to be a set of observations about the thing. It's hard to tell
whether the lists are intended to be complete or exclusive, depending on the
section. Perhaps these should be worked mostly back into the prose, leaving
points here that are specific to clarifying the taxonomy?

"The actually used codec is also an important factor in many 
communication systems."
is unclear. What's this trying to say?

In 2.1.10, 2nd paragraph, is "at least some content" accurate? What 
about the
edge cases where encoding results in an empty stream (an audio stream 
that is
silent, where the codec does silence suppression resulting in no bits 
out for
example). You're still going to be emitting RTCP. Is this section saying
that the RTP stream doesn't qualify as a Source stream?

In 2.2.1 it's not clear what "ensure Endpoint Identification" means. Did you
mean something like 'establish' instead of 'ensure'?

At the end of the first paragraph of 3.6, you point forward to 3.12 for a
discussion of other considerations effecting which usage is desirable.
3.12 doesn't talk about that. It only talks about how you separate the
streams. What is "other considerations" supposed to be pointing to?

Very tiny nits and suggestions:
2.1.4 paragraph 1 : s/as NTP synchronized/as an NTP synchronized clock/
2.1.4 last bullet : In "At any point, it", the word 'it' is ambiguous.
2.1.6 Characteristics bullet: This isn't a characteristic of a Media 
encoder.
       The sentence is almost a cyclic definition. I suggest removing the
       characteristics section from this (or saying something different).
2.1.19 "the Media Transport's transformation" is ambiguous. Which one?
        Did you mean "the combination of of the transport sender, network
        transport, and transport receiver transformations", or something
        like it?
3.5 Consider clarifying "mono encoder"
3.6 last sentence: s/This to/This is to/ or s/This to enable/This enables/