Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol

Note: This ballot was opened for revision 07 and is now closed.

(Ron Bonica) Yes

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

Comment (2012-11-14 for -07)
No email
send info
I'll follow up on Stephen's Comment and ask about
the requirements language.  There is very little
RFC 2119 language, and some of it seems unnecessary:

   Additional such Information Elements
   SHOULD be registered with IANA on an as-needed basis.

Is the RFC 2119 language really needed anywhere?

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2012-11-13 for -07)
No email
send info

- I was a bit puzzled as to what exactly is being specified
here. It seems like there's little normative text here and most
of that is in draft-ietf-ipfix-mediation-protocol, so I
wondered it it wouldn't have been better for this to be an
informational guide and for all the normative stuff to be in
the mediation protocol draft that a developer might be more
likely to read?  To be clear: I'm not fussed about whether this
is standards track or informational nor about the use of 2119
language, but more about whether all the stuff that a developer
might need is in the right document(s). (57 pages of mostly
advice is the kind of thing that'll get ignored:-) Maybe if you
added a sentence in the intro saying that only bits of section
5 and section 7 are normative (or whatever is the case) that
might help the reader?

- 5.1.1 defines a bunch of methods, one of which is the
"simulated process" method of distributing counters over
aggregated flow intervals, however there is nothing in the
description of the simulated process that could be directly
implemented that I can see.  That's puzzling so I don't know
what code might be written to do this, that'd result in
interop. The "Direct" method seems equally vague btw.

- 5.1.1, "SHOULD accept ... in any reasonable order" seems
overly vague, esp. when you say that the meaning of "reasonable
order" might not be clear when writing code.

- 6.4, are the "should" statements here meant as 2119 SHOULDs
or not?

- the examples look great! thanks

(Brian Haberman) No Objection

(Russ Housley) (was Discuss) No Objection

Comment (2012-11-14 for -07)
No email
send info
  The definition of an aggregated flow in Section 2 reads: 

     Aggregated Flow:   A Flow, as defined by
     [I-D.ietf-ipfix-protocol-rfc5101bis], derived from a set of zero
     or more original Flows within a defined Aggregation Interval.  The
     primary difference between a Flow and an Aggregated Flow in the
     general case is that the time interval (i.e., the two-tuple of
     start and end times) of a Flow is derived from information about
     the timing of the packets comprising the Flow, while the time
     interval of an Aggregated Flow is often externally imposed.  Note
     that an Aggregated Flow is defined in the context of an
     Intermediate Aggregation Process only.  Once an Aggregated Flow is
     exported, it is essentially a Flow as in
     [I-D.ietf-ipfix-protocol-rfc5101bis] and can be treated as such.

  The way the second phrase is written confuses me. If 'the time
  interval of an Aggregated Flow' is <often> externally imposed, this
  means that there are exceptions? In which cases? And in these cases
  what is the specific difference that makes that Flow to be Aggregated?

  Section 5.1.1 says: 

     Each counter for an Original Flow is divided by the
     number of time _units_ the Original Flow covers, to derive a mean
     count rate.

  What is the meaning of _units_?

Barry Leiba No Objection

Comment (2012-11-10 for -07)
No email
send info
A couple of minor comments; no email response necessary:

-- Sections 5.3.1 and 12.2 --
You use three slightly different URIs in the document for the IANA registry:
http://www.iana.org/assignments/ipfix/ipfix.html  (in Section 5.3.1)
http://www.iana.org/assignments/ipfix  (in Section 10)
http://www.iana.org/assignments/ipfix/ipfix.xml  (in Section 12.2)

The second is the form that IANA prefers, and it will redirect to the correct page; please change them all to use that form.  (The third will currently work; the first does not (because the registry was converted from HTML to XML)... but the second will continue to work even if they reformat the page in JSON or whatever.)

-- Section 7.2.4 --
   [IANA NOTE: This Information Element is compatible with Information
   Element 3 as used in NetFlow version 9.]

Is this meant to remain after publication?  Or should you say that the RFC Editor should remove this note?

(Pete Resnick) No Objection

(Robert Sparks) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection

Comment (2012-11-14 for -07)
No email
send info
About half way through I read the other AD discuss/comment positions that were already entered and noted that I was starting to feel the same way Stephen did in his first comment.  At 4.3 pages/requirement, the draft seems rather long winded to standardize aggregation of IPFIX flow data.  I guess the community finds this approach acceptable so that's good enough for me.

(Benoît Claise) Recuse