[要約] RFC 7013は、IPFIX情報要素の作成者とレビューアのためのガイドラインです。このRFCの目的は、IPFIX情報要素の作成とレビューのプロセスを支援し、標準化されたIPフロー情報のエクスポートを促進することです。
Internet Engineering Task Force (IETF) B. Trammell
Request for Comments: 7013 ETH Zurich
BCP: 184 B. Claise
Category: Best Current Practice Cisco Systems, Inc.
ISSN: 2070-1721 September 2013
Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements
IPフロー情報エクスポート（IPFIX）情報要素の作成者とレビュー担当者のためのガイドライン
Abstract
概要
This document provides guidelines for how to write definitions of new Information Elements for the IP Flow Information Export (IPFIX) protocol. It provides instructions on using the proper conventions for Information Elements to be registered in the IANA IPFIX Information Element registry, and provides guidelines for expert reviewers to evaluate new registrations.
このドキュメントでは、IPフロー情報エクスポート（IPFIX）プロトコルの新しい情報要素の定義を記述する方法に関するガイドラインを提供します。 IANA IPFIX情報要素レジストリに登録される情報要素の適切な規則を使用する手順と、専門家のレビュー担当者が新しい登録を評価するためのガイドラインを示します。
Status of This Memo
本文書の状態
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベストプラクティスを文書化したものです。
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 BCPs is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7013.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7013で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Intended Audience and Usage ................................3
1.2. Overview of Relevant IPFIX Documents .......................4
2. Terminology .....................................................4
3. How to Apply IPFIX ..............................................5
4. Defining New Information Elements ...............................6
4.1. Information Element Naming .................................7
4.2. Information Element Data Types .............................7
4.3. Information Element Numbering ..............................8
4.4. Ancillary Information Element Properties ...................9
4.5. Internal Structure in Information Elements .................9
4.6. Information Element Multiplicity ..........................10
4.7. Enumerated Values and Subregistries .......................11
4.8. Reversibility as per RFC 5103 .............................11
4.9. Avoiding Bad Ideas in Information Element Design ..........11
5. The Information Element Life Cycle .............................13
5.1. The Process for Review by the IE-DOCTORS ..................13
5.2. Revising Information Elements .............................14
5.3. Deprecating Information Elements ..........................15
6. When Not to Define New Information Elements ....................16
6.1. Maximizing Reuse of Existing Information Elements .........16
6.2. Applying Enterprise-Specific Information Elements .........18
7. Information Element Definition Checklist .......................18
8. Applying IPFIX to Non-Flow Applications ........................21
9. Writing Internet-Drafts for IPFIX Applications .................21
9.1. Example Information Element Definition ....................22
9.2. Defining Recommended Templates ............................22
10. A Textual Format for Specifying Information Elements
and Templates .................................................23
10.1. Information Element Specifiers ...........................24
10.2. Specifying Templates .....................................26
10.3. Specifying IPFIX Structured Data .........................27
11. Security Considerations .......................................27
12. Acknowledgments ...............................................28
13. References ....................................................29
13.1. Normative References .....................................29
13.2. Informative References ...................................29
Appendix A. Example Information Element Definitions ...............31
A.1. sipResponseStatus ..........................................31
A.2. duplicatePacketDeltaCount ..................................31
A.3. ambientTemperature .........................................32
This document provides guidelines for the definition of new IPFIX Information Elements beyond those currently in the IANA IPFIX Information Element Registry [IANA-IPFIX]. Given the self-describing nature of the data export format used by IPFIX, the definition of new Information Elements is often sufficient to allow the application of IPFIX to new network measurement and management use cases.
このドキュメントは、現在IANA IPFIX情報要素レジストリ[IANA-IPFIX]にあるものを超える新しいIPFIX情報要素の定義に関するガイドラインを提供します。 IPFIXによって使用されるデータエクスポート形式の自己記述的な性質を考えると、新しい情報要素の定義は、多くの場合、新しいネットワーク測定および管理のユースケースへのIPFIXの適用を可能にするのに十分です。
We intend this document to enable the application of IPFIX to new areas by experts in the IETF Working Group or Area Directorate, the IETF community, or organization external to the IETF, concerned with the technical details of the protocol or application to be measured or managed using IPFIX. This expansion occurs with the consultation of IPFIX experts informally called IE-DOCTORS. It provides guidelines both for those defining new Information Elements as well as the IE-DOCTORS reviewing them.
このドキュメントは、測定または管理されるプロトコルまたはアプリケーションの技術的な詳細に関係する、IETFワーキンググループまたはエリアディレクター、IETFコミュニティ、またはIETF外部の組織の専門家による新しいエリアへのIPFIXの適用を可能にすることを意図していますIPFIXを使用します。この拡張は、非公式にIE-DOCTORSと呼ばれるIPFIXの専門家との協議により行われます。新しい情報要素を定義するガイドラインと、それらをレビューするIE-DOCTORSのガイドラインを提供します。
This document essentially codifies two meta-guidelines: (1) "define new Information Elements that look like existing Information Elements" and (2) "don't define Information Elements unless you need to".
このドキュメントは基本的に、（1）「既存の情報要素のように見える新しい情報要素を定義する」と（2）「必要がない限り情報要素を定義しない」という2つのメタガイドラインを体系化しています。
This document is meant for two separate audiences. For those defining new Information Elements, it provides specifications and best practices to be used in deciding which Information Elements are necessary for a given existing or new application, instructions for writing the definitions for these Information Elements, and information on the supporting documentation required for the new application (up to and including the publication of one or more RFCs describing it). For the IPFIX experts appointed as IE-DOCTORS, and for IANA personnel changing the IANA IPFIX Information Element Registry [IANA-IPFIX], it defines a set of acceptance criteria against which these proposed Information Elements should be evaluated.
このドキュメントは、2人の対象読者を対象としています。新しい情報要素を定義する人のために、特定の既存または新しいアプリケーションに必要な情報要素を決定する際に使用する仕様とベストプラクティス、これらの情報要素の定義を記述するための手順、およびに必要なサポートドキュメントに関する情報を提供します。新しいアプリケーション（それを説明する1つ以上のRFCの公開まで）。 IE-DOCTORSとして任命されたIPFIXエキスパート、およびIANA IPFIX情報要素レジストリ[IANA-IPFIX]を変更するIANA担当者は、これらの提案された情報要素を評価する必要がある一連の承認基準を定義します。
This document is not intended to guide the extension of the IPFIX protocol itself, e.g., through new export mechanisms, data types, or the like; these activities should be pursued through the publication of Standards Track RFCs within the IPFIX Working Group.
このドキュメントは、たとえば新しいエクスポートメカニズムやデータタイプなどを通じて、IPFIXプロトコル自体の拡張をガイドすることを意図していません。これらの活動は、IPFIXワーキンググループ内のStandards Track RFCsの発行を通じて追求する必要があります。
This document, together with [RFC7012], defines the procedures for management of the IANA IPFIX Information Element Registry [IANA-IPFIX]. The practices outlined in this document are intended
このドキュメントは、[RFC7012]とともに、IANA IPFIX情報要素レジストリ[IANA-IPFIX]の管理手順を定義しています。このドキュメントで概説されているプラクティスは意図されています
to guide experts when reviewing additions or changes to the Information Elements in the registry under Expert Review (as defined in [RFC5226]).
（[RFC5226]で定義されているように）Expert Reviewでレジストリの情報要素への追加または変更をレビューするときにエキスパートをガイドする。
[RFC7011] defines the IPFIX protocol, the IPFIX-specific terminology used by this document, and the data type encodings for each of the data types supported by IPFIX.
[RFC7011]は、IPFIXプロトコル、このドキュメントで使用されるIPFIX固有の用語、およびIPFIXでサポートされる各データ型のデータ型エンコーディングを定義しています。
[RFC7012] defines the basis of the IPFIX Information Model, referring to [IANA-IPFIX] for the specific Information Element definitions. It states that new Information Elements may be added to the Information Model on the basis of Expert Review, delegates the appointment of experts to an IESG Area Director, and refers to this document for details on the extension process. This document is intended to further codify the best practices to be followed by these experts, in order to improve the efficiency of this process.
[RFC7012]はIPFIX情報モデルの基礎を定義し、特定の情報要素の定義については[IANA-IPFIX]を参照します。専門家レビューに基づいて新しい情報要素が情報モデルに追加される可能性があると述べ、専門家の選任をIESGエリアディレクターに委任し、拡張プロセスの詳細についてこのドキュメントを参照します。このドキュメントは、このプロセスの効率を向上させるために、これらの専門家が従うべきベストプラクティスをさらに体系化することを目的としています。
[RFC5103] defines a method for exporting bidirectional Flow information using IPFIX; this document should be followed when extending IPFIX to represent information about bidirectional network interactions in general. Additionally, new Information Elements should be annotated for their reversibility or lack thereof as per this document.
[RFC5103]は、IPFIXを使用して双方向フロー情報をエクスポートする方法を定義しています。 IPFIXを拡張して、一般的な双方向ネットワークの相互作用に関する情報を表す場合、このドキュメントに従う必要があります。さらに、このドキュメントに従って、新しい情報要素に可逆性またはその欠如について注釈を付ける必要があります。
[RFC5610] defines a method for exporting information about Information Elements inline within IPFIX. In doing so, it explicitly defines a set of restrictions, implied in [RFC7011] and [RFC7012], on the use of data types and semantic; these restrictions must be observed in the definition of new Information Elements, as in Section 4.4.
[RFC5610]は、IPFIX内でインラインで情報要素に関する情報をエクスポートする方法を定義しています。その際、[RFC7011]と[RFC7012]で暗示されている、データ型とセマンティックの使用に関する一連の制限を明示的に定義しています。セクション4.4のように、新しい情報要素の定義ではこれらの制限を遵守する必要があります。
Capitalized terms used in this document that are defined in the Terminology section of [RFC7011] are to be interpreted as defined there.
[RFC7011]の用語セクションで定義されている、このドキュメントで使用されている大文字の用語は、そこで定義されているものとして解釈されます。
An "application", as used in this document, refers to a candidate protocol, task, or domain to which IPFIX export, collection, and/or storage is applied. By this definition, the IPFIX applicability statement [RFC5472] defined the initial applications of IPFIX, and Packet Sampling (PSAMP) [RFC5476] was the first new IPFIX application after the publication of the IPFIX protocol itself.
このドキュメントで使用されている「アプリケーション」は、IPFIXのエクスポート、コレクション、ストレージが適用される候補のプロトコル、タスク、またはドメインを指します。この定義により、IPFIX適用性ステートメント[RFC5472]はIPFIXの初期アプリケーションを定義し、パケットサンプリング（PSAMP）[RFC5476]はIPFIXプロトコル自体の公開後の最初の新しいIPFIXアプリケーションでした。
"IANA IE registry", as used in this document, unless otherwise noted, refers to the IANA IPFIX Information Element Registry [IANA-IPFIX].
このドキュメントで使用されている「IANA IEレジストリ」は、特に明記されていない限り、IANA IPFIX情報要素レジストリ[IANA-IPFIX]を指します。
Though originally specified for the export of IP Flow information, the message format, template mechanism, and data model specified by IPFIX led to it being applicable to a wide variety of network management situations. In addition to Flow information export, for which it was designed, and packet information export as specified by PSAMP [RFC5476], any application with the following characteristics is a good candidate for an IPFIX application:
元々はIPフロー情報のエクスポート用に指定されていましたが、IPFIXによって指定されたメッセージフォーマット、テンプレートメカニズム、およびデータモデルにより、さまざまなネットワーク管理状況に適用できるようになりました。設計されたフロー情報のエクスポート、およびPSAMP [RFC5476]で指定されたパケット情報のエクスポートに加えて、次の特性を持つすべてのアプリケーションがIPFIXアプリケーションの良い候補です。
o The application's data Flow is fundamentally unidirectional. IPFIX is a "push" protocol, supporting only the export of information from a sender (an Exporting Process) to a receiver (a Collecting Process). Request-response interactions are not supported by IPFIX.
o アプリケーションのデータフローは基本的に単方向です。 IPFIXは「プッシュ」プロトコルであり、送信者（エクスポートプロセス）から受信者（収集プロセス）への情報のエクスポートのみをサポートします。要求と応答の相互作用は、IPFIXではサポートされていません。
o The application handles discrete event information, or information to be periodically reported. IPFIX is particularly well suited to representing events, which can be scoped in time.
o アプリケーションは、個別のイベント情報、または定期的に報告される情報を処理します。 IPFIXは、時間範囲を指定できるイベントを表すのに特に適しています。
o The application handles information about network entities. IPFIX's information model is network-oriented, so network management applications have many opportunities for information model reuse.
o アプリケーションは、ネットワークエンティティに関する情報を処理します。 IPFIXの情報モデルはネットワーク指向であるため、ネットワーク管理アプリケーションには、情報モデルを再利用する多くの機会があります。
o The application requires a small number of arrangements of data structures relative to the number of records it handles. The template-driven self-description mechanism used by IPFIX excels at handling large volumes of identically structured data, compared to representations that define structure inline with data (such as XML).
o アプリケーションでは、処理するレコードの数に比べて、データ構造の配置が少数で済みます。 IPFIXで使用されるテンプレート駆動型の自己記述メカニズムは、データ（XMLなど）とインラインで構造を定義する表現と比較して、同一構造の大量のデータの処理に優れています。
Most applications meeting these criteria can be supported over IPFIX. Once it has been determined that IPFIX is a good fit, the next step is determining which Information Elements are necessary to represent the information required by the application. Especially for network-centric applications, the IANA IE registry may already contain all the necessary Information Elements (see Section 6.1 for guidelines on maximizing Information Element reuse). In this case, no work within the IETF is necessary: simply define Templates and start exporting.
これらの条件を満たすほとんどのアプリケーションは、IPFIXでサポートできます。 IPFIXが適切であると判断されたら、次のステップは、アプリケーションが必要とする情報を表すために必要な情報要素を決定することです。特にネットワーク中心のアプリケーションでは、IANA IEレジストリに必要な情報要素がすべて含まれている場合があります（情報要素の再利用を最大化するためのガイドラインについては、セクション6.1を参照してください）。この場合、IETF内での作業は不要です。テンプレートを定義してエクスポートを開始するだけです。
It is expected, however, that most applications will be able to reuse some existing Information Elements, but may need to define some additional Information Elements to support all their requirements. In this case, see Section 4 for best practices to be followed in defining Information Elements.
ただし、ほとんどのアプリケーションは一部の既存の情報要素を再利用できると予想されますが、すべての要件をサポートするために追加の情報要素を定義する必要がある場合があります。この場合、情報要素の定義で従うべきベストプラクティスについては、セクション4を参照してください。
Optionally, a Working Group or individual contributor may choose to write an Internet-Draft for publication as an RFC, detailing the new IPFIX application. Such an RFC should contain discussion of the new application, the Information Element definitions as in Section 4, as well as suggested Templates and examples of the use of those Templates within the new application as in Section 9.2. Section 10 defines a compact textual Information Element notation to be used in describing these suggested Templates and/or the use of IPFIX Structured Data [RFC6313] within the new application.
必要に応じて、ワーキンググループまたは個々の寄稿者は、新しいIPFIXアプリケーションの詳細を説明するRFCとして公開するために、インターネットドラフトを作成することを選択できます。このようなRFCには、新しいアプリケーションの説明、セクション4の情報要素の定義、提案されたテンプレート、およびセクション9.2のような新しいアプリケーションでのこれらのテンプレートの使用例が含まれている必要があります。セクション10は、これらの提案されたテンプレートおよび/または新しいアプリケーション内でのIPFIX構造化データ[RFC6313]の使用の説明に使用されるコンパクトなテキスト情報要素表記を定義します。
In many cases, a new application will require nothing more than a new Information Element or set of Information Elements to be exportable using IPFIX. An Information Element meeting the following criteria, as evaluated by the IE-DOCTORS, is eligible for inclusion in the IANA IE registry:
多くの場合、新しいアプリケーションでは、IPFIXを使用してエクスポートできるようにするために、新しい情報要素または情報要素のセットしか必要ありません。 IE-DOCTORSによって評価された次の基準を満たす情報要素は、IANA IEレジストリに含める資格があります。
o The Information Element must be unique within the registry, and its description must represent a substantially different meaning from that of any existing Information Element. An existing Information Element that can be reused for a given purpose should be reused.
o 情報要素はレジストリ内で一意である必要があり、その説明は既存の情報要素とは実質的に異なる意味を表す必要があります。特定の目的に再利用できる既存の情報要素は再利用する必要があります。
o The Information Element should contain as little internal structure as possible. Instead of representing complex information by overlaying internal structure on a simple data type such as octetArray, such information should be represented with multiple simple Information Elements to be exported in parallel or using IPFIX Structured Data [RFC6313], as in Section 4.5. The internal structure of a proposed IE may be evaluated by the IE-DOCTORS with an eye toward interoperability and/or backward compatibility with existing methods of exporting similar data on a case-by-case basis.
o 情報要素には、できるだけ少ない内部構造を含める必要があります。セクション4.5のように、octetArrayなどの単純なデータ型に内部構造をオーバーレイして複雑な情報を表す代わりに、そのような情報は、並行して、またはIPFIX構造化データ[RFC6313]を使用してエクスポートされる複数の単純な情報要素で表す必要があります。提案されたIEの内部構造は、ケースバイケースで同様のデータをエクスポートする既存の方法との相互運用性および/または下位互換性を目的として、IE-DOCTORSによって評価される場合があります。
o Information Elements representing information about proprietary or nonstandard applications should not be registered in the IANA IE registry. These can be represented using enterprise-specific Information Elements as detailed in Section 3.2 of [RFC7011], instead.
o 独自仕様または非標準のアプリケーションに関する情報を表す情報要素は、IANA IEレジストリに登録しないでください。これらは、代わりに[RFC7011]のセクション3.2で説明されているように、企業固有の情報要素を使用して表すことができます。
The definition of new Information Elements requires a descriptive name, a specification of the data type from the IPFIX Data Type subregistry in the IANA IE registry (defined in [RFC7012] as itself extensible via Standards Action as per [RFC5226]), and a human-readable description written in English. This section provides guidelines on each of these components of an Information Element definition, referring to existing documentation such as [RFC7012] as appropriate.
新しい情報要素の定義には、説明的な名前、IANA IEレジストリの[IPFIX Data Type]サブレジストリからのデータ型の仕様（[RFC7012]で定義されており、[RFC5226]に基づく標準アクションにより拡張可能）と人間が必要です。 -英語で書かれた読みやすい説明。このセクションでは、[RFC7012]などの既存のドキュメントを適宜参照しながら、情報要素定義のこれらの各コンポーネントに関するガイドラインを提供します。
As the name of an Information Element is the first thing a potential implementor will use when determining whether it is suitable for a given application, it is important to be as precise and descriptive as possible. Names of Information Elements:
情報要素の名前は、それが特定のアプリケーションに適しているかどうかを判断するときに潜在的な実装者が最初に使用するものであるため、できるだけ正確かつ説明的であることが重要です。情報要素の名前：
o must be chosen carefully to describe the use of the Information Element within the context in which it will be used.
o 情報要素が使用されるコンテキスト内での情報要素の使用を説明するために、注意深く選択する必要があります。
o must be unique within the IANA IE registry.
o IANA IEレジストリ内で一意である必要があります。
o start with lowercase letters.
o 小文字で始めます。
o use capital letters for the first letter of each component except for the first one (aka "camel case"). All other letters are lowercase, even for acronyms. Exceptions are made for acronyms containing a mixture of lowercase and capital letters, such as 'IPv4' and 'IPv6'. Examples are "sourceMacAddress" and "destinationIPv4Address".
o 最初のものを除いて、各コンポーネントの最初の文字には大文字を使用します（「キャメルケース」とも呼ばれます）。他のすべての文字は、頭字語であっても小文字です。例外は、「IPv4」や「IPv6」のように、小文字と大文字が混在した頭字語に対して行われます。例は「sourceMacAddress」および「destinationIPv4Address」です。
In addition, new Information Elements pertaining to a specific protocol should name the protocol in the first word in order to ease searching by name (e.g., "sipMethod" for a SIP method, as would be used in a logging format for SIP based on IPFIX). Similarly, new Information Elements pertaining to a specific application should name the application in the first word.
さらに、特定のプロトコルに関連する新しい情報要素は、名前での検索を容易にするために、最初の単語でプロトコルに名前を付ける必要があります（たとえば、IPFIXに基づくSIPのログ形式で使用されるように、SIPメソッドの「sipMethod」 ）。同様に、特定のアプリケーションに関連する新しい情報要素は、最初の単語でアプリケーションに名前を付ける必要があります。
IPFIX provides a set of data types covering most primitives used in network measurement and management applications. The most appropriate data type should be chosen for the Information Element type, IPFIX informationElementDataTypes subregistry at [IANA-IPFIX]. This subregistry may be extended from time to time by a Standards Action [RFC5226], as defined in [RFC5610].
IPFIXは、ネットワーク測定および管理アプリケーションで使用されるほとんどのプリミティブをカバーする一連のデータタイプを提供します。 [IANA-IPFIX]のIPFIX informationElementDataTypesサブレジストリの情報要素タイプには、最も適切なデータタイプを選択する必要があります。このサブレジストリは、[RFC5610]で定義されているように、標準アクション[RFC5226]によって随時拡張される場合があります。
Information Elements representing an integral value with a natural width should be defined with the appropriate integral data type. This applies especially to values taken directly from fixed-width fields in a measured protocol. For example, tcpControlBits, the TCP flags byte, is an unsigned8, and tcpSequenceNumber is an unsigned32.
自然な幅の整数値を表す情報要素は、適切な整数データ型で定義する必要があります。これは特に、測定されたプロトコルの固定幅フィールドから直接取得した値に適用されます。たとえば、TCPフラグバイトであるtcpControlBitsはunsigned8で、tcpSequenceNumberはunsigned32です。
Information Elements representing counters or identifiers should be defined as signed64 or unsigned64, as appropriate, to maximize the range of values available; applications can use reduced-size encoding as defined in Section 6.2 of [RFC7011] in cases where fewer than 2^64 values are necessary.
カウンターまたは識別子を表す情報要素は、利用可能な値の範囲を最大化するために、signed64またはunsigned64として適切に定義する必要があります。 2 ^ 64未満の値が必要な場合、アプリケーションは[RFC7011]のセクション6.2で定義されている縮小サイズのエンコーディングを使用できます。
Information Elements representing time values must be defined with appropriate precision. For example, an Information Element for a time measured at second-level precision should be defined as having a dateTimeSeconds data type, instead of dateTimeMilliseconds.
時間値を表す情報要素は、適切な精度で定義する必要があります。たとえば、第2レベルの精度で測定された時間の情報要素は、dateTimeMillisecondsではなく、dateTimeSecondsデータ型として定義する必要があります。
Information Elements of type string or octetArray that have length constraints (fixed length, minimum and/or maximum length) must note these constraints in their description.
文字列型または長さ制約（固定長、最小長、最大長、あるいはその両方）を持つoctetArrayの情報要素は、これらの制約の説明に注意する必要があります。
The type of an Information Element must match the type of the data it represents. More specifically, information that could be represented as a string but that better matches one of the other data types (e.g., an integral type for a number or enumerated type, an address type for an address) must be represented by the best-matching type, even if the data was represented using a different type in the source. For example, an IPFIX application that exports Options Template Records mapping IP addresses to additional information about each host from an external database must use Information Elements of an address type to represent the addresses, even if the source database represented these as strings.
情報要素のタイプは、それが表すデータのタイプと一致する必要があります。より具体的には、文字列として表すことができるが、他のデータ型のいずれかによく一致する情報（たとえば、数値または列挙型の整数型、住所の住所型）は、最も一致する型で表す必要があります。 、データがソースで別のタイプを使用して表されている場合でも。たとえば、外部データベースからIPアドレスを各ホストに関する追加情報にマッピングするオプションテンプレートレコードをエクスポートするIPFIXアプリケーションは、ソースデータベースがこれらを文字列として表した場合でも、アドレスタイプの情報要素を使用してアドレスを表す必要があります。
Strings and octetArrays must not be used to encode data that would be more properly represented using multiple Information Elements and/or IPFIX Structured Data [RFC6313]; see Section 4.5 for more.
文字列とoctetArraysは、複数の情報要素やIPFIX構造化データ[RFC6313]を使用してより適切に表現されるデータをエンコードするために使用してはなりません。詳細については、セクション4.5を参照してください。
This document does not cover the addition of new Data Types or Data Type Semantics to the IPFIX protocol. As such changes have important interoperability considerations and require implementation on both Collecting and Exporting Processes, they require a Standards Action as per [RFC5610]. However, note that the set of primitive types provided by IPFIX are applicable to almost any appropriate application, so extending the type system is generally not necessary.
このドキュメントでは、IPFIXプロトコルへの新しいデータタイプまたはデータタイプセマンティクスの追加については説明していません。このような変更には相互運用性に関する重要な考慮事項があり、収集プロセスとエクスポートプロセスの両方に実装する必要があるため、[RFC5610]に基づく標準アクションが必要です。ただし、IPFIXによって提供されるプリミティブ型のセットは、ほとんどすべての適切なアプリケーションに適用できるため、型システムを拡張する必要は通常ありません。
Each Information Element has a unique identifier in the IANA registry.
各情報要素には、IANAレジストリに一意の識別子があります。
When adding newly registered Information Elements to the IANA IE registry, IANA should assign the lowest available Information Element identifier (the value column in [IANA-IPFIX]) in the range 128-32767.
新しく登録された情報要素をIANA IEレジストリに追加する場合、IANAは、128〜32767の範囲で利用可能な最小の情報要素識別子（[IANA-IPFIX]の値列）を割り当てる必要があります。
Information Elements with identifiers in the range 1-127 are reserved for compatibility with corresponding fields in NetFlow version 9, as described in [RFC3954].
[RFC3954]で説明されているように、1〜127の範囲の識別子を持つ情報要素は、NetFlowバージョン9の対応するフィールドとの互換性のために予約されています。
Information Elements to which special semantics apply should refer to one of the values in the Information Element Semantics subregistry of the IANA IE registry, as described in Section 3.2 of [RFC7012], subject to the restrictions given in Section 3.10 of [RFC5610]; in other words, the semantics and the type must be consistent.
[RFC7012]のセクション3.2で説明されているように、[RFC5610]のセクション3.10で規定されている制限に従い、特別なセマンティクスが適用される情報要素は、IANA IEレジストリの情報要素セマンティクスサブレジストリの値の1つを参照する必要があります。つまり、セマンティクスとタイプは一貫している必要があります。
When defining Information Elements representing a dimensioned quantity or entity count, the units of that quantity should be defined in the units field. This field takes its values from the IANA Information Element Units subregistry of the IANA IE registry. If an Information Element expresses a quantity in units not yet in this subregistry, then the unit must be added to the Units subregistry at the same time the Information Element is added to the IANA IE registry. Note that the Units subregistry as defined in [RFC5610] is maintained on an Expert Review basis.
ディメンション化された数量またはエンティティ数を表す情報要素を定義する場合、その数量の単位は単位フィールドで定義する必要があります。このフィールドは、IANA IEレジストリのIANA Information Element Unitsサブレジストリから値を取得します。情報要素がこのサブレジストリにまだない単位で数量を表す場合、その情報要素をIANA IEレジストリに追加すると同時に、その単位をUnitsサブレジストリに追加する必要があります。 [RFC5610]で定義されているUnitsサブレジストリは、Expert Reviewベースで維持されることに注意してください。
Additionally, when the range of values an Information Element can take is smaller than the range implied by its data type, the range should be defined within the Information Element's entry in the IANA IE registry.
さらに、情報要素が取り得る値の範囲が、そのデータ型によって暗示される範囲よりも小さい場合、その範囲は、IANA IEレジストリの情報要素のエントリ内で定義する必要があります。
The definition of Information Elements with an internal structure that is defined in the Description field is not recommended, except in the following cases:
以下の場合を除いて、説明項目で定義されている内部構造を持つ情報要素の定義はお勧めしません。
1. The Information Element is a direct copy of a structured entity in a measured protocol (e.g., the tcpControlBits Information Element for the flags byte from the TCP header).
1. 情報要素は、測定されたプロトコル内の構造化エンティティの直接コピーです（たとえば、TCPヘッダーからのフラグバイトのtcpControlBits情報要素）。
2. The Information Element represents a section of a packet of protocol entity, in raw form as captured from the wire (e.g., the mplsLabelStackSection Information Element for the MPLS label stack).
2. 情報要素は、プロトコルエンティティのパケットのセクションを、ワイヤーからキャプチャされた生の形式で表します（たとえば、MPLSラベルスタックのmplsLabelStackSection情報要素）。
3. The Information Element represents a set of flags that are tightly semantically related, where representing the flags as separate one-byte booleans would be inefficient, and that should always appear together in a data record (e.g., the anonymizationFlags Information Element for specifying optional features of anonymization techniques).
3. 情報要素は、意味的に密接に関連しているフラグのセットを表します。フラグを個別の1バイトのブール値として表すのは非効率的であり、データレコードに常に一緒に表示する必要があります（たとえば、オプションの機能を指定するためのanonymizationFlags情報要素）匿名化手法）。
4. The Information Element contains internal structure by reference to an external data type or specification containing internal structure (e.g., a MIME type or URL), for interoperability and backward-compatibility purposes.
4. 情報要素には、相互運用性と下位互換性のために、外部データ型または内部構造（MIMEタイプやURLなど）を含む仕様を参照することにより、内部構造が含まれています。
Additional exceptions to the above list should be made through publication of an RFC.
上記のリストに対する追加の例外は、RFCの公開を通じて作成する必要があります。
In other cases, candidate Information Elements with internal structure should be decomposed into multiple primitive Information Elements to be used in parallel. For more complicated semantics, where the structure is not identical from Data Record to Data Record, or where there is semantic dependency between multiple decomposed primitive Information Elements, use the IPFIX Structured Data [RFC6313] extension instead.
その他の場合、内部構造を持つ候補情報要素は、並行して使用される複数のプリミティブ情報要素に分解されるべきです。より複雑なセマンティクス、つまりデータレコードとデータレコード間で構造が同一でない場合、または複数の分解されたプリミティブ情報要素間に意味的な依存関係がある場合は、代わりにIPFIX構造化データ[RFC6313]拡張を使用します。
As an example of Information Element decomposition, consider an application-level identifier called an "endpoint", which represents a {host, port, protocol} tuple. Instead of allocating an opaque, structured "source endpoint" Information Element, the source endpoint should be represented by three separate Information Elements: "source address", "source port", "transport protocol". In this example, the required Information Elements already exist in the IANA IE registry: sourceIPv4Address or sourceIPv6Address, sourceTransportPort, protocolIdentifier. Indeed, as well as being good practice, this normalization down to non-structured Information Elements also increases opportunities for reuse as in Section 6.1.
情報要素分解の例として、{ホスト、ポート、プロトコル}タプルを表す「エンドポイント」と呼ばれるアプリケーションレベルの識別子を考えます。不透明で構造化された「ソースエンドポイント」情報要素を割り当てる代わりに、ソースエンドポイントは、「ソースアドレス」、「ソースポート」、「トランスポートプロトコル」の3つの個別の情報要素で表す必要があります。この例では、必要な情報要素がすでにIANA IEレジストリに存在しています：sourceIPv4AddressまたはsourceIPv6Address、sourceTransportPort、protocolIdentifier。実際、この慣行は非構造化情報要素にまで正規化されるだけでなく、セクション6.1のように再利用の機会を増やします。
The decomposition of data with internal structure should avoid the definition of Information Elements that have a meaning too specific to be generally useful or that would result in a multitude of templates to handle different multiplicities. More information on multiplicities is given in the following section.
内部構造を持つデータの分解では、一般的に有用ではない特定の意味を持つ情報要素や、さまざまな多重度を処理するための多数のテンプレートをもたらす情報要素の定義を避ける必要があります。多重度の詳細については、次のセクションで説明します。
Some Information Elements may represent information with a multiplicity other than one, i.e., items that may occur multiple times within the data to be represented in a single IPFIX record. In this case, there are several options, depending on the circumstances:
一部の情報要素は、1以外の多重度で情報を表す場合があります。つまり、単一のIPFIXレコードで表されるデータ内で複数回発生する可能性があるアイテムです。この場合、状況に応じていくつかのオプションがあります。
1. As specified in Section 8 of [RFC7011]: "if an Information Element is required more than once in a Template, the different occurrences of this Information Element should follow the logical order of their treatments by the Metering Process." In other words, in cases where the items have a natural order (e.g., the order in which they occur in the packet), and the multiplicity is the same for each record, the information can be modeled by containing multiple instances of the Information Element representing a single item within the Template Record describing the Data Records.
1. [RFC7011]のセクション8で指定されているように、「テンプレートで情報要素が2回以上必要な場合、この情報要素の異なる出現は、計量プロセスによる処理の論理的な順序に従う必要があります。」言い換えると、アイテムが自然な順序（パケット内での出現順序など）で、各レコードの多重度が同じである場合、情報は、情報要素の複数のインスタンスを含めることによってモデル化できます。データレコードを説明するテンプレートレコード内の単一のアイテムを表します。
2. In cases where the items have a variable multiplicity, a basicList of the Information Element representing a single item can be used as in the IPFIX Structured Data [RFC6313] extension.
2. アイテムの多重度が可変である場合、IPFIX構造化データ[RFC6313]拡張のように、単一のアイテムを表す情報要素のbasicListを使用できます。
3. If the multiple-item structure is taken directly from bytes observed on the wire by the Metering Process or otherwise taken from the application being measured (e.g., a TCP options stack), the multiple-item structure can be exported as a variable-length octetArray Information Element holding the raw content.
3. 複数項目の構造が、メータリングプロセスによってワイヤ上で観察されたバイトから直接取得されるか、測定されているアプリケーション（TCPオプションスタックなど）から取得される場合、複数項目の構造は、可変長のoctetArrayとしてエクスポートできます。生のコンテンツを保持する情報要素。
Specifically, a new Information Element should not encode any multiplicity or ordinality information into the definition of the Information Element itself.
具体的には、新しい情報要素は、多重度または順序情報を情報要素自体の定義にエンコードするべきではありません。
When defining an Information Element that takes an enumerated value from a set of values that may change in the future, this enumeration must be defined by an IANA IE registry or subregistry. For situations where an existing registry defines the enumeration (e.g., the IANA Protocol Numbers registry for the protocolIdentifier Information Element), that registry must be used. Otherwise, a new subregistry of the IANA IPFIX registry must be defined for the enumerated value, to be modified subject to Expert Review [RFC5226].
将来変更される可能性のある値のセットから列挙値を取得する情報要素を定義する場合、この列挙はIANA IEレジストリまたはサブレジストリで定義する必要があります。既存のレジストリが列挙を定義する状況（たとえば、protocolIdentifier情報要素のIANAプロトコル番号レジストリ）では、そのレジストリを使用する必要があります。それ以外の場合、IANA IPFIXレジストリの新しいサブレジストリを列挙値に対して定義して、エキスパートレビュー[RFC5226]に従って変更する必要があります。
[RFC5103] defines a method for exporting bidirectional Flows using a special Private Enterprise Number to define reverse-direction variants of IANA Information Elements, and a set of criteria for determining whether an Information Element may be reversed using this method. Since almost all Information Elements are reversible, [RFC5103] enumerates those Information Elements that were defined at the time of its publication that are NOT reversible.
[RFC5103]は、特別なプライベートエンタープライズ番号を使用して双方向フローをエクスポートする方法を定義し、IANA情報要素の逆方向バリアントを定義し、この方法を使用して情報要素を逆転できるかどうかを決定するための一連の基準を定義します。ほとんどすべての情報要素は可逆的であるため、[RFC5103]は、公開時に定義された、可逆的でない情報要素を列挙しています。
New non-reversible Information Elements must contain a note in the description stating that they are not reversible.
新しい不可逆的な情報要素は、不可逆であることを説明する注記を説明に含める必要があります。
In general, the existence of a similarly defined Information Element in the IANA IE registry sets a precedent that may be followed to determine whether a given proposed Information Element "fits" within the registry. Indeed, the rules specified by this document could be interpreted to mean "make new Information Elements that look like existing Information Elements". However, for reasons of history, there are several Information Elements within the IANA IE registry that do not follow best practices in Information Element design.
一般に、IANA IEレジストリに同様に定義された情報要素が存在すると、指定された提案された情報要素がレジストリ内に「適合する」かどうかを判断するために従うことができる前例が設定されます。実際、このドキュメントで指定されているルールは、「既存の情報要素のように見える新しい情報要素を作成する」ことを意味すると解釈できます。ただし、履歴の理由により、IANA IEレジストリ内には、情報要素設計のベストプラクティスに従わない情報要素がいくつかあります。
These Information Elements are not necessarily so flawed so as to require deprecation, but they should be explicitly ignored when looking for guidance as to whether a new Information Element should be added. Here we provide a set of representative examples taken from the IANA IE registry; in general, entries in the IANA IE registry that do not follow the guidelines in this document should not be used as examples for new Information Element definitions.
これらの情報要素は、必ずしも非推奨になるほど欠陥があるわけではありませんが、新しい情報要素を追加する必要があるかどうかに関するガイダンスを探す場合は、明示的に無視する必要があります。ここでは、IANA IEレジストリから取得した一連の代表的な例を示します。一般に、このドキュメントのガイドラインに従っていないIANA IEレジストリのエントリは、新しい情報要素定義の例として使用しないでください。
Before registering a new Information Element, it must be determined that it would be sufficiently unique within the IANA IE registry. This evaluation has not always been done in the past, and the existence of the Information Elements defined without this evaluation should not be taken as an example that such Information Element definition practices should be followed in the future. Specific examples of such Information Elements include initiatorOctets and responderOctets (which duplicate octetDeltaCount and its reverse per [RFC5103]) and initiatorPackets and responderPackets (the same, for packetDeltaCount).
新しい情報要素を登録する前に、それがIANA IEレジストリ内で十分に一意であることを確認する必要があります。この評価は常に過去に行われたとは限らず、この評価なしで定義された情報要素の存在は、そのような情報要素定義の慣行が将来従われるべき例として取られるべきではありません。このような情報要素の具体例には、initiatorOctetsとresponderOctets（octetDeltaCountとその逆（[RFC5103]ごとに複製））、initiatorPacketsとresponderPackets（packetDeltaCountについても同じ）が含まれます。
As mentioned in Section 4.2, the type of an Information Element should match the type of data the Information Element represents. An example of how not to do this is presented by the p2pTechnology, tunnelTechnology, and encryptedTechnology Information Elements: these represent a three-state enumeration using a String. The example set by these Information Elements should not be followed in the definition of new Information Elements.
セクション4.2で述べたように、情報要素のタイプは、情報要素が表すデータのタイプと一致する必要があります。これを行わない方法の例は、p2pTechnology、tunnelTechnology、およびencryptedTechnology情報要素によって示されます。これらは、文字列を使用した3つの状態の列挙を表します。これらの情報要素によって設定された例は、新しい情報要素の定義では従うべきではありません。
As mentioned in Section 4.6, an Information Element definition should not include any ordinality or multiplicity information. The only example of this within the IANA IE registry the following list of assigned IPFIX Information Elements: mplsTopLabelStackSection, mplsLabelStackSection2, mplsLabelStackSection3, mplsLabelStackSection4, mplsLabelStackSection5, mplsLabelStackSection6 mplsLabelStackSection7, mplsLabelStackSection8, mplsLabelStackSection9, and mplsLabelStackSection10. The only distinction between those almost-identical Information Elements is the position within the MPLS stack. This Information Element design pattern met an early requirement of the definition of IPFIX that was not carried forward into the final specification -- namely, that no semantic dependency was allowed between Information Elements in the same Record -- and as such should not be followed in the definition of new Information Elements. In this case, since the size of the MPLS stack will vary from Flow to Flow, it should be exported using IPFIX Structured Data [RFC6313] where supported, as a basicList of MPLS label entries, or as a raw MPLS label stack using the variable-length mplsLabelStackSection Information Element.
セクション4.6で述べたように、情報要素の定義には、順序情報や多重度情報を含めないでください。 IANA IEレジストリ内の唯一の例は、割り当てられたIPFIX情報要素の次のリストです。それらのほぼ同一の情報要素間の唯一の違いは、MPLSスタック内の位置です。この情報要素の設計パターンは、最終仕様に引き継がれなかったIPFIXの定義の初期の要件を満たしました。つまり、同じレコード内の情報要素間に意味的な依存関係が許可されなかったため、新しい情報要素の定義。この場合、MPLSスタックのサイズはフローごとに異なるため、サポートされている場合は、IPFIX構造化データ[RFC6313]を使用して、MPLSラベルエントリのbasicListとして、または変数を使用して生のMPLSラベルスタックとしてエクスポートする必要があります。 -length mplsLabelStackSection情報要素。
Once an Information Element or set of Information Elements has been identified for a given application, Information Element specifications in accordance with Section 4 are submitted to IANA to follow the process for review by the IE-DOCTORS, as defined below. This process is also used for other changes to the IANA IE registry, such as deprecation or revision, as described later in this section.
特定のアプリケーションの情報要素または情報要素のセットが特定されると、セクション4に基づく情報要素の仕様がIANAに送信され、以下に定義するIE-DOCTORSによる確認プロセスに従います。このプロセスは、このセクションで後述するように、非推奨やリビジョンなど、IANA IEレジストリへの他の変更にも使用されます。
Requests to change the IANA IE registry or a linked subregistry are submitted to IANA, which forwards the request to a designated group of experts (IE-DOCTORS) appointed by the IESG; these are the reviewers called for by the Expert Review [RFC5226] policy defined for the IANA IE registry by [RFC7012]. The IE-DOCTORS review the request for such things as compliance with this document, compliance with other applicable IPFIX-related RFCs, and consistency with the currently defined set of Information Elements.
IANA IEレジストリまたはリンクされたサブレジストリを変更する要求がIANAに送信され、IEANAによって指定された専門家グループ（IE-DOCTORS）に要求が転送されます。これらは、[RFC7012]によってIANA IEレジストリに定義されたエキスパートレビュー[RFC5226]ポリシーによって要求されたレビュー担当者です。 IE-DOCTORSは、このドキュメントへの準拠、他の該当するIPFIX関連のRFCへの準拠、現在定義されている情報要素のセットとの整合性などの要求をレビューします。
Authors are expected to review compliance with the specifications in this document to check their submissions before sending them to IANA.
著者は、IANAに送信する前に提出物を確認するために、このドキュメントの仕様への準拠をレビューする必要があります。
The IE-DOCTORS should endeavor to complete referred reviews in a timely manner. If the request is acceptable, the IE-DOCTORS signify their approval to IANA, which changes the IANA IE registry. If the request is not acceptable, the IE-DOCTORS can coordinate with the requestor to change the request to be compliant. The IE-DOCTORS may also choose in exceptional circumstances to reject clearly frivolous or inappropriate change requests outright.
IE-DOCTORSは、参照されたレビューをタイムリーに完了するよう努めるべきです。要求が受け入れ可能な場合、IE-DOCTORSはIANAへの承認を示し、IANA IEレジストリを変更します。要求が受け入れられない場合、IE-DOCTORSは要求者と調整して、要求を準拠するように変更できます。 IE-DOCTORSは、例外的な状況でも、明らかに軽薄なまたは不適切な変更要求を完全に拒否することを選択する場合があります。
This process should not in any way be construed as allowing the IE-DOCTORS to overrule IETF consensus. Specifically, Information Elements in the IANA IE registry that were added with IETF consensus require IETF consensus for revision or deprecation.
このプロセスは、IE-DOCTORSがIETFコンセンサスを無効にすることを許可するものと決して解釈されるべきではありません。具体的には、IETFコンセンサスで追加されたIANA IEレジストリの情報要素には、改訂または廃止のためにIETFコンセンサスが必要です。
Decisions by the IE-DOCTORS may be appealed as in Section 7 of [RFC5226].
IE-DOCTORSによる決定は、[RFC5226]のセクション7のように上訴される場合があります。
The Information Element status field in the IANA IE registry is defined in [RFC7012] to allow Information Elements to be 'current' or 'deprecated'. No Information Elements are as of this writing deprecated. [RFC5102] additionally specified an 'obsolete' status; however, this has been removed on revision as it served no operational purpose.
IANA IEレジストリの情報要素ステータスフィールドは、[RFC7012]で定義されており、情報要素を「最新」または「非推奨」にすることができます。この記事の執筆時点で非推奨となった情報要素はありません。 [RFC5102]は、「廃止」ステータスを追加で指定しました。ただし、これは運用上の目的を果たさなかったため、改訂時に削除されました。
In addition, no policy is defined for revising IANA IE registry entries or addressing errors therein. To be certain, changes and deprecations within the IANA IE registry are not encouraged, and should be avoided to the extent possible. However, in recognition that change is inevitable, this section is intended to remedy this situation.
さらに、IANA IEレジストリエントリの改訂やエラーの対処に関するポリシーは定義されていません。確かに、IANA IEレジストリ内の変更と廃止は推奨されておらず、可能な限り回避する必要があります。ただし、変更が不可避であることを認識して、このセクションはこの状況を改善することを目的としています。
Changes are initiated by sending a new Information Element definition to IANA, as in Section 5.1, for an already-existing Information Element.
変更は、セクション5.1のように、既存の情報要素の新しい情報要素定義をIANAに送信することによって開始されます。
The primary requirement in the definition of a policy for managing changes to existing Information Elements is avoidance of interoperability problems; IE-DOCTORS must work to maintain interoperability above all else. Changes to Information Elements already in use may only be done in an interoperable way; necessary changes that cannot be done in a way to allow interoperability with unchanged implementations must result in deprecation.
既存の情報要素への変更を管理するためのポリシーの定義における主な要件は、相互運用性の問題の回避です。 IE-DOCTORSは、何よりも相互運用性を維持するように機能する必要があります。すでに使用されている情報要素への変更は、相互運用可能な方法でのみ行うことができます。変更されていない実装との相互運用を可能にする方法で行うことができない必要な変更は、非推奨になる必要があります。
A change to an Information Element is held to be interoperable only when:
情報要素への変更は、次の場合にのみ相互運用できるように保持されます。
1. it involves the correction of an error that is obviously only editorial; or
1. これは明らかに編集上のエラーの修正を伴います。または
2. it corrects an ambiguity in the Information Element's definition, which itself leads to non-interoperability severe enough to prevent the Information Element's usage as originally defined (e.g., a prior change to ipv6ExtensionHeaders); or
2. それは、情報要素の定義のあいまいさを修正します。これにより、最初に定義された情報要素の使用（たとえば、ipv6ExtensionHeadersへの以前の変更）を防ぐのに十分な重大な相互運用性が失われます。または
3. it expands the Information Element's data type without changing how it is represented (e.g., changing unsigned32 to unsigned64, as with a prior change to selectorId); or
3. 情報要素のデータタイプを、それがどのように表現されるかを変更せずに拡張します（たとえば、selectorIdへの以前の変更と同様に、unsigned32をunsigned64に変更します）または
4. it corrects missing information in the Information Element's definition without changing its meaning (e.g., the explicit definition of 'quantity' semantics for numeric Information Elements without a Data Type Semantics value); or
4. 情報要素の定義で欠落している情報を、その意味を変更せずに修正します（たとえば、データタイプのセマンティクスの値がない数値情報要素の「量」のセマンティクスの明示的な定義）。または
5. it defines a previously undefined or reserved enumerated value, or one or more previously reserved bits in an Information Element with flag semantics; or
5. 未定義または予約済みの列挙値、またはフラグセマンティクスを持つ情報要素内の以前に予約された1つ以上のビットを定義します。または
6. it expands the set of permissible values in the Information Element's range; or
6. 情報要素の範囲内の許容値のセットを拡張します。または
7. it harmonizes with an external reference that was itself corrected.
7. それ自体が修正された外部参照と調和します。
If a change is deemed permissible by the IE-DOCTORS, IANA makes the change in the IANA IE registry. The requestor of the change is appended to the requestor in the registry.
IE-DOCTORSによって変更が許容されると見なされる場合、IANAはIANA IEレジストリに変更を加えます。変更の要求者は、レジストリの要求者に追加されます。
Each Information Element in the IANA IE registry has a revision number, starting at zero. Each change to an Information Element following this process increments the revision number by one. Since any revision must be interoperable according to the criteria above, there is no need for the IANA IE registry to store information about old revisions.
IANA IEレジストリの各情報要素には、0から始まるリビジョン番号があります。このプロセスの後に情報要素を変更するたびに、リビジョン番号が1ずつ増加します。リビジョンは上記の基準に従って相互運用可能でなければならないため、IANA IEレジストリに古いリビジョンに関する情報を格納する必要はありません。
When a revised Information Element is accepted into the registry, the date of acceptance of the most recent revision is placed into the revision Date column of the registry for that Information Element.
改訂された情報要素がレジストリに受け入れられると、最新の改訂の受け入れ日が、その情報要素のレジストリの改訂日付列に配置されます。
Changes that are not permissible by these criteria may only be handled by deprecation. An Information Element MAY be deprecated and replaced when:
これらの基準で許可されていない変更は、サポート終了によってのみ処理できます。情報要素は、次の場合に非推奨になり、置き換えられる場合があります。
1. the Information Element definition has an error or shortcoming that cannot be permissibly changed as in Section 5.2; or
1. 情報要素の定義に、セクション5.2のように許容できるほど変更できないエラーまたは欠点がある。または
2. the deprecation harmonizes with an external reference that was itself deprecated through that reference's accepted deprecation method; or
2. 非推奨は、その参照で受け入れられている非推奨メソッドによって非推奨になった外部参照と調和します。または
3. changes in the IPFIX protocol or its extensions, or in community understanding thereof, allow the information represented by the Information Element to be represented in a more efficient or convenient way. Deprecation in this circumstance requires a Standards Action.
3. IPFIXプロトコルまたはその拡張機能の変更、またはそのコミュニティの理解における変更により、情報要素によって表される情報をより効率的または便利な方法で表すことができます。この状況での廃止には、標準アクションが必要です。
A request for deprecation is sent to IANA, which passes it to the IE-DOCTORS for review, as in Section 5.1. When deprecating an Information Element, the Information Element description in the IANA IE registry must be updated to explain the deprecation, as well as to refer to any new Information Elements created to replace the deprecated Information Element.
セクション5.1のように、廃止のリクエストがIANAに送信され、レビューのためにIE-DOCTORSに渡されます。情報要素を非推奨にする場合は、IANA IEレジストリの情報要素の説明を更新して、非推奨について説明し、非推奨の情報要素を置き換えるために作成された新しい情報要素を参照する必要があります。
The revision number of an Information Element is incremented upon deprecation, and the revision Date updated, as with any revision.
情報要素のリビジョン番号は非推奨になるとインクリメントされ、リビジョン日付は他のリビジョンと同様に更新されます。
Deprecated Information Elements should continue to be supported by Collecting Processes, but should not be exported by Exporting Processes. The use of deprecated Information Elements should result in a log entry or human-readable warning at the Exporting and Collecting Processes.
非推奨の情報要素は、収集プロセスによって引き続きサポートされる必要がありますが、エクスポートプロセスによってエクスポートされるべきではありません。非推奨の情報要素を使用すると、エクスポートおよび収集プロセスでログエントリまたは人間が読める警告が表示されます。
Names and elementIDs of deprecated Information Elements must not be reused.
非推奨の情報要素の名前とelementIDは再利用しないでください。
Due to the relatively limited number space of Information Elements in the IANA IE registry, and the fact that the difficulty of managing and understanding the registry increases with its size, avoiding redundancy and clutter in the registry is important in defining new applications. New Information Elements should not be added to the IANA IE registry unless there is an intent to implement and deploy applications using them; research or experimental applications should use enterprise-specific Information Elements as in Section 6.2 instead.
IANA IEレジストリ内の情報要素の数は比較的限られており、レジストリの管理と理解の難しさはそのサイズとともに増大するため、レジストリの冗長性と乱雑さを回避することは、新しいアプリケーションを定義する上で重要です。新しい情報要素は、それらを使用してアプリケーションを実装および展開する意図がない限り、IANA IEレジストリに追加しないでください。研究または実験的アプリケーションは、代わりにセクション6.2のように企業固有の情報要素を使用する必要があります。
The subsections below provide guidelines for reuse of existing Information Elements, as well as guidelines on using enterprise-specific Information Elements instead of adding Information Elements in the IANA IE registry.
以下のサブセクションでは、既存の情報要素を再利用するためのガイドラインと、IANA IEレジストリに情報要素を追加する代わりに企業固有の情報要素を使用するためのガイドラインを示します。
Whenever possible, new applications should prefer usage of existing IPFIX Information Elements to the creation of new Information Elements. IPFIX already provides Information Elements for every common Layer 4 and Layer 3 packet header field in the IETF protocol suite, basic Layer 2 information, basic counters, timestamps and time ranges, and so on. When defining a new Information Element similar to an existing one, reviewers should ensure that the existing one is not applicable.
新しいアプリケーションでは、可能な限り、新しい情報要素の作成よりも既存のIPFIX情報要素の使用を優先する必要があります。 IPFIXはすでに、IETFプロトコルスイートのすべての一般的なレイヤー4およびレイヤー3パケットヘッダーフィールドの情報要素、基本的なレイヤー2情報、基本的なカウンター、タイムスタンプと時間範囲などを提供しています。既存のものと同様の新しい情報要素を定義する場合、レビュー担当者は既存のものが適用可能でないことを確認する必要があります。
Note that this guideline to maximize reuse does not imply that an Information Element that represents the same information from a packet as an existing Information Element should not be added to the IANA IE registry. For example, consider the ipClassOfService (Element ID 5), ipDiffServCodePoint (Element ID 98), and ipPrecedence (Element ID 196) Information Elements. These all represent subsets of the same field in an IP version 4 packet header, but different uses of these bits. The representation in one or another of these Information Elements contains information in itself as to how the bits were interpreted by the Metering Process.
再利用を最大化するこのガイドラインは、既存の情報要素と同じパケットからの情報を表す情報要素をIANA IEレジストリに追加しないことを意味するものではないことに注意してください。たとえば、ipClassOfService（要素ID 5）、ipDiffServCodePoint（要素ID 98）、およびipPrecedence（要素ID 196）情報要素について考えます。これらはすべて、IPバージョン4パケットヘッダーの同じフィールドのサブセットを表しますが、これらのビットの使用方法は異なります。これらの情報要素のいずれかの表現には、メータリングプロセスによってビットがどのように解釈されたかに関する情報が含まれています。
On the other hand, simply changing the context in which an Information Element will be used is insufficient reason for the definition of a new Information Element. For example, an extension of IPFIX to log detailed information about HTTP transactions alongside network-level information should not define httpClientAddress and httpServerAddress Information Elements, preferring instead the use of sourceIPv[46]Address and destinationIPv[46]Address.
一方、情報要素が使用されるコンテキストを変更するだけでは、新しい情報要素を定義するのに不十分です。たとえば、ネットワークレベルの情報とともにHTTPトランザクションに関する詳細情報を記録するIPFIXの拡張では、httpClientAddressおよびhttpServerAddress情報要素を定義しないでください。代わりに、sourceIPv [46] AddressおよびdestinationIPv [46] Addressを使用することをお勧めします。
Applications dealing with bidirectional interactions should use Bidirectional Flow Support for IPFIX [RFC5103] to represent these interactions.
双方向の相互作用を扱うアプリケーションは、IPFIX [RFC5103]の双方向フローサポートを使用して、これらの相互作用を表す必要があります。
Existing timestamp and time range Information Elements should be reused for any situation requiring simple time stamping of an event: for single observations, the observationTime* Information Elements from PSAMP are provided, and for events with a duration, the flowStart* and flowEnd* Information Elements suffice. This arrangement allows minimal generic time handling by existing Collecting Processes and analysis workflows. New timestamp Information Elements should ONLY be defined for semantically distinct timing information (e.g., an IPFIX-exported record containing information about an event to be scheduled in the future).
イベントの単純なタイムスタンプが必要な状況では、既存のタイムスタンプと時間範囲の情報要素を再利用する必要があります。単一の観測の場合、PSAMPからのObservationTime *情報要素が提供され、期間のあるイベントの場合、flowStart *とflowEnd *情報要素が提供されます十分です。この配置により、既存の収集プロセスと分析ワークフローによる最小限の一般的な時間処理が可能になります。新しいタイムスタンプ情報要素は、意味的に異なるタイミング情報（たとえば、将来スケジュールされるイベントに関する情報を含むIPFIXでエクスポートされたレコード）に対してのみ定義する必要があります。
In all cases, the use of absolute timestamp Information Elements (e.g., flowStartMilliseconds) is recommended, as these Information Elements allow for maximum flexibility in processing with minimal overhead. Timestamps based on the Export Time header in the enclosing IPFIX Message (e.g., flowStartTimeDeltaMicroseconds) MAY be used if high-precision timing is important, export bandwidth or storage space is limited, timestamps comprise a relatively large fraction of record size, and the application naturally groups records into IPFIX Messages. Timestamps based on information that must be exported in a separate Data Record defined by an Options Template (e.g., flowStartSysUpTime) MAY be used only in the context of an existing practice of using runtime-defined epochs for the given application. New applications should avoid these structures when possible.
すべての場合において、絶対的なタイムスタンプ情報要素（flowStartMillisecondsなど）を使用することをお勧めします。これらの情報要素により、オーバーヘッドを最小限に抑えながら処理の柔軟性を最大化できるためです。囲んでいるIPFIXメッセージのエクスポート時間ヘッダーに基づくタイムスタンプ（flowStartTimeDeltaMicrosecondsなど）は、高精度のタイミングが重要で、エクスポートの帯域幅またはストレージスペースが限られている場合、タイムスタンプがレコードサイズの比較的大きな部分を占め、アプリケーションが自然に使用される場合があります。レコードをIPFIXメッセージにグループ化します。オプションテンプレート（flowStartSysUpTimeなど）で定義された個別のデータレコードにエクスポートする必要がある情報に基づくタイムスタンプは、特定のアプリケーションでランタイム定義のエポックを使用する既存の方法のコンテキストでのみ使用できます（MAY）。新しいアプリケーションでは、可能であればこれらの構造を回避する必要があります。
IPFIX provides a mechanism for defining enterprise-specific Information Elements, as in Section 3.2 of [RFC7011]. These are scoped to a vendor's or organization's Structure of Management Information (SMI) Private Enterprise Number, and are under complete control of the organization assigning them.
IPFIXは、[RFC7011]のセクション3.2にあるように、企業固有の情報要素を定義するためのメカニズムを提供します。これらは、ベンダーまたは組織の管理情報構造（SMI）プライベートエンタープライズ番号を対象とし、それらを割り当てる組織の完全な管理下にあります。
For situations in which interoperability is unimportant, new information should be exported using enterprise-specific Information Elements instead of adding new Information Elements to the IANA IE registry. These situations include:
相互運用性が重要でない状況では、IANA IEレジストリに新しい情報要素を追加する代わりに、企業固有の情報要素を使用して新しい情報をエクスポートする必要があります。これらの状況は次のとおりです。
o export of implementation-specific information, or
o 実装固有の情報のエクスポート、または
o export of information supporting research or experiments within a single organization or closed community, or
o 単一の組織または閉じたコミュニティ内での研究または実験をサポートする情報のエクスポート、または
o export of information derived in a commercially sensitive or proprietary method, or
o 商業上機密または専有の方法で得られた情報の輸出、または
o export of information or meta-information specific to a commercially sensitive or proprietary application.
o 商業上重要な、または独自仕様のアプリケーションに固有の情報またはメタ情報のエクスポート。
While work within the IETF generally does not fall into these categories, enterprise-specific Information Elements are also useful for pre-standardization testing of a new IPFIX application. While performing initial development and interoperability testing of a new application, the Information Elements used by the application should not be submitted to IANA for inclusion in the IANA IE registry. Instead, these experimental Information Elements should be represented as enterprise-specific until their definitions are finalized.
IETF内の作業は通常これらのカテゴリに分類されませんが、企業固有の情報要素は、新しいIPFIXアプリケーションの事前標準化テストにも役立ちます。新しいアプリケーションの初期開発と相互運用性テストを実行している間、アプリケーションで使用される情報要素をIANAに送信してIANA IEレジストリに含めることはできません。代わりに、これらの実験的な情報要素は、それらの定義が確定するまで企業固有のものとして表す必要があります。
As this document contains best practices for defining new Information Elements, organizations using enterprise-specific Information Elements are advised to follow the guidelines set forth here even if not submitting Information Elements for inclusion in the IANA IE registry.
このドキュメントには新しい情報要素を定義するためのベストプラクティスが含まれているため、企業固有の情報要素を使用する組織は、IANA IEレジストリに含めるために情報要素を提出しなくても、ここで説明するガイドラインに従うことをお勧めします。
The following three checklists, condensed from the rest of this document, can be used when defining and reviewing Information Elements; they refer back to the section of this document from which they are taken. These checklists are intended for the definition of new Information Elements; revision should follow the process defined in Section 5.2, and deprecation should follow the process defined in Section 5.3.
このドキュメントの残りの部分から要約した次の3つのチェックリストは、情報要素を定義および確認するときに使用できます。彼らは、彼らが取られたこの文書のセクションを再び参照する。これらのチェックリストは、新しい情報要素の定義を目的としています。改訂はセクション5.2で定義されたプロセスに従う必要があり、非推奨はセクション5.3で定義されたプロセスに従う必要があります。
Though many of the considerations in this document require the subjective judgement of Information Element authors, reviewers, and IANA, certain parts of the process may be made simpler through tool support. Items on these checklists that could be easily automated or assisted by tools are annotated with "(tool support)". Other items on these checklists require some level of subjective judgement; checks for semantic uniqueness may additionally be supported by textual analysis of descriptions in the future.
このドキュメントの考慮事項の多くは、情報要素の作成者、レビュー担当者、およびIANAの主観的な判断を必要としますが、プロセスの特定の部分は、ツールのサポートにより簡素化される場合があります。ツールで簡単に自動化または支援できるこれらのチェックリストの項目には、「（ツールサポート）」という注釈が付いています。これらのチェックリストの他の項目には、ある程度の主観的な判断が必要です。意味の一意性のチェックは、将来的に説明のテキスト分析によってさらにサポートされる可能性があります。
Checklist 1 contains conditions that must be met by all proposed Information Elements:
チェックリスト1には、提案されたすべての情報要素が満たす必要のある条件が含まれています。
1. The name must be unique within the IANA IE registry, and the name of any current or deprecated Information Element must not be reused. (Section 4.1) (tool support)
1. この名前はIANA IEレジストリ内で一意である必要があり、現在または非推奨の情報要素の名前は再利用できません。 （セクション4.1）（ツールのサポート）
2. The description must be sufficiently semantically unique within the IANA IE registry, representing a substantially different meaning from any current or deprecated Information Element. (Section 4)
2. 説明は、IANA IEレジストリ内で十分に意味的に一意である必要があり、現在のまたは非推奨の情報要素とは実質的に異なる意味を表します。 （セクション4）
3. The name must start with a lowercase letter. (Section 4.1) (tool support)
3. 名前は小文字で始める必要があります。 （セクション4.1）（ツールのサポート）
4. Names composed of more than one word must use capital letters for the first letter of each component except for the first one; all other letters are lowercase, even for acronyms. Exceptions are made for acronyms containing a mixture of lowercase and capital letters, such as 'IPv4' and 'IPv6'. (Section 4.1) (tool support)
4. 複数の単語で構成される名前では、最初の文字を除く各コンポーネントの最初の文字に大文字を使用する必要があります。他のすべての文字は、頭字語であっても小文字です。例外は、「IPv4」や「IPv6」のように、小文字と大文字が混在した頭字語に対して行われます。 （セクション4.1）（ツールのサポート）
5. The data type must match the type of the data being represented. (Section 4.2)
5. データ型は、表されるデータの型と一致する必要があります。 （セクション4.2）
6. Data type semantics must be appropriate for the data type. (Section 4.4) (tool support)
6. データ型のセマンティクスは、データ型に適している必要があります。 （4.4節）（ツールのサポート）
7. The Information Element identifier assigned by IANA must be unique. (Section 4.3) (tool support)
7. IANAによって割り当てられた情報要素識別子は一意である必要があります。 （セクション4.3）（ツールのサポート）
8. The Information Element must be reviewed for the potential of information leakage or other misuse that could reduce the security of the measured system; security considerations specific to the Information Element must be discussed in the description or in a supporting RFC. (Section 11)
8. 情報要素は、測定システムのセキュリティを低下させる可能性のある情報漏えいまたはその他の誤用の可能性について検討する必要があります。情報要素に固有のセキュリティに関する考慮事項は、説明またはサポートするRFCで説明する必要があります。 （セクション11）
Checklist 2 contains conditions that must be met by proposed Information Elements with certain properties, as noted:
チェックリスト2には、次のように、特定のプロパティを持つ提案された情報要素が満たす必要がある条件が含まれています。
1. Time values must be defined with appropriate precision. (Section 4.2)
1. 時間値は適切な精度で定義する必要があります。 （セクション4.2）
2. Strings and octet arrays with length restrictions must note those length restrictions in their descriptions. (Section 4.2)
2. 長さ制限のある文字列とオクテット配列は、説明でそれらの長さ制限に注意する必要があります。 （セクション4.2）
3. Enumerations must refer to an IANA IE registry or subregistry, or a registry maintained by an external standards organization. If no suitable registry or subregistry exists, a new subregistry of the IPFIX Information Element registry must be created for the enumeration, to be modified subject to Expert Review [RFC5226]. (Section 4.7)
3. 列挙は、IANA IEレジストリまたはサブレジストリ、または外部の標準化組織によって維持されているレジストリを参照する必要があります。適切なレジストリまたはサブレジストリが存在しない場合、IPFIX情報要素レジストリの新しいサブレジストリを列挙用に作成し、Expert Review [RFC5226]に従って変更する必要があります。 （セクション4.7）
Checklist 3 contains conditions that should be met by proposed Information Elements:
チェックリスト3には、提案された情報要素が満たすべき条件が含まれています。
1. The name of an Information Element pertaining to a specific protocol or application should contain the name of the protocol or application as the first word. (Section 4.1)
1. 特定のプロトコルまたはアプリケーションに関連する情報要素の名前には、プロトコルまたはアプリケーションの名前を最初の単語として含める必要があります。 （セクション4.1）
2. Information Elements representing integral values should use a data type for the appropriate width for the value. (Section 4.2)
2. 整数値を表す情報要素は、値の適切な幅のデータ型を使用する必要があります。 （セクション4.2）
3. Information Elements representing counters or identifiers should be represented as signed64 or unsigned64, unless they are naturally represented with narrower integral types, as appropriate. (Section 4.2)
3. カウンターまたは識別子を表す情報要素は、必要に応じてより狭い整数型で自然に表現されない限り、signed64またはunsigned64として表現する必要があります。 （セクション4.2）
4. An Information Element should not contain internal structure, subject to the exceptions in Section 4.5; candidate Information Elements with internal structure should be decomposed into multiple Information Elements. (Section 4.5)
4. 情報要素には、4.5項の例外を除き、内部構造を含めないでください。内部構造を持つ候補情報要素は、複数の情報要素に分解する必要があります。 （セクション4.5）
5. An Information Element should not contain multiplicity or ordinality information within the definition of the Information Element itself. (Section 4.6)
5. 情報要素には、情報要素自体の定義内に多重度または順序情報を含めないでください。 （4.6節）
6. Data type semantics should be defined, if appropriate. (Section 4.4) (tool support)
6. 必要に応じて、データ型のセマンティクスを定義する必要があります。 （4.4節）（ツールのサポート）
7. Units should be defined, if appropriate, with new units added to the Information Element Units subregistry if necessary. (Section 4.4) (tool support)
7. 必要に応じて、ユニットを定義し、新しいエレメントを情報要素ユニットサブレジストリに追加する必要があります。 （4.4節）（ツールのサポート）
8. Ranges should be defined, if appropriate. (Section 4.4) (tool support)
8. 必要に応じて、範囲を定義する必要があります。 （4.4節）（ツールのサポート）
9. Non-reversible Information Elements (see [RFC5103]) should note non-reversibility in the description. (Section 4.8)
9. 不可逆情報要素（[RFC5103]を参照）は、説明に不可逆性を記載する必要があります。 （セクション4.8）
10. Information Elements to be registered with IANA should be intended for implementation and deployment on production networks.
10. IANAに登録される情報要素は、実稼働ネットワークでの実装と展開を目的とする必要があります。
At the core of IPFIX is its definition of a Flow, a set of packets sharing some common properties crossing an Observation Point within a certain time window. However, the reliance on this definition does not preclude the application of IPFIX to domains that are not obviously handling Flow data according to this definition. Most network management data collection tasks, those to which IPFIX is most applicable, have at their core the movement of packets from one place to another; by a liberal interpretation of the common properties defining the Flow, then, almost any event handled by these can be held to concern data records conforming to the IPFIX definition of a Flow.
IPFIXの中核となるのは、フローの定義であり、特定の時間枠内で観測ポイントを通過するいくつかの共通のプロパティを共有する一連のパケットです。ただし、この定義への依存は、この定義に従ってフローデータを明らかに処理していないドメインへのIPFIXの適用を排除するものではありません。ほとんどのネットワーク管理データ収集タスク（IPFIXが最も適用されるタスク）は、ある場所から別の場所へのパケットの移動を中心に持っています。フローを定義する共通のプロパティを自由に解釈することにより、これらによって処理されるほとんどすべてのイベントを保持して、フローのIPFIX定義に準拠するデータレコードを考慮することができます。
Non-Flow information defining associations or key-value pairs, on the other hand, are defined by IPFIX Options Templates. Here, the Information Elements within an Options Template Record are divided into Scope Information Elements that define the key and non-scope Information Elements that define the values associated with that key. Unlike Flows, Data Records defined by Options Templates are not necessarily scoped in time; these Data Records are generally held to be in effect until a new set of values for a specific set of keys is exported. While this mechanism is often used by IPFIX to export metadata about the collection infrastructure, it is applicable to any association information.
一方、関連付けまたはキーと値のペアを定義する非フロー情報は、IPFIXオプションテンプレートによって定義されます。ここで、オプションテンプレートレコード内の情報要素は、キーを定義するスコープ情報要素と、そのキーに関連付けられた値を定義するスコープ以外の情報要素に分かれています。フローとは異なり、オプションテンプレートによって定義されたデータレコードは必ずしも時間範囲が限定されるわけではありません。これらのデータレコードは通常、特定のキーのセットの新しい値のセットがエクスポートされるまで有効に保持されます。このメカニズムは、コレクションインフラストラクチャに関するメタデータをエクスポートするためにIPFIXでよく使用されますが、あらゆる関連情報に適用できます。
An IPFIX application can mix Data Records described either type of template in an IPFIX Message or Message stream, and exploit relationships among the Flow Keys, values, and Scopes to create interrelated data structures. See [RFC5473] for an example application of this.
IPFIXアプリケーションは、IPFIXメッセージまたはメッセージストリーム内のいずれかのタイプのテンプレートで記述されたデータレコードを混合し、フローキー、値、およびスコープ間の関係を利用して、相互に関連するデータ構造を作成できます。この使用例については、[RFC5473]を参照してください。
When a new application is complex enough to require additional clarification or specification as to the use of the defined Information Elements, this may be given in an Internet-Draft.
新しいアプリケーションが、定義された情報要素の使用に関して追加の説明または仕様を必要とするほど複雑である場合、これはインターネットドラフトで提供される場合があります。
Internet-Drafts for new IPFIX applications are best submitted to a Working Group with expertise in the area of the new application, or to the Independent Submission stream.
新しいIPFIXアプリケーションのインターネットドラフトは、新しいアプリケーションの領域に関する専門知識を持つワーキンググループ、またはIndependent Submissionストリームに提出するのが最適です。
When defining new Information Elements in an Internet-Draft, the Internet-Draft should contain a section (or subsection) for each Information Element, which contains the attributes in Section 4 in human-readable form. An example subsection is given below. These Information Element descriptions should not assign Information Element numbers, instead using placeholder identifiers for these numbers (e.g., "TBD1", "TBD2", "TBD3") and a note to IANA in the IANA Considerations section to replace those placeholders in the document with Information Element numbers when the numbers are assigned. The use of these placeholder definitions allows references to the numbers in, e.g., box-and-line diagrams or template definitions as in Section 10.
Internet-Draftで新しい情報要素を定義する場合、Internet-Draftには、各情報要素のセクション（またはサブセクション）を含める必要があります。セクションには、セクション4の属性が人間が読める形式で含まれています。サブセクションの例を以下に示します。これらの情報要素の説明では、情報要素番号を割り当てないでください。代わりに、これらの番号のプレースホルダー識別子（「TBD1」、「TBD2」、「TBD3」など）を使用し、IANAの考慮事項セクションのIANAへのメモを使用して、ドキュメント内のそれらのプレースホルダーを置き換えます。番号が割り当てられている場合は、情報要素番号を使用します。これらのプレースホルダー定義を使用すると、セクション10のように、たとえば、箱ひげ図やテンプレート定義などの番号を参照できます。
This is an example of an Information Element definition that would appear in an Internet-Draft. The name appears in the section title.
これは、インターネットドラフトに表示される情報要素定義の例です。名前はセクションのタイトルに表示されます。
Description: Description goes here.; obligatory
説明：ここに説明を入力します。;義務的
Data Type: Data type goes here; obligatory
データ型：ここにデータ型が入ります。義務的
Data Type Semantics: Data type semantics, if any, go here; optional
データ型のセマンティクス：データ型のセマンティクス（存在する場合）、ここに移動します。オプション
Units: Units, if any, go here; optional
単位：単位がある場合は、ここに移動します。オプション
Range: Range, if not implied by the data type, goes here; optional
範囲：データ型によって暗示されない場合、ここに範囲が入ります。オプション
References: References to other RFCs or documents outside the IETF, in which additional information is given, or which are referenced by the description, go here; optional
参照：追加情報が記載されている、または説明によって参照されている、IETF以外の他のRFCまたはドキュメントへの参照は、こちらにアクセスしてください。オプション
ElementId: ElementId, if known, or "TBD" if it will be assigned by IANA and filled in at publication time.
ElementId：既知の場合はElementId、IANAによって割り当てられ、発行時に入力される場合は「TBD」。
New IPFIX applications should not, in the general case, define fixed templates for export, as this throws away much of the flexibility afforded by IPFIX. However, fixed template export is permissible in the case that the export implementation must operate in a resource-constrained environment, and/or that the application is replacing an existing fixed-format binary export format in a maximally compatible way. In any case, Collecting Processes for such applications should support the collection Templates with Information Elements in any order, or Templates with additional Information Elements.
新しいIPFIXアプリケーションは、一般的な場合、エクスポート用の固定テンプレートを定義しないでください。これにより、IPFIXによって提供される柔軟性の多くが失われます。ただし、エクスポートの実装がリソースに制約のある環境で動作する必要がある場合や、アプリケーションが既存の固定形式のバイナリエクスポート形式を最大限に互換性のある方法で置き換えている場合は、固定テンプレートのエクスポートが許可されます。いずれの場合も、そのようなアプリケーションの収集プロセスは、情報要素を任意の順序で含む収集テンプレート、または追加の情報要素を含むテンプレートをサポートする必要があります。
An Internet-Draft clarifying the use of new Information Elements should include any recommended Template or Options Template Records necessary for supporting the application, as well as examples of records exported using these Template Records. In defining these Template Records, such Internet-Drafts should mention, subject to rare exceptions:
新しい情報要素の使用を明確にするインターネットドラフトには、アプリケーションのサポートに必要な推奨テンプレートまたはオプションテンプレートレコード、およびこれらのテンプレートレコードを使用してエクスポートされたレコードの例を含める必要があります。これらのテンプレートレコードを定義する際に、このようなインターネットドラフトは、まれな例外を除いて、言及する必要があります。
1. that the order of different Information Elements within a Template is not significant;
1. テンプレート内のさまざまな情報要素の順序は重要ではありません。
2. that Templates on the wire for the application may also contain additional Information Elements beyond those specified in the recommended Template;
2. アプリケーションのネットワーク上のテンプレートには、推奨されるテンプレートで指定されたものを超える追加の情報要素が含まれる場合があります。
3. that a stream of IPFIX Messages supporting the application may also contain Data Records not described by the recommended Templates; and
3. アプリケーションをサポートするIPFIXメッセージのストリームには、推奨されるテンプレートで記述されていないデータレコードも含まれる可能性があること。そして
4. that any reader of IPFIX Messages supporting the application must accept these conditions.
4. アプリケーションをサポートするIPFIXメッセージのリーダーは、これらの条件を受け入れる必要があります。
Definitions of recommended Template Records for Flow-like information, where the Flow Key is well-defined, should indicate which of the Information Elements in the recommended Template are Flow Keys.
フローキーが明確に定義されているフローのような情報の推奨テンプレートレコードの定義は、推奨テンプレートのどの情報要素がフローキーであるかを示す必要があります。
Recommended Templates are defined, for example, in [RFC5476] for PSAMP packet reports (Section 6.4.1) and extended packet reports (Section 6.4.2). Recommended Options Templates are defined extensively throughout the IPFIX documents, including in the protocol document itself [RFC7011] for exporting export statistics; in the file format [RFC5655] for exporting file metadata; and in intermediate process definitions such as [RFC6235] for intermediate process metadata. The discussion in these examples is a good model for recommended template definitions.
推奨テンプレートは、たとえば、PSAMPパケットレポート（セクション6.4.1）および拡張パケットレポート（セクション6.4.2）の[RFC5476]で定義されています。推奨されるオプションテンプレートは、エクスポート統計をエクスポートするためのプロトコルドキュメント自体[RFC7011]を含め、IPFIXドキュメント全体に広く定義されています。ファイルメタデータをエクスポートするためのファイル形式[RFC5655]。中間プロセスメタデータの[RFC6235]などの中間プロセス定義。これらの例の説明は、推奨されるテンプレート定義の良いモデルです。
Example Templates given in existing IPFIX documents are generally expressed using bitmap diagrams of the respective Templates. These are illustrative of the wire representation of simple Templates, but not particularly readable for more complicated recommended Templates, provide no support for rapid implementation of new Templates, and do not adequately convey the optional nature of ordering and additional Information Elements. Therefore, we define a recommended textual format for specifying Information Elements and Templates in Internet-Drafts in this section.
既存のIPFIXドキュメントで提供されているテンプレートの例は、通常、それぞれのテンプレートのビットマップ図を使用して表現されています。これらは、単純なテンプレートのワイヤ表現を示していますが、より複雑な推奨テンプレートでは特に判読できず、新しいテンプレートの迅速な実装をサポートしておらず、順序付けや追加の情報要素のオプションの性質を適切に伝えていません。したがって、このセクションでは、インターネットドラフトで情報要素とテンプレートを指定するための推奨テキスト形式を定義します。
Here we define a simple textual syntax for describing IPFIX Information Elements and IPFIX Templates, with human readability, human writability, compactness, and ease of parser/generator implementation without requiring external XML support as design goals. It is intended for use both in human communication (e.g., in new Internet-Drafts containing higher-level descriptions of IPFIX Templates, or describing sets of new IPFIX Information Elements for supporting new applications of the protocol) as well as at runtime by IPFIX implementations.
ここでは、設計目標として外部XMLサポートを必要とせずに、人間の可読性、人間の書き込み可能性、コンパクトさ、およびパーサー/ジェネレーター実装の容易さを備えた、IPFIX情報要素およびIPFIXテンプレートを記述するための単純なテキスト構文を定義します。人間のコミュニケーション（IPFIXテンプレートの高レベルの記述を含む新しいインターネットドラフト、またはプロトコルの新しいアプリケーションをサポートするための新しいIPFIX情報要素のセットの記述など）と、実行時のIPFIX実装の両方での使用を目的としています。 。
The basis of this format is the textual Information Element Specifier, or IESpec. An IESpec contains each of the four important aspects of an Information Element: its name, its number, its type, and its size, separated by simple markup based on various types of brackets. Fully qualified IESpecs may be used to specify existing or new Information Elements within an Information Model, while either fully qualified or partial IESpecs may be used to define fields in a Template.
このフォーマットの基礎は、テキストの情報要素指定子、つまりIESpecです。 IESpecには、情報要素の4つの重要な側面（名前、番号、タイプ、およびサイズ）が含まれ、さまざまなタイプのブラケットに基づく単純なマークアップで区切られています。完全修飾IESpecを使用して、情報モデル内の既存または新規の情報要素を指定できます。一方、完全修飾または部分IESpecを使用して、テンプレートのフィールドを定義できます。
Bare words are used for Information Element names, and each aspect of information associated with an Information Element is associated with a type of brackets:
裸の単語は情報要素名に使用され、情報要素に関連付けられている情報の各側面は、角かっこの種類に関連付けられています。
o () parentheses for Information Element numbers,
o ()情報要素番号の括弧、
o <> angle brackets for Information Element data types, and
o <>情報要素データ型の山括弧、および
o [] square brackets for Information Element sizes.
o []情報要素サイズの角括弧。
o {} curly braces contain an optional space-separated list of context identifiers to be associated with an Information Element, as described in more detail in Section 10.2
o {}中括弧には、10.2項で詳しく説明するように、情報要素に関連付けられるコンテキスト識別子のオプションのスペース区切りリストが含まれます。
The symbol + is reserved for Information Elements nesting within structured data elements; these are described in Section 10.3.
記号+は、構造化データ要素内でネストする情報要素用に予約されています。これらについては、10.3項で説明しています。
Whitespace in IESpecs is insignificant; spaces can be added after each element in order, e.g., to align columns for better readability.
IESpecsの空白は重要ではありません。各要素の後にスペースを追加して、たとえば、列を揃えて読みやすくすることができます。
The basic form of a fully qualified IESpec for an IANA-registered Information Element is as follows:
IANA登録情報要素の完全修飾IESpecの基本形式は次のとおりです。
name(number)<type>[size]
where 'name' is the name of the Information Element in UTF-8, 'number' is the Information Element as a decimal integer, 'type' is the name of the data type as in the IANA informationElementDataTypes registry, and 'size' is the length of the Information Element in octets as a decimal integer, where 65535 or the string 'v' signifies a variable-length Information Element. [size] may be omitted. In this case, the data type's native or default size is assumed.
ここで、 'name'はUTF-8の情報要素の名前、 'number'は10進整数としての情報要素、 'type'はIANA informationElementDataTypesレジストリにあるようなデータタイプの名前、 'size'は10進整数としてのオクテット単位の情報要素の長さ。65535または文字列「v」は可変長の情報要素を示します。 【サイズ】は省略可能です。この場合、データ型のネイティブサイズまたはデフォルトサイズが想定されます。
The basic form of a fully qualified IESpec for an enterprise-specific Information Element is as follows:
企業固有の情報要素の完全修飾IESpecの基本形式は次のとおりです。
name(pen/number)<type>[size]
where 'pen' is the Private Enterprise Number as a decimal integer.
ここで、 'pen'は10進整数としての民間企業番号です。
A fully qualified IESpec is intended to express enough information about an Information Element to decode and display Data Records defined by Templates containing that Information Element. Range, unit, semantic, and description information, as in [RFC5610], is not supported by this syntax.
完全修飾IESpecは、情報要素に関する十分な情報を表現して、その情報要素を含むテンプレートによって定義されたデータレコードをデコードおよび表示することを目的としています。 [RFC5610]のように、範囲、単位、セマンティック、および説明情報は、この構文ではサポートされていません。
Example fully qualified IESpecs follow:
次に、完全修飾IESpecの例を示します。
octetDeltaCount(1)<unsigned64>[8]
octetDeltaCount(1)<unsigned64> (unsigned64 is natively 8 octets long)
octetDeltaCount（1）<unsigned64>（unsigned64は本来8オクテット長です）
sourceIPv4Address(8)<ipv4Address>
wlanSSID(146)<string>[v]
sipRequestURI(35566/403)<string>[65535]
A partial IESpec is any IESpec that is not fully qualified; these are useful when defining templates. A partial IESpec is assumed to take missing values from its canonical definition in the IANA IE registry. At minimum, a partial IESpec must contain a name, or a number. Any name, number, or type information given with a partial IESpec must match the values given in the Information Model; however, size information in a partial IESpec overrides size information in the Information Model; in this way, IESpecs can be used to express reduced-size encoding for Information Elements.
部分的なIESpecは、完全に修飾されていないIESpecです。これらは、テンプレートを定義するときに役立ちます。部分的なIESpecは、IANA IEレジストリの正規の定義から欠損値を取得すると想定されています。少なくとも、部分的なIESpecには名前または番号が含まれている必要があります。部分的なIESpecで指定された名前、番号、またはタイプ情報は、情報モデルで指定された値と一致する必要があります。ただし、部分的なIESpecのサイズ情報は、情報モデルのサイズ情報をオーバーライドします。このように、IESpecを使用して、情報要素の縮小サイズのエンコーディングを表現できます。
Example partial IESpecs follow:
次に、IESpecsの例の一部を示します。
o octetDeltaCount
o octetDeltaCount
o octetDeltaCount[4] (reduced-size encoding)
o octetDeltaCount [4]（縮小サイズのエンコード）
o (1)
o （１）
o (1)[4] (reduced-size encoding; note that this is exactly equivalent to an Information Element specifier in a Template)
o （1）[4]（縮小サイズのエンコーディング。これは、テンプレートの情報要素指定子とまったく同じであることに注意してください）
A Template can then be defined simply as an ordered, newline-separated sequence of IESpecs. IESpecs in example Templates illustrating a new application of IPFIX should be fully qualified. Flow Keys may be optionally annotated by appending the {key} context to the end of each Flow Key specifier. A template counting packets and octets per 5-tuple with millisecond precision in IESpec syntax is shown in Figure 1.
テンプレートは、IESpecの順序付けられた改行で区切られたシーケンスとして簡単に定義できます。 IPFIXの新しいアプリケーションを示すサンプルテンプレートのIESpecは完全に修飾する必要があります。フローキーには、各フローキー指定子の最後に{key}コンテキストを追加することで、オプションで注釈を付けることができます。 IESpec構文でミリ秒の精度で5タプルあたりのパケットとオクテットをカウントするテンプレートを図1に示します。
flowStartMilliseconds(152)<dateTimeMilliseconds>[8]
flowEndMilliseconds(153)<dateTimeMilliseconds>[8]
octetDeltaCount(1)<unsigned64>[8]
packetDeltaCount(2)<unsigned64>[8]
sourceIPv4Address(8)<ipv4Address>[4]{key}
destinationIPv4Address(12)<ipv4Address>[4]{key}
sourceTransportPort(7)<unsigned16>[2]{key}
destinationTransportPort(11)<unsigned16>[2]{key}
protocolIdentifier(4)<unsigned8>[1]{key}
Figure 1: Sample Flow Template in IESpec Syntax
図1：IESpec構文のサンプルフローテンプレート
An Options Template is specified similarly. Scope is specified appending the {scope} context to the end of each IESpec for a Scope IE. Due to the way Information Elements are represented in Options Templates, all {scope} IESpecs must appear before any non-scope IESpec. The Flow Key Options Template defined in Section 4.4 of [RFC7011] in IESpec syntax is shown in Figure 2.
オプションテンプレートも同様に指定します。スコープは、スコープIEの各IESpecの末尾に{scope}コンテキストを追加して指定されます。オプションテンプレートでの情報要素の表現方法により、すべての{scope} IESpecは、スコープ以外のIESpecよりも前に表示する必要があります。 IESpec構文の[RFC7011]のセクション4.4で定義されたフローキーオプションテンプレートを図2に示します。
templateId(145)<unsigned16>[2]{scope}
flowKeyIndicator(173)<unsigned64>[8]
Figure 2: Flow Key Options Template in IESpec Syntax
図2：IESpec構文のフローキーオプションテンプレート
IESpecs can also be used to illustrate the structure of the information exported using the IPFIX Structured Data extension [RFC6313]. Here, the semantics of the structured data elements are specified using contexts, and the Information Elements within each structured data element follow the structured data element, prefixed with + to show they are contained therein. Arbitrary nesting of structured data elements is possible by using multiple + signs in the prefix. For example, a basic list of IP addresses with "one or more" semantics would be expressed using partially qualified IESpecs as shown in Figure 3.
IESpecは、IPFIX構造化データ拡張[RFC6313]を使用してエクスポートされた情報の構造を示すためにも使用できます。ここで、構造化データ要素のセマンティクスはコンテキストを使用して指定され、各構造化データ要素内の情報要素は構造化データ要素の後に続きます。構造化データ要素の任意のネストは、接頭辞で複数の+記号を使用することで可能です。たとえば、「1つ以上の」セマンティクスを持つIPアドレスの基本的なリストは、図3に示すように、部分的に修飾されたIESpecを使用して表現されます。
basicList{oneOrMoreOf}
+sourceIPv4Address(8)[4]
Figure 3: Sample basicList in IESpec Syntax
図3：IESpec構文のサンプルbasicList
And an example subTemplateList itself containing a basicList is shown in Figure 4.
また、basicListを含むsubTemplateList自体の例を図4に示します。
subTemplateList{allOf}
+basicList{oneOrMoreOf}
++sourceIPv4Address(8)[4]
+destinationIPv4Address(12)[4]
Figure 4: Sample subTemplateList in IESpec Syntax
図4：IESpec構文のサンプルsubTemplateList
This describes a subTemplateMultilist containing all of the expressed set of source-destination pairs, where the source address itself could be one of any number in a basicList (e.g., in the case of SCTP multihoming).
これは、送信元と宛先のペアの表現されたセットのすべてを含むsubTemplateMultilistを記述します。ここで、送信元アドレス自体は、basicList内の任意の数の1つである可能性があります（たとえば、SCTPマルチホーミングの場合）。
The contexts associable with structured data Information Elements are the semantics, as defined in Section 4.4 of [RFC6313]; a structured data Information Element without any context is taken to have undefined semantics. More information on the application of structured data is available in [RFC6313].
[RFC6313]のセクション4.4で定義されているように、構造化データ情報要素に関連付けられるコンテキストはセマンティクスです。コンテキストのない構造化データ情報要素は、セマンティクスが未定義であると解釈されます。構造化データの適用に関する詳細情報は、[RFC6313]で入手できます。
The IE-DOCTORS must evaluate the security aspects of new Information Elements in light of the information they could provide to support potential attacks against the measured network or entities about which information is exported. Specific security aspects to evaluate include whether the exported information contains personally identifiable information, or information that should be kept confidential about the described entities (e.g., partial payload, or configuration information that could be exploited). This is not to say that such Information Elements should not be defined, but there must be an evaluation of the security risk versus the utility of the exported information for the intended application. For example, "A Framework for Packet Selection and Reporting" [RFC5474] concluded in Section 12.3.2 that the hash function's private parameters should not be exported within IPFIX.
IE-DOCTORSは、情報がエクスポートされる測定対象のネットワークまたはエンティティに対する潜在的な攻撃をサポートするために提供できる情報に照らして、新しい情報要素のセキュリティの側面を評価する必要があります。評価する特定のセキュリティの側面には、エクスポートされた情報に個人を特定できる情報が含まれているか、または説明されたエンティティーについて機密を保持する必要がある情報（部分的なペイロード、または悪用される可能性のある構成情報など）が含まれます。これは、そのような情報要素が定義されるべきではないということではありませんが、意図されたアプリケーションのためにエクスポートされた情報の有用性に対するセキュリティリスクの評価がなければなりません。たとえば、「パケットの選択とレポートのフレームワーク」[RFC5474]は、セクション12.3.2で、ハッシュ関数のプライベートパラメータはIPFIX内でエクスポートされるべきではないと結論付けました。
Security considerations specific to an Information Element must be addressed in the Security Considerations section of the Internet-Draft describing the Information Element, or in the Information Element description itself in case the Information Element is not defined in an Internet-Draft. Information Elements with specific security considerations should be described in an Internet-Draft.
情報要素に固有のセキュリティの考慮事項は、情報要素を説明するインターネットドラフトのセキュリティの考慮事項セクションで、または情報要素がインターネットドラフトで定義されていない場合は情報要素の説明自体で対処する必要があります。特定のセキュリティに関する考慮事項がある情報要素は、インターネットドラフトで説明する必要があります。
For example, the ipHeaderPacketSection in the IPFIX IE registry mentions: "This Information Element, which may have a variable length, carries a series of octets from the start of the IP header of a sampled packet. With sufficient length, this element also reports octets from the IP payload, subject to [RFC2804]. See the Security Considerations section". Another example can be seen in the "Packet Sampling (PSAMP) Protocols Specification" [RFC5476]: "In the basic Packet Report, a PSAMP Device exports some number of contiguous bytes from the start of the packet, including the packet header (which includes link layer, network layer, and other encapsulation headers) and some subsequent bytes of the packet payload. The PSAMP Device SHOULD NOT export the full payload of conversations, as this would mean wiretapping [RFC2804]. The PSAMP Device MUST respect local privacy laws."
たとえば、IPFIX IEレジストリのipHeaderPacketSectionには、次のように記述されています。 [RFC2804]に従い、IPペイロードから。「セキュリティに関する考慮事項」セクションを参照してください。別の例は、「Packet Sampling（PSAMP）Protocols Specification」[RFC5476]にあります。「基本的なパケットレポートでは、PSAMPデバイスは、パケットヘッダーを含む、パケットの先頭からいくつかの連続したバイトをエクスポートします（これには、リンクレイヤー、ネットワークレイヤー、およびその他のカプセル化ヘッダー）およびパケットペイロードの後続のいくつかのバイト。PSAMPデバイスは、盗聴[RFC2804]を意味するので、会話の完全なペイロードをエクスポートしないでください。 」
Thanks to Paul Aitken, Andrew Feren, Dan Romascanu, and David Harrington for their reviews and feedback. Thanks as well to Roni Even and Yoav Nir for their area reviews; and to Pete Resnick, Adrian Farrel, Stephen Farrell, Stewart Bryant, and Barry Leiba for their contributions during IESG discussions. This work is materially supported by the European Union Seventh Framework Programme under grant agreement 257315 (DEMONS).
レビューとフィードバックを提供してくれたPaul Aitken、Andrew Feren、Dan Romascanu、David Harringtonに感謝します。地域のレビューをしてくれたRoni EvenとYoav Nirにも感謝します。 IESGディスカッションでの貢献について、Pete Resnick、Adrian Farrel、Stephen Farrell、Stewart Bryant、Barry Leibaの各氏に感謝します。この作業は、助成金契約257315（悪魔）に基づく欧州連合第7フレームワークプログラムによって実質的にサポートされています。
[RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export Using IP Flow Information Export (IPFIX)", RFC 5103, January 2008.
[RFC5103] Trammell、B。およびE. Boschi、「IP Flow Information Export（IPFIX）を使用した双方向フローエクスポート」、RFC 5103、2008年1月。
[RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, "Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements", RFC 5610, July 2009.
[RFC5610] Boschi、E.、Trammell、B.、Mark、L。、およびT. Zseby、「Exporting Type Information for IP Flow Information Export（IPFIX）Information Elements」、RFC 5610、2009年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, "Export of Structured Data in IP Flow Information Export (IPFIX)", RFC 6313, July 2011.
[RFC6313] Claise、B.、Dhandapani、G.、Aitken、P。、およびS. Yates、「IP Flow Information Export（IPFIX）の構造化データのエクスポート」、RFC 6313、2011年7月。
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, September 2013.
[RFC7011] Claise、B。、編、Trammell、B。、編、およびP. Aitken、「フロー情報の交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、STD 77、RFC 7011、 2013年9月。
[RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, September 2013.
[RFC7012]クレイズ、B。、エド。およびB. Trammell、編、「IPフロー情報エクスポート（IPFIX）の情報モデル」、RFC 7012、2013年9月。
[RFC2804] IAB IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.
[RFC2804] IAB IESG、「IET Policy on Wiretapping」、RFC 2804、2000年5月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：セッション開始プロトコル」 、RFC 3261、2002年6月。
[RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, October 2004.
[RFC3954] Claise、B。、「Cisco Systems NetFlow Services Export Version 9」、RFC 3954、2004年10月。
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
[RFC5102] Quittek、J.、Bryant、S.、Claise、B.、Aitken、P。、およびJ. Meyer、「IPフロー情報エクスポートの情報モデル」、RFC 5102、2008年1月。
[RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, March 2009.
[RFC5472] Zseby、T.、Boschi、E.、Brownlee、N。、およびB. Claise、「IP Flow Information Export（IPFIX）Applicability」、RFC 5472、2009年3月。
[RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports", RFC 5473, March 2009.
[RFC5473] Boschi、E.、Mark、L。、およびB. Claise、「Reduce Redundancy in IP Flow Information Export（IPFIX）and Packet Sampling（PSAMP）Reports」、RFC 5473、2009年3月。
[RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A., Grossglauser, M., and J. Rexford, "A Framework for Packet Selection and Reporting", RFC 5474, March 2009.
[RFC5474] Duffield、N.、Chiou、D.、Claise、B.、Greenberg、A.、Grossglauser、M。、およびJ. Rexford、「A Framework for Packet Selection and Reporting」、RFC 5474、2009年3月。
[RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009.
[RFC5476] Claise、B.、Johnson、A。、およびJ. Quittek、「Packet Sampling（PSAMP）Protocol Specifications」、RFC 5476、2009年3月。
[RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric", RFC 5560, May 2009.
[RFC5560] Uijterwaal、H。、「A One-Way Packet Duplication Metric」、RFC 5560、2009年5月。
[RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, "Specification of the IP Flow Information Export (IPFIX) File Format", RFC 5655, October 2009.
[RFC5655] Trammell、B.、Boschi、E.、Mark、L.、Zseby、T。、およびA. Wagner、「Specification of the IP Flow Information Export（IPFIX）File Format」、RFC 5655、2009年10月。
[RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization Support", RFC 6235, May 2011.
[RFC6235] Boschi、E。およびB. Trammell、「IP Flow Anonymization Support」、RFC 6235、2011年5月。
[IANA-IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities", <http://www.iana.org/assignments/ipfix>.
[IANA-IPFIX] IANA、「IP Flow Information Export（IPFIX）Entities」、<http://www.iana.org/assignments/ipfix>。
This section contains a few example Information Element definitions as they would appear in an Internet-Draft. Note the conformance of these examples to the guidelines in Section 4.
このセクションには、インターネットドラフトに表示される情報要素の定義の例がいくつか含まれています。これらの例がセクション4のガイドラインに準拠していることに注意してください。
The sipResponseStatus Information Element (Appendix A.1) illustrates the addition of an Information Element representing Layer 7 application information, with a reference to the registry containing the allowable values. The duplicatePacketDeltaCount Information Element (Appendix A.2) illustrates the addition of a new metric, with a reference to the RFC defining the metric. The ambientTemperature Information Element (Appendix A.3) illustrates the addition of a new measured value outside the area of traditional networking applications.
sipResponseStatus情報要素（付録A.1）は、許容値を含むレジストリへの参照とともに、レイヤー7アプリケーション情報を表す情報要素の追加を示しています。 duplicatePacketDeltaCount情報要素（付録A.2）は、メトリックを定義するRFCへの参照とともに、新しいメトリックの追加を示しています。 ambientTemperature情報要素（付録A.3）は、従来のネットワークアプリケーションの領域外での新しい測定値の追加を示しています。
Description: The SIP Response code as an integer, as in the Response Codes registry at http://www.iana.org/assignments/sip-parameters defined in [RFC3261] and amended in subsequent RFCs. The presence of this Information Element in a SIP Message record marks it as describing a SIP response; if absent, the record describes a SIP request.
説明：[RFC3261]で定義され、後続のRFCで修正されたhttp://www.iana.org/assignments/sip-parametersの応答コードレジストリにあるような、整数としてのSIP応答コード。この情報要素がSIPメッセージレコードに存在すると、SIP応答を説明するものとしてマークされます。存在しない場合、レコードはSIP要求を示します。
Data Type: unsigned16
データ型：unsigned16
Data Type Semantics: identifier
データ型セマンティクス：識別子
References: [RFC3261]
参照：[RFC3261]
ElementId: TBD1
ElementId：TBD1
Replaces Enterprise-Specific Element: 35566 / 412
企業固有の要素を置き換えます：35566/412
Description: The number of uncorrupted and identical additional copies of each individual packet in the Flow arriving at the destination since the previous Data Record for this Flow (if any), as measured at the Observation Point. This is measured as the Type-P-one-way-packet-duplication metric defined in Section 3 of [RFC5560].
説明：観測ポイントで測定された、このフローの以前のデータレコード（存在する場合）以降の、宛先に到着するフロー内の各パケットの破損していない同一の追加コピーの数。これは、[RFC5560]のセクション3で定義されているType-P-one-way-packet-duplicationメトリックとして測定されます。
Data Type: unsigned64
データ型：unsigned64
Data Type Semantics: deltaCounter Units: packets
データ型セマンティクス：deltaCounter単位：パケット
References: [RFC5560]
参照：[RFC5560]
ElementId: TBD2
ElementId：TBD2
Description: An ambient temperature observed by measurement equipment at an Observation Point, positioned such that it measures the temperature of the surroundings (i.e., not including any heat generated by the measuring or measured equipment), expressed in degrees Celsius.
説明：周囲の温度を測定するように配置された観測点で測定機器によって観測された周囲温度（つまり、測定機器または測定機器によって生成された熱を含まない）。摂氏で表されます。
Data Type: float
データ型：float
Units: degrees Celsius
単位：摂氏
Range: -273.15 - +inf
ElementId: TBD3
ElementId：TBD3
Authors' Addresses
著者のアドレス
Brian Trammell Swiss Federal Institute of Technology Zurich Gloriastrasse 35 8092 Zurich Switzerland
ブライアントラメルスイス連邦工科大学チューリッヒGloriastrasse 35 8092チューリッヒスイス
Phone: +41 44 632 70 13
EMail: trammell@tik.ee.ethz.ch
Benoit Claise Cisco Systems, Inc. De Kleetlaan 6a b1 1831 Diegem Belgium
Benoit Claise Cisco Systems、Inc. De Kleetlaan 6a b1 1831 Diegem Belgium
Phone: +32 2 704 5622
EMail: bclaise@cisco.com