Re: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-qoe-08

Qin Wu <bill.wu@huawei.com> Thu, 13 June 2013 11:45 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0054F21F8F61; Thu, 13 Jun 2013 04:45:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.66
X-Spam-Level:
X-Spam-Status: No, score=-5.66 tagged_above=-999 required=5 tests=[AWL=0.938, 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 reKW1UotHPvm; Thu, 13 Jun 2013 04:44:55 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 84C9A21F8528; Thu, 13 Jun 2013 04:44:54 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASK58399; Thu, 13 Jun 2013 11:44:52 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 13 Jun 2013 12:44:34 +0100
Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 13 Jun 2013 12:44:47 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.43]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Thu, 13 Jun 2013 19:44:44 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "Ali C. Begen (abegen)" <abegen@cisco.com>, "draft-ietf-xrblock-rtcp-xr-qoe@tools.ietf.org" <draft-ietf-xrblock-rtcp-xr-qoe@tools.ietf.org>
Thread-Topic: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-qoe-08
Thread-Index: AQHOZ2ssXcGF3Gxm8Ues0m/5fP6WJZkzfjEQ
Date: Thu, 13 Jun 2013 11:44:43 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA43B40FE2@nkgeml501-mbs.china.huawei.com>
References: <C15918F2FCDA0243A7C919DA7C4BE9940D1411C0@xmb-aln-x01.cisco.com>
In-Reply-To: <C15918F2FCDA0243A7C919DA7C4BE9940D1411C0@xmb-aln-x01.cisco.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_B8F9A780D330094D99AF023C5877DABA43B40FE2nkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: xrblock-chairs <xrblock-chairs@tools.ietf.org>, mmusic <mmusic@ietf.org>, 'xrblock' <xrblock@ietf.org>
Subject: Re: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-qoe-08
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Jun 2013 11:45:00 -0000

Hi,Ali:
Thank for your valuable review. Please see my reply inline below.

Regards!
-Qin
From: mmusic-bounces@ietf.org<mailto:mmusic-bounces@ietf.org> [mailto:mmusic-bounces@ietf.org] On Behalf Of Ali C. Begen (abegen)
Sent: Thursday, June 13, 2013 5:14 PM
To: draft-ietf-xrblock-rtcp-xr-qoe@tools.ietf.org<mailto:draft-ietf-xrblock-rtcp-xr-qoe@tools.ietf.org>
Cc: xrblock-chairs; mmusic
Subject: [MMUSIC] SDP Directorate: Review of draft-ietf-xrblock-rtcp-xr-qoe-08

I am the assigned SDP directorate reviewer for this draft. For background on the SDP directorate, please see the FAQ at

http://www.ietf.org/iesg/directorate/sdp.html

Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Summary:
- I have a serious concern about the definition of QoE and usage of MOS in this draft.
- The RTCP XR extension syntax seems to have an issue.
- There are quite a few grammatical/capitalization/spelling errors. Please proofread the document.

[Qin]: Thanks, See below.

Issues:

- Section 1.3: s/guideline/guidelines, s/XR Block/XR block types

[Qin]: Okay.

- Section 1.4: s/"Audio/Video"/"audio/video", s/transport-dependent/transport-specific

[Qin]: Okay.

- Section 1.4: I don't understand what the following sentence means:

The factors in the second category are application-specific factors that affect real time application (e.g., video) quality and are sensitivity to network errors.

[Qin]: What I am saying here is video is sensitive to transport impairment. So I believe I should remove the second part of this sentence to avoid confusion.
OLD TEXT:
"
The factors in the second category are application-specific factors that affect real time application (e.g., video) quality and are sensitivity to network errors.
"
NEW TEXT:
"
The factors in the second category are application-specific factors that affect real time application (e.g., video) quality.

"

- Section 1.4: s/but not limited/but are not limited

[Qin]: Okay.

- Section 1.4: I don't generally like the term "subscriber". Use more a more generic term like end-user, client, etc.

[Qin]: Okay, will use end user instead.

- Section 2.1: s/8:8/S8:8

[Qin]: In section 2.1, 8:8 is referred to 8:8 an unsigned number in the range 0.0 to
     255.996 with a granularity of 0.0039. We are intending to use S8:8 as an example. Instead, we use S7:8 to give the example.

- Section 3, first paragraph: The use of "recommended". These specific (2119) keywords are not supposed to be used in lower case.

[Qin]: Okay.

- I don't agree with the following statement:

   Information is recorded about QoE metric which provides a
   measure that is indicative of the user's view of a service.

The application cannot possibly know a user's view of service unless the user explicitly enters that info in some fashion to the application.

[Qin]:  The application can rely on QoE evaluation model to calculate MoS value and use such MoS value to reflect how end user feel or experience the media quality. That's what this statement want
to convey.

- Section 3.1:

I think you should replace:

The fields corresponding to unreported parameters MUST be present, but are set to zero.

With:

The fields corresponding to unreported parameters MUST be present, and MUST be set to zero.

[Qin]: Okay.


- Section 4.1: "extmap" attribute was defined in 5285 not 4566.

[Qin]: Okay.


- Section 4.1/4.2: Do not use "may/should/etc." in lower case. There are multiple occurrences of this.

[Qin]: Okay.


- Section 4.1: "extmap" is already a registered attribute name. I did not understand why and in what way you want to use it.

[Qin]: We need a new attribute defining the mapping from the different parameter names (i.e., the different calculation-algorithm parameter names) to the numeric values used in the packets Unlike RFC5285 extmap usage, we map name rather than URI to the numeric values used in the packet.
So I assume "extmap" can be reused, however if not, I believe we should define new attribute similar to "extmap" in this document.
- Section 4.2: s/indicates/indicate

[Qin]: Okay.

- Section 4.1/4.2: Extra spaces in the SDP examples.

Replace

a = rtcp-xr:qoe-metrics = calg:1=G107,calg:2=P1202.1

With

a=rtcp-xr:qoe-metrics=calg:1=G107,calg:2=P1202.1

[Qin]: Okay.

- Section 5.1: Use the correct registry name: "RTP Control Protocol Extended Reports (RTCP XR) Block Type Registry"

[Qin]: Okay.


6) Section 5.2: Use the correct registry name: "RTP Control Protocol Extended Reports (RTCP XR) Session Description Protocol (SDP) Parameters Registry".

[Qin]: Okay.