Subject: [IPFIX] Review: draft-trammell-ipfix-file-04

From: Paul Aitken <[email-masked]>
Date: Thu, 26 Jul 2007 23:08:24 +0100

Hi Brian.

Please see my comments inline.

> 
> IPFIX Working Group                                          B. Trammell
> Internet-Draft                                                CERT/NetSA
> Intended status: Standards Track                               E. Boschi
> Expires: January 10, 2008                                 Hitachi Europe
>                                                                  L. Mark
>                                                                 T. Zseby
>                                                         Fraunhofer FOKUS
>                                                                A. Wagner
>                                                               ETH Zurich
>                                                             July 9, 2007
> 
> 
>                        An IPFIX-Based File Format
>                     draft-trammell-ipfix-file-04.txt
> 
> Status of this Memo
> 
>    By submitting this Internet-Draft, each author represents that any
>    applicable patent or other IPR claims of which he or she is aware
>    have been or will be disclosed, and any of which he or she becomes
>    aware will be disclosed, in accordance with Section 6 of BCP 79.
> 
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups.  Note that
>    other groups may also distribute working documents as Internet-
>    Drafts.
> 
>    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."
> 
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/ietf/1id-abstracts.txt.
> 
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
> 
>    This Internet-Draft will expire on January 10, 2008.
> 
> Copyright Notice
> 
>    Copyright (C) The IETF Trust (2007).
> 
> Abstract
> 
>    This document describes a file format for the storage of flow data
>    based upon the IPFIX message format.  It proposes a set of
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008                [Page 1]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
>    requirements for flat-file, binary flow data file formats, evaluates
>    flow storage systems presently in use for their conformance to these
>    requirements, then applies the IPFIX message format to these
>    requirements to build a new file format.  This IPFIX-based file
>    format is designed to facilitate interoperability and reusability
>    among a wide variety of flow storage, processing, and analysis tools.
> 
> 
> Table of Contents
> 
>    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
>    2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
>    3.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  5
>    4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  7
>      4.1.  Record Format Flexibility  . . . . . . . . . . . . . . . .  7
>      4.2.  Self Description . . . . . . . . . . . . . . . . . . . . .  7
>      4.3.  Data Compression . . . . . . . . . . . . . . . . . . . . .  8
>      4.4.  Indexing and Searching . . . . . . . . . . . . . . . . . .  8
>      4.5.  Data Integrity . . . . . . . . . . . . . . . . . . . . . .  9
>      4.6.  Creator Authentication and Confidentiality . . . . . . . .  9
>      4.7.  Anonymization and Obfuscation  . . . . . . . . . . . . . . 10
>      4.8.  Performance Characteristics  . . . . . . . . . . . . . . . 10
>    5.  Survey of Existing Flow and Trace File Formats . . . . . . . . 11
>      5.1.  NetFlow V5/V7  . . . . . . . . . . . . . . . . . . . . . . 11
>      5.2.  Argus 2  . . . . . . . . . . . . . . . . . . . . . . . . . 11
>      5.3.  SiLK . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
>      5.4.  libpcap dumpfile . . . . . . . . . . . . . . . . . . . . . 12
>    6.  IPFIX File Format Description  . . . . . . . . . . . . . . . . 13
>      6.1.  Recommended Information Elements for IPFIX Files . . . . . 15
>        6.1.1.  collectionTimeMilliseconds . . . . . . . . . . . . . . 16
>        6.1.2.  informationElementAnonymizationType  . . . . . . . . . 16
>        6.1.3.  maxExportSeconds . . . . . . . . . . . . . . . . . . . 16
>        6.1.4.  maxFlowEndSeconds  . . . . . . . . . . . . . . . . . . 17
>        6.1.5.  messageMD5Checksum . . . . . . . . . . . . . . . . . . 17
>        6.1.6.  messageScope . . . . . . . . . . . . . . . . . . . . . 17
>        6.1.7.  minExportSeconds . . . . . . . . . . . . . . . . . . . 18
>        6.1.8.  minFlowStartSeconds  . . . . . . . . . . . . . . . . . 18
>        6.1.9.  sessionScope . . . . . . . . . . . . . . . . . . . . . 19
>      6.2.  Recommended Options Templates for IPFIX Files  . . . . . . 19
>        6.2.1.  Message Checksum Options Template  . . . . . . . . . . 19
>        6.2.2.  Template Anonymization Options Template  . . . . . . . 20
>        6.2.3.  File Time Window Options Template  . . . . . . . . . . 21
>        6.2.4.  Export Session Details Options Template  . . . . . . . 22
>        6.2.5.  Message Details Options Template . . . . . . . . . . . 23
>      6.3.  Recommended Compression Error Resilience Strategy  . . . . 25
>      6.4.  Recommended Encryption Error Resilience Strategy . . . . . 27
>    7.  Applicability of IPFIX Files . . . . . . . . . . . . . . . . . 27
>      7.1.  Testing IPFIX Collecting Processes . . . . . . . . . . . . 27
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008                [Page 2]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
>      7.2.  Storage of IPFIX-collected Flow Data . . . . . . . . . . . 28
>    8.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
>    9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 29
>    10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 29
>    11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
>    12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
>      12.1. Normative References . . . . . . . . . . . . . . . . . . . 30
>      12.2. Informative References . . . . . . . . . . . . . . . . . . 31
>    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
>    Intellectual Property and Copyright Statements . . . . . . . . . . 34
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008                [Page 3]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
> 1.  Introduction
> 
>    This document proposes a file format based upon IPFIX.  It begins by
>    exploring the motivation for proposing a standardized flow file
>    format, and using IPFIX as the basis for this new file format.  It
>    then proposes a set of requirements for this file format, evaluates
>    existing flow storage file formats for their conformance to these
>    requirements, and describes either how the IPFIX message format meets
>    each requirement, or how a file format based upon it could meet the
>    requirement.  It closes by proposing an initial specification of the

"the" -> "a"

>    new file format and providing examples of IPFIX Files meeting this

"Files" -> in the past we were avoiding capitalising terminology until 
after the terminology section, though I'm not sure whether this is a 
MUST or a SHOULD :-)  Same for "Options" below BTW.

>    specification.  This format makes use of the IPFIX Options mechanism
>    for additional file metadata, in order to avoid requiring any
>    protocol or message format extensions.
> 
> 
> 2.  Terminology
> 
>    Terms used in this document that are defined in the Terminology
>    section of the IPFIX Protocol [I-D.ietf-ipfix-protocol] document are
>    to be interpreted as defined there.
> 
>    IPFIX File:   An IPFIX File is a serialized stream of IPFIX Messages
>       stored on a filesystem.  Any IPFIX Message stream that would be
>       considered valid when transported one or more of the specified

"transported *on* one"

>       IPFIX transports (SCTP, TCP, or UDP) as defined in the IPFIX
>       Protocol draft [I-D.ietf-ipfix-protocol] is considered an IPFIX
>       File for purposes of this draft; however, this draft further
>       restricts that definition with recommendations on the construction
>       of IPFIX Files that meet the requirements identified herein.
> 
>    IPFIX File Reader:   An IPFIX File Reader is a Process which reads
>       IPFIX Files from a filesystem, and is analogous to an IPFIX
>       Collecting Process.  An IPFIX File Reader MUST behave as an IPFIX
>       Collecting Process as outlined in the IPFIX Protocol draft
>       [I-D.ietf-ipfix-protocol], except as modified by this document.
> 
>    IPFIX File Writer:   An IPFIX File Writer is a process which writes
>       IPFIX Files to a filesystem, and is analogous to an IPFIX
>       Exporting Process.  An IPFIX File Writer MUST behave as an IPFIX
>       Exporting Process as outlined in the IPFIX Protocol draft
>       [I-D.ietf-ipfix-protocol], except as modified by this document.
> 
>    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].
> 
> 
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008                [Page 4]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
> 3.  Motivation

For this section, please cite references for every assertion.

> 
>    There are a wide variety of applications for the file-based storage
>    of IP flow data, across a continuum of time scales.  Tools used in
>    the analysis of flow data and creation of analysis products often use
>    files as a convenient unit of work, with an ephemeral lifetime.  A
>    set of flows relevant to a security investigation may be stored in a
>    file for the duration of that investigation, and futher exchanged
>    among incident handlers via email or within an external incident
>    handling workflow application.  Sets of flow data relevant to
>    Internet measurement research may be published as files, much as
>    libpcap packet trace files are, to provide common data sets for the
>    repeatability of research efforts; these files would have lifetimes
>    measured in months or years.  Operational flow measurement systems
>    also have a need for long-term, archival storage of flow data, either
>    as a primary flow data repository, or as a backing tier for online
>    storage in a relational database management system (RDBMS).
> 
>    The variety of applications of flow data, and the variety of
>    presently deployed storage approaches, would seem to indicate the
>    need for a standard approach to flow storage with applicability
>    across the continuum of time scales over which flow data is stored.
>    A storage format based around flat files would best address the
>    variety of storage requirements.  While much work has been done on

Can you justify this?

>    structured storage via RDBMS, relational database systems are not a
>    good basis for format standardization owing to the fact that their
>    internal data structures are generally private to a single
>    implementation and subject to change for internal reasons.  Also,
>    there are a wide variety of operations available on flat files, and
>    external tools and standards can be leveraged to meet file-based flow
>    storage requiremenets.  Further, flow data is often not very

Typo, "requiremenets."

Can you justify "often"? Perhaps cite refs.

>    semantically complicated, is managed in very high volume, and
>    therefore an RDBMS-based flow storage system would not benefit much
>    from the advantages of relational database technology.
> 
>    The simplest way to create a new file format is simply to serialize
>    some internal data model to disk, with either textual or binary
>    representation of data elements, and some framing strategy for
>    delimiting fields and records.  "Ad-hoc" file formats such as this
>    have several important disadvantages.  One, they impose the semantics
>    of the data model from which they are derived on the file format; as
>    such, they are difficult to extend, describe, and standardize.
> 
>    Over the past decade XML markup has emerged as a new "universal"
>    representation format for structured data.  It is intended to be
>    human-readable; indeed, that is one reason for its rapid adoption.
>    However XML has limited usefulness for representing network flow
>    data.  Network flow data has a simple, repetitive, non-hierarchical
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008                [Page 5]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
>    structure that does not benefit much from XML.  An XML representation
>    of flow data would be an essentially flat list of the attributes and
>    their values for each flow record.  At the same time network flow
>    data has well-defined semantics, required to do any meaningful
>    processing; these semantics are not known to typical XML tools.

Give examples of processing? eg, "such as ..."

> 
>    The XML approach to data encoding is very heavyweight when compared
>    to binary flow encoding.  While binary flow encodings use a small
>    number of (or even just one) flat data structures that are entirely

"use a small number of flat data structures (or even just one)"

>    sufficient to encode flow data, XML uses start- and end-tags, and
>    plain-text encoding of the actual values.  This leads to significant
>    inefficiency in encoding size.  Typical network flow datasets can
>    contain millions or billions of flows per hour of traffic
>    represented.  Any increase in storage size per record can have
>    dramatic impact on flow data storage and transfer sizes.  While data
>    compression algorithms can partially remove the redundancy introduced
>    by XML encoding, they introduce additional overhead of their own.
> 
>    A further problem is that XML processing tools require a full XML
>    parser.  XML parsers are fully general and therefore complex,
>    resource-intensive and relatively slow.  Since network flow datasets
>    can be very large, XML parsing introduces significant processing time
>    overhead.  At the same time, parsers for typical binary flow data
>    encoding are simply structured, since they only need to parse a very
>    small header and then have complete knowledge of all following fields
>    for the particular flow.  These can then be read in a very efficient
>    linear fashion without the need for any further decisions.  The

Do you include variable length fields in that assertion too?

>    overhead from encoding flow data with XML may well be prohibitive for
>    processing steps that are easily done with standard binary flow
>    encodings.  At the same time XML encoding offers no discernible
>    advantage to the flow storage use case.
> 
>    This leads us to propose the IPFIX message format as the basis for a

Is this a proposal or a standard?

>    new flow data file format.  The IPFIX working group, in defining the
>    IPFIX protocol, has already defined an information model and data
>    formatting rules for representation of flow data.  Especially at
>    shorter time scales, when a file is a unit of data interchange, the
>    filesystem may be viewed as simply another IPFIX message transport
>    between processes.  This format is especially well suited to
>    representing flow data, as it was designed specifically for flow data
>    export; it is easily extensible unlike ad-hoc serialization, and
>    compact unlike XML.  In addition, IPFIX is an emerging standard for
>    the export and collection of flow data; using a common format for
>    storage and analysis at the collection side allows implementors to
>    use substantially the same information model and data formatting
>    implementation for transport as well as storage.
> 
> 
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008                [Page 6]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
> 4.  Requirements
> 
>    In this section, we outline a proposed set of requirements
>    [SAINT2007] for any persistent storage format for flow data.  First
>    and foremost, a flow data file format should support storage across
>    the continuum of time scales important to flow storage applications.
>    Each of the requirements enumerated in the sections below is broadly
>    applicable to flow storage applications, though each may be more
>    important at certain time scales.  For each, we first identify the
>    requirement, then explain how the IPFIX message format addresses it,
>    or briefly outline the changes that must be made in order for an
>    IPFIX-based file format to meet the requirement.
> 
> 4.1.  Record Format Flexibility
> 
>    Due to the wide variety of flow attributes collected by different
>    network flow attribute measurement systems, the ideal flow storage
>    format will not impose a single data model or a specific record type
>    on the flows it stores.  The file format must be flexible and
>    extensible; that is, it must support multiple record types definable
>    within the file itself, and must be able to support new field types
>    for data within the records in a graceful way.
> 
>    IPFIX provides extensibility through the use of Templates to describe
>    each Data Record, through the use of an IANA Registry to define its
>    Information Elements, and through the use of enterprise-specific
>    Information Elements.
> 
> 4.2.  Self Description
> 
>    Archived data may be read at a time in the future where any external
>    reference to the meaning of the data may be lost.  The ideal flow
>    storage format should be self-describing; that is, a process reading

"should be"? Ideally it *is*.

>    flow data from storage should be able to properly interpret the
>    stored flows without reference to anything other than standard
>    sources (e.g., the standards document describing the file format) and
>    the stored flow data itself.
> 
>    The IPFIX message format is partially self-describing; that is, IPFIX
>    Templates containing only IANA-assigned Information Elements can be
>    completely interpreted according to the IPFIX Information Model
>    without additional external data.
> 
>    However, Templates containing private information elements lack

"private" -> "Enterprise Specific". Also again below.

"Information Elements"

>    detailed type and semantic information; a Collecting Process
>    receiving data described by a template containing private Information
>    Elements it does not understand can only treat the data contained
>    within those Information Elements as octet arrays.  To be fully self-
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008                [Page 7]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
>    describing, Enterprise-Specific Information Elements must be

"must be" -> this is certainly one option, though not the only possible one.

>    additionally described via IPFIX Options according to the Information
>    Element Semantics Options Template defined in "Extended Type
>    Information for IPFIX Enterprise-Specific Information Elements"
>    [I-D.boschi-ipfix-extended-type].
> 
> 4.3.  Data Compression
> 
>    Regardless of the representation format, flow data describing traffic
>    on real networks tends to be highly compressible.  Compression tends

References!

>    to improve the scalability of flow collection systems, by reducing
>    the disk storage and I/O bandwidth requirement for a given workload.

- while increasing CPU requirements.

>    The ideal flow storage format should support applications which wish

Should?

>    to leverage this fact by supporting compression of stored data.
> 
>    The IPFIX message format has no support for data compression, as the
>    IPFIX protocol was designed for speed and simplicity of export.  Of
>    course, any flat file is readily compressible using a wide variety of
>    external data compression tools, formats, and algorithms; therefore,
>    this requirement can be met externally.

"external data compression tools" implies the file has already been made 
- in which case the I/O mentioned above is irrelevant.

> 
>    However, a couple of simple optimizations can be made by File Writers
>    to increase the integrity and usability of compressed IPFIX data;
>    these are outlined in the Recommended Compression Strategy section,

It's the "Recommended Compression Error Resilience Strategy" section.

>    which appears below.
> 
> 4.4.  Indexing and Searching
> 
>    Binary, record stream oriented file formats natively support only one
>    form of searching, sequential scan in file order.  By choosing the
>    order of records in a file carefully (e.g., by flow start or flow end

"By choosing to order records in"

>    time), a file can be indexed by a single key.

Multiple keys could be used, ie primary and secondary.

> 
>    Beyond this, properly addressing indexing is an application-specific
>    problem, as it inherently involves tradeoffs between storage
>    complexity and retrieval speed, and requirements vary widely based on
>    time scales and the types of queries used from site to site.
>    However, a generic standard flow storage format may provide limited

"may"? Is it a SHOULD?

>    direct support for indexing and searching.
> 
>    The ideal flow storage format will support a limited table of

"will"? Is it a MUST?

>    contents facility noting that the records in a file contain data
>    relating only to certain keys or values of keys, in order to keep
>    multi-file search implementations from having to scan a file for data
>    it does not contain.
> 
>    The IPFIX message format has no direct support for indexing.
>    However, its template mechanism and the technique described in
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008                [Page 8]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
>    "Reducing Redundancy in IPFIX and PSAMP Reports"
>    [I-D.ietf-ipfix-reducing-redundancy] can be used to describe the
>    contents of a file in a limited way.  Additionally, as flow data is
>    often sorted and divided by time, the start and end time of the flows
>    in a file may be declared using the File Time Window Options Record
>    defined below.
> 
> 4.5.  Data Integrity
> 
>    When storing flow data over long time scales, especially for archival
>    purposes, it is important to ensure that hardware or software faults
>    do not introduce errors into the data over time.  The ideal flow
>    storage format will support the detection and correction of encoding-

"will"? Plus many times below too. Consider whether RFC 2119 language 
would be more appropriate - because what I hear is you describing a 
product you've built, rather than writing the requirements or spec for it.

>    level errors in the data.
> 
>    Note that more advanced error correction is almost certainly best

What about error detection?

>    handled at a layer below that addressed by this document.  Error
>    correction is a topic well addressed by the storage industry in
>    general (e.g. by RAID and other technolgies), and by specifying a
>    flow storage format based upon files, we can leverage these features
>    to meet this requirement.
> 
>    However, the ideal flow storage format will be resilient against
>    errors, providing an internal facility for the detection of errors
>    and the ability to isolate errors to as few data records as possible.
> 
>    Note that this requirement interacts with the choice of data
>    compression or encryption algorithm.  The use of block compression
>    algorithms can serve to isolate errors to a single compression block,
>    unlike stream compressors, which may fail to resynchronize after a
>    single bit error, invalidating the entire message stream.  Similarly,
>    the use of a stream cipher can serve to isloate errors in the
>    plaintext without amplifying them as, for example, a cipher in CBC

References please!

>    mode can.  See the "Recommended Compression Error Resilience
>    Strategy" and "Recommended Encryption Error Resilience Strategy"
>    sections below for more on this interaction.
> 
>    The IPFIX message format does not support data integrity assurance.
>    It is assumed that advanced error correction will be provided
>    externally.  For simple error detection support, checksums may be
>    attached to messages via IPFIX Options according to the Message
>    Checksum Options Template defined below.

I'd much prefer a csum IE.

> 
> 4.6.  Creator Authentication and Confidentiality
> 
>    Storage of flow data across long time scales may also require
>    assurance that no unauthorized entity can read or modify the stored
>    data.  Asymmetric-key cryptography can be applied to this problem, by
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008                [Page 9]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
>    signing flow data with the private key of the creator, and encrypting
>    it with the public keys of those authorized to read it.  The ideal
>    flow storage format will support the encryption and signing of flow
>    data.
> 
>    As with error correction, this problem has been addressed well at a
>    layer below that addressed by this document.  Instead of specifying a

Refs?

>    particular choice of encryption technology, we can leverage the fact
>    that existing cryptographic technologies work quite well on data

"quite well"?

>    stored in files to meet this requirement.
> 
>    Beyond support for the use of TLS for transport over TCP or DTLS for
>    transport over SCTP or UDP, both of which provide transient
>    authentication and confidentiality, the IPFIX protocol does not
>    support this requirement directly.  It is assumed that this

"It is assumed"? -> "This requirement MUST"

>    requirement will be met externally.
> 
> 4.7.  Anonymization and Obfuscation
> 
>    To ensure the privacy of individuals and organizations at the
>    endpoints of communications represented by flow records, it is often
>    necessary to obfuscate or anonymize stored and exported flow data.
>    The ideal flow storage format will provide for a notation that a
>    given information element on a given record type represents
>    anonymized, rather than real, data.
> 
>    The IPFIX message format presently has no support for anonymization
>    notation.  It should be noted that anonymization is one of the
>    requirements given for IPFIX in RFC 3917 [RFC3917].  The decision to
>    qualify this requirement with 'MAY' and not 'MUST' in the
>    requirements document, and its subsequent lack of specification in
>    the current version of the IPFIX protocol, is due to the fact that
>    anonymization algorithms are still a research issue, and that there
>    currently exist no standardized methods for anonymization.
> 
>    Simple anonymization notation may be attached to templates via IPFIX
>    Options according to the Template Anonymization Options Template
>    defined below.
> 
> 4.8.  Performance Characteristics
> 
>    The ideal standard flow storage format will not have a significant
>    negative impact on the performance of the application implementing
>    it.  This is a non-functional requirement, but it is important to
>    note that a standard that implies a performance penalty is unlikely
>    to be widely implemented and adopted.
> 
>    A static analysis of the IPFIX message format would seem to suggest
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008               [Page 10]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
>    that implementations of it are not particularly prone to slowness;
>    indeed, a template-based data representation is more easily subject
>    to optimization for common cases than representations that embed
>    structural information directly in the data stream (e.g.  XML).
>    However, a full analysis of the impact of using IPFIX messages as a
>    basis for flow data storage on read/write performance will require
>    more implementation experience and performance measurement.
> 
> 
> 5.  Survey of Existing Flow and Trace File Formats

Who selected these formats and why? How was the selection made?

> 5.1.  NetFlow V5/V7

I think we use lowercase v: v5 and v7.

Do you consider that v7 is widely used?

> 
>    One de facto standard for the storage of flow data collected via
>    Cisco NetFlow V5 or V7 is to serialize a stream of "raw" NetFlow
>    datagrams into files.  These NetFlow PDU files consist of a
>    collection of header- prefixed blocks (corresponding to the datagrams
>    as received on the wire) containing fixed-length binary flow records.
>    NetFlow V5 and V7 data may be mixed within a given file, as the
>    header on each datagram defines the NetFlow version of the records
>    following; there is indeed very little difference between the two
>    record formats.
> 
>    NetFlow V5/V7 PDU files are neither extensible nor self-describing;
>    however, their status as a de facto standard means the definition of
>    the data format is well-understood.  Indexing, compression, error
>    detection and correction, authentication, and confidentiality must be
>    handled externally.
> 
> 5.2.  Argus 2
> 
>    QoSient's Argus (as of version 2.0.6) uses a file format based upon a
>    stream of type-and-length prefixed records.  There are two general
>    types of records in this stream, management records and flow records.
>    Management records export flow collection statistics, much like the
>    recommended scoped data records in the IPFIX protocol.  Flow records
>    contain information about a single flow each, and are further typed
>    based upon the protocol of the flow (e.g., IP, ICMP, ARP).  The Argus
>    file format natively spports bidirectional flow export, as each flow
>    record contains both forward and reverse counters.
> 
>    The Argus tools support a transport protocol that simply encapsulates
>    a record stream over a TCP connection.  Transport is collector-
>    initiated; that is, a collector establishes a connection to an
>    exporter in order to read a record stream.
> 
>    Argus files are not self-describing; that is, only the Argus tools
>    themselves encapsulate the definition of each of the record types.
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008               [Page 11]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
>    The Argus file format is not extensible without changing the Argus
>    implementation.  Argus provides no indexing facility for its file
>    format, though records are roughly sorted by record generation time.
>    Compression, error correction, authentication, and confidentiality
>    are handled externally to the format, and are available as with all
>    files.  There is no special support for data obfuscation in the
>    format.
> 
> 5.3.  SiLK
> 
>    The CERT/NetSA SiLK tools use a set of fixed-length binary record
>    formats.  Each file is prefixed with a header which denotes which
>    record format the file is stored in.  These record formats are
>    differentiated by the presence or absence of certain fields; in this
>    way, each format identifier is essentially a short-hand identifier
>    for a template describing the record.  This also implies that only
>    one type of record may be stored in any given file.
> 
>    As with Argus, SiLK files are not self-describing and are not
>    extensible.  SiLK provides no indexing facility, though files are
>    generally stored in flow end time order; and when used for archival
>    storage, information about sensors and flow times appearing in each
>    file is stored in the file path name.  Compression is handled

Actually this can be done for any format here.

>    internally to the file format, and allows the storage of compressed
>    data in a file with uncompressed headers, and a guarantee of
>    compression block boundary alignment with record boundaries.  Error
>    correction, authentication, and confidentiality can be handled
>    externally.  There is no special support for data obfuscation in the

obfuscation? Which IPFIX calls anonymisation?

>    SiLK file format.
> 
> 5.4.  libpcap dumpfile
> 
>    The libpcap dumpfile format is a packet trace format rather than a
>    flow file format, so it does not address any of the requirements
>    outlined above.  However, it is used widely in a use case (data
>    storage and distribution for network measurement research) similar to
>    one addressed by the format proposed in this draft, so we include it
>    here.
> 
>    libpcap dumpfiles consist of a file header containing information
>    common to the whole file (most importantly, the datalink layer, for
>    interpretation of the datalink headers on each frame), followed by a
>    set of raw captured frame records each prefixed by a frame header
>    containing timestamp and length information.  The format is not
>    particularly flexible or self-describing, nor does it need to be:
>    undecoded frames are about as semantically simple as network traffic
>    data can get.
> 
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008               [Page 12]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
>    However, the simplicity and ubiquity of the libpcap dumpfile format
>    has led to its becoming a de facto standard for the distribution of
>    packet trace data for Internet measurement applications.  We propose
>    the file format described in this draft in part as an analogue to the
>    libpcap dumpfile format for flow data.
> 
>    Note that libpcap dumpfiles could be used as a storage format for any
>    unidirectional, datagram-oriented protocol such as IPFIX or NetFlow,
>    simply by storing the captured export session.  However, this has
>    several important drawbacks.  First, the additional per-packet
>    headers provided by pcap are redundant in the case of IPFIX, as
>    length and export time are already available in the IPFIX Message
>    Header.  Second, the link, network, and transport layer headers are
>    stored in a dumpfile; these are not necessary for the successful
>    interpretation of an IPFIX Message, and add additional decode
>    overhead.  Third, a file created by capturing an export session may
>    require additional processing to reassemble fragmented datagrams in
>    the message stream.
> 
> 
> 6.  IPFIX File Format Description
> 
>    An IPFIX file, as defined by this draft and elaborated below, is at
>    its core simply an IPFIX Message stream serialized to some
>    filesystem.  Any valid serialized IPFIX Message stream MUST be
>    accepted by a File Reader as a valid IPFIX file.  In this way, the
>    filesystem is simply treated as another IPFIX Transport alongside
>    SCTP, TCP, and UDP, although one with unusually high latency, as the
>    File Reader and File Writer are not necessarily synchronized in time,
>    unlike IPFIX Collecting and Exporting Processes.

The EP and CP are not synch'd at all.

> 
>    An IPFIX File Reader MUST accept as valid any IPFIX message stream
>    that would be considered valid by one or more of the other defined
>    IPFIX transport layers.  Practically, this means that the union of
>    template management features supported by SCTP, TCP, and UDP MUST be
>    supported in IPFIX Files.  The following requirements apply to IPFIX
>    File Readers:
> 
>    o  File Readers MUST accept IPFIX Messages containing Template Sets,
>       Options Template Sets, and Data Sets within the same message, as
>       with IPFIX over TCP or UDP.
> 
>    o  File Readers MUST accept Template Sets that define templates
>       already defined within the file, as may occur with template
>       retransmission when using IPFIX over UDP as described in section
>       10.3.6 of the IPFIX Protocol draft [I-D.ietf-ipfix-protocol].  In
>       the event of a conflict between a resent definition and a previous
>       definition, the File Reader MUST assume that the new template
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008               [Page 13]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
>       replaces the old, as consistent with UDP template expiration and
>       ID reuse.
> 
>    o  File Readers MUST accept Template Withdrawals as described in
>       section 8 of the IPFIX Protocol draft [I-D.ietf-ipfix-protocol],
>       provided that the Template to be withdrawn is defined, as is the
>       case with IPFIX over TCP and SCTP.

I'm thinking that FILE is essentially a layer below EP / CP but above 
transport, something like this:

	+------+        +------+
	|  EP  |        |  CP  |
	+------+--------+------+
	|         File         |
	+----------------------+
	|       transport      |
	+----------------------+

> 
>    However, for representation simplicity and read performance, File
>    Writers SHOULD use the following template and scope management
>    strategy:
> 
>    o  File Writers SHOULD emit Template Sets and Options Template Sets

I think this is a MUST, since data ahead of the necessary Templates 
could be discarded and is therefore of no value. Or put another way, if 
the Template is in the file somewhere, rewrite the file to put the 
Template at the start.

>       to appear at the beginning of the file, before any Data Sets, to
>       ensure all Templates are available and can be inspected before any
>       data is read.  If the set of Templates used within a File is not
>       known when the File Writer starts writing the File, the File
>       Writer MAY interleave Template Sets and Options Template Sets with
>       Data Sets within the File, but SHOULD write each Template Set or
>       Options Template Set before any Data Set described by that
>       Template.
> 
>    o  File Writers SHOULD emit special Data Records described by Options
>       Templates at the beginning of the file after Template Sets and
>       Options Template Sets as above, but before any other Data Records,
>       in the following order:
> 
>       *  Time window order records described by the File Time Window
>          Options Template as defined in section 6.2.3 below; followed by
> 
>       *  commonPropertiesId definitions as described in "Reducing
>          Redundancy in IPFIX and PSAMP Reports"
>          [I-D.ietf-ipfix-reducing-redundancy]; followed by
> 
>       *  Semantics records as described in "Extended Type Information
>          for IPFIX Enterprise-Specific Information Elements"
>          [I-D.boschi-ipfix-extended-type]; followed by
> 
>       *  Anonymization notation records described by the Template
>          Anonymization Options Template as defined in section 6.2.2
>          below.
> 
>    o  File Writers SHOULD emit Data Records described by Options

Again, MUST.

>       Templates to appear in the file before any Data Records which
>       depend on the scopes defined by those options.
> 
>    o  File Writers SHOULD use Template Withdrawals to withdraw Templates

Again, MUST.

>       if template IDs need to be reused.  In this case, the new

You'd have to generate them for UDP, because they won't exist.

> 
> 
> 
> Trammell, et al.        Expires January 10, 2008               [Page 14]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
>       Templates reusing those IDs SHOULD appear directly in the file
>       after the Template Withdrawals making the IDs available for reuse.
>       Template Withdrawals SHOULD NOT be used unless necessary to reuse
>       template IDs.

Why?

> 
>    Each IPFIX File is generally synonymous with a single Transport
>    Session.  File Writers SHOULD store the Templates and Options
>    required to decode the data within the File in the File itself, and
>    File Readers SHOULD NOT use Templates or Options defined in one file
>    to decode or interpret Data Sets in another.

What if I want to save each SCTP stream to a different file?

> 
>    However, some applications, particularly those storing large
>    collections of data over long periods of time, may benefit from the
>    ability to treat a collection of IPFIX Files as a single Transport
>    Session.  A File Reader MAY be configurable to treat a collection of
>    Files (e.g., all the files in a directory) as a single Transport
>    Session.  However, a File Reader MUST NOT treat a single IPFIX File
>    as containing multiple Transport Sessions.

So we need a new file if/when the Transport Session shuts down?

> 
>    File Writers SHOULD write IPFIX Messages within an IPFIX File in
>    ascending Export Time order.  If a File Writer is writing data

Here, ascending order. Below...

>    collected from an IPFIX Collecting Process, the Export Time SHOULD be
>    the export time as reported by the remote IPFIX Exporting Process;
>    otherwise, the Export Time should be the time at which the message
>    was written to the file.
> 
>    By default, File Writers MAY write records to an IPFIX File in any
>    order.  However, File Writers that write flow records to an IPFIX

... any order. Confusing.

>    File in flowStartTime or flowEndTime order SHOULD be consistent in
>    this ordering within each File.

Why? And which are we recommending here, if it's a standard?

> 
>    If an IPFIX File uses the technique described in "Reducing Redundancy
>    in IPFIX and PSAMP Reports" [I-D.ietf-ipfix-reducing-redundancy] AND
>    all of the non-Options Templates in the File contain the

Do you mean "contain *only* the" ?

>    commonPropertiesId Information Element, a File Reader MAY assume the
>    set of commonPropertiesId definitions provides a complete table of
>    contents for the file, for searching purposes.
> 
> 6.1.  Recommended Information Elements for IPFIX Files
> 
>    The following information elements are used by the options templates
>    below to allow IPFIX message streams to meet the requirements
>    outlined above without extension to the message format or protocol.
>    IPFIX File Readers and Writers SHOULD support these Information

MUST?

>    Elements as defined below.
> 
>    In addition, IPFIX File Readers and Writers SHOULD support the
>    Information Elements defined in "Extended Type Information for IPFIX
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008               [Page 15]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
>    Enterprise-Specific Information Elements"
>    [I-D.boschi-ipfix-extended-type] in order to support self-description
>    of Enterprise-Specific Information Elements and anonymization
>    notation.
> 
> 6.1.1.  collectionTimeMilliseconds
> 
>    Description:   The absolute timestamp at which the data within the
>       scope containing this IE was received by a Collecting Process.

When an Exporting Process writes to a file, there's no CP time.

>       This IE SHOULD be bound to its containing IPFIX Message via an
>       options record and the messageScope IE, as defined below.

Say where, ie 6.1.6.

> 
>    Abstract Data Type:   dateTimeMilliseconds
> 
>    ElementId:   TBD1
> 
>    Status:   Proposed
> 
> 6.1.2.  informationElementAnonymizationType

It's a flag, not a type.

> 
>    Description:   A description of the anonymization status of an IPFIX
>       information element within a template.  If this field is FALSE,

"Template"

>       the corresponding IE is not anonymized; to the best ability of the
>       Exporting Process to determine, it represents a real value.  If
>       this field is TRUE, the corresponding IE is anonymized; to the
>       best ability of the Exporting Process to determine, it represents
>       a value that has been transformed to maintain privacy.  Note that
>       if no informationElementAnonymizationType is specified for an
>       information element, it is assumed to be FALSE, or not anonymized.

"Information Element"

> 
>    Abstract Data Type:   boolean
> 
>    ElementId:   TBD2
> 
>    Status:   Proposed
> 
> 6.1.3.  maxExportSeconds
> 
>    Description:   The absolute Export Time of the latest IPFIX message
>       within the scope containing this IE.  This IE SHOULD be bound to
>       its containing IPFIX Transport Session (i.e., File) via an options
>       record and the sessionScope IE, as defined below, and SHOULD

Say where, ie 6.1.9.

>       appear only once in a given IPFIX File.
> 
>    Abstract Data Type:   dateTimeSeconds
> 
> 
> 
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008               [Page 16]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
>    ElementId:   TBD3
> 
>    Status:   Proposed
> 
>    Units:   seconds

Does this give good granularity?

> 
> 6.1.4.  maxFlowEndSeconds
> 
>    Description:   The latest absolute timestamp of the last packet
>       within any Flow within the scope containing this IE, rounded up to
>       the second.  This IE SHOULD be bound to its containing IPFIX
>       Transport Session (i.e., File) via an options record and the
>       sessionScope IE, as defined below, and SHOULD appear only once in
>       a given IPFIX File.
> 
>    Abstract Data Type:   dateTimeSeconds
> 
>    ElementId:   TBD4
> 
>    Status:   Proposed
> 
>    Units:   seconds

Again, does this give good granularity?

> 
> 6.1.5.  messageMD5Checksum
> 
>    Description:   The MD5 checksum of the IPFIX Message containing this
>       record.  This IE SHOULD be bound to its containing IPFIX Message
>       via an options record and the messageScope IE, as defined below,

Eeuuwww. The message should directly contain its own csum IE.

For "below", again say where.

>       and SHOULD appear only once in a given IPFIX Message.  To

Split to a new paragraph here.

>       calculate the value of this IE, first buffer the containing IPFIX
>       Message, setting the value of this IE to all zeroes.  Then
>       caluclate the MD5 checksum of the resulting buffer as defined in
>       RFC 1321 [RFC1321], place the resulting value in this IE, and
>       export the buffered message.
> 
>    Abstract Data Type:   octetArray (16 bytes)
> 
>    ElementId:   TBD5
> 
>    Status:   Proposed
> 
>    Reference:   RFC 1321, The MD5 Message-Digest Algorithm [RFC1321]
> 
> 6.1.6.  messageScope
> 
> 
> 
> 
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008               [Page 17]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
>    Description:   The presence of this Information Element as scope in
>       an Options Template signifies that the options described by the
>       Template apply to the IPFIX Message that contains them.  It is
>       defined for general purpose message scoping of options, and
>       proposed specifically to allow the attachment a checksum to a
>       message via IPFIX Options.  The value of this Information Element
>       MUST be written as 0 by the File Writer or Exporting Process.  The
>       value of this Information Element MUST be ignored by the File
>       Reader or the Collecting Process.
> 
>    Abstract Data Type:   octet

The size should really be zero, right?

> 
>    ElementId:   TBD6
> 
>    Status:   Proposed
> 
> 6.1.7.  minExportSeconds
> 
>    Description:   The absolute Export Time of the earliest IPFIX message
>       within the scope containing this IE.  This IE SHOULD be bound to
>       its containing IPFIX Transport Session (i.e., File) via an options
>       record and the sessionScope IE, as defined below, and SHOULD
>       appear only once in a given IPFIX File.
> 
>    Abstract Data Type:   dateTimeSeconds
> 
>    ElementId:   TBD7
> 
>    Status:   Proposed
> 
>    Units:   seconds
> 
> 6.1.8.  minFlowStartSeconds
> 
>    Description:   The earliest absolute timestamp of the first packet
>       within any Flow within the scope containing this IE, rounded down
>       to the second.  This IE SHOULD be bound to its containing IPFIX
>       Transport Session (i.e., File) via an options record and the
>       sessionScope IE, as defined below, and SHOULD appear only once in
>       a given IPFIX File.
> 
>    Abstract Data Type:   dateTimeSeconds
> 
>    ElementId:   TBD8
> 
> 
> 
> 
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008               [Page 18]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
>    Status:   Proposed
> 
>    Units:   seconds
> 
> 6.1.9.  sessionScope
> 
>    Description:   The presence of this Information Element as scope in
>       an Options Template signifies that the options described by the
>       Template apply to the IPFIX Transport Session that contains them.
>       Note that as all options are implicitly scoped to Transport
>       Session and Observation Domain, this Information Element is
>       equivalent to a "null" scope.  It is defined for general purpose
>       session scoping of options, and proposed specifically to allow the
>       attachment of time window to a file via IPFIX Options.  The value

Split to a new paragraph.

>       of this Information Element MUST be written as 0 by the File
>       Writer or Exporting Process.  The value of this Information
>       Element MUST be ignored by the File Reader or the Collecting
>       Process.
> 
>    Abstract Data Type:   octet

Again, the size should really be zero, right?

> 
>    ElementId:   TBD9
> 
>    Status:   Proposed
> 
> 6.2.  Recommended Options Templates for IPFIX Files
> 
>    The following Options Templates allow IPFIX message streams to meet
>    the requirements outlined above without extension to the message
>    format or protocol.  They are defined in terms of existing
>    Information Elements defined in the IPFIX Information Model
>    [I-D.ietf-ipfix-info], the extended type Information Elements defined
>    in "Extended Type Information for IPFIX Enterprise-Specific
>    Information Elements" [I-D.boschi-ipfix-extended-type], as well as
>    Information Elements defined in the section above.  IPFIX File

Say which section above.

>    Readers and Writers SHOULD support these options templates as defined
>    below.
> 
>    In addition, IPFIX File Readers and Writers SHOULD support the
>    Options Templates defined in "Extended Type Information for IPFIX
>    Enterprise-Specific Information Elements"
>    [I-D.boschi-ipfix-extended-type] in order to support self-description
>    of enterprise-specific Information Elements.
> 
> 6.2.1.  Message Checksum Options Template
> 
>    The Message Checksum Options Template specifies the structure of a
>    Data Record for attaching an MD5 message checksum to an IPFIX
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008               [Page 19]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
>    Message.  An MD5 message checksum as described MAY be used if long-
>    term data integrity is important to the application.  The described
>    Data Record MUST appear only once per IPFIX Message.
> 
>    The template SHOULD contain the following Information Elements:
> 
>    +--------------------+----------------------------------------------+
>    | IE                 | Description                                  |
>    +--------------------+----------------------------------------------+
>    | messageScope       | A marker denoting this Option applies to the |
>    |                    | whole IPFIX message; content is ignored.     |
>    |                    | This Information Element MUST be defined as  |
>    |                    | a Scope Field.                               |

Consider inserting some vertical whitespace here to make these more 
readable.

>    | messageMD5Checksum | The MD5 checksum of the containing IPFIX     |
>    |                    | Message.                                     |
>    +--------------------+----------------------------------------------+
> 
> 6.2.2.  Template Anonymization Options Template
> 
>    The Template Anonymization Options Template specifies the structure
>    of a Data Record for attaching anonymization notation information to
>    Information Elements in specified Template Records.  A Data Record
>    described by this Template SHOULD appear for each Information Element
>    within a Template known by the Exporting Process or File Writer to
>    contain anonymized data.
> 
>    The template SHOULD contain the following Information Elements:
> 
>    +-------------------------------------+-----------------------------+
>    | IE                                  | Description                 |
>    +-------------------------------------+-----------------------------+
>    | templateId                          | The Template ID of the      |
>    |                                     | template this record        |
>    |                                     | describes; it is assumed to |
>    |                                     | be valid within the         |
>    |                                     | Observation Domain ID of    |
>    |                                     | the containing IPFIX        |
>    |                                     | Message, and MUST identify  |
>    |                                     | a Template that has already |
>    |                                     | been exported.  This        |
>    |                                     | Information Element MUST be |
>    |                                     | defined as a Scope Field.   |
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008               [Page 20]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
>    | informationElementId                | The Information Element     |
>    |                                     | identifier of the           |
>    |                                     | Information Element within  |
>    |                                     | the specified Template this |
>    |                                     | record describes.  This     |
>    |                                     | Information Element MUST be |
>    |                                     | defined as a Scope Field.   |
>    | privateEnterpriseNumber             | The Private Enterprise      |
>    |                                     | number of the Information   |
>    |                                     | Element within the          |
>    |                                     | specified Template this     |
>    |                                     | record describes.  May be 0 |
>    |                                     | if this record describes a  |
>    |                                     | public Information Element. |
>    |                                     | This Information Element    |
>    |                                     | MUST be defined as a Scope  |
>    |                                     | Field.                      |

Put the PEN last so it can be omitted if zero.

>    | informationElementAnonymizationType | The anonymization type of   |
>    |                                     | the specified Information   |
>    |                                     | Element.                    |
>    +-------------------------------------+-----------------------------+
> 
> 6.2.3.  File Time Window Options Template
> 
>    The File Time Window Options Template specifies the structure of a
>    Data Record for attaching a time window to an IPFIX File; this Data
>    Record is referred to as a time window record.  A time window record
>    defines the earliest flow start time and the latest flow end time of
>    the flow records within a File.  One and only one time window record
>    MAY appear within an IPFIX File if the time window information is
>    available; a File Writer MUST NOT write more than one time window
>    record to an IPFIX File.  A File Writer that writes a time window
>    record to a File MUST NOT write any Flow with a start time before the
>    beginning of the window or an end time after the end of the window to
>    that File.
> 
>    The template SHOULD contain the following Information Elements:
> 
>    +---------------------+---------------------------------------------+
>    | IE                  | Description                                 |
>    +---------------------+---------------------------------------------+
>    | sessionScope        | A marker denoting this Option applies to    |
>    |                     | the whole IPFIX Transport Session (i.e.,    |
>    |                     | IPFIX File); content is ignored.  This      |
>    |                     | Information Element MUST be defined as a    |
>    |                     | Scope Field.                                |
> 
> 
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008               [Page 21]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
>    | minFlowStartSeconds | The start time of the earliest flow in the  |
>    |                     | Transport Session (i.e., File) in epoch     |
>    |                     | seconds.                                    |
>    | maxFlowEndSeconds   | The end time of the latest flow in the      |
>    |                     | Transport Session (i.e., File) in epoch     |
>    |                     | seconds.                                    |
>    +---------------------+---------------------------------------------+
> 
> 6.2.4.  Export Session Details Options Template
> 
>    The Export Session Details Options Template specifies the structure
>    of a Data Record for recording the details of an IPFIX Transport
>    Session in an IPFIX File.  It is intended for use in storing a single
>    complete IPFIX Transport Session in a single IPFIX File.  The
>    described Data Record SHOULD appear only once in a given IPFIX File.
> 
>    The template SHOULD contain the following Information Elements,
>    subject to applicability as noted on each Information Element:
> 
>    +----------------------------+--------------------------------------+
>    | IE                         | Description                          |
>    +----------------------------+--------------------------------------+
>    | sessionScope               | A marker denoting this Option        |
>    |                            | applies to the whole IPFIX Transport |
>    |                            | Session (i.e., IPFIX File); content  |
>    |                            | is ignored.  This Information        |
>    |                            | Element MUST be defined as a Scope   |
>    |                            | Field.                               |
>    | exporterIPv4Address        | IPv4 address of the IPFIX Exporting  |
>    |                            | Process from which the Messages in   |
>    |                            | this Transport Session were          |
>    |                            | received.  Present only for          |
>    |                            | Exporting Processes with an IPv4     |
>    |                            | interface.  For multi-homed SCTP     |
>    |                            | associations, this SHOULD be the     |
>    |                            | primary path endpoint address of the |
>    |                            | Exporting Process.                   |
>    | exporterIPv6Address        | IPv6 address of the IPFIX Exporting  |
>    |                            | Process from which the Messages in   |
>    |                            | this Transport Session were          |
>    |                            | received.  Present only for          |
>    |                            | Exporting Processes with an IPv6     |
>    |                            | interface.  For multi-homed SCTP     |
>    |                            | associations, this SHOULD be the     |
>    |                            | primary path endpoint address of the |
>    |                            | Exporting Process.                   |
> 
> 
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008               [Page 22]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
>    | exporterTransportPort      | The source port from which the       |
>    |                            | Messages in this Transport Session   |
>    |                            | were received.                       |
>    | collectorIPv4Address       | IPv4 address of the IPFIX Collecting |
>    |                            | Process which received the Messages  |
>    |                            | in this Transport Session.  Present  |
>    |                            | only for Collecting Processes with   |
>    |                            | an IPv4 interface.  For multi-homed  |
>    |                            | SCTP associations, this SHOULD be    |
>    |                            | the primary path endpoint address of |
>    |                            | the Collecting Process.              |
>    | collectorIPv6Address       | IPv6 address of the IPFIX Collecting |
>    |                            | Process which received the Messages  |
>    |                            | in this Transport Session.  Present  |
>    |                            | only for Collecting Processes with   |
>    |                            | an IPv6 interface.  For multi-homed  |
>    |                            | SCTP associations, this SHOULD be    |
>    |                            | the primary path endpoint address of |
>    |                            | the Collecting Process.              |
>    | collectorTransportPort     | The destination port on which the    |
>    |                            | Messages in this Transport Session   |
>    |                            | were received.                       |
>    | collectorTransportProtocol | The IP Protocol Identifier of the    |
>    |                            | transport protocol used to transport |
>    |                            | Messages within this Transport       |
>    |                            | Session.                             |

However, it's not specific to the Collector.

>    | collectorProtocolVersion   | The version of the IPFIX Protocol    |
>    |                            | used to transport Messages within    |
>    |                            | this Transport Session.              |

And again. Also below.

>    | minExportSeconds           | The Export Time of the first Message |
>    |                            | in the Transport Session.            |
>    | maxExportSeconds           | The Export Time of the last Message  |
>    |                            | in the Transport Session.            |
>    +----------------------------+--------------------------------------+
> 
> 6.2.5.  Message Details Options Template
> 
>    The Message Details Options Template specifies the structure of a
>    Data Record for attaching additional export details to an IPFIX
>    Message.  These details include the time at which a message was
>    received and information about the export and collection
>    infrastructure used to transport the Message.
> 
>    The template SHOULD contain the following Information Elements,
>    subject to applicability as noted for each Information Element.  Note
>    that when used in conjunction with the Export Session Details Options
>    Template, when storing a single complete IPFIX Transport Session in
>    an IPFIX File, this template SHOULD contain only the messageScope and
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008               [Page 23]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
>    collectionTimeMilliseconds Information Elements.
> 
>    +----------------------------+--------------------------------------+
>    | IE                         | Description                          |
>    +----------------------------+--------------------------------------+
>    | messageScope               | A marker denoting this Option        |
>    |                            | applies to the whole IPFIX message;  |
>    |                            | content is ignored.  This            |
>    |                            | Information Element MUST be defined  |
>    |                            | as a Scope Field.                    |
>    | collectionTimeMilliseconds | The absolute time at which this      |
>    |                            | Message was received by the IPFIX    |
>    |                            | Collecting Process.                  |
>    | exporterIPv4Address        | IPv4 address of the IPFIX Exporting  |
>    |                            | Process from which the Messages in   |
>    |                            | this Transport Session were          |
>    |                            | received.  Present only for          |
>    |                            | Exporting Processes with an IPv4     |
>    |                            | interface, and if this information   |
>    |                            | is not available via the Export      |
>    |                            | Session Details Options Template.    |
>    |                            | For multi-homed SCTP associations,   |
>    |                            | this SHOULD be the primary path      |
>    |                            | endpoint address of the Exporting    |
>    |                            | Process.                             |
>    | exporterIPv6Address        | IPv6 address of the IPFIX Exporting  |
>    |                            | Process from which the Messages in   |
>    |                            | this Transport Session were          |
>    |                            | received.  Present only for          |
>    |                            | Exporting Processes with an IPv6     |
>    |                            | interface, and if this information   |
>    |                            | is not available via the Export      |
>    |                            | Session Details Options Template.    |
>    |                            | For multi-homed SCTP associations,   |
>    |                            | this SHOULD be the primary path      |
>    |                            | endpoint address of the Exporting    |
>    |                            | Process.                             |
>    | exporterTransportPort      | The source port from which the       |
>    |                            | Messages in this Transport Session   |
>    |                            | were received.  Present only if this |
>    |                            | information is not available via the |
>    |                            | Export Session Details Options       |
>    |                            | Template.                            |
> 
> 
> 
> 
> 
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008               [Page 24]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
>    | collectorIPv4Address       | IPv4 address of the IPFIX Collecting |
>    |                            | Process which received the Messages  |
>    |                            | in this Transport Session.  Present  |
>    |                            | only for Collecting Processes with   |
>    |                            | an IPv4 interface, and if this       |
>    |                            | information is not available via the |
>    |                            | Export Session Details Options       |
>    |                            | Template.  For multi-homed SCTP      |
>    |                            | associations, this SHOULD be the     |
>    |                            | primary path endpoint address of the |
>    |                            | Collecting Process.                  |
>    | collectorIPv6Address       | IPv6 address of the IPFIX Collecting |
>    |                            | Process which received the Messages  |
>    |                            | in this Transport Session.  Present  |
>    |                            | only for Collecting Processes with   |
>    |                            | an IPv6 interface, and if this       |
>    |                            | information is not available via the |
>    |                            | Export Session Details Options       |
>    |                            | Template.  For multi-homed SCTP      |
>    |                            | associations, this SHOULD be the     |
>    |                            | primary path endpoint address of the |
>    |                            | Collecting Process.                  |
>    | collectorTransportPort     | The destination port on which the    |
>    |                            | Messages in this Transport Session   |
>    |                            | were received.  Present only if this |
>    |                            | information is not available via the |
>    |                            | Export Session Details Options       |
>    |                            | Template.                            |
>    | collectorTransportProtocol | The IP Protocol Identifier of the    |
>    |                            | transport protocol used to transport |
>    |                            | Messages within this Transport       |
>    |                            | Session.  Present only if this       |
>    |                            | information is not available via the |
>    |                            | Export Session Details Options       |
>    |                            | Template.                            |
>    | collectorProtocolVersion   | The version of the IPFIX Protocol    |
>    |                            | used to transport Messages within    |
>    |                            | this Transport Session.  Present     |
>    |                            | only if this information is not      |
>    |                            | available via the Export Session     |
>    |                            | Details Options Template.            |
>    +----------------------------+--------------------------------------+
> 
> 6.3.  Recommended Compression Error Resilience Strategy
> 
>    Note that, since any file may be compressed and decompressed with a
>    variety of widely available tools implementing a variety of
>    compression standards (both specified and de facto), compression of
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008               [Page 25]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
>    IPFIX File data can be accomplished externally.  However, compression
>    at the file level is not particularly resilient to errors; in the
>    worst case, a single bit error in a stream-compressed file may result
>    in the loss of the entire file.
> 
>    To limit the impact of errors on the recoverability of compressed
>    data, we recommend the use of block compression where possible.
>    Ideally, the block compression algorithm should support the
>    identification and isolation of blocks containing errors; bzip2 is an
>    example of such a block compressor.
> 
>    Since the block boundary of a block-compressed IPFIX File may fall in
>    the middle of an IPFIX Message, resynchronization of an IPFIX Message
>    stream by a File Reader after a compression error requires some care.
>    The beginning of an IPFIX Message may be identified by its header
>    signature (the Version field of the Message Header, 0x00 0x0A,
>    followed by a 16-bit Message Length), but simply searching for the
>    first occurance of the Version field is insufficient, since these two
>    bytes may occur in valid IPFIX Template or Data Sets.
> 
>    Therefore, we propose the following algorithm for File Readers to
>    resynchronize an IPFIX Message Stream after skipping a compressed
>    block containing errors:
> 
>    1.  Search after the error for the first occurance of the byte string
>        0x00, 0x0A (the IPFIX Message Header Version field.)
> 
>    2.  Treat this field as the beginning of a candidate IPFIX Message.
>        Read the two bytes following the Version field as a Message
>        Length, and seek to that offset from the beginning of the
>        candidate IPFIX Message.
> 
>    3.  If the first two bytes after the candidate IPFIX Message are
>        0x00, 0x0A (i.e., the IPFIX Message Header Version field of the
>        next message in the stream), or if the end of the file is reached
>        precisely at the end of the candidate IPFIX Message, presume that
>        the candidate IPFIX Message is valid, and begin reading the IPFIX
>        File from the start of the candidate IPFIX Message.

I think this is insufficient: one should iterate over the entire message 
to the end to be sure.

> 
>    4.  If not, or if the seek reaches end-of-file or another block
>        containing errors before finding the end of the candidate
>        message, go back to step 1, starting the search two bytes from
>        the start of the candidate IPFIX Message.
> 
>    The algorithm above will improperly identify a non-message as a
>    message approximately 1 in 2^32 times, assuming random IPFIX data.
>    It may be expanded to consider multiple candidate IPFIX Messages in
>    order to increase reliability.

It should be, since the random nature of the data means it'll probably 
fail 9 times out of 10.

> 
> 
> 
> Trammell, et al.        Expires January 10, 2008               [Page 26]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
>    In applications (e.g. archival storage) in which error resilience is
>    very important, File Writers SHOULD use block compression algorithms,
>    and MAY attempt to align IPFIX Messages within compression blocks to
>    ease resynchronization after errors, if such is supported by the
>    chosen block compressor.  File Readers SHOULD use the
>    resynchronization algorithm above to minimize data loss due to
>    compression errors.
> 
> 6.4.  Recommended Encryption Error Resilience Strategy
> 
>    File-level encryption has error resiliency issues similar to file-
>    level compression.  Single bit errors in the encrypted data stream
>    can result in unreadability of the entire remaining file, dependent
>    on the encryption method used.  The use of CBC (Cipher Block
>    Chaining) mode, which suffers from this low error resilience, is
>    relatively common.
> 
>    In applications (e.g. archival storage) in which error resilience is
>    very important, File Writers SHOULD use a stream cipher, for example
>    a block cipher in OFB (Output Feedback) mode (often referred to as
>    stream mode) instead of modes like CBC when encrypting, since errors
>    are not amplified by stream ciphers: A single-bit error in the
>    ciphertext results in a single bit error in the plaintext.
>    Alternatively File Writers SHOULD use any other cipher which can
>    resynchronize after bit errors.  An example is a block cipher in CBC
>    mode that is reinitialized after a specific amount of data has been
>    encrypted.  The maximum data loss per bit-error is then up to the
>    next reinitialization point.  In this case, File Writers SHOULD also
>    use the Message Checksum Options Template to attach a checksum to
>    each IPFIX Message in the IPFIX File, in order to support the
>    recognition of errors in the decrypted data.
> 
> 
> 7.  Applicability of IPFIX Files
> 
>    This section describes the specific applicability of IPFIX Files to
>    various use cases.  IPFIX Files are particularly useful in a flow
>    collection and processing infrastructure using IPFIX for flow export.
>    We explore the applicability and provide guidelines for using IPFIX
>    files during the implementation and operation of IPFIX Collecting
>    Processes.
> 
> 7.1.  Testing IPFIX Collecting Processes
> 
>    IPFIX Files can be used to store IPFIX Messages for the testing of
>    IPFIX Collecting Processes.  A variety of test cases may be stored in
>    IPFIX Files.  First, IPFIX data sets collected in real network
>    environments and stored in an IPFIX File can be used as input to
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008               [Page 27]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
>    check the behavior of new or extended implementations of IPFIX
>    Collectors.  Furthermore, IPFIX Files could be used to validate the
>    operation of a given IPFIX Collecting Process in a new environment,
>    i.e., to test with recorded IPFIX data from the target network before
>    installing the Collecting Process in the network.
> 
>    The IPFIX File format can also be used to store artificial, non-
>    compliant reference messages for specific Collecting Process test
>    cases.  Examples for such test cases are sets of IPFIX records with
>    undefined Information Elements, Data Records described by missing
>    Templates, or incorrectly framed messages or data sets.
>    Representative error handling test cases are defined in "IPFIX
>    Testing" [I-D.ietf-ipfix-testing].
> 
>    Furthermore, fast replay of IPFIX records stored in a file can be
>    used for stress/load tests (e.g., high rate of incoming Data Records,
>    large Templates with high Information Element counts), as described
>    in "IPFIX Testing" [I-D.ietf-ipfix-testing].  The provisioning and
>    use of a set of reference files for testing simplifies the
>    performance of tests and increases the comparability of test results.
> 
>    Note that an extremely simple IPFIX Exporting Process may be crafted
>    for testing purposes by simply reading an IPFIX File and transmitting
>    it directly to a Collecting Process.  Similarly, an extremely simple
>    Collecting Process may be crafted for testing purposes by simply
>    accepting connections and/or IPFIX Messages from Exporting Processes
>    and writing the session's message stream to an IPFIX File.
> 
> 7.2.  Storage of IPFIX-collected Flow Data
> 
>    IPFIX Files can also, naturally, be used to store flow data collected
>    by an IPFIX Collecting Process; indeed, this was one of the primary
>    initial motivations behind the file format described within this
>    document.  Using IPFIX Files as such allows IPFIX implementations to
>    leverage substantially the same code for flow export and flow
>    storage.  In addition, the storage of single Transport Sessions in
>    IPFIX Files is particularly important for network measurement
>    research, allowing repeatability of experiments by providing a format
>    for the storage and exchange of IPFIX flow trace data much as the
>    libpcap format is used for experiments on packet trace data.
> 
>    As noted in the section above, the simplest way for a Collecting
>    Process to store the data collected in a single Transport Session is
>    to simply write the incoming IPFIX Messages to a file as they are
>    read.  However, while the resulting files are valid IPFIX Files, they
>    are lacking information about the IPFIX Transport Session used to
>    export them, such as the network addresses of the Exporting and
>    Collecting Processes and the protocols used to transport them.  An
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008               [Page 28]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
>    IPFIX File Writer MAY store a single IPFIX Transport Session in an
>    IPFIX File and record information about the Transport Session using
>    the Export Session Details Options Template described above.
> 
>    Additional per-Message information MAY be recorded by the File Writer
>    using the Message Details Options Template described above.  Per-
>    message information includes the time at which each IPFIX Message was
>    received at the Collecting Process, and can be used to resend IPFIX
>    Messages while keeping the original measurement plane traffic
>    profile.  This Options Template also allows the storage of the export
>    session metainformation provided the Export Session Details Options

Isn't it "meta information" ?

>    Template, for storing information from multiple Transport Sessions in
>    the same IPFIX File.
> 
> 
> 8.  Examples
> 
>    [TODO in revision -05 or later]
> 
> 
> 9.  Security Considerations
> 
>    The IPFIX-based file format itself does not directly introduce
>    security issues.  Rather it is used to store information which may
>    for privacy or business issues be considered sensitive.  The file
>    format must therefore provide appropriate procedures to guarantee the
>    integrity and confidentiality of the stored information.

The OS or storage system could also do this.

P.

> 
>    The underlying protocol used to exchange the information that will be
>    stored using the format proposed in this document must as well apply
>    appropriate procedures to guarantee the integrity and confidentiality
>    of the exported information.  Such issues are addressed in separate
>    documents, specifically in the IPFIX Protocol
>    [I-D.ietf-ipfix-protocol].
> 
> 
> 10.  IANA Considerations
> 
>    This document specifies the creation of several new IPFIX Information
>    Elements in the IPFIX Information Element registry located at
>    http://www.iana.org/assignments/ipfix, as defined in section 6.1
>    above.  IANA has assigned the following Information Element numbers
>    for their respective Information Elements as specified below:
> 
>    o  Information Element number TBD1 for the collectionTimeMilliseconds
>       Information Element.
> 
> 
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008               [Page 29]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
>    o  Information Element number TBD2 for the
>       informationElementAnonymizationType Information Element.
> 
>    o  Information Element number TBD3 for the maxExportSeconds
>       Information Element.
> 
>    o  Information Element number TBD4 for the maxFlowEndSeconds
>       Information Element.
> 
>    o  Information Element number TBD5 for the messageMD5Checksum
>       Information Element.
> 
>    o  Information Element number TBD6 for the messageScope Information
>       Element.
> 
>    o  Information Element number TBD7 for the minExportSeconds
>       Information Element.
> 
>    o  Information Element number TBD8 for the minFlowStartSeconds
>       Information Element.
> 
>    o  Information Element number TBD9 for the sessionScope Information
>       Element.
> 
>    [NOTE for IANA: The text TBD1, TBD2, TBD3, TBD4, TBD5, TBD6, TBD7,
>    TBD8, and TBD9 should be replaced with the respective assigned
>    Information Element numbers where they appear in this document.]
> 
> 
> 11.  Acknowledgements
> 
>    Thanks to Maurizio Molina, Tom Kosnar, Andreas Kind, and Andrew
>    Johnson for technical assistance with the requirements and their
>    implementation within this specification.
> 
> 
> 12.  References
> 
> 12.1.  Normative References
> 
>    [I-D.ietf-ipfix-protocol]
>               Claise, B., "Specification of the IPFIX Protocol for the
>               Exchange", draft-ietf-ipfix-protocol-24 (work in
>               progress), November 2006.
> 
>    [I-D.ietf-ipfix-info]
>               Quittek, J., "Information Model for IP Flow Information
>               Export", draft-ietf-ipfix-info-15 (work in progress),
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008               [Page 30]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
>               February 2007.
> 
>    [I-D.ietf-ipfix-reducing-redundancy]
>               Boschi, E., "Reducing Redundancy in IP Flow Information
>               Export (IPFIX) and Packet  Sampling (PSAMP) Reports",
>               draft-ietf-ipfix-reducing-redundancy-04 (work in
>               progress), May 2007.
> 
>    [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
>               April 1992.
> 
>    [I-D.boschi-ipfix-extended-type]
>               Boschi, E., Mark, L., Trammell, B., and T. Zseby,
>               "Extended Type Information for IPFIX Enterprise-Specific
>               Information Elements", draft-boschi-ipfix-ext-type-00
>               (work in progress), June 2007.
> 
> 12.2.  Informative References
> 
>    [I-D.ietf-ipfix-biflow]
>               Trammell, B. and E. Boschi, "Bidirectional Flow Export
>               using IPFIX", draft-ietf-ipfix-biflow-05 (work in
>               progress), June 2007.
> 
>    [I-D.ietf-ipfix-testing]
>               Schmoll, C. and P. Aitken, "IP Flow Information eXport
>               (IPFIX) Testing", draft-ietf-ipfix-testing-01 (work in
>               progress), June 2007.
> 
>    [RFC3917]  Quittek, J., Zseby, T., Claise, B., and S. Zander,
>               "Requirements for IP Flow Information Export (IPFIX)",
>               RFC 3917, October 2004.
> 
>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>               Requirement Levels", BCP 14, RFC 2119, March 1997.
> 
>    [SAINT2007]
>               Trammell, B., Boschi, E., Mark, L., and T. Zseby,
>               "Requirements for a standardized flow storage solution",
>                in Proceedings of the SAINT 2007 workshop on Internet
>               Measurement Technology, Hiroshima, Japan, January 2007.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008               [Page 31]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
> Authors' Addresses
> 
>    Brian H. Trammell
>    CERT Network Situational Awareness
>    Software Engineering Institute
>    4500 Fifth Avenue
>    Pittsburgh, Pennsylvania  15213
>    United States
> 
>    Phone: +1 412 268 9748
>    Email: [email-masked]
> 
> 
>    Elisa Boschi
>    Hitachi Europe SAS
>    Immeuble Le Theleme
>    1503 Route les Dolines
>    06560 Valbonne
>    France
> 
>    Phone: +33 4 89874100
>    Email: [email-masked]
> 
> 
>    Lutz Mark
>    Fraunhofer Institute for Open Communication Systems
>    Kaiserin-Augusta-Allee 31
>    10589 Berlin
>    Germany
> 
>    Phone: +49 30 3463 7306
>    Email: [email-masked]
> 
> 
>    Tanja Zseby
>    Fraunhofer Institute for Open Communication Systems
>    Kaiserin-Augusta-Allee 31
>    10589 Berlin
>    Germany
> 
>    Phone: +49 30 3463 7153
>    Email: [email-masked]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008               [Page 32]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
>    Arno Wagner
>    Swiss Federal Institute of Technology Zurich
>    Gloriastrasse 35
>    8092 Zurich
>    Switzerland
> 
>    Phone: +41 44 632 70 04
>    Email: [email-masked]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008               [Page 33]
> 
> Internet-Draft                 IPFIX Files                     July 2007
> 
> 
> Full Copyright Statement
> 
>    Copyright (C) The IETF Trust (2007).
> 
>    This document is subject to the rights, licenses and restrictions
>    contained in BCP 78, and except as set forth therein, the authors
>    retain all their rights.
> 
>    This document and the information contained herein are provided on an
>    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
>    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
>    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
>    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
>    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
>    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
> 
> 
> Intellectual Property
> 
>    The IETF takes no position regarding the validity or scope of any
>    Intellectual Property Rights or other rights that might be claimed to
>    pertain to the implementation or use of the technology described in
>    this document or the extent to which any license under such rights
>    might or might not be available; nor does it represent that it has
>    made any independent effort to identify any such rights.  Information
>    on the procedures with respect to rights in RFC documents can be
>    found in BCP 78 and BCP 79.
> 
>    Copies of IPR disclosures made to the IETF Secretariat and any
>    assurances of licenses to be made available, or the result of an
>    attempt made to obtain a general license or permission for the use of
>    such proprietary rights by implementers or users of this
>    specification can be obtained from the IETF on-line IPR repository at
>    http://www.ietf.org/ipr.
> 
>    The IETF invites any interested party to bring to its attention any
>    copyrights, patents or patent applications, or other proprietary
>    rights that may cover technology that may be required to implement
>    this standard.  Please address the information to the IETF at
>    [email-masked].
> 
> 
> Acknowledgment
> 
>    Funding for the RFC Editor function is provided by the IETF
>    Administrative Support Activity (IASA).
> 
> 
> 
> 
> 
> Trammell, et al.        Expires January 10, 2008               [Page 34]
> 
> 

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix