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

[Brian Trammell <[e-mail]>]

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:


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

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.

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

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.

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

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

<snip>

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

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

<snip>

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

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>

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

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

<snip>

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

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.

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

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.

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

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

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

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.

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

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>

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

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.

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

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.

>>    o  it harmonizes with an external reference which was itself
>>       corrected.

<snip>

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

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>

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

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.

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

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

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

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

>>    SHOULD be logged by the Collecting Process.

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

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

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

On to the next review, then...

Best regards,

Brian