eap Mailing List: Re: Issue 268: SM-05 Review

[Jari Arkko (jari.arkko]

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

Nick Petroni wrote:
> 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
>
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap