Re: [DNSOP] On .ZZ

Bill Woodcock <woody@pch.net> Fri, 22 November 2019 15:15 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 9AA01120104 for <dnsop@ietfa.amsl.com>; Fri, 22 Nov 2019 07:15:17 -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 gkH1UP7PnNj4 for <dnsop@ietfa.amsl.com>; Fri, 22 Nov 2019 07:15:15 -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 D73E612007C for <DNSOP@ietf.org>; Fri, 22 Nov 2019 07:15:15 -0800 (PST)
X-Footer: cGNoLm5ldA==
Received: from [10.19.48.16] ([69.166.14.6]) by mail.pch.net (Kerio Connect 9.2.7 patch 3) with ESMTPS (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256 bits)); Fri, 22 Nov 2019 07:15:13 -0800
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
From: Bill Woodcock <woody@pch.net>
In-Reply-To: <9f39c3b2-03c1-2d1d-e8af-b3c88ba19b62@lisse.na>
Date: Fri, 22 Nov 2019 07:15:09 -0800
Cc: DNSOP@ietf.org
Message-Id: <9FE1B1B3-4DC7-42C6-8F4C-0AA6E052DBC2@pch.net>
References: <9f39c3b2-03c1-2d1d-e8af-b3c88ba19b62@lisse.na>
To: el@lisse.na
X-Mailer: iPhone Mail (17A878)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/98i7GjBqBkDKgx6C9UXLPYZq8AE>
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 15:15:18 -0000

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 <el@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 <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
> 
> -- 
> Dr. Eberhard W. Lisse   \         /      Obstetrician & Gynaecologist 
> el@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