Subject: RE: [eap] RE: a question related to the eap network discovery solution draft

From: "Bari, Farooq" <[email-masked]>
Date: Tue, 5 Oct 2004 20:24:42 -0700

Folks,

To my knowledge we have successfully passed IEEE review of this draft.
Also in the past week or so,  I have not seen any disagreement to Jari
nad Farid's proposal in the following email. I am assuming that with
this final fix we have passed the pseudo last call for this draft. Can
the chairs please confirm this and let us know what the next steps for
this draft need to be.

BR,

Farooq

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrangi, Farid
Sent: Wednesday, September 29, 2004 10:02 AM
To: [email-masked]
Cc: Ruffino Simone; [email-masked]
Subject: RE: [eap] RE: a question related to the eap network discovery
solution draft

Hi Jari,
I agree.  My preference is "do nothing"!  However, I like your proposed
text for discouraging the use of the alternative 2.  
BR,
Farid

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Wednesday, September 29, 2004 4:09 AM
> To: Adrangi, Farid
> Cc: Ruffino Simone; [email-masked]
> Subject: Re: [eap] RE: a question related to the eap network 
> discovery solution draft
> 
> 
> Personally, I'd rather avoid this particular change. The
> reason for this is what I described in the original message:
> additional latency. In particular, an access network is
> not in a position to know whether or not the client wants
> to do manual selection or not. Most likely only a small
> fraction of clients would be doing this (in GSM its relatively
> rare in my understanding). So, everyone else would end up
> paying a roundtrip for the benefit of the few.
> 
> In fact, I'd rather see as choosing between doing nothing,
> or making the text more restrictive than it currently is.
> We currently prohibit "unnecessary" advertisements. Perhaps
> what we could add is some text that discourages the use of
> alternative 2 from my original e-mail. For instance, we
> could say "Note that EAP peers could force the access network
> to generate an advertisement by supplying a NAI that is not
> routable by the access network. However, such usage is NOT
> RECOMMENDED due to the difficulty of finding a NAI that is
> known to be non-routable. Also, this usage is problematic
> when it is not certain that the network supports this
> specification or when the authentication attempt uses
> resources from a number of proxies on the default route
> until it is found to be invalid."
> 
> What do you think?
> 
> --Jari
> 
> Adrangi, Farid wrote:
> > Jari, Simone, all
> > 
> > 
> > Going forward, so far there are two options:
> > 
> > 1) Do nothing
> > 
> > 2) We can reword the following paragraph in Sec. 6, Option 
> 3 for more clarification.
> > 
> > Current text:
> > 
> > "If the RADIUS 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."
> > 
> > Modified Text:
> > 
> > "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. The RADIUS proxy/server may 
> also Send identity hint even when an acceptable NAI realm 
> (i.e., can be routed directly to the home RADIUS server) is 
> received in the EAP Identity/Response."
> > 
> > I believe the WG LS call expires today -- so it would be 
> nice to have a closure on this soon.
> 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 5 Oct 2004 20:41:37 -0700 (PDT)

The EAP Issues List is the definitive list of open issues relating to this
document.  That list contains a number of issues which remain open.