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