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

Glen Zorn <> Wed, 19 September 2012 08:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AFCC621F860F for <>; Wed, 19 Sep 2012 01:16:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zLboE-6LCrwo for <>; Wed, 19 Sep 2012 01:16:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AA37821F8600 for <>; Wed, 19 Sep 2012 01:16:32 -0700 (PDT)
Received: by iabz21 with SMTP id z21so637601iab.31 for <>; Wed, 19 Sep 2012 01:16:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=zhCv/iafOgzfMl1A0aZ2AJBraxarDhoTTCOPGoOerl8=; b=HmmrNbAsA/zm/v0N0T0O0LvLZk9O1BwGhLOkbEu9R65JLe8I54r5LH0fbsWCR//cSv F34nglkENpGXZRzaS8bvipZKDOeO1hznLUqZLIB4Hz7K3+G+2YwgapA+Kk2x4s8JAy35 A31Qi/xMW3DM5eKgwhnRB+OC+uK+KTWUAnXf+VNbgRkqk9TohM3v9MPhHUaPJRGlVfF8 7L2Gbuc9ePosFxPMYaXxS8V3zcdtgzmJULnRS4Zf+x4CI/T2I+DILd83Lz+FZe73t6sQ S18J4kh9+lChRarWEhIieWHIpQ0kkSqimqng8mTrVXW45DtaFy/df/eFHkvOTRY7O67H UfSA==
Received: by with SMTP id vb7mr2180003igb.1.1348042592224; Wed, 19 Sep 2012 01:16:32 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id ng5sm12808406igc.0.2012. (version=SSLv3 cipher=OTHER); Wed, 19 Sep 2012 01:16:31 -0700 (PDT)
Message-ID: <>
Date: Wed, 19 Sep 2012 15:16:27 +0700
From: Glen Zorn <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120830 Thunderbird/15.0
MIME-Version: 1.0
To: Qin Wu <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [xrblock] FW: I-D Action: draft-ietf-xrblock-rtcp-xr-pdv-06.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Sep 2012 08:16:34 -0000

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.