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
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）的产品。它代表了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.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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使用的数据导出格式的自描述性质，新信息元素的定义通常足以允许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测量或管理的协议或应用的技术细节。这种扩展是通过咨询IPFIX专家（非正式称为IE医生）实现的。它既为定义新信息元素的人提供指导，也为审查这些信息元素的IE医生提供指导。
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）“除非需要，否则不要定义信息元素”。
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.
本文件适用于两个不同的受众。对于定义新信息元素的用户，它提供了用于确定给定现有或新应用程序所需信息元素的规范和最佳实践，以及编写这些信息元素定义的说明，以及新申请所需支持文件的信息（直到并包括一份或多份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工作组内发布标准跟踪RFC来开展这些活动。
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]中的定义）。
[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.
或者，工作组或个人贡献者可以选择编写一份Internet草稿作为RFC发布，详细说明新的IPFIX应用程序。此类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 信息元素应该包含尽可能少的内部结构。与通过将内部结构叠加在简单数据类型（如octetArray）上来表示复杂信息不同，此类信息应使用多个简单信息元素来表示，以便并行导出或使用IPFIX结构化数据[RFC6313]，如第4.5节所述。IE-DOCTORS可以评估提议的IE的内部结构，着眼于互操作性和/或与现有方法的向后兼容性，以逐案导出类似数据。
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
新信息元素的定义需要一个描述性名称、来自IANA IE注册表中IPFIX数据类型子区的数据类型规范（在[RFC7012]中定义为自身可通过[RFC5226]标准行动扩展），以及以英语编写的可读说明。本节提供
guidelines on each of these components of an Information Element definition, referring to existing documentation such as [RFC7012] as appropriate.
关于信息元素定义的每个组件的指南，参考现有文档，如[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.
此外，与特定协议相关的新信息元素应在第一个单词中命名协议，以便于按名称搜索（例如，SIP方法的“sipMethod”，将在基于IPFIX的SIP日志格式中使用）。类似地，与特定应用程序相关的新信息元素应在第一个单词中命名该应用程序。
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 Subistry选择最合适的数据类型。根据[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.
表示具有自然宽度的整数值的信息元素应使用适当的整数值数据类型进行定义。这尤其适用于直接从测量协议中的固定宽度字段获取的值。例如，tcpControlBits（TCP标志字节）是无符号8，tcpSequenceNumber是无符号32。
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.
必须以适当的精度定义表示时间值的信息元素。例如，以二级精度测量的时间的信息元素应定义为具有dateTimeSeconds数据类型，而不是DateTimeMillicles。
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.
具有长度约束（固定长度、最小和/或最大长度）的字符串或八进制类型的信息元素必须在其描述中注明这些约束。
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.
不得使用字符串和八进制数组对使用多个信息元素和/或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].
标识符范围在1-127之间的信息元素保留为与NetFlow版本9中的相应字段兼容，如[RFC3954]所述。
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节所述的IANA IE注册表信息元素语义子区中的一个值，但须遵守[RFC5610]第3.10节中给出的限制；换句话说，语义和类型必须一致。
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信息元素单位子区。如果一个信息元素表示的数量单位尚未在此子区域中，则必须在将该信息元素添加到IANA IE注册表的同时将该单位添加到该子区域的单位中。请注意，[RFC5610]中定义的单位分区是在专家审查的基础上维护的。
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. 信息元素表示一组语义紧密相关的标志，其中将标志表示为单独的单字节布尔值将是低效的，并且应始终同时出现在数据记录中（例如，用于指定匿名化技术可选特征的匿名化标志信息元素）。
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.
作为信息元素分解的一个例子，考虑一个称为“端点”的应用层标识符，它表示{主机、端口、协议}元组。与分配不透明的结构化“源端点”信息元素不同，源端点应该由三个独立的信息元素表示：“源地址”、“源端口”、“传输协议”。在本例中，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:
一些信息元素可能以一个以外的多重性表示信息，即在要在单个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
1. 如[RFC7011]第8节所述：“如果模板中多次需要信息元素，则该信息元素的不同出现应遵循计量过程处理的逻辑顺序。”换句话说，在项目具有自然顺序的情况下（例如，它们在数据包中出现的顺序），并且每个记录的多重性相同，信息可以通过以下方式建模：
containing multiple instances of the Information Element representing a single item within the Template Record describing the Data Records.
包含信息元素的多个实例，表示描述数据记录的模板记录中的单个项。
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]扩展中使用。
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选项堆栈），则多项目结构可以导出为保存原始内容的可变长度八进制信息元素。
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
一般来说，IANA IE注册表中存在类似定义的信息元素，这为确定给定的拟议信息元素是否“适合”注册表提供了先例。事实上，本文件规定的规则可以是：
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注册表中有几个信息元素没有遵循信息元素设计中的最佳实践。
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（根据[RFC5103]复制八位DeltaCount及其反向），以及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信息元素提供了一个如何不执行此操作的示例：它们表示使用字符串的三状态枚举。在定义新的信息元素时，不应遵循这些信息元素设置的示例。
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
如第4.6节所述，信息元素定义不应包括任何有序性或多重性信息。IANA IE注册表中唯一的例子是以下分配的IPFIX信息元素列表：MPLSTACKELSTACKSECTION、mplsLabelStackSection2、mplsLabelStackSection3、mplsLabelStackSection4、mplsLabelStackSection5、mplsLabelStackSection6、mplsLabelStackSection7、mplsLabelStackSection8、mplsLabelStackSection9、，以及第10节。这些几乎相同的信息元素之间的唯一区别是MPLS堆栈中的位置。这种信息元素设计模式满足了IPFIX定义的早期要求，该要求没有被带入最终规范，即同一记录中的信息元素之间不允许存在语义依赖关系，因此在定义新的信息元素时不应遵循该要求。在这种情况下，由于MPLS堆栈的大小因流量而异
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.
如果支持，则应使用IPFIX结构化数据[RFC6313]将其导出为MPLS标签项的基本列表，或使用可变长度mplsLabelStackSection信息元素将其导出为原始MPLS标签堆栈。
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，IANA将请求转发给IESG指定的专家组（IE-医生）；这些是[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医生应努力及时完成转诊复查。如果请求可以接受，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共识。具体而言，IANA IE注册表中添加IETF共识的信息元素需要IETF共识进行修订或弃用。
Decisions by the IE-DOCTORS may be appealed as in Section 7 of [RFC5226].
如[RFC5226]第7节所述，可对IE-DOCTORS的决定提出上诉。
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医生必须首先保持互操作性。对已经使用的信息元素的更改只能以可互操作的方式进行；不能以允许与未更改的实现互操作的方式进行的必要更改必须导致弃用。
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. 它扩展信息元素的数据类型，而不更改其表示方式（例如，将unsigned32更改为unsigned64，就像先前更改selectorId一样）；或
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. 它定义了一个先前未定义的或保留的枚举值，或者在具有标志语义的信息元素中定义了一个或多个先前保留的位；或
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注册表中的每个信息元素都有一个修订号，从零开始。在此过程之后对信息元素的每次更改都会将修订号增加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
如第5.1节所示，将否决请求发送给IANA，IANA将其传递给IE-DOCTORS进行审查。不推荐信息元素时，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.
必须更新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
请注意，此最大化重用的指南并不意味着不应将表示与现有信息元素相同的数据包信息的信息元素添加到IANA IE注册表中。例如，考虑IPCopyService
(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.
（元素ID 5）、ipDiffServCodePoint（元素ID 98）和IPRecessence（元素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]地址和destinationIPv[46]地址。
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消息中，则可以使用基于封装的IPFIX消息中的导出时间头的时间戳（例如，flowStartTimeDeltaMicroseconds）。基于必须在由选项模板（例如flowStartSysUpTime）定义的单独数据记录中导出的信息的时间戳只能在为给定应用程序使用运行时定义的纪元的现有实践的上下文中使用。新应用程序应尽可能避免使用这些结构。
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.
新的信息要素；修订应遵循第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信息元素注册中心的新子注册中心，并根据专家审查进行修改[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应用程序的Internet草稿最好提交给在新应用程序领域具有专业知识的工作组，或独立提交流。
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.
在互联网草案中定义新的信息元素时，互联网草案应包含每个信息元素的一节（或小节），其中包含第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.
这是将出现在Internet草稿中的信息元素定义示例。该名称将显示在节标题中。
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分配并在发布时填写。
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
在一般情况下，新的IPFIX应用程序不应该定义用于导出的固定模板，因为这会丢掉IPFIX提供的大部分灵活性。但是，如果导出实现必须在资源受限的环境中运行，和/或应用程序正在以最大兼容的方式替换现有的固定格式二进制导出格式，则允许固定模板导出
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.
方法在任何情况下，此类应用程序的收集过程都应支持具有任意顺序的信息元素的收集模板，或具有附加信息元素的模板。
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.
例如，在[RFC5476]中为PSAMP数据包报告（第6.4.1节）和扩展数据包报告（第6.4.2节）定义了推荐模板。IPFIX文件中广泛定义了推荐选项模板，包括用于导出统计数据的协议文件本身[RFC7011]；文件格式为[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
现有IPFIX文档中给出的示例模板通常使用各自模板的位图图表示。这些示例说明了简单模板的有线表示，但对于更复杂的推荐模板，这些示例不是特别可读的，不支持快速实现新模板，并且没有充分传达订购和附加的可选性质
Information Elements. Therefore, we define a recommended textual format for specifying Information Elements and Templates in Internet-Drafts in this section.
信息要素。因此，我们在本节中定义了一种推荐的文本格式，用于在Internet草稿中指定信息元素和模板。
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.
在这里，我们定义了一个简单的文本语法来描述IPFIX信息元素和IPFIX模板，具有可读性、可写性、紧凑性和易于解析器/生成器实现，而不需要外部XML支持作为设计目标。它既可用于人与人之间的交流（例如，在包含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包含信息元素的四个重要方面：名称、编号、类型和大小，由基于各种括号类型的简单标记分隔。完全限定IESpec可用于指定信息模型中的现有或新信息元素，而完全限定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.
IESpec中的空白不重要；可以在每个元素后按顺序添加空格，例如，对齐列以提高可读性。
The basic form of a fully qualified IESpec for an IANA-registered Information Element is as follows:
IANA注册信息元素的完全合格IESpec的基本形式如下：
name(number)<type>[size]
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”是十进制整数形式的信息元素，“type”是IANA informationElementDataTypes注册表中数据类型的名称，“size”是十进制整数形式的八位字节形式的信息元素的长度，其中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]
name(pen/number)<type>[size]
where 'pen' is the Private Enterprise Number as a decimal integer.
其中，“pen”是作为十进制整数的私有企业编号。
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>[8]
octetDeltaCount(1)<unsigned64> (unsigned64 is natively 8 octets long)
octetDeltaCount（1）<unsigned64>（unsigned64本机为8个八位字节长）
sourceIPv4Address(8)<ipv4Address>
sourceIPv4Address(8)<ipv4Address>
wlanSSID(146)<string>[v]
wlanSSID(146)<string>[v]
sipRequestURI(35566/403)<string>[65535]
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:
部分IESpec的示例如下：
o octetDeltaCount
o 八进制计数
o octetDeltaCount[4] (reduced-size encoding)
o octetDeltaCount[4]（缩减大小编码）
o (1)
o (1)
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}
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之前。图2显示了[RFC7011]第4.4节中以IESpec语法定义的流键选项模板。
templateId(145)<unsigned16>[2]{scope}
flowKeyIndicator(173)<unsigned64>[8]
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]导出的信息的结构。这里，使用上下文指定结构化数据元素的语义，每个结构化数据元素中的信息元素跟随结构化数据元素，前缀为+表示它们包含在其中。通过在前缀中使用多个+符号，可以对结构化数据元素进行任意嵌套。例如，具有“一个或多个”语义的IP地址的基本列表将使用部分限定的IESpec表示，如图3所示。
basicList{oneOrMoreOf}
+sourceIPv4Address(8)[4]
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.
图4显示了一个包含basicList的示例子模板。
subTemplateList{allOf}
+basicList{oneOrMoreOf}
++sourceIPv4Address(8)[4]
+destinationIPv4Address(12)[4]
subTemplateList{allOf}
+basicList{oneOrMoreOf}
++sourceIPv4Address(8)[4]
+destinationIPv4Address(12)[4]
Figure 4: Sample subTemplateList in IESpec Syntax
图4:IESpec语法中的子模板列表示例
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).
这描述了一个包含所有源-目的地对表达集的子模板多列表，其中源地址本身可以是基本列表中的任意数字之一（例如，在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
IE-DOCTORS必须根据他们可以提供的信息评估新信息元素的安全方面，以支持针对被测网络或导出信息的实体的潜在攻击。要评估的特定安全方面包括导出的信息是否包含个人识别信息，或关于所述实体应保密的信息（例如，部分有效载荷，或
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.
可能被利用的配置信息）。这并不是说不应定义此类信息元素，但必须评估安全风险与导出信息对预期应用程序的效用。例如，“数据包选择和报告框架”[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提到：“此信息元素可能具有可变长度，从采样数据包的IP报头开始携带一系列八位字节。如果长度足够，此元素还报告IP有效负载中的八位字节，但需遵守[RFC2804]。请参阅“安全注意事项”一节。另一个例子可以在“数据包采样（PSAMP）协议规范”[RFC5476]：“在基本数据包报告中，PSAMP设备从数据包开始导出一些连续字节，包括数据包头（包括链路层、网络层和其他封装头）以及数据包负载的一些后续字节。PSAMP设备不应导出会话的完整负载，因为这意味着窃听[RFC2804]。PSAMP设备必须遵守当地隐私法。”
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讨论中的贡献。这项工作得到了欧盟第七框架计划257315赠款协议（DEMONS）的实质性支持。
[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流量信息导出（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，“为IP流信息导出（IPFIX）信息元素导出类型信息”，RFC 56102009年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，“在RFCs中编写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流信息导出（IPFIX）中结构化数据的导出”，RFC 63132011年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.，Ed.，Trammell，B.，Ed.，和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]Claise，B.，Ed.和B.Trammell，Ed.，“IP流信息导出（IPFIX）的信息模型”，RFC 7012，2013年9月。
[RFC2804] IAB IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.
[RFC2804]IAB IESG，“IETF关于窃听的政策”，RFC 28042000年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服务导出版本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]Quitek，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流信息导出（IPFIX）适用性”，RFC 54722009年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，“减少IP流信息导出（IPFIX）和数据包采样（PSAMP）报告中的冗余”，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]N.Duffield、Chiou、D.Claise、B.Greenberg、A.Grossglauser、M.和J.Rexford，“数据包选择和报告框架”，RFC 54742009年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，“数据包采样（PSAMP）协议规范”，RFC 54762009年3月。
[RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric", RFC 5560, May 2009.
[RFC5560]Uijterwaal，H.，“单向数据包复制度量”，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，“IP流信息导出（IPFIX）文件格式规范”，RFC 56552009年10月。
[RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization Support", RFC 6235, May 2011.
[RFC6235]Boschi，E.和B.Trammell，“IP流匿名化支持”，RFC 62352011年5月。
[IANA-IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities", <http://www.iana.org/assignments/ipfix>.
[IANA-IPFIX]IANA，“IP流信息导出（IPFIX）实体”<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.
本节包含一些示例信息元素定义，它们将出现在Internet草稿中。注意这些示例与第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。环境温度信息元素（附录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.
描述：SIP响应代码为整数，如位于的响应代码注册表中所示http://www.iana.org/assignments/sip-parameters 在[RFC3261]中定义，并在随后的RFC中修订。SIP消息记录中该信息元素的存在将其标记为描述SIP响应；如果不存在，则记录描述SIP请求。
Data Type: unsigned16
数据类型：unsigned16
Data Type Semantics: identifier
数据类型语义：标识符
References: [RFC3261]
参考文献：[RFC3261]
ElementId: TBD1
元素ID: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节中定义的P型单向数据包复制度量进行测量的。
Data Type: unsigned64
数据类型：unsigned64
Data Type Semantics: deltaCounter
数据类型语义：deltaCounter
Units: packets
单位：小包
References: [RFC5560]
参考文献：[RFC5560]
ElementId: TBD2
元素ID: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
Range: -273.15 - +inf
ElementId: TBD3
元素ID:TBD3
Authors' Addresses
作者地址
Brian Trammell Swiss Federal Institute of Technology Zurich Gloriastrasse 35 8092 Zurich Switzerland
Brian Trammell瑞士联邦理工学院苏黎世Gloriastrasse 35 8092瑞士苏黎世
Phone: +41 44 632 70 13
EMail: trammell@tik.ee.ethz.ch
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比利时
Phone: +32 2 704 5622
EMail: bclaise@cisco.com
Phone: +32 2 704 5622
EMail: bclaise@cisco.com