The Network Access Identifier
draft-ietf-radext-nai-15

[Ballot comment]
As far as I can see, and based on my attempt to find people who would still have an issue, we have cleared the issues that I worried about earlier. Thanks for the updates and working on this topic!

[Ballot discuss]
Thanks for writing this document. It was and is badly needed, and
as noted, roaming, network access authentication, and the use of
NAIs is growing and there is an obvious need to make sure
internationalised identifiers in particular work correctly. And as we
understand now, RFC 4282 indeed didn't provide a satisfactory
answer on that issue.

However, I have a couple observations of the text in the comment
section and one question that I would like to discuss before
recommending an approval of this draft.

The question:

I noticed the change from 4282 in terms of the bang syntax. This
isn't my favourite syntax, but conditions for its use were specified
in 4282. As far as I can see, the same conditions still exist in the
draft, but the draft adds that the usage is NOT RECOMMENDED,
and adds some rationale for this. Stating that the usage is
historical. The draft also removes the processing rules from
what they were in 4282:

  In this case, the part before the (non-escaped) '!'  MUST be a realm
  name as defined in the ABNF in Section 2.1.  This realm name is an
  "IDN-unaware domain name slot", just like the realm name after the
  "@" character; see Section 2.4 for details.  When receiving such an
  NAI, the other realm MUST convert the format back to
  "user@homerealm.example.net" when passing the NAI forward, as well as
  applying appropriate AAA routing for the transaction.

I have two questions related to this.

First, has the WG been aware of existing, not historical usage,
of this syntax? Quick search reveals that 3GPP networks use
a routing convention with the syntax, see
http://www.3gpp.org/DynaReport/23003.htm and
http://www.qtc.jp/3GPP/Specs/24302-a70.pdf (note that I'm not
the expert on these types of usage and there might be additional
examples, or the experts might understand the situation better
than what we can gain merely by looking at the existing specs).

Also, RFC 5729 discusses the use of decorated NAIs in
Diameter context.

In any case, I think the WG should be aware of existing realities
of deployed usage.

Secondly, does that usage change any of your recommendations?
Perhaps one could argue that when you understand your
situation and have good justification, you can go against a SHOULD
or RECOMMEND. Or perhaps one could argue that specific
conventions (such as the 3GPP usage) where the routing
table distribution is not an issue are safe. And finally, it seems
that deprecating processing rules (regardless of the recommendation
about general use of decoration) seems problematic if there are
existing systems that rely on this.

Thoughts?

[Ballot comment]
Thank you for including an explanation of what is intended by inter-domain authentication per my previous discuss point.  I think this will be helpful to the reader.  I also appreciate the language updates to get rid of the term identity and replace it with identifier as well as you using the suggestions I provided for the NAI definition.  The changes do help, thank you.

I support Barry's discuss on privacy concerns and appreciate the text you provided to address this concern.

(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 . 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 .
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.

(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 . 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 .
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.

(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 . 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 .
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.

(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 . 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 . 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.

[Ballot discuss]
Thanks for writing this document. It was and is badly needed, and
as noted, roaming, network access authentication, and the use of
NAIs is growing and there is an obvious need to make sure
internationalised identifiers in particular work correctly. And as we
understand now, RFC 4282 indeed didn't provide a satisfactory
answer on that issue.

However, I have a couple observations of the text in the comment
section and one question that I would like to discuss before
recommending an approval of this draft.

The question:

I noticed the change from 4282 in terms of the bang syntax. This
isn't my favourite syntax, but conditions for its use were specified
in 4282. As far as I can see, the same conditions still exist in the
draft, but the draft adds that the usage is NOT RECOMMENDED,
and adds some rationale for this. Stating that the usage is
historical.

I have two questions related to this.

First, has the WG been aware of existing, not historical usage,
of this syntax? Quick search reveals that 3GPP networks use
a routing convention with the syntax, see
http://www.3gpp.org/DynaReport/23003.htm and
http://www.qtc.jp/3GPP/Specs/24302-a70.pdf (note that I'm not
the expert on these types of usage and there might be additional
examples, or the experts might understand the situation better
than what we can gain merely by looking at the existing specs).
In any case, I think the WG should be aware of existing realities
of deployed usage.

Secondly, does that usage change any of your recommendations?
Perhaps one could argue that when you understand your
situation and have good justification, you can go against a SHOULD
or RECOMMEND. Or perhaps one could argue that specific
conventions (such as the 3GPP usage) where the routing
table distribution is not an issue are safe.

Thoughts?

[Ballot discuss]
Thanks for writing this document. It was and is badly needed, and
as noted, roaming, network access authentication, and the use of
NAIs is growing and there is an obvious need to make sure
internationalised identifiers in particular work correctly. And as we
understand now, RFC 4282 indeed didn't provide a satisfactory
answer on that issue.

However, I have a couple observations of the text in the comment
section and one question that I would like to discuss before
recommending an approval of this draft.

The question:

I noticed the change from 4282 in terms of the bang syntax. This
isn't my favourite syntax, but conditions for its use were specified
in 4282. As far as I can see, the same conditions still exist in the
draft, but the draft adds that the usage is NOT RECOMMENDED,
and adds some rationale for this. Stating that the usage is
historical.

I have two questions related to this.

First, has the WG been aware of existing, not historical usage,
of this syntax? Quick search reveals that 3GPP networks use
a routing convention with the syntax, see
http://www.3gpp.org/DynaReport/23003.htm and
http://www.qtc.jp/3GPP/Specs/24302-a70.pdf (note that I'm not
the expert on these types of usage and there might be additional
examples, or the experts might understand the situation better
than what we can gain merely by looking at the existing specs).
In any case, I think the WG should be aware of existing realities
of deployed usage.

Secondly, does that usage change any of your recommendations?
Perhaps one could argue that when you understand your
situation and have good justification, you can go against a SHOULD
or RECOMMEND. Or perhaps one could argue that specific
conventions (such as the 3GPP usage) where

Thoughts?

[Ballot comment]

Section 1.4:

  * [RFC4282] 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.6:

  In contrast to [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 AAA systems such as proxies
  are not required to perform translations, and can be expected to work
  through AAA systems that are unaware of international character sets.

Not that it matters greatly, but the characterisation of 4282 procedure seems
incorrect. Again, it is clear that we need a better specification for the
internationalised identifiers in NAIs, but RFC 4282 does say:

  The mapping, normalization, and bidirectional character processing
  MUST be performed by end systems that take international text as
  input.  In a network access setting, such systems are typically the
  client and the Authentication, Authorization, and Accounting (AAA)
  server.  NAIs are sent over the wire in their canonical form, and
  tasks such as normalization do not typically need to be performed by
  nodes that just pass NAIs around or receive them from the network.

The real issue isn't that 4282 required intermediate systems to do
translations - it didn't - but rather that the reality of the existing EAP
and other clients is that they put (local) blobs of text into the protocol
payloads and did NOT do anything at the end systems. Which your
draft correctly notes in Section 2.6.1. Which made the translate-to-ascii
approach of 4282 unworkable, and the approach in the current draft
more workable.

Section 2.6.1:

These limitations have the following theoretical and practical
  implications.

    * edge systems used today generally do not normalize the NAI

    * Therefore AAA systems SHOUD attempt to normalize the NAI

  The suggestion in the above sentence contradicts the suggestion in
  the previous section.  This is the reality of imperfect protocols.

  Where the user identifier can be normalized, or determined to be in
  normal form, the normal form MUST be used as the NAI.  In all other
  circumstances, the user identifier MUST NOT be treated as an NAI.
  That data is still, however, a user identifier.  AAA systems MUST NOT
  fail authentication simply because the user identifier is not an NAI.

  That is, when the realm portion of the NAI is not recognized by an
  AAA server, it SHOULD try to normalize the NAI into NFC form.  That
  normalized form can then be used to see if the realm matches a known
  realm.  If no match is found, the original form of the NAI SHOULD be
  used in all subsequent processing.

I'm trying to read the draft but I cannot find where it says explicitly what
to do when an AAA system (such as a NAS or a proxy) performs such
normalisation. Are the results of the normalisation only used locally, such
as for routing? Or is the normalised result somehow passed onwards (such
as when passing the RADIUS request to the next entity)? I think you mean
the former but I'd like to be sure.

Other comments:

I agree with Alissa's comment on distinctions between format and identifier.

I agree with, to the extent that I understand them :-) with Pete's comments on
internationalised names.

I partially disagree with Stephen's suggestion to consider hiding realm portions
in addition to user names. It is useful functionality, and to the extent that it can
be supported by existing mechanisms (like omitting the sensitive part, or using
the bang syntax in some manner) it should be noted. But this RFC-to-be is
for describing very widely deployed functionality, and I wouldn't like to see
additional requirements for intermediate RADIUS nodes as they quite simply
are not implemented today, and hence it would be difficult to use them.

[Ballot comment]
imho I think the hope statements are ok. and I can live with draft 12
------
opsdir review of 11 (by Mehmet Ersue) for the record.

I have reviewed the document "The Network Access Identifier" (draft-ietf-radext-nai-11.txt) as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the operational area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

Intended status: Standards Track
Obsoletes: RFC 4282
Current draft status: Submitted to IESG for Publication

Summary: The document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client prior to accessing resources. This document obsoletes RFC 4282.

I would suggest to change:
"In order to be able to offer roaming capability, one of the requirements is to be able to identify the user's home authentication server." as
"Concerning the support of roaming capability, one of the requirements is the ability to identify the user's home authentication server."

It is praiseworthy that the draft includes a section on the administration of names, which however has been kept short and handles NAI realm namespace piggybacks, NAI realm name uniqueness and the location of the authentication server.

I agree with Brian Haberman who asks to drop the "hope" from section 1.3 making a more definitive statement about the use of the document. There are three occurrences of the verb hope, which should be rewritten in a more explicit manner.

I don't see any other issues from the operations and management pov.

There are some nits in the draft:

The format of Table of Contents is wrong. It lists Appendix A before Introduction.

== The document seems to contain a disclaimer for pre-RFC5378 work, but was
  first submitted on or after 10 November 2008.  The disclaimer is usually
  necessary only for documents that revise or obsolete older RFCs

-- Obsolete informational reference: RFC 5335
  (Obsoleted by RFC 6532)

[Ballot comment]
opsdir review of 11 for the record.

I have reviewed the document "The Network Access Identifier" (draft-ietf-radext-nai-11.txt) as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the operational area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

Intended status: Standards Track
Obsoletes: RFC 4282
Current draft status: Submitted to IESG for Publication

Summary: The document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client prior to accessing resources. This document obsoletes RFC 4282.

I would suggest to change:
"In order to be able to offer roaming capability, one of the requirements is to be able to identify the user's home authentication server." as
"Concerning the support of roaming capability, one of the requirements is the ability to identify the user's home authentication server."

It is praiseworthy that the draft includes a section on the administration of names, which however has been kept short and handles NAI realm namespace piggybacks, NAI realm name uniqueness and the location of the authentication server.

I agree with Brian Haberman who asks to drop the "hope" from section 1.3 making a more definitive statement about the use of the document. There are three occurrences of the verb hope, which should be rewritten in a more explicit manner.

I don't see any other issues from the operations and management pov.

There are some nits in the draft:

The format of Table of Contents is wrong. It lists Appendix A before Introduction.

== The document seems to contain a disclaimer for pre-RFC5378 work, but was
  first submitted on or after 10 November 2008.  The disclaimer is usually
  necessary only for documents that revise or obsolete older RFCs

-- Obsolete informational reference: RFC 5335
  (Obsoleted by RFC 6532)

[Ballot discuss]
1.4:

OLD
  The intent
  appears to have been to encode, compare, and transport realms with
  the ToASCII operation defined in [RFC5890].

RFC5890 does not define ToASCII. ToAscii is defined in 3490, which you really don't want to refer to. See section 2.3.4 of 5890. Instead try this:

NEW
  The intent appears to have been to encode, compare, and transport
  realms by converting them to the Punycode [RFC3492] encoding form as described
  in [RFC5891].

2.5:

  Internationalization of the realm portion of the
  NAI is based on "Internationalized Email Headers" [RFC5335].

First of all, 5335 has been obsoleted by 6532, so you should use the updated reference if you need it. However, I have no idea why you'd use that for the *realm*. A reference to 5890 and/or 5891 should be completely sufficient for the realm portion. Conversely:

  In order to ensure a canonical representation, characters of the
  username portion in an NAI MUST match the ABNF in this specification
  as well as the requirements specified in [RFC5891].

The username needn't follow 5891, does it? Do you have the username and realm reversed here?

If you meant to base the username on 6532, perhaps what you want to say is:

  Internationalization of the username portion of the NAI is based on
  the "Internet Message Format" [RFC5322] "dot-atom" form of the
  "local-part" portion of an email address, as extended by
  "Internationalized Email Headers" [RFC6532] to allow for UTF-8
  characters.
 
  In order to ensure a canonical representation, characters of the
  realm portion in an NAI MUST match the ABNF in this specification
  as well as the requirements specified in [RFC5891].

Is that what you had in mind?

Then down in 3.1, you can change the first two paragraphs as follows:

  As proposed in this document, the Network Access Identifier is of the
  form "user@realm".  Please note that while the user portion of the
  NAI is based on the "Internet Message Format" [RFC5322] "local-part"
  portion of an email address as extended by "Internationalized Email
  Headers" [RFC6532], it has been modified for the purposes of Section
  2.2.  It does not permit quoted text along with "folding" or
  "non-folding" whitespace that is commonly used in email addresses.
  As such, the NAI is not necessarily equivalent to usernames used in
  e-mail.

  However, it is a common practice to use email addresses as user
  identifiers in AAA systems.  The ABNF in Section 2.2 is defined to be
  close to the "addr-spec" portion of [RFC5322] as extended by
  [RFC6532], while still being compatible with [RFC4282].

I have no idea why you wanted to reference 5198.

3.2:

The ToAscii problem.

OLD
  There is therefore no reason for a NAS to apply the ToAscii function
  to the "utf8-realm" portion of an NAI, prior to placing the NAI into
  a RADIUS User-Name attribute.

NEW
  There is therefore no reason for a NAS to convert the "utf8-realm"
  portion of an NAI into Punycode encoding form [RFC3492] prior to
  placing the NAI into a RADIUS User-Name attribute.

OLD
  When the realm portion of the NAI is used as the basis for name
  resolution, it may be necessary to convert internationalized realm
  names to ASCII using the ToASCII operation defined in [RFC5890]. As
  noted in [RFC6055] Section 2, resolver Application Programming
  Interfaces (APIs) are not necessarily DNS-specific, so that the
  ToASCII operation needs to be applied carefully:
 
NEW
  When the realm portion of the NAI is used as the basis for name
  resolution, it may be necessary to convert internationalized realm
  names to Punycode [RFC3492] encoding form as described in [RFC5891].
  As noted in [RFC6055] Section 2, resolver Application Programming
  Interfaces (APIs) are not necessarily DNS-specific, so conversion to
  Punycode needs to be done carefully:
 
3.4: Same problem as above:

OLD
  One example given in [RFC4282] is still permitted by the ABNF, but it
  is NOT RECOMMMENDED because of the use of the ToAscii function to
  create an ASCII encoding from what is now a valid UTF-8 string.

NEW
  One example given in [RFC4282] is still permitted by the ABNF, but it
  is NOT RECOMMMENDED because of the use of the Punycode [RFC3492]
  encoding form for what is now a valid UTF-8 string.

[Ballot comment]
Throughout (and this is the second document this week): I always find the "we" language jarring. "We" in this case is the WG, and that just comes out sounding bizzarre. Instead of "We suggest", say "This document suggests". Instead of "we note", use "note that". Etc. Please change this.

1.3 (and similarly in 2.7):

  Non-AAA systems MAY accept user identifiers in forms other than the
  NAI.

s/MAY/can in both places. This is not specifying a protocol option. It's stating a fact.

[Ballot comment]
Thanks for addressing my comments in version -12.

-- Sections 2.6 and 2.6.1 --
Good work on these sections.  This is difficult stuff, and I think you've handled it well -- at least, in the best way you can.  My favourite bit it this one, which is absolutely true:

  The suggestion in the above sentence contradicts the suggestion in
  the previous section.  This is the reality of imperfect protocols.

Thanks for making that reality clear.

[Ballot comment]

- This is not a blocking DISCUSS as it may be a feature
request but I'd really like to chat about it. In 2.4
you say that the username can be omitted or be
anonymous and that other protocols can support that
which is fine. But shouldn't you also consider that
sometimes (parts of) the realm part might also be
sensitive and handled similarly? E.g. if the "real" NAI
was "joebloggs@sensitive.example.org" then (assuming
example.org is sufficient for routing) wouldn't it be
nice if "@example.org" or "@anonymous.example.org"
could be sent as the visible NAI with the full NAI
being protected elsewhere in the protocol? For example
replacing the string sensitive in that NAI with the
name of a disease or counselling service might be a
real use case. Did the WG discuss this possibility?
(Note: I'm not trying to insist that this be done, I'd
just like to chat about it since it could be easy
enough to allow for here even recognising that it might
not be possible in some important use-cases if the
"protected" other protocol field is only expected to
contain the username part of the NAI.)

- I agree with Barry's discuss and Aliss's concerns and
would like to see the follow up discussion on that and
suspect that involving the WG in that discussion would
be good. Even if the document is perhaps not "pushing"
the idea of using the same identifier everywhere, I do
think that an analysis of the impacts of doing so, and
of how to usefully not do so, should be done, whether
or not all of that analysis output is needed in this
document.  That is, I could buy the concept that the
WG might take on the task of analysing the consequences
of (not)reuse of NAIs in multiple contexts in a
separate document, if the WG would really do that in a
timely manner. And if the WG waned to do that, then
some simple qualifiers added here and there might
be sufficient to handle Barry and Alissa's points.

- Generally, I'd prefer if the term "identifier" was
used throughout, and the term "identity" was never
used, or only very carefully. The abstract does not do
that IMO. Other text seems pretty good though but
I didn't check fully.

- Intro: " We suggest that this re-use is good
practice." needs a qualifier to handle the privacy
issues. (Recommending the format is fine, which goes to
Alissa's discuss.)

- 1.3: Same point: "as there is no need to maintain
multiple identifiers for one user" needs a qualifier.

- 1.3, 2nd last sentence: do you mean sybil attacks
here or something else? If the former saying so would
be good (or adding a ref), if the latter can you tell
me what you mean?

- 2.4, last para: saying "is typically required" seems
a bit weak, I wonder why you cannot require that the
realm part be routable or some such?

[Ballot discuss]
Thanks for your work on this draft and helpful responses to other discusses.  I just have one item I'd like to discuss to see if if we could further clarify what is intended with some additional text to the draft.  I'm not clear on it, so I'll just list my questions:

In 2.7 paragraph 2, the draft states inter-domain authentication would be useful.  What do you mean by inter-domain authentication?  Since the NAI is directed to the appropriate realm (if I am reading this correctly), do you mean that some form of inter-domain authorization would be used (like how OAuth)?  I'd just like to be clear on what is proposed here.  Or if the same username and authentication credentials would be used to authenticate across domains?

I ask the question because a similar idea of using authentication across domains has been discussed on the SecAuth list and it doesn't have much support.  Everyone agrees it would be nice to be able to seamlessly join networks, but also that there is no way we'll be able to get providers to work together to make this possible.  In responses to discuss questions, I believe you had said there is some of of this format for inter-domain authentication.  It would help the reader to have an expanded explanation of what you mean by that. 

Thanks in advance.

[Ballot comment]
I support Barry's discuss on privacy concerns and appreciate the text you provided to address this concern. 

The following is just a comment level suggestion.

For the definition in 1.1 of NAI, could you change the first sentence so it doesn't say the user's "identity" as it's an identifier/username that is actually submitted.  I tried to take a stab at alternate text in a couple of places, let me know what you think:
      The Network Access Identifier (NAI) is the user identity submitted
      by a client during authentication.  The purpose of the NAI is to
      identify the user as well as to assist in the routing of the
      authentication request.  Please note that the NAI may not
      necessarily be the same as the user's email address or the user
      identity submitted in an application layer authentication.
To:
      The Network Access Identifier (NAI) is a common format for a user
      name submitted by a client during authentication.  The purpose
      of the NAI is to provide a commonly formatted credential to associate the user with an account name as well as to assist
      in the routing of the authentication request.  Please note that the NAI may not
      necessarily be the same as the user's email address or the user
      contact information submitted in an application layer authentication.

[Ballot discuss]
= General =

This document seems to confuse an identifier format with an identifier, and I'd like to discuss that.

In my reading, all this document specifies is an identifier format and length, plus some processing rules for use by AAA systems. It does not specify the particular contents of the identifier for any specific protocol or usage, nor does it specify any semantic rules for the construction of such identifiers (e.g., "the same user should always use the same identifier").

However, the document repeatedly makes the case -- in sections 1, 1.3, 2.1, 2.7, 2.8 -- that "the NAI" (whether the actual identifier or the format, it's not clear) should be the universal identifier of choice for all situations and protocols, because it "simplifie[s] the management of credentials," allows other protocols to "leverage AAA for user authentication," removes the need to "maintain multiple identifiers for one user," etc. The claims in all of these sections seem to conflate a single user's use of the same identifier with a single user's use of the same identifier *format*. I thought what is being defined in this document is a format and nothing more.

I'm perfectly fine with encouraging the use of a standard format across protocols and applications (although I still don't see the need to repeat the same recommendation over and over again in the document). That has basically happened already in lots of places.

I'm not fine at all with a blanket recommendation to use a single identifier for the same user everywhere. The ability to authenticate to different services (and even to different networks!) using different identities is a fundamental building block for privacy on the Internet. The message from this document seems to be that we should erase that protection.

I note that although the stated motivation for this document relates to internationalization, pretty much all of the text recommending One Identifier to Rule Them All is new. So perhaps there were multiple motivations for this document update?

I could offer a bunch of detailed text suggestions, but first I'd like to understand what this document is actually trying to do, and whether the term "the NAI" is meant to refer to an identifier or an identifier format.

= Section 2.4 =
"Therefore, the utf8-username portion SHOULD be treated
  as opaque data when processed by nodes that are not a part of the
  authoritative domain (in the sense of Section 4) for that realm."

What does it mean to treat a cleartext username as opaque data? Should the nodes outside the realm not log these usernames, or not process them in any way?

"Omitting the username part is RECOMMENDED over using a fixed username
  part, such as "anonymous", since it provides an unambiguous way to
  determine whether the username is intended to uniquely identify a
  single user."

I don't understand why this is true, other than by convention. If I process a bunch of authentication transactions that use "@example.com" as the NAI, how am I supposed to know that each of those was intended to identify a single user? Is the usage of an NAI to authenticate a group of users discussed somewhere?

In general, I'm uncomfortable with the approach this document takes of making a few notes about how the username part could be constructed without providing a more thorough analysis of threats and mitigations related to identifiability, uniqueness and persistence. This also comes up with the example in Section 2.8, where uniqueness is discussed in the context of the example, but there is no generalized discussion about uniqueness in identifier construction. This might get back to my larger point above about format versus content -- if this document is just specifying a format, it probably shouldn't be commenting on the identifier content or the consequences of it (although being able to omit the username part is certainly a format issue).

[Ballot comment]
= Section 1 =
Is dial-up really a prevalent use case to be highlighting first here? If we're going to obsolete an old document, it's worth making it current.

Similarly, I wonder how current this text is in Section 1.3?

"As described in [RFC2194], there are a number of providers offering
  network access services, and the number of Internet Service Providers
  involved in roaming consortia is increasing rapidly."

[Ballot discuss]
A significant thing that's new in this document is that you're recommending the use of a common identifier across different services and protocols.  This introduces a significant issue: it can enable tracking of the identifier across those services, allowing correlation of a single user's activity.  Did the working group consider that aspect?  I don't see any discussion of this in the document, and it seems to be something that needs to be discussed.

[Ballot comment]
There's quite some duplication between the new text in Section 1 and the new text in Section 1.3.  You might consider looking those over and trimming some of the duplication.

-- Section 2.1 --

  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.

I understand that it's outside the scope of this document to tell us now to do this, but the last sentence tells me that it might be useful to have something in an appendix that talks about how existing practice handles this, by way of example.  No?  (Or maybe the first sentence of the next paragraph is telling me that explaining it is pointless, so let's move on.)

-- Section 2.2 --

  dot-string    =  string
  dot-string    =/ dot-string "." string
  string        =  utf8-atext
  string        =/ string utf8-atext

It's not wrong, of course, but I found these oddly confusing, and wonder why you didn't render them this way:

  dot-string    = [dot-string "."] string
  string        = [string] utf8-atext

or, still more usual, this way:

  dot-string    = string *("." string)
  string        = 1*utf8-atext

The way you did this for "nai" is useful, in that it makes it clear that there are three ways to represent an nai... but for "dot-string" and "string", it just seems odd not to do it the last way, which is far more common.

-- Section 2.3 --
In the second bullet, the semicolon should be a comma.

-- Section 2.5 --
As Brian notes, RFC 5335 (Experimental) has been obsoleted by RFC 6532 (Standards Track).  Unfortunately for this document, 6532 changed how the internationalized identifier is specified, using an alteration of the ABNF in RFC 5322 rather than specifying the ABNF directly.  You should look at this, because there's a conflict: on the one hand, it's more consistent with this spec that you stick with the 5335 reference; on the other hand, it's sad to have you reference the obsolete Experimental spec rather than the current Standards Track one.  In any case, it won't work for you to simply change the reference.

-- Sections 2.6 and 2.6.1 --
Good work on these sections.  This is difficult stuff, and I think you've handled it well -- at least, in the best way you can.  My favourite bit it this one, which is absolutely true:

  The suggestion in the above sentence contradicts the suggestion in
  the previous section.  This is the reality of imperfect protocols.

Thanks for making that reality clear.

[Ballot comment]
I have no problem with the publication of this document, but I do have a few points for you to consider.

1. The references contain RFC 5335.  However, 5335 has been obsoleted by RFC 6532.

2. Can you drop the "hope" from section 1.3 and make a more definitive statement about the use of this document?  Additionally, most of 1.3 does not read like the Purpose of this document.  Can it be tightened up by removing some of the nebulous text on AAA and non-AAA systems and focus on the NAI itself?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-radext-nai-10, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (The Network Access Identifier) to Proposed Standard


The IESG has received a request from the RADIUS EXTensions WG (radext) to
consider the following document:
- 'The Network Access Identifier'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-11-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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 network 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.



The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-radext-nai/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-radext-nai/ballot/


No IPR declarations have been submitted directly on this I-D.

(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 . 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 . 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.

Will do the proto after IETF.

Feb 19th from Alan:

Jouni Korhonen wrote:
> OK, I was waiting since you said you would have a
> new edited version to be submitted. That was 5th Feb.

Ah, sorry.  I thought you had meant the DTLS draft.

The NAI draft is good to go so far as I know.

The WGLC#1 has ended. There are now five open tickets in the issue tracker (#162, #145, #146, #164 and #167). I encourage the I-D author(s) and the WG to sort out the remaining tickets as soon as possible.