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

[Qin Wu <[e-mail]>]

Hi,
----- Original Message ----- 
From: "Glen Zorn" <[e-mail]>
To: "Qin Wu" <[e-mail]>
Cc: "Glen Zorn" <[e-mail]>; "Romascanu, Dan (Dan)" <[e-mail]>; <[e-mail]>
Sent: Wednesday, September 19, 2012 4:16 PM
Subject: Re: [xrblock] FW: I-D Action: draft-ietf-xrblock-rtcp-xr-pdv-06.txt


> On 09/18/2012 09:10 AM, Qin Wu wrote:
> 
> ...
> 
>>> 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.
> 
> I'm not arguing w/RFC 5481, but the idea that app designers can use 
> measurements obtained after the app has already been implemented and 
> deployed confuses the heck out of me.  I suppose that they could use 
> studies of similar apps operating under similar conditions, but 
> describing that would require more than a cut-and-paste from 5481.
> 
>> Do we really need to delete this first sentence you mentioned above?
> 
> Deleting it would be the simplest option, but it could be changed to 
> make a little more temporal sense.  How about something like this: "For 
> example, applications could use these measurements to help adjust the 
> size of adaptive jitter buffers to improve performance."?

[Qin]: 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.
> 
> Yes, but it doesn't seem to me that the job of this draft is to fix the 
> references section in the SDP spec.  I guess the real question is 
> whether or not the syntax follows that used in RFC 4566.  If so, then it 
> should be fine; the fact that it's not the latest & greatest version of 
> ABNF is immaterial.

[Qin]: Agree. In ABNF spec, parenthese usage in RFC4234 doesn't change in RFC5234.

> ...