Subject: RE: [eap] RE: draft-adrangi-eap-network-discovery-11.txt

From: "Adrangi, Farid" <[email-masked]>
Date: Tue, 5 Apr 2005 13:48:06 -0700

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:[email-masked]] 
> Sent: Tuesday, April 05, 2005 1:27 PM
> To: Adrangi, Farid
> Cc: [email-masked]; 'Bernard Aboba'; [email-masked]
> Subject: RE: [eap] RE: draft-adrangi-eap-network-discovery-11.txt
> 
> 
> Adrangi, Farid <mailto:[email-masked]> 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" <[email-masked]>
> >>>> To: Bernard Aboba <[email-masked]>
> >>>> Cc: [email-masked], [email-masked], Jari Arkko
> >>>>      <[email-masked]>, [email-masked], [email-masked],
> >>>>      [email-masked], Eugene Chang
> <[email-masked]>
> >>>> 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:[email-masked]]
> >>>>> Sent: Saturday, April 02, 2005 5:08 PM
> >>>>> To: Adrangi, Farid
> >>>>> Cc: [email-masked]; [email-masked]; Jari Arkko;
> [email-masked];
> >>>>> [email-masked]; [email-masked]; 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
> >>> [email-masked] 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
> >> [email-masked]
> >> 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
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap