doc: Add RFC documents

1 files changed, 1795 insertions, 0 deletions

diff --git a/doc/rfc/rfc7013.txt b/doc/rfc/rfc7013.txt
new file mode 100644
index 0000000..ac6948a
--- /dev/null
+++ b/doc/rfc/rfc7013.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+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
+
+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.
+
+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.
+
+   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.
+
+Copyright Notice
+
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   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.
+
+
+
+
+Trammell & Claise         Best Current Practice                 [Page 1]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+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
+
+
+
+
+
+
+
+
+Trammell & Claise         Best Current Practice                 [Page 2]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+1.  Introduction
+
+   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.
+
+   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.
+
+   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.1.  Intended Audience and Usage
+
+   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.
+
+   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.
+
+   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
+
+
+
+
+
+Trammell & Claise         Best Current Practice                 [Page 3]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+   to guide experts when reviewing additions or changes to the
+   Information Elements in the registry under Expert Review (as defined
+   in [RFC5226]).
+
+1.2.  Overview of Relevant IPFIX Documents
+
+   [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.
+
+   [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.
+
+   [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.
+
+   [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.
+
+2.  Terminology
+
+   Capitalized terms used in this document that are defined in the
+   Terminology section of [RFC7011] are to be interpreted as defined
+   there.
+
+   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.
+
+   "IANA IE registry", as used in this document, unless otherwise noted,
+   refers to the IANA IPFIX Information Element Registry [IANA-IPFIX].
+
+
+
+Trammell & Claise         Best Current Practice                 [Page 4]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+3.  How to Apply 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:
+
+   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  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  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  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).
+
+   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.
+
+   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.
+
+
+
+
+
+Trammell & Claise         Best Current Practice                 [Page 5]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+   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.
+
+4.  Defining New Information Elements
+
+   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:
+
+   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  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  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.
+
+   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
+
+
+
+
+
+Trammell & Claise         Best Current Practice                 [Page 6]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+   guidelines on each of these components of an Information Element
+   definition, referring to existing documentation such as [RFC7012] as
+   appropriate.
+
+4.1.  Information Element Naming
+
+   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  must be unique within the IANA IE registry.
+
+   o  start with lowercase letters.
+
+   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".
+
+   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.
+
+4.2.  Information Element Data Types
+
+   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].
+
+   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.
+
+
+
+
+
+Trammell & Claise         Best Current Practice                 [Page 7]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+4.3.  Information Element Numbering
+
+   Each Information Element has a unique identifier in the IANA
+   registry.
+
+   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.
+
+
+
+
+Trammell & Claise         Best Current Practice                 [Page 8]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+   Information Elements with identifiers in the range 1-127 are reserved
+   for compatibility with corresponding fields in NetFlow version 9, as
+   described in [RFC3954].
+
+4.4.  Ancillary Information Element Properties
+
+   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.
+
+   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.
+
+   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.
+
+4.5.  Internal Structure in Information Elements
+
+   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).
+
+   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).
+
+   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).
+
+
+
+Trammell & Claise         Best Current Practice                 [Page 9]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+   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.
+
+   Additional exceptions to the above list should be made through
+   publication of an 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.
+
+   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.
+
+   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.
+
+4.6.  Information Element Multiplicity
+
+   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.  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
+
+
+
+Trammell & Claise         Best Current Practice                [Page 10]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+       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.
+
+   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.
+
+   Specifically, a new Information Element should not encode any
+   multiplicity or ordinality information into the definition of the
+   Information Element itself.
+
+4.7.  Enumerated Values and Subregistries
+
+   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].
+
+4.8.  Reversibility as per RFC 5103
+
+   [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.
+
+   New non-reversible Information Elements must contain a note in the
+   description stating that they are not reversible.
+
+4.9.  Avoiding Bad Ideas in Information Element Design
+
+   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
+
+
+
+Trammell & Claise         Best Current Practice                [Page 11]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+   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.
+
+   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.
+
+   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).
+
+   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.
+
+   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
+
+
+
+Trammell & Claise         Best Current Practice                [Page 12]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+   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.
+
+5.  The Information Element Life Cycle
+
+   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.
+
+5.1.  The Process for Review by the IE-DOCTORS
+
+   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.
+
+   Authors are expected to review compliance with the specifications in
+   this document to check their submissions before sending them to 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.
+
+   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.
+
+   Decisions by the IE-DOCTORS may be appealed as in Section 7 of
+   [RFC5226].
+
+
+
+
+
+
+
+
+Trammell & Claise         Best Current Practice                [Page 13]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+5.2.  Revising Information Elements
+
+   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.
+
+   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.
+
+   Changes are initiated by sending a new Information Element definition
+   to IANA, as in Section 5.1, for an already-existing Information
+   Element.
+
+   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.
+
+   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
+
+   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
+
+   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
+
+   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
+
+
+
+
+Trammell & Claise         Best Current Practice                [Page 14]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+   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
+
+   6.  it expands the set of permissible values in the Information
+       Element's range; or
+
+   7.  it harmonizes with an external reference that was itself
+       corrected.
+
+   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.
+
+   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.
+
+   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.
+
+5.3.  Deprecating Information Elements
+
+   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
+
+   2.  the deprecation harmonizes with an external reference that was
+       itself deprecated through that reference's accepted deprecation
+       method; or
+
+   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.
+
+   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
+
+
+
+
+Trammell & Claise         Best Current Practice                [Page 15]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+   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.
+
+   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.
+
+6.  When Not to Define New Information Elements
+
+   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.
+
+   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.
+
+6.1.  Maximizing Reuse of Existing Information Elements
+
+   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.
+
+   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
+
+
+
+Trammell & Claise         Best Current Practice                [Page 16]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+   (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.
+
+   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.
+
+   Applications dealing with bidirectional interactions should use
+   Bidirectional Flow Support for IPFIX [RFC5103] to represent these
+   interactions.
+
+   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).
+
+   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.
+
+
+
+
+
+
+Trammell & Claise         Best Current Practice                [Page 17]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+6.2.  Applying Enterprise-Specific Information Elements
+
+   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.
+
+   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:
+
+   o  export of implementation-specific information, or
+
+   o  export of information supporting research or experiments within a
+      single organization or closed community, or
+
+   o  export of information derived in a commercially sensitive or
+      proprietary method, or
+
+   o  export of information or meta-information specific to a
+      commercially sensitive or proprietary application.
+
+   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.
+
+   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.
+
+7.  Information Element Definition Checklist
+
+   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
+
+
+
+
+
+Trammell & Claise         Best Current Practice                [Page 18]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+   new Information Elements; revision should follow the process defined
+   in Section 5.2, and deprecation should follow the process defined in
+   Section 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.
+
+   Checklist 1 contains conditions that must be met by all proposed
+   Information Elements:
+
+   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)
+
+   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)
+
+   3.  The name must start with a lowercase letter. (Section 4.1) (tool
+       support)
+
+   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)
+
+   5.  The data type must match the type of the data being represented.
+       (Section 4.2)
+
+   6.  Data type semantics must be appropriate for the data type.
+       (Section 4.4) (tool support)
+
+   7.  The Information Element identifier assigned by IANA must be
+       unique. (Section 4.3) (tool support)
+
+   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)
+
+
+
+Trammell & Claise         Best Current Practice                [Page 19]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+   Checklist 2 contains conditions that must be met by proposed
+   Information Elements with certain properties, as noted:
+
+   1.  Time values must be defined with appropriate precision.
+       (Section 4.2)
+
+   2.  Strings and octet arrays with length restrictions must note those
+       length restrictions in their descriptions. (Section 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)
+
+   Checklist 3 contains conditions that should be met by proposed
+   Information Elements:
+
+   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)
+
+   2.   Information Elements representing integral values should use a
+        data type for the appropriate width for the value.
+        (Section 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)
+
+   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)
+
+   5.   An Information Element should not contain multiplicity or
+        ordinality information within the definition of the Information
+        Element itself. (Section 4.6)
+
+   6.   Data type semantics should be defined, if appropriate.
+        (Section 4.4) (tool support)
+
+   7.   Units should be defined, if appropriate, with new units added to
+        the Information Element Units subregistry if necessary.
+        (Section 4.4) (tool support)
+
+
+
+
+Trammell & Claise         Best Current Practice                [Page 20]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+   8.   Ranges should be defined, if appropriate. (Section 4.4) (tool
+        support)
+
+   9.   Non-reversible Information Elements (see [RFC5103]) should note
+        non-reversibility in the description. (Section 4.8)
+
+   10.  Information Elements to be registered with IANA should be
+        intended for implementation and deployment on production
+        networks.
+
+8.  Applying IPFIX to Non-Flow Applications
+
+   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.
+
+   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.
+
+   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.
+
+9.  Writing Internet-Drafts for IPFIX Applications
+
+   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.
+
+
+
+
+Trammell & Claise         Best Current Practice                [Page 21]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+   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.
+
+   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.
+
+9.1.  Example Information Element Definition
+
+   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
+
+   ElementId:   ElementId, if known, or "TBD" if it will be assigned by
+      IANA and filled in at publication time.
+
+9.2.  Defining Recommended Templates
+
+   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
+
+
+
+
+Trammell & Claise         Best Current Practice                [Page 22]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+   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;
+
+   2.  that Templates on the wire for the application may also contain
+       additional Information Elements beyond those specified in the
+       recommended Template;
+
+   3.  that a stream of IPFIX Messages supporting the application may
+       also contain Data Records not described by the recommended
+       Templates; and
+
+   4.  that any reader of IPFIX Messages supporting the application must
+       accept these conditions.
+
+   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.
+
+10.  A Textual Format for Specifying Information Elements and Templates
+
+   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
+
+
+
+Trammell & Claise         Best Current Practice                [Page 23]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+   Information Elements.  Therefore, we define a recommended textual
+   format for specifying Information Elements and Templates in Internet-
+   Drafts in this section.
+
+   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.
+
+10.1.  Information Element Specifiers
+
+   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.
+
+   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  <> angle brackets for Information Element data types, and
+
+   o  [] square brackets for Information Element sizes.
+
+   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
+
+   The symbol + is reserved for Information Elements nesting within
+   structured data elements; these are described in Section 10.3.
+
+   Whitespace in IESpecs is insignificant; spaces can be added after
+   each element in order, e.g., to align columns for better readability.
+
+
+
+
+
+
+
+Trammell & Claise         Best Current Practice                [Page 24]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+   The basic form of a fully qualified IESpec for an IANA-registered
+   Information Element is as follows:
+
+   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.
+
+   The basic form of a fully qualified IESpec for an enterprise-specific
+   Information Element is as follows:
+
+   name(pen/number)<type>[size]
+
+   where 'pen' is the Private Enterprise Number as a decimal integer.
+
+   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.
+
+   Example fully qualified IESpecs follow:
+
+      octetDeltaCount(1)<unsigned64>[8]
+
+      octetDeltaCount(1)<unsigned64> (unsigned64 is natively 8 octets
+      long)
+
+      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.
+
+
+
+Trammell & Claise         Best Current Practice                [Page 25]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+   Example partial IESpecs follow:
+
+   o  octetDeltaCount
+
+   o  octetDeltaCount[4] (reduced-size encoding)
+
+   o  (1)
+
+   o  (1)[4] (reduced-size encoding; note that this is exactly
+      equivalent to an Information Element specifier in a Template)
+
+10.2.  Specifying Templates
+
+   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.
+
+   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
+
+   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.
+
+   templateId(145)<unsigned16>[2]{scope}
+   flowKeyIndicator(173)<unsigned64>[8]
+
+      Figure 2: Flow Key Options Template in IESpec Syntax
+
+
+
+
+
+
+
+Trammell & Claise         Best Current Practice                [Page 26]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+10.3.  Specifying IPFIX Structured Data
+
+   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.
+
+   basicList{oneOrMoreOf}
+   +sourceIPv4Address(8)[4]
+
+      Figure 3: Sample basicList in IESpec Syntax
+
+   And an example subTemplateList itself containing a basicList is shown
+   in Figure 4.
+
+   subTemplateList{allOf}
+   +basicList{oneOrMoreOf}
+   ++sourceIPv4Address(8)[4]
+   +destinationIPv4Address(12)[4]
+
+      Figure 4: Sample subTemplateList in IESpec Syntax
+
+   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).
+
+   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].
+
+11.  Security Considerations
+
+   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
+
+
+
+Trammell & Claise         Best Current Practice                [Page 27]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+   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.
+
+   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."
+
+12.  Acknowledgments
+
+   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).
+
+
+
+
+
+
+
+
+
+
+
+
+Trammell & Claise         Best Current Practice                [Page 28]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+13.  References
+
+13.1.  Normative References
+
+   [RFC5103]  Trammell, B. and E. Boschi, "Bidirectional Flow Export
+              Using IP Flow Information Export (IPFIX)", RFC 5103,
+              January 2008.
+
+   [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.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              May 2008.
+
+   [RFC6313]  Claise, B., Dhandapani, G., Aitken, P., and S. Yates,
+              "Export of Structured Data in IP Flow Information Export
+              (IPFIX)", RFC 6313, July 2011.
+
+   [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.
+
+   [RFC7012]  Claise, B., Ed. and B. Trammell, Ed., "Information Model
+              for IP Flow Information Export (IPFIX)", RFC 7012,
+              September 2013.
+
+13.2.  Informative References
+
+   [RFC2804]  IAB IESG, "IETF Policy on Wiretapping", RFC 2804, May
+              2000.
+
+   [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.
+
+   [RFC3954]  Claise, B., "Cisco Systems NetFlow Services Export Version
+              9", RFC 3954, October 2004.
+
+   [RFC5102]  Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
+              Meyer, "Information Model for IP Flow Information Export",
+              RFC 5102, January 2008.
+
+
+
+
+
+
+Trammell & Claise         Best Current Practice                [Page 29]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+   [RFC5472]  Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP
+              Flow Information Export (IPFIX) Applicability", RFC 5472,
+              March 2009.
+
+   [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.
+
+   [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.
+
+   [RFC5476]  Claise, B., Johnson, A., and J. Quittek, "Packet Sampling
+              (PSAMP) Protocol Specifications", RFC 5476, March 2009.
+
+   [RFC5560]  Uijterwaal, H., "A One-Way Packet Duplication Metric", RFC
+              5560, May 2009.
+
+   [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.
+
+   [RFC6235]  Boschi, E. and B. Trammell, "IP Flow Anonymization
+              Support", RFC 6235, May 2011.
+
+   [IANA-IPFIX]
+              IANA, "IP Flow Information Export (IPFIX) Entities",
+              <http://www.iana.org/assignments/ipfix>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Trammell & Claise         Best Current Practice                [Page 30]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+Appendix A.  Example Information Element Definitions
+
+   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.
+
+   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.
+
+A.1.  sipResponseStatus
+
+   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.
+
+   Data Type:   unsigned16
+
+   Data Type Semantics:   identifier
+
+   References:   [RFC3261]
+
+   ElementId:   TBD1
+
+   Replaces Enterprise-Specific Element:  35566 / 412
+
+A.2.  duplicatePacketDeltaCount
+
+   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].
+
+   Data Type:   unsigned64
+
+   Data Type Semantics:   deltaCounter
+
+
+
+
+Trammell & Claise         Best Current Practice                [Page 31]
+
+RFC 7013                    IPFIX IE-DOCTORS              September 2013
+
+
+   Units:   packets
+
+   References:   [RFC5560]
+
+   ElementId:   TBD2
+
+A.3.  ambientTemperature
+
+   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
+
+   Units:   degrees Celsius
+
+   Range:   -273.15 - +inf
+
+   ElementId:   TBD3
+
+Authors' Addresses
+
+   Brian Trammell
+   Swiss Federal Institute of Technology Zurich
+   Gloriastrasse 35
+   8092 Zurich
+   Switzerland
+
+   Phone: +41 44 632 70 13
+   EMail: trammell@tik.ee.ethz.ch
+
+
+   Benoit Claise
+   Cisco Systems, Inc.
+   De Kleetlaan 6a b1
+   1831 Diegem
+   Belgium
+
+   Phone: +32 2 704 5622
+   EMail: bclaise@cisco.com
+
+
+
+
+
+
+
+
+
+Trammell & Claise         Best Current Practice                [Page 32]
+