IETF Logo Mail Archive

Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

Paul Vixie <paul@redbarn.org> Mon, 15 June 2020 22:14 UTC

Return-Path: <paul@redbarn.org>
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 2D7C03A0E6B for <dnsop@ietfa.amsl.com>; Mon, 15 Jun 2020 15:14:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 otsHGMiVa8bH for <dnsop@ietfa.amsl.com>; Mon, 15 Jun 2020 15:14:28 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1282D3A0E6C for <dnsop@ietf.org>; Mon, 15 Jun 2020 15:14:27 -0700 (PDT)
Received: from linux-9daj.localnet (dhcp-166.access.rits.tisf.net [24.104.150.166]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (1024 bits) server-digest SHA256) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 0AAF9B07D0; Mon, 15 Jun 2020 22:14:26 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: Tony Finch <dot@dotat.at>
Cc: John Levine <johnl@taugh.com>, dnsop <dnsop@ietf.org>, Tim Wicinski <tjw.ietf@gmail.com>, Brian Dickson <brian.peter.dickson@gmail.com>
Date: Mon, 15 Jun 2020 22:14:25 +0000
Message-ID: <1654175.cGJSrOA2b8@linux-9daj>
Organization: none
In-Reply-To: <alpine.DEB.2.20.2006152244380.28941@grey.csi.cam.ac.uk>
References: <CAH1iCiouFfMRYoREwhhTbQfnNserw3RVUPs8Pzc8CvNEhysYCw@mail.gmail.com> <2629924.6WoLTOkaPB@linux-9daj> <alpine.DEB.2.20.2006152244380.28941@grey.csi.cam.ac.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="nextPart6895351.ePUzWFbxRR"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/zlqD67CXYZN6MkrkCKhjNWz8OkQ>
Subject: Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld
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: Mon, 15 Jun 2020 22:14:31 -0000

On Monday, 15 June 2020 22:00:31 UTC Tony Finch wrote:
> Paul Vixie <paul@redbarn.org> wrote:
> > ...
> > 
> > reserving a corner of the namespace for decentralized operations makes
> > sense.
> There are perhaps three contexts that you might want a private namespace:
> 
> ...

there are perhaps more than three, and some might not be yet known by those who will 
want them. the reason why some part of the DNS namespace should be reserved in the 
form, "shall never be allocated by IANA", is not because we cannot think of a good 
enough and present cause why such a thing may be desirable.

setting a wildcard to point at AS112 makes perfect sense to me.

the document can remind that there's no uniqueness among unregistered domains, and 
that any name which might be partially or occasionally or eventually visible to a supplier, 
customer, partner, or acquirer should not be placed inside the reserved-name TLD due to 
unreachability and/or collision problems.

nothing should be centralized that does not have to be.

-- 
Paul

v2.23.0 | Report a Bug | By Email