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

From: Benoit Claise <[email-masked]>
Date: Tue, 28 Oct 2014 23:51:36 +0100

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

---

From: Benoit Claise <[email-masked]>
Date: Wed, 29 Oct 2014 21:05:10 +0100

Alan,

Thanks for the version 9.
The technical comment has been taken care of. Thanks.
It's however a missed opportunity not to have taken into account the 
editorial comments below.

Regards, Benoit
> - Like mentioned in the last bullet point below, all links should 
> point to the RFC4282 sections, not to draft-ietf-radext-nai-08 sections.
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Alan DeKok <[email-masked]>
Date: Wed, 29 Oct 2014 16:28:13 -0400

> editorial comments below.

  I thought I had done that...

- "systems" qualified to non-AAA, AAA, and edge

- re-work the contradictory sentences

- etc.

>>    _Systems _MAY accept user identifiers in forms other than the NAI.
>>    NAI format, it is up to the _AAA systems_ to discover this, and to
>>       These terms are defined in [RFC6365] Section 4 <http://tools.ietf.org/html/rfc6365#section-4>.  We incorporate
>>    *  The requirement in Section 2.1 <http://tools.ietf.org/html/draft-ietf-radext-nai-08#section-2.1> that realms are ASCII conflicts
>>    * Section 2.4 <http://tools.ietf.org/html/draft-ietf-radext-nai-08#section-2.4> required mappings that are language-specific,
>>    * Section 2.4 <http://tools.ietf.org/html/draft-ietf-radext-nai-08#section-2.4> requires normalization of user names, which
>>    * The recommendations in Section 2.4 <http://tools.ietf.org/html/draft-ietf-radext-nai-08#section-2.4> for treatment of
>>       in [RFC4282] Section 2.4 <http://tools.ietf.org/html/rfc4282#section-2.4>, among other sections.
>>
>>
>> -
>>
>>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 29 Oct 2014 21:44:16 +0100

-

authentication

-

-

Regards, Benoit

> .

---

From: Alan DeKok <[email-masked]>
Date: Wed, 29 Oct 2014 16:55:40 -0400

Ok... I did actually make the edits, I just sent the wrong file.

  I'll send a -10.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Thu, 30 Oct 2014 08:51:19 +0100

Hi,

>   Ok... I did actually make the edits, I just sent the wrong file.

-09 also currently doesn't contain the fix to TRAC #176. I guess it will
be in -10 then.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66