eap Mailing List: Issue 272: Capitalization of Key Words

[Bernard Aboba (aboba]

Issue 272: Capitalization of Key Words
Submitter name: Florent Bersani
Submitter email address: florent.bersani [at] rd.francetelecom.fr
Date first submitted: 10/4/2004
Reference: http://mail.frascone.com/pipermail/eap/2004-October/002847.html
Document: Keying-03
Comment type: E
Priority: 2
Section: Various for instance 6.1.1
Rationale/Explanation of issue

As I find very unclear the authoritative status of eap-keying, I am very
sensitive to the use of RFC 2119 requirements key words.

However, I find that such key words abound in eap-keying and their
capitalization vary... sometimes erratically IMHO

For instance, in section 6.1.1, the "must" in the first bullet is lower
case "o It must specify how to derive the EMSK" whereas the "MUST" in
the latter bullets are upper case "o The key material used for the EMSK
MUST be computationally independent of the MSK and TEKs."...

I tried to reread very carefully eap-keying to spot out any other
offending miscapitalizations... but this task is daunting :-( see (*)

Anyway, after rereading RFC 2119, I am not sure that capitalization is
"mandatory" (for instance in RFC 2119, section 6 we MAY ;-) read:
"they MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions) For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for" so "MUST" and
"must not" have different capitalizations in RFC 2119).

My view is that capitalization should at least be used to draw attention
to important excerpts

Nevertheless, I have at least been annoyed by the additional following
occurences in annex F.1

"Note that the length of the AMSK must be specified
by the application."

"The application data is optional and may not be
used by some applications."

(*) my word count script gives me the following results:

must 29
MUST 61

may 136
MAY 8

required 26
REQUIRED 2

shall 0
SHALL 2

should 17
SHOULD 24

recommended 4
RECOMMENDED 15

optional 11
OPTIONAL 1
[Jari Arkko] OK - we need to look at this.

Requested change

Capitalize the key words mentioned here above i.e. at least in 6.1.1 and
F.1
[Jari Arkko]
> the latter bullets are upper case "o The key material used for the EMSK
> MUST be computationally independent of the MSK and TEKs."...

This needs to be corrected.

> Nevertheless, I have at least been annoyed by the additional following
> occurences in annex F.1
>
> "Note that the length of the AMSK must be specified
>    by the application."

s/must/MUST/
maybe also /Note that the/The/

> "The application data is optional and may not be
>    used by some applications."

s/may not/MAY NOT/

[Glen Zorn]
Let's not get carried away.  Is this sentence normative or
informative?  I think the latter.  In any case, the "MAY NOT"
construct DOES NOT :-) appear in RFC 2119.

[Jari Arkko]

Yes. My mistake...

[Florent Bersani]
I surely agree with the latter part of your remark.

For what regards the former, I was only saying that, in a document which
authoritative status is unclear IMHO, the abundance of possible
requirements key words is a real pain!
If you expect that the reader will engage in reflexions about whether
sentences are normative or informative in a 73-page document, the I
definitely  admire your optimism ;-)
Most of my concerns would be addressed if the document was split in two...

Florent, "Application data MAY be an empty string" as it is OPTIONAL
that applications provide some ;-) and for sure, there are things much
more interesting and worth doing than engaging in a thorough review of
the hundreds of occurrences of the key words to see if they are in
normative or informative sentences
[Jari Arkko]

> Florent, "Application data MAY be an empty string"

This would be good enough for me. [But it seems that we
need to take a decision about top-level issues first
before looking at the individual text pieces.]