Skip to main content

Last Call Review of draft-ietf-ipfix-text-adt-07
review-ietf-ipfix-text-adt-07-genart-lc-black-2014-07-18-00

Request Review of draft-ietf-ipfix-text-adt
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-07-30
Requested 2014-07-17
Authors Brian Trammell
I-D last updated 2014-07-18
Completed reviews Genart Last Call review of -05 by David L. Black (diff)
Genart Telechat review of -06 by David L. Black (diff)
Genart Last Call review of -07 by David L. Black (diff)
Assignment Reviewer David L. Black
State Completed
Request Last Call review on draft-ietf-ipfix-text-adt by General Area Review Team (Gen-ART) Assigned
Reviewed revision 07 (document currently at 10)
Result Ready w/nits
Completed 2014-07-18
review-ietf-ipfix-text-adt-07-genart-lc-black-2014-07-18-00
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