Special-Use Domain Names Problem Statement

Note: This ballot was opened for revision 06 and is now closed.

(Ben Campbell) Yes

Comment (2017-07-03 for -07)
No email
send info
Is there something to be gained by going out on the "believed to be complete" limb?

(Benoît Claise) Yes

(Alissa Cooper) Yes

Comment (2017-07-05 for -07)
No email
send info
In Section 4, "the IAB technical document" could use a reference.

(Spencer Dawkins) Yes

Comment (2017-07-04 for -07)
No email
send info
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

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

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

(Alexey Melnikov) (was No Objection) Yes

Comment (2017-07-03 for -07)
No email
send info
Thank you for the informative summary of all issues around Special Use TLDs.

(Kathleen Moriarty) Yes

(Alia Atlas) No Objection

(Deborah Brungard) No Objection

(Suresh Krishnan) No Objection

(Mirja Kühlewind) No Objection

Comment (2017-07-06 for -07)
No email
send info
I guess SUDN (registry) and MoU could be added to the terminology section.

Thanks for writting this document!

(Terry Manderson) No Objection

Comment (2017-07-05 for -07)
No email
send info
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".

Alvaro Retana No Objection

Warren Kumari Recuse

Comment (2017-07-05 for -07)
No email
send info
I am an author on this document, and so recusing myself from balloting.