Subject: [eap] Issue 268: SM-05 Review

From: Nick Petroni <[email-masked]>
Date: Sun, 7 Nov 2004 23:26:11 -0500 (EST)

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

> Issue 268: SM-05 Review
> Submitter name: Michael Richardson
> Submitter email address: [email-masked]
> 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

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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 08 Nov 2004 14:09:20 +0200

I tend to agree with Nick on this one. It is true that
a major user of EAP is in 1X but at least the current
documents are organized in a way where the 1X-REV and
EAP-SM work together, not overlap. You could have done
it in another way, having all state machines in the 1X-REV
side but that is not the way that was picked, and, as Nick
points out, there is value in defining EAP's behavior
for everyone, not just 1X-REV.

Regarding the other comments I think it would be valuable
if we could go down to the specific problems, I'm sure the
document could be improved if there's duplication, bad
descriptions or other problems. Can you Michael help Nick
to catch the ones that you noticed?

Note, however, that there is some degree of effort needed
in specifying and understanding semi-formal state machines
like this. For instance, if we want to be precise there
needs to be a definition of variables, interfaces, and
procedures. I have witnessed some IETF efforts where the
pain of getting such details right was too great and people
gave up, in the end producing only the usual MUST/SHOULD
language and no state machines at all, even if the behaviour
needed under different sequences of events was relatively
complicated. Having followed implementation work thereafter, I
tend to think that the effort was simply pushed to implementors
and resulted in long-lasting, hard to debug problems.

--Jari