Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-jb-02.txt

Colin Perkins <csp@csperkins.org> Thu, 13 December 2012 10:01 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C7521F8AC9 for <xrblock@ietfa.amsl.com>; Thu, 13 Dec 2012 02:01:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.901
X-Spam-Level:
X-Spam-Status: No, score=-105.901 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BDSjwDve4MG for <xrblock@ietfa.amsl.com>; Thu, 13 Dec 2012 02:01:28 -0800 (PST)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [93.93.130.6]) by ietfa.amsl.com (Postfix) with ESMTP id 68AFB21F8AC8 for <xrblock@ietf.org>; Thu, 13 Dec 2012 02:01:28 -0800 (PST)
Received: from [195.101.98.59] (helo=[192.168.0.158]) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <csp@csperkins.org>) id 1Tj5bb-0004Lv-1Z; Thu, 13 Dec 2012 10:01:27 +0000
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="iso-8859-1"
From: Colin Perkins <csp@csperkins.org>
X-Priority: 3
In-Reply-To: <76CB4CC914C74AD792B1BED68B7914EB@china.huawei.com>
Date: Thu, 13 Dec 2012 11:01:24 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <9146F423-344F-4E2B-88D7-30E0D4AD0ABA@csperkins.org>
References: <9904FB1B0159DA42B0B887B7FA8119CA024844@AZ-FFEXMB04.global.avaya.com><6DC0D5A8-E781-4584-BA7A-38EC6F9134AA@csperkins.org><F97E5A20FEA344ABAA0997D0421AD03A@china.huawei.com> <50C996AB.7070006@gmail.com> <76CB4CC914C74AD792B1BED68B7914EB@china.huawei.com>
To: Qin Wu <bill.wu@huawei.com>
X-Mailer: Apple Mail (2.1283)
X-BlackCat-Spam-Score: -4
X-Mythic-Debug: Threshold = On =
Cc: xrblock@ietf.org
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-jb-02.txt
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <xrblock.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xrblock>, <mailto:xrblock-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xrblock>
List-Post: <mailto:xrblock@ietf.org>
List-Help: <mailto:xrblock-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xrblock>, <mailto:xrblock-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Dec 2012 10:01:29 -0000

On 13 Dec 2012, at 10:45, Qin Wu wrote:
>>> Also, one question: there are many reserved values for the jb cfg. Do we need to define how new values are to be registered in an IANA Registry, or is the assumption that this draft is revised if new values are needed?
> 
>>> [Qin]:I am a little doubt about this. Do you have other values in mind besides the values for fixed jitter buffer method and adaptive jitter buffer method?
>>> Also these values looks to me are just configuration parameters. They usually fixed upon they are set.
>> 
>> If the meaning of values not defined in this draft is unknown what use are they?
> 
> [Qin]: I think the problem is we don't know how many new values we need to add. The current two values we defined in the draft are used to distinct measurement results that are using different jitter buffer method. If we don't have any new value to be defined, we don't need to resort to IANA Registry, if we do have many new values that need to be defined, I think IANA Registry is the right approach.


I disagree. If this is an expected extension point of the protocol, then you need an IANA registry. Otherwise, mark the bits as reserved, and let someone revise the RFC if they need to extend it.

-- 
Colin Perkins
http://csperkins.org/