Re: [xrblock] [Gen-art] Review: draft-ietf-xrblock-rtcp-xr-qoe-12
Qin Wu <bill.wu@huawei.com> Wed, 13 November 2013 02:14 UTC
Return-Path: <bill.wu@huawei.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 192E421F9FF9; Tue, 12 Nov 2013 18:14:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.496
X-Spam-Level:
X-Spam-Status: No, score=-5.496 tagged_above=-999 required=5 tests=[AWL=1.102, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 W4HANvTvezKV; Tue, 12 Nov 2013 18:14:15 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2316921F9FCF; Tue, 12 Nov 2013 18:14:13 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXU98612; Wed, 13 Nov 2013 02:14:13 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 Nov 2013 02:13:57 +0000
Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 Nov 2013 02:14:11 +0000
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.75]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Wed, 13 Nov 2013 10:14:05 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Alan Clark <alan.d.clark@telchemy.com>, Joel Halpern <jmh@joelhalpern.com>, "A. Jean Mahoney" <mahoney@nostrum.com>, "gen-art@ietf.org" <gen-art@ietf.org>, "draft-ietf-xrblock-rtcp-xr-qoe.all@tools.ietf.org" <draft-ietf-xrblock-rtcp-xr-qoe.all@tools.ietf.org>, "xrblock@ietf.org" <xrblock@ietf.org>
Thread-Topic: [xrblock] [Gen-art] Review: draft-ietf-xrblock-rtcp-xr-qoe-12
Thread-Index: AQHO36B5GaQugoB6sUCYJhv36OsK8pohTW6AgAEcKxA=
Date: Wed, 13 Nov 2013 02:14:05 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA43C39D68@nkgeml501-mbs.china.huawei.com>
References: <527D2037.1010304@nostrum.com> <52821B12.2030700@joelhalpern.com> <52825FDD.9070404@telchemy.com>
In-Reply-To: <52825FDD.9070404@telchemy.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.41.149]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43C39D68nkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [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: Wed, 13 Nov 2013 02:14:20 -0000
Hi, Alan: Thank for quick response. Here are additional changes I proposed. Regarding section 4.1, I propose the following change: OLD TEXT: mapentry = "calg:" 1*5 DIGIT ["/" direction] ;Values other than 4095~4351 are valid NEW TEXT: mapentry = "calg:" 1*3 DIGIT ["/" direction] ;Values 1..255 are valid OLD TEXT: " If the answerer wishes to reject a mosref attribute offered by the offerer, it sets identifiers associated with segment extensions in the answer to the value in the range 4096-4351. " NEW TEXT: " If the answerer wishes to reject a mosref attribute offered by the offerer, it sets identifiers associated with segment extensions in the answer to the value in the range 512-767. " OLD TEXT: " If a party wishes to offer mutually exclusive alternatives, then multiple segment extensions with the same identifier in the (unusable) range 4096-4351 MAY be offered; " NEW TEXT: " If a party wishes to offer mutually exclusive alternatives, then multiple segment extensions with the same identifier in the (unusable) range 512-767 MAY be offered; " OLD TEXT: " Similarly, if more segment extensions are offered than can be fit in the valid range, identifiers in the range 4096-4351 MAY be offered; " NEW TEXT: " Similarly, if more segment extensions are offered than can be fit in the valid range, identifiers in the range 512-767 MAY be offered; " OLD TEXT: " Note that the range 4096-4351 for these negotiation identifiers is deliberately restricted to allow expansion of the range of valid identifiers in future. " NEW TEXT: " Note that the range 512-767 for these negotiation identifiers is deliberately restricted to allow expansion of the range of valid identifiers in future. " Regards! -Qin From: xrblock-bounces@ietf.org [mailto:xrblock-bounces@ietf.org] On Behalf Of Alan Clark Sent: Wednesday, November 13, 2013 1:06 AM To: Joel Halpern; A. Jean Mahoney; gen-art@ietf.org; draft-ietf-xrblock-rtcp-xr-qoe.all@tools.ietf.org; xrblock@ietf.org Subject: Re: [xrblock] [Gen-art] Review: draft-ietf-xrblock-rtcp-xr-qoe-12 Hi Joel Thanks for your comments. (i) Section 1.4 Proposed change The MOS Metrics Report Block can be used in any application of RTP for which QoE measurement algorithms are defined. to The MOS Metrics Report Block can be used in any application of RTP for which QoE (Quality of Experience) measurement algorithms are defined. (ii) Section 3.2.2 Proposed change "The 8-bit ID is the local identifier of this segment in the range 1-255 inclusive" to "The 8-bit CAID is the session specific reference to the calculation algorithm and associated qualifiers indicated in SDP (see Section 4.1) and used to compute QoE scores for this segment" (iii) Section 3.2.1 Proposed change "The 8-bit CAID is the local identifier of calculation algorithm associated with this segment in the range 1-255 inclusive. " to "The 8-bit CAID is the session specific reference to the calculation algorithm and associated qualifiers indicated in SDP (see Section 4.1) and used to compute QoE scores for this segment" (iv) Section 4.1 Proposed change mapentry = "calg:" 1*5 DIGIT ["/" direction] ;Values other than 4095~4351 are valid to mapentry = "calg:" 1*3 DIGIT ["/" direction] ;Values other than 1..255 are valid and remove mostype = "mostype=" ("e"; Estimated MOS [P.800.1] /"s";subjective MOS [P.800.1] /"o";objective MOS [P.800.1] /non-ws-string) We will see if there are additional comments and then update the draft Regards Alan Clark On 11/12/13, 7:12 AM, Joel Halpern wrote: 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><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: _______________________________________________ xrblock mailing list xrblock@ietf.org<mailto:xrblock@ietf.org> https://www.ietf.org/mailman/listinfo/xrblock
- [xrblock] [Gen-art] Review: draft-ietf-xrblock-rt… Joel Halpern
- Re: [xrblock] [Gen-art] Review: draft-ietf-xrbloc… Gonzalo Camarillo
- Re: [xrblock] [Gen-art] Review: draft-ietf-xrbloc… Alan Clark
- Re: [xrblock] [Gen-art] Review: draft-ietf-xrbloc… Joel M. Halpern
- Re: [xrblock] [Gen-art] Review: draft-ietf-xrbloc… Qin Wu
- Re: [xrblock] [Gen-art] Review: draft-ietf-xrbloc… Alan Clark
- Re: [xrblock] [Gen-art] Review: draft-ietf-xrbloc… Qin Wu