eap Mailing List: Issue 268: SM-05 Review

[Nick Petroni (npetroni]

Sorry, I hadn't seen this Issue earlier. Some comments below.

> Issue 268: SM-05 Review
> Submitter name: Michael Richardson
> Submitter email address: mcr [at] sandelman.ottawa.on.ca
> Date first submitted: 9/29/2004
> Reference:
> Document: SM-05
> Comment type: E
> Priority: S
> Section: Various
> Rationale/Explanation of issue

> I had previous read a draft in November of 2003.
> I found it difficult to read and generally pointless. First, it seems
I am not sure what this means. Are these comments based on draft -01 or
draft -05?

> that there is little point in publishing this document. Why not just
I am not sure if this comment is meant to claim there is no point in an
SM document at all or if the commenter just feels the document falls
short of this goal. The need for an EAP SM has been documented for some
time IMHO and the creation of such a document is in the charter
of this Working Group: http://www.ietf.org/html.charters/eap-charter.html

> that there is little point in publishing this document. Why not just
> refer to the 1X-REV diagrams, particularly given section 3.3 makes
I do not understand this comment for a number of reasons, but most
importantly:
 1. I see no state machines reflecting EAP itself in 1X-REV. This
    group worked with that one to try to develop compatible state machines.
    The result is a common interface which is used by both documents,
    but I don't think you could learn how EAP is supposed to work
    by reading their SM's. I could be wrong.

 2. 802.1X is neither the original use for EAP, nor
    the only place EAP is used. Pointing implementers of other protocols
    there would serve only to confuse IMHO.

 3. EAP is defined by the IETF, not the IEEE.

> it clear that anything you learn from this document is not
> authoritative.
This document is not intended to be authoritative, but that does not
inherently make it useless.

> I find that the need for section 3, tells me that there is some issue,
> if one needs three pages of explanation to understand how to read the
> state machines.
I find this comment ironic given the emphasis above on the 1X-REV
document. The majority of section 3 is copied word-for-word from 1X-REV
section 8.2.1 and the notation is intentionally similar to help the
readers of both documents so that the SMs can be understood together.

> RFC793 section 3.2 does just fine with text, and fits it all into
> fewer pages. If one is going to have big long sections like 4.1.1,
On my draft section 4.1.1 is less than a page. Perhaps I am looking at
the wrong section?

> and in particular, redescribe the states in section 4.5, why put all the
> details into the diagram? It just distracts from actual understanding of
> the relationship between states.
This does not seem unusual to me. First, 1X-REV uses the same technique
and that draft seems to be sufficient for the commenter. Second, without
state and variable descriptions, no diagram could possibly be understood.
Finally, this comment provides no constructive feedback. How would you
change the diagram? What should be in text and what should be in the
diagram?

> Neither the diagram nor the text stands alone, yet seem to repeat the
> same items.
I don't find this any different from any other document. I would expect
to find explanations of figures in any technical document. Perhaps
specific examples would help me understand.

Thanks,
nick