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

[Gonzalo Camarillo <[e-mail]>]

Hi Benoit,

the authors introduced the following information in the draft, which was
missing before, per our request:

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-xrblock-rtcp-xr-pdv-06.txt

Could you please let the authors know whether or not that addresses your
discuss and, in case it doesn't, what needs to be done?

Thanks,

Gonzalo

On 20/09/2012 4:56 PM, Benoit Claise wrote:
> 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:[e-mail]]
>>> Sent: Tuesday, September 18, 2012 12:45 PM
>>> To: Romascanu, Dan (Dan)
>>> Cc: Qin Wu; Glen Zorn; [e-mail]
>>> 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:[e-mail]]
>>>>> Sent: Tuesday, September 18, 2012 5:10 AM
>>>>> To: Glen Zorn; Romascanu, Dan (Dan)
>>>>> Cc: [e-mail]
>>>>> 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" <[e-mail]>
>>>>> To: "Romascanu, Dan (Dan)" <[e-mail]>
>>>>> Cc: <[e-mail]>
>>>>> 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:[e-mail]  [mailto:[e-mail]]
>> On
>>>>>>> Behalf [e-mail]
>>>>>>> Sent: Friday, September 14, 2012 12:26 PM
>> To:[e-mail]
>>>>>>> Cc:[e-mail]
>>>>>>> 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
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/xrblock
>>>>>>> _______________________________________________
>>>>>>> xrblock mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/xrblock
>>>>>>
>>>>>> _______________________________________________
>>>>>> xrblock mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/xrblock
>>
>>
>