Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps

[Suzanne Woolf <[e-mail]>]

Hi,

Some comments on the draft….no hats.

I’ve started at the beginning and covered through the beginning of Sec. 4; I’ll review the “existing practices" material separately.

It looks severely critical because it’s long, but most of the changes suggested are small, and I’ve tried hard to keep them in a clear context. In general, I’m mostly suggesting the authors tighten up the specifics and surface a few assumptions.

I think it’s definitely pointed in the right direction.

Thanks to the authors for their work.


Suzanne

======
draft-ietf-dnsop-sutld-ps-02
3 Feb 2017

Abstract

1. I think for purposes of this document, ICANN and SSAC are not "standards organizations", just "organizations". I realize it's a debatable point in casual use (is ICANN's documentation of its processes for changing the root zone "standards"?) but I don’t think it applies within the usual meaning of the term for the IETF and other recognized SDOs.


Introduction

2. I like that the name/resolution distinction is clearly called out here. I’m not sure the names=DNS assumption has been entirely banished throughout but it’s definitely heading in the right direction.

3. STYLE/GRAMMAR: "....defined policies for adding to the registry, and made some suggestions about how that policy might be implemented." This should be "....defined a policy..." or "....about how those policies might be implemented."

4. STYLE/GRAMMAR: This sentence is hard to parse: "In 
   support of the particular set of problems described here...."

OLD:
   "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."

NEW:
"In support of its analysis of the particular set of issues described here, the document also includes descriptions of existing practice as it relates to the use of domain names, a brief history of domain names, and some observations by various IETF participants who have experience with various aspects of the current situation."


Terminology

5. On defining "domain name," I think citing RFC 7719 and the domain-names draft might be helpful. If it were less ambiguous in practice this problem would be easier, but at least mentioning some contexts where domain names are used or some of the constraints of what can be in the strings might be helpful to readers who haven't already seen the challenges in such a definition.

6. The terms are all defined relative to something we don't actually have a term for, but might need one. If we're talking here about "special use" names, what's a "normal" or "ordinary" or "expected" use, and how is a "special use" different? You seem to be answering that question but only by implication.

Possibly add something like "The default or assumed use of a domain name is initialization and resolution within the Domain Name System, which includes a single global resolution scope and the Domain Name System protocol (RFC 1034/1035). Such names are expected to be unique within the global domain namespace. A name intended for use in the internet or its defining protocols, following the construction rules for domain names, but not global in scope or resolved by DNS wire protocol, could be considered a 'special use' name."

We don't have a formal, consensus definition anywhere, but RFC 7719 takes a credible shot at a lot of what we need here, so you might mostly be able to get away with citing it. 


Problems associated with Special-Use Domain Names

7. STYLE/GRAMMAR: The two sentences beginning "Solutions to these problems..." are hard to parse. This is partly because they're making a subtle point, but:

OLD:
   "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."

NEW:
   "Solutions to these problems, including their costs or tradeoffs, are out of scope
   for this document. They will be covered in a separate document."

8. I think para. 2 (bottom of page 3) and para. 3 (top of page 4) are a little confusing, even though I understand the rhetorical device of using the word "problem" 12 times in half a page. I wanted to see how you felt about that text before trying to rewrite it.

9. The text "There are several different types of names in the root of the Domain Namespace" assumes the root is important-- that it's the mathematical root of a tree-- without quite saying so. Citing RFC 7719, sec. 2 is probably helpful here.

10. STYLE/GRAMMAR: "names that may not be applied for as a TLD" -> "....applied for as TLDs"

11. STYLE/GRAMMAR: I wouldn't be surprised if the word "commandeer" made some readers uncomfortable; it's got an implication of illegitimacy.

12. "assign names from the pool of unused names" is a little imprecise, should probably specify slightly further:

OLD:
   "Both ICANN and the IETF have the authority and formal processes to
   assign names from the pool of unused names..."

NEW:
   "Both ICANN and the IETF have the authority and formal processes to
   make new assignments from the pool of unassigned domain names, and expect names they add to
   be unique within the global namespace."

13. The "lack of coordination" is only a problem given the expectation that names created under multiple set of processes will be unique within a shared scope. This can be assumed in the definition of “domain name” or it can be explicitly called out here, but the uniqueness constraint has to be explicit somewhere, because without it there’s (arguably) no problem.

14. You say: "The term "technical use" in RFC 2860 [RFC2860] is considered by
      some to be too inclusive."

Isn't the concern really that the term is ambiguous, so some people find it too inclusive and some people find it too limited? For instance, we've heard the view expressed that it wasn't intended to include names defined for non-DNS resolution mechanisms, so something like .onion or .local isn't covered; we've also seen it asserted that "technical use" by the IETF includes the ability to force a change to the DNS root zone by ICANN. (As a personal view, I don't support either extreme.)

15. You say "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."

It almost makes more sense to me to say the IETF and ICANN each have an ability to add names to the domain name space under conditions such that people will use them, but there's no shared view of what that means in terms of the shared global namespace. Specifically, there's no shared view of how to avoid collisions such that the uniqueness constraint that people expect of their domain names will be reliably honored.

AFAIK the IETF has never claimed anyone would stop using a particular string in a domain name slot just because the IETF told them not to. The IETF can't tell people how to write their code, it just has a process for defining what's interoperable so they can avoid problems with others if they want to.

16. Same comments on the text "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."

17. More generally, on the last two comments, the use of the word "authority" may need to be clarified here. It sounds obvious, but I think if it really were obvious we wouldn't need to think about this stuff quite so hard. If we assume RFC 2860 is not open for modification (one of our ground rules from early on) and it's not the WG's job to interpret it, we're left with the practical reality that ICANN has operational authority over the DNS root zone under its community's processes, the IETF has operational authority over the SUDN registry under its processes (RFC 6761).

18. "Commandeer" again has some questionable connotations. Still not sure of a better word, but the .onion RFC might provide one. 

19. I'd add to the list of possible reasons for putting a name into use without following any external process: "Names are expected to be resolved only within the local scope for a protocol or network, or by some non-DNS protocol, and designers don't realize or don't care that modern systems and applications may nonetheless try to resolve domain names with no context signaling in the global DNS." Handwaving about authority aside, the real concern in these cases is interoperability; no one would care if such names didn't tend to leak, but leaking is an interoperability problem.

20. I don't like the text "These queries may constitute an operational problem for operators of root zone authoritative name servers." They're not. But the document is supposed to be a list of problems people have identified without judgment as to their validity, so I won't object to including it. :-) However, the possibility of inadvertent information leakage (a privacy consideration) is also a real one to many people, and perhaps that should be added.

21. The text "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." seems a little incomplete to me.

I would add something like "This view is usually justified by the observation that the IETF has never asserted control or authority over what protocols are 'allowed' on the internet, and that the principle of 'permissionless innovation' suggests there should be a way for people to include new uses of domain names in new protocols and applications." After all, we don't ask people to prove their application is "good" before we "let" them use TCP for it, even though we're the SDO for TCP. (I'm not personally sure this is a good analogy, but I've heard it. There are plenty of protocol parameter registries for which the policy is "just ask" or FCFS or expert review, so I think this is really a question about registry policy.)

22. You say "In cases where the IETF has made assignments through the RFC 6761 process, technical mistakes have been made," but I admit I'm having trouble identifying an example of an addition to the registry that included such technical mistakes. This text almost sounds like it meant "In cases where the IETF has *not* made assignments through the RFC 6761 process...."

23. You say "In principle, the RFC 6761 process could be used to document the existence of Domain Names that are not safe to assign..." and go on to talk about draft-chapin. This para. mentions root servers again, so my comment above (add the privacy consideration) applies here too.

24. The next para, which begins "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...." puzzles me. Could you clarify why it's not redundant with the previous case? You cite the same draft for both, but I think you're trying to make different points ("unsafe to assign" vs. "commandeered"-- are they the same thing? Has anyone brought up different risks associated with them?)

25. The para that begins "No mechanism exists for adding a name to the registry...." is talking about two different problems (IETF is responsible, no precedence for assignment). It might be clearer if you separate them.

26. There's also a third point that there's no precedence for resolution, either; there's no mechanism in the registry for specifying which protocol is expected for resolution, so no precedence between the functional default (DNS) and others. SO for instance, the registry won't tell people that the string ".onion" when it appears in their networks in domain name contexts, is supposed to be resolved by an entirely different protocol. This may be a problem with the registry structure rather than its existence or its contents, and it may not be the only one (early versions of draft-adpkja-dnsop-special-names-problem had some discussion of the registry itself IIRC).

27. The text "No process exists for checking documents to make sure they don't accidentally assign names (e.g.  RFC 7788)." could be taken to mean either that the IETF has no such process (and it's true, we don't) or that no one else does either (which is also true). Within the IETF, this breaks the standards process; on the wider scale, it risks collision between the same string being assigned informally to multiple, potentially colliding uses (the folks who wanted to use .home in homenets, and the folks already using .home for something else), with no certainty they won't collide and no rule for determining which use, if either, is an error.

28. The text “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.” doesn’t go far enough. People assume both that they need a human-readable name, and that they need a single label name (“TLD”). Both assumptions, especially together, create a perception that there’s a limited number of useful domain names in the world, with corresponding tendencies to treat the underlying resource as scarce. Domain names aren’t scarce; domain names that meet some of the implicit assumptions people make about them might well be.