[IPFIX] draft-ietf-ipfix-ie-doctors-02 review
Paul Aitken <[email protected]>
| Newsgroups | gmane.ietf.ipfix |
|---|---|
| Message-ID | <[email protected]> |
Brian, all,
While reviewing draft-ietf-ipfix-ie-doctors-03 I've found several issues
which I thought I had already pointed out.
I discovered that I reviewed -02 in April, though only up to section 6 -
and therefore never sent my feedback.
Here's what I had; feedback on -03 is coming.
P.
Here's a review of draft-ietf-ipfix-ie-doctors-02.
I have several concerns with the document (marked **), together with
some editorial comments.
Please see inline.
P.
> IPFIX Working Group B. Trammell
> Internet-Draft ETH Zurich
> Intended status: BCP B. Claise
> Expires: September 8, 2012 Cisco Systems, Inc.
> March 7, 2012
>
>
> Guidelines for Authors and Reviewers of IPFIX Information Elements
> draft-ietf-ipfix-ie-doctors-02.txt
>
> Abstract
>
> This document provides guidelines for the definition of IPFIX
> Information Elements for addition to the IANA IPFIX Information
> Element registry, in order to extend the applicability of the IPFIX
> protocol to new operations and management areas.
>
> Status of this Memo
>
> This Internet-Draft is submitted in full conformance with the
> provisions of BCP 78 and BCP 79.
>
> Internet-Drafts are working documents of the Internet Engineering
> Task Force (IETF). Note that other groups may also distribute
> working documents as Internet-Drafts. The list of current Internet-
> Drafts is athttp://datatracker.ietf.org/drafts/current/.
>
> Internet-Drafts are draft documents valid for a maximum of six months
> and may be updated, replaced, or obsoleted by other documents at any
> time. It is inappropriate to use Internet-Drafts as reference
> material or to cite them other than as "work in progress."
>
> This Internet-Draft will expire on September 8, 2012.
>
> Copyright Notice
>
> Copyright (c) 2012 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 Expires September 8, 2012 [Page 1]
>
> Internet-Draft IPFIX IE-DOCTORS March 2012
>
>
> 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. Promotion of Enterprise-Specific Information Elements . . 11
> 4.10. Avoiding Bad Ideas in Information Element Design . . . . . 12
> 5. The Information Element Lifecycle . . . . . . . . . . . . . . 13
> 5.1. The IE-DOCTORS process . . . . . . . . . . . . . . . . . . 13
> 5.2. Revising Information Elements . . . . . . . . . . . . . . 14
> 5.3. Deprecating Information Elements . . . . . . . . . . . . . 15
> 5.4. Versioning the entire IANA Registry . . . . . . . . . . . 16
> 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 . . . . . . . . 22
> 9.1. Example Information Element Definition . . . . . . . . . . 22
> 9.2. Defining Recommended Templates . . . . . . . . . . . . . . 23
> 10. A Textual Format for Specifying Information Elements and
> Templates . . . . . . . . . . . . . . . . . . . . . . . . . . 24
> 10.1. Information Element Specifiers . . . . . . . . . . . . . . 24
> 10.2. Specifying Templates . . . . . . . . . . . . . . . . . . . 26
> 10.3. Specifying IPFIX Structured Data . . . . . . . . . . . . . 27
> 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27
> 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
> 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
> 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
> 14.1. Normative References . . . . . . . . . . . . . . . . . . . 29
> 14.2. Informative References . . . . . . . . . . . . . . . . . . 30
> Appendix A. Example Information Element Definitions . . . . . . . 31
> A.1. sipResponseStatus . . . . . . . . . . . . . . . . . . . . 31
> A.2. duplicatePacketDeltaCount . . . . . . . . . . . . . . . . 31
> A.3. ambientTemperature . . . . . . . . . . . . . . . . . . . . 32
> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
>
>
>
>
> Trammell& Claise Expires September 8, 2012 [Page 2]
>
> Internet-Draft IPFIX IE-DOCTORS March 2012
>
>
> 1. Introduction
>
> This document provides guidelines for the extension of the
> applicability of the IP Flow Information Export (IPFIX) protocol to
> network operations and management purposes outside the initial scope
> defined in "IPFIX Applicability Statement" [RFC5472]. These new
> applications are largely defined by creating new Information Elements
> beyond those in the IANA IPFIX Information Element Registry
> [iana-ipfix-assignments]. New applications may be further specified
> through additional RFCs defining and describing their usage.
>
> We intend this document to enable the expansion of the applicability
> of IPFIX to new areas by experts in the working group or area
> directorate concerned with the technical details of the protocol or
> application to be measured or managed using IPFIX. This expansion
> would occur 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.
>
> 1.1. Intended Audience and Usage
>
> This document is meant for two separate audiences. For IETF
> contributors extending the applicability of IPFIX, it provides
> specifications and best practices to be used in deciding which
> Information Elements are necessary for a given existing or new
> application, defining these Information Elements, and deciding
> whether an RFC should be published to further describe the
> application. For the IPFIX experts appointed as IE-Doctors, and for
> IANA personnel changing the Information Element registry, it defines
Consistently say "IANA registry" or "IANA IPFIX Information Element
registry", else clarify each instance of "registry" with
"[iana-ipfix-assignments]".
See below for a note on "IANA registry".
> 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 by the IPFIX Working Group.
>
> This document, together with
> [I-D.ietf-ipfix-information-model-rfc5102bis], defines the procedures
> for management of the IANA IPFIX Information Element Registry
> [iana-ipfix-assignments]. The practices outlined in this document
> are intended to guide experts when reviewing additions or changes to
> the Information Elements in the registry under Expert Review as
eg here you said "registry" without saying either IANA or
[iana-ipfix-assignments]. So which registry are you talking about?
> defined in [RFC5226].
>
>
>
>
>
>
>
> Trammell& Claise Expires September 8, 2012 [Page 3]
>
> Internet-Draft IPFIX IE-DOCTORS March 2012
>
>
> 1.2. Overview of relevant IPFIX documents
>
> [I-D.ietf-ipfix-protocol-rfc5101bis] 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.
>
> [I-D.ietf-ipfix-information-model-rfc5102bis] defines the basis of
> the IPFIX Information Model, referring to [iana-ipfix-assignments]
> for the specific Information Element definitions. It states that new
> Information Elements may be added to the Information Model on Expert
> Review basis, 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
Be careful with "this document" (above, twice), because it's not clear
whether you mean 5102bis or IE-doctors.
> 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
Again, "this document" is ambiguous.
> 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.
Again...
> [RFC5610] defines a method for exporting information about
> Information Elements inline within IPFIX. In doing so, it explicitly
> defines a set of restrictions on the use of data types and semantics
> which are implied in [I-D.ietf-ipfix-protocol-rfc5101bis] and
Is it the restrictions or the (data types and semantics) which are implied?
> [I-D.ietf-ipfix-information-model-rfc5102bis]; 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 [I-D.ietf-ipfix-protocol-rfc5101bis] 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, beyond those within the IPFIX Applicability
> statement [RFC5472]. By this definition, PSAMP [RFC5476] was the
> first new IPFIX application after the publication of the IPFIX
> protocol itself.
>
> "IANA registry", as used in this document, unless otherwise noted,
IANA has lots of registries, even for IPFIX, so it'd be good to
explicitly call out the registy in the text, eg "IANA's IPFIX
Information Elements registry" ?
> refers to the IANA IPFIX Information Element Registry
> [iana-ipfix-assignments].
>
>
>
> Trammell& Claise Expires September 8, 2012 [Page 4]
>
> Internet-Draft IPFIX IE-DOCTORS March 2012
>
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in [RFC2119].
>
>
> 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 lead 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 which define structure inline with data (such as
> XML).
>
> Most applications meeting these criteria can be supported over IPFIX.
> Once it's been determined that IPFIX is a good fit, the next step is
It's == "it is", so this doesn't scan correctly.
> determining which Information Elements are necessary to represent the
> information required by the application. Especially for network-
> centric applications, the IPFIX Information Element registry may
> already contain all the necessary Information Elements (see
> Section 6.1 for guidelines on maximizing Information Element reuse).
> In this case, no additional work within the IETF is necessary: simply
> define Templates and start exporting.
>
> It is expected, however, that most applications will be able to reuse
>
>
>
> Trammell& Claise Expires September 8, 2012 [Page 5]
>
> Internet-Draft IPFIX IE-DOCTORS March 2012
>
>
> 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.
>
> Optionally, a Working Group or individual contributor may choose to
> publish an RFC detailing the new IPFIX application. Such an RFC
Do WGs and ICs publish RFCs?
> 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 appointed IPFIX experts, is eligible for inclusion in
> the Information Element registry:
>
> o The Information Element MUST be sufficiently unique within the
> registry. Its description MUST represent a substantially
> different meaning from that of any existing Information Element.
> A proposed Information Element which is a substantial duplicate of
> an existing Information Element is to be represented using the
> existing Information Element.
** Disagree. If the new app wants to extend the existing IE in a new and
non-backwards compatible way, while avoiding splitting export across two
IEs (ie, old values in the existing IE, new values in the TBD IE), then
it would clone + extend the existing IE. Therefore it would necessarily
be "a substantial duplicate of an existing Information Element".
> o The Information Element SHOULD contain minimal internal structure;
> complex information should be represented with multiple simple
> Information Elements to be exported in parallel, as in
> Section 4.5.
** Seriously disagree. Multiple IEs are unrelated, and may be
re-ordered, aggregated, or removed by some intermediate process.
Structured data would be required to group the discrete IEs together
into a single entity.
> o The Information Element SHOULD be generally applicable to the
> application at hand, which SHOULD be of general interest to the
> community. Information Elements representing information about
> proprietary or nonstandard applications SHOULD be represented
> using enterprise-specific Information Elements as detailed in
> section 3.2 [RFC-EDITOR NOTE: verify section number] of
> [I-D.ietf-ipfix-protocol-rfc5101bis].
>
> The definition of new Information Elements requires a descriptive
> name, a specification of the data type as one from the IPFIX Data
> Type Registry, and a human-readable description written in English.
Note that the Data Type registry is also extensible, so a new IE could
define a new data type.
eg, as done in mib-variable-export.
> This section provides guidelines on each of these components of an
>
>
>
> Trammell& Claise Expires September 8, 2012 [Page 6]
>
> Internet-Draft IPFIX IE-DOCTORS March 2012
>
>
> Information Element definition, referring to existing documentation
> such as [I-D.ietf-ipfix-information-model-rfc5102bis] as appropriate.
>
> 4.1. Information Element naming
>
> Information Element Names should be defined in accordance with
> section 2.3 [RFC-EDITOR NOTE: verify section number] of
> [I-D.ietf-ipfix-information-model-rfc5102bis]; the most important
> naming conventions are repeated here for convenience.
>
> o Names of Information Elements SHOULD be descriptive.
>
> o Names of Information Elements MUST be unique within the registry.
>
> o Names of Information Elements MUST start with non-capitalized
> letters.
>
> o Composed names MUST use capital letters for the first letter of
> each component except for the first one. All other letters are
aka camel case.
> non-capitalized, even for acronyms. Exceptions are made for
> acronyms containing non-capitalized 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, out of the IPFIX informationElementDataTypes subregistry at
> [iana-ipfix-assignments].
Note that the data types registry is extensible.
> 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.
>
> Information Elements representing counters or identifiers SHOULD be
> defined as signed64 or unsigned64, as appropriate, to maximize the
> range of values available; applications can to use reduced-size
typo, "can to".
> Trammell& Claise Expires September 8, 2012 [Page 7]
>
> Internet-Draft IPFIX IE-DOCTORS March 2012
>
>
> encoding as defined in Section 6.2 [RFC-EDITOR NOTE: verify section
> number] of [I-D.ietf-ipfix-protocol-rfc5101bis] in cases where fewer
> than 2^64 values are necessary.
>
> Information Elements representing time values MUST be defined with
> appropriate precision. For example, a 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 which have a length
> constraints (fixed length, minimum and/or maximum length) MUST note
> this length 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 which 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. In other words, 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.
>
> 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 most any appropriate application,
> so extending the type system is generally not necessary.
>
> 4.3. Information Element numbering
>
> Each Information Element have a unique identifier in the IANA
typo: have -> has
> registry.
>
> In general, when adding newly registered Information Elements to the
> registry, IANA SHOULD assign the lowest available Information Element
> identifier (the value column in [iana-ipfix-assignments] in the range
> 128-32767, noting that prior noncontiguous allocation may lead to
> unassigned Information Elements with lower Information Element
> identifiers than some presently assigned Information Elements. This
> is the case with the PSAMP Information Model [RFC5477], which
> assigned a block of Information Elements identifiers starting at 300.
>
> Information Element identifiers in the range 1-128 MUST NOT be
>
>
>
> Trammell& Claise Expires September 8, 2012 [Page 8]
>
> Internet-Draft IPFIX IE-DOCTORS March 2012
>
>
> assigned unless the Information Element is compatible with the
> NetFlow v9 protocol as described in [RFC3954]. Such Information
> Elements may ONLY be requested by a NetFlow v9 expert, to be
> designated by the IESG to consult with IANA on NetFlow v9
> compatibility with IPFIX.
** AFAIK no such experts have been designated. This would be a blocker
for us.
See suggestion from Benoit.
> 4.4. Ancillary Information Element properties
>
> Information Elements to which special semantics apply SHOULD define
The semantics should be defined by the requester, not by the IE.
> these semantics with one of the values in the Information Element
> Semantics registry, as described in Section 3.2 [RFC-EDITOR NOTE:
> verify section number] of
> [I-D.ietf-ipfix-information-model-rfc5102bis], 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 registry. If an Information Element
> expresses a quantity in units not yet in this registry, then the unit
> MUST be added to the Units registry at the same time the Information
> Element is added to the Information Element registry.
Is units a controlled registry (standards action) ?
It's worth (re)stating this clearly for each of the IANA / IPFIX registries.
> 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 registry.
>
> 4.5. Internal structure in Information Elements
>
> The definition of Information Elements with internal structure with
> the structure defined in the Description field is NOT RECOMMENDED,
> except in the following cases:
>
> o 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)
>
> o 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)
>
> o The Information Element represents a set of flags which are
> tightly semantically related, where representing the flags as
> separate one-byte booleans would be inefficient, and which should
> always appear together in a data record (e.g., the
> anonymizationFlags Information Element for specifying optional
>
>
>
> Trammell& Claise Expires September 8, 2012 [Page 9]
>
> Internet-Draft IPFIX IE-DOCTORS March 2012
>
>
> features of anonymization techniques)
>
> 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 Information
> Element 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.
** Now the CP receives three discrete IEs, with nothing to indicate that
together they represent an endpoint.
Worse, some intermediate process could re-order, aggregate or remove the
discrete fields without knowing that they were required to identify an
endpoint.
The only solution is to use SD to group the fields together and prevent
them from being modified along the way.
> The decomposition of data with internal structure SHOULD avoid the
> definition of Information Elements with a meaning too specific to be
> generally useful, or that would result in either the export of
> meaningless data or 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:
>
> o As specified in section 8 [RFC-EDITOR NOTE: verify section number]
> of [I-D.ietf-ipfix-protocol-rfc5101bis]: "if an Information
> Element is required more than once in a Template, the different
> occurrences of this Information Element SHOULD follow the logical
> order of their treatments by the Metering Process." In other
> words, in cases where the items have a natural order (e.g., the
> order in which they occur in the packet), and the multiplicity is
> the same for each record, the information can be modeled by
> containing multiple instances of the Information Element
> representing a single item within the Template Record describing
> the Data Records.
>
>
>
>
> Trammell& Claise Expires September 8, 2012 [Page 10]
>
> Internet-Draft IPFIX IE-DOCTORS March 2012
>
>
> o 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.
>
> o 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, the multiple-item structure
> can be exported as a variable-length octetArray Information
> Element holding the raw content.
Please give an example to clarify this last point.
> Specifically, 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 which may change in the future, this enumeration
> MUST be defined by an IANA 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 IPFIX
> subregistry 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 which Information Elements which were
> defined at the time of its publication which are NOT reversible.
>
> New non-reversible Information Elements SHOULD contain a note in the
> description stating that they are not reversible.
Why isn't that a MUST?
> 4.9. Promotion of Enterprise-Specific Information Elements
>
> Some Information Elements may start their lifecycle outside the IANA
> registry as enterprise-specific Information Elements scoped to a
> Private Enterprise Number. One stated goal of enterprise-specific
> Information Elements is pre-standards product delivery and
> experimentation; should these experiments be successful and the
> Information Elements generally useful, these SHOULD subsequently
> registered with IANA.
>
>
>
>
> Trammell& Claise Expires September 8, 2012 [Page 11]
>
> Internet-Draft IPFIX IE-DOCTORS March 2012
>
>
> In order to support transition from experimental registration to IANA
> registration, the IANA registry provides an optional "enterprise-
> specific IE reference" column for each Information Element. In cases
The registry doesn't currently contain such fields. I've emailed you a
better idea where it doesn't need to.
> of promoted enterprise-specific Information Elements, this column in
> the registry SHOULD contain the private enterprise and Information
> Element numbers of the enterprise-specific version of the Information
> Element.
>
> 4.10. Avoiding Bad Ideas in Information Element Design
>
> In general, the existence of a similarly-defined Information Element
> in the IANA registry sets a precedent which may be followed to
> determine whether a given proposed Information Element "fits" within
> the registry. Indeed, the rules specified by this document could be
> interpreted to mean "make new Information Elements that look like
> existing Information Elements". However, for reasons of history,
> there are several Information Elements within the IANA registry which
> 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.
>
> Before registering a new Information Element, it must be determined
> that it would be sufficiently unique within the 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).
** Disagree. octetDeltaCount and packetDeltaCount are directionless,
while initiator* and responder* have inherent direction - thus the need
for these fields.
> 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.
Note that I proposed an improvement to this scheme.
I'll try not to take it personally that all the bad examples were added
by me, because I'm the only one who's added any new non-RFC IEs at all.
> 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 registry the following list of
> assigned IPFIX Information Elements: mplsTopLabelStackSection,
> mplsLabelStackSection2, mplsLabelStackSection3,
> mplsLabelStackSection4, mplsLabelStackSection5,
> mplsLabelStackSection6 mplsLabelStackSection7,
>
>
>
> Trammell& Claise Expires September 8, 2012 [Page 12]
>
> Internet-Draft IPFIX IE-DOCTORS March 2012
>
>
> 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 which was not carried forward into the final
> specification -- namely, that no semantic dependency was allowed
> between Information Elements in the same Record -- and as such SHOULD
> NOT be followed in the definition of new Information Elements. In
> this case, since the size of the MPLS stack will vary from flow to
> flow, it should be exported using IPFIX Structured Data [RFC6313]
> where supported, as a basicList of MPLS label entries, or as a raw
> MPLS label stack using the variable-length mplsLabelStackSection
> Information Element.
>
>
> 5. The Information Element Lifecycle
>
> 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 IE-DOCTORS process, as defined below. This process is
> also used for other changes to the registry, such as deprecation or
Which registry is that?
> revision, as described later in this section.
>
> 5.1. The IE-DOCTORS process
>
> Requests to change the IANA Information Element registry or a linked
> subregistry are submitted to IANA, which forwards the request to a
How are requests submitted to IANA?
> designated group of experts (IE-DOCTORS) appointed by the IETF
> Operations Area Directors. This group of experts reviews 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.
>
> IE-DOCTORS reviewers should endeavor to complete referred reviews in
> a timely manner. If the request is acceptable, the IE-DOCTORS
Please define "a timely manner". Without a definition, it's not worth
saying.
> signify their approval to IANA, which changes the IANA Information
> Element registry. If the request is not acceptable, the IE-DOCTORS
> can coordinate with the requestor to change the request to be
Or withdraw the request, presumably?
s/requestor/requester/ ?
> compliant. The IE-DOCTORS may also choose in exceptional
> circumstances to reject clearly frivolous or inappropriate change
> requests outright.
What recourse do requesters have if their application is rejected?
>
>
>
>
>
> Trammell& Claise Expires September 8, 2012 [Page 13]
>
> Internet-Draft IPFIX IE-DOCTORS March 2012
>
>
> 5.2. Revising Information Elements
>
> The Information Element status field in the Information Element
> Registry is defined in [I-D.ietf-ipfix-information-model-rfc5102bis]
> to allow Information Elements to be 'current', 'deprecated' or
> 'obsolete'. No Information Elements are as of this writing
> deprecated or obsolete, and
> [I-D.ietf-ipfix-information-model-rfc5102bis] does not define any
> policy for using them. Additionally, no policy is defined for
For using what - deprecated/obsolete IEs, or the deprecated/obsolete status?
> revising Information Element registry entries or addressing errors
> therein. To be certain, changes and deprecations within the
> Information Element 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.
>
> The primary requirement in the definition of a policy for managing
> changes to existing Information Elements is avoidance of
> interoperability problems; IPFIX experts appointed to review changes
> to the Information Element Registry 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 which 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:
>
> o it involves the correction of an error which is obviously only
> editorial; or
>
> o it corrects an ambiguity in the Information Element's definition,
> which itself leads to non-interoperability (e.g., a prior change
> to ipv6ExtensionHeaders); or
>
> o 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
Note that this could have caused interop issues. However, nobody said
they had implemented or were using it at the time, so it was possible to
change.
> o it defines a previously undefined or reserved enumerated value, or
> one or more previously reserved bits in an Information Element
> with flag semantics; or
>
> o it expands the set of permissible values in the Information
> Element's range; or
Again, that could cause interop issues. eg, you claim your collector
supports IPFIX. I also claim to export IPFIX, and export some bits that
you didn't know about when you wrote the collector. Your collector can't
interpret those bits...
> o it harmonizes with an external reference which was itself
> corrected.
>
>
>
>
> Trammell& Claise Expires September 8, 2012 [Page 14]
>
> Internet-Draft IPFIX IE-DOCTORS March 2012
>
>
> A non-interoperable Information Element change may also be made if it
> can be reasonably assumed in the eyes of the appointed experts that
> no unchanged implementation of the Information Element exists; this
> can be held to happen if a non-interoperable change to an Information
> Element defined shortly before is proposed to the IPFIX mailing list
"Element _is_ defined" ?
> by the original proposer of the Information Element, and no objection
> is raised within a reasonable amount of time, to be defined by the
> expert reviewers.
>
> If a change is permissible, it is sent to IANA, which passes it to
So, the requester decides whether the change is permissible?
> the appointed experts for review; if there is no objection to the
> change from any appointed expert, IANA makes the change in the
> Information Element Registry. The requestor of the change is
> appended to the Requestor in the registry.
The registry should record the original requester + date + modifier +
date + details of modification. See below.
> Each Information Element in the IANA 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 registry to store information about old
> revisions.
I'd prefer revision dates, so changes since the last time can easily be
discovered.
Info about old revisions should be stored, so I can discover exactly
what an IPFIX device does / doesn't support when it's claimed to support
IPFIX as at 1-1-2012, eg.
> 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:
>
> o the Information Element definition has an error or shortcoming
> which cannot be permissibly changed as above; or
>
> o the deprecation harmonizes with an external reference which was
> itself deprecated through that reference's accepted deprecation
> method; or
>
> o 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 additionally
> requires the assent of the IPFIX Working Group, and should be
> specified in the Internet Draft(s) defining the protocol change.
>
> A request for deprecation is sent to IANA, which passes it to the IE-
> DOCTORS for review, as above. When deprecating an Information
For clarity, say "as in 5.1 above".
> Element, the Information Element description 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
>
>
>
> Trammell& Claise Expires September 8, 2012 [Page 15]
>
> Internet-Draft IPFIX IE-DOCTORS March 2012
>
>
> deprecation.
>
> Deprecated Information Elements SHOULD continue to be supported by
> Collecting Processes, but SHOULD NOT be exported by Exporting
** ** That's impossible. If someone causes a certain IE to be
deprecated, none of the existing implementations is going to change.
They're going to carry right on exporting the same info they always have
been.
Then new releases which don't make any change in the area of the
deprecated IE will continue to export the deprecated IE to avoid the
situation where existing devices export IE#x while new devices export
IE#y, although these are both observing the same thing.
Besides, collectors which haven't been updated since the deprecation
won't understand IE#y, so the updated EP will now be seen to be
"broken". Even those CPs which have been updated may not equate x with
y, or translate between them - so there could be issues comparing or
processing pre-change data with post-change data.
> Processes. The use of deprecated Information Elements SHOULD result
> in a log entry or human-readable warning at the Exporting and
> Collecting Processes.
How do you propose that existing implementations become aware of the
deprecation?
> After a period of time determined in the eyes
> of the IE-DOCTORS experts to be reasonable in order to allow deployed
> Exporting Processes to be updated to account for the deprecation, a
> deprecated Information Element may be made obsolete. Obsolete
> Information Elements MUST NOT be supported by either Exporting or
> Collecting Processes. The receipt of obsolete Information Elements
** ** Nope, not happening. I can't force my customers to upgrade just
because some 3rd party says so.
> SHOULD be logged by the Collecting Process.
>
> Names of deprecated Information Elements MUST NOT be reused. Names
> of obsolete Information Elements MAY be reused, but this is NOT
> RECOMMENDED, as it may cause confusion among users.
For simplicity, just say "not reused" here too.
> 5.4. Versioning the entire IANA Registry
>
> Consider a typical Collector implementation, which regularly
> downloads the entire registry in order to be compliant with the
> latest of set of supported IEs. While a registry revision number
Consider an implementation which does not, because it's not connected to
public networks, or because the operator is concerned about the risks of
installing such an update.
> might seems advantageous for the Collector at first glance (avoiding
> the one by one comparison of all IE revisions), it is not necessary,
> as the IPFIX IANA registry specifies the date at which the registry
> was last updated in the "Last Updated" field. For purposes of
> identifying the latest set of Information Element versions specified
> in registry, the last revision date of the Information Element
> registry (available in the registry XML source, or from the Last-
> Modified: header of [iana-ipfix-assignments]) SHOULD be used.
That date tells whether the registry was updated. However, without
individual IE versioning, we can't know which IE(s) the update applies to.
>
> 6. When not to define new Information Elements
<snip>
P.
_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix