IESG state changed to Approved-announcement sent from Approved-announcement to be sent

2015-02-09

15

Amy Vezza

IESG has approved the document

2015-02-09

15

Amy Vezza

Closed "Approve" ballot

2015-02-09

15

Amy Vezza

Ballot approval text was generated

2015-02-09

15

Amy Vezza

Ballot writeup was changed

2015-02-09

15

Amy Vezza

IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup

2015-01-23

15

Jari Arkko

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

[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!

2015-01-23

15

Jari Arkko

[Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss

Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Mehmet Ersue.

2014-12-04

12

Jari Arkko

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

[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 commentsection and one question that I would like to discuss beforerecommending an approval of this draft.

The question:

I noticed the change from 4282 in terms of the bang syntax. Thisisn't my favourite syntax, but conditions for its use were specifiedin 4282. As far as I can see, the same conditions still exist in thedraft, but the draft adds that the usage is NOT RECOMMENDED,and adds some rationale for this. Stating that the usage ishistorical. The draft also removes the processing rules fromwhat 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 usea routing convention with the syntax, seehttp://www.3gpp.org/DynaReport/23003.htm andhttp://www.qtc.jp/3GPP/Specs/24302-a70.pdf (note that I'm notthe expert on these types of usage and there might be additionalexamples, or the experts might understand the situation betterthan what we can gain merely by looking at the existing specs).

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

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

Thoughts?

2014-12-04

12

Jari Arkko

Ballot discuss text updated for Jari Arkko

2014-12-04

12

Kathleen Moriarty

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

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

2014-12-04

12

Kathleen Moriarty

[Ballot Position Update] Position for Kathleen Moriarty has been changed to No Objection from Discuss

2014-12-04

12

Ted Lemon

[Ballot comment]I support the changes Alissa has proposed to address the privacy concerns she raised.

2014-12-04

12

Ted Lemon

[Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon

2014-12-04

12

Benoît Claise

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

(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 choicebecause its purpose is to obsolete another RFC on standards track (RFC4282). Thecategory 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 theconversation. 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 indraft-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 thecurrent -08. The document is now ready for publication.

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

2014-12-04

12

Benoît Claise

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

(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 choicebecause its purpose is to obsolete another RFC on standards track (RFC4282). Thecategory 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 theconversation. 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 indraft-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 thecurrent -08. The document is now ready for publication.

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

2014-12-04

12

Benoît Claise

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

(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 choicebecause its purpose is to obsolete another RFC on standards track (RFC4282). Thecategory 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 theconversation. 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 indraft-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 thecurrent -08. The document is now ready for publication.

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

2014-12-04

12

Benoît Claise

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

(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 choicebecause its purpose is to obsolete another RFC on standards track (RFC4282). Thecategory 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.

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

2014-12-04

12

Jari Arkko

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

[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 commentsection and one question that I would like to discuss beforerecommending an approval of this draft.

The question:

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

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 usea routing convention with the syntax, seehttp://www.3gpp.org/DynaReport/23003.htm andhttp://www.qtc.jp/3GPP/Specs/24302-a70.pdf (note that I'm notthe expert on these types of usage and there might be additionalexamples, or the experts might understand the situation betterthan what we can gain merely by looking at the existing specs).In any case, I think the WG should be aware of existing realitiesof deployed usage.

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

Thoughts?

2014-12-04

12

Jari Arkko

Ballot discuss text updated for Jari Arkko

2014-12-04

12

Jari Arkko

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

[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 commentsection and one question that I would like to discuss beforerecommending an approval of this draft.

The question:

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

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 usea routing convention with the syntax, seehttp://www.3gpp.org/DynaReport/23003.htm andhttp://www.qtc.jp/3GPP/Specs/24302-a70.pdf (note that I'm notthe expert on these types of usage and there might be additionalexamples, or the experts might understand the situation betterthan what we can gain merely by looking at the existing specs).In any case, I think the WG should be aware of existing realitiesof deployed usage.

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

Thoughts?

2014-12-04

12

Jari Arkko

[Ballot comment]

Section 1.4:

* [RFC4282] Section 2.4 required mappings that are language-specific, and which are nearly impossible for ...

[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 theinternationalised 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 dotranslations - it didn't - but rather that the reality of the existing EAPand other clients is that they put (local) blobs of text into the protocolpayloads and did NOT do anything at the end systems. Which your draft correctly notes in Section 2.6.1. Which made the translate-to-asciiapproach of 4282 unworkable, and the approach in the current draftmore 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 whatto do when an AAA system (such as a NAS or a proxy) performs such normalisation. Are the results of the normalisation only used locally, suchas for routing? Or is the normalised result somehow passed onwards (suchas when passing the RADIUS request to the next entity)? I think you meanthe 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 oninternationalised names.

I partially disagree with Stephen's suggestion to consider hiding realm portionsin addition to user names. It is useful functionality, and to the extent that it canbe supported by existing mechanisms (like omitting the sensitive part, or usingthe 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 seeadditional requirements for intermediate RADIUS nodes as they quite simplyare not implemented today, and hence it would be difficult to use them.

2014-12-04

12

Jari Arkko

[Ballot Position Update] New position, Discuss, has been recorded for Jari Arkko

2014-12-04

12

Adrian Farrel

[Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel

2014-12-03

12

Joel Jaeggli

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

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

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)

2014-12-03

12

Joel Jaeggli

Ballot comment text updated for Joel Jaeggli

2014-12-03

12

Joel Jaeggli

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

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

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)

2014-12-03

12

Joel Jaeggli

[Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli

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

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

2014-12-03

12

Pete Resnick

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

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

2014-12-03

12

Pete Resnick

[Ballot Position Update] New position, Discuss, has been recorded for Pete Resnick

2014-12-03

12

Spencer Dawkins

[Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins

2014-12-03

12

Richard Barnes

[Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes

2014-12-03

12

Alia Atlas

[Ballot comment]I support Alissa's concerns on privacy.

2014-12-03

12

Alia Atlas

[Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas

2014-12-03

12

Barry Leiba

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

-- Sections 2.6 and 2.6.1 --Good work on these sections. This is ...

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

2014-12-03

12

Barry Leiba

[Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss

- This is not a blocking DISCUSS as it may be a featurerequest but I'd really like to chat about it. In ...

[Ballot comment]

- This is not a blocking DISCUSS as it may be a featurerequest but I'd really like to chat about it. In 2.4you say that the username can be omitted or beanonymous and that other protocols can support thatwhich is fine. But shouldn't you also consider thatsometimes (parts of) the realm part might also besensitive and handled similarly? E.g. if the "real" NAIwas "joebloggs@sensitive.example.org" then (assumingexample.org is sufficient for routing) wouldn't it benice if "@example.org" or "@anonymous.example.org"could be sent as the visible NAI with the full NAIbeing protected elsewhere in the protocol? For examplereplacing the string sensitive in that NAI with thename of a disease or counselling service might be areal use case. Did the WG discuss this possibility?(Note: I'm not trying to insist that this be done, I'djust like to chat about it since it could be easyenough to allow for here even recognising that it mightnot be possible in some important use-cases if the"protected" other protocol field is only expected tocontain the username part of the NAI.)

- I agree with Barry's discuss and Aliss's concerns andwould like to see the follow up discussion on that andsuspect that involving the WG in that discussion wouldbe good. Even if the document is perhaps not "pushing"the idea of using the same identifier everywhere, I dothink that an analysis of the impacts of doing so, andof how to usefully not do so, should be done, whetheror not all of that analysis output is needed in thisdocument. That is, I could buy the concept that theWG might take on the task of analysing the consequencesof (not)reuse of NAIs in multiple contexts in aseparate document, if the WG would really do that in atimely manner. And if the WG waned to do that, thensome simple qualifiers added here and there might be sufficient to handle Barry and Alissa's points.

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

- Intro: " We suggest that this re-use is goodpractice." needs a qualifier to handle the privacyissues. (Recommending the format is fine, which goes toAlissa's discuss.)

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

- 1.3, 2nd last sentence: do you mean sybil attackshere or something else? If the former saying so wouldbe good (or adding a ref), if the latter can you tellme what you mean?

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

2014-12-03

11

Stephen Farrell

[Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell

2014-12-02

11

Kathleen Moriarty

[Ballot discuss]Thanks for your work on this draft and helpful responses to other discusses. I just have one item I'd like to ...

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

2014-12-02

11

Kathleen Moriarty

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

The following is just ...

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

2014-12-02

11

Kathleen Moriarty

[Ballot Position Update] New position, Discuss, has been recorded for Kathleen Moriarty

2014-12-02

11

Alissa Cooper

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

[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).

2014-12-02

11

Alissa Cooper

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

[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."

2014-12-02

11

Alissa Cooper

[Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper

2014-12-01

11

Barry Leiba

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

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

2014-12-01

11

Barry Leiba

[Ballot comment]There's quite some duplication between the new text in Section 1 and the new text in Section 1.3. You might ...

[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.)

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.

2014-12-01

11

Barry Leiba

[Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba

2014-12-01

11

Brian Haberman

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

[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?

2014-12-01

11

Brian Haberman

[Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman

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

The IESG plans to make a decision in the next few weeks, and solicitsfinal comments on this action. Please send substantive comments to theietf@ietf.org mailing lists by 2014-11-14. Exceptionally, comments may besent to iesg@ietf.org instead. In either case, please retain thebeginning 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.

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

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

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

IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up

2014-10-09

08

Stefan Winter

IESG state changed to Publication Requested

2014-10-09

08

Stefan Winter

IESG process started in state Publication Requested

2014-10-09

08

Stefan Winter

Changed document writeup

2014-10-09

08

Stefan Winter

Changed document writeup

2014-09-24

08

Alan DeKok

New version available: draft-ietf-radext-nai-08.txt

2014-09-23

07

Alan DeKok

New version available: draft-ietf-radext-nai-07.txt

2014-06-17

06

Alan DeKok

New version available: draft-ietf-radext-nai-06.txt

2014-03-25

05

Stefan Winter

Document shepherd changed to Stefan Winter

2014-03-17

05

Jouni Korhonen

Intended Status changed to Proposed Standard from None

2014-03-17

05

Jouni Korhonen

Document shepherd changed to Mauricio Sanchez

2014-02-20

05

Jouni Korhonen

Will do the proto after IETF.

Feb 19th from Alan:

Jouni Korhonen wrote:> OK, I was waiting since you said you would have a ...

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.

2014-02-20

05

Jouni Korhonen

Tag Revised I-D Needed - Issue raised by WGLC cleared.

2014-02-20

05

Jouni Korhonen

IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call

2013-11-06

05

Alan DeKok

New version available: draft-ietf-radext-nai-05.txt

2013-10-17

04

Alan DeKok

New version available: draft-ietf-radext-nai-04.txt

2013-06-18

03

Jouni Korhonen

Annotation tag Revised I-D Needed - Issue raised by WGLC set.

2013-06-03

03

Jouni Korhonen

IETF WG state changed to In WG Last Call from WG Document

2013-06-03

03

Jouni Korhonen

Annotation tag Other - see Comment Log set.

2013-05-23

03

Jouni Korhonen

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

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.