With correct subject line this time ... > -----Original Message----- > From: Gen-art [mailto:gen-art-bounces@xxxxxxxx] On Behalf Of Black, David > Sent: Tuesday, June 24, 2014 5:14 PM > To: ietf@xxxxxxxxxxx; General Area Review Team (gen-art@xxxxxxxx) > Cc: ietf@xxxxxxxx; ipfix@xxxxxxxx > Subject: Re: [Gen-art] Gen-ART review of draft-ietf-ipfix-text-adt-05 > > The -06 version of this draft addresses all of the comments in the > Gen-ART review of the -05 version. > > Nit: I suggest one minor clarification in the added text (insertion > of the word "comparing" is the primary purpose of this change, feel > free to edit to taste): > > OLD > See > [RFC6885] and [I-D.ietf-precis-framework] for more on the dangers of > Unicode strings.. > NEW > See > [RFC6885] and [I-D.ietf-precis-framework] for more on possible > unexpected results and related risks in comparing Unicode strings. > > Thanks, > --David > > > -----Original Message----- > > From: Black, David > > Sent: Friday, May 23, 2014 10:11 PM > > To: ietf@xxxxxxxxxxx; General Area Review Team (gen-art@xxxxxxxx) > > Cc: ipfix@xxxxxxxx; ietf@xxxxxxxx; Black, David > > Subject: Gen-ART review of draft-ietf-ipfix-text-adt-05 > > > > 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 > > ---------------------------------------------------- > > > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art