I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . 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/