Subject: [eap] Issue on eap-keying: capitalization of RFC 2119 requirements key words

From: Florent Bersani <[email-masked]>
Date: Mon, 04 Oct 2004 15:20:39 +0200

Description of issue: capitalization of RFC 2119 requirements key words

    Submitter name: Florent Bersani

    Submitter email address: [email-masked]

    Date first submitted: 10/04/2004

    Document: Keying Framework

    Comment type: 'E'ditorial

    Priority: 2 May fix

    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

Requested change

Capitalize the key words mentioned here above i.e. at least in 6.1.1 and F.1

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Tue, 05 Oct 2004 00:17:16 +0300

> MUST be computationally independent of the MSK and TEKs."...

This needs to be corrected.

> "Note that the length of the AMSK must be specified

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

>    used by some applications."

s/may not/MAY NOT/

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

Ok -- we need to look at each one...

> Capitalize the key words mentioned here above i.e. at least in 6.1.1 and 

Agreed.

--Jari

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Mon, 4 Oct 2004 15:52:24 -0700

Jari Arkko writes:

...

>>    used by some applications."

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.

>> Capitalize the key words mentioned here above i.e. at least in
6.1.1
>> and F.1

---

From: Florent Bersani <[email-masked]>
Date: Tue, 05 Oct 2004 09:07:18 +0200

Glen,

>construct DOES NOT :-) appear in RFC 2119.
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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 05 Oct 2004 13:20:22 +0300

Hi Glen, Florent,

>> construct DOES NOT :-) appear in RFC 2119.

Yes. My mistake...

> 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.]

--Jari

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Tue, 5 Oct 2004 10:04:53 -0700

Florent Bersani <mailto:[email-masked]> writes:

> 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!

I certainly agree that the capitalization must be corrected;
however, my point was that going the opposite way of capitalizing
every occurrence of "must", "should", "may", etc. may leave the doc
in as bad a shape as it is in now.

> definitely  admire your optimism ;-)

No, but I _do_ expect that at least the authors (lacking that, the
reviewers) will engage in those reflections and further, act upon
them appropriately.

> Most of my concerns would be addressed if the document was split
in
> two... 
> normative or informative sentences review of _any_ IETF document,
let alone this one)

There are no doubt much more interesting activities than the
thorough review of _any_ IETF document, let alone this one), but
it's definitely worthwhile.

>>> [email-masked] http://mail.frascone.com/mailman/listinfo/eap

---

From: Florent Bersani <[email-masked]>
Date: Wed, 06 Oct 2004 09:07:49 +0200

Glen,

I think that we both agree on the situation and the work that MUST be 
done ;-)

Florent

Glen Zorn (gwz) wrote:

>>If you expect that the reader will engage in reflexions about
>>    
>>
>whether
>  
>
>>sentences are normative or informative in a 73-page document, the
>>    
>>
>I
>  
>
>>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
>  
>