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 <[email protected]> > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
