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