Information Model for IP Flow Information Export (IPFIX)
RFC 7012

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

(Ron Bonica) Yes

(Ralph Droms) (was Discuss) No Objection

Comment (2013-02-13)
No email
send info
The new text regarding
addresses my Discuss position.

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2013-01-22 for -09)
No email
send info
Thank you for the inclusion of Section 1.1 which was a great help in
reviewing this document.

It seems that the level of change from 5102 is relatively small so it
might be more appropriate to list the authors of 5102 as Contributors
to this document.


I am not really sure about the 2119 usage, but I have no energy to 
debate it. However, you might try for some consistency :-)
For example,
   range - Some Information Elements may only be able to take on a
      restricted set of values that can be expressed as a range (e.g., 0
      through 511 inclusive).  If this is the case, the valid inclusive
      range should be specified; values for this Information Element
      outside the range are invalid and MUST NOT be exported.

Is that should or SHOULD?


Sections 3.1.17 and 3.1.18 refer to formats. Is that appropriate in an
information model?


Format of Sections 7, 8, and 9 looks broken.


In Section 9

  This document does not specify any Information Element carrying keying
  material.  If future extensions will do so, then appropriate
  precautions need to be taken for properly protecting such sensitive

I am not sure this is appropriate. This is an Information model, and so
defining elements for keys would not have security consequence. The use
of the information elements in a data model would have security 
consequences, but that is a different issue.

(Stephen Farrell) No Objection

(Brian Haberman) No Objection

(Russ Housley) No Objection

Barry Leiba (was Discuss) No Objection

Comment (2013-01-22 for -09)
No email
send info
The authors have proposed a new paragraph that notes that encodings are specified in 5101(bis), and I'm happy with that.

The authors have also proposed a rewrite of the abstract, which I like.

I suggest that the ISO 10646 reference be replaced with a newer one, thus:

              International Organization for Standardization,
              "Information technology — Universal Coded Character
              Set (UCS)", ISO/IEC 10646:2012(E), June 2012.

A URL where that can be found is here:

Finally, I wonder why the document uses an ISO reference for ASCII, rather than ANSI X3.4, or even RFC 20.  The authors may check on this, but this is non-blocking.

Thanks for addressing my concerns so quickly!

(Pete Resnick) No Objection

Comment (2013-01-23 for -09)
No email
send info
To follow up on Barry's point:

3.1.14.  string

   The type "string" represents a finite-length string of valid
   characters from the Unicode character encoding set
   [ISO.10646-1.1993].  Unicode allows for ASCII [ISO.646.1991] and many
   other international character sets to be used.

I understand that this was from 5102, but it is pretty poorly written. Since it is a carry over, I certainly won't insist on changing it, but might I suggest:

   The type "string" represents a finite-length string of valid
   characters from the Unicode coded character set
   [ISO.10646-1.1993].  Unicode incorporates ASCII [ISO.646.1991] and the
   characters of many other international character sets.

I agree with Barry that there are better references.

(Robert Sparks) (was Discuss) No Objection

Comment (2013-02-12)
No email
send info
Thanks for addressing my comments

(Martin Stiemerling) No Objection

(Sean Turner) No Objection

(Stewart Bryant) Recuse

Comment (2013-01-22 for -09)
No email
send info
As an author of RFC5102 and a major contributor to the technical text that has been propagated into this version, I am unsure of the ethics of taking a position.

I will however make one note that I think that the shepherding AD should consider. The proposal here seem to be to change the IANA references from RFC5102 to RFC5102bis. That is fine with the information elements re-specified in this RFC2b, but that removes the traceability of in use information elements that were originally specified in RFC5102, but not carried  forward into the bis RFC.

(Benoît Claise) Recuse