[IPFIX] WGLC for draft-ietf-ipfix-protocol-rfc5101bis-03

[Paul Aitken <[e-mail]>]

Dear all,

Here's a comprehensive review of draft-ietf-ipfix-protocol-rfc5101bis-03 :


>   
>
>
>
> Network Working Group                                     B. Claise, Ed.
> Internet Draft                                       Cisco Systems, Inc.
> Obsoletes: 5101                                         B. Trammell, Ed.
> Category: Standards Track                                     ETH Zurich
> Expires: May 24, 2013                                  November 20, 2012
>
>
>     Specification of the IP Flow Information eXport (IPFIX) Protocol
>                    for the Exchange of Flow Information
>                  draft-ietf-ipfix-protocol-rfc5101bis-03
>                                      
>
> Abstract
>
>     This document specifies the IP Flow Information Export (IPFIX)
>     protocol that serves for transmitting Traffic Flow information over
>     the network.  In order to transmit Traffic Flow information from an
>     Exporting Process to an information Collecting Process, a common
>     representation of flow data and a standard means of communicating
>     them is required.  This document describes how the IPFIX Data and
>     Template Records are carried over a number of transport protocols
>     from an IPFIX Exporting Process to an IPFIX Collecting Process.  This
>     document obsoletes RFC 5101.
>
> 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.

Then it's expired already. Can we run a valid WGLC on an expired version?


>
> Copyright Notice
>
>     Copyright (c) 2011 IETF Trust and the persons identified as the
>     document authors.  All rights reserved.

== The copyright year in the IETF Trust and authors Copyright Line does 
not match the current year


>
>     This document is subject to BCP 78 and the IETF Trust's Legal
>     Provisions Relating to IETF Documents
>   
>
>
> <Claise, et al.>            Standards Track                     [Page 1]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     (http://trustee.ietf.org/license-info) in effect on the date of
>     publication of this document.  Please review these documents
>     carefully, as they describe your rights and restrictions with respect
>     to this document.  Code Components extracted from this document must
>     include Simplified BSD License text as described in Section 4.e of
>     the Trust Legal Provisions and are provided without warranty as
>     described in the Simplified BSD License.
>
>
>
>
> Table of Contents
>
>       1.1.  Changes since RFC 5101 . . . . . . . . . . . . . . . . . .  4
>       1.2.  IPFIX Documents Overview . . . . . . . . . . . . . . . . .  5
>     2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
>       2.1.  Terminology Summary Table  . . . . . . . . . . . . . . . . 11
>     3.  IPFIX Message Format . . . . . . . . . . . . . . . . . . . . . 11
>       3.1.  Message Header Format  . . . . . . . . . . . . . . . . . . 14
>       3.2.  Field Specifier Format . . . . . . . . . . . . . . . . . . 15
>       3.3.  Set and Set Header Format  . . . . . . . . . . . . . . . . 16
>         3.3.1.  Set Format . . . . . . . . . . . . . . . . . . . . . . 16
>         3.3.2.  Set Header Format  . . . . . . . . . . . . . . . . . . 17
>       3.4.   Record Format . . . . . . . . . . . . . . . . . . . . . . 18
>         3.4.1.  Template Record Format . . . . . . . . . . . . . . . . 18
>         3.4.2.  Options Template Record Format . . . . . . . . . . . . 20
>           3.4.2.1.  Scope  . . . . . . . . . . . . . . . . . . . . . . 21
>           3.4.2.2.  Options Template Record Format . . . . . . . . . . 22
>         3.4.3.  Data Record Format . . . . . . . . . . . . . . . . . . 24
>     4.  Specific Reporting Requirements  . . . . . . . . . . . . . . . 25
>       4.1.  The Metering Process Statistics Options Template . . . . . 25
>       4.2.  The Metering Process Reliability Statistics Options
>             Template . . . . . . . . . . . . . . . . . . . . . . . . . 26
>       4.3.  The Exporting Process Reliability Statistics Options
>             Template . . . . . . . . . . . . . . . . . . . . . . . . . 28
>       4.4.  The Flow Keys Options Template . . . . . . . . . . . . . . 29
>     5.  IPFIX Message Header Export Time and Flow Record Time  . . . . 30
>     6.  Linkage with the Information Model . . . . . . . . . . . . . . 30
>       6.1.  Encoding of IPFIX Data Types . . . . . . . . . . . . . . . 31
>         6.1.1. Integral Data Types . . . . . . . . . . . . . . . . . . 31
>         6.1.2. Address Types . . . . . . . . . . . . . . . . . . . . . 31
>         6.1.3. float32 . . . . . . . . . . . . . . . . . . . . . . . . 31
>         6.1.4. float64 . . . . . . . . . . . . . . . . . . . . . . . . 31
>         6.1.5. boolean . . . . . . . . . . . . . . . . . . . . . . . . 31
>         6.1.6. string and octetArray . . . . . . . . . . . . . . . . . 31
>         6.1.7. dateTimeSeconds . . . . . . . . . . . . . . . . . . . . 31
>         6.1.8. dateTimeMilliseconds  . . . . . . . . . . . . . . . . . 32
>         6.1.9  dateTimeMicroseconds  . . . . . . . . . . . . . . . . . 32
>   
>
>
> <Claise, et al.>            Standards Track                     [Page 2]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>         6.1.10 dateTimeNanoseconds . . . . . . . . . . . . . . . . . . 32
>       6.2.  Reduced Size Encoding  . . . . . . . . . . . . . . . . . . 33
>     7.  Variable-Length Information Element  . . . . . . . . . . . . . 34
>     8.  Template Management  . . . . . . . . . . . . . . . . . . . . . 36
>       8.1. Template Withdrawal and Redefinition  . . . . . . . . . . . 37
>       8.2   Sequencing Template Management Actions . . . . . . . . . . 39
>       8.3.  Additional considerations for Template Management over
>             SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
>       8.4.  Additional considerations for Template Management over
>             UDP  . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
>     9. The Collecting Process's Side . . . . . . . . . . . . . . . . . 41
>       9.1.  Additional considerations for SCTP Collecting Processes  . 42
>       9.2.  Additional considerations for UDP Collecting Processes . . 42
>     10.  Transport Protocol  . . . . . . . . . . . . . . . . . . . . . 42
>       10.1.  Transport Compliance and Transport Usage  . . . . . . . . 44
>       10.2.  SCTP  . . . . . . . . . . . . . . . . . . . . . . . . . . 44
>         10.2.1.  Congestion Avoidance  . . . . . . . . . . . . . . . . 44
>         10.2.2.  Reliability . . . . . . . . . . . . . . . . . . . . . 44
>         10.2.3.  MTU . . . . . . . . . . . . . . . . . . . . . . . . . 45
>         10.2.4.  Association Establishment and Shutdown  . . . . . . . 45
>         10.2.5.  Failover  . . . . . . . . . . . . . . . . . . . . . . 46
>         10.2.6.  Streams . . . . . . . . . . . . . . . . . . . . . . . 46
>       10.3.  UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
>         10.3.1.  Congestion Avoidance  . . . . . . . . . . . . . . . . 46
>         10.3.2.  Reliability . . . . . . . . . . . . . . . . . . . . . 46
>         10.3.3.  MTU . . . . . . . . . . . . . . . . . . . . . . . . . 47
>         10.3.4.  Session Establishment and Shutdown  . . . . . . . . . 47
>         10.3.5.  Failover and Session Duplication  . . . . . . . . . . 47
>       10.4.  TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
>         10.4.1.  Congestion Avoidance  . . . . . . . . . . . . . . . . 48
>         10.4.2.  Reliability . . . . . . . . . . . . . . . . . . . . . 49
>         10.4.3.  MTU . . . . . . . . . . . . . . . . . . . . . . . . . 49
>         10.4.4.  Connection Establishment, Shutdown, and Restart . . . 49
>         10.4.5.  Failover  . . . . . . . . . . . . . . . . . . . . . . 50
>     11.  Security Considerations . . . . . . . . . . . . . . . . . . . 50
>       11.1.  Applicability of TLS and DTLS . . . . . . . . . . . . . . 51
>       11.2.  Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 52
>       11.3.  Authentication  . . . . . . . . . . . . . . . . . . . . . 52
>       11.4.  Protection against DoS Attacks  . . . . . . . . . . . . . 53
>       11.5.  When DTLS or TLS Is Not an Option . . . . . . . . . . . . 54
>       11.6.  Logging an IPFIX Attack . . . . . . . . . . . . . . . . . 55
>       11.7.  Securing the Collector  . . . . . . . . . . . . . . . . . 55
>     12.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
>     Appendix A.  IPFIX Encoding Examples . . . . . . . . . . . . . . . 56
>       A.1.  Message Header Example . . . . . . . . . . . . . . . . . . 56
>       A.2.  Template Set Examples  . . . . . . . . . . . . . . . . . . 57
>         A.2.1.  Template Set Using IETF-Specified Information
>                 Elements . . . . . . . . . . . . . . . . . . . . . . . 57
>   
>
>
> <Claise, et al.>            Standards Track                     [Page 3]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>         A.2.2.  Template Set Using Enterprise-Specific Information
>                 Elements . . . . . . . . . . . . . . . . . . . . . . . 57
>       A.3.  Data Set Example . . . . . . . . . . . . . . . . . . . . . 59
>       A.4.  Options Template Set Examples  . . . . . . . . . . . . . . 60
>         A.4.1.  Options Template Set Using IETF-Specified
>                 Information Elements . . . . . . . . . . . . . . . . . 60
>         A.4.2.  Options Template Set Using Enterprise-Specific
>                 Information  . . . . . . . . . . . . . . . . . . . . . 60
>         A.4.3.  Options Template Set Using an Enterprise-Specific
>                 Scope  . . . . . . . . . . . . . . . . . . . . . . . . 61
>         A.4.4.  Data Set Using an Enterprise-Specific Scope  . . . . . 62
>       A.5.  Variable-Length Information Element Examples . . . . . . . 63
>         A.5.1.  Example of Variable-Length Information Element with
>                 Length . . . . . . . . . . . . . . . . . . . . . . . . 63
>         A.5.2.  Example of Variable-Length Information Element with
>                 3 Octet Length Encoding  . . . . . . . . . . . . . . . 63
>     References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
>     Normative References . . . . . . . . . . . . . . . . . . . . . . . 63
>     Informative References . . . . . . . . . . . . . . . . . . . . . . 64
>     Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . . . 66
>     Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67
>
>
>
>
>     1.  Introduction
>
>     Traffic on a data network can be seen as consisting of flows passing
>     through network elements. It is often interesting, useful, or even
>     necessary to have access to information about these flows that pass
>     through the network elements for administrative or other purposes. A
>     collecting process should be able to receive the flow information

The earlier Abstract uses capitalised "Collecting Process".


>     passing through multiple network elements within the data network.
>     This requires uniformity in the method of representing the flow
>     information and the means of communicating the flows from the network
>     elements to the collection point. This document specifies a protocol
>     to achieve these aforementioned requirements. This document specifies
>     in detail the representation of different flows, the additional data
>     required for flow interpretation, packet format, transport mechanisms
>     used, security concerns, etc.
>
> 1.1.  Changes since RFC 5101

This section says *what* changes were made. However, it's missing a 
statement on *why* 5101 had to be rewritten. What were the main reasons 
for rewriting 5101?


>     This document obsoletes the Proposed Standard revision of the IPFIX
>     Protocol Specification [RFC5101]. The protocol specified by this
>     document is interoperable with the protocol as specified in
>     [RFC5101]. The following changes have been made to this document with
>     respect to the previous document:
>   
>
>
> <Claise, et al.>            Standards Track                     [Page 4]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     - EDITOR'S NOTE: not sure if we need to this information
>        Errata ID: 1655 (technical)
>        Errata ID: 2791 (technical)
>        Errata ID: 2814 (editorial)
>        Errata ID: 1818 (editorial)
>        Errata ID: 2792 (editorial)
>        Errata ID: 2888 (editorial)
>        Errata ID: 2889 (editorial)
>        Errata ID: 2890 (editorial)
>        Errata ID: 2891 (editorial)
>        Errata ID: 2892 (editorial)
>        Errata ID: 2903 (editorial)
>        Errata ID: 2761 (editorial)
>        Errata ID: 2762 (editorial)
>        Errata ID: 2763 (editorial)
>        Errata ID: 2764 (editorial)
>        Errata ID: 2852 (editorial)
>        Errata ID: 2857 (editorial)
>
>     - The encoding of the dateTimeSeconds, dateTimeMilliseconds,
>     dateTimeMicroseconds, and dateTimeNanoseconds data types, and the
>     related encoding of the IPFIX Message Header Export Time field, have
>     been clarified, especially with respect to the epoch upon which the
>     timestamp data types are based.
>
>     - Clarifications on encoding, especially in Section 6: all IPFIX
>     values encoded big-endian.
>
>     - Template management in section 8 has been simplified, and made as
>     independent of transport protocol as is interoperably possible, by
>     relaxing restrictions on template management actions.
>
>     - Editorial changes, including structural changes to sections 8, 9,
>     and 10 to improve readability.
>
>
> 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
>     Process is defined in [RFC5470], per the requirements defined in
>     [RFC3917].  This document specifies how IPFIX data records and
>     templates are carried via a number of transport protocols from IPFIX
>     Exporting Processes to IPFIX Collecting Processes.
>
>     Four IPFIX optimizations/extensions are currently specified: a
>     bandwidth saving method for the IPFIX protocol in [RFC5473], an
>   
>
>
> <Claise, et al.>            Standards Track                     [Page 5]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     efficient method for exporting bidirectionalflow  in [RFC5103], a

"flows"


>     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 theIPIFX  Mediation Framework [RFC6183].

Although "IP InFormation eXport" is arguably a better name, the current 
name is "IPFIX".


>
>     IPFIX has a formal description of IPFIX Information Elements, their
>     name, type and additional semantic information, as specified in
>     [RFC5102bis], with the export of the Information Element types
>     specified in [RFC5610].
>
>     [IPFIX-CONF] specifies a data model for configuring and monitoring

RFC6728.


>     IPFIX and PSAMP compliant devices using the NETCONF protocol, while
>     the  [RFC5815bis] specifies a MIB module for monitoring.

remove "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.  Terminology
>
>     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 RFC 2119 [RFC2119].
>
>     The definitions of the basic terms like Traffic Flow, Exporting
>     Process, Collecting Process, Observation Points, etc.  are
>     semantically identical to those found in the IPFIX requirements
>     document [RFC3917].  Some of the terms have been expanded for more
>     clarity when defining the protocol.  Additional terms required for
>     the protocol have also been defined.  Definitions in this document
>     and in [RFC5470] are equivalent, except that definitions that are
>     only relevant to the IPFIX protocol only appear here.
>
>     The terminology summary table in Section 2.1 gives a quick overview
>     of the relationships between some of the different terms defined.
>
>     Observation Point
>
>        An Observation Point is a location in the network where packets
>        can be observed.  Examples include: a line to which a probe is
>        attached, a shared medium, such as an Ethernet-based LAN, a single
>        port of a router, or a set of interfaces (physical or logical) of
>        a router.
>   
>
>
> <Claise, et al.>            Standards Track                     [Page 6]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>        Note that every Observation Point is associated with an
>        Observation Domain (defined below), and that one Observation Point
>        may be a superset of several other Observation Points.  For
>        example, one Observation Point can be an entire line card.  That
>        would be the superset of the individual Observation Points at the
>        line card's interfaces.
>
>     Observation Domain
>
>        An Observation Domain is the largest set of Observation Points for
>        which Flow information can be aggregated by a Metering Process.
>        For example, a router line card may be an Observation Domain if it
>        is composed of several interfaces, each of which is an Observation
>        Point.  In the IPFIX Message it generates, the Observation Domain
>        includes its Observation Domain ID, which is unique per Exporting
>        Process.  That way, the Collecting Process can identify the
>        specific Observation Domain from the Exporter that sends the IPFIX
>        Messages. Every Observation Point is associated with an
>        Observation Domain.  It is RECOMMENDED that Observation Domain IDs
>        also be unique per IPFIX Device.
>
>     Traffic Flow or Flow
>
>        There are several definitions of the term 'flow' being used by the
>        Internet community.  Within the context of IPFIX we use the
>        following definition:
>
>        A Flow is defined as a set of packets passing an Observation Point
>        in the network during a certain time interval.  All packets
>        belonging to a particular Flow have a set of common properties.
>        Each property is defined as the result of applying a function to
>        the values of:
>
>           1. one or more packet header fields (e.g., destination IP
>              address), transport header fields (e.g., destination port
>              number), or application header fields (e.g., RTP header
>              fields [RFC3550]).
>
>           2. one or more characteristics of the packet itself (e.g.,
>              number of MPLS labels, etc...).
>
>           3. one or more of fields derived from packet treatment (e.g.,
>              next hop IP address, the output interface, etc...).
>
>        A packet is defined as belonging to a Flow if it completely
>        satisfies all the defined properties of the Flow.
>
>        Note that the set of packets represented by a Flow may be empty;
>   
>
>
> <Claise, et al.>            Standards Track                     [Page 7]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>        that is, a Flow may represent zero or more packets. Note also that
>        as sampling is a packettreatent, this definition includes packets

"treatment"


>        selected by a sampling mechanism.

"also" seems to be in the wrong place. Consider: "Note also that as 
sampling is a packet treatment, this definition also includes packets 
selected by a sampling mechanism."


>
>     Flow Key
>
>        Each of the fields that:
>
>        1.  belong to the packet header (e.g., destination IP address),
>
>        2.  are a property of the packet itself (e.g., packet length),
>
>        3.  are derived from packet treatment (e.g., Autonomous System
>            (AS) number),
>
>        and that are used to define a Flow are termed Flow Keys.

There's an implicit OR between 1, 2, and 3 that's confused by the final 
"and that". Putting ", or" at the end of 1 and 2 might help.


>
>     Flow Record
>
>        A Flow Record contains information about a specific Flow that was
>        observed at an Observation Point.  A Flow Record contains measured
>        properties of the Flow (e.g., the total number of bytes for all
>        the Flow's packets) and usually characteristic properties of the
>        Flow (e.g., source IP address).

Say, "and usually contains characteristic properties", else the 
statement is that "A FR contains ... usually characteristic properties", 
which is something else entirely.


>
>     Metering Process
>
>        The Metering Process generates Flow Records.  Inputs to the
>        process are packet headers and characteristics observed at an
>        Observation Point, and packet treatment at the Observation Point
>        (for example, the selected output interface).

The inputs could come from multiple OPs, and the packet treatment could 
be at a distinct OP from where the characteristics were observed.
eg, suppose a sampler and a filter. That's two treatment OPs.

 From the earlier definition, "one Observation Point may be a superset 
of several other Observation Points". However, it's may not be obvious 
to the IPFIX novice that this applies here.


>
>        The Metering Process consists of a set of functions that includes
>        packet header capturing, timestamping, sampling, classifying, and
>        maintaining Flow Records.
>
>        The maintenance of Flow Records may include creating new records,
>        updating existing ones, computing Flow statistics, deriving
>        further Flow properties, detecting Flow expiration, passing Flow
>        Records to the Exporting Process, and deleting Flow Records.
>
>     Exporting Process
>
>        The Exporting Process sends Flow Records to one or more Collecting

Consider "zero or more", so the EP can be present but disabled or 
inactive, not have a reachable CP, or can be filtering what it exports.
Else, if it's unable to export or decides not to export a particular FR, 
it's technically not longer a 5101bis-compliant EP :-(

Consider "sends Flow Records and Templates".


>        Processes.  The Flow Records are generated by one or more Metering
>        Processes.
>
>     Exporter
>   
>
>
> <Claise, et al.>            Standards Track                     [Page 8]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>        A device that hosts one or more Exporting Processes is termed an
>        Exporter.
>
>     IPFIX Device
>
>        An IPFIX Device hosts at least one Exporting Process.  It may host
>        further Exporting Processes and arbitrary numbers of Observation
>        Points and Metering Processes.
>
>     Collecting Process
>
>        A Collecting Process receives Flow Records from one or more
>        Exporting Processes.  The Collecting Process might process or

So it's not actually a CP until it receives data? ie, if it doesn't 
receive anything, then it's not a CP?


>        store received Flow Records, but such actions are out of scope for
>        this document.
>
>     Collector
>
>        A device that hosts one or more Collecting Processes is termed a
>        Collector.
>
>     Template
>
>        A Template is an ordered sequence of <type, length> pairs used to
>        completely specify the structure and semantics of a particular set
>        of information that needs to be communicated from an IPFIX Device
>        to a Collector.  Each Template is uniquely identifiable by means
>        of a Template ID.

We're moving away from this with SD where type and semantics are 
contained in data records. Potentially similarly with EFS.


>
>     IPFIX Message
>
>        An IPFIX Message is a message originating at the Exporting Process
>        that carries the IPFIX records of this Exporting Process and whose
>        destination is a Collecting Process.  An IPFIX Message is
>        encapsulated at the transport layer.
>
>     Message Header
>
>        The Message Header is the first part of an IPFIX Message, which
>        provides basic information about the message, such as the IPFIX
>        version, length of the message, message sequence number, etc.
>
>     Template Record
>
>        A Template Record defines the structure and interpretation of
>        fields in a Data Record.
>
>     Data Record
>   
>
>
> <Claise, et al.>            Standards Track                     [Page 9]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>        A Data Record is a record that contains values of the parameters
>        corresponding to a Template Record.

Clarify the difference between "Flow Record" and "Data Record" ?


>
>     Options Template Record
>
>        An Options Template Record is a Template Record that defines the
>        structure and interpretation of fields in a Data Record, including
>        defining how to scope the applicability of the Data Record.
>
>     Set
>
>        Set is a generic term for a collection of records that have a
>        similar structure.  In an IPFIX Message, one or more Sets follow
>        the Message Header.

Then is a header with no sets an invalid IPFIX Message?
Maybe it's a new exporter informing the CP that it's there; maybe it's a 
connectivity test. It's an empty Message, but it's still a Message.


>
>        There are three different types of Sets: Template Set, Options
>        Template Set, and Data Set.
>
>     Template Set
>
>        A Template Set is a collection of one or more Template Records
>        that have been grouped together in an IPFIX Message.
>
>     Options Template Set
>
>        An Options Template Set is a collection of one or more Options
>        Template Records that have been grouped together in an IPFIX
>        Message.
>
>     Data Set
>
>        A Data Set is one or more Data Records, of the same type, that are
>        grouped together in an IPFIX Message.  Each Data Record is
>        previously defined by a Template Record or an Options Template
>        Record.
>
>     Information Element
>
>        An Information Element is a protocol and encoding-independent
>        description of an attribute that may appear in an IPFIX Record.
>        The IPFIX information model [RFC5102bis] defines the base set of
>        Information Elements for IPFIX.  The type associated with an

Not any more.


>        Information Element indicates constraints on what it may contain
>        and also determines the valid encoding mechanisms for use in
>        IPFIX.
>
>     Transport Session
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 10]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>        In Stream Control Transmission Protocol (SCTP), the transport
>        session is known as the SCTP association, which is uniquely
>        identified by the SCTP endpoints [RFC4960]; in TCP, the transport
>        session is known as the TCP connection, which is uniquely
>        identified by the combination of IP addresses and TCP ports used.
>        In UDP, the transport session is known as the UDP session, which
>        is uniquely identified by the combination of IP addresses and UDP
>        ports used.
>
> 2.1.  Terminology Summary Table
>
>     +------------------+---------------------------------------------+
>     |                  |                 contents                    |
>     |                  +--------------------+------------------------+
>     |       Set        |      Template      |record          |

Why isn't "record" capitalised?


>     +------------------+--------------------+------------------------+
>     |     Data Set     |          /         |     Data Record(s)     |
>     +------------------+--------------------+------------------------+
>     |   Template Set   | Template Record(s) |           /            |
>     +------------------+--------------------+------------------------+
>     | Options Template | Options Template   |           /            |
>     |       Set        | Record(s)          |                        |
>     +------------------+--------------------+------------------------+
>
>     Figure A: Terminology Summary Table

Figure A is unreferenced, ie there's no text saying "Figure A summarises 
IPFIX terminology".


>
>     A Data Set is composed of Data Record(s).  No Template Record is
>     included.  A Template Record or an Options Template Record defines
>     the Data Record.
>
>     A Template Set contains only Template Record(s).
>
>     An Options Template Set contains only Options Template Record(s).
>
> 3.  IPFIX Message Format
>
>     An IPFIX Message consists of a Message Header, followed by one or
>     more Sets.  The Sets can be any of the possible three types: Data
>     Set, Template Set, or Options Template Set.
>
>     The format of the IPFIX Message is shown in Figure B.
>
>     +----------------------------------------------------+
>     | Message Header                                     |
>     +----------------------------------------------------+
>     | Set                                                |
>     +----------------------------------------------------+
>     | Set                                                |
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 11]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     +----------------------------------------------------+
>       ...
>     +----------------------------------------------------+
>     | Set                                                |
>     +----------------------------------------------------+
>
>     Figure B: IPFIX Message Format
>
>     The Exporter MUST encode all integers in the Message Header and the
>     Set Headers in network byte order (also known as big-endian byte
>     order).
>
>     Following are some examples of IPFIX Messages:
>
>     1. An IPFIX Message consisting of interleaved Template, Data, and
>        Options Template Sets --A newly created Template is exported as
>        soon as possible.  So, if there is already an IPFIX Message with a
>        Data Set that is being prepared for export, the Template and
>        Options Template Sets are interleaved with this information,
>        subject to availability of space.

These are implementation details.

If "A newly created Template is exported as soon as possible" then the 
Message would have been exported before the following Data and Options 
sets could be added.


>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 12]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     +--------+--------------------------------------------------------+
>     |        | +----------+ +---------+     +-----------+ +---------+ |
>     |Message | | Template | | Data    |     | Options   | | Data    | |
>     | Header | | Set      | | Set     | ... | Template  | | Set     | |
>     |        | |          | |         |     | Set       | |         | |
>     |        | +----------+ +---------+     +-----------+ +---------+ |
>     +--------+--------------------------------------------------------+
>
>     Figure C: IPFIX Message, Example 1

Figure C is unreferenced. If it's not required, then remove it. If it's 
required, then add some text to say why it's here.


>
>     2. An IPFIX Message consisting entirely of Data Sets -- After the
>        appropriate Template Records have been defined and transmitted to
>        the Collecting Process, the majority of IPFIX Messages consist
>        solely of Data Sets.
>
>     +--------+----------------------------------------------+
>     |        | +---------+     +---------+      +---------+ |
>     |Message | | Data    |     | Data    |      | Data    | |
>     | Header | | Set     | ... | Set     | ...  | Set     | |
>     |        | +---------+     +---------+      +---------+ |
>     +--------+----------------------------------------------+
>
>     Figure D: IPFIX Message, Example 2

Figure D is unreferenced.


>
>     3. An IPFIX Message consisting entirely of Template and Options
>        Template Sets.

Is there nothing to be said about this, unlike (1) and (2) ?


>
>     +--------+-------------------------------------------------+
>     |        | +----------+     +----------+      +----------+ |
>     |Message | | Template |     | Template |      | Options  | |
>     | Header | | Set      | ... | Set      | ...  | Template | |
>     |        | |          |     |          |      | Set      | |
>     |        | +----------+     +----------+      +----------+ |
>     +--------+-------------------------------------------------+
>
>     Figure E: IPFIX Message, Example 3

Figure E is unreferenced. Why is it here? What does it show?


>
>
>
>
>
>
>
>
>
>
>
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 13]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
> 3.1.  Message Header Format
>
>     The format of the IPFIX Message Header is shown in Figure F.
>
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |       Version Number          |            Length             |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                           Export Time                         |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                       Sequence Number                         |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                    Observation Domain ID                      |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     Figure F: IPFIX Message Header Format
>
>     Message Header Field Descriptions:
>
>     Version
>
>        Version ofFlow Record format  exported in this message.  The value

Consider "IPFIX" instead of "Flow Record format", because if the Header, 
Template IDs, or Set IDs are changed, the version would have to change 
although the FR format may be unchanged.


>        of this field is 0x000a for the current version, incrementing by
>        one the version used in the NetFlow services export version 9
>        [RFC3954].
>
>     Length
>
>        Total length of the IPFIX Message, measured in octets, including
>        Message Header and Set(s).
>
>     Export Time
>
>        Time at which the IPFIX Message Header leaves the Exporter,
>        expressed in seconds since the UNIX epoch of 1 January 1970 at
>        00:00 UTC, encoded as an unsigned 32-bit integer.
>
>     Sequence Number
>
>        Incremental sequence counter modulo 2^32 of all IPFIX Data Records
>        sent in a the current stream from the current Observation Domain
>        by the Exporting Process. Each SCTP Stream counts sequence numbers
>        separately, while all messages in a TCP connection or UDP
>        transport session are considered to be part of the same stream.
>        This value SHOULD be used by the Collecting Process to identify
>        whether any IPFIX Data Records have been missed. Template and
>        Options Template Records do not increase the Sequence Number.
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 14]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>

The "Observation Domain ID" title is missing here.


>        A 32-bit identifier of the Observation Domain that is locally
>        unique to the Exporting Process.  The Exporting Process uses the
>        Observation Domain ID to uniquely identify to the Collecting
>        Process the Observation Domain that metered the Flows.  It is
>        RECOMMENDED that this identifier also be unique per IPFIX Device.
>        Collecting Processes SHOULD use the Transport Session and the
>        Observation Domain ID field to separate different export streams
>        originating from the same Exporter.  The Observation Domain ID
>        SHOULD be 0 when no specific Observation Domain ID is relevant for
>        the entire IPFIX Message, for example, when exporting the
>        Exporting Process Statistics, or in case of a hierarchy of
>        Collectors when aggregated Data Records are exported.
>
> 3.2.  Field Specifier Format
>
>     Vendors need the ability to define proprietary Information Elements,
>     because, for example, they are delivering a pre-standards product, or
>     the Information Element is, in some way, commercially sensitive.
>     This section describes the Field Specifier format for both
>     IETF-specified Information Elements [RFC5102bis] and enterprise-
>     specific Information Elements.

NB this text is inconsistent with the texts under Figure K, and above 
Figure O.


>
>     The Information Elements are identified by the Information Element
>     identifier.  When the Enterprise bit is set to 0, the corresponding
>     Information Element identifierwill report  an IETF-specified

Why future tense? "reports" would be fine.


>     Information Element, and the Enterprise Number MUST NOT be present.
>     When the Enterprise bit is set to 1, the corresponding Information
>     Element identifierwill report  an enterprise-specific Information

As above.


>     Element; the Enterprise Number MUST be present.  An example of this
>     is shown in Section A.4.2.

A.2.2 is the first (and more obvious) example.


>
>     The Field Specifier format is shown in Figure G.
>
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |E|  Information Element ident. |        Field Length           |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                      Enterprise Number                        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     Figure G: Field Specifier Format
>
>
>
>
>
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 15]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     Where:
>
>     E
>
>        Enterprise bit.  This is the first bit of the Field  Specifier.

"Field  Specifier" is double-spaced.


>        If this bit is zero, the Information Element  Identifier

"Element  Identifier" is double-spaced.


>        identifies an IETF-specified Information Element,  and the four-

"Element,  and" is double-spaced.


>        octet Enterprise Number field MUST NOT be present.  If this bit is
>        one, the Information Element identifier identifies an enterprise-
>        specific Information  Element, and the Enterprise Numberfiled

"Information  Element" is double-spaced.

s/filed/field/


>        MUST be present.
>
>     Information Element identifier
>
>        A numeric value that represents the type of Information Element.
>        Refer to [RFC5102bis].

Not any more.


>   
>
>     Field Length
>
>        The length of the corresponding encoded Information Element,  in

"Element,  in" is double-spaced.


>        octets.Refer to [RFC5102bis].  The field length may be smaller
>        than the definition in [RFC5102bis]  ifthe  reduced size encoding

Which definition is that?

Remove "the".


>        is used (see Section 6.2).  The value 65535 is reserved for
>        variable-length Information Elements (see Section 7).
>
>     Enterprise Number
>
>        IANA enterprise number [PEN] of the authority defining the
>        Information Element identifier in this Template Record.
>
> 3.3.  Set and Set Header Format
>
>     A Set is a generic term for a collection of records that have a
>     similar structure.  There are three different types of Sets: Template
>     Sets, Options Template Sets, and Data Sets.  Each of these Sets
>     consists of a Set Header and one or more records.  The Set Format and
>     the Set Header Format are defined in the following sections.
>
> 3.3.1.  Set Format
>
>     A Set has the format shown in Figure H.  The record types can be
>     either Template Records, Options Template Records, or Data Records.
>     The record types MUST NOT be mixed within a Set.
>
>
>
>
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 16]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     +--------------------------------------------------+
>     | Set Header                                       |
>     +--------------------------------------------------+
>     | record                                           |
>     +--------------------------------------------------+
>     | record                                           |
>     +--------------------------------------------------+
>      ...
>     +--------------------------------------------------+
>     | record                                           |
>     +--------------------------------------------------+
>     | Padding (opt.)                                   |
>     +--------------------------------------------------+
>
>     Figure H: Set Format
>
>     The Set Field Definitions are as follows:
>
>     Set Header
>
>        The Set Header Format is defined in Section 3.3.2.
>
>     Record
>
>        One of the record Formats: Template Record, Options Template
>        Record, or Data Record Format.
>
>     Padding
>
>        The Exporting Process MAY insert some padding octets, so that the
>        subsequent Set starts at an aligned boundary.  For security
>        reasons, the padding octet(s) MUST be composed of zero (0) valued
>        octets.  The padding length MUST be shorter than any allowable
>        record in this Set.  If padding of the IPFIX Message is desired in
>        combination with very short records, then the padding Information
>        Element'paddingOctets' [RFC5102bis]  can be used for padding

5102bis isn't a reference for PO.


>        records such that their length is increased to a multiple of 4 or
>        8 octets.  Because Template Sets are always 4-octet aligned by
>        definition, padding is only needed in case of other alignments
>        e.g., on 8-octet boundaries.
>
> 3.3.2.  Set Header Format
>
>     Every Set contains a common header.  This header is defined in Figure
>     I.

Make a non-breaking space in "Figure I".


>
>
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 17]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |          Set ID               |          Length               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     Figure I: Set Header Format
>
>     The Set Header Field Definitions are as follows:
>
>     Set ID
>
>        Set ID value identifies the Set.  A value of 2 is reserved for the
>        Template Set.  A value of 3 is reserved for the Options Template
>        Set.  All other values from 4 to 255 are reserved for future use.
>        Values above 255 are used for Data Sets.  The  Set ID values of 0

"The  Set" is double-spaced.


>        and 1 are not used for historical reasons  [RFC3954].

"reasons  [RFC3954]" is double-spaced.

Add a comma to avoid mis-parsing: "The Set ID values of 0 and 1 are not 
used, for historical reasons" or re-order: "For historical reasons, Set 
ID values of 0 and 1 are not used". As it is, the existing text says 
they're not used for historical reasons, but any other reason is fine.


>
>     Length
>
>        Total length of the Set, in octets, including the Set Header, all
>        records, and the optional padding.  Because an individual Set MAY
>        contain multiple records, the Length value MUST be used to
>        determine the position of the next Set.
>
> 3.4.   Record Format
>
>     IPFIX defines three record formats, defined in the next sections: the
>     Template Record Format, the Options Template Record Format, and the
>     Data Record Format.
>
> 3.4.1.  Template Record Format
>
>     One of the essential elements in the IPFIX record format is the
>     Template Record.  Templates greatly enhance the flexibility of the
>     record format because they allow the Collecting Process to process
>     IPFIX Messages without necessarily knowing the interpretation of all
>     Data Records.  A Template Record contains any combination of
>     IANA-assigned and/or enterprise-specific InformationElements

s/Elements/Element/ (singular)


>     identifiers.
>
>     The format of the Template Record is shown in Figure J.  It consists
>     of a Template Record Header and one or more Field Specifiers.  The
>     definition of the Field Specifiers is given in Figure G above.
>
>
>
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 18]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     +--------------------------------------------------+
>     | Template Record Header                           |
>     +--------------------------------------------------+
>     | Field Specifier                                  |
>     +--------------------------------------------------+
>     | Field Specifier                                  |
>     +--------------------------------------------------+
>      ...
>     +--------------------------------------------------+
>     | Field Specifier                                  |
>     +--------------------------------------------------+
>
>     Figure J: Template Record Format
>
>     The format of the Template Record Header is shown in Figure K.
>
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |      Template ID (> 255)      |         Field Count           |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     Figure K: Template Record Header Format
>
>     The Template Record Header Field Definitions are as follows:
>
>     Template ID
>
>        Each of the newly generated Template Records is given a unique
>        Template ID.  This uniqueness is local to the Transport Session
>        and Observation Domain that generated the Template ID.  Template
>        IDs 0-255 are reserved for Template Sets, Options Template Sets,
>        and other reserved Sets yet to be created.  Template IDs of Data
>        Sets are numbered from 256 to 65535.  There are no constraints
>        regarding the order of the Template ID allocation.

See note in section 4 about Template IDs.


>
>     Field Count
>
>        Number of fields in this Template Record.
>
>     The example in Figure L shows a Template Setwith mixed standard and
>     enterprise-specific Information Elements.  It consists of a Set
>     Header, a Template Header, and several Field Specifiers.

NB this text is inconsistent with the similar texts in section 3.2, and 
above Figure O.


>
>
>
>
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 19]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |          Set ID = 2           |          Length               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |      Template ID = 256        |         Field Count = N       |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |1| Information Element id. 1.1 |        Field Length 1.1       |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                    Enterprise Number  1.1                     |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |0| Information Element id. 1.2 |        Field Length 1.2       |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |             ...               |              ...              |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |1| Information Element id. 1.N |        Field Length 1.N       |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                    Enterprise Number  1.N                     |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |      Template ID = 257        |         Field Count = M       |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |0| Information Element id. 2.1 |        Field Length 2.1       |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |1| Information Element id. 2.2 |        Field Length 2.2       |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                    Enterprise Number  2.2                     |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |             ...               |              ...              |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |1| Information Element id. 2.M |        Field Length 2.M       |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                    Enterprise Number  2.M                     |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                          Padding (opt)                        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

"Enterprise Number  x.y" is double-spaced in each case.


>
>     Figure L: Template Set Example
>
>     Information Element Identifiers 1.2 and 2.1 are defined by the IETF
>     (Enterprise bit = 0) and, therefore, do not need an Enterprise Number
>     to identify them.
>
> 3.4.2.  Options Template Record Format
>
>     Thanks to the notion of scope,The  Options Template Record gives the

s/The/the".


>     Exporter the ability to provide additional information to the
>     Collector that would not be possible with Flow Records alone.
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 20]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     One Options Template Record example is the "Flow Keys", which reports
>     the Flow Keys for a Template, which is defined as the scope.  Another
>     example is the"Template configuration", which reports the
>     configuration sampling parameter(s) for the Template, which is
>     defined as the scope.

Possibly the "sampling configuration" reports the configured sampling 
params ?

s/configuration/configured/

"Flow Keys" is in 4.4, but "Template configuration" (or in fact, 
anything to do with sampling) isn't.


>
> 3.4.2.1.  Scope
>
>     The scope, which is only available in the Options Template Set, gives
>     the context of the reported Information Elements in the Data Records.
>      Note that the IPFIX Message Header already contains the Observation

NB wrong indentation.


>     Domain ID (the identifier of the Observation Domain).  If not zero,
>     this Observation Domain ID can be considered as an implicit scope for
>     the Data Records in the IPFIX Message.  The Observation Domain ID
>     MUST be zero when the IPFIX Message contains Data Records with
>     different Observation Domain ID values defined as scopes.

Not necessarily. I can't think of a great example, but it allows OD#n to 
report on other ODs in a way that's not possible if n must be in the DR 
with all the other ODs.


>   
>
>     Multiple Scope Fields MAY be present in the Options Template Record,
>     in which case, the composite scope is the combination of the scopes.
>     For example, if the two scopes are defined as "metering process" and
>     "template", the combined scope is this Template for this Metering

Why are these terms lowercase? Should they be IE names?


>     Process.  The order of the Scope Fields, as defined in the Options
>     Template Record, is irrelevant in this case.  However, if the order
>     of the Scope Fields in the Options Template Record is relevant, the
>     order of the Scope Fields MUST be used.  For example, if the first
>     scope defines the filtering function, while the second scope defines
>     the sampling function, the order of the scope is important.  Applying
>     the sampling function first, followed by the filtering function,
>     would lead to potentially different Data Records than applying the
>     filtering function first, followed by the sampling function.  In this
>     case, the Collector deduces the function order by looking at the
>     order of the scope in the Options Template Record.

So how does the EP / CP / whoever determine that the order is important?
Why not do away with the ambiguity and simply say that the scope order 
is always to be regarded?


>
>     The scope is an Information Element specified in the IPFIX
>     Information Model[RFC5102bis].  An IPFIX-compliant implementation of
>     the Collecting Process SHOULD support this minimum set of Information
>     Elements as scope: LineCardId, TemplateId, exporterIPv4Address,
>     exporterIPv6Address, and ingressInterface.  Note that other
>     Information Elements, such as meteringProcessId, exportingProcessId,
>     observationDomainId, etc. are also valid scopes.  The IPFIX protocol
>     doesn't prevent the use of any Information Elements for scope.
>     However, some Information Element types don't make sense if specified
>     as scope; for example, the counter Information Elements.
>
>     Finally, note that the Scope Field Count MUST NOT be zero.
>
>
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 21]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
> 3.4.2.2.  Options Template Record Format
>
>     An Options Template Record contains any combination of IANA-assigned
>     and/or enterprise-specific InformationElements  identifiers.

s/Elements/Element/ (singular)


>
>     The format of the Options Template Record is shown in Figure M.  It
>     consists of an Options Template Record Header and one or more Field
>     Specifiers.  The definition of the Field Specifiers is given in
>     Figure G above.
>
>     +--------------------------------------------------+
>     | Options Template Record Header                   |
>     +--------------------------------------------------+
>     | Field Specifier                                  |
>     +--------------------------------------------------+
>     | Field Specifier                                  |
>     +--------------------------------------------------+
>      ...
>     +--------------------------------------------------+
>     | Field Specifier                                  |
>     +--------------------------------------------------+
>
>     Figure M: Options Template Record Format
>
>     The format of the Options Template Record Header is shown in Figure
>     N.

Make a non-breaking space in "Figure N".


>
>      0                  1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |         Template ID (> 255)   |         Field Count           |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |      Scope Field Count        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     Figure N: Options Template Record Header Format

Q: can we deprecate regular Templates (per section 3.4.1) - so 
everything is in "options template" format - and allow the SFC to be 
zero for non-scoped (data) Templates?


>
>     The Options Template Record Header Field Definitions are as follows:
>
>     Template ID
>
>     Template ID of this Options Template Record.  This value is greater
>     than 255.
>
>
>
>
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 22]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     Field Count
>
>     Number of all fields in this Options Template Record, including the
>     Scope Fields.
>
>     Scope Field Count
>
>     Number of scope fields in this Options Template Record.  The  Scope

"The  Scope" is double-spaced.


>     Fields are normal Fields except that they are interpreted as scope at
>     the Collector.  The Scope Field Count  MUST NOT be zero.

"Count  MUST" is double-spaced.


>
>     The example in Figure O shows an Options Template Set  with mixed IETF
>     and enterprise-specific Information Elements.  It consists of a Set
>     Header, an Options Template Header, and several Field Specifiers.

NB this text is inconsistent with similar texts in section 3.2, and 
under Figure K.


>
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |          Set ID = 3           |          Length               |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |         Template ID = 258     |         Field Count = N + M   |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |     Scope Field Count = N     |0|  Scope 1 Infor. Element Id. |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |     Scope 1 Field Length      |0|  Scope 2 Infor. Element Id. |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |     Scope 2 Field Length      |             ...               |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |            ...                |1|  Scope N Infor. Element Id. |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |     Scope N Field Length      |   Scope N Enterprise Number ...
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     ...  Scope N Enterprise Number   |1| Option 1 Infor. Element Id. |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |    Option 1 Field Length      |  Option 1 Enterprise Number ...
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     ... Option 1 Enterprise Number   |              ...              |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |             ...               |0| Option M Infor. Element Id. |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |     Option M Field Length     |      Padding (optional)       |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     Figure O: Options Template Set Example
>
>
>
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 23]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
> 3.4.3.  Data Record Format
>
>     The Data Records are sent in Data Sets.  The format of the Data
>     Record is shown in Figure P.  It consists only of one or more Field
>     Values.  The Template ID to which the Field Values belong is encoded
>     in the Set Header field "Set ID", i.e., "Set ID" = "Template ID".
>
>     +--------------------------------------------------+
>     | Field Value                                      |
>     +--------------------------------------------------+
>     | Field Value                                      |
>     +--------------------------------------------------+
>      ...
>     +--------------------------------------------------+
>     | Field Value                                      |
>     +--------------------------------------------------+
>
>     Figure P: Data Record Format
>
>     Note that Field Values do not necessarily have a length of 16 bits.
>     Field Values are encoded according to their data typespecified in
>     [RFC5102bis].

Not any more.


>
>     Interpretation of the Data Record format can be done only if the
>     Template Record corresponding to the Template ID is available at the
>     Collecting Process.
>
>     The example in Figure Q shows a Data Set. It consists of a Set Header
>     and several Field Values.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 24]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |   Set ID = Template ID        |          Length               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |   Record 1 - Field Value 1    |   Record 1 - Field Value 2    |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |   Record 1 - Field Value 3    |             ...               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |   Record 2 - Field Value 1    |   Record 2 - Field Value 2    |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |   Record 2 - Field Value 3    |             ...               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |   Record 3 - Field Value 1    |   Record 3 - Field Value 2    |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |   Record 3 - Field Value 3    |             ...               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |              ...              |      Padding (optional)       |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     Figure Q: Data Set, Containing Data Records

s/Containing/containing/ (lowercase).


>
> 4.  Specific Reporting Requirements
>
>     Some specific Options Templates and Options Template Records are
>     necessary to provide extra information about the Flow Records and
>     about the Metering Process.
>
>     The Options Template and Options Template Records defined in these
>     subsections, which impose some constraints on the Metering Process
>     and Exporting Process implementations, MAY be implemented.  If
>     implemented, the specific Options Templates SHOULD be implemented as
>     specified in these subsections.
>
>     The minimum set of Information Elements is always specified in these
>     Specific IPFIX Options Templates.  Nevertheless, extra Information
>     Elements may be used in these specific Options Templates.
>
>     The Collecting Process MUST check the possible combinations of
>     Information Elements within the Options Template Records to correctly
>     interpret the following Options Templates.

This is true of all Templates. ie, a CP MUST not assume that Template ID 
N has any particular meaning.
I have been asked about static allocations, so I'd like to see this 
explicitly stated, eg in section 3.4.1.


>
> 4.1.  The Metering Process Statistics Options Template
>
>     The Metering Process Statistics Options Template specifies the
>     structure of a Data Record for reporting Metering Process statistics.
>      It SHOULD contain the following Information Elements that are

NB wrong indent.


>     defined in [RFC5102bis]:

Not any more.


>   
>
>
> <Claise, et al.>            Standards Track                    [Page 25]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     (scope) observationDomainId
>                             An identifier of an Observation Domain that
>                             is locally unique to the Exporting Process.
>                             This Information Element MUST be defined as a
>                             Scope Field.
>
>     (scope) meteringProcessId
>                             An identifier of the Metering Process for
>                             which statistics are reported. This
>                             Information Element MUST be defined as a
>                             Scope Field.
>
>     exportedMessageTotalCount
>                             The total number of IPFIX Messages that the
>                             Exporting Processsuccessfully  sent to the
>                             Collecting Process since the Exporting
>                             Process re-initialization.
>
>     exportedFlowRecordTotalCount
>                             The total number of Flow Records that the
>                             Exporting Processsuccessfully  sent to the
>                             Collecting Process since the Exporting
>                             Process re-initialization.
>
>     exportedOctetTotalCount
>                             The total number of octets that the Exporting
>                             Processsuccessfully  sent to the Collecting
>                             Process since the Exporting Process re-
>                             initialization.

How does the EP know these Messages / Records / Octets were successfully 
sent?
eg, they may be handed off to a transport layer which doesn't report 
back on send status.


>
>     The Exporting Process SHOULD export the Data Record specified by the
>     Metering Process Statistics Options Template on a regular basis or
>     based on some export policy.  This periodicity or export policy
>     SHOULD be configurable.
>
>     Note that if several Metering Processes are available on the Exporter
>     Observation Domain, the Information ElementmeteringProcessId  MUST be
>     specified as an additional Scope Field.

How does the collector determine the meaning of the meteringProcessId ?


>
> 4.2.  The Metering Process Reliability Statistics Options Template
>
>     The Metering Process Reliability Options Template specifies the
>     structure of a Data Record for reporting lack of reliability in the
>     Metering Process.  It SHOULD contain the following Information
>     Elementsthat are defined in [RFC5102bis]:  

Not any more.


>
>
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 26]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     (scope) observationDomainId
>                             An identifier of an Observation Domain that
>                             is locally unique to the Exporting Process.
>                             This Information Element MUST be defined as a
>                             Scope Field.
>
>     (scope) meteringProcessId
>                             The identifier of the Metering Process for
>                             whichlack of  reliability is reported. This

Why "lack of"? This isn't the "Metering Process Unreliability Statistics"!


>                             Information Element MUST be defined as a
>                             Scope Field.
>
>     ignoredPacketTotalCount
>                             The total number of IP packets that the
>                             Metering Process did not process.
>
>     ignoredOctetTotalCount
>                             The total number of octets in observed
>                             packets that the Metering Process did not
>                             process.
>
>     time first packet ignored
>                             The timestamp of the first packet that was
>                             ignored by the Metering  Process.  For this

"Metering  Process" is double-spaced.


>                             timestamp, any of the followingtimestamp  can

"timestamps" plural.


>                             be used: observationTimeSeconds,
>                             observationTimeMilliseconds,
>                             observationTimeMicroseconds, or
>                             observationTimeNanoseconds.
>
>     time last packet ignored
>                             The timestamp of the last packet that was
>                             ignored by the Metering  Process.  For this

"Metering  Process" is double-spaced.


>                             timestamp, any of the followingtimestamp  can

"timestamps" plural.


>                             be used: observationTimeSeconds,
>                             observationTimeMilliseconds,
>                             observationTimeMicroseconds, or
>                             observationTimeNanoseconds.
>
>     The Exporting Process SHOULD export the Data Record specified by the
>     Metering Process Reliability Statistics Options Template on a regular
>     basis or based on some export policy.  This periodicity or export
>     policy SHOULD be configurable.
>
>     Note that if several Metering Processes are available on the Exporter
>     Observation Domain, the Information Element meteringProcessId MUST be
>     specified as an additional Scope Field.
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 27]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     Since the Metering Process Reliability Option Template will logically
>     contain two identical timestamp Information Elements,and since the
>     order of the Information Elements in the Template Records is not
>     guaranteed, the Collecting Process MUST determine which is the oldest

It's defined as { first, last }, ie the semantic is derived from the 
position which is defined in the RFC. See section 8.


>     and the most recent timestamp in order the determine the right
>     semantic behind the time first packet ignored and time last packet
>     ignored Information Elements.Note that the counters wrap-around for
>     the timestamps SHOULD also be taken into account.

You're making this hard for no reason. First, Last, in order, "MUST" -> 
it's easy.


>
> 4.3.  The Exporting Process Reliability Statistics Options Template
>
>     The Exporting Process Reliability Options Template specifies the
>     structure of a Data Record for reporting lack of reliability in the
>     Exporting process.  It SHOULD contain the following Information
>     Elements that are defined in[RFC5102bis]:
>
>     (scope) Exporting Process ID
>                          The identifier of the Exporting Process for
>                          which lack of reliability is reported.  There
>                          are three Information Elements specified in
>                          [RFC5102bis]  that can be used for this purpose:
>                          exporterIPv4Address, exporterIPv6Address, or
>                          exportingProcessId.  This Information Element
>                          MUST be defined as a Scope Field.

How does the collector understand "exportingProcessId" ?


>
>     notSentFlowTotalCount
>                          The total number of Flows that were generated by
>                          the Metering Process and dropped by the Metering
>                          Process or by the Exporting Process instead of
>                          being sent to the Collecting Process.
>
>     notSentPacketTotalCount
>                          The total number of packets in Flow Records that
>                          were generated by the Metering Process and
>                          dropped by the Metering Process or by the
>                          Exporting Process instead of being sent to the
>                          Collecting Process.
>
>     notSentOctetTotalCount
>                          The total number of octets in packets in Flow
>                          Records that were generated by the Metering
>                          Process and dropped by the Metering Process or
>                          by the Exporting Process instead of being sent
>                          to the Collecting Process.
>
>
>
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 28]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     time first flow dropped
>                          The time at which the first Flow Record was
>                          dropped by the Exporting Process.  For this
>                          timestamp, any of the following timestamp can be
>                          used: observationTimeSeconds,
>                          observationTimeMilliseconds,
>                          observationTimeMicroseconds, or
>                          observationTimeNanoseconds.
>
>     time last flow dropped
>                          The time at which the last Flow Record was
>                          dropped by the Exporting Process.  For this
>                          timestamp, any of the following timestamp can be
>                          used: observationTimeSeconds,
>                          observationTimeMilliseconds,
>                          observationTimeMicroseconds, or
>                          observationTimeNanoseconds.
>
>     The Exporting Process SHOULD export the Data Record specified by the
>     Exporting Process Reliability Statistics Options Template on a
>     regular basis or based on some export policy.  This periodicity or
>     export policy SHOULD be configurable.
>
>     Since the Exporting Process Reliability Option Template will
>     logically contain two identical timestamp Information Elements, and
>     since the order of the Information Elements in the Template Records
>     is not guaranteed, the Collecting Process MUST determine which is the
>     oldest and the most recent timestamp in order the determine the right
>     semantic behind the time first packet ignored and time last packet
>     ignored Information Elements.Note that the counters wrap-around for
>     the timestamps SHOULD also be taken into account.

See comments in 4.2 and section 8.


>
> 4.4.  The Flow Keys Options Template
>
>     The Flow Keys Options Template specifies the structure of a Data
>     Record for reporting the Flow Keys of reported Flows.  A Flow Keys
>     Data Record extends a particular Template Record that is referenced
>     by its templateId identifier.  The Template Record is extended by
>     specifying which of the Information Elements contained in the
>     corresponding Data Records describe Flow properties that serve as
>     Flow Keys of the reported Flow.
>
>     The Flow Keys Options Template SHOULD contain the following
>     Information Elements that are defined in [RFC5102bis]:  

Not any more they're not.


>
>
>
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 29]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     (scope) templateId      An identifier of a Template.  This
>                             Information Element MUST be defined as a
>                             Scope Field.
>
>     flowKeyIndicator        Bitmap with the positions of the Flow Keys in
>                             the Data Records.
>
> 5.  IPFIX Message Header Export Time and Flow Record Time
>
>     The IPFIX Message Header Export Time field is the time at which the
>     IPFIX Message Header leaves the Exporter, expressed in seconds since
>     the UNIX epoch, 1 January 1970 at 00:00 UTC, encoded in an unsigned
>     32-bit integer.
>
>     Certain time-related Information Elements may be expressed as an
>     offset from this Export Time. For example, Data Records requiring a
>     microsecond precision can export the flow start and end times with
>     the flowStartMicroseconds and flowEndMicroseconds Information
>     Elements  [RFC5102bis], which encode the absolute time in microseconds
>     in terms of the NTP epoch, 1 January 1900 at 00:00 UTC, in a 64-bit
>     field. An alternate solution is to export the
>     flowStartDeltaMicroseconds and flowEndDeltaMicroseconds Information
>     Elements[RFC5102bis]  in the Data Record, which respectively report
>     the flow start and end time as negative offsets from the Export Time,
>     as an unsigned 32-bit integer. This latter solution lowers the export
>     bandwidth requirement, saving two bytes per timestamp, while
>     increasing the load on the Exporter, as the Exporting Process must
>     calculate the flowStartDeltaMicroseconds and flowEndDeltaMicroseconds
>     of every single Data Record before exporting the IPFIX Message.
>
>     It must be noted that timestamps based on the Export Time impose some
>     time constraints on the Data Records contained within the IPFIX
>     Message. In the example of flowStartDeltaMicroseconds and
>     flowEndDeltaMicroseconds Information Elements[RFC5102bis], the Data
>     Record can only contain records with timestamps within 71 minutes of
>     the Export Time. Otherwise, the 32-bit counter would not be
>     sufficient to contain the flow start time offset.
>
>
> 6.  Linkage with the Information Model
>
>     As with values in the IPFIX Message Header and Set Header, values of
>     all Information Elements[RFC5102bis], except for those of the string

This is potentially a _valid_ citation of 5102bis. I won't mention it 
any more.


>     and octetArray data types, are encoded in canonical format in network
>     byte order (also known as big-endian byte ordering).
>
>
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 30]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
> 6.1.  Encoding of IPFIX Data Types
>
>     The following sectionswill  define the encoding of the data types
>     specified in [RFC5102bis].

Will they? Or do they? Just remove "will".


>
> 6.1.1. Integral Data Types
>
>     Integral data types -- octet, signed8, unsigned16, signed16,
>     unsigned32, signed32, signed64, and unsigned64 -- MUST be encoded
>     using the default canonical format in network byte order.  Signed
>     Integral data types are represented in two's complement notation.
>
> 6.1.2. Address Types
>
>     Address types -- macAddress, ipv4Address, and ipv6Address -- MUST be
>     encoded the same way as the integral data types, as six, four, and
>     sixteen octets in network byte order, respectively.
>
> 6.1.3. float32
>
>     The float32 data type MUST be encoded as an IEEE single-precision
>     32-bit floating point-type, as specified in [IEEE.754.1985], in
>     network byte order.
>
> 6.1.4. float64
>
>     The float64 data type MUST be encoded as an IEEE double-precision 64-
>     bit floating point-type, as specified in [IEEE.754.1985], in network
>     byte order.
>
> 6.1.5. boolean
>
>     The boolean data type is specified according to the TruthValue in
>     [RFC2579]. It is encoded as a single-octet integer in network byte
>     order, as in Section 6.1.1., with the value 1 for true and a value 2
>     for false. Every other value is undefined.
>
> 6.1.6. string and octetArray
>
>     The data type string represents a finite length string of valid
>     characters of the Unicode character encoding set. The string data
>     type MUST be encoded inUTF-8 format.

RFC3629 ?


>     The string is sent asan array
>     of octets  using an Information Element of fixed or variable length.

Where "array" also allows for zero and one octet.


>     The data type octetArray has no encoding rules; it represents a raw
>     array of octets, with theintepretation  of the octets defined in the

"interpretation".


>     Information Element definition.
>
> 6.1.7. dateTimeSeconds
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 31]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     The data type dateTimeSeconds is an unsigned 32-bit integer in
>     network byte order containing the number of seconds since the UNIX
>     epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1].
>     dateTimeSeconds is encoded identically to the IPFIX Message Header
>     Export Time field. It can represent dates between 1 January 1970 and
>     8 February 2106.
>
> 6.1.8. dateTimeMilliseconds
>
>     The data type dateTimeMilliseconds is an unsigned 64-bit integer in
>     network byte order, containing the number of milliseconds since the
>     UNIX epoch, 1 January 1970 at 00:00 UTC, as defined in [POSIX.1]. It
>     can represent dates beginning on 1 January 1970 for approximately the
>     next 500 billion years.
>
> 6.1.9  dateTimeMicroseconds
>
>     The data type dateTimeMicroseconds is a 64-bit field encoded
>     according to the NTP Timestamp format as defined in section 6 of
>     [RFC5905]. This field is made up of two unsigned 32-bit integers in
>     network byte order, Seconds and Fraction. The Seconds field is the
>     number of seconds since the NTP epoch, 1 January 1900 at 00:00 UTC.
>     The Fraction field is the fractional number of seconds in units of
>     1/(2^32) seconds (approximately 233 picoseconds). It can represent
>     dates beginning between 1 January 1900 and 8 February 2036.

Since we're already over 80% through that range, it seems worth moving 
the epoch to 1/1/2000.


>
>     Note that dateTimeMicroseconds and dateTimeNanoseconds share an
>     identical encoding. The dataTimeMicroseconds data type is intended
>     only to represent timestamps of microsecond precision.Therefore, the
>     bottom 11 bits of the fraction field MAY contain any value and MUST
>     be ignored for all Information Elements of this data type (as 2^11 x
>     233 picoseconds = .477 microseconds).

Why not say, the bottom 11 bits must be zero?


>
> 6.1.10 dateTimeNanoseconds
>
>     The data type dateTimeNanoseconds is a 64-bit field encoded according
>     to the NTP Timestamp format as defined in section 6 of [RFC5905].
>     This field is made up of two unsigned 32-bit integers in network byte
>     order, Seconds and Fraction. The Seconds field is the number of
>     seconds since the NTP epoch, 1 January 1900 at 00:00 UTC. The
>     Fraction field is the fractional number of seconds in units of
>     1/(2^32) seconds (approximately 233 picoseconds). It can represent
>     dates beginning between 1 January 1900 and 8 February 2036.
>
>     Note that dateTimeMicroseconds and dateTimeNanoseconds share an
>     identical encoding. There is no restriction on the interpretation of
>     the Fraction field for the dateTimeNanoseconds data type.
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 32]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
> 6.2.  Reduced Size Encoding
>
>     Information Elements encoded as signed, unsigned, or float data types
>     MAY be encoded using fewer octets than those implied by their type in
>     the information model definition [RFC5102bis], based on the
>     assumption that the smaller size is sufficient to carry any value the
>     Exporter may need to deliver. This reduces the network bandwidth
>     requirement between the Exporter and the Collector. Note that the
>     Information Element definitions [RFC5102bis] will always define the
>     maximum encoding size.
>
>     For instance, the information model [RFC5102bis] defines
>     octetDeltaCount as an unsigned64 type, which would require 64 bits.
>     However, if the Exporter will never locally encounter the need to
>     send a value larger than 4294967295, it may chose to send the value
>     instead as an unsigned32. For example, a core router would require an
>     unsigned64 byteCount, while an unsigned32 might be sufficient for an
>     access router.
>
>     This behavior is indicated by the Exporter by specifying a size in
>     the Template with a smaller length than that associated with the
>     assigned type of the Information Element. In the example above, the
>     Exporter would place a length of 4 versus 8 in the Template.
>
>     If reduced size encoding MAY be be applied to the following integer
>     types: unsigned64, signed64, unsigned32, signed32, unsigned16, and
>     signed16. The signed versus unsigned property of the reported value
>     MUST be preserved. The reduction in size can be to any number of
>     octets smaller than the original type if the data value still fits,
>     i.e., so that only leading zeroes are dropped. For example, an
>     unsigned64 can be reduced in size to 7, 6, 5, 4, 3, 2, or 1 octet(s).
>
>     Reduced size encoding MAY be used to reduce float64 to float32. The
>     float32 not only has a reduced number range, but due to the smaller
>     mantissa, is also less precise. In this case, the float64 would be
>     reduced in size to 4 octets.
>
>     Reduced size encoding MUST NOT be applied to any other data type
>     defined in [RFC5102bis] that implies a fixed length, as these types

Again, this is a potentially _valid_ 5102bis citation - so a simple 
s/5102bis/IANA/ isn't appropriate.


>     either have internal structure (such as ipv4Address or
>     dateTimeMicroseconds) or restricted ranges that are not suitable for
>     reduced length encoding (such as dateTimeMilliseconds).
>
>     Information Elements of type octetArray and string may be exported
>     using any length, subject to restrictions on length specific to each
>     Information Element, as noted in that Information Element's
>     description.
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 33]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
> 7.  Variable-Length InformationElement  

Shouldn't it be "elements" ?


>
>     The IPFIX Template mechanism is optimized for fixed-length
>     Information Elements [RFC5102bis].  Where an Information Element has
>     a variable length, the following mechanism MUST be used to carry the
>     length information for both the IETF and proprietary Information
>     Elements.
>
>     In the Template Set, the Information Element Field Length is recorded
>     as 65535.  This reserved length value notifies the Collecting Process
>     that length of the Information Element will be carried in the
>     Information Element content itself.
>
>     In most cases, the length of the Information Element will be less
>     than 255 octets.  The following length-encoding mechanism optimizes
>     the overhead of carrying the Information Element length in this
>     majority case.  The length is carried in the octet before the
>     Information Element, as shown in Figure R.
>
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     | Length (< 255)|          Information Element                  |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                      ... continuing as needed                 |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     Figure R: Variable-Length Information Element (length < 255 octets)
>
>     The length may also be encoded into 3 octets before the Information
>     element allowing the length of the Information Element to be greater
>     than or equal to 255 octets. In this case, first octet of the Length
>     field MUST be 255, and the length is carried in the second and third
>     octets, as shown in Figure S.
>
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |      255      |      Length (0 to 65535)      |       IE      |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                      ... continuing as needed                 |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     Figure S: Variable-Length Information Element (length 0 to 65535
>     octets)
>
>     The octets carrying the length (either the first or the first three
>     octets) MUST NOT be included in the length of the Information
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 34]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     Element.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 35]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
> 8.  Template Management
>
>     This section describes the management of Templates and Options
>     Templates at the Exporting and Collecting Processes. The goal of
>     Template management is to ensure,to the extent possible, that the

What does that mean / add?


>     Exporting Process and Collecting Process have a consistent view of
>     the Templates and Options Templates used to encode and decode the
>     Records sent from the Exporting Process to the Collecting Process.
>     Achieving this goal is complicated somewhat by two factors: 1. the
>     need to support the reuse of Template IDs within a Transport Session
>     and 2. the need to support unreliable transmission for templates when
>     UDP is used as the transport protocol for IPFIX Messages.
>
>     The Template Management mechanisms defined in this section apply to
>     IPFIX Message export on any supported Transport Protocol. Additional
>     considerations specific to SCTP and UDP transport are given in
>     sections 8.3 and 8.4, respectively.
>
>     The Exporting Process assigns and maintains the Template IDs per
>     Transport Session for the Exporter's Observation Domains. A newly

Arguably Exporters do not observe, therefore ODs don't belong to Exporters.


>     created Template Record is assigned an unused Template ID by the
>     Exporting Process. The Collecting Process MUST store all received
>     Template Record information for the duration of each Transport
>     Session until reuse or withdrawal as in section 8.1, except as noted
>     in section 8.4, so that it can interpret the corresponding Data
>     Records that are received in subsequent Data Sets. The Collecting
>     Process MUST NOT assume that the Template IDs from a given Exporting
>     Process refer to the same Templates as they did in previous Transport
>     Sessions from the same Exporting Process.When a Transport Session is
>     closed, the Collecting Process MUST discard all Templates received
>     over that association and stop decoding IPFIX Messages that use those
>     Templates.

Only if it's doing real-time decode. If it's storing Templates and 
Records in a database (file) then you absolutely do not want it to 
discard all the received Templates.


>
>     If a specific Information Element is required by a Template, but is
>     not present in observed packets, the Exporting ProcessMAY  choose to
>     export Flow Records without this Information Element in a Data Record
>     defined by a new Template.

MAY... else, what are its choices?


>
>     If an Information Element is required more than once in a Template,
>     the different occurrences of this Information Element SHOULD follow
>     the logical order of their treatments by the Metering Process. For
>     example, if a selected packet goes through two hash functions, and if
>     the two hash values are sent within a single Template, the first
>     occurrence of the hash value should belong to the first hash function
>     in the Metering Process. For example, when exporting the two source
>     IP addresses of an IPv4 in IPv4 packets, the first sourceIPv4Address
>     Information Element occurrence should be the IPv4 address of the
>     outer header, while the second occurrence should be the address of
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 36]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     the inner header. Collecting processes MUST properly handle Templates
>     with multiple identical Information Elements.

NB this section applies to { first, last } in sections 4.2 and 4.3.


>
>     The Exporting Process SHOULD transmit the Template Set and Options
>     Template Set in advance of any Data Sets that use that (Options)
>     Template ID, to help ensure that the Collector has the Template
>     Record before receiving the first Data Record. Data Records that
>     correspond to a Template Record MAY appear in the same and/or
>     subsequent IPFIX Message(s).
>
>     This ensures that the Collecting Process normally receives Template
>     Records from the Exporting Process before receiving Data Records.
>     However, if the Template Records have not been received at the time
>     Data Records are received,the Collecting Process MAY store the Data
>     Records for a short period of time and decode them after the Template
>     Records are received. In any case, a Collecting Process MUST NOT
>     assume that the Data Set and the associated Template Set (or Options
>     Template Set) are exported in the same IPFIX Message.

Store-and-wait only works for reliable and in-order transports. With an 
unreliable or out-of-order transport, an intervening TWM could have been 
lost (or still be pending), so the subsequently received Template 
doesn't apply to the previously received Data Records.

So perhaps we should do away with this MAY.

Section 8.2 says that Data Records MUST NOT be sent before Templates - 
although that has no bearing on their arrival time.


>
>     Different Observation Domains from the same Transport Session MAY use
>     the same Template ID value to refer to different Templates;
>     Collecting Processes MUST properly handle this case.
>
>     Options Templates and Templates which are related or interdependent
>     (e.g. by sharing common properties as in [RFC5473]) SHOULD be sent
>     together in the same IPFIX Message.
>
> 8.1. Template Withdrawal and Redefinition
>
>     Since a Template may have a lifetime at the Exporting Process
>     independent of the Transport Session, IPFIX provides a mechanism for
>     the withdrawal of templates and for the reuse of template IDs. This
>     mechanism does not apply when UDP is used to transport IPFIX
>     messages; for this case, see Section 8.4.
>
>     Templates that will not be used further by an Exporting Process MUST
>     be withdrawn by sending a Template Withdrawal Message.After
>     receiving a Template Withdrawal, a Collecting Process MUST discard
>     the Template and stop using it to interpret Data Sets.

It mustn't use the Template to interpret further Data Sets. However, it 
could keep the Template and use it to interpret previously-received Data 
Sets.


>
>     A Template Withdrawal consists of a Template Record for the Template
>     ID to be with a Field Count of 0.  The format of aTemplate Withdrawal
>     is shown in Figure T.

"A Template Withdrawal Message consists of a Template Record for the 
Template ID to be withdrawn, with a Field Count of 0."

"format of a Template Withdrawal Message..."


>
>
>
>
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 37]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |       Set ID = (2 or 3)       |          Length = 16          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |          Template ID N        |        Field Count = 0        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |          Template ID ...      |        Field Count = 0        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |          Template ID M        |        Field Count = 0        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     Figure T: Template Withdrawal Set Format
>
>
>     The Set ID field MUST contain the value 2 forTemplate Set Withdrawal
>     and the value 3 forOptions Template Set Withdrawal. Multiple

We're not withdrawing the (options) Template Set, but rather, the 
specified (options) Template itself.

Inconsistent terminology:
     "Template Withdrawal Set" (used three times, in the titles of 
Figures T, U, and V)
     "Template Set Withdrawal" (used twice here)
     "Template Withdrawal Message" (used seven times in the text).


>     Template IDs MAY be withdrawn with a single Template Withdrawal, in
>     that case, padding MAY be used.

This is a comma-splice; it should be a separate sentence. Anyway, why 
would a TWM be padded?


>
>     A Template Withdrawal Message is an IPFIX Message containing Template
>     Withdrawals. It withdraws Template IDs for the Observation Domain ID
>     specified in the IPFIX Message Header.It MUST NOT contain new
>     Template or Options Template Records, or any Data Sets.  The Exporting

Why not? A Template could be withdrawn, redefined, used in a new Data 
Set, then withdrawn again all within a single Message, without any 
ambiguity.


>     Process SHOULD NOT send a Template Withdrawal Message until
>     sufficient time has elapsed to allow receipt and processing of and
>     Data Records described by the withdrawn Templates; see section 8.2
>     for more information on sequencing Template Withdrawals.
>
>     The end of a Transport Session implicitly withdraws all the Templates
>     used within the Transport Session, and Templates must be resent
>     during subsequent Transport Sessions between an Exporting Process and
>     Collecting Process. All Templates for a given Observation Domain MAY
>     also be withdrawn using an All Templates Withdrawal, which withdraws

"All Templates Withdrawal Message"


>     the special Template ID 2; this is shown in Figure U. All Options

No it doesn't.


>     Templates for a given observation Domain MAY likewise be withdrawn
>     using an All Options Templates Withdrawal,which withdraws the
>     special Template ID 3.  Each of these Withdrawals MUST appear in a

No it doesn't.

Template IDs 2 and 3 have particular meanings in IPFIX, they're part of 
a reserved range (section 3.4.1). Exporters do not send Templates 2 and 
3, so these cannot be withdrawn.

Also, Template IDs 2 and 3 aren't "special", they're "reserved".


>     Template Withdrawal Message with no other Withdrawals.
>
>
>
>
>
>
>
>
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 38]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |             Set ID = 2        |          Length = 8           |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |         Template ID = 2       |        Field Count = 0        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     Figure U: All Templates Withdrawal Set Format
>
>
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |             Set ID = 3        |          Length = 8           |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |         Template ID = 3       |        Field Count = 0        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     Figure V: All Options Templates Withdrawal Set Format

Figure V is unreferenced.


>
>
>     Template IDs MAY be reused for new Templates by sending a new
>     Template Record or Options Template Record for a given Template ID
>     after withdrawing the Template.
>
>     If a Collecting Process receives a new Template Record or Options
>     Template Record for an already-allocated Template ID, without having
>     received awithdrawal, it MUST ignore thenew Template Record  and

This should say, "a TWM for that (options) Template Record".

"it MUST ignore the new (options) Template Record and"


>     discard the old Template Record for the allocated ID; it SHOULD log

"discard the old (options) Template Record"

So this is basically a DoS vector? ie, if I can inject bogus Templates 
towards the collector, then it must discard both the bogus Template and 
the perfectly good Template, and therefore stop collecting data.


>     the error.
>
>     If a Collecting Process receives aTemplate Withdrawal  for a Template

"Template Withdrawal Message"


>     or Options Template it does not presently have stored, it MUST ignore
>     theTemplate Withdrawal  and SHOULD log the error.

"Template Withdrawal Message"


>
> 8.2   Sequencing Template Management Actions
>
>     Since there is no guarantee of the ordering of exported IPFIX
>     Messages across SCTP Streams or over UDP, an Exporting Process MUST
>     sequence all template management actions (i.e., Template Records
>     defining new templates andTemplate Withdrawals  withdrawing them)

"Template Withdrawal Messages"


>     using the Export Time field in the IPFIX Message Header.

So CPs must respect the Export Time rather than the delivery (arrival) 
order? Is there some sort of time flux going on here?


>
>     An Exporting Process MUST NOT export a Data Set described by a new
>     Template in an IPFIX Message with an Export Time before the Export
>     Time of the IPFIX Message containing that Template.  If a new Template

In simpler words, Templates must be sent before Data Sets. Or if they're 
not, then at least the later-sent Templates must have earlier Export 
Times. OK, I see how the time flux works.

Except, this contradicts store-and-wait in Section 8. Unless we're 
talking about the corner-corner case of Template is sent, CP restarts, 
Data is sent.


>     and a Data Set described by it appear in the same IPFIX Message, the
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 39]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     Template Set containing the Template MUST appear before the Data Set
>     in the Message.
>
>     An Exporting Process MUST NOT export any Data Sets described by a
>     withdrawn Template in IPFIX Messages with an Export Time after the
>     Export Time of theIPFIX Message containing the Template Withdrawal

"Export Time of the TWM".


>     withdrawing that Template.

Flux capacitor to the rescue again: you're saying that such Data Sets 
can be sent after the TWM provided their Export Time is earlier.


>
>     Put another way,  a Template only describes Records contained in IPFIX

Because the previous way was too complicated for mortals to comprehend :-(


>     Messages with the same Export Time as the IPFIX Message containing
>     Template Record, or a subsequent export time. Likewise,a Template
>     Withdrawal is only in effect for IPFIX Messages with the same Export
>     Time as the Template Withdrawal, or a subsequent Export Time.

No, a TWM does not withdraw subsequent templates.


>     Collecting Processes MAY implement a buffer to handle out-of-order
>     Template management events.

How exactly do you envisage that working? Put events in the buffer, 
sorted by time, and pop the topmost event after allowing some time delta?


This whole section became too confusing and unclear, so even I can 
barely understand it :-(


>
> 8.3.  Additional considerations for Template Management over SCTP
>
>     Template Sets and Options Template Sets MAY be sent on any SCTP
>     stream. Data Sets sent on a given SCTP stream MAY be represented by
>     Template Records exported on any SCTP stream.

xref RFC6526 (per stream) here.


>
>     Template Sets and Options Template Sets MUST be sent reliably andin
>     order.

Why must they be in order? As long as they arrive before their 
corresponding Data Sets - unless an option is scoped to another option 
or a Template?


>
>     Template Withdrawal Messages MAY be sent on any SCTP stream. Template
>     Withdrawal Messages MUST be sent reliably, usingSCTP-ordered

Why is that hyphenated?


>     delivery. Template IDs MAY be reused by sending a Template Withdrawal
>     Message and/or a new Template Record on a different SCTP stream than
>     the stream on which the original Template was sent.

No. A Template can't be redefined simply by sending a new Template 
definition on another stream. With SCTP, the EP must explicitly withdraw 
the template before redefining it.


>
>     Additional Template Management considerations are given in [IPFIX-
>     PER-SCTP-STREAM], which specifies an extension to explicitly link

RFC6526.


>     Templates with SCTP streams. In exchange for more restrictive rules
>     on the assignment of Template Records to SCTP streams, this extension
>     allows fast, reliable reuse of Template IDs and estimation of Data
>     Record loss per Template.
>
> 8.4.  Additional considerations for Template Management over UDP
>
>     Since UDP provides no method for reliable transmission of Templates,
>     Exporting Processes using UDP as the Transport Protocol MUST
>     periodically retransmit each active Template at regular intervals.
>     The template retransmission interval MUST be configurable, as via the
>     the templateRefreshTimeout and optionsTemplateRefreshTimeout defined
>     in [IPFIX-CONF]. Default settings for these values are deployment-
>     and application-specific.
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 40]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     Before exporting any Data Records described by a given Template
>     Record or Options Template Record, especially in the case of Template
>     ID reuse as in section 8.1, the Exporting Process SHOULD send
>     multiple copies of the Template Record in separate IPFIXMessage, in
>     order to help ensure the Collecting Process has received it.

"Messages" plural.

Or more simply, prefix the Data Set with the corresponding Template.


>
>     In order to minimize resource requirements for templates which have
>     expired at the Exporting Process without being withdrawn, or in cases
>     when the Template Withdrawal Message was lost between the Exporting
>     Process and the Collecting Process, the Collecting Process MAY
>     associate a lifetime with each Template received in a UDP Transport
>     Session. Templates not refreshed by the Exporting Process within the
>     lifetime can then be discarded by the Collecting Process. The
>     template lifetime at the Collecting Process MAY be exposed by a
>     configuration parameter, or MAY be derived from observation of the
>     interval of periodic Template retransmissions from the Exporting
>     Process. In this latter case, the Template lifetime SHOULD default to
>     at least 3 times the observed retransmission rate.

The EP should export an option indicating the template lifetime it's using.


>
>     As template IDs are unique per UDP session and per Observation
>     Domain, at any given time, the Collecting Process SHOULD maintain the
>     following for all the current Template Records and Options Template
>     Records: <IPFIX Device, Exporter source UDP port, Observation Domain
>     ID, Template ID, Template Definition,Last Received>.

"IPFIX Device" == Exporter source address?

"Last Received" - is this the last received template definition, a byte 
count, a boolean, a timestamp, or some combination of these?


>
> 9. The Collecting Process's Side
>
>     This section describes the handling of the IPFIX Protocol at the
>     Collecting Process common to all Transport Protocols. Additional
>     considerations for SCTP and UDP are given in Sections 9.1 and 9.2
>     respectively. Template management at Collecting Processes is covered
>     in Section 8.
>
>     The Collecting Process MUST listen for association requests /
>     connections to start new Transport Sessions from the Exporting
>     Process.
>
>     The Collecting Process MUST note the Information Element identifier
>     of any Information Element that it does not understand and MAY
>     discard that Information Element fromthe Flow Record.

 From Flow Records, plural.


>
>     The Collecting Process MUST accept padding in Data Records and
>     Template Records.  The padding size is the Set Length minus the size
>     of the Set Header (4 octets for the Set ID and the Set Length),
>     modulo the Record size deduced from the Template Record.

Is this shown in any figures?


>
>     The IPFIX protocol has a Sequence Number field in the Export header
>     that increases with the number of IPFIX Data Records in the IPFIX
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 41]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     Message. The Collecting Process MAY detect out-of-sequence, dropped,
>     or duplicate IPFIX Messages using this the Sequence Number. If it
>     supports this mechanism, the Collecting Process SHOULD log
>     out-of-sequence IPFIX Messages, as these could indicate resource
>     exhaustion at the Exporting Process or the Collecting Process, an
>     Exporting Process reset, packet loss due to congestion between the
>     Exporting Process and the Collecting Process, or message injection.
>
>     If the Collecting Process receives a malformed IPFIX Message, it MUST
>     discard the IPFIX Message and SHOULD log the error. Note that non-
>     zero Set padding does not constitute a malformed IPFIX Message.

What does constitute a malformed message? Some examples would be useful.


>
> 9.1.  Additional considerations for SCTP Collecting Processes
>
>     The Exporting Process requests a number of streams to use for export
>     at association setup time. An Exporting Process MAY request and
>     support more than one stream per SCTP association.
>
> 9.2.  Additional considerations for UDP Collecting Processes
>
>     A Transport Session for IPFIX Messages transported over UDP is
>     defined from the point of view of the Exporting Process, and roughly
>     corresponds to the time during which a given Exporting Process sends
>     IPFIX messages over UDP to a given Collecting Process. Since this is
>     difficult to detect at the Collecting Process,the Collecting Process
>     MAY expire all Transport Session state after no IPFIX Messages are
>     received from a given Exporting Process during a configurable idle
>     timeout.

That's not quite accurate: the EP may have multiple transport sessions. 
The CP may expire a particular transport session's state regardless of 
whether IPFIX Messages continue to be exported for other transport 
sessions from the EP.


>
>     The Collecting Process SHOULD accept Data Records without the
>     associated Template Record (or other definitions) required to decode
>     the Data Record.  If the Template Records (or other definitions such
>     as Common Properties) have not been received at the time Data Records
>     are received, the Collecting Process SHOULD store the Data Records
>     for a short period of time and decode them after the Template Records
>     (or other definitions) are received.  The short period of time MUST
>     be lower than the lifetime of definitions associated with identifiers
>     considered unique within the UDP session.

Per earlier comments, I think this is dangerous and we should do away 
with it.


> 10.  Transport Protocol
>
>     The IPFIX Protocol Specification has been designed to be transport
>     protocol independent.  Note that the Exporter can export to multiple
>     Collecting Processes using independent transport protocols.
>
>     The IPFIX Message Header 16-bit Length field limits the length of an
>     IPFIX Message to 65535 octets, including the header.  A Collecting
>     Process MUST be able to handle IPFIX Message lengths of up to 65535
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 42]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     octets.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 43]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
> 10.1.  Transport Compliance and Transport Usage
>
>     SCTP [RFC4960] using the PR-SCTP extension specified in [RFC3758]
>     MUST be implemented by all compliant implementations. UDP [UDP] MAY
>     also be implemented by compliant implementations. TCP [TCP] MAY also
>     be implemented by compliant implementations.
>
>     SCTP SHOULD be used in deployments where Exporters and Collectors are
>     communicating over links that are susceptible to congestion. PR-SCTP
>     is capable of providing any required degree of reliability.
>
>     TCP MAY be used in deployments where Exporters and Collectors
>     communicate over links that are susceptible to congestion, but SCTP
>     is preferred due to its ability to limit back pressure on Exporters
>     and its message versus stream orientation.
>
>     UDP MAY be used, although it is not a congestion-aware protocol.
>     However, in this case the IPFIX traffic between Exporter and
>     Collector MUST be separately contained or provisioned to minimize the
>     risk of congestion-related loss.
>
> 10.2.  SCTP
>
>     This section describes how IPFIX is transported over SCTP [RFC4960]
>     using the PR-SCTP [RFC3758] extension.
>
> 10.2.1.  Congestion Avoidance
>
>     The SCTP transport protocol provides the required level of congestion
>     avoidance by design.
>
>     SCTP will detect congestion in the end-to-end path between the IPFIX
>     Exporting Process and the IPFIX Collecting Process, and limit the
>     transfer rate accordingly.  When an IPFIX Exporting Process has
>     records to export, but detects that transmission by SCTP is
>     temporarily impossible, it can either wait until sending is possible
>     again, or it can decide to drop the record.  In the latter case, the
>     dropped export data  MUST be accounted for, so that the amount of
>     dropped export data can be reported.

Say where it's accounted, ie in the Exporting Process Reliability 
Statistics Options Template (section 4.3).


>
> 10.2.2.  Reliability
>
>     The SCTP transport protocol is by default reliable, but has the
>     capability to deliver messages with partial reliability [RFC3758].
>
>     Using reliable SCTP messages for the IPFIX export is not in itself a
>     guarantee that all Data Records will be delivered.  If there is
>     congestion on the link from the Exporting Process to the Collecting
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 44]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     Process, or if a significant number of retransmissions are required,
>     the send queues on the Exporting Process may fill up; the Exporting
>     Process MAY either suspend, export, or discard the IPFIX Messages.
>     If Data Records are discarded the IPFIX Sequence Numbers used for
>     export MUST reflect the loss of data.
>
> 10.2.3.  MTU
>
>     SCTP provides the required IPFIX Message fragmentation service based
>     on path MTU discovery.
>
> 10.2.4.  Association Establishment and Shutdown
>
>     The IPFIX Exporting Process SHOULD initiate an SCTP association with
>     the IPFIX Collecting Process.  By default, the Collecting Process
>     listens for connections onSCTP port 4739.  By default, the
>     Collecting Process listens for secure connections onSCTP port 4740

xref IANA for the ports.
ie, 
http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml


>     (refer to the Security Considerations section).  By default, the
>     Exporting Process tries to connect to one of these ports.It MUST be
>     possible to configure both the Exporting and Collecting Processes to
>     use a different SCTP port.

A different port from the default; not a different port from each other!

Since this paragraph is repeated for UDP and TCP, why not put it in the 
generic section above?


>
>     The Exporting Process MAY establish more than one association
>     (connection "bundle" in SCTP terminology) to the Collecting Process.
>
>     An Exporting Process MAY support more than one active association to
>     different Collecting Processes (including the case of different
>     Collecting Processes on the same host).
>
>     When an Exporting Process is shut down, it SHOULD shut down the SCTP
>     association.
>
>     When a Collecting Process no longer wants to receive IPFIX Messages,
>     it SHOULD shut down its end of the association.  The Collecting
>     Process SHOULD continue to receive and process IPFIX Messages until
>     the Exporting Process has closed its end of the association.
>
>     When a Collecting Process detects that the SCTP association has been
>     abnormally terminated, it MUST continue to listen for a new
>     association establishment.
>
>     When an Exporting Process detects that the SCTP association to the
>     Collecting Process is abnormally terminated, it SHOULD try to
>     re-establish the association.
>
>     Association timeouts SHOULD be configurable.
>
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 45]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
> 10.2.5.  Failover
>
>     If the Collecting Process does not acknowledge the attempt by the
>     Exporting Process to establish an association, the Exporting Process
>     should retry using the SCTP exponential backoff feature.  The
>     Exporter MAY log an alarm if the time to establish the association
>     exceeds a specified threshold, configurable on the Exporter.
>
>     If Collecting Process failover is supported by the Exporting Process,
>     a second SCTP association MAY be opened in advance.
>
> 10.2.6.  Streams
>
>     An Exporting Process MAY request more than one SCTP stream per
>     association.  Each of these streams may be used for the transmission
>     of IPFIX Messages containing Data Sets, Template Sets, and/or Options
>     Template Sets.
>
>     Depending on the requirements of the application, the Exporting
>     Process may send Data Sets with full or partial reliability, using
>     ordered or out-of-order delivery, over any SCTP stream established
>     during SCTP Association setup.
>
>     An IPFIX Exporting Process MAY use any PR-SCTP Service Definition as
>     per Section 4 of the PR-SCTP [RFC3758] specification when using
>     partial reliability to transmit IPFIX Messages containing only Data
>     Sets.
>
>     However, Exporting Processes SHOULD mark such IPFIX Messages for
>     retransmission for as long as resource or other constraints allow.
>
> 10.3.  UDP
>
>     This section describes how IPFIX is transported over UDP [UDP].
>
> 10.3.1.  Congestion Avoidance
>
>     UDP has no integral congestion-avoidance mechanism. Its use over
>     congestion-sensitive network paths is therefore not recommended. UDP
>     MAY be used in deployments where Exporters and Collectors always
>     communicate over dedicated links that are not susceptible to
>     congestion, i.e., links that are over-provisioned compared to the
>     maximum export rate from the Exporters.
>
> 10.3.2.  Reliability
>
>     UDP is not a reliable transport protocol, and cannot guarantee
>     delivery of messages.  IPFIX Messages sent from the Exporting Process
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 46]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     to the Collecting Process using UDP may therefore be lost.  UDP MUST
>     NOT be used unless the application can tolerate some loss of IPFIX
>     Messages.
>
>     The Collecting Process SHOULD deduce the loss and reordering of IPFIX
>     Data Records by looking at the discontinuities in the IPFIX Sequence
>     Number.  In the case of UDP, the IPFIX Sequence Number contains the
>     total number of IPFIX Data Records sent for the UDP Transport Session
>     prior to the receipt of this IPFIX Message, modulo 2^32.  A Collector
>     SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages
>     by tracking the Sequence Number.  Templates sent from the Exporting
>     Process to the Collecting Process using UDP as a transport MUST be
>     re-sent at regular intervals, in case previous copies were lost.

Or in case the CP (re)started.


>
>     Exporting Processes exporting IPFIX Messages via UDP MUST include a
>     valid UDP checksum.
>
> 10.3.3.  MTU
>
>     The maximum size of exported messages MUST be configured such that
>     the total packet size does not exceed the path MTU.  If the path MTU
>     is unknown, a maximum packet size of 512 octets SHOULD be used.
>
> 10.3.4.  Session Establishment and Shutdown
>
>     By default, the Collecting Process listens on the UDP port 4739.  By
>     default, the Collecting Process listens for secure connections on UDP
>     port 4740 (refer to the "Security Considerations" section).  By
>     default, the Exporting Process tries to connect to one of these
>     ports.  It MUST be possible to configure both the Exporting and
>     Collecting Processes to use a different UDP port.

This is just repetition of 10.2.4.


>
>     As UDP is a connectionless protocol, there is no real session
>     establishment or shutdown for IPFIX over UDP. An Exporting Process
>     starts sending IPFIX Messages to a Collecting Process at one point in
>     time, and stops sending them at another point in time. This leads to
>     some complications in template management, which are outlined in
>     Section 8.4 above.
>
> 10.3.5.  Failover and Session Duplication
>
>     Because UDP is not a connection-oriented protocol, the Exporting
>     Process is unable to determine from the transport protocol that the
>     Collecting Process is no longer able to receive the IPFIX Messages.
>     Therefore, it cannot invoke a failover mechanism.  However, the
>     Exporting Process MAY duplicate the IPFIX Message to several
>     Collecting Processes.
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 47]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
> 10.4.  TCP
>
>     The IPFIX Exporting Process initiates a TCP connection to the
>     Collecting Process.  By default, the Collecting Process listens for
>     connections on TCP port 4739.  By default, the Collecting Process
>     listens for secure connections on TCP port 4740 (refer to the
>     Security Considerations section).  By default, the Exporting Process
>     tries to connect to one of these ports.  It MUST be possible to
>     configure both the Exporting Process and the Collecting Process to
>     use a different TCP port.  

This is just repetition of 10.2.4 and 10.3.4.


>
>     An Exporting Process MAY support more than one active connection to
>     different Collecting Processes (including the case of different
>     Collecting Processes on the same host).
>
>     The Exporter MAY log an alarm if the time to establish the connection
>     exceeds a specified threshold, configurable on the Exporter.
>
> 10.4.1.  Congestion Avoidance
>
>     TCP controls the rate at which data can be sent from the Exporting
>     Process to the Collecting Process, using a mechanism that takes into
>     account both congestion in the network and the capabilities of the
>     receiver.
>
>     Therefore, an IPFIX Exporting Process may not be able to send IPFIX
>     Messages at the rate that the Metering Process generates it, either
>     because of congestion in the network or because the Collecting
>     Process cannot handle IPFIX Messages fast enough. As long as
>     congestion is transient, the Exporting Process can buffer IPFIX
>     Messages for transmission. But such buffering is necessarily limited,
>     both because of resource limitations and because of timeliness
>     requirements, so ongoing and/or severe congestion may lead to a
>     situation where the Exporting Process is blocked.

If IPFIX Messages are delayed (whether in the EP, or in the network 
stack), should/must their header Export Time be rewritten?
In the latter (stack) case, this may not even be possible.


>
>     When an Exporting Process has Data Records to export but the
>     transmission buffer is full, and it wants to avoid blocking, it can
>     decide to drop some Data Records.The dropped Data Records MUST be
>     accounted for, so that the number of lost records can later be
>     exported as in Section 4.3.

Say how they're accounted.


>
>     When an Exporting Process finds that the rate at which records should
>     be exported is consistently higher than the rate at which TCP sending
>     permits, it SHOULD provide back pressure to the Metering Processes.
>     The Metering Process could then adapt by temporarily reducing the
>     amount of data it generates, for example, using sampling or
>     aggregation.

That has it's own issues, eg sampling is introduced or sampling rate 
changes -> data records can't be aggregated with previous records at the 
collector, until they're normalised.

Anyway, although sampling means the counts will be lower, the flow 
records will still exist - so the export bandwidth won't change much. 
The EP needs less flow records, as opposed to smaller counts within each 
record.


>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 48]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
> 10.4.2.  Reliability
>
>     TCP ensures reliable delivery of data from the Exporting Process to
>     the Collecting Process.
>
>     In the case of TCP, the IPFIX Sequence Number contains the total
>     number of IPFIX Data Records sent from this TCP connection, from the
>     current Observation Domain by the Exporting Process, prior to the
>     receipt of this IPFIX Message, modulo 2^32.

This is called out as if it's somehow different, which is misleading: 
this is unchanged regardless of transport, so it should be stated once 
generically.


> 10.4.3.  MTU
>
>     As TCP offers a stream service instead of a datagram or sequential
>     packet service, IPFIX Messages transported over TCP are instead
>     separated using the Length field in the IPFIX Message Header. The
>     Exporting Process can choose any valid length for exported IPFIX
>     Messages, as TCP handles segmentation.
>
>     However, if an Exporting Process exports data from multiple
>     Observation Domains, it should be careful to choose IPFIX Message
>     lengths appropriatelyto minimize head-of-line blocking between
>     different Observation Domains.  Multiple TCP connections MAY be used
>     to avoid head-of-line blocking between different Observation Domains.
>
> 10.4.4.  Connection Establishment, Shutdown, and Restart
>
>     The IPFIX Exporting Process initiates a TCP connection to the
>     Collecting Process.  By default, the Collecting Process listens for
>     connections on TCP port 4739.  By default, the Collecting Process
>     listens for secure connections on TCP port 4740 (refer to the
>     Security Considerations section).  By default, the Exporting Process
>     tries to connect to one of these ports.  It MUST be possible to
>     configure both the Exporting Process and the Collecting Process to
>     use a different TCP port.  

This is unnecessary repetition of 10.2.4, 10.3.4, and 10.4.


>
>     An Exporting Process MAY support more than one active connection to
>     different Collecting Processes (including the case of different
>     Collecting Processes on the same host).
>
>     The Exporter MAY log an alarm if the time to establish the connection
>     exceeds a specified threshold, configurable on the Exporter.
>
>     When an Exporting Process is shut down, it SHOULD shut down the TCP
>     connection.
>
>     When a Collecting Process no longer wants to receive IPFIX Messages,
>     it SHOULD close its end of the connection.  The Collecting Process
>     SHOULD continue to read IPFIX Messages until the Exporting Process
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 49]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     has closed its end.
>
>     When a Collecting Process detects that the TCP connection to the
>     Exporting Process has terminated abnormally, it MUST continue to
>     listen for a new connection.
>
>     When an Exporting Process detects that the TCP connection to the
>     Collecting Process has terminated abnormally, it SHOULD try to
>     re-establish the connection.  Connection timeouts and retry schedules
>     SHOULD be configurable.  In the default configuration, an Exporting
>     Process MUST NOT attempt to establish a connection more frequently
>     than once per minute.
>
> 10.4.5.  Failover
>
>     If the Collecting Process does not acknowledge the attempt by the
>     Exporting Process to establish a connection, it will retry using the
>     TCP exponential backoff feature.
>
>     If Collecting Process failover is supported by the Exporting Process,
>     a second TCP connection MAY be opened in advance.
>
> 11.  Security Considerations
>
>     The security considerations for the IPFIX protocol have been derived
>     from an analysis of potential security threats, as discussed in the
>     "Security Considerations" section of IPFIX requirements [RFC3917].
>     The requirements for IPFIX security are as follows:
>
>     1. IPFIX must provide a mechanism to ensure the confidentiality of
>        IPFIX data transferred from an Exporting Process to a Collecting
>        Process, in order to prevent disclosure of Flow Records
>        transported via IPFIX.
>
>     2. IPFIX must provide a mechanism to ensure the integrity of IPFIX
>        data transferred from an Exporting Process to a Collecting
>        Process, in order to prevent the injection of incorrect data or
>        control information (e.g., Templates) into an IPFIX Message
>        stream.
>
>     3. IPFIX must provide a mechanism to authenticate IPFIX Collecting
>        and Exporting Processes, to prevent the collection of data from an
>        unauthorized Exporting Process or the export of data to an
>        unauthorized Collecting Process.
>
>     Because IPFIX can be used to collect information for network
>     forensics and billing purposes, attacks designed to confuse, disable,
>     or take information from an IPFIX collection system may be seen as a
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 50]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     prime objective during a sophisticated network attack.
>
>     An attacker in a position to inject false messages into an IPFIX
>     Message stream can either affect the application using IPFIX (by
>     falsifying data), or the IPFIX Collecting Process itself (by
>     modifying or revoking Templates, or changing options); for this
>     reason, IPFIX Message integrity is important.
>
>     The IPFIX Messages themselves may also contain information of value
>     to an attacker, including information about the configuration of the
>     network as well as end-user traffic and payload data, so care must be
>     taken to confine their visibility to authorized users.  When an
>     Information Element containing end-user payload information is
>     exported, it SHOULD be transmitted to the Collecting Process using a
>     means that secures its contents against eavesdropping.  Suitable
>     mechanisms include the use of either a direct point-to-point
>     connection or the use of an encryption mechanism.  It is the
>     responsibility of the Collecting Process to provide a satisfactory
>     degree of security for this collected data, including, if necessary,
>     anonymization of any reported data.
>
> 11.1.  Applicability of TLS and DTLS
>
>     Transport Layer Security (TLS) [RFC5246] and Datagram Transport Layer
>     Security (DTLS) [RFC4347] were designed to provide the
>     confidentiality, integrity, and authentication assurances required by
>     the IPFIX protocol, without the need for pre-shared keys.
>
>     With the mandatory SCTP transport protocol for IPFIX, DTLS [RFC4347]
>     MUST be implemented.  If UDP is selected as the IPFIX transport
>     protocol, DTLS [RFC4347] MUST be implemented.  If TCP is selected as
>     the IPFIX transport protocol, TLS [RFC5246] MUST be implemented.
>
>     Note that DTLS is selected as the security mechanism for SCTP.
>     Though TLS bindings to SCTP are defined in [RFC3436], they require
>     all communication to be over reliable, bidirectional streams, and
>     require one TLS connection per stream.  This arrangement is not
>     compatible with the rationale behind the choice of SCTP as an IPFIX
>     transport protocol.
>
>     Note that using DTLS [RFC4347] has a vulnerability, i.e., a true man
>     in the middle may attempt to take data out of an association and fool
>     the sender into thinking that the data was actually received by the
>     peer. In generic TLS for SCTP (and/or TCP), this is not possible.
>     This means that the removal of a message may become hidden from the
>     sender or receiver. Another vulnerability of using SCTP with DTLS is
>     that someone could inject SCTP control information to shut down the
>     SCTP association, effectively generating a loss of IPFIX Messages if
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 51]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     those are buffered outside of the SCTP association. Techniques such
>     as [RFC6083] could be used to overcome these vulnerabilities.
>
>     When using DTLS over SCTP, the Exporting Process MUST ensure that
>     each IPFIX Message is sent over the same SCTP stream that would be
>     used when sending the same IPFIX Message directly over SCTP.  Note
>     that DTLS may send its own control messages on stream 0 with full
>     reliability; however, this will not interfere with the processing of
>     stream 0 IPFIX Messages at the Collecting Process, because DTLS
>     consumes its own control messages before passing IPFIX Messages up to
>     the application layer.
>
>     When using DTLS over SCTP or UDP, the HeartbeatExtention  [RFC6520]

Extension.


>     SHOULD be used, especially on long-lived Transport Sessions, to
>     ensure that the association remains active.
>
> 11.2.  Usage
>
>     The IPFIX Exporting Process initiates the communication to the IPFIX
>      Collecting Process, and acts as a TLS or DTLS client according to

NB wrong indentation.


>     [RFC5246] and [RFC4347], while the IPFIX Collecting Process acts as a
>     TLS or DTLS server.  The DTLS client opens a secure connection on the
>     SCTP port 4740 of the DTLS server if SCTP is selected as the
>     transport protocol.  The TLS client opens a secure connection on the
>     TCP port 4740 of the TLS server if TCP is selected as the transport
>     protocol.  The DTLS client opens a secure connection on the UDP port
>     4740 of the DTLS server if UDP is selected as the transport
>     protocol.

Cite IANA for port 4740.


>
> 11.3.  Authentication
>
>     IPFIX Exporting Processes and IPFIX Collecting Processes are
>     identified by the fully qualified domain name of the interface on
>     which IPFIX Messages are sent or received, for purposes of X.509
>     client and server certificates as in [RFC5280].
>
>     To prevent man-in-the-middle attacks from impostor Exporting or
>     Collecting Processes, the acceptance of data from an unauthorized
>     Exporting Process, or the export of data to an unauthorized
>     Collecting Process, strong mutual authentication via asymmetric keys
>     MUST be used for both TLS and DTLS.  Each of the IPFIX Exporting and
>     Collecting Processes MUST verify the identity of its peer against its
>     authorized certificates, and MUST verify that the peer's certificate
>     matches its fully qualified domain name, or, in the case of SCTP, the
>     fully qualified domain name of one of its endpoints.
>
>
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 52]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     The fully qualified domain name used to identify an IPFIX Collecting
>     Process or Exporting Process may be stored either in a subjectAltName
>     extension of type dNSName, or in the most specific Common Name field
>     of the Subject field of the X.509 certificate.  If both are present,
>     the subjectAltName extension is given preference.
>
>     Internationalized domain names (IDN) in either the subjectAltName
>     extension of type dNSName or the most specific Common Name field of
>     the Subject field of the X.509 certificate MUST be encoded using
>     Punycode [RFC3492] as described in [RFC5891], "Conversion
>     Operations".
>
> 11.4.  Protection against DoS Attacks
>
>     An attacker may mount a denial-of-service (DoS) attack against an
>     IPFIX collection system either directly, by sending large amounts of
>     traffic to a Collecting Process, or indirectly, by generating large
>     amounts of traffic to be measured by a Metering Process.
>
>     Direct denial-of-service attacks can also involve state exhaustion,
>     whether at the transport layer (e.g., by creating a large number of
>     pending connections), or within the IPFIX Collecting Process itself
>     (e.g., by sending Flow Records pending Template or scope information,
>     a large amount of Options Template Records, etc.).
>
>     SCTP mandates a cookie-exchange mechanism designed to defend against
>     SCTP state exhaustion denial-of-service attacks.  Similarly, TCP
>     provides the "SYN cookie" mechanism to mitigate state exhaustion; SYN
>     cookies SHOULD be used by any Collecting Process accepting TCP
>     connections.  DTLS also provides cookie exchange to protect against
>     DTLS server state exhaustion.
>
>     The reader should note that there is no way to prevent fake IPFIX
>     Message processing (and state creation) for UDP & SCTP communication.
>      The use of TLS and DTLS can obviously prevent the creation of fake

NB wrong indentation.


>     states, but they are themselves prone to state exhaustion attacks.
>     Therefore, Collector rate limiting SHOULD be used to protect TLS &
>     DTLS (like limiting the number of new TLS or DTLS session per second
>     to a sensible number).
>
>     IPFIX state exhaustion attacks can be mitigated by limiting the rate
>     at which new connections or associations will be opened by the
>     Collecting Process, the rate at which IPFIX Messages will be accepted
>     by the Collecting Process, and adaptively limiting the amount of
>     state kept, particularly records waiting on Templates.  These rate
>     and state limits MAY be provided by a Collecting Process; if
>     provided, the limits SHOULD be user configurable.
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 53]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     Additionally, an IPFIX Collecting Process can eliminate the risk of
>     state exhaustion attacks from untrusted nodes by requiring TLS or
>     DTLS mutual authentication, causing the Collecting Process to accept
>     IPFIX Messages only from trusted sources.
>
>     With respect to indirect denial of service, the behavior of IPFIX
>     under overload conditions depends on the transport protocol in use.
>     For IPFIX over TCP, TCP congestion control would cause the flow of
>     IPFIX Messages to back off and eventually stall, blinding the IPFIX
>     system.  SCTP improves upon this situation somewhat, as some IPFIX
>     Messages would continue to be received by the Collecting Process due
>     to the avoidance of head-of-line blocking by SCTP's multiple streams
>     and partial reliability features, possibly affording some visibility
>     of the attack.  The situation is similar with UDP, as some datagrams
>     may continue to be received at the Collecting Process, effectively
>     applying sampling to the IPFIX Message stream, implying that some
>     forensics may be left.
>
>     To minimize IPFIX Message loss under overload conditions, some
>     mechanism for service differentiation could be used to prioritize
>     IPFIX traffic over other traffic on the same link.  Alternatively,
>     IPFIX Messages can be transported over a dedicated network.  In this
>     case, care must be taken to ensure that the dedicated network can
>     handle the expected peak IPFIX Message traffic.
>
> 11.5.  When DTLS or TLS Is Not an Option
>
>     The use of DTLS or TLS might not be possible in some cases due to
>     performance issues or other operational concerns.
>
>     Without TLS or DTLS mutual authentication, IPFIX Exporting Processes
>     and Collecting Processes can fall back on using IP source addresses
>     to authenticate their peers.  A policy of allocating Exporting
>     Process and Collecting Process IP addresses from specified address
>     ranges, and using ingress filtering to prevent spoofing, can improve
>     the usefulness of this approach.  Again, completely segregating IPFIX
>     traffic on a dedicated network, where possible, can improve security
>     even further.  In any case, the use of open Collecting Processes
>     (those that will accept IPFIX Messages from any Exporting Process
>     regardless of IP address or identity) is discouraged.
>
>     Modern TCP and SCTP implementations are resistant to blind insertion
>     attacks (see [RFC1948], [RFC4960]); however, UDP offers no such
>     protection.  For this reason, IPFIX Message traffic transported via
>     UDP and not secured via DTLS SHOULD be protected via segregation to a
>     dedicated network.
>
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 54]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
> 11.6.  Logging an IPFIX Attack
>
>     IPFIX Collecting Processes MUST detect potential IPFIX Message
>     insertion or loss conditions by tracking the IPFIX Sequence Number,
>     and SHOULD provide a logging mechanism for reporting out-of-sequence
>     messages.  Note that an attacker may be able to exploit the handling
>     of out-of-sequence messages at the Collecting Process, so care should
>     be taken in handling these conditions.  For example, a Collecting
>     Process that simply resets the expected Sequence Number upon receipt
>     of a later Sequence Number could be temporarily blinded by deliberate
>     injection of later Sequence Numbers.
>
>     IPFIX Exporting and Collecting Processes SHOULD log any connection
>     attempt that fails due to authentication failure, whether due to
>     being presented an unauthorized or mismatched certificate during TLS
>     or DTLS mutual authentication, or due to a connection attempt from an
>     unauthorized IP address when TLS or DTLS is not in use.
>
>     IPFIX Exporting and Collecting Processes SHOULD detect and log any
>     SCTP association reset or TCP connection reset.
>
> 11.7.  Securing the Collector
>
>     The security of the Collector and its implementation is important to
>     achieve overall security.  However, it is outside the scope of this
>     document.
>
> 12.  IANA Considerations
>
>     IPFIX Messages use two fields with assigned values.  These are the
>     IPFIX Version Number, indicating which version of the IPFIX Protocol
>     was used to export an IPFIX Message, and the IPFIX Set ID, indicating
>     the type for each set of information within an IPFIX Message.
>
>     The IPFIX Version Number value of 10 is reserved for the IPFIX
>     protocol specified in this document.  Set ID values of 0 and 1 are
>     not used for historical reasons [RFC3954].  The Set ID value of 2 is

Again, "not used for historical reasons" is ambiguous (ie, could be used 
for other reasons).


>     reserved for the Template Set.  The Set ID value of 3 is reserved for
>     the Options Template Set.  All other Set ID values from 4 to 255 are
>     reserved for future use.  Set ID values above 255 are used for Data
>     Sets.
>
>     New assignments in either IPFIX Version Number or IPFIX Set ID
>     assignments require a Standards Action [RFC5226], i.e., they are to
>     be made via Standards Track RFCs approved by the IESG.
>
>
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 55]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
> Appendix A.  IPFIX Encoding Examples
>
>     This appendix, which is a not a normative reference, contains IPFIX
>     encoding examples.
>
>     Let's consider the example of an IPFIX Message composed of a
>     Template Set, a Data Set (which contains three Data Records), an
>     Options Template Set and a Data Set (which contains 2 Data Records
>     related to the previous Options Template Record).
>
>     IPFIX Message:
>
>     +--------+------------------------------------------. . .
>     |        | +--------------+ +------------------+
>     |Message | | Template     | | Data             |
>     | Header | | Set          | | Set              |   . . .
>     |        | | (1 Template) | | (3 Data Records) |
>     |        | +--------------+ +------------------+
>     +--------+------------------------------------------. . .
>
>          . . .-------------------------------------------+
>                +------------------+ +------------------+ |
>                | Options          | | Data             | |
>         . . .  | Template Set     | | Set              | |
>                | (1 Template)     | | (2 Data Records) | |
>                +------------------+ +------------------+ |
>          . . .-------------------------------------------+
>
> A.1.  Message Header Example
>
>     The Message Header is composed of:
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |     Version = 0x000a          |         Length = 152          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                          Export Time                          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                        Sequence Number                        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                     Observation Domain ID                     |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>
>
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 56]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
> A.2.  Template Set Examples
>
> A.2.1.  Template Set Using IETF-Specified Information Elements
>
>
>     We want to report the following Information Elements:
>
>     - The IPv4 source IP address: sourceIPv4Address in [RFC5102bis],
>       with a length of 4 octets
>
>     - The IPv4 destination IP address: destinationIPv4Address in
>       [RFC5102bis], with a length of 4 octets
>
>     - The next-hop IP address (IPv4): ipNextHopIPv4Address in
>       [RFC5102bis], with a length of 4 octets
>
>     - The number of packets of the Flow: packetDeltaCount in
>       [RFC5102bis], with a length of 4 octets
>
>     - The number of octets of the Flow: octetDeltaCount in
>       [RFC5102bis], with a length of 4 octets
>
>     Therefore, the Template Set will be composed of the following:
>
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |         Set ID = 2            |      Length = 28 octets       |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |       Template ID 256         |       Field Count = 5         |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |0|    sourceIPv4Address = 8    |       Field Length = 4        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |0| destinationIPv4Address = 12 |       Field Length = 4        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |0|  ipNextHopIPv4Address = 15  |       Field Length = 4        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |0|    packetDeltaCount = 2     |       Field Length = 4        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |0|    octetDeltaCount = 1      |       Field Length = 4        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> A.2.2.  Template Set Using Enterprise-Specific Information Elements
>
>     We want to report the following Information Elements:
>
>     - The IPv4 source IP address: sourceIPv4Address in [RFC5102bis], with
>       a length of 4 octets
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 57]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     - The IPv4 destination IP address: destinationIPv4Address in
>       [RFC5102bis], with a length of 4 octets
>
>     - An enterprise-specific Information Element representing
>       proprietary information, with a type of 15 and a length of 4
>
>     - The number of packets of the Flow: packetDeltaCount in
>       [RFC5102bis], with a length of 4 octets
>
>     - The number of octets of the Flow: octetDeltaCount in  [RFC5102bis],

"in [RFC" is double-spaced.


>       with a length of 4 octets
>
>     Therefore, the Template Set will be composed of the following:
>
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |         Set ID = 2            |      Length = 32 octets       |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |       Template ID 257         |       Field Count = 5         |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |0|    sourceIPv4Address = 8    |       Field Length = 4        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |0| destinationIPv4Address = 12 |       Field Length = 4        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |1| Information Element Id. = 15|       Field Length = 4        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                       Enterprise number                       |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |0|    packetDeltaCount = 2     |       Field Length = 4        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |0|    octetDeltaCount = 1      |       Field Length = 4        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 58]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
> A.3.  Data Set Example
>
>     In this example, we report the following three Flow Records:
>
>     Src IP addr. | Dst IP addr.  | Next Hop addr. | Packet | Octets
>                  |               |                | Number | Number
>     ------------------------------------------------------------------
>     192.0.2.12   | 192.0.2.254   | 192.0.2.1      | 5009   | 5344385
>     192.0.2.27   | 192.0.2.23    | 192.0.2.2      | 748    | 388934
>     192.0.2.56   | 192.0.2.65    | 192.0.2.3      | 5      | 6534
>
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |          Set ID = 256         |          Length = 64          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                          192.0.2.12                           |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                          192.0.2.254                          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                          192.0.2.1                            |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                             5009                              |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                            5344385                            |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                          192.0.2.27                           |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                          192.0.2.23                           |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                          192.0.2.2                            |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                              748                              |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                             388934                            |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                          192.0.2.56                           |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                          192.0.2.65                           |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                          192.0.2.3                            |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                               5                               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                              6534                             |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>     Note that padding is not necessary in this example.
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 59]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
> A.4.  Options Template Set Examples
>
> A.4.1.  Options Template Set Using IETF-Specified Information Elements
>     
>
>     Per line card (the router being composed of two line cards), we want
>     to report the following Information Elements:
>
>     - Total number of IPFIX Messages: exportedMessageTotalCount
>       [RFC5102bis], with a length of 2 octets
>
>     - Total number of exported Flows: exportedFlowRecordTotalCount
>       [RFC5102bis], with a length of 2 octets
>
>     The line card, which is represented by the lineCardId Information
>     Element [RFC5102bis], is used as the Scope Field.
>
>     Therefore, the Options Template Set will be:
>
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |         Set ID = 3            |          Length = 24          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |       Template ID 258         |        Field Count = 3        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |     Scope Field Count = 1     |0|     lineCardId = 141        |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |   Scope 1 Field Length = 4    |0|exportedMessageTotalCount=41 |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |       Field Length = 2        |0|exportedFlowRecordTotalCo.=42|
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |       Field Length = 2        |           Padding             |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> A.4.2.  Options Template Set Using Enterprise-Specific Information
>          Elements
>
>     Per line card (the router being composed of two line cards), we want
>     to report the following Information Elements:
>
>        - Total number of IPFIX Messages: exportedMessageTotalCount
>          [RFC5102bis], with a length of 2 octets
>
>        - An enterprise-specific number of exported Flows, with a type of
>          42 and a length of 4 octets
>
>     The line card, which is represented by the lineCardId Information
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 60]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     Element [RFC5102bis], is used as the Scope Field.
>
>     The format of the Options Template Set is as follows:
>
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |         Set ID = 3            |          Length = 28          |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |       Template ID 259         |        Field Count = 3        |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |     Scope Field Count = 1     |0|     lineCardId = 141        |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |   Scope 1 Field Length = 4    |0|exportedFlowRecordTotalCo.=41|
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |       Field Length = 2        |1|Information Element Id. = 42 |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |       Field Length = 4        |       Enterprise number      ...
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     ...       Enterprise number      |           Padding             |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> A.4.3.  Options Template Set Using an Enterprise-Specific Scope
>
>     In this example, we want to export the same information as in the
>     example in Section A.4.1:
>
>        - Total number of IPFIX Messages: exportedMessageTotalCount
>          [RFC5102bis], with a length of 2 octets
>
>        - Total number of exported Flows: exportedFlowRecordTotalCount
>          [RFC5102bis], with a length of 2 octets
>
>     But this time, the information pertains to a proprietary scope,
>     identified by enterprise-specific Information Element number 123.
>
>
>
>
>
>
>
>
>
>
>
>
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 61]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     The format of the Options Template Set is now as follows:
>
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |         Set ID = 3            |          Length = 28          |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |       Template ID 260         |        Field Count = 3        |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |     Scope Field Count = 1     |1|Scope 1 Infor. El. Id. = 123 |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |    Scope 1 Field Length = 4   |       Enterprise Number      ...
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     ...       Enterprise Number      |0|exportedMessageTotalCount=41 |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |       Field Length = 2        |0|exportedFlowRecordTotalCo.=42|
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |       Field Length = 2        |           Padding             |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> A.4.4.  Data Set Using an Enterprise-Specific Scope
>
>     In this example, we report the following two Data Records:
>
>     Enterprise field 123   | IPFIX Message  | Exported Flow Records
>     -------------------------------------------------------------------
>     1                      | 345            | 10201
>     2                      | 690            | 20402
>
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |      Set ID = 260             |         Length = 20           |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                               1                               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |             345               |            10201              |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                               2                               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |             690               |            20402              |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>
>
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 62]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
> A.5.  Variable-Length Information Element Examples
>
> A.5.1.  Example of Variable-Length Information Element with Length
>          Inferior to 255 Octets
>
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |       5       |          5 octet Information Element          |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> A.5.2.  Example of Variable-Length Information Element with 3 Octet
>          Length Encoding
>
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |      255      |             1000              |    IE ...     |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                1000 octet Information Element                 |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     :                              ...                              :
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                             ... IE            |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> References
>
> Normative References

FYI (for the RFC editor) the following-lines indent is off by one in all 
the following citations:


>
>
>     [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
>                     Requirement Levels", BCP 14, RFC 2119, March 1997.
>
>     [RFC3436]      Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport
>                     Layer Security over Stream Control Transmission
>                     Protocol", RFC 3436, December 2002.
>
>     [RFC3492]      Costello, A., "Punycode: A Bootstring encoding of
>                     Unicode for Internationalized Domain Names in
>                     Applications (IDNA)", RFC 3492, March 2003.
>
>     [RFC3758]      Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
>                     Conrad, "Stream Control Transmission Protocol (SCTP)
>                     Partial Reliability Extension", RFC 3758, May 2004.
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 63]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     [RFC4347]      Rescorla, E. and N. Modadugu, "Datagram Transport
>                     Layer Security", RFC 4347, April 2006.

** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347)

>
>     [RFC4960]      Stewart, R., Ed., "Stream Control Transmission
>                     Protocol", RFC 4960, September 2007.
>
>     [RFC5226]      Narten, T. and H. Alvestrand, "Guidelines for Writing
>                     an IANA Considerations Section in RFCs", BCP 26, RFC
>                     5226, May 2008.
>
>     [RFC5246]      Dierks, T. and E. Rescorla, "The Transport Layer
>                     Security (TLS) Protocol Version 1.2", RFC 5246,
>                     August 2008.
>
>     [RFC5280]      Cooper, D., Santesson, S., Farrell, S. Boeyen, S.
>                     Housley, R., and W. Polk, "Internet X.509 Public Key
>                     Infrastructure Certificate and Certificate Revocation
>                     List (CRL) Profile", RFC 5280, April 2008.
>
>     [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
>
>     [RFC5891]      J. Klensin, "Internationalized Domain Names in
>                     Applications (IDNA): Protocol", RFC 5891, August
>                     2010.
>
>     [RFC6520]      Seggelmann, R., Tuexen, M., and Williams, M.,
>                     "Transport Layer Security (TLS) and Datagram
>                     Transport Layer Security (DTLS) Heartbeat Extension",
>                     RFC 6520, February 2012.
>
>     [TCP]          Postel, J., "Transmission Control Protocol", STD 7,
>                     RFC 793, September 1981.
>
>     [UDP]          Postel, J., "User Datagram Protocol", STD 6, RFC 768,
>                     August 1980.
>
>     [RFC5102bis]   Quittek, J., Bryant S., Claise, B., Aitken, P., and J.
>                     Meyer, "Information Model for IP Flow Information
>                     Export", draft-claise-ipfix-information-model-
>                     rfc5102bis-01.txt, Work in Progress, October 2011.

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


>
> Informative References
>
>     [PEN]          IANA Private Enterprise Numbers registry
>                     http://www.iana.org/assignments/enterprise-numbers.
>                     
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 64]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     [RFC1948]      Bellovin, S., "Defending Against Sequence Number
>                     Attacks", RFC 1948, May 1996.

-- Obsolete informational reference (is this intentional?): RFC 1948 
(Obsoleted by RFC 6528)


>
>     [RFC2579]      McCloghrie, K., Perkins, D., and J. Schoenwaelder,
>                     "Textual Conventions for SMIv2", STD 58, RFC 2579,
>                     April 1999.
>
>     [RFC3550]      Schulzrinne, H., Casner, S., Frederick, R., and V.
>                     Jacobson, "RTP: A Transport Protocol for Real-Time
>                     Applications", STD 64, RFC 3550, July 2003.
>
>     [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.
>
>     [RFC5101]      Claise, B., Ed., "Bidirectional Flow Export Using IP
>                     Flow Information Export (IPFIX)", RFC 5103, January
>                     2008.
>
>     [RFC5103]      Trammell, B., and E. Boschi, "Specification of the IP
>                     Flow Information Export (IPFIX) Protocol for the
>                     Exchange of IP Traffic Flow Information", RFC 5101,
>                     January 2008.
>
>     [RFC5153]      Boschi, E., Mark, L., Quittek J., and P. Aitken, "IP
>                     Flow Information Export (IPFIX) Implementation
>                     Guidelines", RFC5153, April 2008
>
>     [RFC5470]      Sadasivan, G., Brownlee, N., Claise, B., and J.
>                     Quittek, "Architecture for IP Flow Information
>                     Export", RFC5470, March 2009.
>
>     [RFC5472]      Zseby, T., Boschi, E., Brownlee, N., and B. Claise,
>                     "IP Flow Information Export (IPFIX) Applicability",
>                     RFC5472, March 2009.
>
>     [RFC5471]      Schmoll, C., Aitken, P., and B. Claise, "Guidelines
>                     for IP Flow Information Export (IPFIX) Testing",
>                     RFC5471, 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,
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 65]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>                     "Exporting Type Information for IP Flow Information
>                     Export (IPFIX) Information Elements", July 2009.
>
>     [RFC6083]      Tuexen, M., Seggelman, R. and E. Rescola, "Datagram
>                     Transport Layer Security (DTLS) for Stream Control
>                     Transmission Protocol (SCTP)", RFC6083, January 2011.
>
>     [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.
>
>     [POSIX.1]      IEEE 1003.1-2008 - IEEE Standard for Information
>                     Technology - Portable Operating System Interface,
>                     IEEE, 2008.
>
>     [IEEE.754.1985] Institute of Electrical and Electronics Engineers,
>                     "Standard for Binary Floating-Point Arithmetic", IEEE
>                     Standard 754, August 1985.
>
>     [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.

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


>
>     [IPFIX-PER-SCTP-STREAM] Claise, B., Aitekn, P., Johnson, A. and G.
>                     Muenz, "IPFIX Export per SCTP Stream", draft-ietf-
>                     ipfix-export-per-sctp-stream-08, Work in Progress,
>                     May 2010.

== Outdated reference: draft-ietf-ipfix-export-per-sctp-stream has been 
published as RFC 6526


P.

>
>     [IPFIX-MED-PROTO] Claise, B., Kobayashi, A., and B. Trammell,
>                     "Specification of the Protocol for IPFIX Mediations",
>                     draft-claise-ipfix-mediation-protocol-04, Work in
>                     Progress, July 2011.
>
>     [RFC5815bis]   Dietz, T., Kobayashi, A., Claise, B., and G. Muenz,
>                     "Definitions of Managed Objects for IP Flow
>                     Information Export", draft-dkcm-ipfix-rfc5815bis-
>                     00.txt, Work in Progress, October 2011.
>
> Acknowledgments
>
>     We would like to thank the following persons: Ganesh Sadasivan for
>     his significant contribution during the initial phases of the
>     protocol specification; Juergen Quittek for the coordination job
>     within IPFIX and PSAMP; Nevil Brownlee, Dave Plonka, Paul Aitken, and
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 66]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     Andrew Johnson for the thorough reviews; Randall Stewart and Peter
>     Lei for their SCTP expertise and contributions; Martin Djernaes for
>     the first essay on the SCTP section; Michael Behringer and Eric
>     Vyncke for their advice and knowledge in security; Michael Tuexen for
>     his help regarding the DTLS section; Elisa Boschi for her
>     contribution regarding the improvement of SCTP sections; Mark
>     Fullmer, Sebastian Zander, Jeff Meyer, Maurizio Molina, Carter
>     Bullard, Tal Givoly, Lutz Mark, David Moore, Robert Lowe, Paul
>     Calato, Andrew Feren, Gerhard Muenz, and many more, for the technical
>     reviews and feedback.
>
> Authors' Addresses
>
>     Benoit Claise (Ed.)
>     Cisco Systems
>     De Kleetlaan 6a b1
>     1831 Diegem
>     Belgium
>
>     Phone: [phone]
>     EMail: [e-mail]
>
>
>     Brian Trammell (Ed.)
>     Swiss Federal Institute of Technology Zurich
>     Gloriastrasse 35
>     8092 Zurich
>     Switzerland
>
>     Phone: [phone]
>     EMail: [e-mail]
>
>
>     Stewart Bryant
>     Cisco Systems, Inc.
>     250, Longwater,
>     Green Park,
>     Reading, RG2 6GB,
>     United Kingdom
>
>     Phone: [phone]
>     EMail: [e-mail]
>
>
>
>
>
>
>   
>
>
> <Claise, et al.>            Standards Track                    [Page 67]
> 
> Internet-Draft        IPFIX Protocol Specification     November 20, 2012
>
>
>     Simon Leinen
>     SWITCH
>     Werdstrasse 2
>     P.O. Box
>     8021 Zurich
>     Switzerland
>
>     Phone: [phone]
>     EMail: [e-mail]
>
>
>     Thomas Dietz
>     NEC Europe Ltd.
>     NEC Laboratories Europe
>     Network Research Division
>     Kurfuersten-Anlage 36
>     69115 Heidelberg
>     Germany
>
>     Phone: [phone]
>     EMail: [e-mail]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> <Claise, et al.>            Standards Track                    [Page 68]