Last Call Review of draft-kyzivat-case-sensitive-abnf-01
review-kyzivat-case-sensitive-abnf-01-secdir-lc-lonvick-2014-09-11-00

Request Review of draft-kyzivat-case-sensitive-abnf
Requested rev. no specific revision (document currently at 02)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-09-30
Requested 2014-09-04
Authors Paul Kyzivat
Draft last updated 2014-09-11
Completed reviews Genart Last Call review of -01 by Brian Carpenter (diff)
Genart Last Call review of -02 by Brian Carpenter
Secdir Last Call review of -01 by Chris Lonvick (diff)
Opsdir Last Call review of -01 by Melinda Shore (diff)
Assignment Reviewer Chris Lonvick
State Completed
Review review-kyzivat-case-sensitive-abnf-01-secdir-lc-lonvick-2014-09-11
Reviewed rev. 01 (document currently at 02)
Review result Has Nits
Review completed: 2014-09-11

Review
review-kyzivat-case-sensitive-abnf-01-secdir-lc-lonvick-2014-09-11



Hi,







I have
        reviewed this document as part of the security directorate's
        ongoing effort to review all IETF documents being processed by
        the IESG. These comments were written primarily for the benefit
        of the security area directors. Document editors and WG chairs
        should treat these comments just like any other last call
        comments.





        The abstract is: 










   This document extends the base definition of ABNF (Augmented Mackus-
   Naur Form) to include a way to specify ASCII string literals that are
   matched in a case-sensitive manner.





        Overall, I don't like the statement in the Security
        Considerations section, but it is consistent with all other
        documents related to defining ABNF, and I can't find any
        noteworthy security issues anyway.  From that, I have no
        objection to moving this document forward.





        I did find some nits and have some suggestions for improving
        readability.





        1 - "Mackus-Naur" is used in two places rather than
        "Backus-Naur".





        2 - The last sentence of section 2.1 is:


           







   This mechanism has a clear readability
   disadvantage, with respect to using a literal text string with a
   prefix, and new the prefix mechanism is preferred.





        Perhaps you meant:


           This mechanism of using a literal text string with a prefix
        has a clear 


           readability disadvantage.  The prefix mechanism described in
        this 


           specification can be much more easily read.


           


           


        3 - This part of Section 2.1 may be cleared up some:


         ---vvv---










If no prefix is present then the string is case-insensitive.

   Hence:

         rulename = %i"aBc"

   and:

         rulename = "abc"

   will both match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and
   "ABC".





         ---^^^---





         Suggested:


          ---vvv---


             To be consistent with current implementations of ABNF,
        having no


             prefix means that the string is case-insensitive, and is
        equivalent


             to having the "%i" prefix.





           Hence:





                 rulename = %i"aBc"





           and:





                 rulename = "abc"





           are equivalent and both will match "abc", "Abc", "aBc",
        "abC", "ABc", 


           "aBC", "AbC", and "ABC".


        ---^^^---











    Best regards,


    Chris