[xrblock] [Gen-art] Review: draft-ietf-xrblock-rtcp-xr-qoe-12

Joel Halpern <jmh@joelhalpern.com> Tue, 12 November 2013 12:12 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9EB21F9D23; Tue, 12 Nov 2013 04:12:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcCN0vqQauyd; Tue, 12 Nov 2013 04:12:06 -0800 (PST)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 2A94E21E8113; Tue, 12 Nov 2013 04:12:06 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 213741BC555D; Tue, 12 Nov 2013 04:12:05 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net
Received: from Joels-MacBook-Pro.local (unknown [192.165.183.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 1895F1BCCC3C; Tue, 12 Nov 2013 04:12:03 -0800 (PST)
Message-ID: <52821B12.2030700@joelhalpern.com>
Date: Tue, 12 Nov 2013 07:12:02 -0500
From: Joel Halpern <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "A. Jean Mahoney" <mahoney@nostrum.com>, gen-art@ietf.org, draft-ietf-xrblock-rtcp-xr-qoe.all@tools.ietf.org, xrblock@ietf.org
References: <527D2037.1010304@nostrum.com>
In-Reply-To: <527D2037.1010304@nostrum.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [xrblock] [Gen-art] Review: draft-ietf-xrblock-rtcp-xr-qoe-12
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <xrblock.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xrblock>, <mailto:xrblock-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xrblock>
List-Post: <mailto:xrblock@ietf.org>
List-Help: <mailto:xrblock-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xrblock>, <mailto:xrblock-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Nov 2013 12:12:10 -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-xrblock-rtcp-xr-qoe-12
     RTP Control Protocol (RTCP) Extended Report (XR) Blocks for
                        MOS Metric Reporting
Reviewer: Joel M. Halpern
Review Date: 12-November-2013
IETF LC End Date: 27-November-2013
IESG Telechat date: N/A

Summary: This document is nearly ready for publication as a Proposed 
Standard RFC

Major issues:

Moderate issues:
     In section 3.2.2 on Multi-Channel audio per SSRC Segment, the 
format description for the Calculation Algorithm ID (CAID) reads:
"The 8-bit ID is the local identifier of this segment in the range
1-255 inclusive."  I am pretty sure this is supposed to be an algorithm 
ID, not a segment index?

     The text in section 4.1 indicates that the number after "calg:" in 
the mapentry of the calgextmap is used as the ID in the CAID of the 
xrblock.  The packet format only allows 8 bits of value.  So why does 
the SDP format allow up to 5 digits?  Also, is there some reason that 
the special values 4095-4351 (in section 4.1) or 4096-4351 (in section 
4.2) are used rather than say equally invalid 512 through some 
appropriate upper bound still in 3 digits?

Minor issues:
     Please ensure that all acronyms are expanded on first use.  For 
example, QoE is not expanded.

     The notes in B.3 indicate that mostype was to be removed from the 
SDP grammar.  But it is still defined.  And section 4.2 still mentions 
it, even though it does not get referenced by the message format. Please 
finish removing it.  (also "most type")

Nits/editorial comments: