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

[Adrangi, Farid (farid.adrangi]

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

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko [at] piuha.net] 
> Sent: Wednesday, June 02, 2004 12:56 PM
> To: eap [at] frascone.com; Adrangi, Farid
> Subject: comments on draft-adrangi-eap-network-discovery-00.txt
> 
> 
> 
> 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.
> 
Agree.
> > Option 2 is also equally desirable if
> >    the AP supports the EAP-Start message.
> 
> Is this something that RFC 3579 mandates? 
No RFC 3579 does not mandate EAP-start.
> If so, you could 
> state this, and indicate that not all APs support this yet.
> 
Ok.
> >    [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.
> 
Good catch!
> >    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.
> 
Ok.  I think here you mean there is no direct route .... ?

>     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.
Right.
>  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.
> 
Ok.  But, the intention here is to convey mediating network names that a
WLAN AN has an agreement with.

> 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.
> 
Will fix all the above editorial comments.

> > ABNF
> 
> I think you told me earlier but I have forgotten if your
> 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?