eap Mailing List: comments on draft-adrangi-eap-network-discovery-02.txt

[Bernard Aboba (aboba]

This version is much improved over -01.  With a little bit of cleanup I
think it will be ready for a "pseudo WG last call" (and review by 802.11).

My only substantive comment about this version concerns Section 3.  IMHO,
this section should be provided as an Appendix to the document, with the
exception of any normative requirements on the client.  My advice would be
to put those requirements into Section 1.

I think that Section 1 could use a bit more guidance for
implementations.  Take this statement from Section 3:

"   Client implementation[s] MUST support all three options."

Since the client doesn't have any way to know which option has been
deployed on the AP/AAA server, this normative statement is not meaningful.
What I think you mean to say is that the client may receive a hint in an
initial EAP-Identity/Request, or the hint could be received in a
subsequent EAP-Identity/Request after an initial EAP-Identity/Response is
sent.

Also, we had talked about some advice for implementations, such as:

a. Implementations SHOULD have a default value for the maximum number
   of EAP-Identity round-trips, in case the hint is not taken by the
   peer or is not acceptable to the EAP server.  It is suggested that
   no more than three retries by used by default.

b. It is suggested that an EAP-Notification by sent by the EAP
   server after the maximum retry limit is reached, to inform the
   peer why it is being disconnected, prior to sending an EAP-Failure.


Some NITs:

Section 5

"There, is MUST be considered just" -> "Therefore, it MUST be considered"