Re: [DNSOP] On .ZZ

Bill Woodcock <woody@pch.net> Fri, 22 November 2019 08:26 UTC

Return-Path: <woody@pch.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A5C1200B5 for <dnsop@ietfa.amsl.com>; Fri, 22 Nov 2019 00:26:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRTeGxuBmxNo for <dnsop@ietfa.amsl.com>; Fri, 22 Nov 2019 00:26:55 -0800 (PST)
Received: from mail.pch.net (keriomail.pch.net [206.220.231.84]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149DF12003E for <dnsop@ietf.org>; Fri, 22 Nov 2019 00:26:55 -0800 (PST)
X-Footer: cGNoLm5ldA==
Received: from [10.19.48.26] ([69.166.14.2]) (authenticated user woody@pch.net) by mail.pch.net (Kerio Connect 9.2.7 patch 3) with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)); Fri, 22 Nov 2019 00:26:54 -0800
From: Bill Woodcock <woody@pch.net>
Message-Id: <92EF6592-8801-4E58-B893-DDCF4F68934F@pch.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_212B4CD8-9589-465D-8B71-FADB75D23018"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Fri, 22 Nov 2019 00:26:35 -0800
In-Reply-To: <f4d32eb9-c073-463f-1914-bdc62ec372bf@time-travellers.org>
Cc: dnsop@ietf.org
To: Shane Kerr <shane@time-travellers.org>
References: <CAHXf=0pOVM_MHypgL7uV88242ciBUXGpx6waUetxBbZhvth1gA@mail.gmail.com> <35F0456A-2BA5-4021-AA9D-A86889E74AE6@nohats.ca> <8a5833d5-192f-fdbf-2862-e3f144be80cc@nic.cz> <CAH1iCirfeaD5pJ1_Tm5PaATQ9_zmrj2PbSnPGyL8z40L-_z3nw@mail.gmail.com> <D7475E63-1047-4622-B7EE-DEEA1A891825@pch.net> <f4d32eb9-c073-463f-1914-bdc62ec372bf@time-travellers.org>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9cI044yepglNWB0K2sg-fj8sAIE>
Subject: Re: [DNSOP] On .ZZ
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Nov 2019 08:26:56 -0000


> On Nov 22, 2019, at 12:20 AM, Shane Kerr <shane@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