Subject: RE: [eap] RE: FW: I-D ACTION:draft-adrangi-eap-network-discovery-11.txt

From: "Adrangi, Farid" <[email-masked]>
Date: Sun, 3 Apr 2005 21:29:40 -0700

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.
> 
> 
> On Thu, 31 Mar 2005, Adrangi, Farid wrote:
> 
> > Sorry, just to be clear, the link below contains the update 
> we made to
> > the applicability section in -011 version, based on Glen's 
> comment on
> > -10 version in the last WG meeting.
> > Thanks,
> > Farid
> >
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > On Behalf Of Adrangi, Farid
> > > Sent: Thursday, March 31, 2005 9:33 AM
> > > To: Bernard Aboba
> > > Cc: [email-masked]; [email-masked]; Jari Arkko;
> > > [email-masked]; [email-masked]; [email-masked]; 
> Eugene Chang
> > > Subject: [eap] RE: FW: I-D
> > > ACTION:draft-adrangi-eap-network-discovery-11.txt
> > >
> > >
> > > I think so! The applicability section was introduced in 
> version -08.
> > > Since then we have made several updates to that section based on
> > > comments from Glen Zorn, Eugene Chang, Jari Arkko, and 
> yourself.  The
> > > updates to this section was made based on Glen Zorn's comment
> > > during the
> > > last IETF meeting (relayed to me by Pasi) -- the exact change is
> > > captured in
> > > http://mng.ctgisp.com/IETF/EAP/Network%20Selection/issues-1.tx
> > > t  -- see
> > > #3.  Please let me know if you have any questions.
> > > BR,
> > > Farid
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Bernard Aboba [mailto:[email-masked]]
> > > > Sent: Thursday, March 31, 2005 9:08 AM
> > > > To: Adrangi, Farid
> > > > Cc: [email-masked]; [email-masked]; Jari Arkko;
> > > > [email-masked]; [email-masked]
> > > > Subject: Re: FW: I-D
> > > ACTION:draft-adrangi-eap-network-discovery-11.txt
> > > >
> > > >
> > > > As I recall there was a discussion relating to the appropriate
> > > > applicability statement that should be attached to this 
> document.
> > > >
> > > > Have we come to agreement on what the applicability statement
> > > > should be?
> > > >
> > > > On Mon, 28 Mar 2005, Adrangi, Farid wrote:
> > > >
> > > > > Hi Everyone,
> > > > > In this version, we have done some editorial fixes 
> through out the
> > > > > document and addressed issues brought up during IESG review.
> > > > > ** Editorial changes are summarized in
> > > > >
> > > > http://mng.ctgisp.com/IETF/EAP/Network%20Selection/Editorial_c
> > > > hanges.txt
> > > > > ** List of issues with their resolutions are summarized in
> > > > > 
> http://mng.ctgisp.com/IETF/EAP/Network%20Selection/issues-1.txt
> > > > > Thanks,
> > > > > Farid
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: [email-masked]
> > > > > > [mailto:[email-masked]] On Behalf Of
> > > > > > [email-masked]
> > > > > > Sent: Monday, March 28, 2005 8:04 AM
> > > > > > To: [email-masked]
> > > > > > Subject: I-D 
> ACTION:draft-adrangi-eap-network-discovery-11.txt
> > > > > >
> > > > > >
> > > > > > A New Internet-Draft is available from the on-line
> > > > > > Internet-Drafts directories.
> > > > > >
> > > > > >
> > > > > > 	Title		: Identity selection hints for
> > > > > > Extensible Authentication
> > > > > > 			  Protocol (EAP)
> > > > > > 	Author(s)	: F. Adrangi, et al.
> > > > > > 	Filename	:
> > > draft-adrangi-eap-network-discovery-11.txt
> > > > > > 	Pages		: 13
> > > > > > 	Date		: 2005-3-25
> > > > > >
> > > > > > The Extensible Authentication Protocol (EAP) is defined
> > > > in RFC 3748.
> > > > > >    This document defines a mechanism that allows an
> > > > access network to
> > > > > >    provide identity selection hints to an EAP peer.  The
> > > > purpose is to
> > > > > >    assist the EAP peer in selecting an appropriate
> > > Network Access
> > > > > >    Identifier (NAI) when there is no direct roaming
> > > > > > relationship between
> > > > > >    the access network and the peer's home network.  In
> > > this case,
> > > > > >    authentication is typically accomplished via a mediating
> > > > > > network such
> > > > > >    as a roaming consortium or broker.
> > > > > >
> > > > > > A URL for this Internet-Draft is:
> > > > > > 
> http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-
> > > > > discovery-11.txt
> > > > >
> > > > > To remove yourself from the I-D Announcement list, send a
> > > message to
> > > > > [email-masked] with the word unsubscribe in
> > > > the body of
> > > > > the message.
> > > > > You can also visit
> > > > https://www1.ietf.org/mailman/listinfo/I-D-announce
> > > > > to change your subscription settings.
> > > > >
> > > > >
> > > > > Internet-Drafts are also available by anonymous FTP.
> > > Login with the
> > > > > username
> > > > > "anonymous" and a password of your e-mail address. After
> > > logging in,
> > > > > type "cd internet-drafts" and then
> > > > > 	"get draft-adrangi-eap-network-discovery-11.txt".
> > > > >
> > > > > A list of Internet-Drafts directories can be found in
> > > > > http://www.ietf.org/shadow.html
> > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > > >
> > > > >
> > > > > Internet-Drafts can also be obtained by e-mail.
> > > > >
> > > > > Send a message to:
> > > > > 	[email-masked].
> > > > > In the body type:
> > > > > 	"FILE
> > > > > /internet-drafts/draft-adrangi-eap-network-discovery-11.txt".
> > > > >
> > > > > NOTE:	The mail server at ietf.org can return the document in
> > > > > 	MIME-encoded form by using the "mpack" utility. 
>  To use this
> > > > > 	feature, insert the command "ENCODING mime" 
> before the "FILE"
> > > > > 	command.  To decode the response(s), you will 
> need "munpack" or
> > > > > 	a MIME-compliant mail reader.  Different 
> MIME-compliant mail
> > > > > readers
> > > > > 	exhibit different behavior, especially when dealing with
> > > > > 	"multipart" MIME messages (i.e. documents which 
> have been split
> > > > > 	up into multiple messages), so check your local 
> documentation on
> > > > > 	how to manipulate these messages.
> > > > >
> > > > >
> > > > > Below is the data which will enable a MIME compliant 
> mail reader
> > > > > implementation to automatically retrieve the ASCII 
> version of the
> > > > > Internet-Draft.
> > > > >
> > > >
> > > _______________________________________________
> > > 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: "Glen Zorn (gwz)" <[email-masked]>
Date: Mon, 4 Apr 2005 19:55:54 -0700

Adrangi, Farid <mailto:[email-masked]> supposedly
scribbled:

> 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 

I'm not sure what this means.  Does it mean accepted as in "whatever
you want to do" or as in adopted as correct?  

> (WIEN? - 

Last time I checked, WIEN was just a study group (the 802.11
equivalent of a BOF).  Has this changed?

> the WG has
> sent an official review report to IETF.  

Did we receive a liaison from the 802.11 Working Group or a note
from the WIEN Study Group?  There's a big difference...

> 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 

Unless the draft has changed drastically for the better, the facts
were pretty slim, certainly too slim for it to be called a
"solution" (without volumes of supporting documentation).

> and let the implementer decided whether or not the solution
> is suitable for their deployments outside 3GPP. 

If and when the RFC Editor becomes a vanity publisher for 3GPP, I
will agree; until then, however, I think that we at least a right
(if not a duty) to publish applicability statements that express the
opinions of the IETF (regardless if those opinions coincide with
those of the author(s)).

>> Cc: [email-masked]; [email-masked]; Jari Arkko; [email-masked];
>> [email-masked]; [email-masked]; Eugene Chang
material in
>> the applicability statement, no?
>> 
>>    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
>> Here is a potential strawman note for the EAP Network Discovery
>> document: 
>> 
>>    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.
>> 
>> 
>>> Sorry, just to be clear, the link below contains the update we
made
>>> to the applicability section in -011 version, based on Glen's
>>> comment on -10 version in the last WG meeting.
>>> Thanks,
>>> Farid
>>> 
>>> 
>>>> From: [email-masked] [mailto:[email-masked]] On
>>>> Behalf Of Adrangi, Farid Sent: Thursday, March 31, 2005 9:33 AM
>>>> To: Bernard Aboba
>>>> Cc: [email-masked]; [email-masked]; Jari Arkko; [email-masked];
>>>> [email-masked]; [email-masked]; Eugene Chang
>>>> I think so! The applicability section was introduced in version
>>>> -08. Since then we have made several updates to that section
based
>>>> on comments from Glen Zorn, Eugene Chang, Jari Arkko, and
>>>> yourself.  The updates to this section was made based on Glen
>>>> Zorn's comment during the last IETF meeting (relayed to me by
>>>> Pasi) -- the exact change is captured in
[email-masked];
>>>>> [email-masked] Subject: Re: FW: I-D
document.
>>>>>> In this version, we have done some editorial fixes through
out
>>>>>> the document and addressed issues brought up during IESG
review.
>>>>>>> [email-masked] Sent: Monday, March 28, 2005 8:04
AM
>>>>>>> The Extensible Authentication Protocol (EAP) is defined in
RFC
>>>>>>>    3748. This document defines a mechanism that allows an
>>>>>>>    access network to provide identity selection hints to an
EAP
>>>>>>>    peer.  The purpose is to assist the EAP peer in selecting
an
>>>>>>>    appropriate Network Access Identifier (NAI) when there is
no
>>>>>>>    direct roaming relationship between the access network
and
>>>>>>>    the peer's home network.  In this case, authentication is
>>>>>>>    typically accomplished via a mediating network such as a
>>>>>>> roaming consortium or broker. 
>>>>>>> 
>>>>>> message to [email-masked] with the word
>>>>>> unsubscribe in the body of the message. You can also visit
>>>>>> Internet-Drafts are also available by anonymous FTP. Login
with
>>>>>> the username "anonymous" and a password of your e-mail
address.
>>>>>> After logging in, type "cd internet-drafts" and then
>>>>>> http://www.ietf.org/shadow.html or
>>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>>> 
>>>>>> 
>>>>>> 	feature, insert the command "ENCODING mime" before the
"FILE"
>>>>>> 	command.  To decode the response(s), you will need "munpack"
or
>>>>>> 	a MIME-compliant mail reader.  Different MIME-compliant mail
>>>>>> 	readers exhibit different behavior, especially when dealing
with
>>>>>> 	"multipart" MIME messages (i.e. documents which have been
split
documentation on
>>>>>> Below is the data which will enable a MIME compliant mail
reader
>>>>>> implementation to automatically retrieve the ASCII version of
>>>>>> the Internet-Draft. 
>>>>>> 
>>>>> 

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

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 4 Apr 2005 23:11:33 -0700 (PDT)

> equivalent of a BOF).  Has this changed?

Yes, it has.  WIEN has now been chartered as 802.11u.

> from the WIEN Study Group?  There's a big difference...

We got a note from WIEN indicating that they had reviewed the document and
found that it was not in conflict with the proposed PAR for 802.11u.

Having said that, the 802.11u PAR does authorize work on network selection
within state 1 (unassociated, unauthenticated; EAP network discovery
requires the STA to be in state 3 (associated, authenticated).