Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element
draft-trammell-ipfix-tcpcontrolbits-revision-05

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.

Another agreement with Adrian.

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.

- 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

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.