Subject: [eap] more editorial issues in 2284bis-03.f

From: [email-masked] (Jari Arkko)
Date: Sun, 11 May 2003 23:39:52 +0300

>    Length
> 
>       The Length field is two octets and indicates the length of the EAP
>       packet including the Code, Identifier, Length and Data fields.

I'd prefer "The Length field is two octets. It indicates the number of
octets in the EAP packet including the Code, Identifier, Length, and Data
fields."

Also, Section 4 and 4.1 have duplicate text for the description of
the Length field. Suggest cutting the first text shorter, maybe
"The Length field is two octets and indicates the length of the
complete EAP packet."

> 4.1 ...
> 
>       Retransmitted Requests MUST be sent with the same Identifier value
>       in order to distinguish them from new Requests. The contents of
>       the data field is dependent on the Request Type. The peer MUST

"are dependent" ?

> 5. Initial EAP Request/Response Types
> 
>    All EAP implementations MUST support Types 1-4, which are defined in
>    this document, and SHOULD support Type 254. Follow-on RFCs MAY define
>    additional EAP Types.

MAY in the last sentence does not appear to be an implementation
requirement. Replace with "Implementations MAY support other
Types defined here or in future RFCs."

> 5.7 Expanded Types
> 
>    Description
> 
>       Due to EAP's popularity, the original method Type space, which
>       only provides for 255 values, is being allocated at a pace which
>       if continued would result in exhaustion within a few years.

This is an interesting status report, but may not be very useful in
a protocol specification. In any case, the text that comes after this
explains the purpose of the scheme. Suggestion: delete the first
sentence.

> 7.11. ...
> 
>    This can be done by enabling users to configure which are the
>    acceptable ciphersuites as a matter of security policy; or, the
>    ciphersuite negotiation MAY be authenticated using keying material
>    derived from the EAP authentication and a MAC algorithm agreed upon
>    in advance by lower-layer peers.

s/MAC/MIC/

--Jari