RE: a question related to the eap network discovery solution draft
From: Adrangi, Farid (farid.adrangiintel.com)
Date: Tue, 21 Sep 2004 22:02:55 -0400 (EDT)
I also think the third option is reasonable.  However, please see
comments inline.
BR,
Farid

> I can see a few possible ways of doing this:
> 
> 1) Have the proxies issue an additional request
> regardless of whether they have a working NAI
> or not. The disadvantage of this is that an
> additional roundtrip is imposed. And as far as
> I understand options 2 and 3 in the appendix,
> this isn't allowed by the draft.
> 

For the option 2, the network information is delivered on the first
Identity-Request.  In principle, it is similar to option 1 with the
exception that the initial Identity-Request is issued by the access
network proxy instead of the AP.

The option 3 allows , the current text in the appendix says : "... If
the local RADIUS proxy/server cannot route the message based on the
identity provided by the peer, it sends a second EAP Identity Request
containing the identity hint information."

I think we can address your concern by making the sentence more specific
like:

"
If the local RADIUS proxy/server cannot route the message *directly* to
the home RADIUS server based on the identity provided by the peer (i.e.,
there is not a direct roaming relationship between the access network
and the user's home network), it sends a second EAP Identity/Request
containing the identity hint information.
"

> 2) Have the clients issue a fake realm in
> order to cause a discovery packet to to be
> sent to them. Ugly...
> 

I agree!  Coming up with a fake realm could be challenging too!

> 3) Avoid this requirement (at least until
> link layers can provide the information).
> 
> What do people think? Should the document
> say something about this case?
> 
> (Personally, I think the third option is
> the reasonable one.)
> 

> --Jari
> 
> 
> 

Results generated by Tiger Technologies using MHonArc.