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

[Adrangi, Farid (farid.adrangi]

Hi Bernrad,
Thanks.  please see my responses inline.
BR,
Farid

> -----Original Message-----
> From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] 
> On Behalf Of Bernard Aboba
> Sent: Monday, August 09, 2004 4:47 PM
> To: eap [at] frascone.com
> Subject: [eap] comments on draft-adrangi-eap-network-discovery-02.txt
> 
> 
> 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.
> 

Section 3 is an important part of the solution, so I would rather not to
do it as an appendix.  However, we can follow your advice if you
strongly feel that's the best way to structure the draft.

> 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.
> 

I agree.  And, I also think the point here is that the client should not
need to know which delivery option is implemented by the access network.
So, how about the following text?

"
The client implementation MUST be able to receive identity hint
information in an initial EAP-Identity/Request, or in a subsequent
EAP-Identity/Request after an initial EAP-Identity/Response is sent.
This will enable the client to work with the three delivery options
transparently.
"

> 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.
> 

Doesn't the following paragraph (included in the draft) address this
problem?

"
   When the initial RADIUS Access-Request is received, if the access
   network RADIUS proxy cannot route the RADIUS packet to the next AAA
   hop, it SHOULD send identity hint information to the client (via
   Access-Challenge encapsulating an EAP Identity Request).  When a
   subsequent RADIUS Access-Request is received, if the access network
   RADIUS proxy still cannot route the RADIUS packet to the next AAA
   hop, then it SHOULD discard the packet.  Optionally, the access
   network RADIUS server can also send an error notification (via
   Access-Challenge encapsulating an EAP Notification) with an
   appropriate error message.
"



> 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.
> 
> 

The above paragraph (the last sentence) also mentions about the optional
EAP-Notification that can be sent.  However, I am not sure if we need to
send an EAP-Failure afterward since no EAP method has started at this
point.  Please advise -- will also check RFC 3748 again on this.

> Some NITs:
> 
> Section 5
> 
> "There, is MUST be considered just" -> "Therefore, it MUST be 
> considered"

Ok.
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>