Subject: [secdir] SECDIR review of draft-kyzivat-case-sensitive-abnf

From: Chris Lonvick <[email-masked]>
Date: Fri, 05 Sep 2014 15:02:49 -0700

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

---

From: Barry Leiba <[email-masked]>
Date: Sat, 6 Sep 2014 17:59:09 +0300

Hi, Chris, and thanks for the review.

>    specification can be much more easily read.

No.  Take the sentence in context.  The context is that it's describing the
was we used to do case-sensitive text, giving each character's numeric
value.  It's *that* mechanism that has the readability disadvantage.

Do you really think that text is unclear, in the context that it's given?
 I suppose we could say "The old mechanism has...", to make it even clearer.

Barry

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 06 Sep 2014 12:12:33 -0400

Chris,

Thanks for the comments.

>  From that, I have no objection to moving this document forward.

As you can see, I just followed precedent since I wasn't doing anything 
that would alter the security implications in any way.

But I am open to suggestions for something better to say.

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

Yes. I don't know how that happened.

>     specification can be much more easily read.

No. "This mechanism" refers to "the way that has been used in the past" 
(specify the individual characters numerically). How about:

"The new way (using a literal text string with a prefix) has a clear 
readability advantage over the old way."

>       to having the "%i" prefix.

This seems good, except for the use of "current". That doesn't age well. 
I suggest replacing "current" with "prior".

	Thanks,
	Paul

---

From: Chris Lonvick <[email-masked]>
Date: Sat, 06 Sep 2014 10:37:12 -0700

Hi Barry,

On 9/6/14, 7:59 AM, Barry Leiba wrote:
> No.  Take the sentence in context.  The context is that it's 
> describing the was we used to do case-sensitive text, giving each 
> character's numeric value.  It's *that* mechanism that has the 
> readability disadvantage.
>
> Do you really think that text is unclear, in the context that it's 
> given?  I suppose we could say "The old mechanism has...", to make it 
> even clearer.

The sentence is consistent with the context of the section and I get 
that.  What I was raising a concern about was the nearly unparsable last 
clause: "and new the prefix mechanism is preferred."  :-) Obviously I 
muddied the waters with my suggestion and I don't see the point of 
belaboring this with explanations of %d or %h prefixes make literal 
strings unreadable, so just find some way to clean up that last clause.

Best regards,
Chris

---

From: Chris Lonvick <[email-masked]>
Date: Sat, 06 Sep 2014 10:38:14 -0700

Hi Paul,

On 9/6/14, 9:12 AM, Paul Kyzivat wrote:
> As you can see, I just followed precedent since I wasn't doing 
> anything that would alter the security implications in any way.
>

Nah, I like the consistency.  The only concern (very minor) that I have 
is about how older ABNF interpreters would react to seeing these new 
literals.  I don't think that they're mission critical in any way and 
the one that I tried (BAP) just gave me an error.
> Yes. I don't know how that happened.
Kind'a funny - you're not the first to make that error.
http://publib.boulder.ibm.com/infocenter/wtelecom/v6r2m0/index.jsp?topic=/com.ibm.diameter.rf.doc/rf_rawinterface_r.html
> No. "This mechanism" refers to "the way that has been used in the 
> past" (specify the individual characters numerically). How about:
>

Works for me.  See the response I sent to Barry.
> This seems good, except for the use of "current". That doesn't age 
> well. I suggest replacing "current" with "prior".
>
Works for me as well.

Best regards,
Chris

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Sep 2014 17:07:44 -0400

Chris,

Based on discussions in this thread I've posted an -02 version that 
hopefully addresses all of your comments.

	Thanks,
	Paul

---

From: Chris Lonvick <[email-masked]>
Date: Thu, 11 Sep 2014 10:59:52 -0700

Hi Paul,

It looks good to me.  I recommend progressing this forward.

Best regards,
Chris