eap Mailing List: RE: RE: a question related to the eap network discovery solution draft

[Ruffino Simone (Simone.Ruffino]

Hi to all.

Option 2) with modified text is OK for me.

Regards,
Simone



> -----Original Message-----
> From: Adrangi, Farid [mailto:farid.adrangi [at] intel.com]
> Sent: giovedì 23 settembre 2004 22.40
> To: Ruffino Simone; jari.arkko [at] piuha.net
> Cc: eap [at] frascone.com
> Subject: RE: [eap] RE: a question related to the eap network discovery
> solution draft
> 
> 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.
> 
> BR,
> Farid
> 
> > -----Original Message-----
> > From: Ruffino Simone [mailto:Simone.Ruffino [at] TILAB.COM]
> > Sent: Wednesday, September 22, 2004 6:43 AM
> > To: eap [at] frascone.com
> > Cc: Adrangi, Farid
> > Subject: RE: [eap] RE: a question related to the eap network
> > discovery solution draft
> >
> >
> >
> > Here I support Farid's proposed change, but I would leave
> > space for sending hints also in response to a valid
> > (routable) realm, i.e.,  not only when an unacceptable realm
> > is received.
> >
> > So I propose in Sec. 6, Option 3 the following change :
> >
> > "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."
> >
> > With (first part is Farid's proposal):
> >
> > "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 EAP server MAY
> > reply with an
> > identity hint also when an acceptable NAI realm is received in the
> > EAP Identity/Response, e.g. to support manual selection of mediating
> > networks."
> >
> > Comments appreciated...
> >
> > Regards,
> > Simone
> >
> >
> > > -----Original Message-----
> > > From: eap-admin [at] frascone.com
> > [mailto:eap-admin [at] frascone.com] On Behalf Of
> > > Adrangi, Farid
> > > Sent: mercoledì 22 settembre 2004 4.03
> > > To: jari.arkko [at] piuha.net; eap [at] frascone.com
> > > Subject: [eap] RE: a question related to the eap network discovery
> > > solution draft
> > >
> > > 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
> > > >
> > > >
> > > >
> > > _______________________________________________
> > > eap mailing list
> > > eap [at] frascone.com
> > > http://mail.frascone.com/mailman/listinfo/eap
> >
> >
> > Gruppo Telecom Italia - Direzione e coordinamento di Telecom
> > Italia S.p.A.
> >
> > ====================================================================
> > CONFIDENTIALITY NOTICE
> > This message and its attachments are addressed solely to the persons
> > above and may contain confidential information. If you have received
> > the message in error, be informed that any use of the content hereof
> > is prohibited. Please return it immediately to the sender and delete
> > the message. Should you have any questions, please send an e_mail to
> > MailAdmin [at] tilab.com. Thank you
> > ====================================================================
> >


Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
MailAdmin [at] tilab.com. Thank you
====================================================================