hi David, On 24 Jun 2014, at 23:41, Black, David <david.black@xxxxxxx> wrote: > 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. Yep, that's better. I'll hold this for a -07 post-next-review-round. Many thanks, best regards, Brian >> 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
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail