1. March 15, 2005 IETF #62 Minneapolis1 EAP Discovery draft-adrangi-eap-network-discovery-10.txt Farid Adrangi ( farid.adrangi@intel.com ) farid.adrangi@intel.com Victor Lortz (victor.lortz@intel.com ) victor.lortz@intel.com Farooq Bari (farooq.bari@cingular.com ) farooq.bari@cingular.com Pasi Eronon (pasi.eronen@nokia.com ) pasi.eronen@nokia.com Copyright © 2003, The Internet Society

2. March 15, 2005 IETF #62 Minneapolis2 Current Status / Next Steps Current Status –A number of issues were raised during IESG review –Authors made updates to address most of the issues in -08 thru -10 updates –Authors have proposed resolutions for the remaining issues (currently being discussed on the list) Next Steps –Resolve Open Issues – March 05 –Submit for final review – March -05

3. March 15, 2005 IETF #62 Minneapolis3 Issue List http://www.drizzle.com/~aboba/EAP/eapissues.html Issue Number StatusTypeDescription Proposed Resolution Issue 286IDSEL-08TechnicalSecurity IssueAccept Issue 287IDSEL-08Technical Roaming Model Issue Accept Issue 290IDSEL-10TechnicalState TrackingAccept Issue 293PendingTechnicalClient BehaviorDiscuss

4. March 15, 2005 IETF #62 Minneapolis4 Issue 293 (Submitted by Glen Zorn) Issue : The document does not define the required client behavior. Resolution : –Authors View: Description of client behavior is outside the scope of the draft. However, 3GPP TS24.234 describes the client behavior in detail. –Proposed Text to the Introduction section: “ Exactly how the selection is made by the peer depends largely on the peer's local policy and configuration, and is outside the scope of this document. For example, the peer could decide to use one of its other identities, decide to switch to another access network, or attempt to reformat its NAI [rfc2486bis] to assist in proper AAA routing. The exact client behaviour is described by standard bodies using this specification such as 3GPP [TS.24.234].” -Status: Discuss

5. March 15, 2005 IETF #62 Minneapolis5 Issue #TBD (Submitted by Glen Zorn) Issue : The document is fuzzy about the role of AAA server/proxy with respect to handling EAP-Identity/Request and Response in section 2 Resolution: it is my understanding that the EAP-aware AAA proxy/server [RFC3579] in the access network can send EAP-Request/Identity within an Access-Challenge. –Revised Text for section 2.0: “The EAP authenticator MAY send an identity hint to the peer in the initial EAP- Request/Identity. If the identity hint is not sent initially (such as when the authenticator does not support this specification), then if the local EAP-aware AAA proxy/server implementing this specification receives an AAA Request packet with an unknown realm, it SHOULD reply with an EAP-Request/Identity containing an identity hint. For example, in case of RADIUS, if the EAP-aware RADIUS proxy/server [RFC 3579] receives an Access-Request packet with an unknown realm in the UserName(1) attribute, then it can reply with an EAP-Request/Identity containing an identity hint within an Access-Challenge packet. See "option 3" in the appendix for the message flow diagram.” -Status: Discuss

6. March 15, 2005 IETF #62 Minneapolis6 Issue #TBD (Submitted by Glen Zorn) Issue : The document needs some editorial work Resolution: -Authors have made a number of editorial changes throughout the document for clarification and readability purposes. A summary of editorial changes can be found here: -http://mng.ctgisp.com/IETF/EAP/Network%20Selection/Editorial_changes.txthttp://mng.ctgisp.com/IETF/EAP/Network%20Selection/Editorial_changes.txt The updated draft with editorial changes can be found here: http://mng.ctgisp.com/IETF/EAP/Network%20Selection/draft-adrangi-eap-network- discovery-11-01.txthttp://mng.ctgisp.com/IETF/EAP/Network%20Selection/draft-adrangi-eap-network- discovery-11-01.txt -Status: Discuss

7. March 15, 2005 IETF #62 Minneapolis7 Issue #TBD (Submitted by Glen Zorn) Issue : EAP problem statement and 2484bis references need to be updated Resolution: – Will be fixed in version 11 of the draft