As an author of the only draft in the RFC Editor queue that's waiting on this taxonomy draft, (that would be draft-ietf-dart-dscp-rtp) I certainly did not put any pressure on anyone to rush publication of this taxonomy draft. The normative reference that's causing the dart draft to wait for this taxonomy draft exists because it's important a single set of terminology be used with consensus on what the terms mean. IMHO, getting RFC content right is much more important than getting RFCs published quickly. Thanks, --David > -----Original Message----- > From: Gen-art [mailto:gen-art-bounces@xxxxxxxx] On Behalf Of DRAGE, Keith > (Keith) > Sent: Thursday, May 14, 2015 3:45 PM > To: Robert Sparks; General Area Review Team; avtext@xxxxxxxx; ietf@xxxxxxxx; > draft-ietf-avtext-rtp-grouping-taxonomy@xxxxxxxx > Subject: Re: [Gen-art] [avtext] Genart LC review: draft-ietf-avtext-rtp- > grouping-taxonomy-06 > > In regard to the summary comment, I would like to confirm that the issue of > when to publish was extensively discussed in the working group and between the > working group chairs and the authors. It was agreed that nothing would be > achieved by waiting and therefore there was consensus to move forward. > > The remainder I will leave to the document editor. > > Keith > AVTEXT working group co-chair > > > -----Original Message----- > > From: avtext [mailto:avtext-bounces@xxxxxxxx] On Behalf Of > > Robert Sparks > > Sent: 14 May 2015 20:22 > > To: General Area Review Team; avtext@xxxxxxxx; ietf@xxxxxxxx; > > draft-ietf-avtext-rtp-grouping-taxonomy@xxxxxxxx > > Subject: [avtext] Genart LC review: > > draft-ietf-avtext-rtp-grouping-taxonomy-06 > > > > 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/ > > > > > > > > > > > > _______________________________________________ > > avtext mailing list > > avtext@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/avtext > > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art