[radext] Review of draft-dekok-radext-nai

[Bernard Aboba <[e-mail]>]

One of the issues with RFC 4282 was that it began with the assumption that a single form of the NAI existed independent of the protocol and context in which the NAI was used.  This assumption was wrong.  
Given the problems with RFC 4282,  I am very wary of attempting to simultaneously define the NAI as well as to talk about how it is internationalized in all protocols in a single document.  My suggestion is that this document focus *solely* on the definition of the NAI, with other documents talking about internationalization within specific protocols including RADIUS, Diameter and EAP. 
Here are examples of text that may not belong in this document:
   See [RFC5198] for a discussion of normalization; implementations of
   this specification MUST use the Normal Form Composed (NFC) for NAIs.
[BA] There is context missing here.  For what operations and protocols is NFC to be used (e.g. comparison in RADIUS?) It may be best to discuss the details within the context of specific protocols. 
   Internationalization of the realm portion of the
   NAI is based on "Internationalized Email Headers" [RFC5335].
[BA] This is another statement whose correctness may depend on the specific protocol in which the NAI is used.  
2.6.  The Normalization Process

   All normalization MUST be performed by end systems that take "local"
   text as input.  That is, text that is in an encoding other than
   UTF-8, or that has locale-specific variations.  In a network access
   setting, such systems are typically the client (e.g. EAP supplicant)
   and the Authentication, Authorization, and Accounting (AAA) server.
[BA] This is a statement that may apply to specific protocols and not to others. For example, PPP peers may not normalize NAIs.  So a general MUST doesn't make sense.

   All other AAA systems (proxies, etc.)  MUST NOT perform
   normalization.  These other systems do not have access to locale and
   character set information that is available to end systems.

[BA] I don't believe that general statements about "AAA" are appropriate in this document.  Better to deal with specifics of RADIUS and Diameter in documents created for that purpose. 
   That is, all processing of NAIs from "local" character sets and
   locales to UTF-8 is performed by edge systems, prior to the NAIs
   entering the AAA system.  Inside of an AAA system, NAIs are sent over
   the wire in their canonical form, and this canonical form is used for
   all NAI and/or realm comparisons.

[BA] This is another general statement that probably should be removed and made (or not) within a specific context.  For example, not all EAP methods will normalize NAIs as advocated here. 
   In contrast to the comments in [RFC4282] Section 2.4, we expect AAA
   systems to perform NAI comparisons, matching, and AAA routing based
   on the NAI as it is received.  This specification provides a
   canonical representation, ensures that intermediate systems such as
   AAA proxies do not need to perform translations, and can be expected
   to work through systems that are unaware of international character
   sets.

   For example, much of the common realm routing can be done on the
   "utf8-realm" portion of NAI, through simple checks for equality.
   This routing can be done even if the AAA proxy is unaware of
   internalized domain names.  All that is required is for the AAA proxy
   to be able to enter, store, and compare 8-bit data.

   EAP supplicants MUST normalize user names that get placed in the EAP-
   Response/Identity field.  They MUST NOT copy localized text into that
   field.  This normalization SHOULD be performed once, and then cached
   for subsequent use.

[BA] It is not clear to me that this document should attempt to tackle AAA and EAP internationalization as well as NAI definition.