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

[Glen Zorn <[e-mail]>]

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."?

...

>> 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.

...