RE: RE: draft-adrangi-eap-network-discovery-11.txt
From: Adrangi, Farid (farid.adrangiintel.com)
Date: Tue, 5 Apr 2005 16:48:11 -0400 (EDT)
Ok. So, we can revise the text as follows:

"
If the peer responds with an EAP-Response/Identity containing an
unknown realm after the local AAA proxy/server sends an identity
hint, then the local AAA proxy/server MUST respond with an EAP
Failure packet.  The local AAA proxy/server MAY also send an
EAP-Notification message providing the reason for the failure prior 
to the EAP Failure packet.
"

Will this work for you?

BR,
Farid

> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:gwz [at] cisco.com] 
> Sent: Tuesday, April 05, 2005 1:27 PM
> To: Adrangi, Farid
> Cc: jsalowey [at] cisco.com; 'Bernard Aboba'; eap [at] frascone.com
> Subject: RE: [eap] RE: draft-adrangi-eap-network-discovery-11.txt
> 
> 
> Adrangi, Farid <mailto:farid.adrangi [at] intel.com> supposedly
> scribbled:
> 
> > "
> > If the peer responds with an EAP-Response/Identity containing an
> > unknown realm after the local AAA proxy/server sends an identity
> > hint, then the local AAA proxy/server MUST respond with an EAP
> > Failure packet.  The local AAA proxy/server MAY also send an
> > EAP-Notification message providing the reason for the failure."
> 
> > 
> > Will this work for you?
> 
> I'm pretty sure that the EAP-{Request, Response}/Notification
> exchange has to come before EAP Failure; if you could make that
> sequential character clear (which I attempted to do, but apparently
> failed), it would be great.
> 
> > 
> > 
> >> 3.  The message flows in the Appendix only shoe the success cases
> --
> >> it would be nice if at least one failure case was illustrated.
> > 
> > [FA] Ok.  I will a failure case to one of the delivery options.
> > 
> >>> 
> >>>> 
> >>>> ---------- Forwarded message ----------
> >>>> Date: Sun, 3 Apr 2005 21:29:40 -0700
> >>>> From: "Adrangi, Farid" <farid.adrangi [at] intel.com>
> >>>> To: Bernard Aboba <aboba [at] internaut.com>
> >>>> Cc: eap [at] frascone.com, iesg [at] ietf.org, Jari Arkko
> >>>>      <jari.arkko [at] piuha.net>, gwz [at] cisco.com, jsalowey [at] 
> >>>> cisco.com,
> >>>>      Pasi.Eronen [at] nokia.com, Eugene Chang
> <eugene.chang [at] funk.com>
> >>>> Subject: RE: [eap] RE: FW: I-D
> >>>>     ACTION:draft-adrangi-eap-network-discovery-11.txt
> >>>> 
> >>>> I don't recall talking about an IESG note on the mailing list!
> >>>> Anyhow, as to your strawman IESG note, it should be noted that
> the
> >>>> draft was reviewed and accepted by IEEE 802.11 (WIEN? - the WG
> has
> >>>> sent an official review report to IETF.  And also, I would
> remove
> >>>> the last part of the note: "and it is not recommended for
> >>>> implementation outside of 3GPP."  I think we should state the
> >>>> facts about the solution and let the implementer decided
> whether
> >>>> or not the solution is suitable for their deployments outside
> >>>> 3GPP. BR, Farid 
> >>>> 
> >>>>> -----Original Message-----
> >>>>> From: Bernard Aboba [mailto:aboba [at] internaut.com]
> >>>>> Sent: Saturday, April 02, 2005 5:08 PM
> >>>>> To: Adrangi, Farid
> >>>>> Cc: eap [at] frascone.com; iesg [at] ietf.org; Jari Arkko;
> gwz [at] cisco.com;
> >>>>> jsalowey [at] cisco.com; Pasi.Eronen [at] nokia.com; Eugene Chang
> >>>>> Subject: RE: [eap] RE: FW: I-D
> >>>>> ACTION:draft-adrangi-eap-network-discovery-11.txt
> >>>>> 
> >>>>> 
> >>>>> I think we were talking about an IESG note in addition to
> material
> >>>>> in the applicability statement, no?
> >>>>> 
> >>>>> For example, EAP SIM contains the following note:
> >>>>> 
> >>>>> IESG Note
> >>>>> 
> >>>>> The EAP-SIM protocol was developed by 3GPP.  The documentation
> of
> >>>>> EAP-SIM is provided as information to the Internet community.
> >>>>> While the EAP WG has verified that EAP-SIM is compatible with
> EAP
> >>>>> as defined in RFC 3748, no other review has been done,
> including
> >>>>> validation of the security claims.
> >>>>> 
> >>>>> Here is a potential strawman note for the EAP Network
> Discovery
> >>>>> document: 
> >>>>> 
> >>>>>  EAP Network Discovery was developed by 3GPP.  Documentation
> is
> >>>>> provided as information to the Internet community.  While the
> EAP
> >>>>> WG has verified that EAP Network Discovery is compatible with 
> >>>>> EAP as defined in RFC 3748, no other review has been done,
> >>>>> including investigation of potential security issues.  There
> is
> >>>>> work underway in IEEE 802.11 which may provide similar
> >>>>> functionality, enabling an EAP peer to determine network
> >>>>> availability prior to  handoff. As a result, the approach
> >>>>> described in this document may  be superceded by future
> >>>>> standards, and it is not recommended for implementation
> outside
> >>>>> of 3GPP. 
> >>> 
> >>> Hope this helps,
> >>> 
> >>> ~gwz
> >>> 
> >>> Why is it that most of the world's problems can't be solved by
> >>>   simply listening to John Coltrane? -- Henry Gabriel
> >>> _______________________________________________ eap mailing list
> >>> eap [at] frascone.com http://mail.frascone.com/mailman/listinfo/eap
> >> 
> >> Hope this helps,
> >> 
> >> ~gwz
> >> 
> >> Why is it that most of the world's problems can't be solved by
> simply
> >>   listening to John Coltrane? -- Henry Gabriel
> >> _______________________________________________
> >> eap mailing list
> >> eap [at] frascone.com
> >> http://mail.frascone.com/mailman/listinfo/eap
> 
> Hope this helps,
> 
> ~gwz
> 
> Why is it that most of the world's problems can't be solved by
> simply
>   listening to John Coltrane? -- Henry Gabriel
> 

Results generated by Tiger Technologies using MHonArc.