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.

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

____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.
frascone.com/pipermail/eap

review of draft-ietf-eap-netsel-problem-04.txt

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