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.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
