Skip to main content

Shepherd writeup
draft-ietf-radext-nai

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper
type of RFC? Is this type of RFC indicated in the title page header?

The document is a Proposed Standard (Standards track). This is an appropriate
choice because its purpose is to obsolete another RFC on standards track
(RFC4282). The category is indicated in the title page header.

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up. Recent examples can be
found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary:

In order to provide inter-domain authentication services, it is
   necessary to have a standardized method that domains can use to
   identify each other's users.  This document defines the syntax for
   the Network Access Identifier (NAI), the user identity submitted by
   the client prior to accessing resources. This document is a revised
   version of RFC 4282, which addresses issues with international
   character sets, as well as a number of other corrections to the
   previous document.

Working Group Summary:

The preceding RFC4282 was primarily written for the concrete use case of network
access. Over time however, many services made use of the concept defined
therein; see Citation information at
http://www.arkko.com/tools/allstats/citations-rfc4282.html for a complete list
of IETF work; other standardization bodies or other documents not counted.
draft-ietf-radext-nai thus had to make modest modifications in order not to
create incompatibilities with these existing uses. It also took care to define
the NAI in a protocol-agnostic manner to encourage such re-use.

One particular issue which was discussed at length was the question: which
entity should (be allowed to) normalise or re-encode the realm portions of
NAIs; and what to do if such a re-encoding is needed, but not possible. In the
core scenario of network access, i.e use with RADIUS and Diameter, character
encoding and normalisation information may not be available to any
RADIUS/Diameter endpoint at all (the encoding information may get lost at a
preceding stage, before the NAI reaches the RADIUS client). In other scenarios,
the encoding information may be available at all points in the conversation.
The working group finally converged on the text in section 2.6, which puts a
bias on endpoints doing all conversions, and intermediate entities doing
conversions only inside their local state; not modifying the NAI on the wire.

Another aspect that was discussed is that the notion of User-Name in AAA
protocols and the term NAI are not an exact match; while User-Name often is
used to transmit a NAI, it can also be used to transmit arbitrary strings which
do not follow the NAI conventions of either RFC4282 or draft-ietf-radext-nai.
The working group concluded that this is a fact of life that can't be changed,
and that implementations which inspect a User-Name can't blindly assume to get
a NAI; they need to care about their own fallback/failure handling. Such
handling is outside the scope of draft-ietf-radext-nai.

Document Quality:

The concept of NAIs is not new, and the definitions of draft-ietf-radext-nai are
compatible with implementations of NAIs in the "ASCII" subset. Field evidence
suggests that RFC4282's provisions for dealing with characters from outside
ASCII were with an overwhelming majority not implemented at all or even
violated RFC4282 and did what draft-ietf-radext-nai is now suggesting anyway;
so existing implementations do not conflict with the new encoding rules parts
that are introduced with draft-ietf-radext-nai. It's thus a reasonable
assumption that NAIs as defined in draft-ietf-radext-nai are as widely
implemented as the NAIs of RFC4282.

The encoding and normalisation questions triggered an i18n review; the person
doing that review was Pete Resnick <presnick@qti.qualcomm.com>. The review
comments were one of the inputs to the discussion and were taken into account
in the latest revision of the draft.

Personnel:

The document shepherd is Stefan Winter <stefan.winter@restena.lu>.
The responsible area directors of the Operations and Management area are Benoit
Claise <​bclaise@cisco.com> and Joel Jaeggli <​joelja@bogus.com>.

(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the IESG.

I was active in the discussion of the draft throughout its lifetime (at the
time not being a co-chair but a working group participant). I have read all
revisions of the draft and have given the revision which was originally put
forward for PROTO Write-up (-05) another thorough read. I found some minor
issues, which were subsequently resolved in the current -08. The document is
now ready for publication.

(There is still a minor wordsmithing glitch which is being tracked in
http://tools.ietf.org/wg/radext/trac/ticket/176 ; it will be fixed with the
IETF Last Call comments or during the publication process )

(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

This draft has gotten significant exposure; it was commented on by many working
group members and also experts from outside the working group. I have no
concerns about the breadth and depth of the review process.

(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

Internationalisation is the big topic of this follow-up to RFC4282; it
introduces new ways of handling internationalisation and puts recommendations
on end systems. The end systems need to make sure user input from UI or
configuration items are in UTF-8 or will be converted to UTF-8 before sending
them on the wire; they should also perform normalisation. The
internationalisation review by Pete Resnick was called for in an ad-hoc,
informal manner by a WG participant, and was for an earlier revision of the
draft (-02). It might be useful to flag the document in its current state to
i18n experts again for a thorough review.

(6) Describe any specific concerns or issues that the Document Shepherd has
with this document that the Responsible Area Director and/or the IESG should be
aware of? For example, perhaps he or she is uncomfortable with certain parts of
the document, or has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated that it still
wishes to advance the document, detail those concerns here.

The big items of discussion were outlined earlier in the write-up. There is no
perfect way to define NAI, normalisation, and encoding in the complex
multi-protocol usage that is the deployed reality. The working group reached a
consensus which appears to be the most useful way of dealing with the topics in
question. I thus have no concerns with this document.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

There is only one author, and he has submitted the draft with the pre-2008
boiler plate text. There are large passages of text pulled-in from RFC4282 and
other documents, which could not be worked around; nor did the original authors
agree on changing the IPR. This justifies the pre-2008 boilerplate.

(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

There are no known IPR disclosures surrounding this document.

(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?

The number of people who discussed this draft is comparatively high. I believe
the WG as a whole stands behind this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

There were no threats of appeal. There was friction in the contentious points I
mentioned earlier in the write-up, but in the absence of a perfect solution,
the document as-is found support by a high majority of participants.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Boilerplate checks are not enough; this check needs to be thorough.

-- Obsolete informational reference (is this intentional?): RFC 5335

After checking back with the author, this obsolete reference *is* intentional.
The RFC contains an ABNF production for email headers which the current
document refers to; the successor to RFC5335 (RFC6532) does not contain that
ABNF any more.

The document contains a non-ASCII example. That's not a nit, but raises the
question if this document should be published as UTF-8 text. It would certainly
help readability.

It occured to me that the normative reference to RFC5234 does not mention that
this RFC is also STD68. I don't know if this is something the author has to fix
(references are usually auto-generated and add the "STDxy" if appropriate;
wondering why that didn't happen here).

(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, media type, and URI type reviews.

The document did not have to go through MIB Doctor, Media Type, nor URI type
reviews because it does not assign any of these.

(13) Have all references within this document been identified as either
normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?

All normative references are issued RFCs.

(15) Are there downward normative references references (see RFC 3967)? If so,
list these downward references to support the Area Director in the Last Call
procedure.

The references to RFC2119 and RFC6365 are BCPs. I do not believe that to be
problematic though.

(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it unnecessary.

This document will obsolete RFC4282. This is reflected in the title page
header, listed in the abstract, and discussed in the introduction (section 1.4).

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes are
associated with the appropriate reservations in IANA registries. Confirm that
any referenced IANA registries have been clearly identified. Confirm that newly
created IANA registries include a detailed specification of the initial
contents for the registry, that allocations procedures for future registrations
are defined, and a reasonable name for the new registry has been suggested (see
RFC 5226).

RFC4282 had an extensive section called IANA Considerations but which had no
actual actions for IANA. The text has now been moved to its own section; and
the IANA Considerations are empty. This is the intended state.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

There are no new IANA registries created by this document.

(19) Describe reviews and automated checks performed by the Document Shepherd
to validate sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, etc.

I read and reviewed the BNFs, but did not verify them with an automated parser.
Back