Special-Use Domain Names Problem Statement
draft-ietf-dnsop-sutld-ps-08

[Ballot comment]
Thanks for writing this document - I believe that having such a document makes future discussions much easier, that said I am not a fan of publishing problem statements in the RFC series. Given the document already lays out a level of dissent in so far as some people don't see all these listed "problems" as problems, (and I agree with them!) - they could however be universally described as "issues", where any particular concern or issue doesn't necessarily need to a response (irrespective of which forum or SDO holds the baton for that discussion piece). My suggestion would be to reword language portions to describe the information contained in this draft as "issues and concerns" and further because the text provided covers more than just the enumerated set of "issues" (was problems), may I also suggest a title change to something like "Issues, Concerns, and information related to Special-Use Domain Names".

[Ballot comment]
I have loads of editorial comments, but I'm a Yes, thank you folks for writing this, and Just Do The Right Thing ...

This text

        5.  If there is an IETF process through which a TLD can be
            assigned at zero cost other than time, this process will be
            used as an alternative to the more costly process of getting
            the name registered through ICANN.

seems extremely certain ("will be used"). Is that what you meant to say?

I'm assuming that the intended audience for this document is "people who know less than the authors about the lurid history of DNS". If so, in this text,

  11.  In some cases where the IETF has made assignments through the
        RFC 6761 process, technical mistakes have been made due to
        misunderstandings as to the actual process that RFC 6761
        specifies (e.g., treating the list of suggested considerations
        for assigning a name as a set of requirements all of which must
        be met).  In other cases, the IETF has made de facto assignments
        of Special-Use Domain Names without following the RFC 6761
        process.

citations of at least one de facto assignment would likely be helpful.

Again, I'm assuming your intention is to give people something to think about. Given that, I wonder how badly you need the last sentence in

4.1.  Primary Special-Use Domain Name Documents

  The primary documents are considered primary because they directly
  address the IETF's past thoughts on this topic in a general way, and
  also because they describe what the IETF does in practice.  Only one
  of these documents is an IETF consensus document.

You're pretty careful about pointing out whether each of the RFCs are consensus documents in the following subsections, and you provide enough explanation for the reader to know why the reader cares about each document. With the last sentence of 4.1 as lead-in, and no background because that comes later, document by document, I wouldn't take that section seriously.

I know that text is in Section 4.1, but "these documents" invited me to assume the same thing about the documents in Section 4.2 as well. If you need to keep the last sentence, you might consider

  Only one
  of the documents described in Section 4.1 is an IETF consensus document.

I know we publish a lot of passive voice text around here, but in

4.1.4.  Liaison Statement on Technical Use of Domain Names

  As a result of processing requests to add names to the Special-Use
  Domain Name registry, as documented in
  [I-D.chapin-additional-reserved-tlds] and
  [I-D.grothoff-iesg-special-use-p2p-names], a review was chartered of
  the process defined in RFC 6761 for adding names to the registry (as
  explained earlier).  The Liaison Statement [SDO-IAB-ICANN-LS]
  notified ICANN of the review, affirmed that the discussion would be
  "open and transparent to participation by interested parties" and
  explicitly invited members of the ICANN community to participate.

I am guessing who is requesting what, and who is performing the review, and who sent the liaison statement. Is this saying

  When the IETF received processing requests to add names to the Special-Use
  Domain Name registry, as documented in
  [I-D.chapin-additional-reserved-tlds] and
  [I-D.grothoff-iesg-special-use-p2p-names], the IETF chartered a review of
  the process defined in RFC 6761 for adding names to the registry (as
  explained earlier).  The IETF sent a Liaison Statement [SDO-IAB-ICANN-LS]
  to ICANN to notify ICANN of the review, affirm that the discussion would be
  "open and transparent to participation by interested parties" and
  explicitly invite members of the ICANN community to participate.

? But, as I said, I'm guessing. I'm also not sure whether you want the reader to know the IETF sent a liaison to ICANN, and why, or whether you want the reader to look at the liaison statement text itself. If you want readers to look at the text, you might say what you hope readers find when they look.

I'm wondering how .onion was "affected" in this text,

      Second, for some time, the CA/Browser Forum [SDO-CABF] had been
      issuing certificates for what they referred to as "internal
      names."  Internal names are names allocated unilaterally for use
      in site-specific contexts.  Issuing certificates for such names
      came to be considered problematic, since no formal process for
      testing the validity of such names existed.  Consequently, CA/
      Browser Forum decided to phase out the use of such names in
      certificates [SDO-CABF-INT], and set a deadline after which no new
      certificates for such names would be issued [SDO-CABF-DEADLINE].
      Because the .onion name had been allocated unilaterally, it was
      affected by this policy.

Is this saying that existing certificates for .onion could not be renewed? Or that the nice .onion people planned to get certificates, and now they couldn't? Or something else? I'm guessing

      The IETF's designation of .onion as a Special-Use Top-Level Domain
      Name was needed to facilitate the development of a certificate
      issuance process specific to .onion domain names
      [SDO-CABF-BALLOT144].

is describing how .onion was affected, but I don't know if that's what was meant by "was affected", or something else.

This text

  Newcomers to the problem of resolving Domain Names may be under the
  mistaken impression that the DNS sprang, as in the Greek legend of
  Athena, directly from Paul Mockapetris' forehead.

is the best thing I've seen reviewing documents since IETF 98. Thank you for that moment.

If I'm tracking what I'm reading,

  The Sun Microsystems model of having private domains within a
  corporate site, while supporting the global Domain Name system for
  off-site, persisted even after the NIS protocol fell into disuse.
  Microsoft used to recommend that site administrators use a "private"
  TLD for internal use, and this practice was very much a part of the
  zeitgeist at the time (see section 5.1 of [SDO-ICANN-COLL] and
  Appendix G of [RFC6762]).  This attitude is at the root of the
  widespread practice of simply picking an unused TLD and using it for
  experimental purposes, which persists even at the time of writing of
  this memo.

it might be more accurate to say "simply picking an apparently-unused TLD".

How often has

  Ralph started out as an innocent bystander, but

been an accurate qualifier? :D

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Intended status is Informational, as this document is a commentary on at least one standards track document (RFC 6761) and may inform future updates to standards but is itself only a problem statement, not a protocol or registry administration document.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The Special-Use Domain Names IANA registry policy defined in RFC 6761
  has been shown through experience to present unanticipated
  challenges.  This memo presents a list, intended to be comprehensive,
  of the problems that have been identified.  In addition it reviews
  the history of Domain Names and summarizes current IETF publications
  and some publications from other organizations relating to Special-
  Use Domain Names.

Working Group Summary

  This document was the result of a decision in DNSOP to attempt to characterize the problems we actually face with special use names before attempting to analyze any of several proposals and contending beliefs about how to resolve them. The document has been a considerable time in the making but has WG consensus as a list of the relevant issues and challenges. As such, it can reasonably be the basis for future work in this area, whether it's within scope/charter for DNSOP or not.

Document Quality

  The document summarizes many discussions and documents across DNSOP, the wider IETF, and other concerned communities to date.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Shepherd: Suzanne Woolf
Area Director: Benoit Claise (the OPS AD for DNSOP, Warren Kumari, is a co-author on this document)

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The shepherd has reviewed multiple versions of this document throughout its history in the WG, and a competing document also put forward as a problem statement in the same space. This document seems like a reasonable introduction to the topic and the best we're likely to do for consensus. As such, it should go to the IESG and the IETF for approval and publication.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

The topic of special use names has been in the WG for several years and some participants are weary of it. But this document received multiple careful reviews, before and during WGLC, and was discussed in a dedicated WG virtual interim meeting during the WGLC. So, no.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

The document was extensively reviewed within DNSOP and by several I* participants with relevant expertise. It would probably benefit from wider review, even beyond the IETF, but there was no easy way to do that within WG process; we're looking for ways to do it in IETF LC.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

This document was written and reviewed within the DNSOP WG, but both the interested WG participants and the wider IESG/IAB are well aware that the topic of special use names goes well beyond DNS as its scope, because it doesn't just encompass the use of domain names in the DNS protocol, and possible solutions will also have to be reviewed and discussed well beyond DNSOP.  We'd like for this document to inform future work regardless of where in the IETF it occurs, however.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

No such concerns known to any of the authors, or the WG chairs.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Not all of the WG has been active on the topic, and of those who have, there's no consensus on what solutions to the identified problems might look like. But it has consensus as an initial description of the issues.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

The entire topic throughout its history in the WG has been fraught with discontent. But there has been no discussion of formal action, or of opposition specifically to this document, that has reached the chairs.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The "Nits" check on the draft page shows missing RFC 2119 boilerplate and some references nits (2 to obsolete RFCs). They all appear to be contained in quotes, or in the document discussion of history, so should probably be left alone.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

None required.


(13) Have all references within this document been identified as
either normative or informative?

There are no normative references in this document.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

N/A


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

N/A


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

N/A


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).


N/A

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A

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

The IANA Services Operator has reviewed draft-ietf-dnsop-sutld-ps-05.txt, 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
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: draft-ietf-dnsop-sutld-ps@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, suzworldwide@gmail.com, Suzanne Woolf , bclaise@cisco.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Special-Use Domain Names Problem Statement) to Informational RFC


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Special-Use Domain Names
Problem Statement'
  as Informational RFC

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 2017-06-20. 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 Special-Use Domain Names IANA registry policy defined in RFC 6761
  has been shown through experience to present unanticipated
  challenges.  This memo presents a list, intended to be comprehensive,
  of the problems that have been identified.  In addition it reviews
  the history of Domain Names and summarizes current IETF publications
  and some publications from other organizations relating to Special-
  Use Domain Names.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ballot/


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

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Intended status is Informational, as this document is a commentary on at least one standards track document (RFC 6761) and may inform future updates to standards but is itself only a problem statement, not a protocol or registry administration document.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The Special-Use Domain Names IANA registry policy defined in RFC 6761
  has been shown through experience to present unanticipated
  challenges.  This memo presents a list, intended to be comprehensive,
  of the problems that have been identified.  In addition it reviews
  the history of Domain Names and summarizes current IETF publications
  and some publications from other organizations relating to Special-
  Use Domain Names.

Working Group Summary

  This document was the result of a decision in DNSOP to attempt to characterize the problems we actually face with special use names before attempting to analyze any of several proposals and contending beliefs about how to resolve them. The document has been a considerable time in the making but has WG consensus as a list of the relevant issues and challenges. As such, it can reasonably be the basis for future work in this area, whether it's within scope/charter for DNSOP or not.

Document Quality

  The document summarizes many discussions and documents across DNSOP, the wider IETF, and other concerned communities to date.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Shepherd: Suzanne Woolf
Area Director: TBD (the OPS AD for DNSOP, Warren Kumari, is a co-author on this document, so is seeking another shepherd)

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The shepherd has reviewed multiple versions of this document throughout its history in the WG, and a competing document also put forward as a problem statement in the same space. This document seems like a reasonable introduction to the topic and the best we're likely to do for consensus. As such, it should go to the IESG and the IETF for approval and publication.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

The topic of special use names has been in the WG for several years and some participants are weary of it. But this document received multiple careful reviews, before and during WGLC, and was discussed in a dedicated WG virtual interim meeting during the WGLC. So, no.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

The document was extensively reviewed within DNSOP and by several I* participants with relevant expertise. It would probably benefit from wider review, even beyond the IETF, but there was no easy way to do that within WG process; we're looking for ways to do it in IETF LC.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

This document was written and reviewed within the DNSOP WG, but both the interested WG participants and the wider IESG/IAB are well aware that the topic of special use names goes well beyond DNS as its scope, because it doesn't just encompass the use of domain names in the DNS protocol, and possible solutions will also have to be reviewed and discussed well beyond DNSOP.  We'd like for this document to inform future work regardless of where in the IETF it occurs, however.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

No such concerns known to any of the authors, or the WG chairs.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Not all of the WG has been active on the topic, and of those who have, there's no consensus on what solutions to the identified problems might look like. But it has consensus as an initial description of the issues.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

The entire topic throughout its history in the WG has been fraught with discontent. But there has been no discussion of formal action, or of opposition specifically to this document, that has reached the chairs.


(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The "Nits" check on the draft page shows missing RFC 2119 boilerplate and some references nits (2 to obsolete RFCs). They all appear to be contained in quotes, or in the document discussion of history, so should probably be left alone.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

None required.


(13) Have all references within this document been identified as
either normative or informative?

There are no normative references in this document.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

N/A


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

N/A


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

N/A


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).


N/A

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

N/A