draft-ietf-ippm-metric-registry-07.txt   draft-ietf-ippm-metric-registry-08.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: January 9, 2017 Cisco Systems, Inc. Expires: April 13, 2017 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
July 8, 2016 October 10, 2016
Registry for Performance Metrics Registry for Performance Metrics
draft-ietf-ippm-metric-registry-07 draft-ietf-ippm-metric-registry-08
Abstract Abstract
This document defines the format for the Performance Metrics registry This document defines the format for the Performance Metrics registry
and defines the IANA Registry for Performance Metrics. This document and defines the IANA Registry for Performance Metrics. This document
also gives a set of guidelines for Registered Performance Metric also gives a set of guidelines for Registered Performance Metric
requesters and reviewers. requesters and reviewers.
Status of This Memo Status of This Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 January 9, 2017. This Internet-Draft will expire on April 13, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
skipping to change at page 2, line 27 skipping to change at page 2, line 27
4.1. Interoperability . . . . . . . . . . . . . . . . . . . . 7 4.1. Interoperability . . . . . . . . . . . . . . . . . . . . 7
4.2. Single point of reference for Performance Metrics . . . . 8 4.2. Single point of reference for Performance Metrics . . . . 8
4.3. Side benefits . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Side benefits . . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . 9
6.1. Why this Attempt Will Succeed . . . . . . . . . . . . . . 10 6.1. Why this Attempt Will Succeed . . . . . . . . . . . . . . 10
7. Definition of the Performance Metric Registry . . . . . . . . 10 7. Definition of the Performance Metric Registry . . . . . . . . 10
7.1. Summary Category . . . . . . . . . . . . . . . . . . . . 12 7.1. Summary Category . . . . . . . . . . . . . . . . . . . . 12
7.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 12 7.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 12
7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 14 7.1.4. Description . . . . . . . . . . . . . . . . . . . . . 15
7.2. Metric Definition Category . . . . . . . . . . . . . . . 14 7.1.5. Reference . . . . . . . . . . . . . . . . . . . . . . 15
7.2.1. Reference Definition . . . . . . . . . . . . . . . . 14 7.1.6. Change Controller . . . . . . . . . . . . . . . . . . 15
7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 15 7.2. Metric Definition Category . . . . . . . . . . . . . . . 16
7.3. Method of Measurement Category . . . . . . . . . . . . . 15 7.2.1. Reference Definition . . . . . . . . . . . . . . . . 16
7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 15 7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 16
7.3.2. Packet Stream Generation . . . . . . . . . . . . . . 16 7.3. Method of Measurement Category . . . . . . . . . . . . . 17
7.3.3. Traffic Filter . . . . . . . . . . . . . . . . . . . 16 7.3.1. Reference Method . . . . . . . . . . . . . . . . . . 17
7.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 17 7.3.2. Packet Stream Generation . . . . . . . . . . . . . . 17
7.3.5. Run-time Parameters . . . . . . . . . . . . . . . . . 17 7.3.3. Traffic Filter . . . . . . . . . . . . . . . . . . . 18
7.3.6. Role . . . . . . . . . . . . . . . . . . . . . . . . 18 7.3.4. Sampling Distribution . . . . . . . . . . . . . . . . 18
7.4. Output Category . . . . . . . . . . . . . . . . . . . . . 18 7.3.5. Run-time Parameters . . . . . . . . . . . . . . . . . 19
7.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 19 7.3.6. Role . . . . . . . . . . . . . . . . . . . . . . . . 19
7.4.2. Reference Definition . . . . . . . . . . . . . . . . 19 7.4. Output Category . . . . . . . . . . . . . . . . . . . . . 20
7.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 19 7.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . 20
7.5. Administrative information . . . . . . . . . . . . . . . 19 7.4.2. Reference Definition . . . . . . . . . . . . . . . . 20
7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 19 7.4.3. Metric Units . . . . . . . . . . . . . . . . . . . . 20
7.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 19 7.5. Administrative information . . . . . . . . . . . . . . . 20
7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 19 7.5.1. Status . . . . . . . . . . . . . . . . . . . . . . . 20
7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 20 7.5.2. Requester . . . . . . . . . . . . . . . . . . . . . . 21
7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 20 7.5.3. Revision . . . . . . . . . . . . . . . . . . . . . . 21
8. The Life-Cycle of Registered Performance Metrics . . . . . . 20 7.5.4. Revision Date . . . . . . . . . . . . . . . . . . . . 21
7.6. Comments and Remarks . . . . . . . . . . . . . . . . . . 21
8. The Life-Cycle of Registered Performance Metrics . . . . . . 21
8.1. Adding new Performance Metrics to the Performance Metrics 8.1. Adding new Performance Metrics to the Performance Metrics
Registry . . . . . . . . . . . . . . . . . . . . . . . . 20 Registry . . . . . . . . . . . . . . . . . . . . . . . . 21
8.2. Revising Registered Performance Metrics . . . . . . . . . 22
8.2. Revising Registered Performance Metrics . . . . . . . . . 21 8.3. Deprecating Registered Performance Metrics . . . . . . . 24
8.3. Deprecating Registered Performance Metrics . . . . . . . 22 9. Security considerations . . . . . . . . . . . . . . . . . . . 24
9. Security considerations . . . . . . . . . . . . . . . . . . . 23 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 12.1. Normative References . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . 24 12.2. Informative References . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
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 10, line 48 skipping to change at page 10, line 48
agent to perform a measurement using a given metric by embedding the agent to perform a measurement using a given metric by embedding the
Performance Metric Registry value in the protocol, a metric is Performance Metric Registry value in the protocol, a metric is
properly specified if it is defined well-enough so that it is properly specified if it is defined well-enough so that it is
possible (and practical) to implement the metric in the measurement possible (and practical) to implement the metric in the measurement
agent. This was the failure of the previous attempt: a registry agent. This was the failure of the previous attempt: a registry
entry with an undefined Type-P (section 13 of RFC 2330 [RFC2330]) entry with an undefined Type-P (section 13 of RFC 2330 [RFC2330])
allows implementation to be ambiguous. allows implementation to be ambiguous.
7. Definition of the Performance Metric Registry 7. Definition of the Performance Metric Registry
In this section we define the columns of the Performance Metric This Performance Metric Registry is applicable to Performance Metrics
Registry. This Performance Metric Registry is applicable to used for Active Measurement, Passive Measurement, and any other form
Performance Metrics issued from Active Measurement, Passive of Performance Metric. Each category of measurement has unique
Measurement, and any other form of Performance Metric. Because of properties, so some of the columns defined below are not applicable
that, it may be the case that some of the columns defined are not for a given metric category. In this case, the column(s) SHOULD be
applicable for a given type of metric. If this is the case, the populated with the "NA" value (Non Applicable). However, the "NA"
column(s) SHOULD be populated with the "NA" value (Non Applicable). value MUST NOT be used by any metric in the following columns:
However, the "NA" value MUST NOT be used by any metric in the Identifier, Name, URI, Status, Requester, Revision, Revision Date,
following columns: Identifier, Name, URI, Status, Requester, Description. In the future, a new category of metrics could require
Revision, Revision Date, Description. In addition, it may be additional columns, and adding new columns is a recognized form of
possible that, in the future, a new type of metric requires registry extension. The specification defining the new column(s)
additional columns. Should that be the case, it is possible to add MUST give guidelines to populate the new column(s) for existing
new columns to the registry. The specification defining the new entries (in general).
column(s) must define how to populate the new column(s) for existing
entries.
The columns of the Performance Metric Registry are defined next. The The columns of the Performance Metric Registry are defined below.
columns are grouped into "Categories" to facilitate the use of the The columns are grouped into "Categories" to facilitate the use of
registry. Categories are described at the 7.x heading level, and the registry. Categories are described at the 7.x heading level, and
columns are at the 7.x.y heading level. The Figure below illustrates columns are at the 7.x.y heading level. The Figure below illustrates
this organization. An entry (row) therefore gives a complete this organization. An entry (row) therefore gives a complete
description of a Registered Performance Metric. description of a Registered Performance Metric.
Each column serves as a check-list item and helps to avoid omissions Each column serves as a check-list item and helps to avoid omissions
during registration and expert review. during registration and expert review.
Registry Categories and Columns, shown as Registry Categories and Columns, shown as
Category
------------------
Column | Column |
Summary Category |
------------------------------- ------------------
Identifier | Name | URIs | Description | Column | Column |
Metric Definition Summary
----------------------------------------- ----------------------------------------------------------------------
Reference Definition | Fixed Parameters | Identifier | Name | URIs | Description | Reference | Change Controller
Method of Measurement Metric Definition
--------------------------------------------------------------------- -----------------------------------------
Reference | Packet | Traffic | Sampling | Run-time | Role | Reference Definition | Fixed Parameters |
Method | Stream | Filter | Distribution | Parameters | |
| Generation |
Output
-----------------------------
| Type | Reference | Units |
| | Definition | |
Administrative Information Method of Measurement
---------------------------------- ---------------------------------------------------------------------
Status |Request | Rev | Rev.Date | Reference | Packet | Traffic | Sampling | Run-time | Role |
Method | Stream | Filter | Distribution | Parameters | |
| Generation |
Output
-----------------------------
| Type | Reference | Units |
| | Definition | |
Comments and Remarks Administrative Information
-------------------- ----------------------------------
Status |Request | Rev | Rev.Date |
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 Metric Registry. identifier MUST be unique within the Performance Metric Registry.
The Registered Performance Metric unique identifier is a 16-bit The Registered Performance Metric unique identifier is a 16-bit
integer (range 0 to 65535). When adding newly Registered Performance integer (range 0 to 65535).
Metrics to the Performance Metric Registry, IANA should assign the
lowest available identifier to the next Registered Performance The Identifier 0 should be Reserved. The Identifier values from
Metric. 64512 to 65536 are reserved for private use.
When adding newly Registered Performance Metrics to the Performance
Metric Registry, IANA should assign the lowest available identifier
to the next Registered Performance Metric.
7.1.2. Name 7.1.2. Name
As the name of a Registered Performance Metric is the first thing a As the name of a Registered Performance Metric is the first thing a
potential human implementor will use when determining whether it is potential human implementor will use when determining whether it is
suitable for their measurement study, it is important to be as suitable for their measurement study, it is important to be as
precise and descriptive as possible. In future, users will review precise and descriptive as possible. In future, users will review
the names to determine if the metric they want to measure has already the names to determine if the metric they want to measure has already
been registered, or if a similar entry is available as a basis for been registered, or if a similar entry is available as a basis for
creating a new entry. creating a new entry.
Names are composed of the following elements, seperated by an Names are composed of the following elements, separated by an
underscore character "_": underscore character "_":
MetricType_MethodLayer_SubTypeMethod_... Spec_Units_Output MetricType_Method_SubTypeMethod_... Spec_Units_Output
o MetricType: a combination of the directional properties and the o MetricType: a combination of the directional properties and the
metric measured, such as RTDelay, OWDelay, metric measured, such as:
o Method: One of the methods defined in [RFC7799], such as Active, RTDelay
Passive, HybridType1,
OWDelay
RTLoss
OWLoss
OWPDV
OWIPDV
OWReorder
OWDuplic
o Method: One of the methods defined in [RFC7799], such as:
Active
Passive
HybridType1
HybridType2
Spatial
o SubTypeMethod: One or more sub-types to further describe the o SubTypeMethod: One or more sub-types to further describe the
features of the entry, such as ICMP, IP, UDP, Poisson, Periodic, features of the entry, such as:
ICMP
IP
UDP
Poisson
Periodic
o <optionally, other SubTypeMethods> o <optionally, other SubTypeMethods>
o Spec: RFC that specifies this entry in the form RFCXXXXsecY, such o Spec: RFC that specifies this entry in the form RFCXXXXsecY, such
as RFC7799sec3. Note: this is not the Primary Reference as RFC7799sec3. Note: this is not the Primary Reference
specification for the metric; it will be blank until the RFC specification for the metric; it will be blank until the RFC
number is assigned. number is assigned, and would remain blank in private registry
entries without an RFC.
o Units: The units of measurement for the output, such as Seconds, o Units: The units of measurement for the output, such as:
RatioPercent,
o Output: The type of resulting ouptut of measurement, such as Seconds
Singleton, Minimum, Maximum, Median, 95%tile,
RatioPercent
EventTotal (for unit-less counts)
o Output: The type of output resulting from measurement, such as:
Singleton
Minimum
Maximum
Median
Mean
95percentile
99percentile
An example is: An example is:
RTDelay_Active_UDP_Poisson_RFCXXXXsecY_Seconds_95th%tile RTDelay_Active_UDP_Poisson_RFCXXXXsecY_Seconds_95th%tile
as described in section 4 of [I-D.ietf-ippm-initial-registry]. as described in section 4 of [I-D.ietf-ippm-initial-registry].
Note that private registries following the format described here Note that private registries following the format described here
SHOULD use the prefix "Priv_" on any name to avoid unintended SHOULD use the prefix "Priv_" on any name to avoid unintended
conflicts (further considerations are described in section 10). conflicts (further considerations are described in section 10).
skipping to change at page 14, line 20 skipping to change at page 15, line 26
the metric name. The resulting URI is globally unique. the metric name. The resulting URI is globally unique.
The URIs column MUST contain a second URI which is a URL [RFC3986] The URIs column MUST contain a second URI which is a URL [RFC3986]
and uniquely identifies and locates the metric entry so it is and uniquely identifies and locates the metric entry so it is
accessible through the Internet. The URL points to a file containing accessible through the Internet. The URL points to a file containing
the human-readable information of exactly one registry entry. the human-readable information of exactly one registry entry.
Ideally, the file will be HTML-formated and contain URLs to Ideally, the file will be HTML-formated and contain URLs to
referenced sections of HTML-ized RFCs. The separate files for referenced sections of HTML-ized RFCs. The separate files for
different entries can be more easily edited and re-used when different entries can be more easily edited and re-used when
preparing new entries. The exact composition of each metric URL will preparing new entries. The exact composition of each metric URL will
be determined by IANA, but there will be some overlap with the URN be determined by IANA and reside on "iana.org", but there will be
described above. The major sections of some overlap with the URN described above. The major sections of
[I-D.ietf-ippm-initial-registry] provide an example in HTML form [I-D.ietf-ippm-initial-registry] provide an example in HTML form
(sections 4 and above). (sections 4 and above).
7.1.4. Description 7.1.4. Description
A Registered Performance Metric description is a written A Registered Performance Metric description is a written
representation of a particular Performance Metrics Registry entry. representation of a particular Performance Metrics Registry entry.
It supplements the Registered Performance Metric name to help It supplements the Registered Performance Metric name to help
Performance Metrics Registry users select relevant Registered Performance Metrics Registry users select relevant Registered
Performance Metrics. Performance Metrics.
7.1.5. Reference
This entry gives the specification containing the candidate registry
entry which was reviewed and agreed, if such an RFC or other
specification exists.
7.1.6. Change Controller
This entry names the entity responsible for approving revsions to the
regsitry entry, and provides contact information.
7.2. Metric Definition Category 7.2. Metric Definition Category
This category includes columns to prompt all necessary details This category includes columns to prompt all necessary details
related to the metric definition, including the RFC reference and related to the metric definition, including the RFC reference and
values of input factors, called fixed parameters, which are left open values of input factors, called fixed parameters, which are left open
in the RFC but have a particular value defined by the performance in the RFC but have a particular value defined by the performance
metric. metric.
7.2.1. Reference Definition 7.2.1. Reference Definition
skipping to change at page 21, line 25 skipping to change at page 22, line 37
A request for Revision is only permissible when the changes maintain A request for Revision is only permissible when the changes maintain
backward-compatibility with implementations of the prior Performance backward-compatibility with implementations of the prior Performance
Metrics Registry entry describing a Registered Performance Metric Metrics Registry entry describing a Registered Performance Metric
(entries with lower revision numbers, but the same Identifier and (entries with lower revision numbers, but the same Identifier and
Name). Name).
The purpose of the Status field in the Performance Metric Registry is The purpose of the Status field in the Performance Metric Registry is
to indicate whether the entry for a Registered Performance Metric is to indicate whether the entry for a Registered Performance Metric is
'current' or 'deprecated'. 'current' or 'deprecated'.
In addition, no policy is defined for revising IANA Performance In addition, no policy is defined for revising the Performance Metric
Metric entries or addressing errors therein. To be certain, changes entries in the IANA Regsirty or addressing errors therein. To be
and deprecations within the Performance Metric Registry are not certain, changes and deprecations within the Performance Metric
encouraged, and should be avoided to the extent possible. However, Registry are not encouraged, and should be avoided to the extent
in recognition that change is inevitable, the provisions of this possible. However, in recognition that change is inevitable, the
section address the need for revisions. provisions of this section address the need for revisions.
Revisions are initiated by sending a candidate Registered Performance Revisions are initiated by sending a candidate Registered Performance
Metric definition to IANA, as in Section 8, identifying the existing Metric definition to IANA, as in Section 8, identifying the existing
Performance Metrics Registry entry. Performance Metrics Registry entry.
The primary requirement in the definition of a policy for managing The primary requirement in the definition of a policy for managing
changes to existing Registered Performance Metrics is avoidance of changes to existing Registered Performance Metrics is avoidance of
interoperability problems; Performance Metric Experts must work to interoperability problems; Performance Metric Experts must work to
maintain interoperability above all else. Changes to Registered maintain interoperability above all else. Changes to Registered
Performance Metrics may only be done in an inter-operable way; Performance Metrics may only be done in an inter-operable way;
skipping to change at page 23, line 41 skipping to change at page 24, line 51
This draft doesn't introduce any new security considerations for the This draft doesn't introduce any new security considerations for the
Internet. However, the definition of Performance Metrics may Internet. However, the definition of Performance Metrics may
introduce some security concerns, and should be reviewed with introduce some security concerns, and should be reviewed with
security in mind. security in mind.
10. IANA Considerations 10. IANA Considerations
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 "Registered Performance Metrics" with the Performance Metrics called "Registered Performance Metrics". This
columns defined in Section 7. Registry will contain the following Summary columns:
Identifier:
Name:
URIs:
Description:
Reference:
Change Controller:
Descriptions of these columns and additional information found in the
template for registry entries (categories and columns) are further
defined in section Section 7.
The "Identifier" 0 should be Reserved. "The Identifier" values from
64512 to 65536 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
are further defined in section Section 7.
The "Name" (or "URIs" ??) column will have a link to the full
template.
The "Reference" column will include an RFC, an approved specification
from another standards body, or the contact person.
New assignments for Performance Metric Registry will be administered New assignments for Performance Metric Registry will be administered
by IANA through Expert Review [RFC5226], i.e., review by one of a by IANA through Expert Review [RFC5226], i.e., review by one of a
group of experts, the Performance Metric Experts, appointed by the group of experts, the Performance Metric Experts, who are appointed
IESG upon recommendation of the Transport Area Directors. The by the IESG upon recommendation of the Transport Area Directors. The
experts can be initially drawn from the Working Group Chairs and experts can be initially drawn from the Working Group Chairs and
document editors of the Performance Metrics Directorate among other document editors of the Performance Metrics Directorate among other
sources of experts. sources of experts.
The Identifier values from 64512 to 65536 are reserved for private >>> ok to here, pending the use of "Name" or URIs column question.
use. Names starting with the prefix Priv_ are reserved for private
use, and are not considered for registration.
This document requests the allocation of the URI prefix This document requests the allocation of the URI prefix
urn:ietf:params:ippm:metric for the purpose of generating URIs for urn:ietf:params:ippm:metric for the purpose of generating URIs for
Registered Performance Metrics. Registered Performance Metrics. Note: an alternate proposal which
avoids the "params" namspace for protocols is urn:ietf:metric: .
Extensions of the Registry require IETF Standards Action. Two forms
of registry extension are envisaged:
1. Adding columns or both categories and columns, to accommodate
unanticipated aspects of new measurements and metric categories.
Note: this form of extension may be well-served by adding a
format version number column now, then existing entries (without
the extended column) can be left as-is, if desired.
2. Additional values for the various elements used in the Metric
"Name" column. A candidate Metric Entry RFC would propose one or
more new element values required to describe the entry.
11. Acknowledgments 11. 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
to Michelle Cotton for her early IANA review, and to Amanda Barber
for answering questions related to the presentation of the registry
and accessibility of the complete template via URL.
12. References 12. References
12.1. Normative References 12.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,
<http://www.rfc-editor.org/info/rfc2026>. <http://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
skipping to change at page 27, line 37 skipping to change at page 29, line 42
everything in-between, or Hybrid)", draft-ietf-ippm- everything in-between, or Hybrid)", draft-ietf-ippm-
active-passive-06 (work in progress), January 2016. active-passive-06 (work in progress), January 2016.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <http://www.rfc-editor.org/info/rfc7799>. May 2016, <http://www.rfc-editor.org/info/rfc7799>.
[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 Metric Registry Entries", draft-ietf- "Initial Performance Metric Registry Entries", draft-ietf-
ippm-initial-registry-00 (work in progress), March 2016. ippm-initial-registry-01 (work in progress), July 2016.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<http://www.rfc-editor.org/info/rfc6991>. <http://www.rfc-editor.org/info/rfc6991>.
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
 End of changes. 32 change blocks. 
112 lines changed or deleted 226 lines changed or added

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