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 | IETF Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2014-09-30 | |
| Requested | 2014-09-04 | |
| Authors | Paul Kyzivat | |
| I-D last updated | 2018-04-26 (Latest revision 2014-09-10) | |
| Completed reviews |
Genart IETF Last Call review of -01
by Brian E. Carpenter
(diff)
Genart IETF Last Call review of -02 by Brian E. Carpenter Secdir IETF Last Call review of -01 by Chris M. Lonvick (diff) Opsdir IETF Last Call review of -01 by Melinda Shore (diff) |
|
| Assignment | Reviewer | Chris M. Lonvick |
| State | Completed | |
| Request | IETF Last Call review on draft-kyzivat-case-sensitive-abnf by Security Area Directorate Assigned | |
| 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