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

[ATSUSHI KOBAYASHI <[e-mail]>]

Dear all, Nevil,

I checked the draft, I found some comments and editorial issue.
Please see in-line.

Regards, Atsushi
> 
> 
> 
> 
> 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
>                                     

snip 

> 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 bidirectional flow in [RFC5103], a
>    method for the definition and export of complex data structures in
>    [RFC6313], and the specification of the Protocol for IPFIX Mediations
>    [IPFIX-MED-PROTO] based on the IPIFX Mediation Framework [RFC6183]. 
> 
>    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
>    IPFIX and PSAMP compliant devices using the NETCONF protocol, while
>    the [RFC5815bis] specifies a MIB module for monitoring.  

Please replace it within entire document.
s/RFC5815bis/RFC6615/

snip

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

snip

>    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

Comment#1:

Why don't you add "frames" to the above sentence?

>       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;
>  
> 
> 
snip


> 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 and Template Withdrawals withdrawing them)
>    using the Export Time field in the IPFIX Message Header.
> 
>    An Exporting Process MUST NOT export a Data Set described by a new

Comment#2:
It uses two ways; "defined by a new Template", or "described by a new Template".
It prefers one way within entire document.

>    Template in an IPFIX Message with an Export Time before the Export
>    Time of the IPFIX Message containing that Template. If a new Template
>    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 the IPFIX Message containing the Template Withdrawal
>    withdrawing that Template.
> 

Comment#3:

I could not understand the following paragraph. If you want to describe
another way, please explain it in more detail.

>    Put another way, a Template only describes Records contained in IPFIX
>    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.
> 
>    Collecting Processes MAY implement a buffer to handle out-of-order
>    Template management events.
> 
> 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.
> 
>    Template Sets and Options Template Sets MUST be sent reliably and in
>    order.
> 
>    Template Withdrawal Messages MAY be sent on any SCTP stream. Template
>    Withdrawal Messages MUST be sent reliably, using SCTP-ordered
>    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.
> 
>    Additional Template Management considerations are given in [IPFIX-
>    PER-SCTP-STREAM], which specifies an extension to explicitly link
>    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.
> 

Comment#4:

It is hard to understand to sentence "estimation of Data  Record loss
per Template" in the paragraph.