eap Mailing List: Re: Issue: Changes Appendix

[Jari Arkko (jari.arkko]

Looks very good, though I'm not sure this covers everything.
Perhaps we should go through the issue list and look at each
issue to figure out what technical changes have gone in to
the draft. What about sequences, lock-step, strictness,
Nak of identity, to mention a few -- or are some of these
covered in the bullet item about 4.1?

Anyway, I think the text you posted is good enough for -02.
A few nits below.

> Appendix B. Changes from RFC 2284
>
>    This section lists the major changes between [RFC2284] and this
>    document. Minor changes, including style, grammar, spelling and
>    editorial changes are not mentioned here.

Might be an idea to separate functional changes from (major) document
changes such as the addition of IANA or security considerations sections.

>    o  The Terminology section (Section 1.2) has been expanded, defining
>       more concepts and giving more exact definitions.
>
>    o  In Section 2, it is explicitly specified that more than one
>       exchange of Request and Response packets may occur as part of the
>       EAP authentication exchange. How this may and may not be used is
>       specified in detail in Section 2.1.
>
>    o  Also in Section 2, some requirements on the authenticator when
>       acting in pass-through mode has been made explicit.
>
>    o  An EAP multiplexing model (Section 2.2) has been added, to
>       illustrate a typical implementation of EAP. There is no
>       requirement that an implementation conforms to this model, as long
>       as the on-the-wire behavior is consistent with it.
>
>    o  As EAP is now in use with a variety of lower layers, not just PPP
>       for which it was first designed, Section 3 on lower layer behavior
>       has been added.
>
>    o  In the description of the EAP Request and Response interaction
>       (Section 4.1), it has been more exactly specified when packets
>       should be silently discarded, and also the behavior on receiving
>       duplicate requests. The implementation notes in this section has
>       been substantially expanded.
>
>    o  In Section 4.2, it has been clarified that Success and Failure
>       packets must not contain additional data, and the implementation
>       note has been expanded. A sub-section giving requirements on

subsection?

>       processing of success and failure packets has been added.
>
>    o  Section 5 on EAP Request/Response Types lists two new type values:
>       the Expanded type (Section 5.7), which is used to expand the type
>       value number space, and the Experimental type. In the Expanded
>       type number space, the new Expanded Nak (Section 5.3.2) type has
>       been added. Clarifications have been made in the description of
>       most of the existing types. Security claims summaries has been
>       added for authentication methods.

s/has/have/

>    o  An IANA Considerations section (Section 6) has been added, giving
>       registration policies for the numbering spaces defined for EAP.
>
>    o  The Security Considerations (Section 7) have been greatly
>       expanded, aiming at giving a much more comprehensive coverage of
>       possible threaths and other security considerations.

s/threaths/threats/