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

[Ballot comment]

- 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

[Ballot comment]
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.

[Ballot comment]
This draft is not required to go through the IESG:

The update of IPFIX registry in question doesn't need a specification and no IETF consensus (see BCP 184 -- thanks to Brian Trammel for point this out) and it also is a full match of what is described in Section 4.2.3 of RFC 2026, i.e., this should be directly send to the RFC editor.

[Ballot discuss]
I do not have any general objection to the publication of the document.

However, I do see an issue that this document is progressed as AD sponsorship, thus raising Adrian's comment to a DISCUSS.

This draft is a perfect shot for a WG item and I have really troubles to understand why this has been AD sponsored. It even may fall under point 1 of the WG charter.

Aren't we short-cutting the IETF Standards Process?

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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
interfer 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.

IESG/Authors/WG Chairs:

IANA has reviewed draft-trammell-ipfix-tcpcontrolbits-revision-04.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA has asked a representative from the IE Doctors team to confirm that the experts have confirmed this action.

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the IPFIX Information Elements subregistry of the IP Flow Information Export (IPFIX) Entities registry located at:

http://www.iana.org/assignments/ipfix/

the entry for ElementID 6 (tcpControlBits will be modified as follows:

ElementId:  6
Data Type:  unsigned16
Data Type Semantics:  flags
Description:  TCP control bits observed for the packets of this Flow.  This information is encoded as a bit field; for each TCP control bit, there is a bit in this set.  The bit is set to 1 if any observed packet of this Flow has the corresponding TCP control bit set to 1.  The bit is cleared to 0 otherwise.

The values of each bit are shown below, per the definition of the bits in the TCP header [RFC0793]:

MSb                                                        LSb
  0  1  2  3  4  5  6  7  8  9  10  11  12  13  14  15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|              |          | N | C | E | U | A | P | R | S | F |
|    Zero      |  Future  | S | W | C | R | C | S | S | Y | I |
| (Data Offset) |    Use    |  | R | E | G | K | H | T | N | N |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
bit    flag
value  name  description
------+-----+-------------------------------------
0x8000      Zero (see tcpHeaderLength)
0x4000      Zero (see tcpHeaderLength)
0x2000      Zero (see tcpHeaderLength)
0x1000      Zero (see tcpHeaderLength)
0x0800      Future Use
0x0400      Future Use
0x0200      Future Use
0x0100  NS  ECN Nonce Sum
0x0080  CWR  Congestion Window Reduced
0x0040  ECE  ECN Echo
0x0020  URG  Urgent Pointer field significant
0x0010  ACK  Acknowledgment field significant
0x0008  PSH  Push Function
0x0004  RST  Reset the connection
0x0002  SYN  Synchronize sequence numbers
0x0001  FIN  No more data from sender

References:  [RFC0793][RFC3168][RFC3540]
Revision:  1

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Revision of the tcpControlBits IPFIX Information Element) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Revision of the tcpControlBits IPFIX Information Element'
  as Informational
RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-11-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document revises the tcpControlBits IPFIX Information Element as
  originally defined in [RFC5102] to reflect changes to the TCP Flags
  header field since [RFC0793].




The file can be obtained via
http://datatracker.ietf.org/doc/draft-trammell-ipfix-tcpcontrolbits-revision/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-trammell-ipfix-tcpcontrolbits-revision/ballot/


No IPR declarations have been submitted directly on this I-D.