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

[Qin Wu <[e-mail]>]

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