Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Ralph Droms <[e-mail]>]

I'm responding here with none of my various hats on...

Here's the tl;dr version.  This document has some useful information and raises, directly and indirectly, some important questions that the IETF should consider.  Unfortunately, those useful bits are buried in a polemic that is directed toward a specific outcome.  If this document is accepted as a WG document, I strongly suggest that it be heavily edited to extract and emphasize the useful text and discard the rest.

If you're still reading...

Let me start with the fundamental difference I have with one of the key pre-conclusions of this document.  In my opinion, RFC 6761 and the Special-Use Domain Names registry meet the requirement of a complete and useful way to record and make available information about domain names designated to be special use.  Section 4 of RFC 6761 explicitly leaves the identification of special use names to "Standards Action" or "IESG Approval".  I've made several comments below in which I think the distinction is important for the accuracy and authority of draft-adpkja-dnsop-special-names-problem.

The document does identify some key questions the IETF should
consider:
* does the IETF want to formally sanction protocol switching based on
  the last label?
* should the IETF coordinate the designation of special-use domain
  names with other bodies such as ICANN; if so, how?
* does the IETF want to specify a more formal review process for the
  designation of special-use domain names?

I think this document would be greatly strengthened and far more helpful to the dnsop WG and the IETF if it included a clear identification of a list of specific problems that have been encountered with the review and publication of documents that define special use names in the past, and that might be encountered in the future.  Citations of mailing list discussions that lead to the identification of the specific problems would be a real plus.

Finally, I think the document would be strengthened by editing out text on solutions and editing down the text to state and motivate the problems directly and succinctly.

Specific comments, more or less in the order of appearance in draft-adpkja-dnsop-special-names-problem-02:

Abstract

   The dominant protocol for name resolution on the Internet is the
   Domain Name System (DNS).  However, other protocols exist that are
   fundamentally different from the DNS, and may or may not share the
   same namespace.

RD>> I think the problem is actually broader than just other
protocols.  We have a namespace that is primarily used for names
intended for resolution through DNS, but, as recorded in RFC 6761,
there are parts of the namespace that are handled in special ways.

   When an end-user triggers resolution of a name on a system which
   supports multiple, different protocols (or resolution mechanisms) for
   name resolution, it is desirable that the protocol used is
   unambiguous, and that requests intended for one protocol are not
   inadvertently answered using another.

RD>> editorial: too much detail for an abstract?

   RFC 6761 introduced a framework by which, under certain
   circumstances, a particular domain name could be acknowledged as
   being special.  This framework has been used twice to reserve top-
   level domains (.local and .onion) that should not be used within the
   DNS, to avoid the possibility of namespace collisions in parallel use
   of non-DNS name resolution protocols.

RD>> I disagree with this characterization of RFC 6761, which provides
an explicit registry for behaviors that are specified in other
documents for special handling.  My view of the process defined in RFC
6761 is that an RFC is published that describes the special use for
part of the domain namespace.  The decision about whether to
standardize that use is implicitly part of the RFC publication
process.  Once the decision is made to publish the RFC, the effects of
the standardized use of the subset of the namespace is recorded in the
RFC 6761 registry.

   Various challenges have become apparent with this application of the
   guidance provided in RFC 6761.  This document aims to document those
   challenges in the form of a problem statement, to facilitate further
   discussion of potential solutions.

RD>> I would phrase the problem as challenges in the process of
reviewing documents that would standardize special uses of names from
the domain name space.

RD>> Editorial nit: the Introduction is usually the first section of
the body of the document.

RD>> In 2. Introduction, and I'm sorry to be repeating myself, in my
opinion RFC 6761 records the special uses of some domain names, as
approved for publication as an Internet Standard.  I'll also repeat
myself that RFC 6761 describes other alternative special handling
aside from protocol switches.  That alternative special handling must
be considered carefully at the time of publication of the defining
RFC, regardless of the nature of the special use.

RD>> Also in the Introduction:

   The framework in [RFC6761] has recently been used to reserve the
   .onion label, allowing it to be used as a switch to the Tor
   resolution process, as described in [RFC7686].  Because the .onion
   label in the IANA "Special-Use Domain Names" registry
   [IANA-SPECIAL-USE], the Tor Project can be assured that there will
   not be a .onion TLD created in the IANA rooted DNS, and thus the
   possibility of collisions in the namespace will be avoided.

RD>> I think it's more correct to write that RFC 7686 defines ".onion"
as a Special-Use Domain Name, which takes it out of the Domain Name
space.  This designation is then recorded in the Special-Use Domain
Names registry, according to RFC 6761.

RD>> I disagree with the premise of the paragraph in section 3 that begins:

   The intent of those seven questions was originally to serve as the
   justifications for why a proposed special-use registration should be
   granted [...]

RD>> The intent from the beginning was to provide guidance as to what
should be written in the registry.  The justification is to be written
as a separate part of whatever RFC defines the registry entries.  The remainder of this paragraph really needs explicit support for the conclusions drawn about the special-use name designation process, or the conclusions should be clearly labeled as the opinions of the authors.

RD>> In 4. Architectural Considerations:

   At the time of writing, two top-level domain names reserved by
   inclusion in the Registry went through the [RFC6761] process [...]

For completeness, there are actually several names that have been
recorded in the Special-Use Domain Names registry as defined in RFC
6761.  Other top-level domain names in the registry include:

.example
.invalid
.localhost
.test

In addition, there are a couple of names designated for special use
that remove them from the available DNS Names space:

.example.com
.example.net
.example.org

Another name, ipv4only.arpa, has been designated a special-use name in
RFC 7050 (although it doesn't yet appear in the Special Use Names
registry).

Finally, draft-chapin-additional-reserved-tlds proposed the
designation of .home, .corp and .mail as special-use domain names.
The dnsop WG reviewed the draft and chose not to proceed with
publication of an RFC to so designate those names.

RD>> Also in section 4:

   In particular, DNS imposes constraints on name syntax.  An example of
   such constraints is the 63 octet limit per label.  Strings used in
   the .onion domain do not have that constraint.

This statement could use some explanation about the impact of the
observation; otherwise, I don't understand the relevance.

RD>> Similarly, why are .uucp and .bitnet "bad precedents"?

RD>> Regarding "building a catalog of all top level domains and what
resolution protocol each one invokes [...]", this argument is, in my
opinion, specious.  I think the common assumption is that everything
not lised in the Special-Use Domain Names registry is in the DNS name
space, which would make the Registry a complete catalog.  If I'm
wrong, seems like a pretty simple issue to fix.

RD>> I have to say I simply don't understand the discussion about
"expectations" in section 5.  Section 2 of RFC 7686 describes how
namnes ending in .onion should be processed.  It is, of course,
possible that names ending in .onion may be sent over the Internet by
non-compliant implementations.  That sort of expectation comes along
with any protocol that may encounter non-compliant implementations.
If there is a special concern, about a particular type of name, that
concern can be expressed in the defining RFC.  I don't see how every
possible failure case can be anticipated in the Registry, nor do I see
such a requirement placed on any other IETF protocols.

RD>> From Section 5:

   "[...] the [RFC6761] registry does not include
   direct guidance for any of the seven audiences, relying instead upon
   a reference for each entry in the Registry to the document that
   requested its insertion."

RD>> This argument is specious, as well.  It is common practice to
point at an RFC for information about a particular registry entry, to
avoid confusion and transcription errors inherent in putting redundant
text in the registry.  In the case of the Special-Use Domain names
registry and RFC 6762, there is no expectation that all of RFC 6762
needs to be read to understand the details of the special-use
designation.  Section 22.1, "Domain Name Reservation Considerations,
gives concise answers to the relevant questions from RFC 6761.

RD>> In section 6.1:

   [RFC2860] draws a line between what is policy and what is technical.
   A variety of opinions have been expressed regarding whether [RFC6761]
   blurs this line.  In particular, [HUSTON] has one viewpoint on the
   topic.  As noted earlier, it is out of scope for this document to
   analyse this issue beyond noting that such a variety of views
   exist.

RD>> Any reason not to include some of those other views, here,
especially views different from the views epressed in [HUSTON]?  Seems
like pretty selective reporting to me.

RD>> In response to section 6.2.*: again, in my opinion, RFC
6761 did not attempt to put any approval or designation process in
place beyond the explicit "an IETF 'Standards Action' or 'IESG
Approval' document".  So, RFC 6761 does not expect that the questions
for the registry would be the way in which a request for designation
as a special-use name would be evaluated.  Rather, each request was
left to be evaluated on a case-by-case basis through the normal IETF
Standards Action publication process.  By design, RFC 6761 makes no
statement about a specific WG or evaluation body or process.  One of
the key questions the IETF needs to consider is whether more formal
process is needed; if so, the IETF can design and publish a
description of that process.

> On Mar 8, 2016, at 9:09 AM 3/8/16, Alain Durand <[e-mail]> wrote:
> 
> Dear wg,
> 
> draft-adpkja-dnsop-special-names-problem-01 has been posted today. It is available at:
> https://www.ietf.org/internet-drafts/draft-adpkja-dnsop-special-names-problem-01.txt <https://www.ietf.org/internet-drafts/draft-adpkja-dnsop-special-names-problem-01.txt>
> 
> It is an individual submission, not a working group item. It reflects the discussions the initial 3 authors have had so far. Also, Warren Kumari provided lots of input and generously contributed significant amount of text. In the tradition of IETF recognizing contributions, we have added Warren to the author list.
> 
> The authors know that the subject addressed in this document is controversial. We hope it will help clarify the discussion. In many places, we know different opinion exits. We have tried to reflect the existence of those opposition views to the best of our possibilities.
> 
> We would like to see discussion of those views in the mailing list to help us prepare the next version of this draft with the goal to ask the working group to adopt it.
> 
> Best,
> 
> Alain, on behalf of the document authors.
> 
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop