Re: [IPFIX] WG Last Call for draft-ietf-ipfix-information-model-rfc5102bis-05.txt

[Brian Trammell <[e-mail]>]

Hi, Paul,

Many, many thanks for your review. We hadn't actually done a new revision (as we got no commentary during the LC), so let's call these WGLC comments and roll them into a -07 revision, which I'll submit once the Atlanta window is open again (or once this thread comes to a conclusion, whichever comes first).

Specific comments inline; omitted sections accepted without comment, as usual. Comments on Section 5 deferred until we have a consensus on whether we keep it (see other thread).

On Oct 30, 2012, at 11:28 PM, Paul Aitken wrote:

> Some IEs are missing from this document, although they are defined in IANA's IPFIX registry:
> 
>    All the IE's from section 5.8. "Min/Max Flow Properties" of [5102] are missing:
> 
>        6    tcpControlBits
>        25    minimumIpTotalLength
>        26    maximumIpTotalLength
>        52    minimumTTL
>        53    maximumTTL
>        64    ipv6ExtensionHeaders
>        208    ipv4Options
>        209    tcpOptions
> 
> 
>    This 5103 IE is missing:
> 
>        239    biflowDirection
> 
> 
>    The following IEs defined by cisco are listed by IANA, but not in this text:
> 
>        82    interfaceName
>        83    interfaceDescription
>        91    mplsTopLabelPrefixLength
>        98    postIpDiffServCodePoint
>        99    multicastReplicationFactor
>        105-127
>        225-236
>        240+
> 
> 
>    The following IEs are not mentioned here, although they are detailed in draft-yourtchenko-cisco-ies :
> 
>        3, 34, 35, 38, 39, 43, 48-51, 65-69, 84, 87, 89, 92-93, 100, 101, 102, 103, 104, 94-97.

The IEs in 5102bis' categories were chosen because they appeared in 5102; we decided to keep the categorization but explicitly not to update the document to point to IEs added since 5102's publication. (Section 5.8 appears to be an editing oversight; I'm not sure when it fell out of the document, but is not in any working copy of the doc I have; I'll add it back in).

However, if we replace Section 5 as I propose in the other thread, this discussion becomes moot.

> Please find specific feedback inline:
> 
>> 
>> 1.1. Changes since RFC 5102
>> 
>>    This document obsoletes the Proposed Standard revision of the IPFIX
>>    Protocol Specification [RFC5102].  The following changes have been
>>    made to this document with respect to the previous document:
>> 
>>       - All outstanding technical and editorial errata filed on the
>>    [RFC5102] as of publication time have been corrected
>>       - All references into [RFC5101] have been updated to [RFC5101bis],
>>    reflecting changes in that document as necessary
>>       - Information element definitions have been removed, as the
>>    reference for these is now [IPFIX-IANA]; categorizations of
>>    information elements as defines in [RFC5102] have been retained in
>>    section 5.
>>       - The process for modifying [IPFIX-IANA] has been improved, and is
>>    now described in [IPFIX-IE-DOCTORS]; Section 6 has been updated
>>    accordingly, and a new section 7.3 gives IANA considerations for this
>>    process.
>>       - Definitions of timestamp data types have been clarified
>>       - Appendices A and B have been removed
> 
> BTW, the indentation of that section makes it difficult to read. Can you get all the text - including the wrapped lines - to the right of the bullets?

I'm not an nroff hacker. Any pointers?

It's also not clear that this section should survive IESG processing / RFC editor processing.

>> 2.3.  Naming Conventions for Information Elements
>> 
>>    The following naming conventions were used for naming Information
>>    Elements in this document.  It is recommended that extensions of the
>>    model use the same conventions.
>> 
>>    o  Names of Information Elements SHOULD be descriptive.
>> 
>>    o  Names of Information Elements MUST be unique within the IANA
>>       registry.   Enterprise-specific Information Elements SHOULD be
>>       prefixed with a vendor name.
>> 
>>    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
>>       non-capitalized, even for acronyms.  Exceptions are made for
>>       acronyms containing non-capitalized letters, such as 'IPv4' and
>>       'IPv6'.  Examples are sourceMacAddress and destinationIPv4Address.
> 
> Combination of the above rules means that IANA will name an IE "foo", while the ES equivalent is named "enterpriseFoo".
> It's unfortunate that "foo" != "Foo".

We have the same issue with RFC5103. Fortunately most platforms have an equivalent of tolower()/toupper(), but yeah, this is a little bit of a pain.

>> 3.  Type Space
>> 
>>    This section describes the abstract data types that can be used for
>>    the specification of IPFIX Information Elements in Section 4.
>>    Section 3.1 describes the set of abstract data types.
>> 
>>    Abstract data types unsigned8, unsigned16, unsigned32, unsigned64,
>>    signed8, signed16, signed32, and signed64 are integral data types.
> 
> They're just different sizes of the same types.

Yep. But we defined them this way, and there are strong hints to implementors contained therein as to how big the backing store for an IE must be even if it's reduced-length.

>> 
>> 3.2.  Data Type Semantics
>> 
>>    This section describes the set of valid data type semantics of the
>>    IPFIX information model. A registry of data type semantics is
>>    established in [RFC5610]; the restrictions on the use of semantics
> 
> Surely IANA is the reference point, rather than 5610?
> eg, if new semantics are added, they'll be listed in IANA without raising errata against 5610.

This is the pointer to the establishment of the registry; the registry is a subregistry of the IANA IPFIX registry so there is no direct reference to it; will add an [IPFIX-IANA] xref.

> 
>>    below are compatible with those specified in section 3.10 of that
>>    document. These semantics apply only to numeric types, as noted in
>>    the description of each semantic below.
>> 
>>    Further data type semantics may be specified by future extensions of
>>    the IPFIX information model.
> 
> State the required 5226 action / process for that, eg expert review.
> Or, xref the section where that's stated.

The intention here is if you want new semantics, you have to update 5102bis, since these aren't just a matter of encoding, but of rather deep internal implementation questions on EPs and CPs alike. So: Standards Action. (Will also make a parallel clarification in Section 3.1 above)

>> 3.2.3.  deltaCounter
>> 
>>    An numeric value reporting the value of a counter. Counters are
>>    unsigned and wrap back to zero after reaching the limit of the type.
>>    For example, an unsigned64 with counter semantics will continue to
>>    increment until reaching the value of 2**64 - 1. At this point, the
>>    next increment will wrap its value to zero and continue counting from
>>    zero. The semantics of a delta counter is similar to the semantics of
>>    counters used in SNMP, such as Counter32 defined in RFC 2578
>>    [RFC2578]. The only difference between delta counters and counters
>>    used in SNMP is that the delta counters have an initial value of 0. A
>>    delta counter is reset to 0 each time its value is exported.
> 
> What if the cache entry is removed but not exported (eg, an export filter blocks the export) ?
> Then the counter was not exported, so it should not be reset to 0?
> 
> ie, the reset action is more to do with the cache entry expiring than whatever happens to it next.

As I read it, this language was chosen in an attempt to be implementation-independent; nowhere in 5102 does the word "cache" appear, since that makes assumptions about how flow records are created in an MP. (The terminology and implicit design choices associated therewith crept into IPFIX in 6728, but I suppose there was nothing to be done there; you have to make some assumptions about MP internals if you're going to describe how to configure an MP.)

How about the more neutral:

A delta counter is reset to 0 each time it is exported and/or expires without export.

>> 3.2.4.  identifier
>> 
>>    An integral value that serves as an identifier. Specifically,
>>    mathematical operations on two identifiers (aside from the equality
>>    operation) are meaningless. For example, Autonomous System ID 1 *
>>    Autonomous System ID 2 is meaningless. Identifiers MUST be one of the
>>    signed or unsigned data types.
> 
> We could also have non-numeric identifiers, eg wlanSSID is a string identifier.

Do we need to mark string identifiers as identifiers? The definition of identifier is you can't do math on it, and if you're doing math on strings or representing things on which one could do math with strings, you're just doing it wrong. 

>> 5.  Information Element Categories
>> 
>>    This section describes the Information Element category for the IPFIX
>>    information model at the time that [RFC5102] was published. Since
>>    this category field is not part of the IANA process for assigning new
>>    Information Element (even though it has been reused, for example, in
> 
> s/Element/Elements/
> 
> 
>>    [RFC5103]), the newest Information Elements in IANA [IPFIX-IANA]
>>    don't have this classification. The elements are grouped into 12
>>    groups according to their semantics and their applicability:
> 
> TBD: are categories useful? If not, let's say they're deprecated and not discuss them further.

If they're deprecated, then we should remove Section 5 from this document in its entirety.

Actually, I don't see anything in your comments below on this section which would point to it being a useful thing to try and keep; see other thread I just started. I'll hold of on further changes to Section 5 (and keep your comments below intact) 

> 
>> 
>>    1.   Identifiers
>>    2.   Metering and Exporting Process Configuration
>>    3.   Metering and Exporting Process Statistics
>>    4.   IP Header Fields
>>    5.   Transport Header Fields
>>    6.   Sub-IP Header Fields
>>    7.   Derived Packet Properties
>>    8.   Min/Max Flow Properties
>>    9.   Flow Timestamps
>>    10.  Per-Flow Counters
>>    11.  Miscellaneous Flow Properties
>>    12.  Padding
>> 
>>    The Information Elements that are derived from fields of packets or
> 
> s/fields of packets/packet fields/
> 
> 
>>    from packet treatment, such as the Information Elements in groups
>>    4-7, can typically serve as Flow Keys used for mapping packets to
>>    Flows.
>> 
>>  
>> 
>> Claise, Trammell            Standards Track                    [Page 13]
>> 
>> Internet-Draft          IPFIX Information Model          October 3, 2012
>> 
>> 
>>    If they do not serve as Flow Keys, their value may change from packet
>>    to packet within a single Flow.  For Information Elements with values
>>    that are derived from fields of packets or from packet treatment and
> 
> s/fields of packets/packet fields/
> 
> 
>>    for which the value may change from packet to packet within a single
>>    Flow, the IPFIX information model defines that their value is
>>    determined by the first packet observed for the corresponding Flow,
>>    unless the description of the Information Element explicitly
>>    specifies a different semantics.  This simple rule allows writing all
> 
> I don't think it's appropriate for the infomodel to define this.
> 
> In some cases, the same IE may be observed in different ways according to the implementation.
> By the above definition, we'd need multiple IEs.
> 
> 
>>    Information Elements related to header fields once when the first
>>    packet of the Flow is observed.  For further observed packets of the
>>    same Flow, only Flow properties that depend on more than one packet,
>>    such as the Information Elements in groups 8-11, need to be updated.
> 
> This model is based on an historic and simplistic understanding of the MP.
> 
> Today we may not be able to determine all the key fields until some variable number of packets have been observed.
> eg, consider if a key field is in fragment N > 1.
> 
> 
>> 
>>    Information Elements with a name having the "post" prefix, for
>>    example, "postIpClassOfService", do not report properties that were
>>    actually observed at the Observation Point, but retrieved by other
>>    means within the Observation Domain.  These Information Elements can
>>    be used if there are middlebox functions within the Observation
>>    Domain changing Flow properties after packets passed the Observation
>>    Point.
> 
> s/changing/which change/
> 
> 
>> 
>> 
>> 5.1.  Identifiers
>> 
>>    Information Elements grouped in the table below are identifying
>>    components of the IPFIX architecture, of an IPFIX Device, or of the
>>    IPFIX protocol.  All of them have an integral abstract data type and
>>    data type semantics "identifier" as described in Section 3.2.4.
>> 
>>    Typically, some of them are used for limiting scopes of other
>>    Information Elements.  However, other Information Elements MAY be
>>    used for limiting scopes.  Note also that all Information Elements
>>    listed below MAY be used for other purposes than limiting scopes.
>> 
>>    +-----+---------------------------+-----+---------------------------+
>>    |  ID | Name                      |  ID | Name                      |
>>    +-----+---------------------------+-----+---------------------------+
>>    | 141 | lineCardId                | 148 | flowId                    |
>>    | 142 | portId                    | 145 | templateId                |
>>    |  10 | ingressInterface          | 149 | observationDomainId       |
>>    |  14 | egressInterface           | 138 | observationPointId        |
>>    | 143 | meteringProcessId         | 137 | commonPropertiesId        |
>>    | 144 | exportingProcessId        |     |                           |
>>    +-----+---------------------------+-----+---------------------------+
>> 
>>    See [IPFIX-IANA] for the definitions of these Information Elements.
> 
> Instead of repeating this over and over, just say it once in section 5. ?
> 
> 
>> 
>> 
>>  
>> 
>> Claise, Trammell            Standards Track                    [Page 14]
>> 
>> Internet-Draft          IPFIX Information Model          October 3, 2012
>> 
>> 
>>    5.2.  Metering and Exporting Process Configuration
>> 
>>    Information Elements in this section describe the configuration of
>>    the Metering Process or the Exporting Process.  The set of these
>>    Information Elements is listed in the table below.
>> 
>>    +-----+--------------------------+-----+----------------------------+
>>    |  ID | Name                     |  ID | Name                       |
>>    +-----+--------------------------+-----+----------------------------+
>>    | 130 | exporterIPv4Address      | 213 | exportInterface            |
>>    | 131 | exporterIPv6Address      | 214 | exportProtocolVersion      |
>>    | 217 | exporterTransportPort    | 215 | exportTransportProtocol    |
>>    | 211 | collectorIPv4Address     | 216 | collectorTransportPort     |
>>    | 212 | collectorIPv6Address     | 173 | flowKeyIndicator           |
>>    +-----+--------------------------+-----+----------------------------+
>> 
>>    See [IPFIX-IANA] for the definitions of these Information Elements.
>> 
>> 
>> 
>> 5.3.  Metering and Exporting Process Statistics
>> 
>>    Information Elements in this section describe statistics of the
>>    Metering Process and/or the Exporting Process.  The set of these
>>    Information Elements is listed in the table below.
>> 
>>    +-----+-----------------------------+-----+-------------------------+
>>    |  ID | Name                        |  ID | Name                    |
>>    +-----+-----------------------------+-----+-------------------------+
>>    |  41 | exportedMessageTotalCount   | 165 | ignoredOctetTotalCount  |
>>    |  40 | exportedOctetTotalCount     | 166 | notSentFlowTotalCount   |
>>    |  42 | exportedFlowRecordTotalCount| 167 | notSentPacketTotalCount |
>>    | 163 | observedFlowTotalCount      | 168 | notSentOctetTotalCount  |
>>    | 164 | ignoredPacketTotalCount     |     |                         |
>>    +-----+-----------------------------+-----+-------------------------+
>> 
>>    See [IPFIX-IANA] for the definitions of these Information Elements.
>> 
>> 
>> 
>> 5.4.  IP Header Fields
>> 
>>    Information Elements in this section indicate values of IP header
>>    fields or are derived from IP header field values in combination with
>>    further information.
>> 
>>    +-----+----------------------------+-----+--------------------------+
>>    |  ID | Name                       |  ID | Name                     |
>>  
>> 
>> Claise, Trammell            Standards Track                    [Page 15]
>> 
>> Internet-Draft          IPFIX Information Model          October 3, 2012
>> 
>> 
>>    +-----+----------------------------+-----+--------------------------+
>>    |  60 | ipVersion                  | 193 | nextHeaderIPv6           |
>>    |   8 | sourceIPv4Address          | 195 | ipDiffServCodePoint      |
>>    |  27 | sourceIPv6Address          | 196 | ipPrecedence             |
>>    |   9 | sourceIPv4PrefixLength     |   5 | ipClassOfService         |
>>    |  29 | sourceIPv6PrefixLength     |  55 | postIpClassOfService     |
>>    |  44 | sourceIPv4Prefix           |  31 | flowLabelIPv6            |
>>    | 170 | sourceIPv6Prefix           | 206 | isMulticast              |
>>    |  12 | destinationIPv4Address     |  54 | fragmentIdentification   |
>>    |  28 | destinationIPv6Address     |  88 | fragmentOffset           |
>>    |  13 | destinationIPv4PrefixLength| 197 | fragmentFlags            |
>>    |  30 | destinationIPv6PrefixLength| 189 | ipHeaderLength           |
>>    |  45 | destinationIPv4Prefix      | 207 | ipv4IHL                  |
>>    | 169 | destinationIPv6Prefix      | 190 | totalLengthIPv4          |
>>    | 192 | ipTTL                      | 224 | ipTotalLength            |
>>    |   4 | protocolIdentifier         | 191 | payloadLengthIPv6        |
>>    +-----+----------------------------+-----+--------------------------+
>> 
>>    See [IPFIX-IANA] for the definitions of these Information Elements.
>> 
>> 
>> 
>> 5.5.  Transport Header Fields
>> 
>>    The set of Information Elements related to transport header fields
>>    and length includes the Information Elements listed in the table
>>    below.
>> 
>>    +-----+---------------------------+-----+---------------------------+
>>    |  ID | Name                      |  ID | Name                      |
>>    +-----+---------------------------+-----+---------------------------+
>>    |   7 | sourceTransportPort       | 238 | tcpWindowScale            |
>>    |  11 | destinationTransportPort  | 187 | tcpUrgentPointer          |
>>    | 180 | udpSourcePort             | 188 | tcpHeaderLength           |
>>    | 181 | udpDestinationPort        |  32 | icmpTypeCodeIPv4          |
>>    | 205 | udpMessageLength          | 176 | icmpTypeIPv4              |
>>    | 182 | tcpSourcePort             | 177 | icmpCodeIPv4              |
>>    | 183 | tcpDestinationPort        | 139 | icmpTypeCodeIPv6          |
>>    | 184 | tcpSequenceNumber         | 178 | icmpTypeIPv6              |
>>    | 185 | tcpAcknowledgementNumber  | 179 | icmpCodeIPv6              |
>>    | 186 | tcpWindowSize             |  33 | igmpType                  |
>>    +-----+---------------------------+-----+---------------------------+
>> 
>>    See [IPFIX-IANA] for the definitions of these Information Elements.
>> 
>> 
>> 
>> 
>>  
>> 
>> Claise, Trammell            Standards Track                    [Page 16]
>> 
>> Internet-Draft          IPFIX Information Model          October 3, 2012
>> 
>> 
>> 5.6.  Sub-IP Header Fields
>> 
>>    The set of Information Elements related to Sub-IP header fields
>>    includes the Information Elements listed in the table below.
>> 
>>    +-----+---------------------------+-----+---------------------------+
>>    |  ID | Name                      |  ID | Name                      |
>>    +-----+---------------------------+-----+---------------------------+
>>    |  56 | sourceMacAddress          | 201 | mplsLabelStackLength      |
>>    |  81 | postSourceMacAddress      | 194 | mplsPayloadLength         |
>>    |  58 | vlanId                    |  70 | mplsTopLabelStackSection  |
>>    |  59 | postVlanId                |  71 | mplsLabelStackSection2    |
>>    |  80 | destinationMacAddress     |  72 | mplsLabelStackSection3    |
>>    |  57 | postDestinationMacAddress |  73 | mplsLabelStackSection4    |
>>    | 146 | wlanChannelId             |  74 | mplsLabelStackSection5    |
>>    | 147 | wlanSSID                  |  75 | mplsLabelStackSection6    |
>>    | 200 | mplsTopLabelTTL           |  76 | mplsLabelStackSection7    |
>>    | 203 | mplsTopLabelExp           |  77 | mplsLabelStackSection8    |
>>    | 237 | postMplsTopLabelExp       |  78 | mplsLabelStackSection9    |
>>    | 202 | mplsLabelStackDepth       |  79 | mplsLabelStackSection10   |
>>    +-----+---------------------------+-----+---------------------------+
>> 
>>    See [IPFIX-IANA] for the definitions of these Information Elements.
>> 
>> 
>> 5.7.  Derived Packet Properties
>> 
>>    The set of Information Elements derived from packet properties (for
>>    example, values of header fields) includes the Information Elements
>>    listed in the table below.
>> 
>>    +-----+---------------------------+-----+---------------------------+
>>    |  ID | Name                      |  ID | Name                      |
>>    +-----+---------------------------+-----+---------------------------+
>>    | 204 | ipPayloadLength           |  18 | bgpNextHopIPv4Address     |
>>    |  15 | ipNextHopIPv4Address      |  63 | bgpNextHopIPv6Address     |
>>    |  62 | ipNextHopIPv6Address      |  46 | mplsTopLabelType          |
>>    |  16 | bgpSourceAsNumber         |  47 | mplsTopLabelIPv4Address   |
>>    |  17 | bgpDestinationAsNumber    | 140 | mplsTopLabelIPv6Address   |
>>    | 128 | bgpNextAdjacentAsNumber   |  90 | mplsVpnRouteDistinguisher |
>>    | 129 | bgpPrevAdjacentAsNumber   |     |                           |
>>    +-----+---------------------------+-----+---------------------------+
>> 
>>    See [IPFIX-IANA] for the definitions of these Information Elements.
>> 
>> 
>> 
>> 
>>  
>> 
>> Claise, Trammell            Standards Track                    [Page 17]
>> 
>> Internet-Draft          IPFIX Information Model          October 3, 2012
>> 
>> 
>> 5.9.  Flow Timestamps
>> 
>>    Information Elements in this section are timestamps of events.
>> 
>>    Timestamps flowStartSeconds, flowEndSeconds, flowStartMilliseconds,
>>    flowEndMilliseconds, flowStartMicroseconds, flowEndMicroseconds,
>>    flowStartNanoseconds, flowEndNanoseconds, and
>>    systemInitTimeMilliseconds are absolute and have a well-defined fixed
>>    time base, such as, for example, the number of seconds since 0000 UTC
>>    Jan 1st 1970.
> 
> It's a bit dangerous to give this example, since it could be misread as being the actual definition.
> xref sections 3.1.15 - 3.1.18 where the time bases are stated.
> 
> 
>> 
>>    Timestamps flowStartDeltaMicroseconds and flowEndDeltaMicroseconds
>>    are relative timestamps only valid within the scope of a single
>>    IPFIX Message.  They contain the negative time offsets relative to
>>    the export time specified in the IPFIX Message Header.  The maximum
> 
> In order for the EP to populate *DeltaMicroseconds in a flow record, it must first know what Export Time it's going to stamp into the IPFIX header, and the flow record must be exported with that given second... unless we allow that data may be exported somewhat asynchronously to the header timestamping (eg, if there's a queue of outgoing packets at a level below the EP, eg in the IP stack). If a flow's export is delayed such that the Export Time changes, then these deltas must be recalculated. Practically, that may not be possible.
> 
> Anyway, why do we have microsecond offsets from a "seconds" time?
> 
> In short, these two IEs seem flawed and should be deprecated.
> 
> 
>>    time offset that can be encoded by these delta counters is 1 hour, 11
>>    minutes, and 34.967295 seconds.
>> 
>>    Timestamps flowStartSysUpTime and flowEndSysUpTime are relative
>>    timestamps indicating the time relative to the last
>>    (re-)initialization of the IPFIX Device.  For reporting the time
>>    of the last (re-)initialization, systemInitTimeMilliseconds can
>>    be reported, for example, in Data Records defined by Option
>>    Templates.
>> 
>>    +-----+---------------------------+-----+---------------------------+
>>    |  ID | Name                      |  ID | Name                      |
>>    +-----+---------------------------+-----+---------------------------+
>>    | 150 | flowStartSeconds          | 156 | flowStartNanoseconds      |
>>    | 151 | flowEndSeconds            | 157 | flowEndNanoseconds        |
>>    | 152 | flowStartMilliseconds     | 158 | flowStartDeltaMicroseconds|
>>    | 153 | flowEndMilliseconds       | 159 | flowEndDeltaMicroseconds  |
>>    | 154 | flowStartMicroseconds     | 160 | systemInitTimeMilliseconds|
>>    | 155 | flowEndMicroseconds       |  22 | flowStartSysUpTime        |
>>    |     |                           |  21 | flowEndSysUpTime          |
>>    +-----+---------------------------+-----+---------------------------+
>> 
>>    See [IPFIX-IANA] for the definitions of these Information Elements.
>> 
>> 5.10.  Per-Flow Counters
>> 
>>    Information Elements in this section are counters all having integer
>>    values.  Their values may change for every report they are used in.
>>    They cannot serve as part of a Flow Key used for mapping packets to
>>    Flows.  However, potentially they can be used for selecting exported
> 
> Well, octetDeltaCount could be used to make all packets of the same size hash to the same bucket.
> 
> More realistically, these could be used when aggregating flows into other flows. eg, all the flows with the same number of packets, or all the flows with the same TCP SYN count.
> 
> 
>>    Flows, for example, by only exporting Flows with more than a
>>    threshold number of observed octets.
>> 
>>  
>> 
>> Claise, Trammell            Standards Track                    [Page 18]
>> 
>> Internet-Draft          IPFIX Information Model          October 3, 2012
>> 
>> 
>>    There are running counters and delta counters.  Delta counters are
>>    reset to zero each time their values are exported.  Running counters
>>    continue counting independently of the Exporting Process.
>> 
>>    There are per-Flow counters and counters related to the Metering
>>    Process and/or the Exporting Process.  Per-Flow counters are Flow
>>    properties that potentially change each time a packet belonging to
>>    the Flow is observed.  The set of per-Flow counters includes the
>>    Information Elements listed in the table below.  Counters related to
>>    the Metering Process and/or the Exporting Process are described in
>>    Section 5.3.
>> 
>>    +-----+---------------------------+-----+---------------------------+
>>    |  ID | Name                      |  ID | Name                      |
>>    +-----+---------------------------+-----+---------------------------+
>>    |   1 | octetDeltaCount           | 134 | droppedOctetTotalCount    |
>>    |  23 | postOctetDeltaCount       | 135 | droppedPacketTotalCount   |
>>    | 198 | octetDeltaSumOfSquares    |  19 | postMCastPacketDeltaCount |
>>    |  85 | octetTotalCount           |  20 | postMCastOctetDeltaCount  |
>>    | 171 | postOctetTotalCount       | 174 | postMCastPacketTotalCount |
>>    | 199 | octetTotalSumOfSquares    | 175 | postMCastOctetTotalCount  |
>>    |   2 | packetDeltaCount          | 218 | tcpSynTotalCount          |
>>    |  24 | postPacketDeltaCount      | 219 | tcpFinTotalCount          |
>>    |  86 | packetTotalCount          | 220 | tcpRstTotalCount          |
>>    | 172 | postPacketTotalCount      | 221 | tcpPshTotalCount          |
>>    | 132 | droppedOctetDeltaCount    | 222 | tcpAckTotalCount          |
>>    | 133 | droppedPacketDeltaCount   | 223 | tcpUrgTotalCount          |
>>    +-----+---------------------------+-----+---------------------------+
>> 
>> 
>> See [IPFIX-IANA] for the definitions of these Information Elements.
>> 
>> 
>> 5.11.  Miscellaneous Flow Properties
>> 
>>    Information Elements in this section describe properties of Flows
>>    that are related to Flow start, Flow duration, and Flow termination,
>>    but they are not timestamps as the Information Elements in Section
>>    5.9 are.
>> 
>>    +-----+---------------------------+-----+---------------------------+
>>    |  ID | Name                      |  ID | Name                      |
>>    +-----+---------------------------+-----+---------------------------+
>>    |  36 | flowActiveTimeout         | 161 | flowDurationMilliseconds  |
>>    |  37 | flowIdleTimeout           | 162 | flowDurationMicroseconds  |
>>    | 136 | flowEndReason             |  61 | flowDirection             |
>>    +-----+---------------------------+-----+---------------------------+
>> 
>>  
>> 
>> Claise, Trammell            Standards Track                    [Page 19]
>> 
>> Internet-Draft          IPFIX Information Model          October 3, 2012
>> 
>> 
>> See [IPFIX-IANA] for the definitions of these Information Elements.
>> 
>> 
>> 
>> 5.12.  Padding
>> 
>>    This section contains a single Information Element that can be used
>>    for padding of Flow Records.
>> 
>>    IPFIX implementations may wish to align Information Elements within
>>    Data Records or to align entire Data Records to 4-octet or 8-octet
>>    boundaries.  This can be achieved by including one or more
>>    paddingOctets Information Elements in a Data Record.
>> 
>>    +-----+---------------------------+-----+---------------------------+
>>    |  ID | Name                      |  ID | Name                      |
>>    +-----+---------------------------+-----+---------------------------+
>>    | 210 | paddingOctets             |     |                           |
>>    +-----+---------------------------+-----+---------------------------+
>> 
>> See [IPFIX-IANA] for the definitions of these Information Elements.
>> 
>> 
>> 7.4.  Addition, Revision, and Deprecation
>> 
>> As stated in Section 6, addition, revision, and deletion of Information
>> Elements in the IPFIX Information Element registry is subject to a
>> process described in [IPFIX-IE-DOCTORS]. The IE-DOCTORS experts mentions
>> in this process are to be appointed by the IESG.
> 
> When was/will that be done? Where are/will they be listed? How will IANA know who they are?

Feedback from IANA indicates that this process is IANA-managed and internal; i.e. this document should leave it up to them.

Thanks, cheers,

Brian