Re: [DNSOP] new version submitted for draft-arends-private-use-tld

Joe Abley <> Wed, 06 May 2020 01:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 675313A0CAA for <>; Tue, 5 May 2020 18:18:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m16fUa7d2Pd1 for <>; Tue, 5 May 2020 18:18:24 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8C3D13A0CB1 for <>; Tue, 5 May 2020 18:18:24 -0700 (PDT)
Received: by with SMTP id 23so408389qkf.0 for <>; Tue, 05 May 2020 18:18:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=k+1+AxPe0Ocsrzxd6a9qrCQcIN15nqXs6JzemB7XADw=; b=E7QtcrRlu8LU0NspbIiQEQIRWytBEdQmIFWTg90oAus8M7gVyK6qDk5EPzXvBgUNNX nya56rIqrodNJgjoF7DuDjdtRVz98AGdR24phsNqu9fKTtKCSNPStKLvbibFfLV99TaK UluhqKDnAno69flWIeOZ0CiiaPbuVwGPZ8b/A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=k+1+AxPe0Ocsrzxd6a9qrCQcIN15nqXs6JzemB7XADw=; b=Gy+KtjywT99WJ3TPZbhvsPY4zXtr5ItwmIM2sNS3xsyTqUpj9ZBHhotwhfc0dForKT QNsFlddC9QSGklkhQoL7Jwzv8biT9eG7IwdtWs8tziqCGo6j7LWbiD3Lfn8XQEMkpD2n KCx/lyeNtgwQZS1af1nwczFMvji/VV9v5e97qqujYBqO5zgSr6YC4hk0x33PBvd7Hn/A ymWBMOVzpSp9ZZv8+hfJSeIDmURD6mdSCJtai9wNhUWc2w9ILI7MMkXPLGGLBrtHfTy9 ubCd0KpOBvUsBi8JjnyHFh3mULM/0iq1inJFivtqapFSpAOupGgSy2HtEuKTwReA6U9T pcKQ==
X-Gm-Message-State: AGi0Puau7bNaJTCtb0umNn1umei9Iw9PEibADtAfqGGENFdsDoApAKd3 YaJ0qUopRmHJmzEmZcoNTHCpzOCDWkfUZrX7
X-Google-Smtp-Source: APiQypIXClzbWtDcpsUwAxfbpymOzSVHM6RkH8tyn8dcABcc48kgG4NDGNEF6CyjNbzyC1LoKaaxWA==
X-Received: by 2002:a05:620a:1222:: with SMTP id v2mr6374485qkj.463.1588727902950; Tue, 05 May 2020 18:18:22 -0700 (PDT)
Received: from ?IPv6:2607:f2c0:e784:c7:1d2f:a0ca:a0a1:1ab1? ([2607:f2c0:e784:c7:1d2f:a0ca:a0a1:1ab1]) by with ESMTPSA id u13sm523518qkj.44.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 May 2020 18:18:21 -0700 (PDT)
From: Joe Abley <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_63714ECF-69EC-4E23-ACAC-3CBA37D9D7E5"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Tue, 05 May 2020 21:18:17 -0400
In-Reply-To: <>
Cc: dnsop <>
To: Roy Arends <>
References: <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [DNSOP] new version submitted for draft-arends-private-use-tld
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 May 2020 01:18:28 -0000

Hi Roy,

On 2 May 2020, at 10:09, Roy Arends <> wrote:

> Ed and I just submitted a new version of our private-use TLD draft.
> This draft has substantial more information than the first draft. It explains that a private-use namespace does not exist, why it is needed, and how a namespace aligned with the user-assigned alpha-2 code elements in the ISO-3166-1 standard can be used as private-use namespace.
> It contains plenty of examples of how user-assigned code elements are used in the field, including other ISO standards, the UN, UNICODE, CAB/forum, and the IETF itself.
> This new version came about after fruitful discussions with peers inside and outside the IETF. Most discussions were productive. This has lead to the removal of the advice/example to use ZZ, as it was distracting from the point of the draft: these two-letter top level domains are available for private-use.

I have read this document and I like it.

There have been other proposals to make recommendations like this in the past that I have not been very enthusiastic about. The reason I like this draft-arends proposal more is that it neatly avoids the problem of who gets to make policy about this stuff by pointing out that suitable policies already exist and that hence the problem is already solved.

I also like the happy accident that the names on the user-assigned list are all pretty much equally arbitrary in every language in which US-ASCII labels have the potential to have semantic meaning. This seems better than choosing a label that is a recognisable word in some languages but not others.

I have two suggestions for the document. I have some doubt about the second suggestion, but the first one seems definitely great. :-)

1. While this document currently includes instructions to the IANA that could be viewed as specifying TLD naming policy, it might be possible to avoid that particular hidden foot-operated explosive device with some re-wording.

This document could simply make the observation that since existing ccTLD label policy is to defer completely to ISO-3166 alpha-2 (citation needed) and since ISO-3166 alpha-2 includes user-assigned codes that will never be assigned to a territory (citation needed) then it is consistent with existing policies that those user-assigned codes will never be delegated from the root zone in the DNS and, for that reason, will never give rise to collisions with any future new TLD.

That would leave this document simply as a clarifying description of existing policy, instead of appearing to have ambitions to change or specify policy in the root zone (which is the kind of thing that ICANN is also plausibly responsible for). The consequence of that small change might be (is, I think) to make this document completely uncontroversial whilst preserving the core advice. No worm containment failure required.

2. The document stops short of making a clear recommendation in section 5. While the decision to anchor a private namespace in something that looks like a TLD is not necessarily the only plausible answer (I could anchor such a namespace at a domain that I reserve through normal domain registration, for example) the document *could* say "for applications that require a private namespace anchored at something that looks like a TLD, our recommendation is to do this".

It is possible, of course, that a clear recommendation might have an XKCD-927 effect (which would be unfortunate but perhaps tolerable) or no effect whatsoever (which at least seems benign, but which is also a bit useless). However, if the document is not going to make any clear recommendation, I'm not sure what the point of publishing it is.