[radext] draft-ietf-radext-nai-08 AD review

[Benoit Claise <[e-mail]>]

Dear all,

Here is my draft-ietf-radext-nai-08 AD review

_Technical:_
-

    AAA systems MUST therefore be
    able to handle user identifiers which are not in the NAI format.

    ...

    Systems MAY accept user identifiers in forms other than the NAI.

These are contradictory.
I believe that:
- those two sentences (or paragraphs) should be next to each others.
- the second sentence should stress "Non AAA systems"

    _Systems_MAY accept user identifiers in forms other than the NAI.
    This specification does not forbid that practice.  It only codifies
    the format and interpretation of the NAI.  We cannot expect to change
    existing protocols or practices.  We can, however, suggest that using
    a consistent form for a user identifier is of a benefit to the
    community.

    Where protocols carry identifiers which are expected to be
    transported over an AAA protocol, it is RECOMMENDED that the
    identifiers be in NAI format.  Where the identifiers are not in the
    NAI format, it is up to the_AAA systems_  to discover this, and to
    process them.  This document does not suggest how that is done.
    However, existing practice indicates that it is possible.

Be consistent between systems, non-AAA systems, and AAA systems

Editorial:

-
when you produce a new draft version, don't forget 
http://tools.ietf.org/wg/radext/trac/ticket/176

-

   Considerable interest exists for a set of features that fit within
    the general category of inter-domain authentiction

authentication

-
    Normalization Canonicalization

       These terms are defined in[RFC6365] Section 4  <http://tools.ietf.org/html/rfc6365#section-4>.  We incorporate
       the definitions here by reference.

Isn't "Normalization or Canonicalization"

- Like mentioned in the last bullet point below, all links should point 
to the RFC4282 sections, not to draft-ietf-radext-nai-08 sections.

    *  The requirement inSection 2.1  <http://tools.ietf.org/html/draft-ietf-radext-nai-08#section-2.1>  that realms are ASCII conflicts
       with the Extensible Authentication Protocol (EAP) and RADIUS,
       which are both 8-bit clean, and which both recommend the use of
       UTF-8 for identitifiers.

    *Section 2.4  <http://tools.ietf.org/html/draft-ietf-radext-nai-08#section-2.4>  required mappings that are language-specific,
       and which are nearly impossible for intermediate nodes to perform
       correctly without information about that language.

    *Section 2.4  <http://tools.ietf.org/html/draft-ietf-radext-nai-08#section-2.4>  requires normalization of user names, which
       may conflict with local system or administrative requirements.

    * The recommendations inSection 2.4  <http://tools.ietf.org/html/draft-ietf-radext-nai-08#section-2.4>  for treatment of
       bidirectional characters have proven to be unworkable.

    * The prohibition against use of unassigned code points in
       Section 2.4  <http://tools.ietf.org/html/draft-ietf-radext-nai-08#section-2.4>  effectively prohibits support for new scripts.

    * No Authentication, Authorization, and Accounting (AAA)
       client, proxy, or server has implemented any of the requirements
       in[RFC4282] Section 2.4  <http://tools.ietf.org/html/rfc4282#section-2.4>, among other sections.



-


    5 <http://tools.ietf.org/html/draft-ietf-radext-nai-08#section-5>.
    Administration of Names


    In order to avoid creating any new administrative procedures,


    administration of the NAI realm namespace piggybacks on the
    administration of the DNS namespace.

There is a tag issue above. The section tag contains the first line of section 5.

Regards, Benoit