[DNSOP] Ed's comment s on Re: WGLC for draft-ietf-dnsop-sutld-ps

Edward Lewis <edward.lewis@icann.org> Thu, 16 February 2017 16:18 UTC

Return-Path: <edward.lewis@icann.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A37129D9F for <dnsop@ietfa.amsl.com>; Thu, 16 Feb 2017 08:18:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBiOo9vBFE3F for <dnsop@ietfa.amsl.com>; Thu, 16 Feb 2017 08:18:50 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24F37129D9C for <dnsop@ietf.org>; Thu, 16 Feb 2017 08:18:50 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 16 Feb 2017 08:18:47 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Thu, 16 Feb 2017 08:18:47 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: dnsop <dnsop@ietf.org>
Thread-Topic: Ed's comment s on Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps
Thread-Index: AQHSiHBZOUYkQk4EIUKztTlqk8NFCg==
Date: Thu, 16 Feb 2017 16:18:47 +0000
Message-ID: <F56640AF-27DF-425F-B844-8453DE02987E@icann.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.1e.0.170107
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.47.234]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3570088726_1417514986"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GGI9-LXLnBIJFS6EYS7RbWYm0Gs>
Subject: [DNSOP] Ed's comment s on Re: WGLC for draft-ietf-dnsop-sutld-ps
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Feb 2017 16:18:53 -0000

Lines beginning with "#" are from the document. "# ..." means I removed the section as I had no comment on it.

# Network Working Group                                           T. Lemon
# Internet-Draft                                             Nominum, Inc.
# Intended status: Informational                                  R. Droms
# Expires: August 3, 2017
#                                                                W. Kumari
#                                                                   Google
#                                                         January 30, 2017
# 
# 
#                   Special-Use Names Problem Statement
#                       draft-ietf-dnsop-sutld-ps-02
# 
# 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 standards organizations relating to
#    special-use Domain Names.
# 
# 1.  Introduction
# 
#    One of the key services required to use the Internet is name
#    resolution.  Name resolution is the process of translating a symbolic
#    name into some object or set of objects to which the name refers,
#    most typically one or more IP addresses.  These names are often
#    referred to as Domain Names.  When reading this document, care must
#    be taken to not assume that the term Domain Name implies the
#    particular protocol for resolving these names, the Domain Name System
#    [RFC1034].  An excellent presentation on this topic can be found in
#    Domain Names [I-D.lewis-domain-names].
# 
#    Special-Use Domain Names [RFC6761] created an IANA registry for
#    special-use Domain Names [SDO-IANA-SUDR], defined policies for adding
#    to the registry, and made some suggestions about how that policy
#    might be implemented.  Since the publication of RFC 6761, the IETF
#    has been asked to designate several new special-use Domain Names in
#    this registry.  During the evaluation process for these special-use

It would be good to provide a list of requests for new special use names.
Especially for a problem statement, this provides a way to estimate the 
"size and shape" of the problem and the urgency.

#    Domain Names, the IETF encountered several different sorts of issues.
#    Because of this, the IETF has decided to investigate the problem and
#    decide if and how the RFC 6761 process can be improved, or whether it
#    should be deprecated.
# 
#    This document presents a list, believed to be complete, of the
#    problems associated with the assignment of special-use names.  In
#    support of the particular set of problems described here, the
#    document also includes documentation of existing practice as it
#    relates to the use of Domain Names, as well as a brief history of
#    Domain Names, and finally to describe the set of problems that exist
#    as reported by various IETF participants with experience in the
#    various aspects of the problem.
# 
# 2.  Terminology
# 
#    For the sake of brevity this document uses a number of abbreviations.
#    These are expanded here:
# 
#    Domain Name  A name which serves as input to a name resolution
#       process, for example 'EXAMPLE.ORG'.
# 
#    Domain Namespace  The set of all possible Domain Names.
# 
#    SUDN  Special Use Domain Name
# 
#    SUTLDN  Special-Use Top-Level Domain Name
# 
#    IANA  Internet Assigned Numbers Authority
# 
#    ICANN  Internet Corporation for Assigned Names and Numbers
# 
# 3.  Problems associated with Special-Use Domain Names
# 
#    This section presents a list of problems that have been identified
#    with respect to the assignment of special-use names.  Solutions to
#    these problems are out of scope for this document.  Because of that,
#    problems with solutions to these problems are also out of scope for
#    this document, and will be covered in a separate document.
# 
#    No assertion is made that any of these problems is more or less
#    important than any other.  The point of this is simply to enumerate
#    and briefly describe the problems that have been raised during
#    discussions of the special-use name problem.  The degree of detail is
#    intended to be sufficient that that participants in the discussion
#    can agree that the problems they've raised have been adequately
#    described, and no more.  These problems should not appear to every
#    reader to all be problems: we intend to cover any problem that any
#    participant considers a problem, not just those problems that
#    everyone agrees are problems.
# 
#    In addition, no assertion is made that all of these problems must be
#    addressed, or that, if we think they should be addressed, the IETF is
#    the organization with competence to address them.  While each problem
#    has one or more solutions, the solutions may in some cases be
#    mutually contradictory, or may come with costs that do not justify
#    the benefit that would be obtained from solving them.
# 
#    This is the list of problems:

On my second pass, the list is more a list of "complaints heard" rather than
any analysis to synthesize a solvable set of "problems."  Members of this list are repetitive to some extent and seem to reflect unhappiness with the set up rather than a quantification of the issues (as would a list of pending name requests mentioned earlier).

#    o  There are several different types of names in the root of the
#       Domain Namespace:
# 
#       *  Reserved by the IETF for technical purposes
# 
#       *  Assigned by ICANN to the public DNS root
# 
#       *  ICANN Reserved Names; names that may not be applied for as a
#          TLD (see [SDO-ICANN-DAG]Section 2.2.1.2.1, Reserved Names )
# 
#       *  Commandeered for use by other organizations
# 
#       *  Not a member of any other category

I think the same verb should be used in the first two bullets.  By using
different terms, one could read an imbalance between the two processes for
designating domain name states.

The third bullet is redundant with the first two.

Commandeered is a subjective term, implying intent to take over something.  I
would suggest "In use via other means."

This bullet also addresses "the root", but the Special Use Domain Name registry is not exclusively filled by top-level domain names.  One of the over-hanging issues is how to resolve designations of arbitrary domain names with the special treatment in the root zone, further, to understand what that root zone is.

#    o  Both ICANN and the IETF have the authority and formal processes to
#       assign names from the pool of unused names, but no formal
#       coordination process exists.  The lack of coordination complicates
#       the management of the root of the Domain Namespace and may lead to
#       conflicts in name assignments [SDO-ICANN-SAC090].

I'm not sure that I agree with this as a problem.  It's potentially a problem.

I mean, ICANN could potentially create a process that could lead to collision
with an IETF process but currently there is no such process.  (Note: ICANN
applicaitons for gTLDs are restricted to windows of time that are an outcome
of an extensive policy process.  The last window existed in 2012, there are
no concrete future windows in a calendar, saying this in light that it is
always possible.)

#    o  The term "technical use" in RFC 2860 [RFC2860] is considered by
#       some to be too inclusive.

I'd call it "ill defined".  The phrase is begging for testable attributes.
 
#    o  The IETF and ICANN each have administrative authority over the
#       Domain Namespace.  Not all developers of protocols on the internet
#       agree that this authority should reside with the IETF and ICANN.

If one creates a virtual space, how can they not have administrative authority?

If not, the virtual space has no value to anyone.
 
#    o  Although IETF and ICANN nominally have authority over this
#       namespace, neither organization can enforce that authority over
#       any third party who wants to just start using a subset of the
#       namespace.

I don't think that's a properly stated problem, but it does point to something.

The problem is that the name space nominally defined and created between IETF
and ICANN is susceptible to interference.  If another entity decides to use
identifiers that are confusingly similar to the Domain Namespace, the existing system is not prepared to "heal itself."

#    o  Organizations do in fact sometimes commandeer subsets of the
#       namespace.  Reasons a third party might do this include:
# 
#       *  Unaware that a process exists for assigning such names
# 
#       *  Intended use is covered by gTLD process, but no gTLD process is
#          ongoing
# 
#       *  Intended use is covered by gTLD process, don't want to pay fee
# 
#       *  Intended use is covered by some IETF process, but don't want to
#          follow process
# 
#       *  Intended use is covered by ICANN or IETF process, but expected
#          outcome is refusal or non-action

Bullet #2 is impossible...if there is no process ongoing then their is no
process "covering".

I would combine the first and last bullets - no process is known or the process discourages applicants.  I know we are staying away from solutions, but the solution to the two is basically - education/designing an easy process.  (Same situation DNS once faced with allocation of Resource Record type codes.)

If I buy a relational database from a vendor, am I required to have the same
data schemas as everyone else?  In parallel to following the DNS documents to
implement and run a DNS server, do I need to have the same names in it as
the global public Internet?  I think not - but the point is that we need to
place the discussion appropriately.  The Special Use Domain Name registry is
not something that alters the DNS protocol, it does have an impact on how 
the global public Internet operates the shared DNS system.

#    o  There is demand for more than one name resolution protocol for
#       Domain Names, but Domain Names contain no metadata to indicate
#       which protocol to use to resolve them.

This isn't a problem with special use domain names.  It's part of a larger,
architectural problem with Domain Names.

#    o  When a special-use Domain Name is added to the special-use Domain
#       Names registry, not all software that processes such names will
#       understand the special use of that name.  In many cases, name
#       resolution software will use the Domain Name System for resolution
#       of names not known to have a special use.  Consequently, any such
#       use will result in queries for special-use names being sent to
#       Domain Name System authoritative servers.  These queries may
#       constitute an operational problem for operators of root zone
#       authoritative name servers.

"Leaking" isn't a problem for the special use domain name registry, it's a
problem for applications that think a special reservation is the solution
to that.

#    o  The RFC6761 process is sufficiently uncertain that some protocol
#       developers have assumed they could not get a name assigned; the
#       process of assigning the first new name ('.local') using the RFC
#       6761 process took more than ten years from beginning to end:
#       longer by a factor of ten than any other part of the protocol
#       development process.  Other uses of the process have proceeded
#       more smoothly, but there is a reasonably justified perception that
#       using this process is likely to be slow and difficult, with an
#       uncertain outcome.

That paragraph is unclear.  The protocol development process is often cited as being slow to come to conclusion (e.g., look at the publication of DNSSEC and adoption curves, look at EDNS0).  As far as other names reservations, past gTLD "rounds" have taken many years to complete.  (See https://www.nanog.org/sites/default/files/nanog63-dnstrack-lewis-newgtlds.pdf, specifically slide 5.)

#    o  There is strong resistance within the IETF to assigning Domain
#       Names to resolution systems outside of the DNS, for a variety of
#       reasons:
# 
#       *  Requires a mechanism for identifying which of a set of
#          resolution processes is required in order to resolve a
#          particular name.
# 
#       *  Assertion of authority: there is a sense that the Domain
#          Namespace is "owned" by the IETF or by ICANN, and so, if a name
#          is claimed outside of that process, the person or entity that
#          claimed that name should suffer some consequence that would,
#          presumably, deter future circumvention of the official process.

We need to clean up the notion of a concept for a name space under Domain Names and the notion that there is an operational Domain Name space.  For the latter, under which the Special Use Domain Name registry operates, there is some authority, originally resting with whomever instantiated it.

(To make this a bit more concrete, the DNS protocol allows for software to be
written that would serve a TLD called "*".  I've done this, it works, for some value of works.  But, this wouldn't work on the global public Internet version of the Domain Name namespace, if because the value of "works" is different.)

# 
#       *  More than one name resolution protocol is bad, in the sense
#          that a single protocol is less complicated to implement and
#          deploy.

This speaks against "permission-less innovation."

If by listing this, it is meant that some have perceived this as a problem, it would be helpful to provide references.  (A general statement for all of
these.)

#       *  The semantics of alternative resolution protocols may differ
#          from the DNS protocol; DNS has the concept of RRtypes; other
#          protocols may not support RRtypes, or may support some entirely
#          different data structuring mechanism.

If this is seen as a problem, please provide references.

#       *  If there is an IETF process through which a name can be
#          assigned at zero cost other than time, this process will be
#          used as an alternative to purchasing the name through ICANN.

I think it is divisive and distracting to refer to "purchasing" or paying
a fee as an important hurdle to reserving a name via ICANN.  In the spirit
of building a cooperative environment, the issue is that there are two (plus)
potential sources of processes for reserving names and it would be wise to
avoid allowing them to compete.

#       *  A name might be assigned for a particular purpose when a more
#          general use of the name would be more beneficial.

This is an understatement - besides "more general" there are many other
considerations when a resource is used for one particular case out of many.

#       *  If the IETF assigns a name that some third party or parties
#          believes belongs to them in some way, the IETF could become
#          embroiled in an expensive dispute with those parties.

It's best if we stick to technical issues than try to wade into other fields
outside the expertise of the group, for the sake of consensus.  E.g., 
expensive dispute" to me implies legal actions - which sometimes are worth
the cost.
 
#    o  If there were no process for assigning names for technical use
#       through the IETF, there is a concern that protocols that require
#       such names would not be able to get them.

Conflicting with the notion that others are using them outside the process.

#    o  In cases where the IETF has made assignments through the RFC 6761
#       process, technical mistakes have been made due either 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), or to a
#       failure to follow the process that was defined in RFC 6761.

An example of this would be appreciated.  In the sense that I don't follow.

#    o  In principle, the RFC 6761 process could be used to document the
#       existence of Domain Names that are not safe to assign, and provide
#       information on how those names are used in practice.  However,
#       attempts to use RFC6761 to accomplish this
#       [I-D.chapin-additional-reserved-tlds] have not been successful.
#       One side effect of this is that any mitigation effect on the root
#       name servers has been missed.

It is not that the process failed, the reasons why it failed are the problems. (I.e., the process fail is a symptom of underlying unresolved issues.)
 
#    o  There are several Domain Name TLDs that have been commandeered
#       without due process for a variety of purposes [SDO-ICANN-COLL].
#       The status of these names need to be clarified and recorded to
#       avoid future disputes about their use. [ Ed note: We note that
#       DNSOP has previously discussed some of these in draft-chapin-
#       additional-reserved-tlds-02, and decided not to adopt the draft -
#       https://www.ietf.org/mail-archive/web/dnsop/current/msg14887.html
#       .  The authors are not recommending that DNSOP revisit this,
#       rather that is needs to be addressed in some venue. ]

One issue is establishing what is "due process" in the face of "permission-less innovation."

#    o  No mechanism exists for adding a name to the registry without
#       claiming that the IETF is responsible for that name, nor is it
#       possible to state a precedence for the name, e.g. "if ICANN
#       delegates this name, ICANN's delegation takes precedence."

Would it be desirable to have rankings?  A quote from George Orwell's "Animal
Farm" (https://en.wikipedia.org/wiki/Animal_Farm) comes to mind: "All animals
are equal but some animals are more equal than others."

Apologies - couldn't resist.

#    o  No process exists for checking documents to make sure they don't
#       accidentally assign names (e.g.  RFC 7788).

Now - this is good, citing a reference to the use case behind the statement.
Please more of this.

#    o  Use of the registry is inconsistent--some SUTLDN RFCs specify
#       registry entries, some don't; some specify delegation, some don't.
# 
#    o  There exists no safe, non-process-violating mechanism for ad-hoc
#       assignment of special-use names.
# 
#    o  It is generally assumed that protocols that need a special-use
#       name need a human-readable special-use name.  This assumption may
#       not be warranted in all cases.
# 
#    o  RFC 6761 uses the term "Domain Name" to describe the thing for
#       which special uses are registered.  This creates a great deal of
#       confusion because some readers take "Domain Name" to imply the use
#       of the DNS protocol.
# 
#    The problems we have stated here represent the current understanding
#    of the authors of the document as to the complete set of problems
#    that have been identified during discussion by the working group on
#    this topic.  The remainder of this document provides additional
#    context that will be needed for reasoning about these problems.
# 
# 4.  Existing Practice Regarding SUDNs
# ...
# 4.1.  Primary SUDN Documents
# ...
# 4.1.1.  IAB Technical Comment on the Unique DNS Root
# ... 
# 4.1.2.  Special-Use Domain Names
# ...
# 4.1.3.  MoU Concerning the Technical Work of the IANA
# 
#    There exists a Memorandum of Understanding[RFC2860] between the IETF
#    and ICANN (Internet Corporation for Assigned Names and Numbers) which
#    discusses how names and numbers will be managed through the IANA
#    (Internet Assigned Numbers Authority).  This document is important to
#    the discussion of SUDNs because, while it delegates authority for
#    managing the Domain Name System Namespace generally to ICANN, it
#    reserves to the IETF the authority that RFC 6761 formalizes:
# 
#       Note that (a) assignments of Domain Names for technical uses (such
#       as Domain Names for inverse DNS lookup), (b) assignments of
#       specialised address blocks (such as multicast or anycast blocks),
#       and (c) experimental assignments are not considered to be policy
#       issues, and shall remain subject to the provisions of this
#       Section 4.
# 
#    The above text is an addendum to the following:
# 
#       Two particular assigned spaces present policy issues in addition
#       to the technical considerations specified by the IETF: the
#       assignment of Domain Names, and the assignment of IP address
#       blocks.  These policy issues are outside the scope of this MOU.
# 
#    In general, then, the assignment of names in the DNS root zone, and
#    the management of the DNS namespace, is a function that is performed
#    by ICANN.  However, the MoU specifically exempts domain names
#    assigned for technical use, and uses the example of domains used for
#    inverse DNS lookup.  Both 'IN-ADDR.ARPA' and 'IP6.ARPA' are in the
#    special-use Domain Names registry.
# 
#    The point here is not to say what the implications of this statement
#    in the MoU are, but rather to call the reader's attention to the
#    existence of this statement.

This last paragraph seems to contradict the section.  If the point is not
to interpret the MoU, then citing it is sufficient.  Providing an
interpretation (as in the preceding paragraph) is a statement on the
implications.

# 4.2.  Secondary documents relating to the SUTLDN question
# ...
# 4.2.1.  Multicast DNS
# 
#    Multicast DNS [RFC6762] defines the Multicast DNS protocol, which
#    uses the '.LOCAL' SUTLDN.  Section 3 describes the semantics of
#    "multicast DNS names."  It is of considerable historical importance
#    to note that the -00 version of this document, an individual
#    submission, was published in July of 2001.  This version contains

I don't understand the "considerable historical importance."

My personal memory was that the WG wasn't all that excited about this work.
When the IESG returned the document to the WG, it took a large effort by the
chairs to fix it in face of general apathy (again, my recollection).

#    substantially the same text in section 3, and was discussed in the
#    DNSEXT working group at IETF 51 in August of 2001[IETF-PRO-51].  The
#    first version of this document designated '.LOCAL.ARPA' as the

What I recall of that session was the debate over the A6 record.  Just to
say I don't get the comment above about "considerable historical importance"
and to suggest that the authors/editors elaborate more.

I'm not saying that there is no importance, I'm saying that whatever it is,
it begs more explaining.

#    special-use name.  This idea was strongly opposed by DNSEXT working
#    group participants, and as a result the author eventually switched to
#    using '.LOCAL'.
# 
#    The history of RFC 6762 is documented in substantial detail in
#    Appendix H; some notable milestones include the initial proposal to
#    replace Appletalk's NBP in July 1997, the chartering of the Zeroconf
#    working group in September 1999, assignment of a multicast address
#    for link-local name discovery in April of 2000.  A companion
#    requirements document, eventually published as [RFC6760] was first
#    published in September of 2001.
# 
#    The point of mentioning these dates is so that discussions involving
#    the time when the '.LOCAL' domain was first deployed, and the context
#    in which it was deployed, may be properly informed.

Four years seems like a blink of an eye in IETF terms.  Not to discount that,
but again, there seems to be a need to explain why this is mentioned.

# 4.2.2.  The .onion Special-Use TLD
# 
#    The .onion Special Use TLD [RFC7686] is important because it is the
#    most recent IETF action on the topic of SUTLDNs; although it does not
#    set new policy, the mere fact of its publication is worth thinking
#    about.
# 
#    Two important points to consider about this document are that:
# 
#    o  The IETF gained consensus to publish it
# 
#    o  The situation was somewhat forced, both by the fact of its
#       unilateral use by the TOR project without following the RFC 6761
#       process, and because a deadline had been set by the CA/Browser
#       Forum [SDO-CABF-INT] after which all .onion PKI certificates would
#       expire and no new certificates would be issued, unless the .onion
#       SUTLDN were to be recognized by the IETF.

This sounds like consensus was more of a "shotgun wedding."
(https://en.wikipedia.org/wiki/Shotgun_wedding)

Speaking as someone who never understood "the consensus" but is willing to
live with it.  (I certainly asked questions that went unanswered.)  This
is what spurred me to write the Domain Names draft (note: draft), even
digging through documents for that found it hard to find a documented
background on the Tor project in sufficient detail to answer my questions
on how the DNS was impacted.

# 4.2.3.  Locally Served DNS Zones
# ...
# 4.2.4.  Name Collision in the DNS
# ... 
# 4.2.5.  SSAC Advisory on the Stability of the Domain Namespace
# 
#    This document reports on some issues surrounding the conflicting
#    uses, interested parties and processes related to the Domain
#    Namespace.  The document recommends the development of collaborative
#    processes among the various interested parties to coordinate their
#    activities related to the Domain Namespace.

A reference to the document would be good.

# 4.2.6.  Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis
# 
#    Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis
#    [RFC7050] is an example of a document that successfully used the RFC
#    6761 process to designate '.ipv4only.arpa' as a special-use name; in
#    this case the process worked smoothly and without controversy.
# 
#    Unfortunately, while the IETF process worked smoothly, in the sense
#    that there was little controversy or delay in approving the new use,
#    it did not work correctly: the name 'ipv4only.arpa' was never added
#    to the special-use Domain Names registry.  This appears to have
#    happened because the IAB was able to simply add the name to the .ARPA
#    zone, which the IAB administers.  This is an illustration of one of
#    the problems that we have with the 6761 process: it is apparently
#    fairly easy to miss the step of adding the name to the registry.

s/the registry/the appropriate registry/

# 4.2.7.  Additional Reserved Top Level Domains
# 
#    Additional Reserved Top Level Domains
#    [I-D.chapin-additional-reserved-tlds] is an example of a document
#    that attempted to reserve several TLDs identified by ICANN as
#    particularly at risk for collision as special-use Domain Names with
#    no documented use.  This attempt failed.
# 
#    Although this document failed to gain consensus to publish, the need
#    it was intended to fill still exists.  Unfortunately, although a fair
#    amount is known about the use of these names, no document exists that
#    documents how they are used, and why it would be a problem to
#    delegate them.  Additionally, to the extent that the uses being made
#    of these names are valid, no document exists indicating when it might
#    make sense to use them, and when it would not make sense to use them.
# 
#    RFC 7788 [RFC7788] defines the Domain Name TLD ".home" for use as the
#    default name for name resolution relative to a home network context.
#    Although, as defined in RFC 7788, ".home" is a special-use Domain
#    Name, RFC 7788 did not follow the process in RFC 6761 and request the
#    addition of ".home" to the IANA Special-Use Domain Name registry.
#    Additionally, ".home" is an example of an attempt to reuse a Domain
#    Name that has already been commandeered for other purposes
#    [SDO-ICANN-COLL], which further complicates the situation.  At the
#    time this document was written, the IETF was developing a solution to
#    this problem.

That description doesn't mention the errata filed to remove .home from the
document.

<End of my comments, not the end of the draft>