Subject: [eap] comments on draft-adrangi-eap-network-discovery-00.txt

From: Jari Arkko <[email-masked]>
Date: Wed, 02 Jun 2004 22:56:28 +0300

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

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Adrangi, Farid" <[email-masked]>
Date: Wed, 2 Jun 2004 18:30:13 -0700

Hi Jari,
Thanks so much for your detailed review and comments.  Please see my
responses below.
BR,
Farid

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Wednesday, June 02, 2004 12:56 PM
> To: [email-masked]; Adrangi, Farid
> Subject: comments on draft-adrangi-eap-network-discovery-00.txt
> 
> 
> 
> Hi Farid,
> 
> 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:
> 
Agree.
> Is this something that RFC 3579 mandates? 
No RFC 3579 does not mandate EAP-start.
> If so, you could 
Ok.
> reference, or at least moving to informative section.
Good catch!
>     routing assistance is given.
Ok.  I think here you mean there is no direct route .... ?

>     just available via the web.
Right.
>  Similarly, dynamic communication of
Ok.  But, the intention here is to convey mediating network names that a
WLAN AN has an agreement with.

> >        Intellectual Property and Copyright Statements . . . 
> . . . . . 
> > 16
> 
> If these options were ordered 3, 2, 1, I think they would be 
> easier to understand.
> 
Will fix all the above editorial comments.

> ABNF passed the ABNF checker. It should pass it.

I need to make minor changes to the ABNFs

1) identity-request-data ABNF

   identity-request-data = displayable-string [ %d0 network-info ]
   displayable-string = *CHAR

   network-info = item ["," item ]
   item = attribute "=" value

   attribute =  1*( ALPHA / "-" / "_" / DIGIT)

   value = 1*( 0x01-2B / 0x2D-FF ) ; any non-null UTF-8 char except ","

Change:  in the last line, replace (0x01-2B / 0x2D-FF) with (%x01-2B /
%x2D-FF)

2) value ABNF

   value = Realm [ ";" Realm ]

   Realm = *( domainlabel "." ) toplabel

   domainlabel    =  alphanum *( alphanum / "-" )
   toplabel         =  ALPHA *alphanum

Change: replace the last two lines with

   domainlabel    =  (ALPHA / DIGIT) *( ALPHA / DIGIT / "-" )
   toplabel         =  ALPHA * (ALPHA / DIGIT)

Both modified ABNF pass the ABNF checker with a small problem!  And that
is, I get the following messages for the above ABNFs:

1)
unreferenced rule: identity-request-data
ABNF validation (version 1.0) completed

2)
unreferenced rule: value
ABNF validation (version 1.0) completed

However, I don't think this is a problem, because I would get the same
message if run something simple like:

        rulename    =  %d97 %d98 %d99

Then, I get the similar message:

unreferenced rule: rulename
ABNF validation (version 1.0) completed

Agree?