[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Please Review: documents on IESG Agenda for May 26, 2005 Telechat

Wijnen, Bert (Bert) wrote:

o draft-adrangi-eap-network-discovery-12.txt
Identity selection hints for Extensible Authentication Protocol (EAP) (Informational) - 2 of 2 Token: Margaret Wasserman


First, Bernard posted some status information about this to the IESG
a while ago (see below).

Secondly, perhaps some context and history information
will be useful as you process this draft. It has a long
history... it started out as a fairly general purpose mechanism, and
we have had lengthy discussions in the EAP WG about what is the right
layer and protocol to implement network discovery hints. I believe
the general feeling in the group (also supported by some input from
the IEEE) is that a very limited EAP layer mechanism is useful until
link layers develop the necessary support, which may still take a few
years. As a result, Farid's draft has undergone a significant scaling
down over the last two years, and is now quite narrow in terms of
its extension. We have also re-defined it in terms of talking about
EAP layer data only. That is, it talks about the identities used
at the EAP layer, which is more appropriate than carrying a lot of
lower layer information in EAP. Finally, discussion during IETF LC
resulted in a narrowed-down applicability statement.

The document is one of the Release 6 dependencies from 3GPP.

Finally, I reviewed this document again.
Here are my findings:


  This document specifies behavior of RADIUS proxies that handle EAP
  messages.  This includes the specification of the behavior of proxies
  in response to an unknown realm within the User-Name(1) attribute of
  an Access-Request containing one or EAP-Message attributes.  This
  document, which depends on NAI "decoration" specified in
  [rfc2486bis], assumes a source routing model for determination of the
  roaming relationship path, and therefore affects the behavior of
  RADIUS proxies in roaming situations.


This may be a bit strong statement. I think this may have been
added to address Glen Zorn's issues, but identity selection per
se does not imply that you have to use "decoration" -- it may
simply mean that you decide to use "jari@piuha.net" instead of
"jari@ericsson.com". Suggest an editorial change as a part of
the IESG approval note, maybe saying "if used in a scenario
requiring NAI decoration" instead of "which depends on NAI
decoration".

Otherwise I'm OK with the document as-is.

---------------- Bernard's mail ---------------------
The EAP WG has completed its review of this document, which had been
submitted to the RFC Editor for publication as an Informational RFC.
The review did not identify any incompatibilities between the
document and EAP WG documents as RFC 3748 or the EAP Key Management
framework.

At this point, all known issues relating to the document have been
resolved, with the possible exception of Issues 295 and 296, raised by
Glen Zorn:
http://www.drizzle.com/~aboba/EAP/eapissues.html

Prior to completing its review, the WG chairs attempted to contact Glen
for confirmation that the Issues had been resolved in -13, but did not
receive a reply.

Issue 295 relates to documentation of message flows and error conditions.

Issue 296 relates to dependencies of the specification on 3GPP documents,
compatibility with previous  IETF work on roaming, and a potential IESG
note.