I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-ipfix-text-adt-05 Reviewer: David L. Black Review Date: May 23, 2014 IETF LC End Date: May 28, 2014 Summary: This draft is on the right track, but has open issues described in the review. This is a relatively short draft defining textual representations of IPFIX data elements. It's clear and easy to read. I assume that all the ABNF has been checked. The open issues involve use of Unicode. Minor issues: Section 4.7 string As Information Elements of the string type are simply UTF-8 encoded strings, they are represented directly, subject to the escaping and encoding rules of the Enclosing Context. There's nothing "simply" about use of UTF-8 encoded strings :-). There appear to be no restrictions on Unicode codepoint usage and no requirements for string normalization or other preparation either in this draft or RFC 7011. This can be a formula for all sorts of mischief, so some warnings about what's possible should be added somewhere - some of these comments may be raising Unicode concerns in RFC 7011 that would be better addressed there. A general warning about unreliability of Unicode string comparison is in order. This also applies if an identifier that is not limited to ASCII characters is substituted for an integer as described in Section 4.2. In addition, the concerns around visually similar characters discussed in section 10.5 of the précis framework draft (draft-ietf-précis-framework) apply; a short summary and pointer to that section of that draft should suffice. Section 4.1.5 of the précis framework draft warns against use of mixed- direction Unicode strings, as "there is currently no widely accepted and implemented solution for the processing and safe display of mixed- direction strings." That warning deserves repetition here. Lots of mischief is possible with non-printing and control characters - I would expect that the Enclosing Context contains sufficient restrictions on use of Unicode to deal with most of this concern, and would state that expectation. This comment is definitely specific to this draft. Nits/editorial comments: Section 4.4 float32 and float64 exponent = ( "e" / "E" ) [sign] 1*3DIGIT Please explain why no more than 3 digits are ever required. Section 4.8 dateTime* The '*' in the section title, dateTime* is clever, but it's meaning is not obvious. I suggest "The dateTime Data Types" as a better section title. Section 5 Security Considerations The security considerations for the IPFIX Protocol [RFC7011] apply; this document presents no additional security considerations. That's ok, although adding a direct mention of the [UTF8-EXPLOIT] TR cited in RFC 7011 would be helpful. idnits 2.13.01 warns that the JSON reference (RFC 4627) is obsolete, and needs to be replaced with one or two current RFC references. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.black@xxxxxxx Mobile: +1 (978) 394-7754 ----------------------------------------------------