RE: Gen-ART review of draft-ietf-ipfix-text-adt-05

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
> ----------------------------------------------------
> 






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]