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

Paul Vixie <paul@redbarn.org> Sat, 13 June 2020 23:56 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 07BEE3A0819; Sat, 13 Jun 2020 16:56:37 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_PASS=-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 qptctjFJAsKf; Sat, 13 Jun 2020 16:56:34 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A61303A07C7; Sat, 13 Jun 2020 16:56:34 -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 1C112B07D0; Sat, 13 Jun 2020 23:56:32 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: Tim Wicinski <tjw.ietf@gmail.com>, dnsop@ietf.org
Cc: dnsop <dnsop@ietf.org>, dnsop-chairs <dnsop-chairs@ietf.org>, Geoff Huston <gih@apnic.net>
Date: Sat, 13 Jun 2020 23:56:32 +0000
Message-ID: <4797913.7D3pEc4KDL@linux-9daj>
Organization: none
In-Reply-To: <8BF10121-CF4B-4341-BC40-F427A8F4B50A@apnic.net>
References: <CADyWQ+F=JA6fogcy_JGRJaZv=Hq52ozgmY5gmzfPm=1oHcJXKg@mail.gmail.com> <8BF10121-CF4B-4341-BC40-F427A8F4B50A@apnic.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/emRA8y8WOkrOfJcTrXYoNxPOuPI>
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: Sat, 13 Jun 2020 23:56:37 -0000

On Saturday, 13 June 2020 21:39:05 UTC Geoff Huston wrote:
> ...
> 
> I believe that the IETF passed responsibility for the determination of
> policy regarding the DNS namespace to what we now call ICANN some decades
> ago, and in line with that transfer of role and responsibility such
> discussions should take place within the open policy forums hosted by ICANN
> (however torturous and dysfunctional that may be), and accepting this
> document within the remit of the IETF DNSOP working group is contrary to
> this earlier IETF action. ...

i understand, but do not share, this point of view. ietf is where protocols 
come from, and dns is a protocol. early on, the decision of what top-level 
domains to create was made outside the ietf, but recorded by iana. later on, 
the iana became a functions contract, currently operated by what we now call 
icann, who then uses a global policy process to get the global economy's input 
on what top level domains to create.

it is for ietf to decide what to reserve directly with the iana, for the needs 
of protocol development. that sets the starting conditions for what icann can 
work with (everything not reserved by the ietf).

we might imagine a new protocol, sdns, which had an extended presentation form 
compared to classic dns, and in which the old namespace was encapsulated under 
some new top level identifier (like .ietf or .iana), and which had a search 
list capability allowing names not found in the sdns namespace to be findable 
in the old namespace. none of this would depend on cooperation from iana, or 
from what we now call icann as the iana functions contractor.

protocol development creates identifier spaces, which have reserved 
identifiers. to me it makes perfect sense that ietf would develop new top 
level identifiers for dns, and instruct iana to reserve them. icann's role in 
that transaction would be as iana functions operator, and their policy 
development process for other parts of the icann corporate mission would not 
be invoked.

i support adoption, and will review.

-- 
Paul