Subject: [eap] new state machine document and issue #98

From: [email-masked] (Jari Arkko)
Date: Wed, 14 May 2003 13:36:36 +0300

Thank you for the new state machine document! This
version (-02) is much better than the previous one.
I still have some comments, though, and I will send
them as my review of the document progresses.

The first comment is that I checked issue #98 that I filed
earlier on the -01 document:

   http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%2098

It seems to be handled, but there's a few details left that
should perhaps be fixed:

- Delete the paragraph from the abstract that starts
   with "This document is still a work in progress." Sure it
   is, all I-Ds are and we'd have to remove the statement
   anyway at some point...

- The text and the state machine pictures are inconsistent in
   the capitalization of the ELSE label. Sometimes "ELSE", sometimes
   "else".

- I still didn't find any statement that would clarify the
   role of the state machine transitions vs. MAY/SHOULD/MUST
   requirements in 2284bis. I *think* your intention is that
   any transition-like requirements end up as transitions in
   your document, regardless of the strength of the keyword
   possible associated with it in some other document.
   Suggested text to add in 3.2 or other appropriate place:
   "This document specifies the possible transitions and
   actions for EAP peers, authenticators, and pass-through
   authenticators. It does not attempt to characterize the
   RFC 2119 requirement levels (MAY, SHOULD, MUST, and so
   on) of these transitions."

- The "methodState = { SUCC | CON_SUCC | ... }" notation has not
   been explained.

- In the text:

   "Next, the method must decide whether to process the packet or
    silently discard it. If the packet looks like it wasn't sent by the
    legitimate authenticator (e.g. it has invalid MIC, and this case
    should never occur), the method can set intCheck=FALSE.  In this
    case, the method must not modify methodState, and it should not
    modify its own method-specific state."

   It is not 100% clear that MICs are optional. Suggested rewrite:

   "Next, the method must decide whether to process the packet or
    silently discard it. Some methods may use MIC values in the
    messages to ensure that the messages have been sent by the
    legitimate authenticator. If the method can perform such
    a check, and finds that the MIC is invalid, it sets intCheck
    to FALSE. In this case, the method must not modify methodState,
    and it should not modify its own method-specific state."

--Jari