(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:
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
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
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.
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 <firstname.lastname@example.org>. The review comments
were one of the inputs to the discussion and were taken into account in the latest
revision of the draft.
The document shepherd is Stefan Winter <email@example.com>.
The responsible area directors of the Operations and Management area are Benoit Claise <firstname.lastname@example.org> and Joel Jaeggli <email@example.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?
(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.