Subject: [IPFIX] draft-ietf-ipfix-ie-doctors-02 review

From: Paul Aitken <[email-masked]>
Date: Tue, 17 Jul 2012 22:03:37 +0100

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.

---

From: Brian Trammell <[email-masked]>
Date: Thu, 19 Jul 2012 11:01:15 +0200

Hi, Paul, 

Applying editorial comments without comment; thanks! Replies to concerns and other important points inline. Comments on issues not already handled in the -03 review to follow in a separate message...

On Jul 17, 2012, at 11:03 PM, Paul Aitken wrote:

> ** 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".

While I think the desire to create a new IE to export the same data without consideration for backward compatibility is a bit misguided at best -- such things should be handled through the creation of subregistries or though the process in section 5.2 -- I don't think there's disagreement here; a new IE would not be a "substantial duplicate" since it would be able to represent completely new values as well.

> ** 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.

This single entity is called a Data Record. Or am I missing something? 

Yes, Data Records are not inviolate, but sticking inscrutable structure into an IE is not the way to keep a rogue ImP from hosing your data; that's a deployment/configuration time issue.

> Note that the Data Type registry is also extensible, so a new IE could define a new data type.

Explicitly per 5610, and implicitly per 5101, this requires a Standards Action. Mibvar is a (potential) standards action, not a simple IE definition.

<snip>

> ** AFAIK no such experts have been designated. This would be a blocker for us.

No; the document specifies the expert must be designated, and the IESG appoints one. I don't see the problem here.

<snip>

> ** 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.

Er, no. This is precisely a notional endpoint as in any common Flow Data Record you can export in IPFIX: the fact that they appear together in a _record_ means they identify and endpoint!

Again, I really, really don't understand the apparent fear of rogue ImPs breaking fine structure in Data Records.

<snip>

>>    description stating that they are not reversible.

In case, for instance (see below), the application for which the IE is defined is somehow completely oblivious to 5103.

<snip>

> ** Disagree. octetDeltaCount and packetDeltaCount are directionless, while initiator* and responder* have inherent direction - thus the need for these fields.

octetDeltaCount and packetDeltaCount are not directionless in the presence of 5103. Indeed, I'd argue that even without 5103, octetDeltaCount and packetDeltaCount implicitly carry the (non-stated) "observation direction", but I freely admit that's a penumbral interpretation.

The presence of these fields in the registry raises an ambiguity: I have biflows I want to export, and I only care about packet and octet counts as values. What do I do? I use these fields, probably, because they look simpler than all this special Enterprise-Specific IE hackery. Oh, wait, now I want to export TCP flags in both directions. What do I do now? Or even more subtly, I want delta counter semantics instead of total counter counter semantics. What do I do now?

As below, I'll try not to take it personally as an author of 5103 that people implementing biflow export have somehow managed to miss a standards-track RFC on how to export biflows in IPFIX and have therefore defined an (incompatible and potentially incomparable) set of IEs for doing exactly the same thing.

> Note that I proposed an improvement to this scheme.

Indeed; IIRC it's even reasonably backward compatible. I would hope that the IE Doctors process could be used to rev the IEs to make them better.

> 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.

:) Nothing personal meant here, of course; these examples were compiled on a review of recent additions, and finding that some of them managed to violate (what I thought were) presumptive rules that hadn't even been stated yet.

> How are requests submitted to IANA?

I presume via email, though I'm not sure we want to put specific directions about how IANA's process works into a BCP.  

> Please define "a timely manner". Without a definition, it's not worth saying.

This was, IIRC, the result of a conversation in the WG, where it was suggested that time limits in an RFC without allowances for extenuating circumstances, the cycles of work in the IETF, IANA's workflow, etc., would be unnecessarily bureaucratic.

> What recourse do requesters have if their application is rejected?

I presume this would be handled as in section 7 of RFC 5226, which in turn refers to section 6.5.4 of RFC 2026. We can note this, certainly.

<snip>

> 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.

Hm, point. I'd thought this would only cause interop issues if RLE wasn't properly implemented, but RLE doesn't specify what to do for, well, _increased_ length encoding.

> 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...

Indeed. As with above, for any enumerated-value IE which you could possibly extend, the collector should be defensive against new values. To review in 5101-bis: whether this is covered.

<snip>

> The registry should record the original requester + date + modifier + date + details of modification. See below.
> 
> 
> I'd prefer revision dates, so changes since the last time can easily be discovered.

Last revision dates are stored in the registry as per the current revision of the document.

> 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.

Keep in mind that any given exporter or collector will probably only care about a subset of the IEs. This brings up the question of what "supports IPFIX" means. If my collector only knows about IPv4, can it reject records with IPv6 addresses and still "support IPFIX"? If I don't care about Layer 2, do I need to recognize the Layer 2 IEs? If I implement 5103, do I also have to handle initiatorOctets and responderOctets? I would hope all the answers to these questions are "no", because otherwise we're not going to have any "implementations of IPFIX".

We can certainly talk to IANA about keeping old versions, but I strongly suggest they be stored in a separate registry; the main registry should be for current IE defs. Otherwise it would appear as though the intent were to specifically support picking and choosing of IE revisions.

<snip>

> ** ** 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.

Deprecation is always tricky. You're right, we can only specify. The best we can do here is "SHOULD NOT".

> 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.

This is a fundamental problem in any protocol without feature negotiation.

> How do you propose that existing implementations become aware of the deprecation?

Well, I presume the implementors will continue paying attention to the registry, at the very least, if the implementations are being actively kept current.

> ** ** Nope, not happening. I can't force my customers to upgrade just because some 3rd party says so.

"MUST NOT be supported by new implementations of either Exporting or Collecting Processes"?

The point here is that if we're going to support deprecation (which was clearly the intent of the WG, given its inclusion in 5102), there may be a mismatch between the deployed and specified environment WRT supported IEs.

> 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.

Point. Indeed, this entire section should be removed; it serves to continue a discussion that, IIRC, was done in the WG in Prague.

>>    Modified: header of [iana-ipfix-assignments]) SHOULD be used.

On to the next review, then...

Best regards,

Brian

---

From: Andrew Feren <[email-masked]>
Date: Thu, 19 Jul 2012 10:35:52 -0400

On 07/19/2012 05:01 AM, Brian Trammell wrote:

[ snip ]
> The point here is that if we're going to support deprecation (which was clearly the intent of the WG, given its inclusion in 5102), there may be a mismatch between the deployed and specified enviro…
I have to side with Paul on this one.  Saying that a collecting process 
MUST NOT support obsoleted IEs seems to me to violate the robustness 
principle.  An argument can be made that new exporters SHOULD / MUST NOT 
send deprecated IEs, but I think more than that is too much.

To give a specific example of the shelf life of the obsolete. Wikipedia 
tells me that NetFlow v1 is obsolete (and it has been for years), but I 
still see NetFlow v1 exports on some customer networks.

-Andrew

---

From: Brian Trammell <[email-masked]>
Date: Thu, 19 Jul 2012 16:45:52 +0200

Hi, Andrew,

Essentially, if this is the argument (which I'm not saying I disagree with), then we should drop obsolete as a status, and just stay with deprecated -- there's no point in distinguishing "don't use it" from "REALLY don't use it" unless we specify that use of deprecated IEs is a warning and use of obsolete IEs is an error.

Especially since we'll never reclaim number or namespace anyway, why not just collapse to one "dead" status?

Cheers,

Brian

On Jul 19, 2012, at 4:35 PM, Andrew Feren wrote:

> I have to side with Paul on this one.  Saying that a collecting process MUST NOT support obsoleted IEs seems to me to violate the robustness principle.  An argument can be made that new exporters SHOULD / MUST NOT send deprecated IEs, but I think more than that is too much.
> 
> To give a specific example of the shelf life of the obsolete. Wikipedia tells me that NetFlow v1 is obsolete (and it has been for years), but I still see NetFlow v1 exports on some customer networks.
> 
> -Andrew
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix