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 revision | 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 E. Carpenter
(diff)
Genart Last Call review of -02 by Brian E. Carpenter Secdir Last Call review of -01 by Chris M. Lonvick (diff) Opsdir Last Call review of -01 by Melinda Shore (diff) |
|
| Assignment | Reviewer | Chris M. Lonvick |
| State | Completed Snapshot | |
| Review |
review-kyzivat-case-sensitive-abnf-01-secdir-lc-lonvick-2014-09-11
|
|
| Reviewed revision | 01 (document currently at 02) | |
| Result | Has Nits | |
| Completed | 2014-09-11 |
review-kyzivat-case-sensitive-abnf-01-secdir-lc-lonvick-2014-09-11-00
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