Skip to main content

Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol
draft-ietf-ipfix-a9n-08

Yes

(Ron Bonica)

No Objection

(Adrian Farrel)
(Brian Haberman)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Pete Resnick)
(Robert Sparks)
(Stewart Bryant)
(Wesley Eddy)

Recuse

(Benoît Claise)

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

Ron Bonica Former IESG member
Yes
Yes (for -07) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (2012-11-10 for -07) Unknown
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?
Brian Haberman Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Ralph Droms Former IESG member
No Objection
No Objection (2012-11-14 for -07) Unknown
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?
Robert Sparks Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection (2012-11-14 for -07) Unknown
  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_?
Sean Turner Former IESG member
No Objection
No Objection (2012-11-14 for -07) Unknown
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.
Stephen Farrell Former IESG member
No Objection
No Objection (2012-11-13 for -07) Unknown

- 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
Stewart Bryant Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Wesley Eddy Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Benoît Claise Former IESG member
Recuse
Recuse (for -07) Unknown