eap Mailing List: comments on draft-adrangi-eap-network-discovery-00.txt

[Jari Arkko (jari.arkko]

Hi Farid,

Thanks for working on this draft. I think it looks
pretty reasonable -- certainly not the final word
in network selection for future link layers, but
something which is simple enough to be understood
and sufficiently modular to be replaced by future
schemes should they become available. I have
some comments below, but the document is short and
to the point; and I don't see a need for too many
updates cycles of this draft unless someone comes
up with new issues.

Substantial:

>    1.  A general data model and syntax by which network information is
>        structured for unambiguous interpretation by the wireless client.

This seems to imply that other information than the mediating
networks could be passed this way. Other parts of the document
don't make this possible -- and that is very good. But maybe the text
above could be changed to:

   1.  A syntax by which mediating network information can be
       represented.

> Option 2 is also equally desirable if
>    the AP supports the EAP-Start message.

Is this something that RFC 3579 mandates? If so, you could
state this, and indicate that not all APs support this yet.

>    [5]  Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

I'm not sure you actually use the RADIUS accounting in
this document for anything, except in one definition and
even there it seems unnecessary. Suggest deleting the
reference, or at least moving to informative section.

>    The following describes the three options with pros and cons of each.

This reminds me: I think you should also include some
warnings about the effects and limitations of EAP-level
discovery schemes. Here's some suggested text:

   The use of EAP for network selection on all
   attachments will have a substantial adverse impact on roaming
   performance without appropriate lower layer support (such as
   support for Class 1 data frames within IEEE 802.11). As a
   result, the use of the mechanism described in this document
   SHOULD be reserved for situations where there indeed is
   no route to the home network unless some client-provided
   routing assistance is given.

   Only a very limited amount of information about AAA routes can be
   dynamically communicated.  It is necessary to retrieve network and
   intermediary names, but quality of service or pricing information is
   clearly something that would need to be pre-provisioned, or perhaps
   just available via the web.  Similarly, dynamic communication of
   network names can not be expected to provide all possible home
   network names, as their number can be quite large globally.

Editorial:

>    6.2   Informative References . . . . . . . . . . . . . . . . . . .  9
>        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  9
>        Intellectual Property and Copyright Statements . . . . . . . . 16

Appendix is missing from the table of contents.

> ,And

In figure 1, change s/,And/and/. Appears twice.

>                 Figure 3: Ambiguous AAA routing

I don't see a Figure 2 anywhere.

> Network Information

It could be my language skills, but "network information"
feels better, at least the way its used in the document.
Maybe "mediating network information".

>    Option 1
>
>       Use a subsequent EAP-Identity Request issued by the access network
>       RADIUS server.
>
>    Option 2
>
>       Use the initial EAP-Identity Request issued by the access network
>       RADIUS server.
>
>    Option 3
>
>       Use the Initial EAP-Identity Request issued by the access network
>       NAS.

If these options were ordered 3, 2, 1, I think they would be easier
to understand.

> ABNF

I think you told me earlier but I have forgotten if your
ABNF passed the ABNF checker. It should pass it.

--Jari