Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations
draft-klensin-idna-rfc5891bis-06

[Ballot discuss]
[Remove the item that was addressed in -06. Add new DOWNREF issue.]

Taking over this DISCUSS from Alissa.

> (2) Section 4 says:
>
>    "While the IETF rarely gives advice to those who choose to violate
>    IETF Standards, some advice to zones in the second category above may
>    be in order.  That advice is that significant conservatism in what is
>    allowed to be registered, even for reservation purposes, and even
>    more conservatism about what labels are actually entered into zones
>    and delegated, is the best option for the Internet and its users."
>
> I don't see how we can have this formulation in a consensus IETF document.
> Either we are giving the advice to the specific audience, in which we should
> give it in a straightforward manner, or we are not giving the advice, in which
> case we should not have this text in the document. I think a better approach
> would be to re-formulate the whole paragraph in which this text is embedded to
> explain what the best practices are as far as conservatism for registries and
> registrars of any type.

On this one, I see no text changes in -06. I agree with Alissa's objection.
Asmus Freytag proposed a rephrasing that looks like it would address this DISCUSS.

Appendix "A.6.", paragraph 9, discuss:
>    o  References to RFCs 5893 and 6912 moved from Informative to
>      Normative.

This change created a new DOWNREF to RFC6912 that consequently has not been
through IETF Last Call.

[Ballot comment]
[I thought I would skip these, but since this will likely need another IETF Last Call,
maybe you want to pick some of these suggestions up as well.]

This document uses RFC2119 keywords, but does not contain the recommended
RFC8174 boilerplate. (It contains some text with a similar beginning.)

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools, so there will likely be some false positives. There is no need
to let me know what you did with these suggestions.

Section 4, paragraph 7, nit:
-    operate to produce revenue about actual costs, are sufficiently
-                                  ^^
+    operate to produce revenue above actual costs, are sufficiently
+                                  ^^

Section 2, paragraph 3, nit:
>  already registered in the zone, so as to avoid homograph attacks [Gabrilovic
>                                  ^^^^^^^^
'So as to' expresses purpose and is used in formal texts. Consider using "to"

Section 2, paragraph 4, nit:
> nion of the needs for all zones as well as to the desires of the most permiss
>                                ^^^^^^^^^^
Probable usage error. Use "and" after 'both'.

Section 3, paragraph 7, nit:
> olicy, with the expectation that some of the code points in the MSR would not
>                                  ^^^^^^^^^^^^^^^^^^
If the text is a generality, 'of the' is not necessary.

Section 3, paragraph 9, nit:
> ts they understand. In this, some of the other recommendations, such as the I
>                              ^^^^^^^^^^^
If the text is a generality, 'of the' is not necessary.

Section 4, paragraph 5, nit:
> t might be considered clever, much less ones that are hard to type, render, o
>                                    ^^^^
Did you mean "fewer"? The noun ones is countable.

Section 5.1, paragraph 2, nit:
>  In retrospect and contrary to some of the suggestions in the errata, that va
>                                ^^^^^^^^^^^
If the text is a generality, 'of the' is not necessary.

Section 5.1, paragraph 2, nit:
> vely with Unicode code points. Consequently the relevant material in RFC 5890
>                                ^^^^^^^^^^^^
Did you forget a comma after a conjunctive/linking adverb?

Section 5.1, paragraph 7, nit:
>  UTF-32), U-labels that obey all of the relevant symmetry (and other) constra
>                              ^^^^^^^^^^
Consider using "all the".

[Ballot discuss]
Taking over this DISCUSS from Alissa.

> (1) Labeling one category of zones as "for-profit" gives me pause because a
> number of such zones are operated by not-for-profit entities, and retaining
> that status is quite important for both them and the Internet (e.g., .org,
> which is obviously significant for the IETF). I think the distinction being
> made is not whether the zone is run for profit, but whether it is commercial
> -- that is, whether domain names in the zone are bought and sold.

I believe this was addressed in -06.

> (2) Section 4 says:
>
>    "While the IETF rarely gives advice to those who choose to violate
>    IETF Standards, some advice to zones in the second category above may
>    be in order.  That advice is that significant conservatism in what is
>    allowed to be registered, even for reservation purposes, and even
>    more conservatism about what labels are actually entered into zones
>    and delegated, is the best option for the Internet and its users."
>
> I don't see how we can have this formulation in a consensus IETF document.
> Either we are giving the advice to the specific audience, in which we should
> give it in a straightforward manner, or we are not giving the advice, in which
> case we should not have this text in the document. I think a better approach
> would be to re-formulate the whole paragraph in which this text is embedded to
> explain what the best practices are as far as conservatism for registries and
> registrars of any type.

On this one, I see no text changes in -06.

[Ballot comment]
Trimming most of my comments originally on the -05 as (assumed to be)
addressed or explained to be non-issues.  I can't find in my archives anything
that is responsive to the following one, though (my apologies if I just didnt'
look hard enough):

I'm not really sure I understand the response to the secdir reviewer's
suggestion to more clearly differentiate "domain registry", "IANA
registry", and "script registry"; could the relevant portion of the
reply be pointed out more clearly?  (Absent a better understanding of
the existing response, I have similar sentiments as the reviewer.)


Additional comments on the -06:

draft-klensin-idna-unicode-review became RFC 8753; is there a reason
to mention it instead of just removing the pointer to the draft?

s/revenue about actual costs/revenue above actual costs/?

[Ballot discuss]
I expect to ballot Yes once this small issue is addressed.

Section 3 says:

  further protection for registrants and users.  For example, the
  widely-used principle that bars labels containing characters from
  more than one script is not an IDNA2008 requirement.  It has been
  adopted by many registries but, as Section 4.4 of RFC 5890 indicates,
  there may be circumstances in which is it not required or
  appropriate.

I don't get that sense from reading Section 4.4 of RFC 5890; rather, to
me it is just noting that applying this rule cannot be a complete
solution. I do not see 5890 as providing positive support for the
existence of cases when the rule is harmful.

[Ballot comment]
I'm not really sure I understand the response to the secdir reviewer's
suggestion to more clearly differentiate "domain registry", "IANA
registry", and "script registry"; could the relevant portion of the
reply be pointed out more clearly?  (Absent a better understanding of
the existing response, I have similar sentiments as the reviewer.)

Section 1

  Instead, the algorithm and rules of RFCs 5891 and 5892 eliminate many
  of the most dangerous and otherwise problematic cases, but cannot
  eliminate the need for registries and registrars to understand what
  they are doing and taking responsibility for the decisions they make.

Would it be appropriate to document in this document the enforcement
mechanisms available against registries and registrars that fail to mee
these requirements?

  number of names registered and delegated from them.  While rarely
  reflected in the DNS protocols, the distinction between domains
  operated in those ways and ones that are operated for, e.g., use
  within an enterprise or otherwise as a service have become very
  important today.  See Section 4 for a discussion on how those issues
  affect this specification.

nit: I suggest disambiguating "those ways".

            It also makes a specific recommendation for character
  repertoire subsetting intermediate between the code points allowed by
  RFCs 5891 and 5892 and those allowed by individual registries.  It
  does not alter the basic IDNA2008 protocols and rules themselves in
  any way.

nit: is the meaning unchanged if "that is" is inserted prior to
"intermediate"?  I think that doing so would make the sentence easier to
parse.

Section 2

  The chosen list MUST be a subset of the collection of code points
  specified as "PVALID", "CONTEXTJ", and "CONTEXTO" by the rules
  established by the protocols themselves.  [...]

nit: I'm failing to remember why this is "protocols" plural.

  In consequence, additional registry restrictions are essential to
  provide for the necessary security in the face of the tremendous
  variations and differences in writing systems, their ongoing
  evolution and development, as well as the human ability to recognize
  and distinguish characters in different scripts around the world and
  under different circumstances.

nit: "in the face of" looks to introduce a list of items, but "as well
as" does not function as a conjunction to terminate the list.

Section 3

  points that may be particularly important for complex scripts.  They
  also interact with recommendations about how labels that appear to be
  the same or apparently the same should be handled.

I don't understand the intended distinction between "appear to be the
same" and "appear to be apparently the same".

  constructing policies that disallow characters used in historic
  writing systems (whether these be archaic scripts or extensions of
  modern scripts for historic or obsolete orthographies) or characters
  whose use is restricted to specialized, or highly technical contexts.

nit: I think this comma is superfluous.

      vowel signs and the like.  While, theoretically, any combining
      mark may occur in any context in Unicode, in practice rendering
      and other software that users rely on in viewing or entering
      labels will not support arbitrary combining sequences, or indeed
      arbitrary combinations of code points, in the case of complex
      scripts.

An example might be highly illustrative for readers that do not have
prior interaction with any of the scripts in question.

      registries to only support code points they understand.  In this,
      some of the other recommendations, such as the Informational RFCs
      for specific scripts (e.g., Cyrillic [RFC5992]) or languages
      (e.g., Arabic [RFC5564] or Chinese [RFC4713]), or the Root Zone
      LGRs developed by ICANN, may provide useful guidance.

nit: "which other recommendations?"

Section 4

I'm reluctant to wade into the "for-profit" tussle, but will observe
that a highly relevant attribute of the zones in question is that they
are incentivized to maximize the number of subdomains/registrations in
the zone.  I'm not sure whether a pithy turn of phrase that builds on
that observation is possible, though.

      Zones operating primarily or exclusively within an organization or
      enterprise and responsible to that organization or enterprise.
      DNS operations, including registrations and delegations, will
      typically occur in support of the purpose of that organization or
      enterprise rather than being its primary purpose.

nit: I'd suggest s/rather than being its primary purpose/rather than
being the primary purpose of the organization/ to avoid misbinding
"its".

  While the IETF rarely gives advice to those who choose to violate
  IETF Standards, some advice to zones in the second category above may
  be in order.  That advice is that significant conservatism in what is
  allowed to be registered, even for reservation purposes, and even
  more conservatism about what labels are actually entered into zones
  and delegated, is the best option for the Internet and its users.  If

I agree with Alissa that the same impact can be had by just making the
recommendation without the intro.

Section 5

  Because further updates to RFC 5892 would require addressing other
  pending issues, the outstanding erratum for that document is not
  considered here.  [...]

  Readers should note that an update to RFC 5892 that is primarily
  concerned with the review process for new versions of Unicode but
  that makes some additional patches
  [ID.draft-klensin-idna-unicode-review] is in progress.  [...]

I think that the paragraph/content split here should be revisited; the
intervening note about preserving references to Unicode 5.0 is logically
separate but the two quoted points are intrinsically related.  The
former leaves the reader with the impression that there are latent
unresolved issues with 5892, an impression that does not seem to be
supported by the reality of the other document.

Section 5.1

      New:  A-labels (the form actually used in the DNS) and the
        Punycode algorithm used as part of the process to produce them
        [RFC3492] are strings that are potentially much more compressed
        than any standard Unicode Encoding Form.  A 63 octet A-label
        cannot represent more than 58 Unicode code points (four octet
        overhead and the requirement that at least one character lie
        outside the ASCII range) but implementations allocating buffer
        space for the conversion should allow significantly more space
        depending on the encoding form they are using.

"more space" in what units/metric?

Section 6


  This document is one of a series of measures that have been suggested
  to address IDNA issues raised in other documents, including
  mechanisms for dealing with combining sequences and single-code point
  characters with the same appearance that normalization neither
  combines nor decomposes as IDNA2008 assumed [IDNA-Unicode], including
  the IAB response to that issue [IAB-2015], and to take a higher-level
  view of issues, demands, and proposals for new uses of the DNS.

This sentence is pretty long, and includes the word "including" twice in
a nested fashion.  I strongly suggest splitting it up.
In particular, is it this document that is acting "to take a
higher-level view"?

                          The discussion of combining sequences and
  non-decomposing characters is intended to lay the foundation for an
  actual update to the IDNA code points document [RFC5892].  Such an
  update will presumably also address the existing errata against that
  document.

nit: Seeing "the discussion" makes me want to look in the current
document and not, as I think is the case, in the other documents that
are being alluded to here.  It does make one wonder if, when it's other
documents that are doing this ground-laying, we really need to mention
a prospective update to 5892 here.

Section 10.2

Since we use normative language ("MUST also conform to the requirements
of RFC 5893"), my interpretation of
https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/
is that 5893 would need to be a normative reference ... unless we change
Section 3 to not use "MUST" outside of a literal quotation from 5893.
AIUI, doing the latter would not change any requirements on anyone.

On the other hand, I don't have an easy way to make RFC 6912 not need to
be a normative reference ("a registry SHOULD follow the IAB guidance in
RFC 6912").

[Ballot discuss]
(1) Labeling one category of zones as "for-profit" gives me pause because a number of such zones are operated by not-for-profit entities, and retaining that status is quite important for both them and the Internet (e.g., .org, which is obviously significant for the IETF). I think the distinction being made is not whether the zone is run for profit, but whether it is commercial -- that is, whether domain names in the zone are bought and sold.

(2) Section 4 says:

"While the IETF rarely gives advice to those who choose to violate
  IETF Standards, some advice to zones in the second category above may
  be in order.  That advice is that significant conservatism in what is
  allowed to be registered, even for reservation purposes, and even
  more conservatism about what labels are actually entered into zones
  and delegated, is the best option for the Internet and its users."

I don't see how we can have this formulation in a consensus IETF document. Either we are giving the advice to the specific audience, in which we should give it in a straightforward manner, or we are not giving the advice, in which case we should not have this text in the document. I think a better approach would be to re-formulate the whole paragraph in which this text is embedded to explain what the best practices are as far as conservatism for registries and registrars of any type.

[Ballot comment]
** Section 2.  Recommend citing homograph attacks like was done in RFC8324:
[CACM-Homograph] Gabrilovich, E. and A. Gontmakher, "The Homograph Attack", Communications of the ACM, Volume 45, Issue 2, pp. 128, DOI 10.1145/503124.503156, February 2002, .

** Section 2.  Per “The most obvious of those restrictions include provisions … so as to avoid homograph attacks and other issues”, what are “other issues"?

** Section 3.  Per “registries SHOULD normally consult … [ICANN-MSR4]”, what does the normative language of consulting mean here?

** Section 4.  Per “IDNA (and IDNs generally) would work better and Internet users would be better protected and more secure if registries and registrars (of any type) confined their registrations to scripts and code point sequences that they understood thoroughly”:

-- Is there a citation to back the claim that tighter scripts/code point sequences have resulted in better end user security? Or that loose practices are sources of attacks?

-- what does “understood thoroughly” mean here?  How does one know that they have an “understanding”?

** Section 7.  Per “As discussed in IAB recommendations about internationalized domain names [RFC4690], [RFC6912], and elsewhere, poor choices of strings for DNS labels can lead to opportunities for attack …”, isn’t the key issue design policies for the labels (as noted later).  An attacker choosing a clever name doesn’t seem like a poor choice of a string.

[Ballot comment]
Thank you for the work put into this document. I have only one easy to fix COMMENT but I also wonder (like Mirja) about the sections about errata.

Regards,

-éric

== COMMENTS ==

-- Section 1 --
C.1) Please use a the RFC 8174 boilerplate.

[Ballot comment]
I think the status of this document should be BCP or informational. The shepherd write-up says that it's PS because it updates rfc5890, however, I don't think there is requirement for an updating document to have the same status (given this is "just" and update and not a bis that's obsoleting the old doc; which btw. is confusing given this naming of this draft).

I also don't find it a useful practice to (only) update RFCs to integrate errata. If the errata as currently logged as verified are not correct (and the document is not actually obsoleted by a bis), there should probably be a way to update the errata correctly.

1. Summary
Pete Resnick resnick@episteme.net is the document shepherd. Barry Leiba
is the responsible AD.

Abstract

The IDNA specifications for internationalized domain names combine
rules that determine the labels that are allowed in the DNS without
violating the protocol itself and an assignment of responsibility,
consistent with earlier specifications, for determining the labels
that are allowed in particular zones. Conformance to IDNA by
registries and other implementations requires both parts. Experience
strongly suggests that the language describing those responsibilities
was insufficiently clear to promote safe and interoperable use of the
specifications and that more details and discussion of circumstances
would have been helpful. Without making any substantive changes to
IDNA, this specification updates two of the core IDNA documents (RFC
5980 and 5891) and the IDNA explanatory document (RFC 5894) to
provide that guidance and to correct some technical errors in the
descriptions.

This document is primarily aimed at registries and registrars, giving
deployment and operations guidance for IDNA. If it were up to the
shepherd, that reads like the very definition of a BCP document (see RFC
2026, section 5, paragraph 2). However, this "updates" RFC 5891,
a Standards Track document, which speaks to making this Standards Track.

2. Review and Consensus
This document has not been formally reviewed on any IETF list, including
on the i18ndir list, though a few key directorate participants have read
and commented on the document.  The document was mentioned on the
idna-update list, and some comments came from there. That said, this is a
document regarding recommendations to the registry and registrar
community that could only be developed by experts on IDNA, of which the
IETF has very few. A 4-week IETF-wide Last Call (as required for
individual submissions) is more than enough time for the i18ndir list to
remind experts to take a final look and confirm that there is community
consensus, insofar as that ever exists for these kinds of documents.

As a matter of style, there is a lot of repetitive text in the first 4
sections. However, I'm well aware of the target audience of this
document, and so this level of explication is probably reasonable.

3. Intellectual Property
Each author has stated that their direct, personal knowledge of any IPR
related to this document has already been disclosed, in conformance with
BCPs 78 and 79. There has been no other discussion of IPR regarding this
document, and the shepherd has no reason to believe that any applicable
IP exists.

4. Other Points
The idnits check has a few things:

References to 1591 and 5894 are downrefs, but they are reasonable and
have been called out during Last Call.

Other reference nits are false positives.

The Abstract appropriately talks about the updates, even though idnits
couldn't parse it. No problem there.

All of the other checklist items seem satisfied.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-klensin-idna-rfc5891bis-04, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

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

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-08-30):

From: The IESG
To: IETF-Announce
CC: draft-klensin-idna-rfc5891bis@ietf.org, resnick@episteme.net, barryleiba@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations) to Proposed Standard


The IESG has received a request from an individual submitter to consider the
following document: - 'Internationalized Domain Names in Applications (IDNA):
Registry
  Restrictions and Recommendations'
  as Proposed Standard

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

Abstract
  The IDNA specifications for internationalized domain names combine
  rules that determine the labels that are allowed in the DNS without
  violating the protocol itself and an assignment of responsibility,
  consistent with earlier specifications, for determining the labels
  that are allowed in particular zones.  Conformance to IDNA by
  registries and other implementations requires both parts.  Experience
  strongly suggests that the language describing those responsibilities
  was insufficiently clear to promote safe and interoperable use of the
  specifications and that more details and discussion of circumstances
  would have been helpful.  Without making any substantive changes to
  IDNA, this specification updates two of the core IDNA documents (RFC
  5980 and 5891) and the IDNA explanatory document (RFC 5894) to
  provide that guidance and to correct some technical errors in the
  descriptions.


The file can be obtained via
https://datatracker.ietf.org/doc/draft-klensin-idna-rfc5891bis/

When IESG discussion has begun, it can be tracked via
https://datatracker.ietf.org/doc/draft-klensin-idna-rfc5891bis/ballot/


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


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc5894: Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale (Informational - IETF stream)
    rfc1591: Domain Name System Structure and Delegation (Informational - Legacy stream)

1. Summary
Pete Resnick resnick@episteme.net is the document shepherd. Barry Leiba is the responsible AD.

Abstract

The IDNA specifications for internationalized domain names combine
rules that determine the labels that are allowed in the DNS without
violating the protocol itself and an assignment of responsibility,
consistent with earlier specifications, for determining the labels
that are allowed in particular zones. Conformance to IDNA by
registries and other implementations requires both parts. Experience
strongly suggests that the language describing those responsibilities
was insufficiently clear to promote safe and interoperable use of the
specifications and that more details and discussion of circumstances
would have been helpful. Without making any substantive changes to
IDNA, this specification updates two of the core IDNA documents (RFC
5980 and 5891) and the IDNA explanatory document (RFC 5894) to
provide that guidance and to correct some technical errors in the
descriptions.

This document is primarily aimed at registries and registrars, giving
deployment and operations guidance for IDNA. If it were up to the
shepherd, that reads like the very definition of a BCP document (see RFC
2026, section 5, paragraph 2). However, there are always politics
involved in the categorization of documents, and this document may be
perceived as "less important" to the right people (the 2026 approval
requirements of BCPs notwithstanding) if it is not on the standards
track, so the shepherd will fail to make a stink if the IESG should
choose a different path.

2. Review and Consensus
This document has not been formally reviewed on any IETF list, including
on the i18ndir list, though a few key directorate participants have read
and commented on the document. That said, this is a document regarding
recommendations to the registry and registrar community that could only
be developed by experts on IDNA, of which the IETF has very few. A 4-week
IETF-wide Last Call (as required for individual submissions) is more than
enough time for the i18ndir list to remind experts to take a final look
and confirm that there is community consensus, insofar as that ever
exists for these kinds of documents.

As a matter of style, there is a lot of repetitive text in the
first 4 sections. I would do an editing pass and cut out a lot of fluff.
However, I'm well aware of the target audience of this document, and so
perhaps this level of explication is reasonable. I leave it to the
authors and the AD to decide if such and edit pass is necessary.

3. Intellectual Property
Each author has stated that their direct, personal knowledge of any IPR
related to this document has already been disclosed, in conformance with
BCPs 78 and 79. There has been no other discussion of IPR regarding this
document, and the shepherd has no reason to believe that any applicable
IP exists.

4. Other Points
The idnits check has a few things:

References to 1591 and 5894 are downrefs, but they seem reasonable and
should be called out during Last Call.

Other reference nits are false positives.

The Abstract appropriately talks about the updates, even though idnits
couldn't parse it. No problem there.

All of the other checklist items seem satisfied.

AD review:

Before we go into last call on this document, I have a few comments
that I'd like addressed.  Some are nits, which I'm not worried about
before last call, but there are some substantive ones that I'd like
fixed first... so let's just handle the lot.

-- Section 2 --

  The chosen list MUST BE smaller than the collection of code points
  specified as "PVALID", "CONTEXTJ", and "CONTEXTO" by the rules
  established by the protocols themselves.

Nit: "be" should be in lower case.
More substantive: I don't think "smaller than" is right here; we're
not talking about size, but composition.  Maybe you want "a subset
of"?

  The latter two categories,
  and labels containing any characters that are normally part of a
  script written right to left [RFC5893], require that additional

Nit: There are three, so "the last two".
More substantive: You're mixing categories of characters with labels
in that sentence.  You mean this, I think:

NEW
  Labels containing any characters from the last
  two categories or any characters that are normally part of a
  script written right to left [RFC5893] require that additional
END

  These per-registry (or per-zone) rules are commonly known as
  "registry restrictions"
...
  In consequence,
  additional Registry restrictions are essential to provide for the

Please use consistent capitalization for "registry restrictions".

-- Section 3 --

  The algorithm and rules of RFC 5891 and 5892 set an absolute upper
  bound on the code points that can be used in domain name labels;

Again, "upper bound" is talking about numbers, and here we don't mean
a limit on the number of code points.  I think "set an absolute
boundary around the code points" is better.  I don't think this is a
nit: I want to be sure that no one reads this and thinks we're talking
about the *number* of characters in the set.

  It has been adopted by many
  registries but, as Section 4.4 of RFC 5890 indicates

I know John doesn't like to write this like "as Section 4.4 of
[RFC5890] indicates", but as the tools currently work, this will
result in a clickable link in the HTML rendering to that section,
where the existing text won't.  Do as you think best, but I just
wanted to point that out.

  recommendations on how to deal with alternate representations of the
  same or apparently the same labels.

Nit: "alternative", please.
Also, I think it reads better this way:

NEW
  recommendations on how to deal with alternative representations of the
  same label, or of labels that appear the same.
END

  Particularly for a zone for which all labels to be delegated are not
  for the use of the same organization or enterprise, a registry

Ooh, très awkward.  I think you mean this (but correct it elsewise if
I got it wrong, but please do re-word it):

NEW1
  Particularly for a zone for which not all labels to be delegated are
  for the use of the same organization or enterprise, a registry
END

...or, probably better:

NEW2
  Particularly for a zone for which labels to be delegated are
  for the use of mixed organizations or enterprises, a registry
END

  1.  The MSR, like the set of code points permissible under IDNA2008
      itself, was conceived merely as an upper bound on permissible

There's "an upper bound on" again; please fix ("a boundary around").

      Contextual rules are required to limit allowable code point
      sequences to those that can be expected to be rendered reliably.

Because we often use "X is required to " to place a
requirement on the behaviour of X, I'd word this differently to make
it clear that it's not that:

NEW
      Contextual rules are needed in order to limit allowable code point
      sequences to those that can be expected to be rendered reliably.
END

Nit: "on a per script basis" needs a hyphen: "on a per-script basis"

  Registries choosing to make exceptions and allow code points that
  recommendations such as the MSR do not allow should make such
  decisions only with great care and only if they have considerable
  understanding of, and great confidence in, their appropriateness.

Nit: A little more punctuation would make this easier to read.  I'd do this:

NEW
  Registries choosing to make exceptions -- to allow code points that
  recommendations such as the MSR do not allow -- should make such
  decisions only with great care and only if they have considerable
  understanding of, and great confidence in, their appropriateness.
END

-- Section 4 --

  These include These
  include ICANN's twin efforts of creating per-script Root Zone Label

There's a There's a paste error there.

-- Section 5 --

  Readers should note that an update to RFC 5892 that is primarily
  concerned with the review process for new versions of Unicode but
  that makes some additional patches
  [ID.draft-klensin-idna-unicode-review] is in progress.  Its status
  should be checked in conjunction with application of the present
  specification.

Not necessarily an issue for now, but this will need to be re-worded
during AUTH48.  If you want to do it now, we can try this:

NEW
  Readers should note that [ID.draft-klensin-idna-unicode-review]
  is an update to RFC 5892 that is primarily concerned with the
  review process for new versions of Unicode and also makes
  some additional patches.  That document
  should be checked in conjunction with application of the present
  specification.
END

-- Section 9 --
No issue here, just flagging it: IANA will ask that you leave the IANA
Considerations section in, rather than having the RFC Editor remove
it.  I don't care either way, but I suggest we leave it in as IANA
will suggest.

1. Summary
Pete Resnick resnick@episteme.net is the document shepherd. Barry Leiba is the responsible AD.

Abstract

The IDNA specifications for internationalized domain names combine
rules that determine the labels that are allowed in the DNS without
violating the protocol itself and an assignment of responsibility,
consistent with earlier specifications, for determining the labels
that are allowed in particular zones. Conformance to IDNA by
registries and other implementations requires both parts. Experience
strongly suggests that the language describing those responsibilities
was insufficiently clear to promote safe and interoperable use of the
specifications and that more details and discussion of circumstances
would have been helpful. Without making any substantive changes to
IDNA, this specification updates two of the core IDNA documents (RFC
5980 and 5891) and the IDNA explanatory document (RFC 5894) to
provide that guidance and to correct some technical errors in the
descriptions.

This document is primarily aimed at registries and registrars, giving
deployment and operations guidance for IDNA. If it were up to the
shepherd, that reads like the very definition of a BCP document (see RFC
2026, section 5, paragraph 2). However, there are always politics
involved in the categorization of documents, and this document may be
perceived as "less important" to the right people (the 2026 approval
requirements of BCPs notwithstanding) if it is not on the standards
track, so the shepherd will fail to make a stink if the IESG should
choose a different path.

2. Review and Consensus
This document has not been formally reviewed on any IETF list, including
on the i18ndir list, though a few key directorate participants have read
and commented on the document. That said, this is a document regarding
recommendations to the registry and registrar community that could only
be developed by experts on IDNA, of which the IETF has very few. A 4-week
IETF-wide Last Call (as required for individual submissions) is more than
enough time for the i18ndir list to remind experts to take a final look
and confirm that there is community consensus, insofar as that ever
exists for these kinds of documents.

The shepherd has done a review of the document and is satisfied with the
technical content. The following are editorial comments by the shepherd,
some of which should be fixed before Last Call.

Section 1

¶1: The words "trustee for the community" do not appear in RFC 1591.
Indeed, the talk of the 'responsibilities' and 'service' to the
community" in 1591 have little, if anything, to do with permitted
characters, and is probably about something that is completely the
opposite of ICANN's charge today (cf. ¶5 in this section, even though it
underplays how much 1591 differs from the current state of affairs). That
said, at least a reword of the sentence containing the quote seems
appropriate. Perhaps something like this:

That requirement and restriction are consistent with the "duty to
serve the community" described in the original specification for DNS
naming and authority [RFC1591].

¶4: I would change "obscured" to "underplayed". The text in the original
IDNA specs seems clear to me, but didn't yell it very loudly.

Section 4, change "no no" to "no". Also, you are still missing a
reference in the last paragraph for "generation rules" (as per the CREF).

Section 5.1, last paragraph: No, I don't think you need a reference here.

Section 5.2: The first sentence doesn't parse.

Finally, as a matter of style, there is a lot of repetitive text in the
first 4 sections. I would do an editing pass and cut out a lot of fluff.
However, I'm well aware of the target audience of this document, and so
perhaps this level of explication is reasonable. I leave it to the
authors and the AD to decide if such and edit pass is necessary.

3. Intellectual Property
Each author has stated that their direct, personal knowledge of any IPR
related to this document has already been disclosed, in conformance with
BCPs 78 and 79. There has been no other discussion of IPR regarding this
document, and the shepherd has no reason to believe that any applicable
IP exists.

4. Other Points
The idnits check has a few things:

Reference to [Unicode] is not resolved in the References. That should be
fixed by the authors.

References to 1591 and 5894 are downrefs, but they seem reasonable and
should be called out during Last Call.

Other reference nits are false positives.

The Abstract appropriately talks about the updates, even though idnits
couldn't parse it. No problem there.

All of the other checklist items seem satisfied.

1. Summary
Pete Resnick resnick@episteme.net is the document shepherd. Barry Leiba is the responsible AD.

Abstract

The IDNA specifications for internationalized domain names combine
rules that determine the labels that are allowed in the DNS without
violating the protocol itself and an assignment of responsibility,
consistent with earlier specifications, for determining the labels
that are allowed in particular zones. Conformance to IDNA by
registries and other implementations requires both parts. Experience
strongly suggests that the language describing those responsibilities
was insufficiently clear to promote safe and interoperable use of the
specifications and that more details and discussion of circumstances
would have been helpful. Without making any substantive changes to
IDNA, this specification updates two of the core IDNA documents (RFC
5980 and 5891) and the IDNA explanatory document (RFC 5894) to
provide that guidance and to correct some technical errors in the
descriptions.

This document is primarily aimed at registries and registrars, giving deployment and operations guidance for IDNA. If it were up to the shepherd, that reads like the very definition of a BCP document (see RFC 2026, section 5, paragraph 2). However, there are always politics involved in the categorization of documents, and this document may be perceived as "less important" to the right people (the 2026 approval requirements of BCPs notwithstanding) if it is not on the standards track, so the shepherd will fail to make a stink if the IESG should choose a different path.

2. Review and Consensus
This document has not been formally reviewed on any IETF list, including on the i18ndir list, though a few key directorate participants have read and commented on the document. That said, this is a document regarding recommendations to the registry and registrar community that could only be developed by experts on IDNA, of which the IETF has very few. A 4-week IETF-wide Last Call (as required for individual submissions) is more than enough time for the i18ndir list to remind experts to take a final look and confirm that there is community consensus, insofar as that ever exists for these kinds of documents.

The shepherd has done a review of the document and is satisfied with the technical content. The following are editorial comments by the shepherd, some of which should be fixed before Last Call.

Section 1

¶1: The words "trustee for the community" do not appear in RFC 1591. Indeed, the talk of the 'responsibilities' and 'service' to the community" in 1591 have little, if anything, to do with permitted characters, and is probably about something that is completely the opposite of ICANN's charge today (cf. ¶5 in this section, even though it underplays how much 1591 differs from the current state of affairs). That said, at least a reword of the sentence containing the quote seems appropriate. Perhaps something like this:

That requirement and restriction are consistent with the "duty to
serve the community" described in the original specification for DNS
naming and authority [RFC1591].

¶4: I would change "obscured" to "underplayed". The text in the original IDNA specs seems clear to me, but didn't yell it very loudly.

Section 4, change "no no" to "no". Also, you are still missing a reference in the last paragraph for "generation rules" (as per the CREF).

Section 5.1, last paragraph: No, I don't think you need a reference here.

Section 5.2: The first sentence doesn't parse.

Finally, as a matter of style, there is a lot of repetitive text in the first 4 sections. I would do an editing pass and cut out a lot of fluff. However, I'm well aware of the target audience of this document, and so perhaps this level of explication is reasonable. I leave it to the authors and the AD to decide if such and edit pass is necessary.

3. Intellectual Property
Each author has stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79. There has been no other discussion of IPR regarding this document, and the shepherd has no reason to believe that any applicable IP exists.

4. Other Points
The idnits check has a few things:

Reference to [Unicode] is not resolved in the References. That should be fixed by the authors.

References to 1591 and 5894 are downrefs, but they seem reasonable and should be called out during Last Call.

Other reference nits are false positives.

The Abstract appropriately talks about the updates, even though idnits couldn't parse it. No problem there.

All of the other checklist items seem satisfied.