On 7/8/15, 7:36, "Suzanne Woolf" <suzworldw...@gmail.com> wrote:
>For example, the distinction between gTLDs and ccTLDs is of great >importance to ICANN and to participants in its decisions, but of less >obvious relevance to an application developer or DNS operator who sees >only "name that gets a positive response to a DNS query against the >public root zone." It's not that the distinction between gTLDs and ccTLDs matters, I believe that what matters first is whether this is an issue best handled in the DNS protocol or in the operational conventions applied to placing names into the root zone. As much as I spend time trying to distinguish characteristics of TLDs, I don't think any of that really matters in this context, at least in the high level. If a name is meant to be represented in the DNS, then delegate it, NS/DS set and all. If a name is not meant to be in the DNS, then we can 1) simply reserve it from being delegated, 2) delegate it in a way that shunts all queries to /dev/null or 3) alter code paths such that the name is never spoken over port 53. A clear definition that hasn't been made is what names are we talking about. Re-reading notes, it seems that all the use cases match, to date, host names and there are specifications that bear that out. Such as pointing to RFC 1123's definition of a host name. But the described use of onion would break that assumption. This lack of definition isn't a show stopper but to be pedantic about it, no one has offered up why we talk about "domain" names. (RFC799 seems to be the origin, citing mail domains, but that is in the context of mail servers.) >It seems to me, as a first cut, that the important thing to take into >account here is that the production DNS root zone is dynamic-- just as >any other chunk of the namespace. We're accustomed to thinking of the >root zone as special, and indeed it's still far less dynamic than other >areas of the namespace, for good reason-- but it's not static. Rules we >try to derive today could change within foreseeable time. (Some of us >are/were opposed to the decisions that resulted in this fact, but it >remains a fact.) It's been dynamic for a decade, NS sets change and there has been activity in ccTLDs and even some sporadic gTLD delegations, not to mention test IDNs coming and going. I sense the fear is more in the way other pieces of software treat the root zone. I recall a past version of a general purpose, open-source name server that would refuse to load a zone as the root unless explicitly informed the operator was sane. The concern returns once again to what I see as a central question - is this about the protocol or the operational convention of registering names in the root zone? If it is the former, we are tinkering with, perhaps, the production of the root zone. If it is the latter, we are tinkering with the submission process. >It further seems to me that an attempt to list names that are currently >in the public root zone or might someday be in the public root zone has a >high risk of being simply backwards if the purpose is to identify names >it's "safe" to use in other contexts because they won't collide with >names in the public root zone. Our current approach as documented in RFC >6761 comes at this question from the perspective that the IETF can >declare whatever names it likes to be so "protected" by extending the >standard with a new entry in the special use names registry, but takes no >account of any possible distinctions between names currently in use at an >arbitrary time for the DNS, names that will (or even might) be in use at >a future time for the DNS, and any other categories. > >We might want to decide which, if any, of such distinctions are >meaningful for the purposes of the IETF identifying "special use names". "Special Use Domain Names" The third word is central to this thread is often omitted. It is why we should have a definition of 'domain' names, state whether this applied to the operation of the global public Internet or is a matter of altering the standard, base, protocol. One perspective I think needs to be addresses too is "what is the process" for registering a name in the root zone registry? What does it mean? There is the ICANN process. The process has been defined by a community process akin to the IETF albeit with more structure to the community. When I see words like "to ICANN and to participants in its decisions" I cringe because that is giving credit to the wrong group when it comes to many of the processes. ICANN does implement what comes in from community processes so there may be an appearance of the ICANN staff making decisions. But this is as much a function of what comes from the community. But this isn't what I want to impart. (There have been threads on whether it's as easy to participate in IETF or ICANN communities. I'll leave that as an open topic.) There's been talk that the price of a TLD is high. I am unable to rationalize all of the price tag, but it covers a lot of work done by a lot of people when it comes to clearing a name for registration and delegation. I'm not going to try to justify the price here, but I do think it's is instructive to keep in mind the work needed before a name is delegated. Is a name going to work? Does it meet protocol limitations? That's pretty simple. Is the name compatible with the existing set of code out there? Are names in use that would be disruptive? For example, "local." For this the IETF list is important. Is the name offensive? This is something we don't talk about inside engineering circles, it's highly subjective. But what if some managed to deploy a system using a top name what is, well, offensive. Perhaps having a thick skin makes one think it is okay, but still it might incite violent reactions by others. Does the name conflict with another use in a way that causes harm? Could someone, seeing it or copying it from hardcopy be fooled by the name? Is it visually similar? 1 vs. i, Cyrillic 'a' vs. Latin 'a' and so on. There are other reasons...but I'll skip to the last obvious one - will a registry for the name work? I raise this because this is a part of the current process for gTLDs but is one that is not applicable to names that are not meant to be registries. I've been kicking the process around in my mind the past weeks. I keep thinking there's a easy way around all this work, but I don't think so (except for the last one). If it were, then the price of a new TLD need not be so high. But I keep coming to this, decidedly non-engineering, question: What if someone uses RFC 6761 to get an offensive name registered as a special-use domain name? What organization is going to bear the risk of dealing with any potential fallout from the registration? Well, maybe I'm wrong about this - objections raised about operating something with an offensive name more so than recognizing a name is offensive. What if I have to have the name in my code paths though? I'm not against innovation and using (domain) names for things that will not be in the DNS. I am against altering code paths such that we restrict the use the DNS protocol in other contexts or in the future. I am against putting the IETF in harms way if someone manages to "game the system" for one purpose or another. I do think an alt-TLD is needed, one that avoids the trouble some strings might bring. I do think that the IETF needs a process for determining what names should not be activated (given NS sets in the root zone), or at least provide recommendations for what should not be activated. Perhaps IETF last call is what people feel is sufficient to judge whether an idea has consensus. In many ways, I'm not all that confident. Last calls are only heard by those that are subscribed to the lists. (That's behind my comment that I'm concerned by the not-engaged developer population.)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
