eap Mailing List: Re: review of draft-ietf-eap-netsel-problem-04.txt

[Bari, Farooq (farooq.bari]

See responses inline.

BR,

Farooq

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko [at] piuha.net]
> Sent: Wednesday, September 06, 2006 7:41 AM
> To: eap [at] frascone.com; jouni.korhonen [at] teliasonera.com
> Subject: [eap] review of draft-ietf-eap-netsel-problem-04.txt
> 
> 
> I have reviewed the latest version of this
> draft.
> 
> Overall, I liked this version much more
> than the previous ones. The new terminology
> and problem definitions are great.
> 
> There are a few relatively small issues
> left, however. Please see below:
> 
> ISSUE: RFC 2606 compliance.
> 
> >          Figure 1: Two credentials, three possible access networks
> 
> The examples in this figure (and elsewhere) need to
> conform to RFC 2606, e.g., example.com instead of
> example1.com.
> 
[Bari, Farooq] Agree to update the draft accordingly.

> ISSUE: NAI hint recommendation strength
> 
> >    As a result, network-based AAA routing mechanisms are preferred
over
> >    user-based selection where sufficient routes have been configured
and
> >    there is no need for user control.  Where these conditions are
not
> >    met -- particularly when an attempt to use the network-based
routing
> >    mechanism has failed -- routing hints can be placed in an NAI as
> >    defined in [12].
> 
> I would like to make the above a bit stronger. How about
> 
>    As a result, network-based AAA routing mechanisms should be used
>    instead of user-based selection where sufficient routes exist.  In
>    an error situation, such as when an attempt to use the
network-based
> routing
>    mechanism has failed, routing hints can be advertised and used as
>    defined in [13] and [12]. Even so, such approaches have severe
>    scalability limitations. See Section 3.1 for further discussion.
> 
[Bari, Farooq] Agree

> >    Since RFC 1035 [1] enables FQDNs to be
> >    up to 255 octets in length, this may not enable the announcement
of
> >    many realms, although if SSIDs are used, the maximum length of 32
> >    octets per SSID may provide somewhat better scaling.  The use of
> >    other network identifiers than domain names is also possible, for
> >    instance the PANA protocol uses an a free form string and an SMI
> >    Network Management Private Enterprise Code [17], or Mobile
Network
> >    Codes embedded in NAIs as specified in 3GPP.
> 
> I don't think we should talk about SSIDs here because
> [13] explicitly uses realms, not SSIDs (and the proliferation
> of new Id Request parameters would be harmful). If
> MNCs are embedded in NAIs, this does not really reduce
> the length all that much. I think this leaves only the PANA
> example, even if the general point is valid.
> 
[Bari, Farooq] Agree. Bernard had comment on the same part. Propose the
following text.

Since RFC 1035 [1] enables FQDNs to be up to 255 octets in length, this
may not enable the announcement of many realms. The use of other network
identifiers than domain names is also possible, for instance the PANA
protocol uses a free form string and an SMI  Network Management Private
Enterprise Code [17], or Mobile Network Codes embedded in NAIs as
specified in 3GPP.

> ISSUE: Extensibility in 3GPP section
> 
> >    o  Extensibility is desired, to allow the advertisement of other
> >       parameters later.  The current network advertisement and
selection
> >       is based on [12].
> >
> The right reference is [13] and [12], I think.
> 
> In addition, both references are very explicit
> about extensibility to other parameters: this
> is discouraged. As a result the statement in the
> draft is quite misleading. Delete the bullet item
> or reformulate.
> 
[Bari, Farooq] Agree to delete the bullet.

> Editorial:
> 
> ISSUE: Editorial
> 
> Overall, the editorial state of the document
> is good. My main problem was that the same
> topic (e.g. properties of the Adrangi scheme)
> is discussed in several different parts of the
> document. But I did not come up with a better
> organization, so I'm fine with this as it is.
> 
> Smaller issues:
> 
> >                 Network Discovery and Selection Problem
> > ...
> > Abstract
> >
> >    The so called realm discovery and selection problem affects
network
> >    access, particularly in the presence of multiple available
wireless
> >    accesses and roaming.  This problem has been the subject of
> >    discussions in various standards bodies.  This document
summarizes
> >    the discussion held about this problem in the Extensible
> >    Authentication Protocol (EAP) working group at the IETF.  The
problem
> >    is defined and divided into subproblems, and some constraints for
> >    possible solutions are outlined.  The document also provides a
> >    discussion of the limitations of certain classes of solution,
> >    including some that have been previously defined.
> 
> There a mismatch between the title and the abstract (realm vs.
> network). I think most of the document deals with realm discovery,
> but you could also start with a network discovery title and explain
> that the realm discovery is a part of the network discovery. This
> would actually be my preference, because one of useful features
> of this document is that it reminds people of the existence of
> various different types of discovery.
> 
[Bari, Farooq] Bernard had comments on the same topic in issue 376 and
378. Please see the proposal in response to issue 376.

> >    The realm discovery and selection problem becomes relevant when
any
> >    of the following conditions are true:
> >
> >    o  There is more than one available network attachment point, and
the
> >       different attachment points may have different characteristics
or
> >       belong to different operators.  In the case of virtual
operators,
> >       access network infrastructure including e.g. the access points
can
> >       be shared by multiple operators.
> 
> Presumably *realm* discovery is not an issue if you
> have a set of access points if they all provide the same
> authentication service. Maybe delete the part about different
> characteristics.
>
[Bari, Farooq] not sure I understood the comment. The reason for using
the term "different characteristics" was to indicate that the access
networks associated with the attachment points may be from different
technologies (e.g 802.11, 802.16, UMTS etc.) and therefore will have
different capabilities.
 
> >  Miscellaneous warnings:
> >  - Line 275 has weird spacing: '... realms  are a...'
> >  - Line 713 has weird spacing: '...lection  solut...'
> >
> >  Experimental warnings:
> >  - Unused Reference: '4' is defined on line 1019, but not referenced
> >  - Unused Reference: '6' is defined on line 1025, but not referenced
> >  - Unused Reference: '7' is defined on line 1029, but not referenced
> >  - Unused Reference: '9' is defined on line 1036, but not referenced
> >  - Unused Reference: '21' is defined on line 1086, but not
referenced
> >  - Unused Reference: '24' is defined on line 1097, but not
referenced
> >  - Unused Reference: '26' is defined on line 1103, but not
referenced
> >  - Unused Reference: '28' is defined on line 1109, but not
referenced
> >
> >
[Bari, Farooq] Agree to the fixes above.

> Please fix the above idnits warnings.
> 
> > As noted in [10] Section 4.x, the minimum EAP MTU is 1020 octets,
> 
> Delete Section 4.x, or provide the exact reference.
> 
[Bari, Farooq] Agree to delete "section 4.x" from the sentence.

> --Jari
> 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap