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

Benoit Claise <bclaise@cisco.com> Thu, 20 September 2012 13:56 UTC

Return-Path: <bclaise@cisco.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 A39DC21F84A7 for <xrblock@ietfa.amsl.com>; Thu, 20 Sep 2012 06:56:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.575
X-Spam-Level:
X-Spam-Status: No, score=-4.575 tagged_above=-999 required=5 tests=[AWL=-1.976, BAYES_00=-2.599]
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 ZRoEViSZlNhi for <xrblock@ietfa.amsl.com>; Thu, 20 Sep 2012 06:56:34 -0700 (PDT)
Received: from av-tac-bru.cisco.com (spooky-brew.cisco.com [144.254.15.113]) by ietfa.amsl.com (Postfix) with ESMTP id 55D1821F8471 for <xrblock@ietf.org>; Thu, 20 Sep 2012 06:56:34 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8KDuQjA012369; Thu, 20 Sep 2012 15:56:27 +0200 (CEST)
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8KDuOpo028004; Thu, 20 Sep 2012 15:56:24 +0200 (CEST)
Message-ID: <505B2088.6030208@cisco.com>
Date: Thu, 20 Sep 2012 15:56:24 +0200
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: "Romascanu, Dan (Dan)" <dromasca@avaya.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>
In-Reply-To: <EDC652A26FB23C4EB6384A4584434A0408129E1C@307622ANEX5.global.avaya.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: me <bclaise@cisco.com>, 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: Thu, 20 Sep 2012 13:56:35 -0000

Dear all,
> Hi Gonzalo and Benoit,
>
> Please correct me if I am wrong, but my impression is that Benoit's
> DISCUSS is related to the process of defining the  metrics in the
> different places in the IETF in a consistent manner and keeping them in
> one repository with a clear owner.
Exactly.
Regarding the consistency, we must do something now by updating the 
XRBLOCK drafts to use the RF C6390 template for performance metrics 
definition.
Regarding the single location for performance metrics, the idea would be 
to start with a WIKI. This work should be initiated by the PMOL directorate.

Regards, Benoit.
> Are there any text changes required
> in draft-ietf-xrblock-rtcp-xr-pdv?
>
> Thanks and Regards,
>
> Dan
>
>
>> -----Original Message-----
>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]
>> Sent: Tuesday, September 18, 2012 12:45 PM
>> To: Romascanu, Dan (Dan)
>> Cc: Qin Wu; Glen Zorn; xrblock@ietf.org
>> Subject: Re: [xrblock] FW: I-D Action: draft-ietf-xrblock-rtcp-xr-pdv-
>> 06.txt
>>
>> Hi Dan,
>>
>> yes, it is better to update the document. Just make sure you
> coordinate
>> the document update with the conversation with Benoit to clear his
>> discuss so that nobody gets confused when the new revision is posted.
>>
>> Cheers,
>>
>> Gonzalo
>>
>> On 18/09/2012 11:02 AM, Romascanu, Dan (Dan) wrote:
>>> Gonzalo,
>>>
>>> We can do one more update before the document is approved, in order
> to
>>> incorporate these changes. This would spare a lengthy note to the
> RFC
>>> editor.
>>>
>>> Dan
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Qin Wu [mailto:bill.wu@huawei.com]
>>>> Sent: Tuesday, September 18, 2012 5:10 AM
>>>> To: Glen Zorn; Romascanu, Dan (Dan)
>>>> Cc: xrblock@ietf.org
>>>> Subject: Re: [xrblock] FW: I-D Action:
>>>> draft-ietf-xrblock-rtcp-xr-pdv- 06.txt
>>>>
>>>> Hi, Glen:
>>>> Thank for your comments, please see my reply inline.
>>>>
>>>> Regards!
>>>> -Qin
>>>> ----- Original Message -----
>>>> From: "Glen Zorn" <glenzorn@gmail.com>
>>>> To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
>>>> Cc: <xrblock@ietf.org>
>>>> Sent: Monday, September 17, 2012 11:59 PM
>>>> Subject: Re: [xrblock] FW: I-D Action:
>>>> draft-ietf-xrblock-rtcp-xr-pdv- 06.txt
>>>>
>>>>
>>>>> On 09/16/2012 03:55 PM, Romascanu, Dan (Dan) wrote:
>>>>>> A revised version of raft-ietf-xrblock-rtcp-xr-pdv was issued in
>>>> order
>>>>>> to address the problems raised in DISCUSSes and COMMENTs during
> the
>>>> IESG
>>>>>> review.
>>>>>>
>>>>>> We believe that the changes are editorial and clarification in
>>>> nature,
>>>>>> they do not affect bits on the wire and improve the quality of
> the
>>>>>> document. However, more scrutiny from the other WG participants
>>> never
>>>>>> harms. Please read the revised version and let us know before
> 9/21
>>> if
>>>>>> you see any problems.
>>>>>>
>>>>>> Thanks and Regards,
>>>>>>
>>>>>> Dan
>>>>> The change to Section i.1 introduced a punctuation error: s/,,/,/
>>>> [Qin]: Good catch and will fix this. Thanks.
>>>>
>>>>> I find the change to Section 1.4 rather confusing:
>>>>>
>>>>>
>>>>>                  Application designers can know the range of delay
>>>>> variation they must
>>>>>                  accommodate, whether they are designing fixed or
>>>>> adaptive buffer
>>>>>                  systems.
>>>>> Are these app designers clairvoyant?  If not, how can they "know
> the
>>>>> range of delay variation they must accommodate, whether they are
>>>>> designing fixed or adaptive buffer systems" from measurements that
>>>> can't
>>>>> be made until the system is not only implemented but deployed (at
>>>> least
>>>>> in a test bed)?
>>>> [Qin]: Sorry to bring confusing here, what we want to convey is
> these
>>>> application designers need to know the range of delay variation
> they
>>>> must accomodate, and then based on the range of delay variation to
>>>> determine whether
>>> they
>>>> are designing
>>>> fixed or adaptive buffer systems.
>>>> You can get more details in the section 3.2 of RFC5481.
>>>> Do we really need to delete this first sentence you mentioned
> above?
>>>>> The next sentence doesn't make much sense, either, as written.  I
>>>>> suggest deleting the first and rewriting the second to
>>>> make
>>>>> more sense; for example: "For example, network managers can use
> this
>>>>> metric to compare actual delay variation to targets (i.e., a
>>> numerical
>>>>> objective or Service Level Agreement) to help ensure the quality
> of
>>>>> real-time application performance." Or something like that.
>>>> [Qin]: Your proposed change to the second setence looks good to me.
>>>>
>>>>> What does Section 2 mean?  How can one use an entire RFC as a
>>>>> "terminology statement"?  Does it actually mean "This document
> uses
>>>> ABNF
>>>>> notation [RFC5234] in Section 4."?
>>>> [Qin]: Yes, this statement doesn't intend to apply to the whold
>>>> document.
>>>> Thank for your proposed change.
>>>>
>>>>> If so, just say that; OTOH, since
>>>>> the ABNF usage is in the context of SDP & RFC 3611 both references
>>> the
>>>>> ABNF spec and is listed as a normative reference in this draft,
> why
>>>>> bother?
>>>> [Qin]: The reason is ABNF spec referenced by SDP document (i.e.,
>>>> RFC4566) and RFC3611
>>>> is outdated or obsoleted RFC4234, this RFC should be replaced by
>>>> RFC5234.
>>>>
>>>>> I suggest just deleting Section 2.
>>>> [Qin] How about move this statement to the first place in the
> section
>>> 4?
>>>>>> -----Original Message-----
>>>>>> From:xrblock-bounces@ietf.org  [mailto:xrblock-bounces@ietf.org]
> On
>>>>>> Behalf Ofinternet-drafts@ietf.org
>>>>>> Sent: Friday, September 14, 2012 12:26 PM
> To:i-d-announce@ietf.org
>>>>>> Cc:xrblock@ietf.org
>>>>>> Subject: [xrblock] I-D Action:
>>> draft-ietf-xrblock-rtcp-xr-pdv-06.txt
>>>>>>
>>>>>> A New Internet-Draft is available from the on-line
> Internet-Drafts
>>>>>> directories.
>>>>>>    This draft is a work item of the Metric Blocks for use with
>>> RTCP's
>>>>>> Extended Report Framework Working Group of the IETF.
>>>>>>
>>>>>> Title           : RTCP XR Report Block for Packet Delay
>>>>>> Variation Metric Reporting
>>>>>> Author(s)       : Alan Clark
>>>>>>                             Qin Wu
>>>>>> Filename        : draft-ietf-xrblock-rtcp-xr-pdv-06.txt
>>>>>> Pages           : 21
>>>>>> Date            : 2012-09-14
>>>>>>
>>>>>> Abstract:
>>>>>>      This document defines a Real-Time Control Protocol (RTCP)
>>>> Extended
>>>>>>      Report (XR) block that allows the reporting of Packet Delay
>>>> Variation
>>>>>>      metrics for a range of Real-time Transport Protocol (RTP)
>>>>>>      applications.
>>>>>>
>>>>>>
>>>>>> The IETF datatracker status page for this draft is:
>>>>>> https://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-pdv
>>>>>>
>>>>>> There's also a htmlized version available at:
>>>>>> http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-pdv-06
>>>>>>
>>>>>> A diff from the previous version is available at:
>>>>>>
> http://www.ietf.org/rfcdiff?url2=draft-ietf-xrblock-rtcp-xr-pdv-06
>>>>>>
>>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>>>
>>>>>> _______________________________________________
>>>>>> xrblock mailing list
>>>>>> xrblock@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/xrblock
>>>>>> _______________________________________________
>>>>>> xrblock mailing list
>>>>>> xrblock@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/xrblock
>>>>>
>>>>> _______________________________________________
>>>>> xrblock mailing list
>>>>> xrblock@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/xrblock
>
>