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
