[要約] RFC 8911は、パフォーマンスメトリクスのためのレジストリを定義し、その目的は様々なネットワークパフォーマンス測定ツール間でメトリクスの一貫性と互換性を確保することです。このレジストリは、ネットワークの診断、性能評価、およびトラブルシューティングの際に利用されます。
Internet Engineering Task Force (IETF) M. Bagnulo
Request for Comments: 8911 UC3M
Category: Standards Track B. Claise
ISSN: 2070-1721 Huawei
P. Eardley
BT
A. Morton
AT&T Labs
A. Akhter
Consultant
November 2021
Registry for Performance Metrics
パフォーマンスメトリックのレジストリ
Abstract
概要
This document defines the format for the IANA Registry of Performance Metrics. This document also gives a set of guidelines for Registered Performance Metric requesters and reviewers.
このドキュメントは、パフォーマンスメトリックのIANAレジストリのフォーマットを定義します。この資料は、登録されたパフォーマンスメトリックリクエスタおよびレビュー担当者の一連のガイドラインも与えられます。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書はインターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それはパブリックレビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8911.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8911で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2021 IETFの信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。この文書から抽出されたコードコンポーネントには、信託法定規定のセクション4。
Table of Contents
目次
1. Introduction
2. Terminology
3. Scope
4. Motivations for the Performance Metrics Registry
4.1. Interoperability
4.2. Single Point of Reference for Performance Metrics
4.3. Side Benefits
5. Criteria for Performance Metrics Registration
6. Performance Metrics Registry: Prior Attempt
6.1. Why This Attempt Should Succeed
7. Definition of the Performance Metrics Registry
7.1. Summary Category
7.1.1. Identifier
7.1.2. Name
7.1.3. URI
7.1.4. Description
7.1.5. Reference
7.1.6. Change Controller
7.1.7. Version (of Registry Format)
7.2. Metric Definition Category
7.2.1. Reference Definition
7.2.2. Fixed Parameters
7.3. Method of Measurement Category
7.3.1. Reference Method
7.3.2. Packet Stream Generation
7.3.3. Traffic Filter
7.3.4. Sampling Distribution
7.3.5. Runtime Parameters
7.3.6. Role
7.4. Output Category
7.4.1. Type
7.4.2. Reference Definition
7.4.3. Metric Units
7.4.4. Calibration
7.5. Administrative Information
7.5.1. Status
7.5.2. Requester
7.5.3. Revision
7.5.4. Revision Date
7.6. Comments and Remarks
8. Processes for Managing the Performance Metrics Registry Group
8.1. Adding New Performance Metrics to the Performance Metrics
Registry
8.2. Backward-Compatible Revision of Registered Performance
Metrics
8.3. Non-Backward-Compatible Deprecation of Registered
Performance Metrics
8.4. Obsolete Registry Entries
8.5. Registry Format Version and Future Changes/Extensions
9. Security Considerations
10. IANA Considerations
10.1. Registry Group
10.2. Performance Metrics Name Elements
10.3. New Performance Metrics Registry
11. Blank Registry Template
11.1. Summary
11.1.1. ID (Identifier)
11.1.2. Name
11.1.3. URI
11.1.4. Description
11.1.5. Reference
11.1.6. Change Controller
11.1.7. Version (of Registry Format)
11.2. Metric Definition
11.2.1. Reference Definition
11.2.2. Fixed Parameters
11.3. Method of Measurement
11.3.1. Reference Method
11.3.2. Packet Stream Generation
11.3.3. Traffic Filtering (Observation) Details
11.3.4. Sampling Distribution
11.3.5. Runtime Parameters and Data Format
11.3.6. Roles
11.4. Output
11.4.1. Type
11.4.2. Reference Definition
11.4.3. Metric Units
11.4.4. Calibration
11.5. Administrative Items
11.5.1. Status
11.5.2. Requester
11.5.3. Revision
11.5.4. Revision Date
11.6. Comments and Remarks
12. References
12.1. Normative References
12.2. Informative References
Acknowledgments
Authors' Addresses
The IETF specifies and uses Performance Metrics of protocols and applications transported over its protocols. Performance Metrics are an important part of network operations using IETF protocols, and [RFC6390] specifies guidelines for their development.
IETFは、そのプロトコルを介して転送されたプロトコルとアプリケーションのパフォーマンスメトリックを指定して使用します。パフォーマンスメトリックは、IETFプロトコルを使用したネットワーク操作の重要な部分であり、[RFC6390]は開発のガイドラインを指定します。
The definition and use of Performance Metrics in the IETF have been fostered in various working groups (WGs). Most notably:
IETF内の性能メトリックの定義と使用は、さまざまなワーキンググループ（WGS）で育成されています。最も注目に値する：
* The "IP Performance Metrics" (IPPM) WG is the WG primarily focusing on Performance Metrics definition at the IETF.
* 「IP Performance Metrics」（IPPM）WGは、主にIETFのパフォーマンスメトリック定義に焦点を当てているWGです。
* The "Benchmarking Methodology" WG (BMWG) defines many Performance Metrics for use in laboratory benchmarking of internetworking technologies.
* 「ベンチマーク方法」WG（BMWG）は、インターネットワーキング技術の実験室ベンチマークで使用するための多くの性能測定基準を定義しています。
* The "Metric Blocks for use with RTCP's Extended Report Framework" (XRBLOCK) WG (concluded) specified many Performance Metrics related to "RTP Control Protocol Extended Reports (RTCP XR)" [RFC3611], which establishes a framework to allow new information to be conveyed in RTCP, supplementing the original report blocks defined in "RTP: A Transport Protocol for Real-Time Applications" [RFC3550].
* 「RTCPの拡張レポートフレームワークで使用するためのメトリックブロック」（XRBLOCK）WG（締結）は、「RTP制御プロトコル拡張レポート（RTCP XR）」[RFC3611]に関連する多くのパフォーマンスメトリックを指定し、新しい情報を許可するフレームワークを確立しました。RTCPで運ばれ、「RTP：リアルタイムアプリケーション用のトランスポートプロトコル」[RFC3550]で定義されている元のレポートブロックを補充します。
* The "IP Flow Information eXport" (IPFIX) WG (concluded) specified an Internet Assigned Numbers Authority (IANA) process for new Information Elements. Some Information Elements related to Performance Metrics are proposed on a regular basis.
* 「IPフロー情報エクスポート」（IPFIX）WG（締結）は、新しい情報要素のインターネット割り当て番号局（IANA）プロセスを指定しました。パフォーマンスメトリックに関連するいくつかの情報要素は定期的に提案されています。
* The "Performance Metrics for Other Layers" (PMOL) WG (concluded) defined some Performance Metrics related to Session Initiation Protocol (SIP) voice quality [RFC6035].
* 「他のレイヤーのパフォーマンスメトリック」（PMOL）WG（終了）は、セッション開始プロトコル（SIP）音声品質[RFC6035]に関連するパフォーマンスメトリックを定義しました。
It is expected that more Performance Metrics will be defined in the future -- not only IP-based metrics but also metrics that are protocol specific and application specific.
IPベースのメトリックだけでなく、プロトコル固有のメトリックとアプリケーション固有のメトリックだけでなく、将来的にはより多くのパフォーマンスメトリックが定義されることが予想されます。
Despite the importance of Performance Metrics, there are two related problems for the industry:
パフォーマンス測定基準の重要性にもかかわらず、業界には2つの関連する問題があります。
* First, ensuring that when one party requests that another party measure (or report or in some way act on) a particular Performance Metric, both parties have exactly the same understanding of what Performance Metric is being referred to.
* まず、ある当事者が特定のパフォーマンスメトリックを測定する（または報告または何らかの方法で行われている）ことを1人の当事者が要求したときに、両方の当事者は、どのパフォーマンスメトリックが参照されているかについてまったく同じ理解を持っています。
* Second, discovering which Performance Metrics have been specified, to avoid developing a new Performance Metric that is very similar but not quite interoperable.
* 次に、非常に類似しているが全く相互運用不可能ではない新しいパフォーマンスメトリックを開発することを避けるために、どのパフォーマンスメトリックを指定したかを検出しています。
These problems can be addressed by creating a Registry for Performance Metrics with the Internet Assigned Numbers Authority (IANA). As such, this document defines the new IANA Registry for Performance Metrics.
これらの問題は、インターネット割り当て番号局（IANA）を使用してパフォーマンスメトリックのレジストリを作成することによって対処できます。そのため、この文書はパフォーマンスメトリックのための新しいIANAレジストリを定義します。
Per this document, IANA has created and now maintains the Performance Metrics Registry, according to the maintenance procedures and the format defined in the sections below. The resulting Performance Metrics Registry is for use by the IETF and others. Although the Registry formatting specifications herein are primarily for Registry creation by IANA, any other organization that wishes to create a Performance Metrics Registry may use the same formatting specifications for their purposes. The authors make no guarantee of the Registry format's applicability to any possible set of Performance Metrics envisaged by other organizations, but we encourage others to apply it. In the remainder of this document, unless we explicitly say otherwise, we will refer to the IANA-maintained Performance Metrics Registry as simply the Performance Metrics Registry.
このドキュメントでは、IANAが作成し、メンテナンス手順と下記のセクションで定義されている形式に従って、パフォーマンスメトリックレジストリを維持しています。結果として得られるパフォーマンスメトリックレジストリは、IETFなどで使用されます。本明細書のレジストリフォーマット仕様は、主にIANAによるレジストリ作成のために、パフォーマンスメトリックレジストリを作成したい他の組織では、その目的で同じフォーマット仕様を使用することがあります。著者らは、他の組織によって想定されているパフォーマンスメトリックの可能なセットへのレジストリフォーマットの適用性を保証しませんが、他の人がそれを適用することを奨励します。このドキュメントの残りの部分では、明示的に言っていない限り、IANA管理されているパフォーマンスメトリックレジストリを単にパフォーマンスメトリクスレジストリとして参照します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Performance Metric: A quantitative measure of performance, targeted to an IETF-specified protocol or targeted to an application transported over an IETF-specified protocol. Examples of Performance Metrics are the FTP response time for a complete file download, the DNS Response time to resolve the IP address(es), a database logging time, etc. This definition is consistent with the definition of a metric in [RFC2330] and broader than the definition of a Performance Metric in [RFC6390].
パフォーマンスメトリック：IETF指定されたプロトコルをターゲットとした、またはIETF指定されたプロトコルを介して転送されたアプリケーションをターゲットにしたパフォーマンスの定量的な尺度。パフォーマンスメトリックの例は、完全なファイルダウンロードのFTP応答時間、IPアドレス（ES）、データベースロギング時間などを解決するためのDNS応答時間です。この定義は[RFC2330]のメトリックの定義と一致しています。[RFC6390]のパフォーマンスメトリックの定義よりも広い。
Registered Performance Metric: A Performance Metric expressed as an entry in the Performance Metrics Registry, administered by IANA. Such a Performance Metric has met all of the Registry review criteria defined in this document in order to be included in the Registry.
登録パフォーマンスメトリック：IANAによって管理されたパフォーマンスメトリックレジストリのエントリとして表現されたパフォーマンスメトリック。このようなパフォーマンスメトリックは、レジストリに含まれるためにこの文書で定義されているすべてのレジストリレビュー基準を満たしています。
Performance Metrics Registry: The IANA Registry containing Registered Performance Metrics.
Performance Metricsレジストリ：登録パフォーマンスメトリックを含むIANAレジストリ。
Proprietary Registry: A set of metrics that are registered in a proprietary Registry, as opposed to the Performance Metrics Registry.
独自のレジストリ：Performance Metricsレジストリとは対照的に、独自のレジストリに登録されているメトリックのセット。
Performance Metrics Experts: A group of designated experts [RFC8126] selected by the IESG to validate the Performance Metrics before updating the Performance Metrics Registry. The Performance Metrics Experts work closely with IANA.
パフォーマンスメトリック専門家：Performance Metricsレジストリを更新する前に、IESGによって選択された指定された専門家[RFC8126]のグループ。パフォーマンス指標の専門家はIANAと緊密に機能します。
Parameter: An input factor defined as a variable in the definition of a Performance Metric. A Parameter is a numerical or other specified factor forming one of a set that defines a metric or sets the conditions of its operation. All Parameters must be known in order to make a measurement using a metric and interpret the results. There are two types of Parameters: Fixed and Runtime. For the Fixed Parameters, the value of the variable is specified in the Performance Metrics Registry Entry and different Fixed Parameter values results in different Registered Performance Metrics. For the Runtime Parameters, the value of the variable is defined when the Metric Measurement Method is executed and a given Registered Performance Metric supports multiple values for the Parameter. Although Runtime Parameters do not change the fundamental nature of the Performance Metric's definition, some have substantial influence on the network property being assessed and interpretation of the results.
パラメータ：パフォーマンスメトリックの定義の変数として定義された入力係数。パラメータは、メトリックを定義するか、またはその動作の条件を設定するセットのうちの1つを形成する数値的または他の指定された要因です。測定基準を使用して測定を行い、結果を解釈するためには、すべてのパラメータを知らなければなりません。パラメータには2種類あります。固定と実行時。固定パラメータの場合、変数の値はパフォーマンスメトリックレジストリエントリで指定され、異なる固定パラメータ値は異なる登録パフォーマンスメトリックになります。ランタイムパラメータの場合、変数の値は、メトリック測定方法が実行され、指定された登録済みパフォーマンスメトリックがパラメータに複数の値をサポートしているときに定義されます。ランタイムパラメータはパフォーマンスメトリックの定義の基本的な性質を変えないが、いくつかは、結果の評価および解釈にあるネットワークプロパティに大きな影響を与える。
Note: Consider the case of packet loss in the following two Active Measurement Method cases. The first case is packet loss as background loss where the Runtime Parameter set includes a very sparse Poisson stream and only characterizes the times when packets were lost. Actual user streams likely see much higher loss at these times, due to tail drop or radio errors. The second case is packet loss ratio as the complimentary probability of delivery ratio where the Runtime Parameter set includes a very dense, bursty stream, and characterizes the loss experienced by a stream that approximates a user stream. These are both "Loss metrics", but the difference in interpretation of the results is highly dependent on the Runtime Parameters (at least), to the extreme where we are actually using loss ratio to infer its complimentary probability: delivery ratio.
注：以下の2つのアクティブ測定方法の場合の場合は、パケット損失の場合を考えてください。最初のケースは、ランタイムパラメータセットが非常にスパースポアソンストリームを含むバックグラウンドロスとしてのパケット損失であり、パケットが失われた時の時間を特徴付ける。実際のユーザーストリームは、テールドロップまたはラジオエラーのために、これらの時にはるかに高い損失を見る可能性があります。第2のケースは、ランタイムパラメータセットが非常に緻密でバーストストリームを含み、ユーザストリームに近いストリームによって経験される損失を特徴付ける配信比率の相補的確率としてのパケット損失率である。これらは両方とも「損失測定基準」であるが、結果の解釈の違いは、実際に私達が実際に損失率を使用してその相補的確率を推測するために、ランタイムパラメータ（少なくとも）に大きく依存している。
Active Measurement Methods: Methods of Measurement conducted on traffic that serves only the purpose of measurement and is generated for that reason alone, and whose traffic characteristics are known a priori. The complete definition of Active Methods is specified in Section 3.4 of [RFC7799]. Examples of Active Measurement Methods are the Measurement Methods for the one-way delay metric defined in [RFC7679] and the round-trip delay metric defined in [RFC2681].
能動測定方法：測定目的のみを担当し、その理由で生成され、その理由で生成され、その旨が先験的に知られている測定方法。アクティブメソッドの完全な定義は[RFC7799]のセクション3.4で指定されています。能動的測定方法の例は、[RFC7679]で定義されている一方向遅延メトリックと[RFC2681]で定義されている往復遅延メトリックの測定方法です。
Passive Measurement Methods: Methods of Measurement conducted on network traffic, generated by either (1) the end users or (2) network elements that would exist regardless of whether the measurement was being conducted or not. The complete definition of Passive Methods is specified in Section 3.6 of [RFC7799]. One characteristic of Passive Measurement Methods is that sensitive information may be observed and, as a consequence, stored in the measurement system.
受動的測定方法：ネットワークトラフィックで実行される測定方法（1）エンドユーザーまたは（2）測定が行われているかどうかにかかわらず存在する（2）存在するネットワーク要素。パッシブメソッドの完全な定義は、[RFC7799]のセクション3.6で指定されています。受動的測定方法の1つの特徴は、機密情報が観察され、結果として測定システムに格納されていることである。
Hybrid Measurement Methods: Methods of Measurement that use a combination of Active Methods and Passive Methods, to assess Active Metrics, Passive Metrics, or new metrics derived from the a priori knowledge and observations of the stream of interest. The complete definition of Hybrid Methods is specified in Section 3.8 of [RFC7799].
ハイブリッド測定方法：能動的なメトリックと受動的な方法の組み合わせを使用して、能動的なメトリック、受動的なメトリック、または興味の流れの先験的な知識と観察から得られた新しい測定基準を評価する測定方法。ハイブリッドメソッドの完全な定義は[RFC7799]のセクション3.8で指定されています。
This document is intended for two different audiences:
この文書は2つの異なる視聴者を対象としています。
1. For those preparing a candidate Performance Metric, it provides criteria that the proposal SHOULD meet (see Section 5). It also provides instructions for writing the text for each column of the candidate Performance Metric and the references required for the new Performance Metrics Registry Entry (up to and including the publication of one or more immutable documents such as an RFC) (see Section 7).
1. 候補性能測定基準を準備するためには、提案が満たすべき基準を提供します（セクション5を参照）。また、候補性能メトリックの各列のテキストと、新しいパフォーマンスメトリックレジストリエントリに必要な参照（RFCなどの1つ以上の不変文書の公開）に必要な参照についても説明します（セクション7を参照）。。
2. For the appointed Performance Metrics Experts and for IANA personnel administering the new IANA Performance Metrics Registry, it defines a set of acceptance criteria against which a candidate Registered Performance Metric should be evaluated, and requirements for the composition of a candidate Performance Metric Registry Entry.
2. 任命されたパフォーマンスメトリクスの専門家とIANA担当者のための新しいIANAのパフォーマンスメトリックレジストリの管理のために、候補登録パフォーマンスメトリックを評価する必要がある一連の承認基準、および候補性能メトリックレジストリエントリの構成に対する要件を定義します。
Other organizations that standardize performance metrics are encouraged to use the process defined in this memo to propose a candidate Registered Performance Metric. In addition, this document may be useful for other organizations who are defining a Performance Metrics Registry of their own and may reuse the features of the Performance Metrics Registry defined in this document.
パフォーマンスメトリックを標準化する他の組織は、このメモに定義されたプロセスを使用して候補登録パフォーマンスメトリックを提案することが奨励されています。さらに、このドキュメントは、自分のパフォーマンスメトリクスレジストリを定義している他の組織にとって有用であり、このドキュメントで定義されているパフォーマンスメトリックレジストリの機能を再利用する可能性があります。
This Performance Metrics Registry is applicable to Performance Metrics derived from Active Measurement, Passive Measurement, and any other form of Performance Metric. This Registry is designed to encompass Performance Metrics developed throughout the IETF and especially for the technologies specified in the following working groups: IPPM, XRBLOCK, IPFIX, and BMWG. This document analyzes a prior attempt to set up a Performance Metrics Registry and the reasons why this design was inadequate [RFC6248].
このパフォーマンスメトリックレジストリは、アクティブな測定、パッシブ測定、およびその他のパフォーマンスメトリックから派生したパフォーマンスメトリックに適用されます。このレジストリは、IETF全体で開発されたパフォーマンスメトリック、特に次のワーキンググループで指定されたテクノロジを網羅するように設計されています.IPPM、XRBLOCK、IPFIX、およびBMWG。このドキュメントでは、パフォーマンスメトリクスレジストリを設定する以前の試みと、このデザインが不適切である理由[RFC6248]。
[RFC8912] populates the new Registry with the initial set of entries.
[RFC8912]初期のエントリのセットに新しいレジストリを入力します。
In this section, we detail several motivations for the Performance Metrics Registry.
このセクションでは、パフォーマンスメトリクスレジストリのいくつかの動機を詳しく説明しています。
As with any IETF Registry, the primary intention is to manage the registration of Identifiers for use within one or more protocols. In the particular case of the Performance Metrics Registry, there are two types of protocols that will use the Performance Metrics in the Performance Metrics Registry during their operation (by referring to the index values):
任意のIETFレジストリと同様に、主な意図は、1つまたは複数のプロトコル内で使用するための識別子の登録を管理することです。Performance Metricsレジストリの特定のケースでは、（インデックス値を参照して）パフォーマンスメトリックレジストリのパフォーマンスメトリックを使用するプロトコルには2種類あります。
Control Protocol: This type of protocol is used to allow one entity to request that another entity perform a measurement using a specific metric defined by the Performance Metrics Registry. One particular example is the Large-scale Measurement of Broadband Performance (LMAP) framework [RFC7594]. Using the LMAP terminology, the Performance Metrics Registry is used in the LMAP Control Protocol to allow a Controller to schedule a Measurement Task for one or more Measurement Agents. In order to enable this use case, the entries in the Performance Metrics Registry must be sufficiently defined to allow a Measurement Agent implementation to trigger a specific Measurement Task upon the reception of a Control Protocol message. This requirement heavily constrains the types of entries that are acceptable for the Performance Metrics Registry.
制御プロトコル：このタイプのプロトコルは、Performance Metricsレジストリによって定義された特定のメトリックを使用して別のエンティティが測定を実行するように要求することを要求するために使用されます。1つの特定の例は、ブロードバンド性能（LMAP）フレームワーク[RFC7594]の大規模測定です。LMAP用語を使用して、Performance MetricsレジストリはLMAP制御プロトコルで使用され、コントローラが1つ以上の測定エージェントの測定タスクをスケジュールできるようになります。このユースケースを有効にするためには、Performance Metricsレジストリ内のエントリは、制御エージェントの実装が制御プロトコルメッセージの受信時に特定の測定タスクをトリガできるように十分に定義されている必要があります。この要件は、パフォーマンスメトリックレジストリに許容されるエントリの種類を大きく制限します。
Report Protocol: This type of protocol is used to allow an entity to report Measurement Results to another entity. By referencing to a specific Registered Performance Metric, it is possible to properly characterize the Measurement Result data being reported. Using the LMAP terminology, the Performance Metrics Registry is used in the LMAP Report Protocol to allow a Measurement Agent to report Measurement Results to a Collector.
レポートプロトコル：このタイプのプロトコルは、エンティティが測定結果を別のエンティティに報告できるようにするために使用されます。特定の登録能力測定基準を参照することにより、報告されている測定結果データを適切に特徴付けることができる。LMAP用語を使用して、Performance MetricsレジストリはLMAPレポートプロトコルで使用され、測定エージェントが測定結果をコレクタに報告できるようにします。
It should be noted that the LMAP framework explicitly allows for using not only the IANA-maintained Performance Metrics Registry but also other registries containing Performance Metrics, i.e., either (1) registries defined by other organizations or (2) private registries. However, others who are creating registries to be used in the context of an LMAP framework are encouraged to use the Registry format defined in this document, because this makes it easier for developers of LMAP Measurement Agents to programmatically use information found in those other registries' entries.
LMAPフレームワークは、IANA維持パフォーマンスメトリックレジストリだけでなく、パフォーマンスメトリック、すなわち（1）レジストリを含む（1）プライベートレジストリのどちらかを含む他のレジストリを明示的に使用することを明示的に許可することに注意してください。ただし、LMAPフレームワークのコンテキストで使用されるレジストリを作成している他のユーザーは、このドキュメントで定義されているレジストリ形式を使用することが奨励されているため、LMAP測定エージェントの開発者がプログラムでそれらの他のレジストリにある情報をプログラム的に使用するのが簡単になります。エントリ
A Performance Metrics Registry serves as a single point of reference for Performance Metrics defined in different working groups in the IETF. As we mentioned earlier, there are several working groups that define Performance Metrics in the IETF, and it is hard to keep track of all of them. This results in multiple definitions of similar Performance Metrics that attempt to measure the same phenomena but in slightly different (and incompatible) ways. Having a Registry would allow the IETF community and others to have a single list of relevant Performance Metrics defined by the IETF (and others, where appropriate). The single list is also an essential aspect of communication about Performance Metrics, where different entities that request measurements, execute measurements, and report the results can benefit from a common understanding of the referenced Performance Metric.
Performance Metricsレジストリは、IETF内のさまざまなワーキンググループで定義されているパフォーマンスメトリックの単一の参照点として機能します。前述したように、IETFにパフォーマンスメトリックを定義するワーキンググループがいくつかあり、それらすべてを追跡するのは困難です。これにより、同じ現象を測定しようとするのがわずかに異なる（および互換性のない）方法で、同様の性能メトリックの複数の定義が得られます。レジストリを持つことで、IETFコミュニティなどがIETF（または他のものが適切な場合には）によって定義された関連性能メトリックの単一のリストを持つことができます。シングルリストは、測定を要求し、測定を実行し、結果を報告するさまざまなエンティティのパフォーマンスメトリックに関する通信の重要な側面でも、参照されたパフォーマンスメトリックの共通の理解から利益を得ることができます。
There are a couple of side benefits of having such a Registry. First, the Performance Metrics Registry could serve as an inventory of useful and used Performance Metrics that are normally supported by different implementations of Measurement Agents. Second, the results of measurements using the Performance Metrics should be comparable even if they are performed by different implementations and in different networks, as the Performance Metric is properly defined. BCP 176 [RFC6576] examines whether the results produced by independent implementations are equivalent in the context of evaluating the completeness and clarity of metric specifications. [RFC6576] is a BCP [RFC2026] that defines the Standards Track advancement testing for (Active) IPPM Metrics, and the same process will likely suffice to determine whether Registered Performance Metrics are sufficiently well specified to result in comparable (or equivalent) results. If a Registered Performance Metric has undergone such testing, this SHOULD be noted in "Comments and Remarks" (see Section 7.6), with a reference to the test results.
そのようなレジストリを持つことの2つの側面利益があります。第1に、パフォーマンスメトリックレジストリは、通常の測定エージェントの実装によって通常サポートされている有用なパフォーマンスメトリックのインベントリとして機能する可能性があります。第二に、性能メトリックが正しく定義されているので、パフォーマンスメトリックを使用した測定結果は、それらがさまざまな実装とさまざまなネットワークによって実行されていても比較できます。 BCP 176 [RFC6576]は、独立した実装によって生成された結果が、メトリック仕様の完全性と明確さを評価するという状況において同等であるかどうかを調べます。 [RFC6576]は、（Active）IPPMメトリックの標準トラックの進歩テストを定義するBCP [RFC2026]であり、同じプロセスでは、登録されたパフォーマンスメトリックが同等（または同等の）結果をもたらすのに十分に明確に指定されているかどうかを判断するのに十分です。登録されたパフォーマンスメトリックがそのようなテストを受けている場合、これは「コメントと備考」（7.6項を参照）で注意してください。テスト結果を参照してください。
It is neither possible nor desirable to populate the Performance Metrics Registry with all combinations of Parameters of all Performance Metrics. A Registered Performance Metric SHOULD be:
パフォーマンスメトリクスレジストリをすべてのパフォーマンスメトリックのパラメータのすべての組み合わせと入力することは不可能でもありません。登録されたパフォーマンスメトリックは次のとおりです。
1. Interpretable by the human user.
1. 人間のユーザーによって解釈可能
2. Implementable by the software or hardware designer.
2. ソフトウェアまたはハードウェアデザイナによって実装可能です。
3. Deployable by network operators.
3. ネットワーク事業者によって展開可能
4. Accurate in terms of producing equivalent results, and for interoperability and deployment across vendors.
4. 同等の結果を生み出すという点で、そしてベンダー全体での相互運用性および展開のために正確に。
5. Operationally useful, so that it has significant industry interest and/or has seen deployment.
5. それが重要な業界で興味を持っていること、および/または展開を見たことがあります。
6. Sufficiently tightly defined, so that different values for the Runtime Parameters do not change the fundamental nature of the measurement or change the practicality of its implementation.
6. 十分に厳密に定義されているので、ランタイムパラメータの異なる値は測定の基本的な性質を変えたり、その実装の実用性を変化させません。
In essence, there needs to be evidence that (1) a candidate Registered Performance Metric has significant industry interest or has seen deployment and (2) there is agreement that the candidate Registered Performance Metric serves its intended purpose.
本質的には、（1）候補登録業績メトリックが重要な業界であるか、展開を見たことがあるか、（2）候補登録業績メトリックが意図された目的に役立つということを証明する必要があります。
There was a previous attempt to define a Metrics Registry [RFC4148]. However, it was obsoleted by [RFC6248] because it was "found to be insufficiently detailed to uniquely identify IPPM metrics... [there was too much] variability possible when characterizing a metric exactly", which led to the IPPM Metrics Registry defined in [RFC4148] having "very few users, if any."
メトリックレジストリ[RFC4148]を定義する前の試みがありました。ただし、IPPMメトリックレジストリが定義されているIPPMメトリクスレジストリにつながって、メトリックメトリクスレジストリが導かれた場合、IPPMメトリクスレジストリが導かれた場合は、IPPMメトリクスレジストリが導かれたことがわかりました。[RFC4148]「あれば非常に少数のユーザーを持つ」。
Three interesting additional quotes from [RFC6248] might help to understand the issues related to that registry.
[RFC6248]からの3つの興味深い引用符が、そのレジストリに関連する問題を理解するのに役立ちます。
1. "It is not believed to be feasible or even useful to register every possible combination of Type P, metric parameters, and Stream parameters using the current structure of the IPPM Metrics Registry."
1. 「IPPMメトリックレジストリの現在の構造を使用して、P、メトリックパラメータ、およびストリームパラメータのすべての可能な組み合わせを登録することは、実行可能であるか、または有用であるとは考えられていない。」
2. "The current registry structure has been found to be insufficiently detailed to uniquely identify IPPM metrics."
2. 「現在のレジストリ構造は、IPPMメトリックを一意に識別するために十分に詳細なことがわかっています。」
3. "Despite apparent efforts to find current or even future users, no one responded to the call for interest in the RFC 4148 registry during the second half of 2010."
3. 「現在または将来のユーザーを見つけるための明らかな努力にもかかわらず、2010年後半のRFC 4148レジストリへの関心のあるコールには誰もが回答しませんでした。
The current approach learns from this by tightly defining each Registered Performance Metric with only a few variable (Runtime) Parameters to be specified by the measurement designer, if any. The idea is that entries in the Performance Metrics Registry stem from different Measurement Methods that require input (Runtime) Parameters to set factors like Source and Destination addresses (which do not change the fundamental nature of the measurement). The downside of this approach is that it could result in a large number of entries in the Performance Metrics Registry. There is agreement 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 questionable usefulness.
現在のアプローチは、測定デザイナによって指定される数の変数（ランタイム）パラメータだけで、登録された各パフォーマンスメトリックをしっかりと定義することによって学習します。このアイデアは、パフォーマンスメトリックレジストリのエントリが、入力（Runtime）パラメータを必要とするさまざまな測定メソッドから、ソースアドレスと宛先アドレス（測定の基本的な性質を変更しない）を設定するというさまざまな測定方法からステムです。このアプローチの欠点は、パフォーマンスメトリクスレジストリにエントリが多数ある可能性があることです。この文脈ではもっと少ないという合意があります。
As mentioned in the previous section, one of the main issues with the previous Registry was that the metrics contained in the Registry were too generic to be useful. This document specifies stricter criteria for Performance Metric registration (see Section 5) and imposes a group of Performance Metrics Experts that will provide guidelines to assess if a Performance Metric is properly specified.
前のセクションで述べたように、以前のレジストリに関する主な問題の1つは、レジストリに含まれているメトリックが一般的ではありませんでした。このドキュメントでは、パフォーマンスメトリック登録のためのシラタル基準（セクション5を参照）を指定し、パフォーマンスメトリックが正しく指定されているかどうかを評価するためのガイドラインを提供するパフォーマンスメトリック専門家のグループを課します。
Another key difference between this attempt and the previous one is that in this case there is at least one clear user for the Performance Metrics Registry: the LMAP framework and protocol. Because the LMAP protocol will use the Performance Metrics Registry values in its operation, this actually helps to determine if a metric is properly defined -- in particular, since we expect that the LMAP Control Protocol will enable a Controller to request that a Measurement Agent perform a measurement using a given metric by embedding the Performance Metrics Registry Identifier in the protocol. Such a metric and method are properly specified if they are defined well enough so that it is possible (and practical) to implement them in the Measurement Agent. This was the failure of the previous attempt: a Registry Entry with an undefined Type-P (Section 13 of [RFC2330]) allows measurement results to vary significantly.
この試行の間のもう1つの重要な違いと前のものは、この場合、Performance Metricsレジストリに少なくとも1つのクリアユーザーがあります.LMAPフレームワークとプロトコル。LMAPプロトコルはその操作でパフォーマンスメトリックレジストリ値を使用するため、実際にはメトリックが正しく定義されているかどうかを判断するのに役立ちます。プロトコルにパフォーマンスメトリックレジストリ識別子を埋め込むことで、指定されたメトリックを使用した測定。そのようなメトリックおよび方法は、それらが十分に定義されているのであれば適切に指定されているので、それらを測定エージェントに実装することが可能である（そして実用的）。これは前の試行の失敗でした。未定義のタイプPを持つレジストリエントリ（[RFC2330]のセクション13）では、測定結果が大幅に変化することができます。
This Performance Metrics Registry is applicable to Performance Metrics used for Active Measurement, Passive Measurement, and any other form of Performance Measurement. Each category of measurement has unique properties, so some of the columns defined below are not applicable for a given metric category. In this case, the column(s) SHOULD be populated with the "N/A" value (Not Applicable). However, the "N/A" value MUST NOT be used by any metric in the following columns: Identifier, Name, URI, Status, Requester, Revision, Revision Date, Description. In the future, a new category of metrics could require additional columns, and adding new columns is a recognized form of Registry extension. The specification defining the new column(s) MUST give general guidelines for populating the new column(s) for existing entries.
このパフォーマンスメトリックレジストリは、アクティブな測定、パッシブ測定、およびその他のパフォーマンス測定に使用されるパフォーマンスメトリックに適用されます。測定値の各カテゴリには固有のプロパティがあります。そのため、以下に定義されている列の中には、特定のメトリックカテゴリには適用できません。この場合、列に「N / A」の値（該当なし）が入力されている必要があります。ただし、識別子、名前、URI、ステータス、リクエスタ、リビジョン、リビジョン日、説明。将来的には、メトリックの新しいカテゴリが追加の列を必要とし、新しい列を追加することは、認識されているレジストリ拡張形式です。新しい列を定義する仕様は、既存のエントリの新しい列を入力するための一般的なガイドラインを与える必要があります。
The columns of the Performance Metrics Registry are defined below. The columns are grouped into "Categories" to facilitate the use of the Registry. Categories are described at the "Section 7.x" heading level, and columns are described at the "Section 7.x.y" heading level. The figure below illustrates this organization. An entry (row) therefore gives a complete description of a Registered Performance Metric.
Performance Metricsレジストリの列を以下に定義します。列はレジストリの使用を容易にするために「カテゴリ」にグループ化されます。カテゴリは「7.x」の見出しレベルで説明され、列は「7.x.y」の見出しレベルで説明されています。下の図はこの組織を示しています。したがって、エントリ（行）は登録されたパフォーマンスメトリックの完全な説明を与えます。
Each column serves as a checklist item and helps to avoid omissions during registration and Expert Review [RFC8126].
各列はチェックリスト項目として機能し、登録およびエキスパートレビュー中の省略を回避するのに役立ちます[RFC8126]。
Registry Categories and Columns are shown below in this format:
レジストリカテゴリと列は、次の形式で以下に示されています。
Category
------------------...
Column | Column |...
Summary
----------------------------------------------------------------
Identifier | Name | URI | Desc. | Reference | Change | Ver |
| | | | | Controller |
Metric Definition
-----------------------------------------
Reference Definition | Fixed Parameters |
Method of Measurement
---------------------------------------------------------------------
Reference | Packet | Traffic | Sampling | Runtime | Role |
Method | Stream | Filter | Distribution | Parameters | |
| Generation |
Output
-----------------------------------------
Type | Reference | Units | Calibration |
| Definition | | |
Administrative Information
-------------------------------------
Status |Requester | Rev | Rev. Date |
Comments and Remarks
--------------------
There is a blank template of the Registry template provided in Section 11 of this memo.
このメモのセクション11に提供されているレジストリテンプレートの空白のテンプレートがあります。
This column provides a numeric Identifier for the Registered Performance Metric. The Identifier of each Registered Performance Metric MUST be unique. Note that revising a Metric according to the process in Section 8.2 creates a new entry in the Performance Metrics Registry with the same identifier.
この列は、登録されたパフォーマンスメトリックの数値識別子を提供します。登録された各パフォーマンスメトリックの識別子は一意である必要があります。セクション8.2のプロセスに従ってメトリックを修正することで、パフォーマンスメトリックレジストリに同じ識別子を持つ新しいエントリが作成されることに注意してください。
The Registered Performance Metric unique Identifier is an unbounded integer (range 0 to infinity).
登録されたパフォーマンスメトリック固有IDは、無制限の整数（無限大の範囲）です。
The Identifier 0 should be Reserved. The Identifier values from 64512 to 65535 are reserved for private or experimental use, and the user may encounter overlapping uses.
識別子0は予約されるべきです。64512から65535の識別子値は、プライベートまたは実験的な使用のために予約されており、ユーザーは重複する使用に遭遇する可能性があります。
When adding new Registered Performance Metrics to the Performance Metrics Registry, IANA SHOULD assign the lowest available Identifier to the new Registered Performance Metric.
Performance Metricsレジストリに新しい登録されたパフォーマンスメトリックを追加する場合、IANAは使用可能な最小の識別子を新しい登録済みパフォーマンスメトリックに割り当てる必要があります。
If a Performance Metrics Expert providing review determines that there is a reason to assign a specific numeric Identifier, possibly leaving a temporary gap in the numbering, then the Performance Metrics Expert SHALL inform IANA of this decision.
パフォーマンスメトリクスエキスパートレビューでは、特定の数値識別子を割り当てる理由があると判断した場合、標識に一時的なギャップを残すと、パフォーマンスメトリックエキスパートはこの決定のIANAに通知するものとします。
As the Name of a Registered Performance Metric is the first thing a potential human implementer will use when determining whether it is suitable for their measurement study, it is important to be as precise and descriptive as possible. In the future, users will review 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 creating a new entry.
登録されたパフォーマンスメトリックの名前は、それが測定研究に適しているかどうかを判断する際に潜在的な人間の実装者が最初に使用されるので、できるだけ正確で説明的であることが重要です。将来的には、ユーザーは、測定したいメトリックがすでに登録されているか、新しいエントリを作成するための基礎として、メトリックがすでに登録されているかどうかを判断します。
Names are composed of the following elements, separated by an underscore character "_":
名前は、アンダースコア文字 "_"で区切られた次の要素で構成されています。
MetricType_Method_SubTypeMethod_... Spec_Units_Output
metrictype_method_subtypeMethod _... spec_units_output.
MetricType: A combination of the directional properties and the metric measured, such as and not limited to:
Metrictype：指向性特性と測定されたメトリックの組み合わせ、例えば以下のようなものです。
+-----------+--------------------------------------+
| RTDelay | Round-Trip Delay |
+-----------+--------------------------------------+
| RTDNS | Response Time Domain Name Service |
+-----------+--------------------------------------+
| RLDNS | Response Loss Domain Name Service |
+-----------+--------------------------------------+
| OWDelay | One-Way Delay |
+-----------+--------------------------------------+
| RTLoss | Round-Trip Loss |
+-----------+--------------------------------------+
| OWLoss | One-Way Loss |
+-----------+--------------------------------------+
| OWPDV | One-Way Packet Delay Variation |
+-----------+--------------------------------------+
| OWIPDV | One-Way Inter-Packet Delay Variation |
+-----------+--------------------------------------+
| OWReorder | One-Way Packet Reordering |
+-----------+--------------------------------------+
| OWDuplic | One-Way Packet Duplication |
+-----------+--------------------------------------+
| OWBTC | One-Way Bulk Transport Capacity |
+-----------+--------------------------------------+
| OWMBM | One-Way Model-Based Metric |
+-----------+--------------------------------------+
| SPMonitor | Single-Point Monitor |
+-----------+--------------------------------------+
| MPMonitor | Multi-Point Monitor |
+-----------+--------------------------------------+
Table 1
表1
Method: One of the methods defined in [RFC7799], such as and not limited to:
方法：以下のような[RFC7799]で定義されている方法の1つ。
+-------------+----------------------------------------------+
| Active | depends on a dedicated measurement packet |
| | stream and observations of the stream as |
| | described in [RFC7799] |
+-------------+----------------------------------------------+
| Passive | depends *solely* on observation of one or |
| | more existing packet streams as described in |
| | [RFC7799] |
+-------------+----------------------------------------------+
| HybridType1 | Hybrid Type I observations on one stream |
| | that combine both Active Methods and Passive |
| | Methods as described in [RFC7799] |
+-------------+----------------------------------------------+
| HybridType2 | Hybrid Type II observations on two or more |
| | streams that combine both Active Methods and |
| | Passive Methods as described in [RFC7799] |
+-------------+----------------------------------------------+
| Spatial | spatial metric as described in [RFC5644] |
+-------------+----------------------------------------------+
Table 2
表2.
SubTypeMethod: One or more subtypes to further describe the features of the entry, such as and not limited to:
subtypeMethod：次のようなエントリの機能をさらに説明するための1つ以上のサブタイプ。
+----------------+------------------------------------------------+
| ICMP | Internet Control Message Protocol |
+----------------+------------------------------------------------+
| IP | Internet Protocol |
+----------------+------------------------------------------------+
| DSCPxx | where xx is replaced by a Diffserv code point |
+----------------+------------------------------------------------+
| UDP | User Datagram Protocol |
+----------------+------------------------------------------------+
| TCP | Transport Control Protocol |
+----------------+------------------------------------------------+
| QUIC | QUIC transport protocol |
+----------------+------------------------------------------------+
| HS | Hand-Shake, such as TCP's 3-way HS |
+----------------+------------------------------------------------+
| Poisson | packet generation using Poisson distribution |
+----------------+------------------------------------------------+
| Periodic | periodic packet generation |
+----------------+------------------------------------------------+
| SendOnRcv | sender keeps one packet in transit by sending |
| | when previous packet arrives |
+----------------+------------------------------------------------+
| PayloadxxxxB | where xxxx is replaced by an integer, the |
| | number of octets or 8-bit Bytes in the Payload |
+----------------+------------------------------------------------+
| SustainedBurst | capacity test, worst case |
+----------------+------------------------------------------------+
| StandingQueue | test of bottleneck queue behavior |
+----------------+------------------------------------------------+
Table 3
表3.
SubTypeMethod values are separated by a hyphen "-" character, which indicates that they belong to this element and that their order is unimportant when considering Name uniqueness.
サブタイプメソッド値はハイフン " - "文字で区切ります。これは、それらがこの要素に属していること、および名前の一意性を考慮すると、その順序は重要ではないことを示します。
Spec: An immutable document Identifier combined with a document section Identifier. For RFCs, this consists of the RFC number and major section number that specifies this Registry Entry in the form "RFCXXXXsecY", e.g., RFC7799sec3. Note: The RFC number is not the primary reference specification for the metric definition (e.g., [RFC7679] as the primary reference specification for one-way delay metrics); it will contain the placeholder "RFCXXXXsecY" until the RFC number is assigned to the specifying document and would remain blank in 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.
SPEC：ドキュメントセクション識別子と組み合わされた不変文書識別子。RFCSの場合、これはRFC番号とメジャーセクション番号で構成されています。このレジストリエントリは、 "RFCxxxxSecy"、例えばRFC7799Sec3の形式で指定されます。注：RFC番号は、メトリック定義（例えば、一方向遅延メトリックの主な参照仕様としての[RFC7679]として、メトリック定義の主な参照指定ではありません。RFC番号が指定文書に割り当てられるまでプレースホルダー「RFCXXXXSECY」を含み、対応するRFCのないプライベートレジストリエントリでは空白のままになります。RFC番号の桁数に関係なく、RFC10Kの問題を予想すると、RFCの数は「rfcxxxx」の代わりになり続けます。他の標準機関からのレジストリエントリを予測すると、この名前要素の形式を提案し、エキスパートレビュー担当者による一貫性と独自性について検討する必要があります。
Units: The units of measurement for the output, such as and not limited to:
単位：次のような出力の測定単位、および以下に限定されます。
+------------+----------------------------+
| Seconds | |
+------------+----------------------------+
| Ratio | unitless |
+------------+----------------------------+
| Percent | value multiplied by 100% |
+------------+----------------------------+
| Logical | 1 or 0 |
+------------+----------------------------+
| Packets | |
+------------+----------------------------+
| BPS | bits per second |
+------------+----------------------------+
| PPS | packets per second |
+------------+----------------------------+
| EventTotal | for unitless counts |
+------------+----------------------------+
| Multiple | more than one type of unit |
+------------+----------------------------+
| Enumerated | a list of outcomes |
+------------+----------------------------+
| Unitless | |
+------------+----------------------------+
Table 4
表4.
Output: The type of output resulting from measurement, such as and not limited to:
出力：以下のような測定による出力の種類は、次のようにしています。
+--------------+------------------------------------+
| Singleton | |
+--------------+------------------------------------+
| Raw | multiple singletons |
+--------------+------------------------------------+
| Count | |
+--------------+------------------------------------+
| Minimum | |
+--------------+------------------------------------+
| Maximum | |
+--------------+------------------------------------+
| Median | |
+--------------+------------------------------------+
| Mean | |
+--------------+------------------------------------+
| 95Percentile | 95th percentile |
+--------------+------------------------------------+
| 99Percentile | 99th percentile |
+--------------+------------------------------------+
| StdDev | standard deviation |
+--------------+------------------------------------+
| Variance | |
+--------------+------------------------------------+
| PFI | pass, fail, inconclusive |
+--------------+------------------------------------+
| FlowRecords | descriptions of flows observed |
+--------------+------------------------------------+
| LossRatio | lost packets to total packets, <=1 |
+--------------+------------------------------------+
Table 5
表5.
An example, as described in Section 4 of [RFC8912], is
例は、[RFC8912]のセクション4に記載されているように、
RTDelay_Active_IP-UDP-Periodic_RFC8912sec4_Seconds_95Percentile
RTDELAY_ACTIVE_IP-UDP-DEMERIC_RFC8912SEC4_SECONDSS_95PERCENTILE
Note that private registries following the format described here SHOULD use the prefix "Priv_" on any Name to avoid unintended conflicts (further considerations are described in Section 10). Private Registry Entries usually have no specifying RFC; thus, the Spec: element has no clear interpretation.
ここで説明されているフォーマットに続くプライベートレジストリは、意図しない競合を回避するために任意の名前で「priv_」を使用する必要があります（さらに考慮事項はセクション10で説明されています）。プライベートレジストリエントリには通常RFCを指定していません。したがって、spec：要素には明確な解釈はありません。
The URI column MUST contain a URL [RFC3986] that uniquely identifies and locates the Metric Entry so it is accessible through the Internet. The URL points to a file containing all of the human-readable information for one Registry Entry. The URL SHALL reference a target file that is preferably HTML-formatted and contains URLs to referenced sections of HTMLized RFCs, or other reference specifications. These target files for different entries can be more easily edited and reused when preparing new entries. The exact form of the URL for each target file, and the target file itself, will be determined by IANA and reside on <https://www.iana.org/>. Section 4 of [RFC8912], as well as subsequent major sections of that document, provide an example of a target file in HTML form.
URI列には、メトリックエントリを一意に識別して、インターネットを介してアクセス可能なように、URL [RFC3986]を含める必要があります。URLは、1つのレジストリエントリのすべての人間が読める情報を含むファイルを指します。URLは、好ましくはHTMLフォーマットされたターゲットファイルを参照し、HTMLized RFCの参照セクションまたはその他の参照仕様にURLを含む。さまざまなエントリのためのこれらのターゲットファイルは、新しいエントリを作成するときに、より簡単に編集して再利用できます。各ターゲットファイルのURLとターゲットファイル自体の正確な形式は、IANAによって決定され、<https：//www.iana.org/>にあります。[RFC8912]のセクション4、およびそのドキュメントの後続の主要セクションは、ターゲットファイルの例をHTML形式で提供します。
A Registered Performance Metric description is a written representation of a particular Performance Metrics Registry Entry. It supplements the Registered Performance Metric Name to help Performance Metrics Registry users select relevant Registered Performance Metrics.
登録されたパフォーマンスメトリックの説明は、特定のパフォーマンスメトリックレジストリエントリの書き込み表現です。Performance Metricsレジストリユーザーに関連する登録済みパフォーマンスメトリックを選択するために、登録されたパフォーマンスメトリック名を補足します。
This entry gives the specification containing the candidate Registry Entry that was reviewed and agreed upon, if such an RFC or other specification exists.
このエントリは、そのようなRFCまたは他の仕様が存在する場合に、レビューされ合意された候補レジストリエントリを含む仕様を提供します。
This entry names the entity responsible for approving revisions to the Registry Entry and SHALL provide contact information (for an individual, where appropriate).
このエントリは、レジストリエントリへのリビジョンを承認する責任があるエンティティに、そして連絡先情報（適切な場合は個人用）を提供します。
This column gives the version number for the Registry format used, at the time the Performance Metric is registered. The format complying with this memo MUST use 1.0. A new RFC that changes the Registry format will designate a new version number corresponding to that format. The version number of Registry Entries SHALL NOT change unless the Registry Entry is updated to reflect the Registry format (following the procedures in Section 8).
この列は、パフォーマンスメトリックが登録されたときに使用されるレジストリフォーマットのバージョン番号を示します。このメモに準拠したフォーマットは1.0を使用する必要があります。レジストリフォーマットを変更する新しいRFCは、その形式に対応する新しいバージョン番号を指定します。レジストリエントリがレジストリフォーマットを反映するように更新されない限り、レジストリエントリのバージョン番号は変更されません（セクション8の手順に従って）。
This category includes columns to prompt all necessary details related to the metric definition, including the immutable document reference and values of input factors, called "Fixed Parameters", which are left open in the immutable document but have a particular value defined by the Performance Metric.
このカテゴリには、不変文書参照と入力ファクタの値を含む、メトリック定義に関連するすべての必要な詳細と、不変文書に開いているがパフォーマンスメトリックによって定義された特定の値を含む、メトリック定義に関連するすべての必要な詳細をプロンプロップする列が含まれています。。
This entry provides a reference (or references) to the relevant sections of the document or documents that define the metric, as well as any supplemental information needed to ensure an unambiguous definition for implementations. A given reference needs to be an immutable document, such as an RFC; for other standards bodies, it is likely to be necessary to reference a specific, dated version of a specification.
このエントリは、メトリックを定義する文書または文書の関連セクション、および実装の明確な定義を確実にするために必要な補足情報を参照（または参照）に提供します。所与の基準は、RFCのような不変文書である必要がある。他の標準機関の場合、仕様の特定の日付バージョンを参照する必要がある可能性があります。
Fixed Parameters are Parameters whose values must be specified in the Performance Metrics Registry. The measurement system uses these values.
固定パラメータは、パフォーマンスメトリックレジストリで値を指定する必要があるパラメータです。測定システムはこれらの値を使用します。
Where referenced metrics supply a list of Parameters as part of their descriptive template, a subset of the Parameters will be designated as Fixed Parameters. As an example for Active Metrics, Fixed Parameters determine most or all of the IPPM framework convention "packets of Type-P" as described in [RFC2330], such as transport protocol, payload length, TTL, etc. An example for Passive Metrics is for an RTP packet loss calculation that relies on the validation of a packet as RTP, which is a multi-packet validation controlled by the MIN_SEQUENTIAL variable as defined by [RFC3550]. Varying MIN_SEQUENTIAL values can alter the loss report, and this variable could be set as a Fixed Parameter.
参照されたメトリックがそれらの説明的なテンプレートの一部としてパラメータのリストを提供する場合、パラメータのサブセットは固定パラメータとして指定されます。アクティブメトリックの例として、トランスポートプロトコル、ペイロード長、TTLなどの[RFC2330]に記載されているIPPMフレームワーク規則「Type-Pのパケット」のほとんどまたは全部を決定します。パッシブメトリックの例はRTPとしてのパケットの検証に依存するRTPパケット損失計算は、[RFC3550]で定義されているMIN_SEQUINITIN変数によって制御されるマルチパケット検証です。min_sequential値を変えることで、損失レポートを変更でき、この変数は固定パラメータとして設定できます。
Parameters MUST have well-defined names. For human readers, the hanging-indent style is preferred, and any Parameter names and definitions that do not appear in the Reference Method Specification MUST appear in this column (or the Runtime Parameters column).
パラメータは明確に定義された名前を持つ必要があります。人間の読者のために、吊り下げインデントスタイルが好ましく、参照方法の指定に表示されないパラメータ名と定義はこの列（またはランタイタパラメータ列）に表示されなければなりません。
Parameters MUST have a well-specified data format.
パラメータは明確に指定されたデータフォーマットを持つ必要があります。
A Parameter that is a Fixed Parameter for one Performance Metrics Registry Entry may be designated as a Runtime Parameter for another Performance Metrics Registry Entry.
1つの性能メトリックレジストリエントリの固定パラメータであるパラメータは、別のパフォーマンスメトリックレジストリエントリのランタイムパラメータとして指定できます。
This category includes columns for references to relevant sections of the immutable document(s) and any supplemental information needed to ensure an unambiguous method for implementations.
このカテゴリには、不変文書の関連セクションへの参照の列と、実装の明確な方法を確保するために必要な補足情報が含まれています。
This entry provides references to relevant sections of immutable documents, such as RFC(s) (for other standards bodies, it is likely to be necessary to reference a specific, dated version of a specification) describing the Method of Measurement, as well as any supplemental information needed to ensure unambiguous interpretation for implementations referring to the immutable document text.
このエントリは、RFCなどの不変文書の関連セクションへの参照を提供します（他の標準体の場合は、特定の特定の日付の仕様書を参照する必要がある可能性があります）、測定方法を説明しています。不変文書テキストを参照して実装の明確な解釈を確実にするために必要な補足情報。
Specifically, this section should include pointers to pseudocode or actual code that could be used for an unambiguous implementation.
具体的には、このセクションには、疑似コードまたは実際のコードへのポインタを含める必要があります。
This column applies to Performance Metrics that generate traffic as part of their Measurement Method, including, but not necessarily limited to, Active Metrics. The generated traffic is referred to as a "stream", and this column describes its characteristics.
この列は、それらの測定方法の一部としてトラフィックを生成するパフォーマンスメトリックに適用されますが、必ずしも有効なメトリックを含むわけではありません。生成されたトラフィックは「ストリーム」と呼ばれ、この列はその特性を説明します。
Each entry for this column contains the following information:
この列の各エントリには、次の情報が含まれています。
Value: The name of the packet stream scheduling discipline
値：パケットストリームスケジューリング規律の名前
Reference: The specification where the Parameters of the stream are defined
参照：ストリームのパラメータが定義されている仕様
The packet generation stream may require Parameters such as the average packet rate and distribution truncation value for streams with Poisson-distributed inter-packet sending times. If such Parameters are needed, they should be included in either the Fixed Parameters column or the Runtime Parameters column, depending on whether they will be fixed or will be an input for the metric.
パケット生成ストリームは、Poisson分散間パケット間送信時間を有するストリームの平均パケットレートおよび配信切り捨て値などのパラメータを必要とし得る。そのようなパラメータが必要な場合は、固定パラメータ列またはランタイムパラメータ列のいずれかに含める必要があります。
The simplest example of stream specification is singleton scheduling (see [RFC2330]), where a single atomic measurement is conducted. Each atomic measurement could consist of sending a single packet (such as a DNS request) or sending several packets (for example, to request a web page). Other streams support a series of atomic measurements using pairs of packets, where the packet stream follows a schedule defining the timing between transmitted packets, and an atomic measurement assesses the reception time between successive packets (e.g., a measurement of Inter-Packet Delay Variation). More complex streams and measurement relationships are possible. Principally, two different streams are used in IPPM Metrics: (1) Poisson, distributed as described in [RFC2330] and (2) periodic, as described in [RFC3432]. Both Poisson and periodic have their own unique Parameters, and the relevant set of Parameter names and values should be included in either the Fixed Parameters column or the Runtime Parameters column.
ストリーム仕様の最も単純な例はシングルトンスケジューリング（[RFC2330]参照）であり、単一の原子測定が行われています。各アトミック測定は、単一のパケット（DNS要求など）を送信すること、または複数のパケットを送信することからなることができます（たとえば、Webページを要求するためなど）。他のストリームは、パケットストリームが送信されたパケット間のタイミングを定義するスケジュールに従うパケットのペアを使用して一連のアトミック測定をサポートし、アトミック測定は連続したパケット間の受信時間を評価する（例えば、パケット間遅延変動の測定値）。 。より複雑なストリームと測定関係が可能です。主に、2つの異なるストリームがIPPMメトリックで使用されています：（1）[RFC2330]および（2）定期的に（RFC3432]に記載されているように配布されているPOISSON。 PoissonとPeriodicの両方に独自の固有のパラメータがあり、関連するパラメータ名と値の関連セットは固定パラメータ列またはランタイムパラメータ列のいずれかに含める必要があります。
This column applies to Performance Metrics that observe packets flowing through (the device with) the Measurement Agent, i.e., packets that are not necessarily addressed to the Measurement Agent. This includes, but is not limited to, Passive Metrics. The filter specifies the traffic that is measured. This includes protocol field values/ranges, such as address ranges, and flow or session Identifiers.
この列は、測定エージェント、すなわち測定エージェントに必ずしもアドレス指定されていないパケットを通過するパケットを観察するパフォーマンスメトリックに適用されます。これには、パッシブメトリックが含まれますが、これらに限定されません。フィルタは、測定されるトラフィックを指定します。これには、アドレス範囲、およびフローまたはセッション識別子などのプロトコルフィールド値/範囲が含まれます。
The Traffic Filter itself depends on the needs of the metric itself and a balance of an operator's measurement needs and a user's need for privacy. Mechanics for conveying the filter criteria might be the BPF (Berkeley Packet Filter) or PSAMP (Packet Sampling) [RFC5475] Property Match Filtering, which reuses IPFIX [RFC7012]. An example BPF string for matching TCP/80 traffic to remote Destination net 192.0.2.0/24 would be "dst net 192.0.2.0/24 and tcp dst port 80". More complex filter engines may allow for matching using Deep Packet Inspection (DPI) technology.
トラフィックフィルタ自体は、メトリック自体のニーズと、オペレータの測定ニーズとユーザーのプライバシーの必要性に依存します。フィルタ基準を搬送するための力学は、BPF（Berkeley Packet Filter）またはPSAMP（Packet Sampling）[RFC5475]プロパティ一致フィルタリングであり、IPFIX [RFC7012]を再利用することができます。TCP / 80トラフィックをリモート宛先Net 192.0.2.0/24にマッチングするためのBPF文字列の例は、「DST Net 192.2.0/24とTCP DSTポート80」になります。より複雑なフィルタエンジンは、ディープパケット検査（DPI）技術を用いたマッチングを可能にし得る。
The Traffic Filter includes the following information:
トラフィックフィルタには、以下の情報が含まれています。
Type: The type of Traffic Filter used, e.g., BPF, PSAMP, OpenFlow rule, etc., as defined by a normative reference
タイプ：規範的参照で定義されているように、使用されるトラフィックフィルタの種類、例えばBPF、PSamp、OpenFlowルールなど。
Value: The actual set of rules expressed
値：表現された実際の規則のセット
The sampling distribution defines, out of all of the packets that match the Traffic Filter, which one or more of those packets are actually used for the measurement. One possibility is "all", which implies that all packets matching the Traffic Filter are considered, but there may be other sampling strategies. It includes the following information:
サンプリング分布は、トラフィックフィルタと一致するすべてのパケットのうち、それらのパケットのうちの1つまたは複数のパケットが実際に測定に使用されることを定義します。1つの可能性は「all」であり、これはトラフィックフィルタに一致するすべてのパケットが考慮されることを意味するが、他のサンプリング戦略があるかもしれない。以下の情報が含まれています。
Value: The name of the sampling distribution
値：サンプリング分布の名前
Reference definition: Pointer to the specification where the sampling distribution is properly defined
参照定義：サンプリング分布が正しく定義されている仕様へのポインタ
The sampling distribution may require Parameters. If such Parameters are needed, they should be included in either the Fixed Parameters column or the Runtime Parameters column, depending on whether they will be fixed or will be an input for the metric.
サンプリング分布はパラメータを必要とするかもしれません。そのようなパラメータが必要な場合は、固定パラメータ列またはランタイムパラメータ列のいずれかに含める必要があります。
PSAMP is documented in "Sampling and Filtering Techniques for IP Packet Selection" [RFC5475], while "A Framework for Packet Selection and Reporting" [RFC5474] provides more background information. The sampling distribution Parameters might be expressed in terms of the model described in "Information Model for Packet Sampling Exports" [RFC5477] and the process provided in "Flow Selection Techniques" [RFC7014].
PSAMPは「IPパケット選択用のサンプリングとフィルタリングのテクニック」で文書化されています[RFC5475]、「パケット選択とレポートのフレームワーク」[RFC5474]がより多くの背景情報を提供します。サンプリング分布パラメータは、「パケットサンプリングエクスポートの情報モデル」[RFC5477]で説明されているモデルと「フロー選択技術」[RFC7014]で説明されているモデルで表しています。
In contrast to the Fixed Parameters, Runtime Parameters are Parameters that do not change the fundamental nature of the measurement and their values are not specified in the Performance Metrics Registry. They are left as variables in the Registry, as an aid to the measurement system implementer or user. Their values are supplied on execution, configured into the measurement system, and reported with the Measurement Results (so that the context is complete).
固定パラメータとは対照的に、ランタイムパラメータは測定の基本的な性質を変えないパラメータであり、それらの値はパフォーマンスメトリックレジストリには指定されていません。それらは、測定システムの実装者またはユーザーへの補助として、それらはレジストリ内の変数として残されています。それらの値は実行時に供給され、測定システムに構成され、測定結果（コンテキストが完了するように）で報告されます。
Where metrics supply a list of Parameters as part of their descriptive template, a subset of the Parameters will be designated as Runtime Parameters.
Metricsがそれらの説明的なテンプレートの一部としてパラメータのリストを指定する場合、パラメータのサブセットはランタイムパラメータとして指定されます。
Parameters MUST have well-defined names. For human readers, the hanging-indent style is preferred, and the names and definitions that do not appear in the Reference Method Specification MUST appear in this column.
パラメータは明確に定義された名前を持つ必要があります。人間の読者のために、吊り下げ式スタイルが優先され、参照方法の指定に表示されない名前と定義はこの列に表示されなければなりません。
A data format for each Runtime Parameter MUST be specified in this column, to simplify the control and implementation of measurement devices. For example, Parameters that include an IPv4 address can be encoded as a 32-bit integer (i.e., a binary base64-encoded value) or "ip-address" as defined in [RFC6991]. The actual encoding(s) used must be explicitly defined for each Runtime Parameter. IPv6 addresses and options MUST be accommodated, allowing Registered Performance Metrics to be used in that address family. Other address families are permissible.
測定装置の制御と実装を簡単にするために、この列では各ランタイムパラメータのデータフォーマットを指定する必要があります。たとえば、IPv4アドレスを含むパラメータは、[RFC6991]で定義されている32ビット整数（すなわち、バイナリBase64エンコード値）または「IPアドレス」として符号化することができる。使用される実際のエンコーディングは、実行時パラメータごとに明示的に定義されている必要があります。IPv6アドレスとオプションに対応する必要があり、そのアドレスファミリで登録されたパフォーマンスメトリックを使用することができます。他のアドレスファミリーは許可されています。
Examples of Runtime Parameters include IP addresses, measurement point designations, start times and end times for measurement, and other information essential to the Method of Measurement.
ランタイムパラメータの例には、IPアドレス、測定ポイントの指定、測定時間および終了時間、および測定方法に不可欠な情報が含まれる。
In some Methods of Measurement, there may be several Roles defined, e.g., for a one-way packet delay Active Measurement, there is one Measurement Agent that generates the packets and another Agent that receives the packets. This column contains the name of the Role(s) for this particular entry. In the one-way delay example above, there should be two entries in the Registry's Role column, one for each Role (Source and Destination). When a Measurement Agent is instructed to perform the "Source" Role for the one-way delay metric, the Agent knows that it is required to generate packets. The values for this field are defined in the Reference Method of Measurement (and this frequently results in abbreviated Role names such as "Src").
いくつかの測定方法では、例えば、一方向パケット遅延アクティブ測定のために、いくつかの役割が定義されていてもよい。一方向パケット遅延能動測定では、パケットを生成する1つの測定エージェントおよびパケットを受信する別のエージェントがある。この列には、この特定のエントリの役割の名前が含まれています。上記の一方向の遅延の例では、レジストリの役割列には2つのエントリがあり、それぞれの役割（送信元と宛先）に1つあります。測定エージェントが一方向遅延メトリックの「ソース」ロールを実行するように指示された場合、エージェントはパケットを生成することが要求されることを知っている。このフィールドの値は測定の参照方法で定義されています（そしてこれは「SRC」のような省略された役割名をもたらします）。
When the Role column of a Registry Entry defines more than one Role, the Role SHALL be treated as a Runtime Parameter and supplied for execution. It should be noted that the LMAP framework [RFC7594] distinguishes the Role from other Runtime Parameters.
レジストリエントリの役割列が複数のロールを定義すると、役割はランタイムパラメータとして扱われ、実行のために提供されます。LMAPフレームワーク[RFC7594]は、他のランタイムパラメータからの役割を区別していることに注意してください。
For entries that involve a stream and many singleton measurements, a statistic may be specified in this column to summarize the results to a single value. If the complete set of measured singletons is output, this will be specified here.
ストリームと多くのシングルトン測定を含むエントリの場合、結果を単一の値にまとめるためにこの列に統計を指定できます。測定されたシングルトンの完全なセットが出力された場合、これはここで指定されます。
Some metrics embed one specific statistic in the reference metric definition, while others allow several output types or statistics.
一部のメトリックは、基準メトリック定義に1つの特定の統計を埋め込み、他のものはいくつかの出力タイプまたは統計を許可します。
This column contains the name of the output type. The output type defines a single type of result that the metric produces. It can be the raw results (packet send times and singleton metrics), or it can be a summary statistic. The specification of the output type MUST define the format of the output. In some systems, format specifications will simplify both measurement implementation and collection/storage tasks. Note that if two different statistics are required from a single measurement (for example, both "Xth percentile mean" and "Raw"), then a new output type must be defined ("Xth percentile mean AND Raw"). See Section 7.1.2 above for a list of output types.
この列には、出力タイプの名前が含まれています。出力タイプは、メトリックが生成する1種類の結果を定義します。それは生の結果（パケット送信時間とシングルトンメトリック）であるか、要約統計的になることができます。出力タイプの指定は出力のフォーマットを定義する必要があります。一部のシステムでは、フォーマット仕様は測定実装とコレクション/ストレージタスクの両方を単純化します。単一の測定から2つの異なる統計が必要な場合（たとえば、「Xthパーセンタイル平均」と「RAW」の両方）、新しい出力タイプを定義する必要があります（「Xthパーセンタイル平均と生」）。出力タイプのリストについては、上記の7.1.2項を参照してください。
This column contains a pointer to the specification(s) where the output type and format are defined.
この列には、出力タイプとフォーマットが定義されている仕様へのポインタが含まれています。
The measured results must be expressed using some standard dimension or units of measure. This column provides the units.
測定結果は、標準寸法または測定単位を使用して表現する必要があります。この列は単位を提供します。
When a sample of singletons (see Section 11 of [RFC2330] for definitions of these terms) is collected, this entry will specify the units for each measured value.
シングルトンのサンプル（RFC2330のセクション11を参照してください）が収集されると、このエントリは各測定値の単位を指定します。
Some specifications for Methods of Measurement include the ability to perform an error calibration. Section 3.7.3 of [RFC7679] is one example. In the Registry Entry, this field will identify a method of calibration for the metric, and, when available, the measurement system SHOULD perform the calibration when requested and produce the output with an indication that it is the result of a calibration method. In-situ calibration could be enabled with an internal loopback that includes as much of the measurement system as possible, performs address manipulation as needed, and provides some form of isolation (e.g., deterministic delay) to avoid send-receive interface contention. Some portion of the random and systematic error can be characterized in this way.
測定方法のためのいくつかの仕様には、エラー校正を実行する能力が含まれます。[RFC7679]のセクション3.7.3は一例です。レジストリエントリでは、このフィールドはメトリックのキャリブレーション方法を識別します。利用可能な場合、測定システムは要求されたときに校正を実行し、それが校正方法の結果であることを示して出力を生成する必要があります。インサイチュキャリブレーションは、できるだけ多くの測定システムを含む内部ループバックでイネーブルされ、送信受信インタフェースの競合を回避するためにアドレスの操作を実行することができ、ある種の単離（例えば、決定論的遅延）を提供します。このようにして、ランダムおよび体系的な誤差のいくつかの部分を特徴付けることができる。
For one-way delay measurements, the error calibration must include an assessment of the internal clock synchronization with its external reference (this internal clock is supplying timestamps for measurement). In practice, the time offsets of clocks at both the Source and Destination are needed to estimate the systematic error due to imperfect clock synchronization (the time offsets are smoothed; thus, the random variation is not usually represented in the results).
一方向の遅延測定のために、エラー校正には、外部リファレンスとの内部クロック同期の評価を含める必要があります（この内部クロックは測定用のタイムスタンプを供給しています）。実際には、電源と宛先の両方のクロックの時計のオフセットは、不完全なクロック同期のために系統的な誤差を推定するために必要です（時間オフセットは平滑化されます。したがって、ランダムな変動は通常結果には表されません）。
Both internal loopback calibration and clock synchronization can be used to estimate the *available accuracy* of the Output Metric Units. For example, repeated loopback delay measurements will reveal the portion of the output result resolution that is the result of system noise and is thus inaccurate.
内部ループバックキャリブレーションとクロック同期の両方を使用して、出力メトリックユニットの*使用可能な精度*を推定できます。例えば、繰り返しのループバック遅延測定は、システムノイズの結果であり、したがって不正確である出力結果分解能の部分を明らかにする。
This entry indicates the status of the specification of this Registered Performance Metric. Allowed values are 'Current', 'Deprecated', and 'Obsolete'. All newly defined Registered Performance Metrics have 'Current' Status.
このエントリは、この登録済みパフォーマンスメトリックの仕様のステータスを示しています。許容値は「現在」、「廃止予定」、および「廃止」です。新しく定義されているすべての登録パフォーマンスメトリックには「現在」のステータスがあります。
This entry indicates the requester for the Registered Performance Metric. The requester MAY be a document (such as an RFC) or a person.
このエントリは、登録済みパフォーマンスメトリックの要求者を示しています。リクエスターは文書（RFCなど）、または人物であり得る。
This entry indicates the revision number of a Registered Performance Metric, starting at 0 for Registered Performance Metrics at the time of definition and incremented by one for each revision. However, in the case of a non-backward-compatible revision, see Section 8.3.
このエントリは、定義時の登録パフォーマンスメトリックの0から始まり、リビジョンごとに1つずつ増加した登録済みパフォーマンスメトリックのリビジョン番号を示します。ただし、非互換性のないリビジョンの場合は、8.3項を参照してください。
This entry indicates the date of acceptance of the most recent revision for the Registered Performance Metric. The date SHALL be determined by IANA and the reviewing Performance Metrics Expert.
このエントリは、登録されたパフォーマンスメトリックの最新のリビジョンの受け入れ日を示します。日付はIANAとレビュー業績測定薬の専門家によって決定されます。
Besides providing additional details that do not appear in other categories, this open category (single column) allows unforeseen issues to be addressed by simply updating this informational entry.
他のカテゴリに表示されていない追加の詳細を提供することに加えて、このオープンカテゴリ（単一列）は、この情報入力を単に更新することによって、予期せぬ問題を解決することができます。
Once a Performance Metric or set of Performance Metrics has been identified for a given application, candidate Performance Metrics Registry Entry specifications prepared in accordance with Section 7 should be submitted to IANA to follow the process for review by the Performance Metrics Experts, as defined below. This process is also used for other changes to a Performance Metrics Registry Entry, such as deprecation or revision, as described later in this section.
特定のアプリケーションに対してパフォーマンスメトリックまたはパフォーマンスメトリックのセットが特定されると、セクション7に従って作成された候補性能メトリックレジストリエントリの仕様は、以下に定義されているように、パフォーマンスメトリック専門家によるレビューのプロセスに従うためにIANAに提出されるべきです。このプロセスは、このセクションで後述するように、非推奨またはリビジョンなど、パフォーマンスメトリックレジストリエントリへの他の変更にも使用されます。
It is desirable that the author(s) of a candidate Performance Metrics Registry Entry seek review in the relevant IETF working group or offer the opportunity for review on the working group mailing list.
候補パフォーマンスメトリックレジストリエントリの著者は、関連するIETFワーキンググループでレビューを求めるか、ワーキンググループのメーリングリストでのレビューの機会を提供することが望ましいです。
Requests to add Registered Performance Metrics in the Performance Metrics Registry SHALL be submitted to IANA, which forwards the request to a designated group of experts (Performance Metrics Experts) appointed by the IESG; these are the reviewers called for by the Specification Required policy [RFC8126] defined for the Performance Metrics Registry. The Performance Metrics Experts review the request for such things as compliance with this document, compliance with other applicable Performance Metrics-related RFCs, and consistency with the currently defined set of Registered Performance Metrics. The most efficient path for submission begins with preparation of an Internet-Draft containing the proposed Performance Metrics Registry Entry using the template in Section 11, so that the submission formatting will benefit from the normal IETF Internet-Draft submission processing (including HTMLization).
パフォーマンスメトリックレジストリに登録されたパフォーマンスメトリックを追加する要求IESGによって指定された専門家の専門家のグループに要求を転送するIANAに提出されなければならない。これらは、Performance Metricsレジストリに定義されている仕様必須ポリシー[RFC8126]によって呼び出されるレビュー担当者です。Performance Metrics Expertsは、この文書のコンプライアンス、他の適用可能なパフォーマンスメトリック関連のRFC、現在定義されている登録パフォーマンスメトリックの一貫性との遵守などの要求を確認します。提出のための最も効率的なパスは、セクション11のテンプレートを使用して提案されたパフォーマンスメトリックレジストリエントリを含むインターネットドラフトの準備から始まります。
Submission to IANA may be during IESG review (leading to IETF Standards Action), where an Internet-Draft proposes one or more Registered Performance Metrics to be added to the Performance Metrics Registry, including the text of the proposed Registered Performance Metric(s).
IEANAへの投稿は、IESGレビュー中（IETF標準アクションをもたらします）、Internet-Draftは、提案された登録済みパフォーマンスメトリックのテキストを含むパフォーマンスメトリックレジストリに追加される1つ以上の登録パフォーマンスメトリックを提案します。
If an RFC-to-be includes a Performance Metric and a proposed Performance Metrics Registry Entry but the Performance Metrics Expert's review determines that one or more of the criteria listed in Section 5 have not been met, then the proposed Performance Metrics Registry Entry MUST be removed from the text. Once evidence exists that the Performance Metric meets the criteria in Section 5, the proposed Performance Metrics Registry Entry SHOULD be submitted to IANA to be evaluated in consultation with the Performance Metrics Experts for registration at that time.
Performance Metricと提案されたパフォーマンスメトリクスレジストリエントリが含まれているが、パフォーマンスメトリックエキスパートのレビューは、セクション5に記載されている1つ以上の基準が満たされていないと判断した場合、提案されたパフォーマンスメトリックレジストリエントリはテキストから削除されました。パフォーマンスメトリックがセクション5の基準を満たす証拠が存在すると、提案されたパフォーマンスメトリックレジストリエントリは、その時点での登録のパフォーマンスメトリック専門家と協議して評価されるようにIANAに提出されるべきです。
Authors of proposed Registered Performance Metrics SHOULD review compliance with the specifications in this document to check their submissions before sending them to IANA.
提案された登録業績メトリックの著者は、この文書の仕様への準拠を見直して、それらをIANAに送信する前に彼らの提出をチェックする必要があります。
At least one Performance Metrics Expert should endeavor to complete referred reviews in a timely manner. If the request is acceptable, the Performance Metrics Experts signify their approval to IANA, and IANA updates the Performance Metrics Registry. If the request is not acceptable, the Performance Metrics Experts MAY coordinate with the requester to change the request so that it is compliant; otherwise, IANA SHALL coordinate resolution of issues on behalf of the expert. The Performance Metrics Experts MAY choose to reject clearly frivolous or inappropriate change requests outright, but such exceptional circumstances should be rare.
少なくとも1つのパフォーマンスメトリックエキスパートはタイムリーに紹介されたレビューを完了するように努力してください。要求が許容できる場合、パフォーマンスメトリック専門家はIANAへの承認を表し、IANAはPerformance Metricsレジストリを更新します。要求が受け入れられない場合、パフォーマンスメトリック専門家は要求者と協調して要求を変更して準拠している可能性があります。それ以外の場合、IANAは専門家に代わって問題の解決を調整するものとします。パフォーマンス指標の専門家は、明確に軽量なまたは不適切な変更要求を完全に拒否することを選択できますが、そのような例外的な状況はまれです。
If the proposed Metric is unique in a significant way, in order to properly describe the Metric, it may be necessary to propose a new Name Element Registry, or (more likely) a new Entry in an existing Name Element Registry. This proposal is part of the request for the new Metric, so that it undergoes the same IANA review and approval process.
提案されたメトリックが重要な方法で一意である場合は、メトリックを正しく説明するために、新しいネーム要素レジストリを提案すること、または（より可能性が高い）既存のネーム要素レジストリに新しいエントリを提案する必要があるかもしれません。この提案は、新しいメトリックの要求の一部であり、それは同じIANAのレビューと承認プロセスを受けます。
Decisions by the Performance Metrics Experts may be appealed per Section 10 of [RFC8126].
パフォーマンスメトリック専門家による決定は、[RFC8126]のセクション10ごとに上訴される可能性があります。
A request for revision is only permitted when the requested changes maintain backward compatibility with implementations of the prior Performance Metrics Registry Entry describing a Registered Performance Metric (entries with lower revision numbers but having the same Identifier and Name).
リビジョンの要求は、要求された変更が、登録されたパフォーマンスメトリックを記述する従来のパフォーマンスメトリックレジストリエントリの実装との下位互換性を維持した場合にのみ許可されます（リビジョン番号が小さいが、同じ識別子と名前を持つエントリ）。
The purpose of the Status field in the Performance Metrics Registry is to indicate whether the entry for a Registered Performance Metric is 'Current', 'Deprecated', or 'Obsolete'. The term 'deprecated' is used when an entry is replaced, either with a backwards-compatible revision (this sub-section) or with a non-backwards-compatible revision (in Section 8.3).
Performance Metricsレジストリのステータスフィールドの目的は、登録されたパフォーマンスメトリックのエントリが「current」、「廃止予定」、または「廃止された」かを示すことです。「廃止予定」という用語は、エントリが後方互換性のあるリビジョン（このサブセクション）または後方互換性のないリビジョンで（セクション8.3）のいずれかで置き換えられるときに使用されます。
In addition, no policy is defined for revising the Performance Metric Entries in the IANA Registry or addressing errors therein. To be clear, changes and deprecations within the Performance Metrics Registry are not encouraged and should be avoided to the extent possible. However, in recognition that change is inevitable, the provisions of this section address the need for revisions.
さらに、IANAレジストリ内のパフォーマンスメトリックエントリを修正するためのポリシーは定義されていません。クリアするために、パフォーマンスメトリックレジストリ内の変更と廃止は奨励されず、可能な限り回避されるべきです。ただし、変更が避けられないという認識では、このセクションの規定は修正の必要性に対処しています。
Revisions are initiated by sending a candidate Registered Performance Metric definition to IANA, per Section 8.1, identifying the existing Performance Metrics Registry Entry, and explaining how and why the existing entry should be revised.
リビジョンは、セクション8.1ごとに候補登録済みパフォーマンスメトリック定義をIANAに送信し、既存のパフォーマンスメトリックレジストリエントリを識別し、既存のエントリを修正する方法とその理由を説明することによって開始されます。
The primary requirement in the definition of procedures for managing changes to existing Registered Performance Metrics is avoidance of measurement interoperability problems; the Performance Metrics Experts must work to maintain interoperability above all else. Changes to Registered Performance Metrics may only be done in an interoperable way; necessary changes that cannot be done in a way that allows interoperability with unchanged implementations MUST result in the creation of a new Registered Performance Metric (with a new Name, replacing the RFCXXXXsecY portion of the Name) and possibly the deprecation of the earlier metric.
既存の登録業績メトリックへの変更を管理するための手順の定義の主な要件は、測定相互運用性の問題を回避することです。パフォーマンスメトリック専門家は、他のすべてのものより上の相互運用性を維持するために働かなければなりません。登録されたパフォーマンスメトリックへの変更は相互運用可能な方法でのみ行われます。変更されていない実装との相互運用性を可能にする方法では実行できない変更は、新しい登録済みパフォーマンスメトリックの作成（新しい名前を持つ、名前のRFCxxxxsecy部分を置き換えます）、そしておそらく以前のメトリックの非推奨になる必要があります。
A change to a Registered Performance Metric SHALL be determined to be backward compatible when:
登録されたパフォーマンスメトリックへの変更は、次の場合に下位互換性があると判断されます。
1. it involves the correction of an error that is obviously only editorial, or
1. それは明らかに編集のみであるエラーの修正を含みます。
2. it corrects an ambiguity in the Registered Performance Metric's definition, which itself leads to issues severe enough to prevent the Registered Performance Metric's usage as originally defined, or
2. 登録されたパフォーマンスメトリックの定義のあいまいさを修正し、それ自体が最初に定義されたように登録されたパフォーマンスメトリックの使用量を防ぐのに十分な深刻な問題につながる。
3. it corrects missing information in the metric definition without changing its meaning (e.g., the explicit definition of 'quantity' semantics for numeric fields without a Data Type Semantics value), or
3. 意味を変更せずにメトリック定義内の欠落している情報を修正します（例えば、データ型セマンティクス値のない数量フィールドの「数量」セマンティクスの明示的な定義）、または
4. it harmonizes with an external reference that was itself corrected, or
4. それ自体が修正された外部参照と調和します。
5. if the current Registry format has been revised by adding a new column that is not relevant to an existing Registered Performance Metric (i.e., the new column can be safely filled in with "Not Applicable").
5. 既存の登録済みパフォーマンスメトリックに関連しない新しい列を追加して現在のレジストリフォーマットが修正されている場合（すなわち、新しい列は「該当なしで安全に埋めることができます」）。
If a Performance Metric revision is deemed permissible and backward compatible by the Performance Metrics Experts, according to the rules in this document, IANA SHOULD execute the change(s) in the Performance Metrics Registry. The requester of the change is appended to the original requester in the Performance Metrics Registry. The Name of the revised Registered Performance Metric, including the RFCXXXXsecY portion of the Name, SHALL remain unchanged even when the change is the result of IETF Standards Action. The revised Registry Entry SHOULD reference the new immutable document, such as an RFC. 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.
パフォーマンスメトリックリビジョンがパフォーマンスメトリック専門家によって許可され逆方向に互換性があると見なされる場合、このドキュメントの規則に従って、IANAはPerformance Metricsレジストリの変更を実行する必要があります。変更の要求者は、Performance Metricsレジストリの元の要求者に追加されます。rfcxxxxcy部分を含む改訂された登録済みパフォーマンスメトリックの名前は、変更がIETF標準アクションの結果であっても変更されません。改訂されたレジストリエントリは、RFCなどの新しい不変文書を参照する必要があります。他の標準機関では、適切なカテゴリと列の指定の特定の日付バージョンを参照する必要がある可能性があります。
Each Registered Performance Metric in the Performance Metrics Registry has a revision number, starting at zero. Each change to a Registered Performance Metric following this process increments the revision number by one.
Performance Metricsレジストリの各登録済みパフォーマンスメトリックには、ゼロから始まるリビジョン番号があります。このプロセスに従って、登録されたパフォーマンスメトリックへの各変更は、リビジョン番号を1つずつ増加させます。
When a revised Registered Performance Metric is accepted into the Performance Metrics Registry, the date of acceptance of the most recent revision is placed into the Revision Date column of the Registry for that Registered Performance Metric.
登録された登録業績メトリックがパフォーマンスメトリックレジストリに受け入れられると、最新のリビジョンの受付日がその登録済みパフォーマンスメトリックのレジストリのリビジョン日列に配置されます。
Where applicable, additions to Registered Performance Metrics in the form of text in the Comments or Remarks column should include the date, but such additions may not constitute a revision according to this process.
該当する場合は、コメントまたは備考欄にテキストの形で登録されたパフォーマンスメトリックへの追加は日付を含めるべきであるが、このプロセスによれば、そのような追加は修正を構成することはないかもしれない。
Older versions of the updated Metric Entries are kept in the Registry for archival purposes. The older entries are kept with all fields unmodified (including Revision Date) except for the Status field, which SHALL be changed to 'Deprecated'.
更新されたメトリックエントリの古いバージョンは、アーカイブ目的のためにレジストリに保存されます。古いエントリは、ステータスフィールドを除いて、変更されていないすべてのフィールド（改訂日を含む）で保持されます。これは「非推奨」に変更されます。
This process should not in any way be construed as allowing the Performance Metrics Experts to overrule IETF consensus. Specifically, any Registered Performance Metrics that were added to the Performance Metrics Registry with IETF consensus require IETF consensus for revision or deprecation.
このプロセスは、Performance Metricsの専門家がIETFコンセンサスを過剰にすることを可能にすると解釈されるべきではありません。具体的には、IETFコンセンサスとPerformance Metricsレジストリに追加された登録されたパフォーマンスメトリックでは、リビジョンまたは廃止のためにIETFコンセンサスが必要です。
8.3. Non-Backward-Compatible Deprecation of Registered Performance Metrics
8.3. 登録済みパフォーマンスメトリックの非下位互換性の非推奨
This section describes how to make a non-backward-compatible update to a Registered Performance Metric. A Registered Performance Metric MAY be deprecated and replaced when:
このセクションでは、登録済みパフォーマンスメトリックに非バックアップ対応の更新方法を説明します。登録されたパフォーマンスメトリックは、次の場合に推奨されて置き換えられます。
1. the Registered Performance Metric definition has an error or shortcoming that cannot be permissibly changed per Section 8.2 ("Revising Registered Performance Metrics"), or
1. 登録されているパフォーマンスメトリック定義には、セクション8.2（登録済みパフォーマンスメトリックの修正）ごとに許可できるほど変更できないエラーまたは欠点があります。
2. the deprecation harmonizes with an external reference that was itself deprecated through that reference's accepted deprecation method.
2. 廃止予定は、その参照の認められている廃止法を通じてそれ自体が推奨されていない外部参照と調和します。
A request for deprecation is sent to IANA, which passes it to the Performance Metrics Experts for review. When deprecating a Performance Metric, the Performance Metric Description in the Performance Metrics Registry MUST be updated to explain the deprecation, as well as to refer to the new Performance Metric created to replace the deprecated Performance Metric.
償却要求はIANAに送信され、それはレビューのためにパフォーマンスメトリックの専門家に渡されます。パフォーマンスメトリックを非推奨する場合、パフォーマンスメトリックレジストリのパフォーマンスメトリックの説明は、非推奨を説明するように更新され、廃止予定のパフォーマンスメトリックを置き換えるために作成された新しいパフォーマンスメトリックを参照する必要があります。
When a new, non-backward-compatible Performance Metric replaces a (now) deprecated metric, the revision number of the new Registered Performance Metric is incremented over the value in the deprecated version, and the current date is entered as the Revision Date of the new Registered Performance Metric.
新しい非互換性のあるパフォーマンスメトリックを（現在）非推奨メトリックを置き換えると、新しい登録済みパフォーマンスメトリックのリビジョン番号が廃止予定バージョンの値を超えて増加し、現在の日付が変更日として入力されます。新しい登録業績メトリック
The intentional use of deprecated Registered Performance Metrics should result in a log entry or human-readable warning by the respective application.
廃止予定の登録業績メトリックの意図的な使用は、それぞれのアプリケーションによってログエントリまたは人間が読める警告を起こすべきである。
Names and Metric IDs of deprecated Registered Performance Metrics must not be reused.
非推奨の登録済みパフォーマンスメトリックの名前とメトリックIDは再利用してはいけません。
The deprecated entries are kept with all Administrative columns unmodified, except the Status field (which is changed to 'Deprecated').
廃止予定のエントリは、ステータスフィールドを除いて、変更されていないすべての管理列に保持されます（これは「非推奨」に変更されます）。
Existing Registry Entries may become obsolete over time due to:
既存のレジストリエントリは、次のために時間の経過とともに廃止される可能性があります。
1. the Registered Performance Metric is found to contain considerable errors (and no one sees the value in the effort to fix it), or
1. 登録されているパフォーマンスメトリックはかなりのエラーを含むことがわかります（そして、誰もそれを修正するための努力には価値が見えない）、または
2. one or more critical References (or sections thereof) have been designated obsolete by the SDO, or
2. 1つ以上の重要な参照（またはそのセクション）は、SDOによって時代遅れに指定されています。
3. other reasons brought to the attention of IANA and the Registry Experts.
3. IANAとレジストリの専門家の注目を集めるその他の理由。
When a Performance Metric Registry Entry is declared obsolete, the Performance Metric Description in the Performance Metrics Registry is updated to explain the reasons the Entry is now obsolete and has not been replaced (Deprecation always involves replacement).
Performance Metric Registryエントリが廃棄されると、Performance Metrics Registryのパフォーマンスメトリックの説明が更新され、エントリが廃止され、置き換えられていない理由が更新されます（非推奨は常に交換を含みます）。
Obsolete entries are kept with all Administrative columns unmodified, except the Status field (which is changed to 'Obsolete').
廃止されたエントリは、ステータスフィールドを除いて、変更されていないすべての管理列に保存されます（これは「廃止」に変更されます）。
The Registry Format Version defined in this memo is 1.0, and candidate Registry Entries complying with this memo MUST use 1.0.
このメモに定義されているレジストリフォーマットのバージョンは1.0、およびこのメモに準拠した候補レジストリエントリは1.0を使用する必要があります。
The Registry Format can only be updated by publishing a new RFC with the new format (Standards Action).
レジストリフォーマットは、新しいRFCを新しいフォーマット（標準アクション）で公開することによってのみ更新できます。
When a Registered Performance Metric is created or revised, then it uses the most recent Registry Format Version.
登録されたパフォーマンスメトリックが作成または修正されると、最新のレジストリフォーマットのバージョンが使用されます。
Only one form of Registry extension is envisaged:
1つの形式のレジストリ拡張のみが考えられます。
Adding columns, or both categories and columns, to accommodate unanticipated aspects of new measurements and metric categories.
新しい測定値とメトリックカテゴリの予期しない側面に対応するために、列、またはカテゴリと列の両方を追加します。
If the Performance Metrics Registry is extended in this way, the version number of future entries complying with the extension SHALL be incremented (in either the unit or the tenths digit, depending on the degree of extension).
パフォーマンスメトリックレジストリがこのように拡張されている場合、拡張子に準拠した将来のエントリのバージョン番号は増加します（拡張程度によっては、単位または10分の1桁のいずれかで）。
This document defines a Registry structure and does not itself introduce any new security considerations for the Internet. The definition of Performance Metrics for this Registry may introduce some security concerns, but the mandatory references should have their own considerations for security, and such definitions should be reviewed with security in mind if the security considerations are not covered by one or more reference standards.
この文書はレジストリ構造を定義し、それ自体がインターネットのための新しいセキュリティ上の考慮を紹介しません。このレジストリのパフォーマンスメトリックの定義はいくつかのセキュリティ上の関心事を導入する可能性がありますが、必須の参考文献はセキュリティに関する独自の考慮事項を持ち、セキュリティ上の考慮事項が1つ以上の参照標準でカバーされていない場合は、セキュリティで検討する必要があります。
The aggregated results of the Performance Metrics described in this Registry might reveal network topology information that may be considered sensitive. If such cases are found, then access control mechanisms should be applied.
このレジストリに記載されているパフォーマンスメトリックの集約結果は、敏感に見える可能性があるネットワークトポロジ情報を明らかにするかもしれません。そのような場合が見つかった場合は、アクセス制御メカニズムを適用する必要があります。
With the background and processes described in earlier sections, IANA has taken the actions described below.
以前のセクションで説明されている背景やプロセスで、IANAは以下の動作を実行しました。
The new Registry group is named Performance Metrics. This document refers to it as the "Performance Metrics Group" or "Registry Group", meaning all registrations appearing on <https://www.iana.org/assignments/performance-metrics> (https://www.iana.org/assignments/performance-metrics).
新しいレジストリグループはPerformance Metricsという名前です。この文書とは、「パフォーマンスメトリックグループ」または「レジストリグループ」として、<https：//www.iana.org/assignments/performance-metrics>（https://www.iana.org）に表示されます。/割り当て/パフォーマンスメトリック）。
For clarity, note that this document and [RFC8912] use the following conventions to refer to the various IANA registries related to Performance Metrics.
明確にするために、このドキュメントと[RFC8912]は、パフォーマンスメトリックに関するさまざまなIANAレジストリを参照するために、次の規則を使用しています。
+===============+===========================+=====================+
| | RFC 8911 and RFC 8912 | IANA Web page |
+===============+===========================+=====================+
| Page Title | Performance Metrics Group | Performance Metrics |
+---------------+---------------------------+---------------------+
| Main Registry | Performance Metrics | Performance Metrics |
| | Registry | Registry |
+---------------+---------------------------+---------------------+
| Registry Row | Performance Metrics | registration (also |
| | Registry Entry | template) |
+---------------+---------------------------+---------------------+
Table 6
表6.
Registration Procedure: Specification Required
登録手順：指定が必要です
Reference: RFC 8911
参照：RFC 8911
Experts: Performance Metrics Experts
専門家：パフォーマンスメトリクス専門家
This memo specifies and populates the Registries for the Performance Metric Name Elements. The Name assigned to a Performance Metric Registry Entry consists of multiple Elements separated by an "_" (underscore), in the order defined in Section 7.1.2. IANA has created the following registries, which contain the current set of possibilities for each Element in the Performance Metric Name.
このメモは、パフォーマンスメトリック名要素のレジストリを指定して入力します。パフォーマンスメトリックレジストリエントリに割り当てられている名前は、セクション7.1.2で定義されている順序で、 "_"（アンダースコア）で区切られた複数の要素で構成されています。IANAは次のレジストリを作成しました。これには、パフォーマンスメトリック名の各要素の現在の可能性のセットが含まれています。
MetricType
メトリクタイプ
Method
方法
SubTypeMethod
サブタイプメソッド
Spec
仕様
Units
単位
Output
出力
At creation, IANA has populated the Registered Performance Metrics Name Elements using the lists of values for each Name Element listed in Section 7.1.2. The Name Elements in each Registry are case sensitive.
作成時に、IANAはセクション7.1.2にリストされている各ネーム要素の値のリストを使用して、登録されたパフォーマンスメトリック名要素を入力しました。各レジストリの名前要素は大文字と小文字が区別されます。
When preparing a Metric Entry for registration, the developer SHOULD choose Name Elements from among the registered elements. However, if the proposed metric is unique in a significant way, it may be necessary to propose a new Name Element to properly describe the metric, as described below.
登録用のメトリックエントリを準備するとき、開発者は登録された要素の中から名前要素を選択する必要があります。しかしながら、提案されたメトリックが重要な方法で一意である場合、以下に説明するように、メトリックを適切に記述するために新しいネーム要素を提案する必要があるかもしれない。
A candidate Metric Entry proposes a set of values for its Name Elements. These are reviewed by IANA and an Expert Reviewer. It is possible that a candidate Metric Entry proposes a new value for a Name Element (that is, one that is not in the existing list of possibilities), or even that it proposes a new Name Element. Such new assignments are administered by IANA through the Specification Required policy [RFC8126], which includes Expert Review (i.e., review by one of a group of Performance Metrics Experts, who are appointed by the IESG upon recommendation of the Transport Area Directors).
候補メトリックエントリは、その名前要素の値のセットを提案します。これらはIANAと専門家の査読者によって見直されています。候補メトリックエントリは、Name要素（つまり、既存の可能な可能性のリストにはないもの）の新しい値を提案すること、あるいは新しい名前要素を提案することさえ可能です。そのような新しい課題は、専門家レビューを含む仕様必要なポリシー[RFC8126]を通じてIANAによって管理されています。
This document specifies the Performance Metrics Registry. The Registry contains the following columns in the Summary category:
このドキュメントはパフォーマンスメトリックレジストリを指定します。レジストリには、サマリーカテゴリの次の列が含まれています。
Identifier
識別子
Name
名前
URI
u u
Description
説明
Reference
リファレンス
Change Controller
コントローラを変更する
Version
バージョン
Descriptions of these columns and additional information found in the template for Registry Entries (categories and columns) are further defined in Section 7.
これらの列の説明とレジストリエントリのテンプレート（カテゴリと列）にある追加情報は、セクション7でさらに定義されています。
The Identifier 0 should be Reserved. The Registered Performance Metric unique Identifier is an unbounded integer (range 0 to infinity). The Identifier values from 64512 to 65535 are reserved for private or experimental use, and the user may encounter overlapping uses. When adding new Registered Performance Metrics to the Performance Metrics Registry, IANA SHOULD assign the lowest available Identifier to the new Registered Performance Metric. If a Performance Metrics Expert providing review determines that there is a reason to assign a specific numeric Identifier, possibly leaving a temporary gap in the numbering, then the Performance Metrics Expert SHALL inform IANA of this decision.
識別子0は予約されるべきです。登録されたパフォーマンスメトリック固有IDは、無制限の整数（無限大の範囲）です。64512から65535の識別子値は、プライベートまたは実験的な使用のために予約されており、ユーザーは重複する使用に遭遇する可能性があります。Performance Metricsレジストリに新しい登録されたパフォーマンスメトリックを追加する場合、IANAは使用可能な最小の識別子を新しい登録済みパフォーマンスメトリックに割り当てる必要があります。パフォーマンスメトリクスエキスパートレビューでは、特定の数値識別子を割り当てる理由があると判断した場合、標識に一時的なギャップを残すと、パフォーマンスメトリックエキスパートはこの決定のIANAに通知するものとします。
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 7.
プレフィックス "priv_"で始まる名前は、プライベート使用のために予約されており、登録のために考慮されません。名前列エントリはセクション7でさらに定義されています。
The URI column will have a URL to each completed Registry Entry. The Registry Entry text SHALL be HTMLized to aid the reader (similar to the way that Internet-Drafts are HTMLized, the same tool can perform the function), with links to referenced section(s) of an RFC or another immutable document.
URI列には、完了した各レジストリエントリへのURLがあります。レジストリエントリテキストは、（インターネットドラフトがhtmlizedの方法と同様に、同じツールが機能を実行でき、同じツールが機能を実行する方法と同様に）、RFCまたは別の不変文書の参照セクションへのリンクを使用します。
The Reference column will include an RFC number, an approved specification designator from another standards body, or some other immutable document.
参照列には、RFC番号、別の標準の本体からの承認された仕様指定子、またはその他の不変文書が含まれます。
New assignments for the Performance Metrics Registry will be administered by IANA through the Specification Required policy [RFC8126] (which includes Expert Review, i.e., review by one of a group of experts -- in the case of this document, the Performance Metrics Experts, who are appointed by the IESG upon recommendation of the Transport Area Directors) or by Standards Action. The experts can be initially drawn from the Working Group Chairs, document editors, and members of the Performance Metrics Directorate, among other sources of experts.
Performance Metrics Registryの新しい割り当ては、指定されたポリシー[RFC8126]（専門家のレビュー、すなわち、専門家のグループの1つによるレビュー、パフォーマンス指標の専門家、専門家のグループの1つによるレビュー）を通じて管理されます。輸送場取締役の勧告または標準行動によるIESGによって任命されている人。専門家は、最初に、実用的な専門家の原因で、作業グループの議長、ドキュメントエディタ、およびパフォーマンス指標のメンバーから描かれています。
Extensions to the Performance Metrics Registry require IETF Standards Action. Only one form of Registry extension is envisaged:
Performance Metricsレジストリへの拡張には、IETF標準アクションが必要です。1つの形式のレジストリ拡張のみが考えられます。
* Adding columns, or both categories and columns, to accommodate unanticipated aspects of new measurements and metric categories.
* 新しい測定値とメトリックカテゴリの予期しない側面に対応するために、列、またはカテゴリと列の両方を追加します。
If the Performance Metrics Registry is extended in this way, the version number of future entries complying with the extension SHALL be incremented (in either the unit or the tenths digit, depending on the degree of extension).
パフォーマンスメトリックレジストリがこのように拡張されている場合、拡張子に準拠した将来のエントリのバージョン番号は増加します（拡張程度によっては、単位または10分の1桁のいずれかで）。
This section provides a blank template to help IANA and Registry Entry writers.
このセクションでは、IANAおよびレジストリエントリ作成者を支援するための空白のテンプレートを提供します。
This category includes multiple indexes to the Registry Entry: the element ID and Metric Name.
このカテゴリには、レジストリエントリへの複数のインデックスが含まれています。要素IDとメトリック名。
<insert a numeric Identifier, an integer, TBD>
<数値識別子を挿入、整数、TBD>
<insert the Name, according to the metric naming convention>
<メトリックネーミング条約に従って、名前を挿入する>
URL: https://www.iana.org/assignments/performance-metrics/ ... <Name>
<provide a description>
<説明を提供する>
<provide the RFC or other specification that contains the approved candidate Registry Entry>
<承認された候補レジストリエントリを含むRFCまたはその他の仕様を提供する>
<provide information regarding the entity responsible for approving revisions to the Registry Entry (including contact information for an individual, where appropriate)>
<レジストリエントリへのリビジョンの承認を担当するエンティティに関する情報（必要に応じて個人の連絡先情報を含む）を提供します。
This category includes columns to prompt the entry of all necessary details related to the metric definition, including the immutable document reference and values of input factors, called "Fixed Parameters".
このカテゴリには、「固定パラメータ」と呼ばれる、不変文書参照と入力因子の値を含む、メトリック定義に関連するすべての必要な詳細のエントリを促す列が含まれています。
<provide a full bibliographic reference to an immutable document>
<不変文書への完全書誌参照を提供する>
<provide a specific section reference and additional clarifications, if needed>
<必要に応じて、特定のセクションの参照と追加の説明を提供します。
<list and specify Fixed Parameters, input factors that must be determined and embedded in the measurement system for use when needed>
<固定パラメータの一覧と指定、必要なときに使用するために測定システムに決定され埋め込まれなければならない入力ファクタ
This category includes columns for references to relevant sections of the immutable document(s) and any supplemental information needed to ensure an unambiguous method for implementations.
このカテゴリには、不変文書の関連セクションへの参照の列と、実装の明確な方法を確保するために必要な補足情報が含まれています。
<for the metric, insert relevant section references and supplemental info>
<メトリックの場合、関連するセクションの参照と補足情報>
<provide a list of generation Parameters and section/spec references if needed>
<必要に応じて生成パラメータとセクション/ SPEC参照のリストを提供する>
This category provides the filter details (when present), which qualify the set of packets that contribute to the measured results from among all packets observed.
このカテゴリには、フィルタの詳細（存在する場合）があります。これは、観測されたすべてのパケットの中から測定結果に寄与するパケットのセットを修飾します。
<provide a section reference>
<セクション参考文献を提供する>
<insert time distribution details, or how this is different from the filter>
<時間配布の詳細、またはこれがフィルタとどのように異なるか>
Runtime Parameters are input factors that must be determined, configured into the measurement system, and reported with the results for the context to be complete.
ランタイムパラメータは、測定システムに構成され、測定システムに構成され、完了するための結果を報告する必要ファクタです。
<provide a list of Runtime Parameters and their data formats>
<ランタイムパラメータとそのデータ形式のリストを提供する>
<list the names of the different Roles from the Measurement Method>
<測定方法から別の役割の名前をリストします>
This category specifies all details of the output of measurements using the metric.
このカテゴリは、メトリックを使用した測定値の出力の詳細を指定します。
<insert the name of the output type -- raw results or a selected summary statistic>
<出力タイプの名前 - 生の結果または選択した要約統計情報の名前を挿入します>
<describe the reference data format for each type of result>
<結果の種類の基準データ形式について説明します>
<insert units for the measured results, and provide the reference specification>
<測定結果の挿入単位を挿入し、参照仕様書を提供します>
<insert information on calibration>
<キャリブレーションに関する情報を挿入します
This category provides administrative information.
このカテゴリは管理情報を提供します。
<provide status: 'Current' or 'Deprecated'>
<provide a person's name, an RFC number, etc.>
<人の名前、RFC番号などを提供する>
<provide the revision number: starts at 0>
<provide the date, in YYYY-MM-DD format>
<日付をyyyy-mm-dd形式で提供する>
<list any additional (informational) details for this entry>
<このエントリの追加（情報）詳細をリストします>
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, <https://www.rfc-editor.org/info/rfc2026>.
[RFC2026] Bradner、S.、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、DOI 10.17487 / RFC2026、1996年10月、<https：//www.rfc-editor.org/info/rfc2026>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, <https://www.rfc-editor.org/info/rfc2330>.
[RFC2330] Paxson、V.、Almes、G.、MAHDAVI、J.、およびM Mathis、「IPパフォーマンスメトリックのためのフレームワーク」、RFC 2330、DOI 10.17487 / RFC2330、1998年5月、<https：//www.rfc-editor.org/info/rfc2330>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Field、R.、およびL.Masinter、 "Uniform Resource Identifier（URI）：汎用構文"、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：//www.rfc-editor.org/info/rfc3986>。
[RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance Metrics (IPPM): Spatial and Multicast", RFC 5644, DOI 10.17487/RFC5644, October 2009, <https://www.rfc-editor.org/info/rfc5644>.
[RFC5644] Stephan、E.、Liang、L.、およびA.モートン、「IPパフォーマンス測定基準（IPPM）：空間的およびマルチキャスト」、RFC 5644、DOI 10.17487 / RFC5644、2009年10月、<https：//www.rfc-editor.org/info/rfc5644>。
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, DOI 10.17487/RFC6390, October 2011, <https://www.rfc-editor.org/info/rfc6390>.
[RFC6390] Clark、A.およびB.Claise、「新しいパフォーマンスメトリック開発を検討するためのガイドライン」、BCP 170、RFC 6390、DOI 10.17487 / RFC6390、2011年10月、<https：//www.rfc-editor.org/info/ RFC6390>。
[RFC6576] Geib, R., Ed., Morton, A., Fardid, R., and A. Steinmitz, "IP Performance Metrics (IPPM) Standard Advancement Testing", BCP 176, RFC 6576, DOI 10.17487/RFC6576, March 2012, <https://www.rfc-editor.org/info/rfc6576>.
[RFC6576] Geib、R.、Ed。、Morton、A.、Fardid、R.およびA. Steinmitz、「IP性能測定基準（IPPM）標準前進テスト」、BCP 176、RFC 6576、DOI 10.17487 / RFC6576、3月2012、<https://www.rfc-editor.org/info/rfc6576>。
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC7799]モートン、A。、「能動的および受動的な測定基準と方法（インス間のハイブリッド型（ハイブリッドタイプおよびメソッド）、RFC 7799、DOI 10.17487 / RFC7799、2016年5月、<https：//www.rfc-editor.org/info/ RFC7799>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www.rfc-editor.org / info / rfc8126>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B.、RFC 2119キーワードの「大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999, <https://www.rfc-editor.org/info/rfc2681>.
[RFC2681] Almes、G.、KalidIndi、S.、およびM.Zekauskas、「IPPMの往復遅延測定基準」、RFC 2681、DOI 10.17487 / RFC2681、1999年9月、<https：//www.rfc-編集者.ORG / INFO / RFC2681>。
[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network performance measurement with periodic streams", RFC 3432, DOI 10.17487/RFC3432, November 2002, <https://www.rfc-editor.org/info/rfc3432>.
[RFC3432] Raisanen、V.、GroteFeld、G.、およびA.モートン、「定期的なストリームによるネットワーク性能測定」、RFC 3432、DOI 10.17487 / RFC3432、2002年11月、<https：//www.rfc-editor.org/ info / rfc3432>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R.、およびV. Jacobson、「RTP：リアルタイムアプリケーション用輸送プロトコル」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、<https://www.rfc-editor.org/info/rfc3550>。
[RFC3611] Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, DOI 10.17487/RFC3611, November 2003, <https://www.rfc-editor.org/info/rfc3611>.
[RFC3611] Friedman、T.、ED。、Caceres、R.、Ed。、A. Clark、Ed。、「RTP XR）」、RFC 3611、DOI 10.17487 / RFC3611、2003年11月、<https://www.rfc-editor.org/info/rfc3611>。
[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics Registry", BCP 108, RFC 4148, DOI 10.17487/RFC4148, August 2005, <https://www.rfc-editor.org/info/rfc4148>.
[RFC4148] Stephan、E.、 "IP Performance Metrics（IPPM）メトリクスレジストリ"、BCP 108、RFC 4148、DOI 10.17487 / RFC4148、2005年8月、<https：//www.rfc-editor.org/info/rfc4148>。
[RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A., Grossglauser, M., and J. Rexford, "A Framework for Packet Selection and Reporting", RFC 5474, DOI 10.17487/RFC5474, March 2009, <https://www.rfc-editor.org/info/rfc5474>.
[RFC5474] Duffield、N.、Ed。、Chiou、D.、Claise、B.、Greenberg、A.、Grossglauser、M.、J.Rexford、「パケット選択のためのフレームワーク」、RFC 5474、DOI10.17487 / RFC5474、2009年3月、<https：//www.rfc-editor.org/info/rfc5474>。
[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, DOI 10.17487/RFC5475, March 2009, <https://www.rfc-editor.org/info/rfc5475>.
[RFC5475] Zseby、T.、Molina、M.、Duffield、N.、Niccolini、S.、およびF. Raspall、「IPパケット選択用のサンプリング・フィルタリング技術」、RFC 5475、DOI 10.17487 / RFC5475、2009年3月、<https://www.rfc-editor.org/info/rfc5475>。
[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, DOI 10.17487/RFC5477, March 2009, <https://www.rfc-editor.org/info/rfc5477>.
[RFC5477] Dietz、T.、Claise、B.、Aitken、P.、Dressler、F.、およびG。Carle、RFC 5477、DOI 10.17487 / RFC5477、2009年3月、<HTTPS//www.rfc-editor.org/info/rfc5477>。
[RFC6035] Pendleton, A., Clark, A., Johnston, A., and H. Sinnreich, "Session Initiation Protocol Event Package for Voice Quality Reporting", RFC 6035, DOI 10.17487/RFC6035, November 2010, <https://www.rfc-editor.org/info/rfc6035>.
[RFC6035] Pendleton、A.、Clark、A.、Johnston、A.、およびH. Sinnreich、「音質報告用のセッション開始プロトコルイベントパッケージ」、RFC 6035、DOI 10.17487 / RFC6035、2010年11月、<https：//www.rfc-editor.org/info/rfc6035>。
[RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete", RFC 6248, DOI 10.17487/RFC6248, April 2011, <https://www.rfc-editor.org/info/rfc6248>.
[RFC6248]モートン、A。、「RFC 4148とIPパフォーマンスメトリック（IPPM）は、2011年4月、2011年4月、RFC 6248、DOI 10.17487 / RFC6248、<https://www.rfc-editor.org/情報/ RFC6248>。
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.
[RFC6991] Schoenwaelder、J.、Ed。、「共通ヤンデータ型」、RFC 6991、DOI 10.17487 / RFC6991、2013年7月、<https：//www.rfc-editor.org/info/rfc6991>。
[RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, September 2013, <https://www.rfc-editor.org/info/rfc7012>.
[RFC7012]クリーズ、B、ED。B. Trammell、ED。、「IPフロー情報の輸出（IPFIX）の情報モデル」、RFC 7012、DOI 10.17487 / RFC7012、2013年9月、<https：//www.rfc-editor.org/info/rfc7012>。
[RFC7014] D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow Selection Techniques", RFC 7014, DOI 10.17487/RFC7014, September 2013, <https://www.rfc-editor.org/info/rfc7014>.
[RFC7014] D'Antonio、S.、Zseby、T.、Henke、C、およびL. Peluso、 "Flow Selection Techniques"、RFC 7014、DOI 10.17487 / RFC7014、2013年9月、<https：//www.rfc-editor.org/info/rfc7014>。
[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, "A Framework for Large-Scale Measurement of Broadband Performance (LMAP)", RFC 7594, DOI 10.17487/RFC7594, September 2015, <https://www.rfc-editor.org/info/rfc7594>.
[RFC7594]イヤーディリー、P.、Morton、A。、Bagnulo、M.、Burbridge、T.、Aitken、P.、A. AKHTER、「ブロードバンド性能の大規模測定のためのフレームワーク（LMAP）」、RFC7594、DOI 10.17487 / RFC7594、2015年9月、<https://www.rfc-editor.org/info/rfc7594>。
[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2016, <https://www.rfc-editor.org/info/rfc7679>.
[RFC7679] Almes、G.、Kiristindi、S.、Zekauskas、M.、およびA.モートン、「IP性能メトリックの一方向遅延メトリック（IPPM）」、STD 81、RFC 7679、DOI 10.17487/ RFC7679、2016年1月、<https：//www.rfc-editor.org/info/rfc7679>。
[RFC8912] Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza, "Initial Performance Metrics Registry Entries", RFC 8912, DOI 10.17487/RFC8912, November 2021, <https://www.rfc-editor.org/info/rfc8912>.
[RFC8912]モートン、A.、Bagnulo、M.、Eardley、P.、およびK.D' Souza、「初期性能測定基準レジストリエントリー」、RFC 8912、DOI 10.17487 / RFC8912、2021年11月、<https：// www.rfc-editor.org / info / rfc8912>。
Acknowledgments
謝辞
Thanks to Brian Trammell and Bill Cerveny, IPPM co-chairs during the development of this memo, for leading several brainstorming sessions on this topic. Thanks to Barbara Stark 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 Baber for answering questions related to the presentation of the Registry and accessibility of the complete template via URL. Thanks to Roni Even for his review and suggestions to generalize the procedures. Thanks to all of the Area Directors for their reviews.
このメモの開発中のBrian TrammellとBill Cerveny、IPPM Co-Chairsに感謝します。Barbara StarkとJuergen Schoenwaelderの詳細なフィードバックと提案のおかげで。メートルメートル命名に関する提案については、Andrew McGregorに感謝します。URLを介した完全なテンプレートのプレゼンテーションに関連した質問に関連した質問に答えるために、彼女の初期のIANAレビューのためにMichelle CottonとAmanda Baberに感謝します。手順を一般化するための彼のレビューと提案のためでさえもRONIに感謝します。彼らのレビューのためにすべての地域取締役のおかげで。
Authors' Addresses
著者の住所
Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 28911 Leganes Madrid Spain
Marcelo Bagnulo Universidad Carlos Iii de Madrid AV。ユニバースID 30 28911 Leganes Madridスペイン
Phone: 34 91 6249500
Email: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es
Benoit Claise Huawei
Benoit Claise Huawei
Email: benoit.claise@huawei.com
Philip Eardley BT Adastral Park, Martlesham Heath Ipswich United Kingdom
Philip Eardley BT Adastral Park、Martlesham Heath Ipswichイギリス
Email: philip.eardley@bt.com
Al Morton AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 United States of America
Al Morton At＆T Labs 200 Laurel Avenue南Middletown、NJ 07748アメリカ合衆国
Email: acmorton@att.com
Aamer Akhter Consultant 118 Timber Hitch Cary, NC United States of America
Aamer Akhterコンサルタント118 Timber Hitch Cary、NCアメリカ合衆国
Email: aakhter@gmail.com