Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element
draft-trammell-ipfix-tcpcontrolbits-revision-05
Yes
(Benoît Claise)
(Joel Jaeggli)
No Objection
(Jari Arkko)
(Richard Barnes)
(Sean Turner)
(Spencer Dawkins)
(Ted Lemon)
Note: This ballot was opened for revision 05 and is now closed.
Benoît Claise Former IESG member
Yes
Yes
()
Unknown
Joel Jaeggli Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2013-12-15)
Unknown
This message is not directed to the document authors, and I don't ask them to do anything to address it. I have no objection to the publication of this document, but I have to say that the reason given in the Ballot text for this document being published as AD Sponsored rather than the output of the IPFIX working group is pure baloney! We are carefully told that the document has been discussed on the working group mailing list and that there is clear consensus within the working group for it, but for some reason testing that consensus with a two week working group last call would somehow interfere with "the IPFIX WG slowly but surely finishing up his (sic) last deliverables and shutting down." I really don't think this matters, but when there is a working group dedicated to a topic, when using the working group would not add significant delay or effort, and when working group consensus is claimed, I can't see any reason not to use the working group.
Barry Leiba Former IESG member
No Objection
No Objection
(2013-12-19)
Unknown
Another agreement with Adrian.
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Martin Stiemerling Former IESG member
(was Abstain, Discuss)
No Objection
No Objection
(2013-12-18)
Unknown
I've changed to no objection, but still support Adrian's comment. I will be definitely to think again about the BCP 184 process and what it means when it is executed.
Richard Barnes Former IESG member
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
No Objection
No Objection
()
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
()
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2013-12-19)
Unknown
- Is the ElementId value of 6 the same as the old one? If so, and the size of this is changing then I don't see how you get good backwards/ forwards compatibility without a flag day. Shouldn't this have a new ElementId or am I just missing something basic? - Please also see the secdir review. [1] There looked to be some tweaks to do based on the discussion between reviewer and author. [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04355.html
Stewart Bryant Former IESG member
No Objection
No Objection
(2013-12-16)
Unknown
I agree with Adrian's comment. Additionally, I am suprised that the opportunity was not taken to to define bits 4..6 as "as defined by updates to the TCP specification" so that there is no need to publish an update to this RFC if TCP makes any enhancement to these bits.
Ted Lemon Former IESG member
No Objection
No Objection
()
Unknown