Re: [xrblock] Usage of RFC 6390 in XRBLOCK documents

Qin Wu <bill.wu@huawei.com> Tue, 04 December 2012 10:22 UTC

Return-Path: <bill.wu@huawei.com>
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 1513F21F85D5 for <xrblock@ietfa.amsl.com>; Tue, 4 Dec 2012 02:22:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.803
X-Spam-Level:
X-Spam-Status: No, score=-4.803 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
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 5RA11Thp5xBs for <xrblock@ietfa.amsl.com>; Tue, 4 Dec 2012 02:21:59 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0AACE21F85C4 for <xrblock@ietf.org>; Tue, 4 Dec 2012 02:21:54 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMD89534; Tue, 04 Dec 2012 10:21:53 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 4 Dec 2012 10:21:24 +0000
Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 4 Dec 2012 10:21:50 +0000
Received: from w53375 (10.138.41.149) by szxeml419-hub.china.huawei.com (10.82.67.158) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 4 Dec 2012 18:21:40 +0800
Message-ID: <89453CF0D394472AB2BB4A81E5938F9A@china.huawei.com>
From: Qin Wu <bill.wu@huawei.com>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, xrblock@ietf.org
References: <9904FB1B0159DA42B0B887B7FA8119CA02DF35@AZ-FFEXMB03.global.avaya.com>
Date: Tue, 04 Dec 2012 18:21:39 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Originating-IP: [10.138.41.149]
X-CFilter-Loop: Reflected
Cc: Benoit Claise <bclaise@cisco.com>
Subject: Re: [xrblock] Usage of RFC 6390 in XRBLOCK documents
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: Tue, 04 Dec 2012 10:22:00 -0000

I have no problem to apply this policy to the XRBLOCK documents that reference to RFC6390 
and check the normative part of performance metric definition in RFC6390 is followed by 
the metrics block. 

I believe this is what we always bear this in mind from the beginning when this WG was 
formed, i.e., see whether the XRBLOCK draft is consistent/compliant with RFC6390 .

Another thing I just want to point out is, for some metrics included in the metrics block, 
especially most of the end system metrics, they are some metrics which can be directly 
measured and don't need us to design special measurement method. However for some
metrics that depend on those metrics which can be directly measured, they do need 
method of measurement or calculation.

Regards!
-Qin
----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: <xrblock@ietf.org>
Cc: "Benoit Claise" <bclaise@cisco.com>
Sent: Monday, December 03, 2012 8:56 PM
Subject: [xrblock] Usage of RFC 6390 in XRBLOCK documents


> Most if not all participants in the work of XRBLOCK are probably familiar with BCP 170 / RFC 6390 - ' Guidelines for Considering New Performance Metric Development'. This RFC describes a framework and a process for developing Performance Metrics of protocols and applications transported over IETF-specified protocols and makes a number of recommendations about the definition of new metrics. 
> 
> Specifically section 5.4.2 of the RFC defines the normative part of a Performance Metric definition, which MUST include the following: 
> 
> (i) Metric Name
> (ii) Metric Description 
> (iii) Method of Measurement or Calculation
> (iv) Units of Measurement
> (v) Measurement Point(s) with Potential Measurement Domain
> (vi) Measurement Timing
> 
> In XRBLOCK documents we are re-using definitions of metrics already defined somewhere else and normatively refer these documents. We do not intent to change this, but we would like to use the list above as a checklist that all mandatory information does exist in the definitions of the metrics that we refer. Authors can chose whether to use the exact format or terminology used by 6390 or not, provided that all necessary information is present. 
> 
> In documents that define new metrics (if there will be such document) it will be required to include all normative parts of the performance metric definition as specified in section 5.4.2 of RFC 6390. 
> 
> Please let us know if you see any problem with starting to apply this policy immediately. 
> 
> Thanks and Regards,
> 
> Dan
> 
> 
> 
> _______________________________________________
> xrblock mailing list
> xrblock@ietf.org
> https://www.ietf.org/mailman/listinfo/xrblock