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

[Jari Arkko (jari.arkko]

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.

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.

>    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.

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.

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.

>    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.

>  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
>  
>
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.

--Jari