Skip to main content

Information Model for IP Flow Information Export (IPFIX)
draft-ietf-ipfix-information-model-rfc5102bis-10

Yes

(Ron Bonica)

No Objection

(Brian Haberman)
(Martin Stiemerling)
(Russ Housley)
(Sean Turner)
(Stephen Farrell)
(Wesley Eddy)

Recuse

(Benoît Claise)

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

Ron Bonica Former IESG member
Yes
Yes (for -09) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2013-01-22 for -09) Unknown
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
  information.

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.
Barry Leiba Former IESG member
(was Discuss) No Objection
No Objection (2013-01-22 for -09) Unknown
Update:
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:

NEW
   [ISO.10646]
              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:
http://standards.iso.org/ittf/PubliclyAvailableStandards/c056921_ISO_IEC_10646_2012.zip

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!
Brian Haberman Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (2013-01-23 for -09) Unknown
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.
Ralph Droms Former IESG member
(was Discuss) No Objection
No Objection (2013-02-13) Unknown
The new text regarding www.iana.org/assignments/ipfix/ipfix.xml
addresses my Discuss position.
Robert Sparks Former IESG member
(was Discuss) No Objection
No Objection (2013-02-12) Unknown
Thanks for addressing my comments
Russ Housley Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Wesley Eddy Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Benoît Claise Former IESG member
Recuse
Recuse (for -09) Unknown

                            
Stewart Bryant Former IESG member
Recuse
Recuse (2013-01-22 for -09) Unknown
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.