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

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.

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!

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.

The new text regarding www.iana.org/assignments/ipfix/ipfix.xml
addresses my Discuss position.

Thanks for addressing my comments