1) Issue xxx (Submitted by Glen Zorn)

Glen Writes:
"
There still seems to me to be a problem here.  The thinking
portrayed in the revised document seems awfully fuzzy to me.  This
is exemplified by the following: "If the identity hint is not sent
initially (such as when the authenticator does not support this
specification), then if the local AAA proxy/server implementing this
specification receives an EAP-Response/Identity with an unknown
realm, it SHOULD reply with an EAP-Request/Identity containing an
identity hint."  Of course, the AAA proxy _cannot_ receive an
EAP-Response, nor send an EAP-Request, since it is a _AAA_ proxy,
not an EAP entity of any variety.  This is the same thing that I
wrote about earlier, when I said that this draft is interfering with
the EAP protocol: it seems clear that whatever is sending these
"hints" is an EAP entity of some sort (because it is engaged in at
least a subset of the EAP protocol), but it's not a peer (since it's
not being authenticated), it's not an authenticator (since it's not
doing the authenticating) and it's not a server (since it doesn't
terminate the authentication method. So what is it?  
"


Proposed Resolution:
===================

Revise the second paragraph in section 2 as below:

"
The EAP authenticator MAY send an identity hint to the peer in the
initial EAP-Request/Identity.  If the identity hint is not sent
initially (such as when the authenticator does not support this
specification), then if the local EAP-aware AAA proxy/server
implementing this specification receives an AAA Request packet with an
unknown realm, it SHOULD reply with an EAP-Request/Identity containing
an identity hint.  For example, in case of RADIUS, if the EAP-aware
RADIUS proxy/server [RFC 3579] receives an Access-Request packet with an
unknown realm in the UserName(1) attribute, then it can reply with an
EAP-Request/Identity containing an identity hint within an
Access-Challenge packet. See "option 3" in the appendix for the
message flow diagram.
"


2) Issue 293 -- Client Behaviour (submitted by Glen Zorn)

The document does not define the required client behavior. 


Proposed Resolution:
====================

Revise the fourth paragraph in the introduction section as below: 

"
   Exactly how the selection is made by the peer depends largely on the
   peer's local policy and configuration, and is outside the scope of
   this document.  For example, the peer could decide to use one of its
   other identities, decide to switch to another access network, or
   attempt to reformat its NAI [rfc2486bis]  to assist in proper AAA
   routing.  The exact client behaviour is described by standard bodies
   using this specification such as 3GPP [TS.24.234].
"



3) Issue xxx -- Clarification on Applicability (Submitted by Glen Zorn)

Description:  The applicability should point out that the mechanisim described 
in this document solve only a part of the general network discovey and selection
problem.

Proposed Resolution:
====================

Append the following paragrah to the applicability section.

"
This document is also related to the general network discovery and
selection problem described in [netsel-problem]. The proposed mechanism 
described in this document solves only a part of the problem in [netsel-problem].
IEEE 802.11 is also looking into more comprehensive and long-term solutions 
for network discovery and selection. 
"