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

[Gonzalo Camarillo <[e-mail]>]

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