This whole discussion confuses me. As Roy and Jaap have pointed out, ISO 3166 has indicated the user defined codes won’t be allocated. They are for private use. Just as RFC 1918 has designated 10/8 for private use.
To me, this means any of the user defined ISO codes are fair game for internal use (that is, between consenting adults), regardless of context, including use in the DNS. My interpretation of this is that since ISO 3166/MA won’t be assigning those codes and it is wildly unlikely ccTLD policy will change such that IANA could delegate any of those codes, it makes the use of those 2-letter domains for private use wildly unlikely to result in a collision with public use (that is, delegation) since the domains can’t be delegated. The advantages of this are: 1) no change in IANA policy 2) no need to rerun the fun of the RFC 6761 “discussions" 3) no need to do an ICANN PDP or some other undoubtedly painful process to reserve a string 4) no need for interminable arguments about language (“internal doesn’t mean anything in Klingon!”) 5) people can paint their bike shed any one of 42 colors I don’t understand why one would need to pick ZZ (or any other user defined code) to mean by convention anything. It doesn’t hurt anything, I just don’t see the point. I would turn the question around: Why not simply have an RFC that declares the user defined ISO 3166 codes as the RFC 1918-space equivalent for the DNS and be done with it? If people _really_ want to continue the bike shedding on a particular string, they still can, but the folks who want a string (or strings) that they can use for internal purposes without fear of it being delegated in some future round of new gTLDs can just get on with their lives. Confusedly, -drc P.S. Yes, I know people can use those 2 letter codes now, but having it explicitly stated in an RFC comforts some folks > On Nov 22, 2019, at 4:23 PM, Bill Woodcock <wo...@pch.net> wrote: > > Man, sorry for the weird random capitalization, y’all. Autocorrect has a > mind of its own. > > Also, what Matt said: perhaps we could approach consensus if those in favor > of the proposal would articulate their thoughts on why specifying a > two-letter is the best solution to (this, any) problem, the rest of us might > be able to see why you feel your case is compelling. > > -Bill > > >> On Nov 22, 2019, at 07:15, Bill Woodcock <wo...@pch.net> wrote: >> >> Eberhard: >> >> The principle I’m trying to articulate is that our relationship to ISO 3166 >> is that of a standards body which has delegated to it. >> >> ISO 3166, in turn, specifies that this code is (for now, and at their >> authority) to be used by USERS for their purposes. >> >> It’s my assertion that it’s bad form for us, having placed ourselves in the >> standards body role on one side of ISO, to now also claim that we, the same >> people, are also “users” Standing on the other side of ISO. >> >> That seems to me to not be in the spirit of a good-faith delegation. >> >> If we want to start individually specifying the meaning or use of two-letter >> TLDs, it’s my assertion that We should first un-delegate that role from ISO, >> and take direct control of the task, not attempt to stand on both sides of >> them. And I think the harm of doing so would vastly outweigh any benefit. >> Therefore I think this shouldn’t be done. Either we delegate authority to >> them, or we don’t. No splitting the baby. >> >> -Bill >> >> >>> On Nov 22, 2019, at 02:17, Dr Eberhard W Lisse <e...@lisse.na> wrote: >>> >>> Bill, >>> >>> ISO has new draft out as part of their regular maintenance cycle which >>> states >>> >>> [...] In addition exactly 42 alpha-2 code elements are not used in >>> the ISO 3166, AA, QM to QZ, XA to XZ, ZZ. This rule may change in >>> the future. [...] >>> >>> and then references this >>> >>> If users need code elements to represent country names not included >>> in this part of ISO 3166, the series of letters AA, QM to QZ, XA to >>> XZ, and ZZ [...] are available. >>> >>> I read that to mean that a .ZZ (or rather any of the 42 possibles) would >>> be safe to use in our context. >>> >>> If the rule were to change I would however speculate that the wishes of >>> the government concerned might prevail over the wishes of ICANN. >>> >>> Whether this all is safe enough to write a standard, I don't know. >>> >>> >>> el >>> >>> >>>> On 22/11/2019 10:26, Bill Woodcock wrote: >>>>> On Nov 22, 2019, at 12:20 AM, Shane Kerr <sh...@time-travellers.org> >>>>> wrote: >>>>> >>>>> "User-assigned codes - If users need code elements to represent >>>>> country names not included in ISO 3166-1, the series of letters AA, >>>>> QM to QZ, XA to XZ, and ZZ, and the series AAA to AAZ, QMA to QZZ, >>>>> XAA to XZZ, and ZZA to ZZZ respectively, and the series of numbers >>>>> 900 to 999 are available. NOTE: Please be advised that the above >>>>> series of codes are not universal, those code elements are not >>>>> compatible between different entities." >>>>> >>>>> So the intention of the ISO at least is that these codes are used by >>>>> users. (I'm not sure what the scary warning means.) Certainly I >>>>> have made heavy use of .Q* and .X* in my own testing, with the >>>>> assumption that these would never be assigned (and yes, there is >>>>> .TEST but sometimes you need more than one one TLD). >>>> >>>> Right. And in fact, “unassigned” ISO codes _do_ get used, for places >>>> like Kosovo, that are in a state of disputed or partially-recognized >>>> countryhood, and ranges that are reserved for user use really should >>>> be left for that use, because they do in fact get used by users, so >>>> any centrally-coordinated use will run afoul of that. >>>> >>>> Again, this is an argument from principle rather than an argument >>>> based on the specific case at hand. I just think that we have a >>>> well-established precedent that all two-letter TLDs are derived from >>>> ISO 3166 Alpha-2, and it’s bad form to cross back over and start >>>> poaching in their territory. >>>> >>>> -Bill >>> >>> -- >>> Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist >>> e...@lisse.na / * | Telephone: +264 81 124 6733 (cell) >>> PO Box 8421 \ / >>> Bachbrecht 10007, Namibia ;____/ >>> >>> >>> _______________________________________________ >>> 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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
