[xrblock] Usage of RFC 6390 in XRBLOCK documents

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Mon, 03 December 2012 12:56 UTC

Return-Path: <dromasca@avaya.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 DC39621F86D8 for <xrblock@ietfa.amsl.com>; Mon, 3 Dec 2012 04:56:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.508
X-Spam-Level:
X-Spam-Status: No, score=-103.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 U1-s7fva9TXM for <xrblock@ietfa.amsl.com>; Mon, 3 Dec 2012 04:56:34 -0800 (PST)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD0221F86EF for <xrblock@ietf.org>; Mon, 3 Dec 2012 04:56:34 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4LAIbQt1DGmAcF/2dsb2JhbABEgmy9GRZsB4IgAQEDEig/EgEVFRRCJgEEDg0ah24BogadDJAgYQOcDoo3gnKCIQ
X-IronPort-AV: E=Sophos;i="4.84,186,1355115600"; d="scan'208";a="378785366"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 03 Dec 2012 07:48:01 -0500
Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 Dec 2012 07:54:19 -0500
Received: from AZ-FFEXHC02.global.avaya.com (135.64.58.12) by DC-US1HCEX2.global.avaya.com (135.11.52.21) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 3 Dec 2012 07:56:33 -0500
Received: from AZ-FFEXMB03.global.avaya.com ([fe80::d008:af0c:fa66:47e3]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.02.0318.004; Mon, 3 Dec 2012 07:56:32 -0500
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "xrblock@ietf.org" <xrblock@ietf.org>
Thread-Topic: Usage of RFC 6390 in XRBLOCK documents
Thread-Index: Ac3RVZ3sndR7nrgsR2+xFQARszaEYg==
Date: Mon, 03 Dec 2012 12:56:31 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA02DF35@AZ-FFEXMB03.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.64.58.45]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Benoit Claise <bclaise@cisco.com>
Subject: [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: Mon, 03 Dec 2012 12:56:35 -0000

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