Re: [xrblock] FW: I-D Action: draft-ietf-xrblock-rtcp-xr-pdv-06.txt

Qin Wu <bill.wu@huawei.com> Sat, 22 September 2012 04:41 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 00A2721E810B for <xrblock@ietfa.amsl.com>; Fri, 21 Sep 2012 21:41:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.425
X-Spam-Level:
X-Spam-Status: No, score=-4.425 tagged_above=-999 required=5 tests=[AWL=-0.779, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, J_CHICKENPOX_64=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9SaCK0OvSUC for <xrblock@ietfa.amsl.com>; Fri, 21 Sep 2012 21:41:24 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DE24521E8104 for <xrblock@ietf.org>; Fri, 21 Sep 2012 21:41:23 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKX91694; Sat, 22 Sep 2012 04:41:22 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 22 Sep 2012 05:40:43 +0100
Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 22 Sep 2012 05:41:21 +0100
Received: from w53375 (10.138.41.149) by szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 22 Sep 2012 12:41:14 +0800
Message-ID: <FBA8DDD33B05495F91E6898F76D1A2D3@china.huawei.com>
From: Qin Wu <bill.wu@huawei.com>
To: Glen Zorn <glenzorn@gmail.com>
References: <EDC652A26FB23C4EB6384A4584434A0408129C10@307622ANEX5.global.avaya.com><505748C5.60701@gmail.com><EE3DB190F8C24FA29DEAB8BD531B1380@china.huawei.com><EDC652A26FB23C4EB6384A4584434A0408129D56@307622ANEX5.global.avaya.com><50584298.9040407@ericsson.com><EDC652A26FB23C4EB6384A4584434A0408129E1C@307622ANEX5.global.avaya.com><505B2088.6030208@cisco.com> <505B2F1C.7090606@ericsson.com><EDC652A26FB23C4EB6384A4584434A040812A3D4@307622ANEX5.global.avaya.com> <505C62DB.4080300@gmail.com> <E561737C4D424CA58127D184AB632CE3@china.huawei.com> <505D39D5.2030003@gmail.com>
Date: Sat, 22 Sep 2012 12:41:12 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Originating-IP: [10.138.41.149]
X-CFilter-Loop: Reflected
Cc: xrblock@ietf.org
Subject: Re: [xrblock] FW: I-D Action: draft-ietf-xrblock-rtcp-xr-pdv-06.txt
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: Sat, 22 Sep 2012 04:41:26 -0000

Hi,
----- Original Message ----- 
From: "Glen Zorn" <glenzorn@gmail.com>
To: "Qin Wu" <bill.wu@huawei.com>
Cc: "Glen Zorn" <glenzorn@gmail.com>; "Romascanu, Dan (Dan)" <dromasca@avaya.com>; <xrblock@ietf.org>
Sent: Saturday, September 22, 2012 12:08 PM
Subject: Re: [xrblock] FW: I-D Action: draft-ietf-xrblock-rtcp-xr-pdv-06.txt


> On 09/22/2012 09:17 AM, Qin Wu wrote:
> 
> ...
> 
>>> COMMENT The last phrase is  confusing, because it seems that what
> >> causes MAPDV2 to be reported is that really the fact that the value
> >> of the pdvtype field is 0; the rest of the values seem irrelevant
> >> (or at least esoteric).
> >
> > [Qin]:It looks esoteric but required since it is up to measurement
> > method defined in G.1020 or Y.1540. You can see SDP also signals
> > that.
> >
> >>
> >> Section 4 COMMENT Is "<as defined in Section 3.4 of [RFC5234]>"
> >> valid ABNF?
> >>
> >> COMMENT When SDP is used in offer-answer, a system sending SDP may
> >> request a specific type of PDV measurement. In addition, they may
> >> state a specific percentile or threshold value, and expect to
> >> receive the corresponding threshold or percentile metric,
> >> respectively. The system receiving the SDP SHOULD send the PDV
> >> metrics requested, but if the metric is not available, the system
> >> receiving the SDP MUST send the metric block with the flag value
> >> indicating that the metric is unavailable. I don't see any flag
> >> value in this block that indicates that the metric is unavailable.
> >
> > [Qin]: The flag value is in the mean PDV field, Positive PDV
> > Threshold/Peak field,Positive PDV Percentile,etc. e.g., we use 0xFFFF
> > to indicate metric is unavailable.
> 
> I see, thanks!
> 
>>
> >>
> >> Section 5.4 COMMENT o Initial assignments are as follows:
> >>
> >> * 0: MAPDV2, Clause 6.2.3.2 of [G.1020],
> >>
> >> * 1: 2-point PDV, Clause 6.2.4 of [Y.1540]
> >>
> >> Are the rest of the values reserved?
> >
> > [Qin]: Yes. Here we just give initial assignments.
> 
> OK, but the initial assignments include the reservation of unassigned 
> values, right?  I'm pretty sure that IANA will ask this question later , 
> so why not save time now?

[Qin]: Okay, how about add one statement at the end of initial assignment part to say.
value 2-15 are valid and reserved for future use. 

>>
> >>
> >> Section 6 OLD The authors gratefully acknowledge the comments and
> >> contributions made by Bruce Adams, Philip Arden, Amit Arora, Bob
> >> Biskner, Kevin Connor, Claus Dahm, Randy Ethier, Roni Even, Jim
> >> Frauenthal, Albert Higashi, Tom Hock, Shane Holthaus, Paul Jones,
> >> Rajesh Kumar, Keith Lantz, Mohamed Mostafa, Amy Pendleton, Colin
> >> Perkins, Mike Ramalho, Ravi Raviraj, Albrecht Schwarz, Tom Taylor,
> >> and Hideaki Yamada,Jing Zhao,Kevin Gross, Colin Perkins, Charles
> >> Eckel, Glen Zorn,Shida Schubert, Benoit Claise, Adrian Farrel, Pete
> >> Resnick. NEW The authors gratefully acknowledge the comments and
> >> contributions made by Bruce Adams, Philip Arden, Amit Arora, Bob
> >> Biskner, Kevin Connor, Claus Dahm, Randy Ethier, Roni Even, Jim
> >> Frauenthal, Albert Higashi, Tom Hock, Shane Holthaus, Paul Jones,
> >> Rajesh Kumar, Keith Lantz, Mohamed Mostafa, Amy Pendleton, Colin
> >> Perkins, Mike Ramalho, Ravi Raviraj, Albrecht Schwarz, Tom Taylor,
> >> Hideaki Yamada, Jing Zhao, Kevin Gross, Colin Perkins, Charles
> >> Eckel, Glen Zorn, Shida Schubert, Benoit Claise, Adrian Farrel and
> >> Pete Resnick.
> >
> > [Qin]: Okay.
> >
> >> COMMENT The first sentence says "The authors gratefully acknowledge
> >> the comments and contributions" but there is a "Contributors"
> >> section. If some of these people actually contributed to the
> >> document (i.e., text), shouldn't they at a minimum be in that
> >> section, if not added as authors?
> >
> > [Qin]: I can't remember who is contributor and who is not in the
> > history. Sorry about that.
> 
> OK, so maybe change "comments and contributions made by" to "reviews and 
> feedback provided by".  The reasons are that
> 
> 1. "contributor" is a technical term, denoting a person who has done
>    more than just review a draft and thus deserves more credit and
> 2. some people are very sensitive about getting the credit them

[Qin]: Okay, looks reasonable to me, thanks.
>>
> >> _______________________________________________ xrblock mailing
> >> list xrblock@ietf.org
> >> https://www.ietf.org/mailman/listinfo/xrblock
> 
>