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

Colin Perkins <csp@csperkins.org> Wed, 12 December 2012 16:13 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 C430021F898C for <xrblock@ietfa.amsl.com>; Wed, 12 Dec 2012 08:13:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.182
X-Spam-Level:
X-Spam-Status: No, score=-106.182 tagged_above=-999 required=5 tests=[AWL=0.417, 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 3pcylAhmwjcz for <xrblock@ietfa.amsl.com>; Wed, 12 Dec 2012 08:13:03 -0800 (PST)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id EBC5421F8855 for <xrblock@ietf.org>; Wed, 12 Dec 2012 08:13:02 -0800 (PST)
Received: from [217.108.124.185] (helo=[10.5.0.186]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <csp@csperkins.org>) id 1Tiovb-0005sc-Bc; Wed, 12 Dec 2012 16:12:59 +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: <F97E5A20FEA344ABAA0997D0421AD03A@china.huawei.com>
Date: Wed, 12 Dec 2012 17:12:53 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <D5522192-0480-4460-B9EB-326B5DD51A80@csperkins.org>
References: <9904FB1B0159DA42B0B887B7FA8119CA024844@AZ-FFEXMB04.global.avaya.com> <6DC0D5A8-E781-4584-BA7A-38EC6F9134AA@csperkins.org> <F97E5A20FEA344ABAA0997D0421AD03A@china.huawei.com>
To: Qin Wu <bill.wu@huawei.com>
X-Mailer: Apple Mail (2.1283)
X-BlackCat-Spam-Score: -18
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: Wed, 12 Dec 2012 16:13:08 -0000

On 12 Dec 2012, at 08:51, Qin Wu wrote:
> Hi,
> ----- Original Message ----- 
> From: "Colin Perkins" <csp@csperkins.org>
> To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
> Cc: <xrblock@ietf.org>
> Sent: Wednesday, December 12, 2012 6:26 AM
> Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-jb-02.txt
> 
> 
>> On 29 Nov 2012, at 13:51, Romascanu, Dan (Dan) wrote:
>>> This is a Working Group Last Call for http://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-jb-02.txt.  
>>> 
>>> Please read and review this document, and send your comments, questions and concerns to the WG list before December 13, 2012. If you have no comments and you believe that the document is ready for submission to the IESG as a Standards Track document please send a short message as well to help us in determining the level of review and consensus. 
>> 
>> 
>> This looks to be in good shape. One minor comment: why is SHOULD used for the value to report if over-range or unknown values are received, rather than MUST?
> 
> [Qin]: I believe you are right, we should use MUST instead.
> 
>> 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?

I don't have any other values in mind, but I noted that this is a large, with few values assigned, so the question of how any future values are to be assigned naturally arises. 

> Also these values looks to me are just configuration parameters. They usually fixed upon they are set.

Sure.

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