Subject: [ipfix-arch] simple editorial changes for the architecture draft version 8

From: Benoit Claise <[email-masked]>
Date: Thu, 02 Jun 2005 12:25:37 +0200

Hi Nevil,

I reviewed the architecture draft one last time.
Here is a list of simple editorial changes.

-  Note that *_vvery_ Observation Point is associated with an
      Observation Domain (defined below), and that* one Observation Point
      may be a superset of several other Observation Points.  For
      example one Observation Point can be an entire line card.  That
      would be the superset of the individual Observation Points at the
      line card's interfaces.

	vvery -> every.

Btw, as we say "For the same terms defined here and in IPFIX-PROTO [3] the definitions are equivalent in both documents.", I will update this in IPFIX-PROTO.

- you should update  the observation domain definition, to make it consistent with IPFIX-PROTO.
 Observation Domain 
    
   An Observation Domain is the largest set of Observation Points for 
   which Flow information can be aggregated by a Metering Process.  
   Each Observation Domain presents itself using a unique ID to the 
   Collecting Process to identify the IPFIX Messages it generates.  For 
   example, a router line card may be an observation domain if it is 
   composed of several interfaces: each of which is an Observation 
   Point.  _Every Observation Point is associated with an Observation 
   Domain. _

	-> add the last sentence

- "1.  Changes/Issues from the -07 Draft" will have to be removed before the next version for the IESG :)

- section 7.3  Control Information
   "The ID must be sent within the Flow Records in order to be able to match the right configuration
   _control information_"
   	
	-> Control Information

-  6.3.2  Filter Functions, Fi

   Several such filters could be used in any sequence to select packets.
   Note that packets selected by a (sequence of) filter function(s) may be
   further classified by other filter functions, i.e. the selected
   packets may belong to several Flows, any or all of which are
   exported.

   At the minimum, change: function -> function(s)

   Now, I'm wondering if the sentence makes sense. 
   New proposal:
   Several such filters could be used in any sequence to select packets.
   Note that packets selected by a filter function may be
   further classified by other filter functions, i.e. the selected
   packets may belong to several Flows, any or all of which are
   exported.

-  Section 6.7  Summary
   +--------------------|----------------------------------------------+
   |                    |     Exporting Process                        |
   |+-------------------|-------------------------------------------+  |
   ||                   v       IPFIX Protocol                      |  |
   ||+-----------------------------+  +----------------------------+|  |
   |||Rules for                    |  |Functions                   ||  |
   ||| Picking/sending Templates   |  |-Packetize selected Control ||  |
   ||| Picking/sending Flow Records|->|  & data Information into   ||  |
   ||| Encoding Template & data    |  |  IPFIX export packets.     ||  |
   ||| Selecting Flows to export(*)|  |-Handle export errors       ||  |
   ||+-----------------------------+  +----------------------------+|  |
   |+----------------------------+----------------------------------+  |
   |+----------------------------+----------------------------------+  |
   |                             |                                     |
   |                    exported IPFIX Messages                        |
   |                             |                                     |
   |                +------------+-----------------+                   |
   |                |  Anonymize export packet(*)  |                   |
   |                +------------+-----------------+                   |
   |                             |                                     |
   |                +------------+-----------------+                   |
   |                |       Transport  Protocol    |                   |
   |                +------------+-----------------+                   |
   |                             |                                     |
   +-----------------------------+-------------------------------------+

   IPFIX export packets -> IPFIX Messages
   Anonymize export packet(*) -> Anynomize IPFIX Messages (*)

-  section 7.1  Information Model Overview

   However, the
   list of fields that can be transmitted by the protocol, such as Flow
   attributes (source IP address, number of packets, etc.) and
   information about the Metering and Exporting Process (packet
   Observation Point, sampling rate, Flow  timeout interval, etc.), is
   not specified in IPFIX-PROTO [3].  
	Flow  timeout -> Flow timeout

- there are 3 occurrences of "Field Type". See section 7.1 and 13.2 (two times)
  "Field Type" should not be capitalized, as there is no definition.

  The second occurrence says: "Within an IPFIX message the field type is indicated by its Field Type."
  Proposal: Within an IPFIX message the field type is indicated by its "field type" [IPFIX-PROTO]

-  Section 8.  IPFIX Protocol Details

   When the IPFIX Working Group was chartered there were existing common
   practices in the area of Flow export, for example NetFlow, CRANE,
   LFAP, RTFM, etc.  

   do you want to add the references? You will find the right format in RFC3955
	NetFlow: RFC3954
	CRANE: RFC3423
	LFAP: RFC2124
	RTFM: Nevil, you should know the RFC

- A minor point. Shouldn't we group the authors by affiliations in the top page.

Regards, Benoit.

**