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/