Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2023-08-18
06 Murray Kucherawy IESG state changed to AD Evaluation from AD is watching
2023-08-18
06 Murray Kucherawy Document is now in IESG state AD is watching
2023-08-18
06 Murray Kucherawy Reverting to base state.  This document once revived will need a new Last Call and a fresh ballot.
2023-08-18
06 (System) Changed action holders to Murray Kucherawy (IESG state changed)
2023-08-18
06 Murray Kucherawy IESG state changed to I-D Exists from IESG Evaluation::AD Followup
2021-04-26
06 Lars Eggert
[Ballot discuss]
[Remove the item that was addressed in -06. Add new DOWNREF issue.]

Taking over this DISCUSS from Alissa.

> (2) Section 4 says: …
[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.
2021-04-26
06 Lars Eggert
[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 …
[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".
2021-04-26
06 Lars Eggert Ballot comment and discuss text updated for Lars Eggert
2021-04-22
06 Lars Eggert
[Ballot discuss]
Taking over this DISCUSS from Alissa.

> (1) Labeling one category of zones as "for-profit" gives me pause because a
> number of …
[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.
2021-04-22
06 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded for Lars Eggert
2021-03-08
06 Barry Leiba Shepherding AD changed to Murray Kucherawy
2020-07-13
06 Benjamin Kaduk
[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 …
[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/?
2020-07-13
06 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to Yes from Discuss
2020-07-13
06 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-07-13
06 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2020-07-13
06 John Klensin New version available: draft-klensin-idna-rfc5891bis-06.txt
2020-07-13
06 (System) New version approved
2020-07-13
06 (System) Request for posting confirmation emailed to previous authors: Asmus Freytag , John Klensin
2020-07-13
06 John Klensin Uploaded new revision
2019-10-18
05 Gunter Van de Velde Assignment of request for Last Call review by OPSDIR to Tim Chown was marked no-response
2019-09-19
05 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2019-09-19
05 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2019-09-19
05 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2019-09-18
05 Benjamin Kaduk
[Ballot discuss]
I expect to ballot Yes once this small issue is addressed.

Section 3 says:

  further protection for registrants and users.  For example, …
[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.
2019-09-18
05 Benjamin Kaduk
[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 …
[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").
2019-09-18
05 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2019-09-18
05 Alissa Cooper
[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 …
[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.
2019-09-18
05 Alissa Cooper [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper
2019-09-18
05 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2019-09-18
05 Roman Danyliw
[Ballot comment]
** Section 2.  Recommend citing homograph attacks like was done in RFC8324:
[CACM-Homograph] Gabrilovich, E. and A. Gontmakher, "The Homograph Attack", Communications …
[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.
2019-09-18
05 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2019-09-17
05 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2019-09-17
05 Adam Roach [Ballot Position Update] New position, Yes, has been recorded for Adam Roach
2019-09-17
05 Éric Vyncke
[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) …
[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.
2019-09-17
05 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2019-09-05
05 Mirja Kühlewind
[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 …
[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.
2019-09-05
05 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2019-09-02
05 Paul Wouters Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Paul Wouters. Sent review to list.
2019-08-31
05 Alexey Melnikov [Ballot comment]
The document suggests possible changes to other documents, which might not age well once published. These need to be double checked.
2019-08-31
05 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2019-08-30
05 Cindy Morgan Placed on agenda for telechat - 2019-09-19
2019-08-30
05 Barry Leiba Ballot has been issued
2019-08-30
05 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2019-08-30
05 Barry Leiba Created "Approve" ballot
2019-08-30
05 Barry Leiba Ballot writeup was changed
2019-08-30
05 Barry Leiba IESG state changed to IESG Evaluation from Waiting for Writeup
2019-08-30
05 Barry Leiba
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 …
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.
2019-08-30
05 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-08-29
05 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2019-08-29
05 John Klensin New version available: draft-klensin-idna-rfc5891bis-05.txt
2019-08-29
05 (System) New version approved
2019-08-29
05 (System) Request for posting confirmation emailed to previous authors: Asmus Freytag , John Klensin
2019-08-29
05 John Klensin Uploaded new revision
2019-08-29
04 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2019-08-29
04 Sabrina Tanamal
(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 …
(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
2019-08-13
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Chown
2019-08-13
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Chown
2019-08-13
04 Vijay Gurbani Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Vijay Gurbani. Sent review to list.
2019-08-08
04 Jean Mahoney Request for Last Call review by GENART is assigned to Vijay Gurbani
2019-08-08
04 Jean Mahoney Request for Last Call review by GENART is assigned to Vijay Gurbani
2019-08-08
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to Paul Wouters
2019-08-08
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to Paul Wouters
2019-08-02
04 Cindy Morgan IANA Review state changed to IANA - Review Needed
2019-08-02
04 Cindy Morgan
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: …
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)
2019-08-02
04 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2019-08-02
04 Barry Leiba Last call was requested
2019-08-02
04 Barry Leiba Ballot approval text was generated
2019-08-02
04 Barry Leiba Ballot writeup was generated
2019-08-02
04 Barry Leiba IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2019-08-02
04 Barry Leiba Last call announcement was changed
2019-08-02
04 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-08-02
04 John Klensin New version available: draft-klensin-idna-rfc5891bis-04.txt
2019-08-02
04 (System) New version approved
2019-08-02
04 (System) Request for posting confirmation emailed to previous authors: Asmus Freytag , John Klensin
2019-08-02
04 John Klensin Uploaded new revision
2019-08-01
03 Barry Leiba
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 …
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.
2019-08-01
03 Barry Leiba
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 …
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.
2019-08-01
03 Barry Leiba IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2019-08-01
03 Barry Leiba IESG state changed to AD Evaluation from Publication Requested
2019-08-01
03 Barry Leiba
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 …
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.
2019-08-01
03 Barry Leiba IESG process started in state Publication Requested
2019-08-01
03 Barry Leiba IESG state changed to I-D Exists from Dead
2019-08-01
03 Barry Leiba
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 …
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.
2019-08-01
03 Barry Leiba Notification list changed to Pete Resnick <resnick@episteme.net>
2019-08-01
03 Barry Leiba Document shepherd changed to Pete Resnick
2019-08-01
03 Barry Leiba Shepherding AD changed to Barry Leiba
2019-07-22
03 John Klensin New version available: draft-klensin-idna-rfc5891bis-03.txt
2019-07-22
03 (System) New version approved
2019-07-22
03 (System) Request for posting confirmation emailed to previous authors: Asmus Freytag , John Klensin
2019-07-22
03 John Klensin Uploaded new revision
2019-07-22
03 (System) Request for posting confirmation emailed to previous authors: Asmus Freytag , John Klensin
2019-07-22
03 John Klensin Uploaded new revision
2019-07-05
02 John Klensin New version available: draft-klensin-idna-rfc5891bis-02.txt
2019-07-05
02 (System) New version approved
2019-07-05
02 (System) Request for posting confirmation emailed to previous authors: Asmus Freytag , John Klensin
2019-07-05
02 John Klensin Uploaded new revision
2018-04-19
01 (System) Document has expired
2018-04-19
01 (System) IESG state changed to Dead from AD is watching
2017-11-12
01 Murray Kucherawy Added to session: IETF-100: dispatch  Mon-0930
2017-10-23
01 Alexey Melnikov IESG state changed to AD is watching from Dead
2017-09-12
01 John Klensin New version available: draft-klensin-idna-rfc5891bis-01.txt
2017-09-12
01 (System) New version approved
2017-09-12
01 (System) Request for posting confirmation emailed to previous authors: John Klensin , Asmus Freytag
2017-09-12
01 John Klensin Uploaded new revision
2017-09-12
00 (System) Document has expired
2017-09-12
00 (System) IESG state changed to Dead from AD is watching
2017-03-14
00 Alexey Melnikov
Network Working Group                                          J. Jeong …
Network Working Group                                          J. Jeong
Internet-Draft                                  Sungkyunkwan University
Obsoletes: 6106 (if approved)                                    S. Park
Intended status: Standards Track                    Samsung Electronics
Expires: July 21, 2017                                        L. Beloeil
                                                      France Telecom R&D
                                                          S. Madanapalli
                                                      iRam Technologies
                                                        January 17, 2017

        IPv6 Router Advertisement Options for DNS Configuration
                  draft-ietf-6man-rdnss-rfc6106bis-15

Abstract

  This document specifies IPv6 Router Advertisement (RA) options
  (called DNS RA options) to allow IPv6 routers to advertise a list of
  DNS recursive server addresses and a DNS Search List to IPv6 hosts.

  This document, which obsoletes RFC 6106, defines a higher default
  value of the lifetime of the DNS RA options to reduce the likelihood
  of expiry of the options on links with a relatively high rate of
  packet loss.

Status of This Memo

  This Internet-Draft is submitted to IETF in full conformance with the
  provisions of BCP 78 and BCP 79.

  Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF), its areas, and its working groups.  Note that
  other groups may also distribute working documents as Internet-
  Drafts.

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any
  time.  It is inappropriate to use Internet-Drafts as reference
  material or to cite them other than as "work in progress."

  The list of current Internet-Drafts can be accessed at
  http://www.ietf.org/ietf/1id-abstracts.txt.

  The list of Internet-Draft Shadow Directories can be accessed at
  http://www.ietf.org/shadow.html.

  This Internet-Draft will expire on July 21, 2017.

Jeong, et al.            Expires July 21, 2017                [Page 1]
Internet-Draft            IPv6 DNS RA Options              January 2017

Copyright Notice

  Copyright (c) 2017 IETF Trust and the persons identified as the
  document authors.  All rights reserved.

  This document is subject to BCP 78 and the IETF Trust's Legal
  Provisions Relating to IETF Documents
  (http://trustee.ietf.org/license-info) in effect on the date of
  publication of this document.  Please review these documents
  carefully, as they describe your rights and restrictions with respect
  to this document.  Code Components extracted from this document must
  include Simplified BSD License text as described in Section 4.e of
  the Trust Legal Provisions and are provided without warranty as
  described in the Simplified BSD License.

Table of Contents

  1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
    1.1.  Applicability Statements . . . . . . . . . . . . . . . . .  3
    1.2.  Coexistence of RA Options and DHCP Options for DNS
          Configuration  . . . . . . . . . . . . . . . . . . . . . .  4
  2.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  4
  3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
  4.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
  5.  Neighbor Discovery Extension . . . . . . . . . . . . . . . . .  5
    5.1.  Recursive DNS Server Option  . . . . . . . . . . . . . . .  5
    5.2.  DNS Search List Option . . . . . . . . . . . . . . . . . .  7
    5.3.  Procedure of DNS Configuration . . . . . . . . . . . . . .  8
      5.3.1.  Procedure in IPv6 Hosts  . . . . . . . . . . . . . . .  8
      5.3.2.  Warnings for DNS Options Configuration . . . . . . . .  9
  6.  Implementation Considerations  . . . . . . . . . . . . . . . . 10
    6.1.  DNS Repository Management  . . . . . . . . . . . . . . . . 10
    6.2.  Synchronization between DNS Server List and Resolver
          Repository . . . . . . . . . . . . . . . . . . . . . . . . 11
    6.3.  Synchronization between DNS Search List and Resolver
          Repository . . . . . . . . . . . . . . . . . . . . . . . . 12
  7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
    7.1.  Security Threats . . . . . . . . . . . . . . . . . . . . . 12
    7.2.  Recommendations  . . . . . . . . . . . . . . . . . . . . . 12
  8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
  9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
  10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
    10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
    10.2. Informative References . . . . . . . . . . . . . . . . . . 14
  Appendix A.  Changes from RFC 6106 . . . . . . . . . . . . . . . . 16

Jeong, et al.            Expires July 21, 2017                [Page 2]
Internet-Draft            IPv6 DNS RA Options              January 2017

1.  Introduction

  The purpose of this document is to standardize IPv6 Router
  Advertisement (RA) options (DNS RA options) for DNS Recursive Server
  Addresses used for the DNS name resolution in IPv6 hosts, and also
  for a DNS Search List of domain suffixes.

  Neighbor Discovery (ND) for IP version 6 and IPv6 Stateless Address
  Autoconfiguration (SLAAC) provide ways to configure either fixed or
  mobile nodes with one or more IPv6 addresses, default routers, and
  some other parameters [RFC4861][RFC4862].

  It is infeasible to manually configure nomadic hosts each time they
  connect to a different network.  While a one-time static
  configuration is possible, it is generally not desirable on general-
  purpose hosts such as laptops.  For instance, locally defined name
  spaces would not be available to the host if it were to run its own
  recursive name server directly connected to the global DNS.

  The DNS information can also be provided through DHCPv6 [RFC3315]
  [RFC3736][RFC3646].  However, the access to DNS is a fundamental
  requirement for almost all hosts, so IPv6 stateless autoconfiguration
  cannot stand on its own as an alternative deployment model in any
  practical network without any support for DNS configuration.

  These issues are not pressing in dual-stack networks as long as a DNS
  server is available on the IPv4 side, but they become more critical
  with the deployment of IPv6-only networks.  As a result, this
  document defines a mechanism based on DNS RA options to allow IPv6
  hosts to perform the automatic DNS configuration.

1.1.  Applicability Statements

  RA-based DNS configuration is a useful alternative in networks where
  an IPv6 host's address is autoconfigured through IPv6 stateless
  address autoconfiguration and where there is either no DHCPv6
  infrastructure at all or some hosts do not have a DHCPv6 client.  The
  intention is to enable the full configuration of basic networking
  information for hosts without requiring DHCPv6.  However, for
  networks that need to distribute additional information, DHCPv6 is
  likely to be employed.  In these networks, RA-based DNS configuration
  may not be needed.

  RA-based DNS configuration allows an IPv6 host to acquire the DNS
  configuration (i.e., DNS recursive server addresses and DNS Search
  List) for the link(s) to which the host is connected.  Furthermore,
  the host learns this DNS configuration from the same RA message that
  provides configuration information for the link.

Jeong, et al.            Expires July 21, 2017                [Page 3]
Internet-Draft            IPv6 DNS RA Options              January 2017

  The advantages and disadvantages of the RA-based approach are
  discussed in [RFC4339] along with other approaches, such as the DHCP
  and well-known anycast address approaches.

1.2.  Coexistence of RA Options and DHCP Options for DNS Configuration

  Two protocols exist to configure the DNS information on a host, the
  Router Advertisement options specified in this document and the
  DHCPv6 options specified in [RFC3646].  They can be used together.
  The rules governing the decision to use stateful configuration
  mechanisms are specified in [RFC4861].  Hosts conforming to this
  specification MUST extract DNS information from Router Advertisement
  messages, unless static DNS configuration has been specified by the
  user.  If there is DNS information available from multiple Router
  Advertisements and/or from DHCP, the host MUST maintain an ordered
  list of this information as specified in Section 5.3.1.

2.  Requirements Language

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in [RFC2119].

3.  Terminology

  This document uses the terminology defined in [RFC4861] and
  [RFC4862].  In addition, four new terms are defined below:

  o  Recursive DNS Server (RDNSS): Server that provides a recursive DNS
      resolution service for translating domain names into IP addresses
      or resolving PTR records, as defined in [RFC1034] and [RFC1035].

  o  RDNSS Option: IPv6 RA option to deliver the RDNSS information to
      IPv6 hosts [RFC4861].

  o  DNS Search List (DNSSL): The list of DNS suffix domain names used
      by IPv6 hosts when they perform DNS query searches for short,
      unqualified domain names.

  o  DNSSL Option: IPv6 RA option to deliver the DNSSL information to
      IPv6 hosts.

  o  DNS Repository: Two data structures for managing DNS Configuration
      Information in the IPv6 protocol stack in addition to Neighbor
      Cache and Destination Cache for Neighbor Discovery [RFC4861].  The
      first data structure is the DNS Server List for RDNSS addresses
      and the second is the DNS Search List for DNS search domain names.

Jeong, et al.            Expires July 21, 2017                [Page 4]
Internet-Draft            IPv6 DNS RA Options              January 2017

  o  Resolver Repository: Configuration repository with RDNSS addresses
      and a DNS Search List that a DNS resolver on the host uses for DNS
      name resolution; for example, the Unix resolver file (i.e., /etc/
      resolv.conf) and Windows registry.

4.  Overview

  This document standardizes the ND option called the RDNSS option that
  contains the addresses of recursive DNS servers.  This document also
  standardizes the ND option called the DNSSL option that contains the
  Domain Search List.  This is to maintain parity with the DHCPv6
  options and to ensure that there is necessary functionality to
  determine the search domains.

  The existing ND message (i.e., Router Advertisement) is used to carry
  this information.  An IPv6 host can configure the IPv6 addresses of
  one or more RDNSSes via RA messages.  Through the RDNSS and DNSSL
  options, along with the prefix information option based on the ND
  protocol ([RFC4861] and [RFC4862]), an IPv6 host can perform the
  network configuration of its IPv6 address and the DNS information
  simultaneously without needing DHCPv6 for the DNS configuration.  The
  RA options for RDNSS and DNSSL can be used on networks that support
  the use of ND.

  This approach requires the manual configuration or other automatic
  mechanisms (e.g., DHCPv6 or vendor proprietary configuration
  mechanisms) to configure the DNS information in routers sending the
  advertisements.  The automatic configuration of RDNSS addresses and a
  DNS Search List in routers is out of scope for this document.

5.  Neighbor Discovery Extension

  The IPv6 DNS configuration mechanism in this document needs two ND
  options in Neighbor Discovery: (i) the Recursive DNS Server (RDNSS)
  option and (ii) the DNS Search List (DNSSL) option.

5.1.  Recursive DNS Server Option

  The RDNSS option contains one or more IPv6 addresses of recursive DNS
  servers.  All of the addresses share the same Lifetime value.  If it
  is desirable to have different Lifetime values, multiple RDNSS
  options can be used.  Figure 1 shows the format of the RDNSS option.

Jeong, et al.            Expires July 21, 2017                [Page 5]
Internet-Draft            IPv6 DNS RA Options              January 2017

      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type      |    Length    |          Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Lifetime                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                              |
    :            Addresses of IPv6 Recursive DNS Servers            :
    |                                                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 1: Recursive DNS Server (RDNSS) Option Format

  Fields:
    Type          8-bit identifier of the RDNSS option type as assigned
                  by the IANA: 25

    Length        8-bit unsigned integer.  The length of the option
                  (including the Type and Length fields) is in units of
                  8 octets.  The minimum value is 3 if one IPv6 address
                  is contained in the option.  Every additional RDNSS
                  address increases the length by 2.  The Length field
                  is used by the receiver to determine the number of
                  IPv6 addresses in the option.

    Lifetime      32-bit unsigned integer.  The maximum time in
                  seconds (relative to the time the packet is received)
                  over which these RDNSS addresses MAY be used for name
                  resolution.  The value of Lifetime SHOULD by default
                  be at least 3 * MaxRtrAdvInterval where
                  MaxRtrAdvInterval is the Maximum RA Interval defined
                  in [RFC4861].  A value of all one bits (0xffffffff)
                  represents infinity.  A value of zero means that the
                  RDNSS addresses MUST no longer be used.

    Addresses of IPv6 Recursive DNS Servers
                  One or more 128-bit IPv6 addresses of the recursive
                  DNS servers.  The number of addresses is determined
                  by the Length field.  That is, the number of
                  addresses is equal to (Length - 1) / 2.

  Note:  The addresses for recursive DNS servers in the RDNSS option
      MAY be link-local addresses.  Such link-local addresses SHOULD be
      registered into the resolver repository along with the
      corresponding link zone indices of the links that receive the
      RDNSS option(s) for them.  The link-local addresses MAY be

Jeong, et al.            Expires July 21, 2017                [Page 6]
Internet-Draft            IPv6 DNS RA Options              January 2017

      represented in the resolver repository with their link zone
      indices in the textual format for scoped addresses as described in
      [RFC4007].  When a resolver sends a DNS query message to an RDNSS
      identified by a link-local address, it MUST use the corresponding
      link.

      The rationale of the default value of the Lifetime field is as
      follows.  Router Lifetime set by AdvDefaultLifetime has the
      default of 3 * MaxRtrAdvInterval in [RFC4861], so such a default
      or a larger default can allow for the reliability of DNS options
      even under the loss of RAs on links with a relatively high rate of
      packet loss.  Note that the ratio of AdvDefaultLifetime to
      MaxRtrAdvInterval is the number of unsolicited multicasted RAs
      sent by the router.  Since the DNS option entries can survive for
      at most three consecutive losses of RAs containing DNS options,
      the default value of the Lifetime lets the DNS option entries be
      resilient to packet-loss environments.

5.2.  DNS Search List Option

  The DNSSL option contains one or more domain names of DNS suffixes.
  All of the domain names share the same Lifetime value.  If it is
  desirable to have different Lifetime values, multiple DNSSL options
  can be used.  Figure 2 shows the format of the DNSSL option.

      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type      |    Length    |          Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          Lifetime                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                              |
    :                Domain Names of DNS Search List                :
    |                                                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 2: DNS Search List (DNSSL) Option Format

  Fields:
    Type          8-bit identifier of the DNSSL option type as assigned
                  by the IANA: 31

    Length        8-bit unsigned integer.  The length of the option
                  (including the Type and Length fields) is in units of
                  8 octets.  The minimum value is 2 if at least one
                  domain name is contained in the option.  The Length

Jeong, et al.            Expires July 21, 2017                [Page 7]
Internet-Draft            IPv6 DNS RA Options              January 2017

                 
2017-03-14
00 Alexey Melnikov Responsible AD changed to Alexey Melnikov
2017-03-14
00 Alexey Melnikov IESG process started in state AD is watching
2017-03-14
00 Alexey Melnikov Changed consensus to Yes from Unknown
2017-03-14
00 Alexey Melnikov Intended Status changed to Proposed Standard from None
2017-03-14
00 Alexey Melnikov Stream changed to IETF from None
2017-03-11
00 John Klensin New version available: draft-klensin-idna-rfc5891bis-00.txt
2017-03-11
00 (System) New version approved
2017-03-11
00 John Klensin Request for posting confirmation emailed  to submitter and authors: Asmus Freytag , John C Klensin
2017-03-11
00 John Klensin Uploaded new revision