From: Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <7E4C1956-8477-4F07-BC29-3D163B7160AA@mnot.net>
Date: Thu, 26 Nov 2015 17:38:31 +1100
To: dnsop@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/zqatO-F-vtjfGDx-yp_c8zfKz58>
Subject: [DNSOP] Some thoughts on special-use names,
 from an application standpoint
Precedence: list

RFC7230 Section 2.7.1 says this about hostnames in HTTP URLs:

"""
If host is a registered name, the registered name is an indirect =
identifier for use with a name resolution service, such as DNS, to find =
an address for that origin server.=20
"""

... which builds on how RFC3986 Section 3.2.2 talks about hostnames in =
URLs and URIs:

"""
The presence of a host subcomponent within a URI does not imply that the =
scheme requires access to the given host on the Internet.  In many =
cases, the host syntax is used only for the sake of reusing the existing =
registration process created and deployed for DNS, thus obtaining a =
globally unique name without the cost of deploying another registry.  =
However, such use comes with its own costs: domain name ownership may =
change over time for reasons not anticipated by the URI producer.  In =
other cases, the data within the host component identifies a registered =
name that has nothing to do with an Internet host.  We use the name =
"host" for the ABNF rule because that is its most common purpose, not =
its only purpose.
"""

So, the Web architecture already has baked in a notion of multiple =
mechanisms for location within a single name space. Indeed, the =
flexibility of multiple location mechanisms might be required to address =
issues like domain name ownership changes.

Given this context, I was disturbed to hear the design team presentation =
in Yokohama suggest that we "remove the value of a top-level domain" as =
a potential solution (around 49:30 in the meetecho recording).

To me, this fundamentally misses the point; the value of a single naming =
root with flexible location is a community good, and cannot be removed =
just to make life easier for DNSOPS. The impact goes far beyond DNS.

In the ensuing discussion, Andrew Sullivan's comments (at around 58:00) =
made the most sense to me. The problems that =
draft-adpkja-dnsop-special-names identifies (e.g., "what technical =
criteria should the evaluation body use to examine the merit of an =
application for such a reserved name/protocol switch", "With regard to =
the actual choice of name, [RFC6761] is silent") are already handled by =
our normal processes, where we invest technical authority to judge in =
bodies like the IESG, and document an appeals process. It's also far =
from clear that we *need* to have only one path to a new special-use =
name (as section 6.2.1 seems to desire).

While I appreciate that the .onion discussion was a prolonged headache =
for DNSOP, and that perhaps in the future other venues should be used, =
deciding how to handle the general issue of naming based upon its impact =
on *one* location protocol community doesn't seem appropriate. If this =
effort is to do more than make modest clarifications to RFC6761, I'd =
suggest that we consider moving it elsewhere.

Kind regards,


P.S. The draft begins:

"""
In recent years, using the last label of a domain name (aka TLD) as =
switch to indicate how to treat name resolution has been experimented =
using the framework of [RFC6761].
"""

This framing is incorrect. RFC6761 is a Proposed Standard, not =
Experimental.=20


--
Mark Nottingham   https://www.mnot.net/