IETF Logo Mail Archive

Re: [xrblock] WGLC fordraft-ietf-xrblock-rtcp-xr-burst-gap-discard-08.txt

Colin Perkins <csp@csperkins.org> Wed, 12 December 2012 16:11 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 422D121E809A for <xrblock@ietfa.amsl.com>; Wed, 12 Dec 2012 08:11:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.099
X-Spam-Level:
X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 P7VLa9mr6n2b for <xrblock@ietfa.amsl.com>; Wed, 12 Dec 2012 08:11:46 -0800 (PST)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.52]) by ietfa.amsl.com (Postfix) with ESMTP id 083CE21F889C for <xrblock@ietf.org>; Wed, 12 Dec 2012 08:11:46 -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 1Tiou6-0005Sb-SR; Wed, 12 Dec 2012 16:11:29 +0000
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="windows-1252"
From: Colin Perkins <csp@csperkins.org>
X-Priority: 3
In-Reply-To: <8FBC337CBD27418CA6E08DE44368A42F@china.huawei.com>
Date: Wed, 12 Dec 2012 17:11:23 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <AABB76E6-8ED0-432C-B57E-8C1CA1716AE2@csperkins.org>
References: <9904FB1B0159DA42B0B887B7FA8119CA0329F3@AZ-FFEXMB03.global.avaya.com> <4509053F-861C-40C2-AE6E-A39071B018B5@csperkins.org> <8FBC337CBD27418CA6E08DE44368A42F@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 fordraft-ietf-xrblock-rtcp-xr-burst-gap-discard-08.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:11:48 -0000

On 12 Dec 2012, at 09:12, 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:09 AM
> Subject: Re: [xrblock] WGLC fordraft-ietf-xrblock-rtcp-xr-burst-gap-discard-08.txt
> 
> On 6 Dec 2012, at 13:14, Romascanu, Dan (Dan) wrote:
>> This is a (second) Working Group Last Call for http://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-burst-gap-discard-08.txt.  
>> 
>> Please read and review this document, and send your comments, questions and concerns to the WG list before December 20, 2012. If you read the document, 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. Some minor points I noticed:
> 
> - The last paragraph of the definition of the Interval Metric Flag in Section 3.2 might be clearer written “Burst/Gap Discard Metrics can only be measured over definite intervals, and cannot be sampled. Accordingly, the value I=01, indicating a sampled value, MUST NOT be used.”
> 
> [Qin]: Good proposed change, thanks.
> 
> - For Packets discarded in bursts and Total packets expected in bursts, why are the values 0xFFFFFE and 0xFFFFFF listed as SHOULD? If there is a case where the condition is satisfied by the listed value isn’t reported, then this needs to be documented; otherwise the draft ought to say MUST instead.
> 
> [Qin]: Accepted, we will use MUST.
> 
> - Section 3.3 reads as-if some new metrics are going to be defined, but all it actually does is reference another draft. I wonder if those summary metrics shouldn’t be defined in this draft, and if the split of related metrics into a separate draft is worthwhile in this case?
> 
> [Qin]: Okay, it looks no harm to remove section 3.3.


My question was actually whether it would make sense to split the summary metrics draft, and move some of that content into Section 3.3 of this draft.

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

v2.23.0 | Report a Bug | By Email