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

From: Nevil Brownlee <[email-masked]>
Date: Thu, 04 Oct 2012 11:44:51 +1300

Hi all:

The WG Last Call for this I-D starts now, and will run until Monday,
22 October.

Do please read the draft, and post your comments to the list.  It's
important that we can show it has been well-considered/reviewed within
the WG, so short comments like "yes, this does clearly describe the
IPFIX Information Model as we want it to be" are important and useful!

Cheers, Nevil

-- 
---------------------------------------------------------------------
  Nevil Brownlee                    Computer Science Department | ITS
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand

---

From: Paul Aitken <[email-masked]>
Date: Tue, 30 Oct 2012 22:28:12 +0000

Nevil, All,

> The WG Last Call for this I-D starts now, and will run until Monday, 

Sorry I'm late for -05, but hopefully still in time for -06? :-)

So here's a 110% review of rfc5102bis-06.

There are some nits:

   == Missing Reference: 'RFC5101' is mentioned on line 164, but not defined

   == Outdated reference: A later version (-02) exists of
      draft-ietf-ipfix-protocol-rfc5101bis-00

   -- Possible downref: Normative reference to a draft: ref. 'RFC5101bis'

   == Outdated reference: A later version (-07) exists of
      draft-ietf-ipfix-ie-doctors-00

   == Outdated reference: draft-ietf-ipfix-configuration-model has been
      published as RFC 6728

   == Outdated reference: A later version (-02) exists of
      draft-ietf-ipfix-mediation-protocol-00

   == Outdated reference: draft-ietf-ipfix-rfc5815bis has been published as
      RFC 6615

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.

Please find specific feedback inline:

> Network Working Group                                     B. Claise, Ed.
> Internet Draft                                       Cisco Systems, Inc.
> Obsoletes: 5102                                         B. Trammell, Ed.
> Category: Standards Track                                     ETH Zurich
> Expires: April 6, 2013                                   October 3, 2012
>
>
>          Information Model for IP Flow Information eXport (IPFIX)
>            draft-ietf-ipfix-information-model-rfc5102bis-06.txt
>                                      
>
> Abstract
>
> This document provides an overview of the information model for the IP
> Flow Information eXport (IPFIX) protocol, as defined in the IANA IPFIX
> Information Element Registry. It is used by the IPFIX Protocol for
> encoding measured traffic information and information related to the
> traffic Observation Point, the traffic Metering Process, and the
> Exporting Process. Although developed for the IPFIX Protocol, the model
> is defined in an open way that easily allows using it in other
> protocols, interfaces, and applications. This document obsoletes RFC
> 5102.
>
> 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
>     at http://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 March 23, 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
>   
>
>
> Claise, Trammell            Standards Track                     [Page 1]
> 
> Internet-Draft          IPFIX Information Model          October 3, 2012
>
>
>     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.
>
>
> Table of Contents
>
>     1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
>       1.1. Changes since RFC 5102  . . . . . . . . . . . . . . . . . .  4
>       1.2. IPFIX Documents Overview  . . . . . . . . . . . . . . . . .  4
>     2.  Properties of IPFIX Protocol Information Elements  . . . . . .  5
>       2.1.  Information Element Specification Template . . . . . . . .  5
>       2.2.  Scope of Information Elements  . . . . . . . . . . . . . .  7
>       2.3.  Naming Conventions for Information Elements  . . . . . . .  8
>     3.  Type Space . . . . . . . . . . . . . . . . . . . . . . . . . .  8
>       3.1.  Abstract Data Types  . . . . . . . . . . . . . . . . . . .  9
>         3.1.1.  unsigned8  . . . . . . . . . . . . . . . . . . . . . .  9
>         3.1.2.  unsigned16 . . . . . . . . . . . . . . . . . . . . . .  9
>         3.1.3.  unsigned32 . . . . . . . . . . . . . . . . . . . . . .  9
>         3.1.4.  unsigned64 . . . . . . . . . . . . . . . . . . . . . .  9
>         3.1.5.  signed8  . . . . . . . . . . . . . . . . . . . . . . .  9
>         3.1.6.  signed16 . . . . . . . . . . . . . . . . . . . . . . .  9
>         3.1.7.  signed32 . . . . . . . . . . . . . . . . . . . . . . .  9
>         3.1.8.  signed64 . . . . . . . . . . . . . . . . . . . . . . .  9
>         3.1.9.  float32  . . . . . . . . . . . . . . . . . . . . . . . 10
>         3.1.10.  float64 . . . . . . . . . . . . . . . . . . . . . . . 10
>         3.1.11.  boolean . . . . . . . . . . . . . . . . . . . . . . . 10
>         3.1.12.  macAddress  . . . . . . . . . . . . . . . . . . . . . 10
>         3.1.13.  octetArray  . . . . . . . . . . . . . . . . . . . . . 10
>         3.1.14.  string  . . . . . . . . . . . . . . . . . . . . . . . 10
>         3.1.15.  dateTimeSeconds . . . . . . . . . . . . . . . . . . . 10
>         3.1.16.  dateTimeMilliseconds  . . . . . . . . . . . . . . . . 10
>         3.1.17.  dateTimeMicroseconds  . . . . . . . . . . . . . . . . 10
>         3.1.18.  dateTimeNanoseconds . . . . . . . . . . . . . . . . . 11
>         3.1.19.  ipv4Address . . . . . . . . . . . . . . . . . . . . . 11
>         3.1.20.  ipv6Address . . . . . . . . . . . . . . . . . . . . . 11
>       3.2.  Data Type Semantics  . . . . . . . . . . . . . . . . . . . 11
>         3.2.1.  quantity . . . . . . . . . . . . . . . . . . . . . . . 11
>         3.2.2.  totalCounter . . . . . . . . . . . . . . . . . . . . . 11
>         3.2.3.  deltaCounter . . . . . . . . . . . . . . . . . . . . . 12
>         3.2.4.  identifier . . . . . . . . . . . . . . . . . . . . . . 12
>         3.2.5.  flags  . . . . . . . . . . . . . . . . . . . . . . . . 12
>     4.  Information Element Identifiers  . . . . . . . . . . . . . . . 12
>       4.1.  NetFlow version 9 compatible Information Element
>             Identifiers  . . . . . . . . . . . . . . . . . . . . . . . 13
>   
>
>
> Claise, Trammell            Standards Track                     [Page 2]
> 
> Internet-Draft          IPFIX Information Model          October 3, 2012
>
>
>     5.  Information Element Categories . . . . . . . . . . . . . . . . 13
>       5.1.  Identifiers  . . . . . . . . . . . . . . . . . . . . . . . 14
>       5.3.  Metering and Exporting Process Statistics  . . . . . . . . 15
>       5.4.  IP Header Fields . . . . . . . . . . . . . . . . . . . . . 15
>       5.5.  Transport Header Fields  . . . . . . . . . . . . . . . . . 16
>       5.6.  Sub-IP Header Fields . . . . . . . . . . . . . . . . . . . 17
>       5.7.  Derived Packet Properties  . . . . . . . . . . . . . . . . 17
>       5.9.  Flow Timestamps  . . . . . . . . . . . . . . . . . . . . . 18
>       5.10.  Per-Flow Counters . . . . . . . . . . . . . . . . . . . . 18
>       5.11.  Miscellaneous Flow Properties . . . . . . . . . . . . . . 19
>       5.12.  Padding . . . . . . . . . . . . . . . . . . . . . . . . . 20
>     6.  Extending the Information Model  . . . . . . . . . . . . . . . 20
>     7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
>       7.1.  IPFIX Information Elements . . . . . . . . . . . . . . . . 21
>       7.2.  MPLS Label Type Identifier . . . . . . . . . . . . . . . . 21
>       7.3.  XML Namespace and Schema . . . . . . . . . . . . . . . . . 22
>       7.4.  Addition, Revision, and Deprecation  . . . . . . . . . . . 23
>     8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
>     9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
>     10.  References  . . . . . . . . . . . . . . . . . . . . . . . . . 24
>       10.1.  Normative References  . . . . . . . . . . . . . . . . . . 24
>       10.2.  Informative References  . . . . . . . . . . . . . . . . . 24
>     Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
>
>
>
>
>
> 1.  Introduction
>
>     The IP Flow Information eXport (IPFIX) protocol serves for
>     transmitting information related to measured IP traffic over the

We also have non-IP traffic, eg MPLS and layer 2 information.

>     Internet.  The protocol specification in [RFC5101bis] defines how

Not just "over the Internet", but any IP network.

>     Information Elements are transmitted.  For Information Elements, it
>     specifies the encoding of a set of basic data types.  However, the
>     list of Information Elements that can be transmitted by the protocol,
>     such as Flow attributes (source IP address, number of packets, etc.)
>     and information about the Metering and Exporting Process (packet
>     Observation Point, sampling rate, Flow timeout interval, etc.), is
>     not specified in [RFC5101bis].
>
>     The canonical reference for IPFIX Information Elements the IANA IPFIX
>     Information Element registry [IPFIX-IANA]; the initial values for
>     this registry were provided by [RFC5102].
>
>     This document complements the IPFIX protocol specification by

"the IPFIX protocol specification in [RFC5101bis] by"

>     providing an overview of the IPFIX information model and specifying
>     data types for it. IPFIX-specific terminology used in this document
>   
>
>
> Claise, Trammell            Standards Track                     [Page 3]
> 
> Internet-Draft          IPFIX Information Model          October 3, 2012
>
>
>     is defined in Section 2 of [RFC5101bis]. As in [RFC5101bis], these
>     IPFIX-specific terms have the first letter of a word capitalized when
>     used in this document.
>
>     The use of the term 'information model' is not fully in line with the
>     definition of this term in [RFC3444].  The IPFIX information model
>     does not specify relationships between Information Elements, but also
>     it does not specify a concrete encoding of Information Elements.

The IPFIX encoding is specified in 5101.

>     Besides the encoding used by the IPFIX protocol, other encodings of
>     IPFIX Information Elements can be applied, for example, XML-based
>     encodings.
>
>     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].
>
> 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

s/defines/defined/

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

>
> 1.2. IPFIX Documents Overview
>
>     The IPFIX protocol provides network administrators with access to IP
>     flow information.  The architecture for the export of measured IP
>     flow information out of an IPFIX Exporting Process to a Collecting

I'd be tempted to drop "IP" from "IP flow information" (x2).

>     Process is defined in [RFC5470], per the requirements defined in
>     [RFC3917].  The IPFIX specifications [RFC5101bis] document specifies

"The IPFIX specifications document [RFC5101bis]" ?

>     how IPFIX data records and templates are carried via a number of
>     transport protocols from IPFIX Exporting Processes to IPFIX
>     Collecting Processes.
>
>   
>
>
> Claise, Trammell            Standards Track                     [Page 4]
> 
> Internet-Draft          IPFIX Information Model          October 3, 2012
>
>
>     Four IPFIX optimizations/extensions are currently specified: a
>     bandwidth saving method for the IPFIX protocol in [RFC5473], an
>     efficient method for exporting bidirectional flow in [RFC5103], a

"bidirectional flows", plural.

>     method for the definition and export of complex data structures in
>     [RFC6313], and the specification of the Protocol for IPFIX Mediations
>     [IPFIX-MED-PROTO] based on the IPIFX Mediation Framework [RFC6183].

s/IPIFX/IPFIX/

>
>     IPFIX has a formal description of IPFIX Information Elements, their
>     name, type and additional semantic information, as specified in this
>     document, with the export of the Information Element types specified
>     in [RFC5610].
>
>     [IPFIX-CONF] specifies a data model for configuring and monitoring
>     IPFIX and PSAMP compliant devices using the NETCONF protocol, while
>     the [RFC5815bis] specifies a MIB module for monitoring.

- "the"

>
>     In terms of development, [RFC5153] provides guidelines for the
>     implementation and use of the IPFIX protocol, while [RFC5471]
>     provides guidelines for testing.
>
>     Finally, [RFC5472] describes what type of applications can use the
>     IPFIX protocol and how they can use the information provided.  It
>     furthermore shows how the IPFIX framework relates to other
>     architectures and frameworks.
>
> 2.  Properties of IPFIX Protocol Information Elements
>
> 2.1.  Information Element Specification Template
>
>     Information in messages of the IPFIX protocol is modeled in terms of
>     Information Elements of the IPFIX information model. The IPFIX
>     Information Elements mentioned in Section 5 are specified in [IPFIX-
>     IANA]. For specifying these Information Elements, a template is used
>     that is described below.

At first I misunderstood "template" here. It's all in the context.

>
>     All Information Elements specified for the IPFIX protocol MUST have
>     the following properties defined:
>
>     name - A unique and meaningful name for the Information Element.
>
>     elementId - A numeric identifier of the Information Element.  If this
>        identifier is used without an enterprise identifier (see
>        [RFC5101bis] and enterpriseId below), then it is globally unique
>        and the list of allowed values is administered by IANA.  It is
>        used for compact identification of an Information Element when
>        encoding Templates in the protocol.
>
>     description - The semantics of this Information Element. Describes
>   
>
>
> Claise, Trammell            Standards Track                     [Page 5]
> 
> Internet-Draft          IPFIX Information Model          October 3, 2012
>
>
>        how this Information Element is derived from the Flow or other
>        information available to the observer. Information Elements of
>        dataType string or octetArray which have a length constraints

- "a"

>        (fixed length, minimum and/or maximum length) MUST note these
>        constraints in their description.
>
>     dataType - One of the types listed in Section 3.1 of this document or
>        registered in the IANA IPFIX Information Element Data Types
>        registry. The type space for attributes is constrained to
>        facilitate implementation. The existing type space does however
>        encompass most basic types used in modern programming languages,
>        as well as some derived types (such as ipv4Address) that are
>        common to this domain and useful to distinguish.

At first there seemed to be missing text at the end of this line.

>
>     status - The status of the specification of this Information Element.
>        Allowed values are 'current' and 'deprecated'. All newly-defined
>        Information Elements have 'current' status. The process for moving
>        Information Elements to the 'deprecated' status is defined in
>        Section 5.2 of [IPFIX-IE-DOCTORS].
>
>     Enterprise-specific Information Elements MUST have the following
>     property defined:
>
>     enterpriseId - Enterprises may wish to define Information Elements
>        without registering them with IANA, for example, for
>        enterprise-internal purposes.  For such Information Elements, the
>        Information Element identifier described above is not sufficient
>        when the Information Element is used outside the enterprise.  If
>        specifications of enterprise-specific Information Elements are
>        made public and/or if enterprise-specific identifiers are used by
>        the IPFIX protocol outside the enterprise, then the
>        enterprise-specific identifier MUST be made globally unique by
>        combining it with an enterprise identifier.  Valid values for the
>        enterpriseId are defined by IANA as Structure of Management
>        Information (SMI) network management private enterprise codes.
>        They are defined at http://www.iana.org/assignments/enterprise-
>        numbers.

Move the URL to an I-ref? It's mentioned again below.

>
>     All Information Elements specified for the IPFIX protocol either in
>     this document or by any future extension MAY have the following
>     properties defined:
>
>     dataTypeSemantics - The integral types may be qualified by additional
>        semantic details.  Valid values for the data type semantics are
>        specified in Section 3.2 of this document or in a future extension
>        of the information model.

Section 3.2.1 specifies that "quantity" is the default semantic, so this 
isn't really a MAY.
If semantics is an optional property, why does it have a default?

>
>     units - If the Information Element is a measure of some kind, the
>   
>
>
> Claise, Trammell            Standards Track                     [Page 6]
> 
> Internet-Draft          IPFIX Information Model          October 3, 2012
>
>
>        units identify what the measure is.
>
>     range - Some Information Elements may only be able to take on a
>        restricted set of values that can be expressed as a range (e.g., 0
>        through 511 inclusive).  If this is the case, the valid inclusive
>        range should be specified.

Should we make any comment on the invalidity of values outside the range?

>
>     reference - Identifies additional specifications that more precisely
>        define this item or provide additional context for its use.
>
>
>     The following two Information Element properties are defined to allow
>     the management of an Information Element registry with Information
>     Element definitions that may be updated over time, per the process
>     defined in Section 5.2 of [IPFIX-IE-DOCTORS].
>
>     revision - The revision number of an Information Element, starting at
>        0 for Information Elements at time of definition, and incremented
>        by one for each revision.
>
>     date - The date of the entry of this revision of the Information
>        Element into the registry.
>
>     For Information Elements of the string or octetArray data types which
>     have size limits (minimum and/or maximum size, or fixed length), the
>     limits MUST be defined within the description of the Information
>     Element.

This repeats earlier text in the "description" section.

>
> 2.2.  Scope of Information Elements
>
>     By default, most Information Elements have a scope specified in their
>     definitions.
>
>     o  The Information Elements listed in Sections 5.2 and 5.3, and
>        similar Information Elements in [IPFIX-IANA], have a default of "a
>        specific Metering Process" or of "a specific Exporting Process",
>        respectively.
>
>     o  The Information Elements listed in Sections 5.4-5.11, and similar
>        Information Elements in [IPFIX-IANA], have a scope of "a specific
>        Flow".
>
>     Within Data Records defined by Option Templates, the IPFIX protocol
>     allows further limiting of the Information Element scope.  The new
>     scope is specified by one or more scope fields and defined as the
>     combination of all specified scope values; see Section 3.4.2.1 on
>     IPFIX scopes in [RFC5101bis].
>
>   
>
>
> Claise, Trammell            Standards Track                     [Page 7]
> 
> Internet-Draft          IPFIX Information Model          October 3, 2012
>
>
> 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.

Unique within IANA's *IPFIX* registry.
Add xref to 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
>        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".

>
>     o  Middleboxes [RFC3234] may change Flow properties, such as the
>        Differentiated Service Code Point (DSCP) value or the source IP
>        address.  If an IPFIX Observation Point is located in the path of
>        a Flow before one or more middleboxes that potentially modify
>        packets of the Flow, then it may be desirable to also report Flow
>        properties after the modification performed by the middleboxes.
>        An example is an Observation Point before a packet marker changing
>        a packet's IPv4 Type of Service (TOS) field that is encoded in
>        Information Element ipClassOfService.  Then the value observed and
>        reported by Information Element ipClassOfService is valid at the
>        Observation Point, but not after the packet passed the packet
>        marker.  For reporting the change value of the TOS field, the
>        IPFIX information model uses Information Elements that have a name
>        prefix "post", for example, "postIpClassOfService".  Information
>        Elements with prefix "post" report on Flow properties that are not
>        necessarily observed at the Observation Point, but which are
>        obtained within the Flow's Observation Domain by other means
>        considered to be sufficiently reliable, for example, by analyzing
>        the packet marker's marking tables.
>
> 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,
>   
>
>
> Claise, Trammell            Standards Track                     [Page 8]
> 
> Internet-Draft          IPFIX Information Model          October 3, 2012
>
>
>     signed8, signed16, signed32, and signed64 are integral data types.

They're just different sizes of the same types.

>     As described in Section 3.2, their data type semantics can be further
>     specified, for example, by 'totalCounter', 'deltaCounter',
>     'identifier', or 'flags'.
>
> 3.1.  Abstract Data Types
>
>     This section describes the set of valid abstract data types of the
>     IPFIX information model.  Note that further abstract data types may
>     be specified by future extensions of the IPFIX information model.
>
> 3.1.1.  unsigned8
>
>     The type "unsigned8" represents a non-negative integer value in the
>     range of 0 to 255.
>
> 3.1.2.  unsigned16
>
>     The type "unsigned16" represents a non-negative integer value in the
>     range of 0 to 65535.
>
> 3.1.3.  unsigned32
>
>     The type "unsigned32" represents a non-negative integer value in the
>     range of 0 to 4294967295.
>
> 3.1.4.  unsigned64
>
>     The type "unsigned64" represents a non-negative integer value in the
>     range of 0 to 18446744073709551615.
>
> 3.1.5.  signed8
>
>     The type "signed8" represents an integer value in the range of -128
>     to 127.
>
> 3.1.6.  signed16
>
>     The type "signed16" represents an integer value in the range of
>     -32768 to 32767.
>
> 3.1.7.  signed32
>
>     The type "signed32" represents an integer value in the range of
>     -2147483648 to 2147483647.
>
> 3.1.8.  signed64
>
>   
>
>
> Claise, Trammell            Standards Track                     [Page 9]
> 
> Internet-Draft          IPFIX Information Model          October 3, 2012
>
>
>     The type "signed64" represents an integer value in the range of
>     -9223372036854775808 to 9223372036854775807.
>
> 3.1.9.  float32
>
>     The type "float32" corresponds to an IEEE single-precision 32-bit
>     floating point type as defined in [IEEE.754.1985].
>
> 3.1.10.  float64
>
>     The type "float64" corresponds to an IEEE double-precision 64-bit
>     floating point type as defined in [IEEE.754.1985].
>
> 3.1.11.  boolean
>
>     The type "boolean" represents a binary value.  The only allowed
>     values are "true" and "false".
>
> 3.1.12.  macAddress
>
>     The type "macAddress" represents a string of 6 octets.
>
> 3.1.13.  octetArray
>
>     The type "octetArray" represents a finite-length string of octets.
>
> 3.1.14.  string
>
>     The type "string" represents a finite-length string of valid
>     characters from the Unicode character encoding set
>     [ISO.10646-1.1993].  Unicode allows for ASCII [ISO.646.1991] and many
>     other international character sets to be used.
>
> 3.1.15.  dateTimeSeconds
>
>     The data type dateTimeSeconds is an unsigned 32-bit integer
>     representing the number of seconds since the UNIX epoch, 1 January
>     1970 at 00:00 UTC, as defined in [POSIX.1].
>
> 3.1.16.  dateTimeMilliseconds
>
>     The data type dateTimeMilliseconds is an unsigned 64-bit integer
>     containing the number of milliseconds since the UNIX epoch, 1 January
>     1970 at 00:00 UTC, as defined in [POSIX.1].
>
> 3.1.17.  dateTimeMicroseconds
>
>     The type "dateTimeMicroseconds" represents a time value with
>   
>
>
> Claise, Trammell            Standards Track                    [Page 10]
> 
> Internet-Draft          IPFIX Information Model          October 3, 2012
>
>
>     microsecond precision according to the NTP Timestamp format as
>     defined in section 6 of [RFC5905].
>
> 3.1.18.  dateTimeNanoseconds
>
>     The type "dateTimeNanoseconds" represents a time value with
>     nanosecond precision according to the NTP Timestamp format as defined
>     in section 6 of [RFC5905].
>
> 3.1.19.  ipv4Address
>
>     The type "ipv4Address" represents a value of an IPv4 address.

"a value", as if it has many values? What exactly is the "value" of an 
address?

Consider "The type "ipv4Address" represents an IPv4 address." ?

>
> 3.1.20.  ipv6Address
>
>     The type "ipv6Address" represents a value of an IPv6 address.

Similarly.

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

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

>
> 3.2.1.  quantity
>
>     A numeric (integral or floating point) value representing a measured
>     value pertaining to the record. This is distinguished from counters
>     that represent an ongoing measured value whose "odometer" reading is
>     captured as part of a given record. This is the default semantic type
>     of all numeric data types.
>
> 3.2.2.  totalCounter
>
>     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 total counter is similar to the semantics of
>     counters used in SNMP, such as Counter32 defined in [RFC2578]. The
>     only difference between total counters and counters used in SNMP is
>     that the total counters have an initial value of 0. A total counter
>   
>
>
> Claise, Trammell            Standards Track                    [Page 11]
> 
> Internet-Draft          IPFIX Information Model          October 3, 2012
>
>
>     counts independently of the export of its value.
>
> 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.

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

>
> 3.2.5.  flags
>
>     An integral value that represents a set of bit fields. Logical
>     operations are appropriate on such values, but not other mathematical
>     operations. Flags MUST always be of an unsigned data type.
>
> 4.  Information Element Identifiers
>
>     All Information Elements defined in the IANA IPFIX Information
>     Element registry [IPFIX-IANA] have their identifiers assigned by
>     IANA.
>
>     The value of these identifiers is in the range of 1-32767. Within
>     this range, Information Element identifier values in the sub-range of
>     1-127 are compatible with field types used by NetFlow version 9
>     [RFC3954]; Information Element identifiers in this range MUST NOT be
>     assigned unless the Information Element is compatible with the
>     NetFlow version 9 protocol. Such Information Elements may ONLY be
>     requested by a NetFlow v9 expert, to be designated by the IESG.
>
>     In general, IANA will add newly registered Information Elements to
>     the registry, assigning the lowest available Information Element
>     identifier in the range 128-32767.
>
>     Enterprise-specific Information Element identifiers have the same
>   
>
>
> Claise, Trammell            Standards Track                    [Page 12]
> 
> Internet-Draft          IPFIX Information Model          October 3, 2012
>
>
>     range of 1-32767, but they are coupled with an additional enterprise
>     identifier. For enterprise-specific Information Elements, Information
>     Element identifier 0 is also reserved. Enterprise-specific
>     Information Element identifiers can be chosen by an enterprise
>     arbitrarily within the range of 1-32767. The same identifier may be
>     assigned by other enterprises for different purposes; these
>     Information Elements are distinct because the Information Element
>     identifier is coupled with an enterprise identifier.
>
>     Enterprise identifiers MUST be registered as SMI network management
>     private enterprise code numbers with IANA.  The registry can be found
>     at http://www.iana.org/assignments/enterprise-numbers.

Add the URL as an I-ref per earlier comment.

>
> 4.1.  NetFlow version 9 compatible Information Element Identifiers
>
>     Information Elements with identifiers from 1-127 are reserved for
>     compatibility with corresponding fields in NetFlow version 9
>     [RFC3954].

This simply repeats the second paragraph of section 4 above.

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

>
>     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.
>
>
>
> 6.  Extending the Information Model
>
>     A key requirement for IPFIX is to allow for extension of the
>     Information Model maintained by IANA. The process for extending the
>     Information Model is described in [IPFIX-IE-DOCTORS], which also
>     provides guidelines for authors and reviewers of new Information
>     Element definitions.
>
>     For new Information Elements, the type space defined in Section 3 can
>     be used. If required, new abstract data types can be added to the
>     subregistry defined in [RFC5610]. New abstract data types MUST be
>     defined in IETF Standards Track documents.

Isn't IANA the master reference for that registry?

What's the policy for adding new IEs? By which I mean, cite one of the 
definitions from section 4.1 of RFC5226.

>
>     Enterprises may wish to define Information Elements without
>     registering them with IANA. IPFIX explicitly supports
>     enterprise-specific Information Elements. Enterprise-specific
>     Information Elements are described in Sections 2.1 and 4; guidelines
>     for using them appear in [IPFIX-IE-DOCTORS].
>
>
>
>
>
>
>   
>
>
> Claise, Trammell            Standards Track                    [Page 20]
> 
> Internet-Draft          IPFIX Information Model          October 3, 2012
>
>
> 7.  IANA Considerations
>
> 7.1.  IPFIX Information Elements
>
> This document refers to Information Elements, for which the Internet
> Assigned Numbers Authority (IANA) has created the IPFIX Information
> Element Registry [IPFIX-IANA]. The columns of this registry must at
> minimum be able to store the information defined in the template in
> Section 2.1; it may contain other information as necessary for the
> management of the registry.
>
> New assignments for IPFIX Information Elements will be administered by

s/will be/are/

> IANA through Expert Review [RFC5226], i.e., review by one of a group of
> experts designated by the IESG. Further considerations for this review
> are specified in [IPFIX-IE-DOCTORS].
>
> Future assignments added to the IPFIX Information Element Registry which
> require subregistries for enumerated values (e.g. section 7.2, below)
> must have those subregistries added simultaneously with the new
> assignment; additions to these subregistries must be subject to Expert
> Review [RFC5226]. Unless specified at assignment time, the experts for
> the subregistry will be the same as for the Information Element registry
> as a whole.
>
> Changes may also be made to the entries in this registry from time to
> time; the process for these changes are specified in [IPFIX-IE-DOCTORS].
>
> [NOTE to IANA: please update the Reference for the IPFIX Information
> Element Registry to refer to this document.]
>
> [NOTE to IANA: on publication of this document, please set the Revision
> of all existing Information Elements to 0.]
>
> [NOTE to IANA: on publication of this document, please set the Date of
> all existing Information Elements to the publication date of this
> document.]
>
> [NOTE to IANA: on publication of this document, please set the Name of
> all existing Reserved Information Elements to "Assigned for NetFlow v9
> compatibility", and the reference to [RFC3954].]

NB this works now that 312 and 315 have been assigned as requested in 
data-link-layer-monitoring, else those would have been incorrectly 
attributed.

>
> 7.2.  MPLS Label Type Identifier
>
> Information Element #46, named mplsTopLabelType, carries MPLS label
> types.  Values for 5 different types have initially been defined.  For
> ensuring extensibility of this information, IANA has created a new
> subregistry for MPLS label types and filled it with the initial list
> from the description Information Element #46, mplsTopLabelType.
>   
>
>
> Claise, Trammell            Standards Track                    [Page 21]
> 
> Internet-Draft          IPFIX Information Model          October 3, 2012
>
>
> New assignments for MPLS label types will be administered by IANA

s/will be/are/

> through Expert Review [RFC5226], i.e., review by one of a group of
> experts designated by an IETF Area Director.  The group of experts must
> double check the label type definitions with already defined label types
> for completeness, accuracy, and redundancy.  The specification of new
> MPLS label types MUST be published using a well-established and
> persistent publication medium.
>
> [NOTE to IANA: please update the Reference for the IPFIX MPLS Label Type
> subregistry to refer to this document.]
>
> 7.3.  XML Namespace and Schema
>
> [IPFIX-XML-SCHEMA] defines an XML schema for IPFIX Information Element
> definitions.  All Information Elements specified in [IPFIX-IANA] are
> defined by this schema.  This schema may also be used for specifying
> further Information Elements in future extensions of the IPFIX
> information model in a machine-readable way.
>
> [IPFIX-XML-SCHEMA] uses URNs to describe an XML namespace and an XML
> schema for IPFIX Information Elements conforming to a registry mechanism
> described in [RFC3688].  Two URI assignments have been made.
>
> 1.  Registration for the IPFIX information model namespace
>      *  URI: urn:ietf:params:xml:ns:ipfix-info
>      *  Registrant Contact: IETF IPFIX Working Group <[email-masked]>,
>         as designated by the IESG <[email-masked]>.
>      *  XML: None.  Namespace URIs do not represent an XML.
>
> 2.  Registration for the IPFIX information model schema
>      *  URI: urn:ietf:params:xml:schema:ipfix-info
>      *  Registrant Contact: IETF IPFIX Working Group <[email-masked]>,
>         as designated by the IESG <[email-masked]>.
>
> Using a machine-readable syntax for the information model enables the
> creation of IPFIX-aware tools that can automatically adapt to
> extensions to the information model, by simply reading updated
> information model specifications.
>
> The wide availability of XML-aware tools and libraries for client
> devices is a primary consideration for this choice.  In particular,
> libraries for parsing XML documents are readily available.  Also,
> mechanisms such as the Extensible Stylesheet Language (XSL) allow for
> transforming a source XML document into other documents.  This
> document was authored in XML and transformed according to [RFC2629].
>
> It should be noted that the use of XML in Exporters, Collectors, or
> other tools is not mandatory for the deployment of IPFIX.  In
>   
>
>
> Claise, Trammell            Standards Track                    [Page 22]
> 
> Internet-Draft          IPFIX Information Model          October 3, 2012
>
>
> particular, Exporting Processes do not produce or consume XML as part
> of their operation.  It is expected that IPFIX Collectors MAY take
> advantage of the machine readability of the information model vs.
> hard coding their behavior or inventing proprietary means for
> accommodating extensions.
>
> [NOTE to IANA: please update the Reference for the the IPFIX
> information model namespace and schema to refer to this document.]
>
> 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

s/mentions/mentioned/

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

>
> When IANA receives a request to add, revise, or deprecate an Information
> Element in the IPFIX Information Elements Registr, it forwards the

s/Registr/Register/

> request to the IE-DOCTORS experts for review.
>
> When IANA receives an approval for a request to add an Information
> Element definition from the IE-DOCTORS experts, it adds that Information
> Element to the registry. The approved request may include changes from
> the original request.

Changes made by the requester, the experts, or IANA?

P.

>
> When IANA receives an approval for a request to revise an Information
> Element definition from the IE-DOCTORS experts, it changes that
> Information Element's definition in the registry, and updates the
> Revision and Date columns as appropriate. The approved request may
> include changes from the original request. If the original Information
> Element was added to the registry with IETF consensus (i.e., was defined
> by an RFC), the revision will require IETF consensus as well.
>
> When IANA receives an approval for a request to deprecate an Information
> Element definition from the IE-DOCTORS experts, it changes that
> Information Element's definition in the registry, and updates the
> Revision and Date columns as appropriate. The approved request may
> include changes from the original request. If the original Information
> Element was added to the registry with IETF consensus (i.e., was defined
> by an RFC), the deprecation will require IETF consensus as well.
>
>
> 8.  Security Considerations
>
> The IPFIX information model itself does not directly introduce security
> issues.  Rather, it defines a set of attributes that may for privacy or
> business issues be considered sensitive information.
>
>   
>
>
> Claise, Trammell            Standards Track                    [Page 23]
> 
> Internet-Draft          IPFIX Information Model          October 3, 2012
>
>
> For example, exporting values of header fields may make attacks possible
> for the receiver of this information, which would otherwise only be
> possible for direct observers of the reported Flows along the data path.
>
> The underlying protocol used to exchange the information described here
> must therefore apply appropriate procedures to guarantee the integrity
> and confidentiality of the exported information.  Such protocols are
> defined in separate documents, specifically the IPFIX protocol document
> [RFC5101bis].
>
> This document does not specify any Information Element carrying keying
> material.  If future extensions will do so, then appropriate precautions
> need to be taken for properly protecting such sensitive information.
>
> 9.  Acknowledgements
>
> The editors would like to thanks the authors of the RFC5102 [RFC5102],
> as this document is directly based upon this original RFC: Juergen
> Quittek, Stewart Bryant, Paul Aitken, and Jeff Meyer.
>
> 10.  References
>
> 10.1.  Normative References
>
>     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>                Requirement Levels", BCP 14, RFC 2119, March 1997.
>
>     [RFC5905]  Mills, D., Delaware, U., Martin, J., Burbank, J. and W.
>                Kasch, "Network Time Protocol Version 4: Protocol and
>                Algorithms Specification", RFC 5905, June 2010
>
>     [RFC5101bis]
>                Claise, B., and B. Trammell, Editors, "Specification of
>                the IP Flow Information eXport (IPFIX) Protocol for the
>                Exchange of IP Traffic Flow Information", draft-ietf-
>                ipfix-protocol-rfc5101bis-00, Work in Progress, November
>                2011.
>
>     [IPFIX-IE-DOCTORS]
>                Trammell, B., and B. Claise, "Guidelines for Authors and
>                Reviewers of IPFIX Information Elements", draft-ietf-
>                ipfix-ie-doctors-00, Work in Progress, November 2011.
>
> 10.2.  Informative References
>
>     [IEEE.754.1985]
>                Institute of Electrical and Electronics Engineers,
>                "Standard for Binary Floating-Point Arithmetic", IEEE
>   
>
>
> Claise, Trammell            Standards Track                    [Page 24]
> 
> Internet-Draft          IPFIX Information Model          October 3, 2012
>
>
>                Standard 754, August 1985.
>
>     [ISO.10646-1.1993]
>                International Organization for Standardization,
>                "Information Technology - Universal Multiple-octet coded
>                Character Set (UCS) - Part 1: Architecture and Basic
>                Multilingual Plane", ISO Standard 10646-1, May 1993.
>
>     [ISO.646.1991]
>                International Organization for Standardization,
>                "Information technology - ISO 7-bit coded character set
>                for information interchange", ISO Standard 646, 1991.
>                
>
>     [POSIX.1]  IEEE 1003.1-2008 - IEEE Standard for Information
>                Technology - Portable Operating System Interface, IEEE,
>                2008.
>
>     [RFC2578]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
>                "Structure of Management Information Version 2 (SMIv2)",
>                STD 58, RFC 2578, April 1999.
>
>     [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
>                June 1999.
>
>     [RFC3234]  Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
>                Issues", RFC 3234, February 2002.
>
>     [RFC3444]  Pras, A. and J. Schoenwaelder, "On the Difference between
>                Information Models and Data Models", RFC 3444, January
>                2003.
>
>     [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
>                January 2004.
>
>     [RFC3917]  Quittek, J., Zseby, T., Claise, B., and S. Zander,
>                "Requirements for IP Flow Information Export (IPFIX)", RFC
>                3917, October 2004.
>
>     [RFC3954]  Claise, B., Ed., "Cisco Systems NetFlow Services Export
>                Version 9", RFC 3954, October 2004.
>
>     [RFC5102]  Trammell, B., and E. Boschi, "Bidirectional Flow Export
>                Using IP Flow Information Export (IPFIX)", RFC 5103,
>                January 2008.
>
>     [RFC5103]  Quittek, J., Bryant, S. Claise, B., Aitken, P., and J.
>                Meyer, "Information Model for IP Flow Information Export",
>   
>
>
> Claise, Trammell            Standards Track                    [Page 25]
> 
> Internet-Draft          IPFIX Information Model          October 3, 2012
>
>
>                RFC 5102, January 2008.
>
>     [RFC5153]  Boschi, E., Mark, L., Quittek J., and P. Aitken, "IP Flow
>                Information Export (IPFIX) Implementation Guidelines",
>                RFC5153, April 2008.
>
>     [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
>                IANA Considerations Section in RFCs", BCP 26, RFC 5226,
>                May 2008.
>
>     [RFC5470]  Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek,
>                "Architecture for IP Flow Information Export", RFC5470,
>                March 2009.
>
>     [RFC5471]  Schmoll, C., Aitken, P., and B. Claise, "Guidelines for IP
>                Flow Information Export (IPFIX) Testing", RFC5471, March
>                2009.
>
>     [RFC5472]  Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP
>                Flow Information Export (IPFIX) Applicability", RFC5472,
>                March 2009.
>
>     [RFC5473]  Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy
>                in IP Flow Information Export (IPFIX) and Packet Sampling
>                (PSAMP) Reports", RFC5473, March 2009.
>
>     [RFC5610]  Boschi, E., Trammell, B., Mark, L., and T. Zseby,
>                "Exporting Type Information for IP Flow Information Export
>                (IPFIX) Information Elements", July 2009.
>
>     [RFC6313]  Claise, B., Dhandapani, G., Aitken, P, and S. Yates,
>                "Export of Structured Data in IP Flow Information Export
>                (IPFIX)", RFC6313, July 2011.
>
>     [RFC6183]  Kobayashi, A., Claise, B., Muenz, G, and K. Ishibashi, "IP
>                Flow Information Export (IPFIX) Mediation: Framework",
>                RFC6183, April 2011.
>
>     [IPFIX-CONF]
>                Muenz, G., Claise, B., and P. Aitken, "Configuration Data
>                Model for IPFIX and PSAMP", draft-ietf-ipfix-
>                configuration-model-10, Work in Progress, July 2011.
>
>     [IPFIX-MED-PROTO]
>                Claise, B., Kobayashi, A., and B. Trammell, "Specification
>                of the Protocol for IPFIX Mediations", draft-ietf-ipfix-
>                mediation-protocol-00, Work in Progress, December 2011.
>
>   
>
>
> Claise, Trammell            Standards Track                    [Page 26]
> 
> Internet-Draft          IPFIX Information Model          October 3, 2012
>
>
>     [RFC5815bis]
>                Dietz, T., Kobayashi, A., Claise, B., and G. Muenz,
>                "Definitions of Managed Objects for IP Flow Information
>                Export", draft-ietf-ipfix-rfc5815bis-01.txt, Work in
>                Progress, January 2012.
>
>     [IPFIX-IANA]
>                http://www.iana.org/assignments/ipfix/ipfix.xml
>
>     [IPFIX-XML-SCHEMA]
>                http://www.iana.org/assignments/xml-
>                registry/schema/ipfix.xsd
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>   
>
>
> Claise, Trammell            Standards Track                    [Page 27]
> 
> Internet-Draft          IPFIX Information Model          October 3, 2012
>
>
> Authors' Addresses
>
>     Benoit Claise
>     Cisco Systems, Inc.
>     De Kleetlaan 6a b1
>     1831 Diegem
>     Belgium
>
>     Phone: +32 2 704 5622
>     EMail: [email-masked]
>
>
>     Brian Trammell
>     Swiss Federal Institute of Technology Zurich
>     Gloriastrasse 35
>     8092 Zurich
>     Switzerland
>
>     Phone: +41 44 632 70 13
>     EMail: [email-masked]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Claise, Trammell            Standards Track                    [Page 28]

---

From: Brian Trammell <[email-masked]>
Date: Wed, 31 Oct 2012 10:29:08 +0100

Hi, Paul, all,

A more detailed response to your review follows (thank you!!); however, there is a rather important implicit question there that I wanted to put to the working group before we meet in Atlanta.

That is: does anyone at all find the content (IE categorization and possibly deprecated restrictions) of section 5 of RFC5102bis useful?  Categorization was not carried over into the IANA registry (and in any case would require redefinition as IPFIX applications move down to layer 2 and up to layer 7), and Paul makes convincing arguments that most of the rest of the content of the section are historic restrictions on information model usage.

My proposal is to remove the section completely and replace it with a historical note stating that section 5 of 5102 defined the Information Model before the IANA registry existed, but that the IANA registry is now normative.

Comments?

Thanks, cheers,

Brian

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

> Nevil, All,
> 
>> The WG Last Call for this I-D starts now, and will run until Monday, 22 October.
> 
> 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
>    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.
> 
> 
> 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?
> 
> 
>> 
> Section 3.2.1 specifies that "quantity" is the default semantic, so this isn't really a MAY.
> Combination of the above rules means that IANA will name an IE "foo", while the ES equivalent is named "enterpriseFoo".
> "a value", as if it has many values? What exactly is the "value" of an address?
> 
> eg, if new semantics are added, they'll be listed in IANA without raising errata against 5610.
> 
> 
> What if the cache entry is removed but not exported (eg, an export filter blocks the export) ?
> ie, the reset action is more to do with the cache entry expiring than whatever happens to it next.
> 
> 
>> 
>> 3.2.4.  identifier
>> 
> We could also have non-numeric identifiers, eg wlanSSID is a string identifier.
> 
> 
>> 
>> 3.2.5.  flags
>> 
> TBD: are categories useful? If not, let's say they're deprecated and not discuss them further.
> 
> 
>> 
>>    1.   Identifiers
> In some cases, the same IE may be observed in different ways according to the implementation.
> Today we may not be able to determine all the key fields until some variable number of packets have been observed.
> It's a bit dangerous to give this example, since it could be misread as being the actual definition.
> 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.
> 
> 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.
> 
> 
> What's the policy for adding new IEs? By which I mean, cite one of the definitions from section 4.1 of RFC5226.
> 
> 
>> 
> NB this works now that 312 and 315 have been assigned as requested in data-link-layer-monitoring, else those would have been incorrectly attributed.
> 
> 
>> 
> When was/will that be done? Where are/will they be listed? How will IANA know who they are?
> 
> 
>>

---

From: Brian Trammell <[email-masked]>
Date: Wed, 31 Oct 2012 10:42:58 +0100

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

>    The following IEs are not mentioned here, although they are detailed in draft-yourtchenko-cisco-ies :

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.

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

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

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

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

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

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

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

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

> 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

---

From: Paul Aitken <[email-masked]>
Date: Wed, 31 Oct 2012 13:26:54 +0000

Brian,

A few replies inline; other stuff cut for brevity.

> 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 su…

To be clear, Nevil started WGLC on -05 (see the subject line above) just 
hours after -06 was announced. I reviewed -06.

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

~somewhat. However proto-IE-doctors should check that these IE's all 
conform to the 5102bis specifications.

> I'm not an nroff hacker. Any pointers?

Personally, I had to hack rfc2xml to make it do what I wanted.

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

Since this doc obsoletes 5102, I find it useful to get a high level 
overview of what was changed, and for that overview to be given early in 
the document.

Else, add an editorial note to remove the section.

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

So does the "names must be unique" rule include or exclude case?

eg, are "fondantHem" and "fondAnthem" the same name? Are "coveredRaft" 
and "coveRedraft" the same?

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

By their nature, delta counters don't exist after they expire or are 
exported - so they're not really reset.

In fact the total and delta counter mechanisms are identical; only their 
observation periods set them apart. ie the difference between them is 
due to time. So I think the definition should capture that.

P.

---

From: Brian Trammell <[email-masked]>
Date: Wed, 31 Oct 2012 15:33:20 +0100

hi Paul,

(inline)^n.

On 31 Oct 2012, at 14:26 , Paul Aitken wrote:

> To be clear, Nevil started WGLC on -05 (see the subject line above) just hours after -06 was announced. I reviewed -06.

Ah, oops. I presumed that was an oversight; I thought -06 got WGLC'd.

> ~somewhat. However proto-IE-doctors should check that these IE's all conform to the 5102bis specifications.

Point; will make a note of this list somewhere.

> Personally, I had to hack rfc2xml to make it do what I wanted.

Bah; okay, I'll look somewhere for some nroff that does things correctly and copy from that then.

> Since this doc obsoletes 5102, I find it useful to get a high level overview of what was changed, and for that overview to be given early in the document.

Okay, that's one vote, so we'll keep it.

> eg, are "fondantHem" and "fondAnthem" the same name? Are "coveredRaft" and "coveRedraft" the same?

Ugh. Point. My inclination is we should define naming match as case-insensitive, since the intention is not to have these names used on the wire, and the only examples I can think of of collision are typographical in nature.

> By their nature, delta counters don't exist after they expire or are exported - so they're not really reset.

Implementation-dependent. You cannot at the protocol level force the MP implementation to forget things it doesn't want to.

> In fact the total and delta counter mechanisms are identical; only their observation periods set them apart. ie the difference between them is due to time. So I think the definition should capture that.

again, _in the exemplar design you use to reason about the protocol_ yes, but the exact implementation of these counters is (rightly) left out of the protocol.

Which, indeed, the more neutral language I proposed above fails to do (it captures the concepts of "reset" and "expiration"). How about:

A delta counter counts only observations made since the last export of a Flow Record for a given Flow.

Cheers,

Brian

---

From: Paul Aitken <[email-masked]>
Date: Wed, 31 Oct 2012 14:55:47 +0000

Brian,

> My inclination is we should define naming match as case-insensitive, since the intention is not to have these names used on the wire, and the only examples I can think of of collision are typographical in nature.

+1.

> How about:

That's back to my point that the observation might not be exported.

More to the point, delta/total counting is a function of the MP. Whether 
the MP hands data to the EP, and what the EP does or does not do with 
that data, should have no bearing on how the MP meters subsequent data. 
So the definition should be purely in MP terms ("last export" being an 
EP term).

P.

---

From: Brian Trammell <[email-masked]>
Date: Wed, 31 Oct 2012 15:58:44 +0100

Hi, Paul,

On 31 Oct 2012, at 15:55 , Paul Aitken wrote:

> More to the point, delta/total counting is a function of the MP. Whether the MP hands data to the EP, and what the EP does or does not do with that data, should have no bearing on how the MP meters subsequent data. So the definition should be purely in MP terms ("last export" being an EP term).

What verb does the MP apply to a unit of information when it gives it to the EP?

A delta counter counts only observations made since the last Flow Record for a given Flow was measured.

Or maybe we can sidestep the action completely:

A delta counter counts only observations made since the previous Flow Record for a given Flow.

Cheers,

Brian

---

From: Paul Aitken <[email-masked]>
Date: Wed, 31 Oct 2012 15:22:19 +0000

Brian,

> A delta counter counts only observations made since the previous Flow Record for a given Flow.

No, that's still involving export.

What should the MP do if the flow ends *but isn't exported* ? Just the 
same as when the flow *is* exported. So the definition of deltaCount is 
independent of export, flow records, etc.

So the definitions have to be about the metering time, and particularly 
that we've started metering again. However, we can't write that, because 
some implementations may not hold state that tells them this. So all we 
know is that totalCounters meter from the start of the MP, while delta 
counters meter a potentially shorter interval, reporting the value 
metered since the start of that interval.

P.

---

From: Brian Trammell <[email-masked]>
Date: Thu, 1 Nov 2012 07:35:05 +0100

On Oct 31, 2012, at 4:22 PM, Paul Aitken wrote:

> What should the MP do if the flow ends *but isn't exported* ?

In the idealized architecture, the MP can't know, so it just keeps exporting, clearly. If your implementation allows loss between the MP and the EP, there is nothing conceptually different between this situation and loss between the EP and the CP, except you can't use wireshark to debug it. :)

> Just the same as when the flow *is* exported. So the definition of deltaCount is independent of export, flow records, etc.
> 
> So the definitions have to be about the metering time, and particularly that we've started metering again. However, we can't write that, because some implementations may not hold state that tells them this. So all we know is that totalCounters meter from the start of the MP, while delta counters meter a potentially shorter interval, reporting the value metered since the start of that interval.

I've stared at this for a while and I can't come up with a way to express it that's unconvoluted enough for my taste. I still don't see why my last attempt at a definition above necessarily invokes export -- it's the MP sending on the information in a proto-Flow Record to the EP and deciding to start the counters over. So I suppose for the corner case that the MP sends something up to the EP and the EP drops it we could complicate the language a bit:

A delta counter counts only observations made since the previous Flow Record for a given Flow, as seen from the point of view of the Metering Process (i.e., discounting any failure or refusal to export the Flow Record on the part of the Exporting Process or failure to receive the Flow Record on the part of the Collecting Process).

although truth be told I think this overly complicated and unreadable for the magnitude of the corner case it addresses. Maybe without the i.e. phrase?

Cheers,

Brian