< draft-ietf-ippm-metric-registry-20.txt   draft-ietf-ippm-metric-registry-21.txt >
Network Working Group M. Bagnulo Network Working Group M. Bagnulo
Internet-Draft UC3M Internet-Draft UC3M
Intended status: Best Current Practice B. Claise Intended status: Best Current Practice B. Claise
Expires: March 14, 2020 Cisco Systems, Inc. Expires: May 24, 2020 Cisco Systems, Inc.
P. Eardley P. Eardley
BT BT
A. Morton A. Morton
AT&T Labs AT&T Labs
A. Akhter A. Akhter
Consultant Consultant
September 11, 2019 November 21, 2019
Registry for Performance Metrics Registry for Performance Metrics
draft-ietf-ippm-metric-registry-20 draft-ietf-ippm-metric-registry-21
Abstract Abstract
This document defines the format for the IANA Performance Metrics This document defines the format for the IANA Performance Metrics
Registry. This document also gives a set of guidelines for Registry. This document also gives a set of guidelines for
Registered Performance Metric requesters and reviewers. Registered Performance Metric requesters and reviewers.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 14, 2020. This Internet-Draft will expire on May 24, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Motivation for a Performance Metrics Registry . . . . . . . . 7 4. Motivation for a Performance Metrics Registry . . . . . . . . 8
4.1. Interoperability . . . . . . . . . . . . . . . . . . . . 7 4.1. Interoperability . . . . . . . . . . . . . . . . . . . . 8
4.2. Single point of reference for Performance Metrics . . . . 8 4.2. Single point of reference for Performance Metrics . . . . 9
4.3. Side benefits . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Side benefits . . . . . . . . . . . . . . . . . . . . . . 9
5. Criteria for Performance Metrics Registration . . . . . . . . 9 5. Criteria for Performance Metrics Registration . . . . . . . . 9
6. Performance Metric Registry: Prior attempt . . . . . . . . . 9 6. Performance Metric Registry: Prior attempt . . . . . . . . . 10
6.1. Why this Attempt Will Succeed . . . . . . . . . . . . . . 10 6.1. Why this Attempt Will Succeed . . . . . . . . . . . . . . 11
7. Definition of the Performance Metric Registry . . . . . . . . 11 7. Definition of the Performance Metric Registry . . . . . . . . 11
7.1. Summary Category . . . . . . . . . . . . . . . . . . . . 12 7.1. Summary Category . . . . . . . . . . . . . . . . . . . . 13
7.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 12 7.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 13
7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 17 7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 17
7.1.5. Reference . . . . . . . . . . . . . . . . . . . . . . 17 7.1.5. Reference . . . . . . . . . . . . . . . . . . . . . . 17
7.1.6. Change Controller . . . . . . . . . . . . . . . . . . 17 7.1.6. Change Controller . . . . . . . . . . . . . . . . . . 17
7.1.7. Version (of Registry Format) . . . . . . . . . . . . 17 7.1.7. Version (of Registry Format) . . . . . . . . . . . . 17
7.2. Metric Definition Category . . . . . . . . . . . . . . . 17 7.2. Metric Definition Category . . . . . . . . . . . . . . . 18
7.2.1. Reference Definition . . . . . . . . . . . . . . . . 17 7.2.1. Reference Definition . . . . . . . . . . . . . . . . 18
7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 18 7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 18
7.3. Method of Measurement Category . . . . . . . . . . . . . 18 7.3. Method of Measurement Category . . . . . . . . . . . . . 19
7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 18 7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 19
7.3.2. Packet Stream Generation . . . . . . . . . . . . . . 19 7.3.2. Packet Stream Generation . . . . . . . . . . . . . . 19
7.3.3. Traffic Filter . . . . . . . . . . . . . . . . . . . 19 7.3.3. Traffic Filter . . . . . . . . . . . . . . . . . . . 20
7.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 20 7.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 20
7.3.5. Run-time Parameters . . . . . . . . . . . . . . . . . 20 7.3.5. Run-time Parameters . . . . . . . . . . . . . . . . . 21
7.3.6. Role . . . . . . . . . . . . . . . . . . . . . . . . 21 7.3.6. Role . . . . . . . . . . . . . . . . . . . . . . . . 21
7.4. Output Category . . . . . . . . . . . . . . . . . . . . . 21 7.4. Output Category . . . . . . . . . . . . . . . . . . . . . 22
7.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 22 7.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 22
7.4.2. Reference Definition . . . . . . . . . . . . . . . . 22 7.4.2. Reference Definition . . . . . . . . . . . . . . . . 22
7.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 22 7.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 22
7.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 22 7.4.4. Calibration . . . . . . . . . . . . . . . . . . . . . 23
7.5. Administrative information . . . . . . . . . . . . . . . 23 7.5. Administrative information . . . . . . . . . . . . . . . 23
7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 23 7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 23
7.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 23 7.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 23
7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 23 7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 24
7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 23 7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 24
7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 23 7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 24
8. The Life-Cycle of Registered Performance Metrics . . . . . . 24 8. The Life-Cycle of Registered Performance Metrics . . . . . . 24
8.1. Adding new Performance Metrics to the Performance Metrics 8.1. Adding new Performance Metrics to the Performance Metrics
Registry . . . . . . . . . . . . . . . . . . . . . . . . 24 Registry . . . . . . . . . . . . . . . . . . . . . . . . 24
8.2. Revising Registered Performance Metrics . . . . . . . . . 25 8.2. Revising Registered Performance Metrics . . . . . . . . . 25
8.3. Deprecating Registered Performance Metrics . . . . . . . 27 8.3. Deprecating Registered Performance Metrics . . . . . . . 27
9. Security considerations . . . . . . . . . . . . . . . . . . . 27 9. Security considerations . . . . . . . . . . . . . . . . . . . 28
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
10.1. Registry Group . . . . . . . . . . . . . . . . . . . . . 28 10.1. Registry Group . . . . . . . . . . . . . . . . . . . . . 28
10.2. Performance Metric Name Elements . . . . . . . . . . . . 28 10.2. Performance Metric Name Elements . . . . . . . . . . . . 28
10.3. New Performance Metrics Registry . . . . . . . . . . . . 29 10.3. New Performance Metrics Registry . . . . . . . . . . . . 29
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 11. Blank Registry Template . . . . . . . . . . . . . . . . . . . 31
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 11.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . 31
12.1. Normative References . . . . . . . . . . . . . . . . . . 30 11.1.1. ID (Identifier) . . . . . . . . . . . . . . . . . . 31
12.2. Informative References . . . . . . . . . . . . . . . . . 31 11.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 11.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 31
11.1.4. Description . . . . . . . . . . . . . . . . . . . . 31
11.1.5. Change Controller . . . . . . . . . . . . . . . . . 31
11.1.6. Version (of Registry Format) . . . . . . . . . . . . 31
11.2. Metric Definition . . . . . . . . . . . . . . . . . . . 31
11.2.1. Reference Definition . . . . . . . . . . . . . . . . 31
11.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 32
11.3. Method of Measurement . . . . . . . . . . . . . . . . . 32
11.3.1. Reference Method . . . . . . . . . . . . . . . . . . 32
11.3.2. Packet Stream Generation . . . . . . . . . . . . . . 32
11.3.3. Traffic Filtering (observation) Details . . . . . . 32
11.3.4. Sampling Distribution . . . . . . . . . . . . . . . 32
11.3.5. Run-time Parameters and Data Format . . . . . . . . 32
11.3.6. Roles . . . . . . . . . . . . . . . . . . . . . . . 32
11.4. Output . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 33
11.4.2. Reference Definition . . . . . . . . . . . . . . . . 33
11.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 33
11.4.4. Calibration . . . . . . . . . . . . . . . . . . . . 33
11.5. Administrative items . . . . . . . . . . . . . . . . . . 33
11.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 33
11.5.2. Requestor . . . . . . . . . . . . . . . . . . . . . 33
11.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 33
11.5.4. Revision Date . . . . . . . . . . . . . . . . . . . 33
11.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 33
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
13.1. Normative References . . . . . . . . . . . . . . . . . . 34
13.2. Informative References . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction 1. Introduction
The IETF specifies and uses Performance Metrics of protocols and The IETF specifies and uses Performance Metrics of protocols and
applications transported over its protocols. Performance metrics are applications transported over its protocols. Performance metrics are
such an important part of the operations of IETF protocols that such an important part of the operations of IETF protocols that
[RFC6390] specifies guidelines for their development. [RFC6390] specifies guidelines for their development.
The definition and use of Performance Metrics in the IETF happens in The definition and use of Performance Metrics in the IETF happens in
various working groups (WG), most notably: various working groups (WG), most notably:
skipping to change at page 9, line 19 skipping to change at page 9, line 51
IPPM metrics, and the same process will likely suffice to determine IPPM metrics, and the same process will likely suffice to determine
whether Registered Performance Metrics are sufficiently well whether Registered Performance Metrics are sufficiently well
specified to result in comparable (or equivalent) results. specified to result in comparable (or equivalent) results.
Registered Performance Metrics which have undergone such testing Registered Performance Metrics which have undergone such testing
SHOULD be noted, with a reference to the test results. SHOULD be noted, with a reference to the test results.
5. Criteria for Performance Metrics Registration 5. Criteria for Performance Metrics Registration
It is neither possible nor desirable to populate the Performance It is neither possible nor desirable to populate the Performance
Metrics Registry with all combinations of Parameters of all Metrics Registry with all combinations of Parameters of all
Performance Metrics. The Registered Performance Metrics should be: Performance Metrics. The Registered Performance Metrics SHOULD be:
1. interpretable by the user. 1. interpretable by the user.
2. implementable by the software designer, 2. implementable by the software designer,
3. deployable by network operators, 3. deployable by network operators,
4. accurate, for interoperability and deployment across vendors, 4. accurate, for interoperability and deployment across vendors,
5. Operationally useful, so that it has significant industry 5. Operationally useful, so that it has significant industry
skipping to change at page 9, line 50 skipping to change at page 10, line 34
6. Performance Metric Registry: Prior attempt 6. Performance Metric Registry: Prior attempt
There was a previous attempt to define a metric registry RFC 4148 There was a previous attempt to define a metric registry RFC 4148
[RFC4148]. However, it was obsoleted by RFC 6248 [RFC6248] because [RFC4148]. However, it was obsoleted by RFC 6248 [RFC6248] because
it was "found to be insufficiently detailed to uniquely identify IPPM it was "found to be insufficiently detailed to uniquely identify IPPM
metrics... [there was too much] variability possible when metrics... [there was too much] variability possible when
characterizing a metric exactly" which led to the RFC4148 registry characterizing a metric exactly" which led to the RFC4148 registry
having "very few users, if any". having "very few users, if any".
A couple of interesting additional quotes from RFC 6248 might help A couple of interesting additional quotes from RFC 6248 [RFC6248]
understand the issues related to that registry. might help to understand the issues related to that registry.
1. "It is not believed to be feasible or even useful to register 1. "It is not believed to be feasible or even useful to register
every possible combination of Type P, metric parameters, and every possible combination of Type P, metric parameters, and
Stream parameters using the current structure of the IPPM Metrics Stream parameters using the current structure of the IPPM Metrics
Registry." Registry."
2. "The registry structure has been found to be insufficiently 2. "The registry structure has been found to be insufficiently
detailed to uniquely identify IPPM metrics." detailed to uniquely identify IPPM metrics."
3. "Despite apparent efforts to find current or even future users, 3. "Despite apparent efforts to find current or even future users,
skipping to change at page 10, line 35 skipping to change at page 11, line 18
of entries in the Performance Metrics Registry. There is agreement of entries in the Performance Metrics Registry. There is agreement
that less is more in this context - it is better to have a reduced that less is more in this context - it is better to have a reduced
set of useful metrics rather than a large set of metrics, some with set of useful metrics rather than a large set of metrics, some with
with questionable usefulness. with questionable usefulness.
6.1. Why this Attempt Will Succeed 6.1. Why this Attempt Will Succeed
As mentioned in the previous section, one of the main issues with the As mentioned in the previous section, one of the main issues with the
previous registry was that the metrics contained in the registry were previous registry was that the metrics contained in the registry were
too generic to be useful. This document specifies stricter criteria too generic to be useful. This document specifies stricter criteria
for performance metric registration (see section 6), and imposes a for performance metric registration (see section 5), and imposes a
group of Performance Metrics Experts that will provide guidelines to group of Performance Metrics Experts that will provide guidelines to
assess if a Performance Metric is properly specified. assess if a Performance Metric is properly specified.
Another key difference between this attempt and the previous one is Another key difference between this attempt and the previous one is
that in this case there is at least one clear user for the that in this case there is at least one clear user for the
Performance Metrics Registry: the LMAP framework and protocol. Performance Metrics Registry: the LMAP framework and protocol.
Because the LMAP protocol will use the Performance Metrics Registry Because the LMAP protocol will use the Performance Metrics Registry
values in its operation, this actually helps to determine if a metric values in its operation, this actually helps to determine if a metric
is properly defined. In particular, since we expect that the LMAP is properly defined.
control protocol will enable a controller to request a measurement
agent to perform a measurement using a given metric by embedding the In particular, since we expect that the LMAP control protocol will
Performance Metrics Registry value in the protocol, a metric is enable a controller to request a measurement agent to perform a
properly specified if it is defined well-enough so that it is measurement using a given metric by embedding the Performance Metrics
possible (and practical) to implement the metric in the measurement Registry identifier in the protocol. Such a metric and method are
agent. This was the failure of the previous attempt: a registry properly specified if they are defined well-enough so that it is
entry with an undefined Type-P (section 13 of RFC 2330 [RFC2330]) possible (and practical) to implement them in the measurement agent.
allows implementation to be ambiguous. This was the failure of the previous attempt: a registry entry with
an undefined Type-P (section 13 of RFC 2330 [RFC2330]) allows
implementation to be ambiguous.
7. Definition of the Performance Metric Registry 7. Definition of the Performance Metric Registry
This Performance Metrics Registry is applicable to Performance This Performance Metrics Registry is applicable to Performance
Metrics used for Active Measurement, Passive Measurement, and any Metrics used for Active Measurement, Passive Measurement, and any
other form of Performance Metric. Each category of measurement has other form of Performance Metric. Each category of measurement has
unique properties, so some of the columns defined below are not unique properties, so some of the columns defined below are not
applicable for a given metric category. In this case, the column(s) applicable for a given metric category. In this case, the column(s)
SHOULD be populated with the "NA" value (Non Applicable). However, SHOULD be populated with the "NA" value (Non Applicable). However,
the "NA" value MUST NOT be used by any metric in the following the "NA" value MUST NOT be used by any metric in the following
skipping to change at page 12, line 30 skipping to change at page 12, line 42
--------------------------------------------------------------------- ---------------------------------------------------------------------
Reference | Packet | Traffic | Sampling | Run-time | Role | Reference | Packet | Traffic | Sampling | Run-time | Role |
Method | Stream | Filter | Distribution | Parameters | | Method | Stream | Filter | Distribution | Parameters | |
| Generation | | Generation |
Output Output
----------------------------------------- -----------------------------------------
Type | Reference | Units | Calibration | Type | Reference | Units | Calibration |
| Definition | | | | Definition | | |
Administrative Information Administrative Information
Status |Request | Rev | Rev.Date | ------------------------------------
Status |Requester | Rev | Rev.Date |
Comments and Remarks Comments and Remarks
-------------------- --------------------
7.1. Summary Category 7.1. Summary Category
7.1.1. Identifier 7.1.1. Identifier
A numeric identifier for the Registered Performance Metric. This A numeric identifier for the Registered Performance Metric. This
identifier MUST be unique within the Performance Metrics Registry. identifier MUST be unique within the Performance Metrics Registry.
The Registered Performance Metric unique identifier is an unbounded The Registered Performance Metric unique identifier is an unbounded
integer (range 0 to infinity). integer (range 0 to infinity).
The Identifier 0 should be Reserved. The Identifier values from The Identifier 0 should be Reserved. The Identifier values from
64512 to 65536 are reserved for private use. 64512 to 65536 are reserved for private or experimental use, and the
user may encounter overlapping uses.
When adding newly Registered Performance Metrics to the Performance When adding newly Registered Performance Metrics to the Performance
Metrics Registry, IANA SHOULD assign the lowest available identifier Metrics Registry, IANA SHOULD assign the lowest available identifier
to the new Registered Performance Metric. to the new Registered Performance Metric.
If a Performance Metrics Expert providing review determines that If a Performance Metrics Expert providing review determines that
there is a reason to assign a specific numeric identifier, possibly there is a reason to assign a specific numeric identifier, possibly
leaving a temporary gap in the numbering, then the Performance Expert leaving a temporary gap in the numbering, then the Performance Expert
SHALL inform IANA of this decision. SHALL inform IANA of this decision.
skipping to change at page 15, line 16 skipping to change at page 15, line 33
which indicates that they belong to this element, and that their which indicates that they belong to this element, and that their
order is unimportant when considering name uniqueness. order is unimportant when considering name uniqueness.
o Spec: RFC number and major section number that specifies this o Spec: RFC number and major section number that specifies this
Registry entry in the form RFCXXXXsecY, such as RFC7799sec3. Registry entry in the form RFCXXXXsecY, such as RFC7799sec3.
Note: the RFC number is not the Primary Reference specification Note: the RFC number is not the Primary Reference specification
for the metric definition, such as [RFC7679] for One-way Delay; it for the metric definition, such as [RFC7679] for One-way Delay; it
will contain the placeholder "RFCXXXXsecY" until the RFC number is will contain the placeholder "RFCXXXXsecY" until the RFC number is
assigned to the specifying document, and would remain blank in assigned to the specifying document, and would remain blank in
private registry entries without a corresponding RFC. private registry entries without a corresponding RFC.
Anticipating the "RFC10K" problem, the number of the RFC continues
to replace RFCXXXX regardless of the number of digits in the RFC
number. Anticipating Registry Entries from other standards
bodies, the form of this Name Element MUST be proposed and
reviewed for consistency and uniqueness by the Expert Reviewer.
o Units: The units of measurement for the output, such as: o Units: The units of measurement for the output, such as:
Seconds Seconds
Ratio (unitless) Ratio (unitless)
Percent (value multiplied by 100) Percent (value multiplied by 100)
Logical (1 or 0) Logical (1 or 0)
skipping to change at page 18, line 37 skipping to change at page 19, line 8
Parameters MUST have a well-specified data format. Parameters MUST have a well-specified data format.
A Parameter which is a Fixed Parameter for one Performance Metrics A Parameter which is a Fixed Parameter for one Performance Metrics
Registry entry may be designated as a Run-time Parameter for another Registry entry may be designated as a Run-time Parameter for another
Performance Metrics Registry entry. Performance Metrics Registry entry.
7.3. Method of Measurement Category 7.3. Method of Measurement Category
This category includes columns for references to relevant sections of This category includes columns for references to relevant sections of
the RFC(s) and any supplemental information needed to ensure an the immutable document(s) and any supplemental information needed to
unambiguous method for implementations. ensure an unambiguous method for implementations.
7.3.1. Reference Method 7.3.1. Reference Method
This entry provides references to relevant sections of the RFC(s) This entry provides references to relevant sections of immutable
describing the method of measurement, as well as any supplemental documents, such as RFC(s) (for other standards bodies, it is likely
information needed to ensure unambiguous interpretation for to be necessary to reference a specific, dated version of a
implementations referring to the RFC text. specification) describing the method of measurement, as well as any
supplemental information needed to ensure unambiguous interpretation
for implementations referring to the RFC text.
Specifically, this section should include pointers to pseudocode or Specifically, this section should include pointers to pseudocode or
actual code that could be used for an unambigious implementation. actual code that could be used for an unambigious implementation.
7.3.2. Packet Stream Generation 7.3.2. Packet Stream Generation
This column applies to Performance Metrics that generate traffic as This column applies to Performance Metrics that generate traffic as
part of their Measurement Method, including but not necessarily part of their Measurement Method, including but not necessarily
limited to Active metrics. The generated traffic is referred as a limited to Active metrics. The generated traffic is referred as a
stream and this column describes its characteristics. stream and this column describes its characteristics.
skipping to change at page 23, line 42 skipping to change at page 24, line 14
7.5.3. Revision 7.5.3. Revision
The revision number of a Registered Performance Metric, starting at 0 The revision number of a Registered Performance Metric, starting at 0
for Registered Performance Metrics at time of definition and for Registered Performance Metrics at time of definition and
incremented by one for each revision. incremented by one for each revision.
7.5.4. Revision Date 7.5.4. Revision Date
The date of acceptance or the most recent revision for the Registered The date of acceptance or the most recent revision for the Registered
Performance Metric. The date SHALL be determined by the reviewing Performance Metric. The date SHALL be determined by IANA and the
Performance Metrics Expert in the case of Expert Review, or by IANA reviewing Performance Metrics Expert.
in the case of Standards Action.
7.6. Comments and Remarks 7.6. Comments and Remarks
Besides providing additional details which do not appear in other Besides providing additional details which do not appear in other
categories, this open Category (single column) allows for unforeseen categories, this open Category (single column) allows for unforeseen
issues to be addressed by simply updating this informational entry. issues to be addressed by simply updating this informational entry.
8. The Life-Cycle of Registered Performance Metrics 8. The Life-Cycle of Registered Performance Metrics
Once a Performance Metric or set of Performance Metrics has been Once a Performance Metric or set of Performance Metrics has been
skipping to change at page 24, line 37 skipping to change at page 25, line 7
things as compliance with this document, compliance with other things as compliance with this document, compliance with other
applicable Performance Metric-related RFCs, and consistency with the applicable Performance Metric-related RFCs, and consistency with the
currently defined set of Registered Performance Metrics. currently defined set of Registered Performance Metrics.
Submission to IANA MAY be during IESG review (leading to IETF Submission to IANA MAY be during IESG review (leading to IETF
Standards Action), where an Internet Draft proposes one or more Standards Action), where an Internet Draft proposes one or more
Registered Performance Metrics to be added to the Performance Metrics Registered Performance Metrics to be added to the Performance Metrics
Registry, including the text of the proposed Registered Performance Registry, including the text of the proposed Registered Performance
Metric(s). Metric(s).
If the proposed registry entry is defined in an RFC but is not yet
widely deployed, there SHOULD be a statement in the RFC that says the
proposed registry entry is not ready for registration, and use SHOULD
employ a private/experimental ID. It is the responsibility of the
document authors to submit the request to IANA when the proposed
registry entry is ready for official registration.
Authors of proposed Registered Performance Metrics SHOULD review Authors of proposed Registered Performance Metrics SHOULD review
compliance with the specifications in this document to check their compliance with the specifications in this document to check their
submissions before sending them to IANA. submissions before sending them to IANA.
At least one Performance Metric Expert should endeavor to complete At least one Performance Metric Expert should endeavor to complete
referred reviews in a timely manner. If the request is acceptable, referred reviews in a timely manner. If the request is acceptable,
the Performance Metric Experts signify their approval to IANA, and the Performance Metric Experts signify their approval to IANA, and
IANA updates the Performance Metrics Registry. If the request is not IANA updates the Performance Metrics Registry. If the request is not
acceptable, the Performance Metric Experts MAY coordinate with the acceptable, the Performance Metric Experts MAY coordinate with the
requester to change the request to be compliant, otherwise IANA SHALL requester to change the request to be compliant, otherwise IANA SHALL
skipping to change at page 26, line 29 skipping to change at page 27, line 4
corrected. corrected.
If a Performance Metric revision is deemed permissible and backward- If a Performance Metric revision is deemed permissible and backward-
compatible by the Performance Metric Experts, according to the rules compatible by the Performance Metric Experts, according to the rules
in this document, IANA SHOULD execute the change(s) in the in this document, IANA SHOULD execute the change(s) in the
Performance Metrics Registry. The requester of the change is Performance Metrics Registry. The requester of the change is
appended to the original requester in the Performance Metrics appended to the original requester in the Performance Metrics
Registry. The Name of the revised Registered Performance Metric, Registry. The Name of the revised Registered Performance Metric,
including the RFCXXXXsecY portion of the name, SHALL remain unchamged including the RFCXXXXsecY portion of the name, SHALL remain unchamged
(even when the change is the result of IETF Standards Action; the (even when the change is the result of IETF Standards Action; the
revised registry entry SHOULD reference the new RFC in an appropriate revised registry entry SHOULD reference the new immutable document,
category and column). such as an RFC or for other standards bodies, it is likely to be
necessary to reference a specific, dated version of a specification,
in an appropriate category and column).
Each Registered Performance Metric in the Performance Metrics Each Registered Performance Metric in the Performance Metrics
Registry has a revision number, starting at zero. Each change to a Registry has a revision number, starting at zero. Each change to a
Registered Performance Metric following this process increments the Registered Performance Metric following this process increments the
revision number by one. revision number by one.
When a revised Registered Performance Metric is accepted into the When a revised Registered Performance Metric is accepted into the
Performance Metrics Registry, the date of acceptance of the most Performance Metrics Registry, the date of acceptance of the most
recent revision is placed into the revision Date column of the recent revision is placed into the revision Date column of the
registry for that Registered Performance Metric. registry for that Registered Performance Metric.
skipping to change at page 28, line 8 skipping to change at page 28, line 28
introduce any new security considerations for the Internet. The introduce any new security considerations for the Internet. The
definition of Performance Metrics for this registry may introduce definition of Performance Metrics for this registry may introduce
some security concerns, but the mandatory references should have some security concerns, but the mandatory references should have
their own considerations for secuity, and such definitions should be their own considerations for secuity, and such definitions should be
reviewed with security in mind if the security considerations are not reviewed with security in mind if the security considerations are not
covered by one or more reference standards. covered by one or more reference standards.
10. IANA Considerations 10. IANA Considerations
With the background and processes described in earlier sections, this With the background and processes described in earlier sections, this
document requests the following IANA Actions. Note that mock-ups of document requests the following IANA Actions.
the implementation of this set of requests have been prepared with
IANA's help during development of this memo, and have been captured Editor's Note: Mock-ups of the implementation of this set of requests
in the Proceedings of IPPM working group sessions. have been prepared with IANA's help during development of this memo,
and have been captured in the Proceedings of IPPM working group
sessions. IANA is currently preparing a mock-up. A recent version
is available here: http://encrypted.net/IETFMetricsRegistry-106.html
10.1. Registry Group 10.1. Registry Group
The new registry group SHALL be named, "PERFORMANCE METRICS Group". The new registry group SHALL be named, "PERFORMANCE METRICS Group".
Registration Procedure: Specification Required
Reference: <This RFC>
Experts: Performance Metrics Experts
Note: TBD
10.2. Performance Metric Name Elements 10.2. Performance Metric Name Elements
This document specifies the procedure for Performance Metrics Name This document specifies the procedure for Performance Metrics Name
Element Registry setup. IANA is requested to create a new set of Element Registry setup. IANA is requested to create a new set of
registries for Performance Metric Name Elements called "Registered registries for Performance Metric Name Elements called "Registered
Performance Metric Name Elements". Each Registry, whose names are Performance Metric Name Elements". Each Registry, whose names are
listed below: listed below:
MetricType: MetricType:
skipping to change at page 28, line 51 skipping to change at page 29, line 33
creation, the IANA is asked to use the lists of values for each name creation, the IANA is asked to use the lists of values for each name
element listed in Section 7.1.2. The Name Elements in each registry element listed in Section 7.1.2. The Name Elements in each registry
are case-sensitive. are case-sensitive.
When preparing a Metric entry for Registration, the developer SHOULD When preparing a Metric entry for Registration, the developer SHOULD
choose Name elements from among the registered elements. However, if choose Name elements from among the registered elements. However, if
the proposed metric is unique in a significant way, it may be the proposed metric is unique in a significant way, it may be
necessary to propose a new Name element to properly describe the necessary to propose a new Name element to properly describe the
metric, as described below. metric, as described below.
A candidate Metric Entry RFC or document for Expert Review would A candidate Metric Entry RFC or immutable document for IANA and
propose one or more new element values required to describe the Expert Review would propose one or more new element values required
unique entry, and the new name element(s) would be reviewed along to describe the unique entry, and the new name element(s) would be
with the metric entry. New assignments for Registered Performance reviewed along with the metric entry. New assignments for Registered
Metric Name Elements will be administered by IANA through Expert Performance Metric Name Elements will be administered by IANA through
Review [RFC8126], i.e., review by one of a group of experts, the Expert Review [RFC8126], i.e., review by one of a group of experts,
Performance Metric Experts, who are appointed by the IESG upon the Performance Metric Experts, who are appointed by the IESG upon
recommendation of the Transport Area Directors. recommendation of the Transport Area Directors.
10.3. New Performance Metrics Registry 10.3. New Performance Metrics Registry
This document specifies the procedure for Performance Metrics This document specifies the procedure for Performance Metrics
Registry setup. IANA is requested to create a new registry for Registry setup. IANA is requested to create a new registry for
Performance Metrics called "Performance Metrics Registry". This Performance Metrics called "Performance Metrics Registry". This
Registry will contain the following Summary columns: Registry will contain the following Summary columns:
Identifier: Identifier:
skipping to change at page 29, line 47 skipping to change at page 30, line 30
64512 to 65536 are reserved for private use. 64512 to 65536 are reserved for private use.
Names starting with the prefix Priv_ are reserved for private use, Names starting with the prefix Priv_ are reserved for private use,
and are not considered for registration. The "Name" column entries and are not considered for registration. The "Name" column entries
are further defined in section Section 7. are further defined in section Section 7.
The "URIs" column will have a URL to the full template of each The "URIs" column will have a URL to the full template of each
registry entry. The Registry Entry text SHALL be HTML-ized to aid registry entry. The Registry Entry text SHALL be HTML-ized to aid
the reader, with links to reference RFCs (similar to the way that the reader, with links to reference RFCs (similar to the way that
Internet Drafts are HTML-ized, the same tool can perform the Internet Drafts are HTML-ized, the same tool can perform the
function). function) or immutable document.
The "Reference" column will include an RFC number, an approved The "Reference" column will include an RFC number, an approved
specification designator from another standards body, or the contact specification designator from another standards body, other immutable
person. document, or the contact person @@@@ acm thinks this list needs to
exclude contact person now.
New assignments for Performance Metrics Registry will be administered New assignments for Performance Metrics Registry will be administered
by IANA through Expert Review [RFC8126], i.e., review by one of a by IANA through Expert Review [RFC8126], i.e., review by one of a
group of experts, the Performance Metric Experts, who are appointed group of experts, the Performance Metric Experts, who are appointed
by the IESG upon recommendation of the Transport Area Directors, or by the IESG upon recommendation of the Transport Area Directors, or
by Standards Action. The experts can be initially drawn from the by Standards Action. The experts can be initially drawn from the
Working Group Chairs, document editors, and members of the Working Group Chairs, document editors, and members of the
Performance Metrics Directorate, among other sources of experts. Performance Metrics Directorate, among other sources of experts.
Extensions of the Performance Metrics Registry require IETF Standards Extensions of the Performance Metrics Registry require IETF Standards
Action. Only one form of registry extension is envisaged: Action. Only one form of registry extension is envisaged:
1. Adding columns, or both categories and columns, to accommodate 1. Adding columns, or both categories and columns, to accommodate
unanticipated aspects of new measurements and metric categories. unanticipated aspects of new measurements and metric categories.
If the Performance Metrics Registry is extended in this way, the If the Performance Metrics Registry is extended in this way, the
Version number of future entries complying with the extension SHALL Version number of future entries complying with the extension SHALL
be incremented (either in the unit or tenths digit, depending on the be incremented (either in the unit or tenths digit, depending on the
degree of extension. degree of extension.
11. Acknowledgments 11. Blank Registry Template
This section provides a blank template to help IANA and registry
entry writers.
11.1. Summary
This category includes multiple indexes to the registry entry: the
element ID and metric name.
11.1.1. ID (Identifier)
<insert a numeric identifier, an integer, TBD>
11.1.2. Name
<insert name according to metric naming convention>
11.1.3. URIs
URL: http://<TBD by IANA>/<name>
11.1.4. Description
<provide a description>
11.1.5. Change Controller
11.1.6. Version (of Registry Format)
11.2. Metric Definition
This category includes columns to prompt the entry of all necessary
details related to the metric definition, including the RFC reference
and values of input factors, called fixed parameters.
11.2.1. Reference Definition
<Full bibliographic reference to an immutable doc.>
<specific section reference and additional clarifications, if needed>
11.2.2. Fixed Parameters
<list and specify Fixed Parameters, input factors that must be
determined and embedded in the measurement system for use when
needed>
11.3. Method of Measurement
This category includes columns for references to relevant sections of
the RFC(s) and any supplemental information needed to ensure an
unambiguous methods for implementations.
11.3.1. Reference Method
<for metric, insert relevant section references and supplemental
info>
11.3.2. Packet Stream Generation
<list of generation parameters and section/spec references if needed>
11.3.3. Traffic Filtering (observation) Details
The measured results based on a filtered version of the packets
observed, and this section provides the filter details (when
present).
<section reference>.
11.3.4. Sampling Distribution
<insert time distribution details, or how this is diff from the
filter>
11.3.5. Run-time Parameters and Data Format
Run-time Parameters are input factors that must be determined,
configured into the measurement system, and reported with the results
for the context to be complete.
<list of run-time parameters, and their data formats>
11.3.6. Roles
<lists the names of the different roles from the measurement method>
11.4. Output
This category specifies all details of the Output of measurements
using the metric.
11.4.1. Type
<insert name of the output type, raw or a selected summary statistic>
11.4.2. Reference Definition
<describe the reference data format for each type of result>
11.4.3. Metric Units
<insert units for the measured results, and the reference
specification>.
11.4.4. Calibration
<insert information on calibration>
11.5. Administrative items
11.5.1. Status
<current or deprecated>
11.5.2. Requestor
<name or RFC, etc.>
11.5.3. Revision
<1.0>
11.5.4. Revision Date
<format YYYY-MM-DD>
11.6. Comments and Remarks
<Additional (Informational) details for this entry>
12. Acknowledgments
Thanks to Brian Trammell and Bill Cerveny, IPPM chairs, for leading Thanks to Brian Trammell and Bill Cerveny, IPPM chairs, for leading
some brainstorming sessions on this topic. Thanks to Barbara Stark some brainstorming sessions on this topic. Thanks to Barbara Stark
and Juergen Schoenwaelder for the detailed feedback and suggestions. and Juergen Schoenwaelder for the detailed feedback and suggestions.
Thanks to Andrew McGregor for suggestions on metric naming. Thanks Thanks to Andrew McGregor for suggestions on metric naming. Thanks
to Michelle Cotton for her early IANA review, and to Amanda Barber to Michelle Cotton for her early IANA review, and to Amanda Barber
for answering questions related to the presentation of the registry for answering questions related to the presentation of the registry
and accessibility of the complete template via URL. and accessibility of the complete template via URL.
12. References 13. References
12.1. Normative References 13.1. Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
<https://www.rfc-editor.org/info/rfc2026>. <https://www.rfc-editor.org/info/rfc2026>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 31, line 29 skipping to change at page 35, line 9
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References 13.2. Informative References
[I-D.ietf-ippm-initial-registry] [I-D.ietf-ippm-initial-registry]
Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza, Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza,
"Initial Performance Metrics Registry Entries", draft- "Initial Performance Metrics Registry Entries", draft-
ietf-ippm-initial-registry-11 (work in progress), March ietf-ippm-initial-registry-12 (work in progress),
2019. September 2019.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681,
September 1999, <https://www.rfc-editor.org/info/rfc2681>. September 1999, <https://www.rfc-editor.org/info/rfc2681>.
[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network
performance measurement with periodic streams", RFC 3432, performance measurement with periodic streams", RFC 3432,
DOI 10.17487/RFC3432, November 2002, DOI 10.17487/RFC3432, November 2002,
<https://www.rfc-editor.org/info/rfc3432>. <https://www.rfc-editor.org/info/rfc3432>.
skipping to change at page 33, line 27 skipping to change at page 37, line 8
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>. May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC8194] Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for [RFC8194] Schoenwaelder, J. and V. Bajpai, "A YANG Data Model for
LMAP Measurement Agents", RFC 8194, DOI 10.17487/RFC8194, LMAP Measurement Agents", RFC 8194, DOI 10.17487/RFC8194,
August 2017, <https://www.rfc-editor.org/info/rfc8194>. August 2017, <https://www.rfc-editor.org/info/rfc8194>.
Authors' Addresses Authors' Addresses
Marcelo Bagnulo Marcelo Bagnulo
Universidad Carlos III de Madrid Universidad Carlos III de
Madrid
Av. Universidad 30 Av. Universidad 30
Leganes, Madrid 28911 Leganes, Madrid 28911
SPAIN SPAIN
Phone: 34 91 6249500 Phone: 34 91 6249500
Email: marcelo@it.uc3m.es Email: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es URI: http://www.it.uc3m.es
Benoit Claise Benoit Claise
Cisco Systems, Inc. Cisco Systems,
Inc.
De Kleetlaan 6a b1 De Kleetlaan 6a b1
1831 Diegem 1831 Diegem
Belgium Belgium
Email: bclaise@cisco.com Email: bclaise@cisco.com
Philip Eardley Philip Eardley
BT BT
Adastral Park, Martlesham Heath Adastral Park, Martlesham Heath
Ipswich Ipswich
 End of changes. 42 change blocks. 
82 lines changed or deleted 275 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/