[Gen-art] Genart LC review: draft-ietf-avtext-rtp-grouping-taxonomy-06

Robert Sparks <rjsparks@nostrum.com> Thu, 14 May 2015 19:22 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1674C1B2F53; Thu, 14 May 2015 12:22:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S31yH2_MczVz; Thu, 14 May 2015 12:22:04 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C33D1ACDE2; Thu, 14 May 2015 12:22:01 -0700 (PDT)
Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t4EJM0kq006060 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 May 2015 14:22:00 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local
Message-ID: <5554F5D3.7080204@nostrum.com>
Date: Thu, 14 May 2015 14:21:55 -0500
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: General Area Review Team <gen-art@ietf.org>, avtext@ietf.org, "ietf@ietf.org" <ietf@ietf.org>, draft-ietf-avtext-rtp-grouping-taxonomy@ietf.org
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/DgA7SIYs5XNEl53wRJp_Ur4NdWc>
Subject: [Gen-art] Genart LC review: draft-ietf-avtext-rtp-grouping-taxonomy-06
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 May 2015 19:22:06 -0000

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/