Re: [DNSOP] perspective Re: Thoughts on the top level name space
A re-ordering of the previous message happens here:
On 7/9/15, 13:45, DNSOP on behalf of hellekin dnsop-boun...@ietf.org on
behalf of helle...@gnu.org wrote:
*** Should IETF use social media to expand their reach? (@ietf?
@dnsopwg?)
Oddly enough, ICANN does this, an in fact the ICANN staff includes a
Communications Team whose job is to engage as many peoples as possible
(and my peoples I an stretching that beyond cultures to, umm,
classifications like government workers, etc., i.e., non-cultural
divides). This is also why ICANN makes a point of holding meetings and
events in places where the IETF is reluctant to go.
There's a double point here. One, yes, this is a necessary component that
the IETF has not taken on as a role. And two, the IETF doesn't employ a
communications team trained and equipped to do this. I'm not saying the
IETF is deficient, I mean it is what it is.
So, to summarize, when considering Special-Use Domain Names candidates*,
I'm for:
- - rejecting based on current use in DNS (to avoid name conflicts)
- - rejecting based on proximity of an existing name when it can lead to
confusion and pose a security risk
- - recommending rejection when the word is threatening or contrary to
cooperative and humanistic values (e.g., UNDHR)
- - suggesting rejection when the word can be considered offensive
* I guess IANA could tell better about how that fits their own process
for TLDs.
The first I don't completely understand, if it's in the DNS, then the ship
has sailed. I'm missing that point.
The other categories are fine. It's the implementation that has me
concerned.
In another thread, you'd asked about [less] ambiguous and simpler (I
inserted less because I think you meant to include that) in a critique
about RFC 6761. You'd also mentioned that, and I can't find the quote so
forgive me for paraphrasing your thought, that it wasn't what RFC 6761
asked that was a problem, it was the answers submitted - with the problem
being ambiguity.
Unless I have mis-paraphrased you, and recognizing John Levine's comment
that the IETF is better at technology than processes, RFC 6761('s
potential replacement) could do with a lot more determinism. RFC 6761 has
it's heart in the right direction, recognizing there's a difference
between impacts on code paths in applications, in DNS servers, DNS
resolution, and registration activity. (I don't get the first item on
6761's list, do humans know the name to be special, but that's another
matter unimportant here.) What RFC 6761 doesn't do well enough is give
any guidance of how to evaluate the responses.
There are only 6 sets of successful justifications in the registry
representing, if I counted right, 31 domain names, in 9 TLDs [net has
example.net], representing just 5 TLDs [local]. Looking the Users:
responses, all are free to use with the exception of the justification
of example as meaning only for documentation. (Most documentation of
DNS configurations comes from running it through a server, so...I mention
to this to mean I really don't get the Users: consideration section of
the RFC 6761 application.)
Throw in that 5 of the successful justifications are in the same RFC that
defines the registry, the 6th is in the next (numerical) RFC and by the
same authors. Section 5 does give guidance on what to put in the
justifications but there's no guidance of what is important or necessary
to gain approval. That's not a lot to go on, given that there aren't many
criteria listed anywhere. And that there's no expectation that the review
of the application will be taken on by outside-the-IETF interested parties.
The IETF often uses refers to deciding something with the appropriate
expertise involved. By that metric, I see the process described in RFC
6761 not being sufficient, it doesn't ensure that the appropriate experts
are involved. Yes, the IETF has expertise when it comes to whether a name
is special in engineering - and I think that is missing from RFC 6761 -
especially having deterministic criteria defined. One thing I'll mention
in the sense of being blue sky - there are IAB liaisons to ICANN board
that could be a means for coordination, perhaps there is a way for an
expert review to happen.
BTW, stumbled across in preparing this message, perhaps of interest:
https://datatracker.ietf.org/liaison/1351/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 07/08/2015 02:33 PM, Edward Lewis wrote:
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?
TL;DR: you cannot avoid subjectivity, you have to embrace it.
Your entire post is very interesting and thoughtful, Edward, but I
wanted to follow-up on my response to Suzanne and focus on your mention
of subjectivity and engineering.
There's no way we cut subjectivity out of the process, because decisions
are made by humans, on objective criteria (e.g., my previous
Re: [DNSOP] perspective Re: Thoughts on the top level name space
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/08/2015 08:36 AM, Suzanne Woolf wrote: 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. I can see a distinction here between names that are currently in the public root zone, and names that might someday be in the public root zone. Obviously, the former is a finite list of names in operation, and can serve as a reference to avoid name conflicts with non-DNS namespaces: they already exist, so they should be considered solid. Besides, if I understood well, there's a procedure to send decommissioned domains to a 50-year-purgatory before they return to the unused set. On the other hand, this latter set of unused, potential domain names is the complementary of the former in the superset of all domain names: making it special as such would determine the future of the namespace, which seems to go against the idea of letting reality unfold and adapt to it. So I'd recommend a clear distinction is made between existing domain names in the public root, and the rest of the set, kept as undetermined and irrelevant to daily operations. 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. I'm not sure I understand what you mean by currently in use at an arbitrary time for the DNS: it sounds to me as an equivalent to the superset of all possible domain names that I evoked earlier; if a domain is in use now, it's part of the set of existing domain names in the public root, otherwise it's undetermined. Or do you mean there should be a preemptive complete assignation of the domain namespace? I don't think it's possible to predict an ordered way of revealing the namespace until its exhaustion: it sounds mechanistic. Maybe you're suggesting that some names should be reserved for future use? In that case I fear arbitrariness may be the rule. What example categories would you think of? We might want to decide which, if any, of such distinctions are meaningful for the purposes of the IETF identifying special use names. For the sake of avoiding name conflicts, the distinction above is necessary (existing, i.e., registered by IANA, or not). Regards, == hk -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQJ8BAEBCgBmBQJVnqZPXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0 ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9KiYQAJoYiCpysih6Afs2TIRMFjCz qqK17dtdesnEGDCGVoj3IFSfSFDcj2CFauxb7bppiemZGx/Ot1Gnsly/ULCI9TC7 1UGP/QkmLHPXaU9xiGoDssEoMtXxMfD89zi5RxqwIW5NvUg8CH4UUU3njW+oLCzG EA1LH0V8PmOhLvWmI21FN02csq5w+4crTMytfbgT6rywnYJgAUB4mYLUMzl1XSI/ DlYW5PwHCC4T6dD8GkA4bvcB8Ve8fjXO+zk2PlOdtQy+9cA0I14Ah8Y7Fo3HDUOI 5fmdLi5B73E+KedYLVrAs+MZENGd0qfoHZRcLPN8yObQ2NSFIXYxV1K+tI/QhzP+ 2/D+oemihDvaV1Vi8rNAHknzSUG3afMtrsPjC/9vcooYeqXPQjavKDYJg7UZDeT6 lphoa5r4AeQd6321cKcDbT55y9/Pq5OJBCGa1bWLNlax4DGUZ5juy1j2NLD+faLU jIUW0bT3t6m3meQsj/dmw9xX3ITHz8ESF9NbicItJ4uLpjXdIxNoxgVJzuQEEM/f jji9E6bmqe8IbqiXbSk0aNGf1O4h7nXDXrzTqlB6L6x/4n+eZVzWTykZbMdOlUnH xuW020sWk9GXh/EuKE82p+xCDYK6b0ES5e9sU9kVFCoiaXm5JsCe9ygmQvRZM485 2t1TLkEDrrUesg3iT7PW =Z2EX -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] perspective Re: Thoughts on the top level name space
Hi, Thanks, Suzanne for your thoughtful contribution. I posit that continued inaction on the question of Does the .onion case fit the RFC6761 mechanism actually weakens the reputation of the IETF, and certainly that of DNSOP. I acknowledge that it is important to have discussion and a wide range of opinion expressed, such that an informed decision can be made. We have seen plenty of discussion. I beleve that it is time to make a decision. People will then respond to that in whatever manner best suits their objectives. I encourage the relevant chairs of the working groups to push for a decision. Regards, Hugo Connery From: DNSOP [dnsop-boun...@ietf.org] on behalf of Suzanne Woolf [suzworldw...@gmail.com] Sent: Wednesday, 8 July 2015 13:36 To: Jaap Akkerhuis Cc: Edward Lewis; Steve Crocker; dnsop@ietf.org Subject: [DNSOP] perspective Re: Thoughts on the top level name space Colleagues, As we pursue this discussion, I think it would be helpful to focus on attributes that are visible and relevant from the perspective of DNS operators, with an eye towards guidance we might provide to them and applications developers. 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 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 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. best, Suzanne On Jul 8, 2015, at 3:53 AM, Jaap Akkerhuis j...@nlnetlabs.nl wrote: Steve Crocker writes: For the alpha 3-code the complete user assigned set is: AAA-AAZ, QMA-QZZ, XAA-XZZZ and ZZA to ZZZ so one could argue that the delegations for TLD xyz (and maybe xxx) is a actually against the rules in ICANN�s Application Guide Book. It's my understanding that only the two character codes are included in the relationship between DNS top level names and ISO 3166-1. Three letter codes aren't included, so there's no conflict. There is a relation between aplha-3 codes and gTLDS. In my reading of Applicants Guide Book Section 2.2.1.4 point 1, apha-3 codes are considered an off limits if listed in ISO 3166-3. (That's why google retracted some applications because they collided with his rule). Of course, the list above is 1918-like space but still so it doesn't matter that much;. However, one might want to be consistent in threating 1918-like thingies. jaap ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] perspective Re: Thoughts on the top level name space
secretary-hat on On Jul 8, 2015, at 8:06 AM, Hugo Maxwell Connery h...@env.dtu.dk wrote: I posit that continued inaction on the question of Does the .onion case fit the RFC6761 mechanism actually weakens the reputation of the IETF, and certainly that of DNSOP. I acknowledge that it is important to have discussion and a wide range of opinion expressed, such that an informed decision can be made. We have seen plenty of discussion. I beleve that it is time to make a decision. People will then respond to that in whatever manner best suits their objectives. I encourage the relevant chairs of the working groups to push for a decision. Just to be clear: the WG already did decide that. The WG document has been submitted to the IESG a few weeks ago. See the archives of this list, and https://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/history/. To see the (hopefully-up-to-date) list of WG documents, see https://svn.tools.ietf.org/svn/wg/dnsop/doclist.html --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] perspective Re: Thoughts on the top level name space
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
Re: [DNSOP] perspective Re: Thoughts on the top level name space
Em 08/07/2015, à(s) 14:33:000, Edward Lewis edward.le...@icann.org escreveu: 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. Actually, a better distinction would be between ISO-controlled allocation and ICANN-controlled allocation, not gTLDs and ccTLDs. For 2 ASCII letters, ISO is now considered authoritative in allocating pair of letters to countries and territories; ICANN's only decision is whether an organization represents that country in RFC-1591 terms. But when it comes to IDN ccTLDs, registries need to pick a 2-char IDN string, submit to ICANN which then decides whether that combination is to become a ccTLD or not; with IDNs there is actual decision on whether that string is to be allocated as a ccTLD. Rubens ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] perspective Re: Thoughts on the top level name space
On 7/8/15, 13:51, DNSOP on behalf of Rubens Kuhl dnsop-boun...@ietf.org on behalf of rube...@nic.br wrote: Em 08/07/2015, à(s) 14:33:000, Edward Lewis edward.le...@icann.org escreveu: 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. Actually, a better distinction would be between ISO-controlled allocation and ICANN-controlled allocation, not gTLDs and ccTLDs. For 2 ASCII letters, ISO is now considered authoritative in allocating pair of letters to countries and territories; ICANN's only decision is whether an organization represents that country in RFC-1591 terms. But when it comes to IDN ccTLDs, registries need to pick a 2-char IDN string, submit to ICANN which then decides whether that combination is to become a ccTLD or not; with IDNs there is actual decision on whether that string is to be allocated as a ccTLD. Hmmm. I'm confused in many ways about this reply. My comment above is that, as far as the thread on the Special Use Domain Name registry and any potential replacement of the process of making an entry in it, it doesn't really matter how or why a name appears (or doesn't) in the DNS to the software handling the names. But beyond that, ISO, has, as one of its many functions, the job of maintaining the ISO-3166-1 alpha-2 codes. I did some web searching and found this reference which might clear up ICANN-controlled allocation : http://icannwiki.com/CcTLD and, in particular: http://www.iana.org/help/eligible-tlds As far as the IDN ccTLDs, registries need to pick a 2-char IDN string - I believe that to be factually incorrect. The Fast-Track process here: https://www.icann.org/resources/pages/fast-track-2012-02-25-en has details. But there are plenty of examples of more than two character IDN ccTLDs already, I think. For example, Mongolia's which 'looks like' MOH : https://www.iana.org/domains/root/db/xn--l1acc.html There are many names that are longer scripts I don't understand enough about to count characters. Like one of Sri Lanka's : https://www.iana.org/domains/root/db/xn--xkc2al3hye2a.html smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
