In reviewing the changes in the draft for Proposed Standard status (vs. the prior Informational status), I found one small nit: In section 4.2: Otherwise, the values of Information Elements of an unsigned integer type may be represented either as unprefixed base-10 (decimal) strings, as base-16 (hexadecimal) strings prefixed by "0x", or as base-2 (binary) strings prefixed by "0b". In the 2nd line: "type may be represented" -> "type are represented" idnits 2.13.01 misinterpreted [WSP] in the ABNF for octetArray as a reference - the resulting warning should be ignored. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Tuesday, June 24, 2014 5:41 PM > To: Black, David; ietf at trammell.ch; General Area Review Team (gen- > art at ietf.org) > Cc: ietf at ietf.org; ipfix at ietf.org > Subject: Gen-ART review of draft-ietf-ipfix-text-adt-06 > > With correct subject line this time ... > > > -----Original Message----- > > From: Gen-art [ mailto:gen-art-bounces at ietf.org] On Behalf Of Black, David > > Sent: Tuesday, June 24, 2014 5:14 PM > > To: ietf at trammell.ch; General Area Review Team (gen-art at ietf.org) > > Cc: ietf at ietf.org; ipfix at ietf.org > > 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 at trammell.ch; General Area Review Team (gen-art at ietf.org) > > > Cc: ipfix at ietf.org; ietf at ietf.org; 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 at emc.com        Mobile: +1 (978) 394-7754 > > > ---------------------------------------------------- > > > > > > > _______________________________________________ > > Gen-art mailing list > > Gen-art at ietf.org > > https://www.ietf.org/mailman/listinfo/gen-art