Re: [DNSOP] [EXT] Re: draft-schanzen-gns and draft-ietf-dns-alt-tld

Jim Reid <jim@rfc1035.com> Mon, 08 August 2022 12:53 UTC

Return-Path: <jim@rfc1035.com>
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 52438C14F74E for <dnsop@ietfa.amsl.com>; Mon, 8 Aug 2022 05:53:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnot1UJ7MwZ7 for <dnsop@ietfa.amsl.com>; Mon, 8 Aug 2022 05:53:53 -0700 (PDT)
Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3808CC14F72F for <dnsop@ietf.org>; Mon, 8 Aug 2022 05:53:52 -0700 (PDT)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id E7D082421535; Mon, 8 Aug 2022 12:53:48 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Jim Reid <jim@rfc1035.com>
In-Reply-To: <c9031076-a424-887a-3c1d-b8beb0746f84@rfc-editor.org>
Date: Mon, 08 Aug 2022 13:53:48 +0100
Cc: dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DCAE818C-5128-4813-AD5F-C22471E36B57@rfc1035.com>
References: <59965e06-b0bc-5cff-98c8-4809b2d7ff39@huitema.net> <5F5F9843-078B-4716-8723-733DC2FF3726@hopcount.ca> <c9031076-a424-887a-3c1d-b8beb0746f84@rfc-editor.org>
To: "Independent Submissions Editor (Eliot Lear)" <rfc-ise@rfc-editor.org>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/F_8GxlF9SNblWpeFByTuGr-bnkc>
Subject: Re: [DNSOP] [EXT] Re: draft-schanzen-gns and draft-ietf-dns-alt-tld
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
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, 08 Aug 2022 12:53:54 -0000


> On 8 Aug 2022, at 11:16, Independent Submissions Editor (Eliot Lear) <rfc-ise@rfc-editor.org> wrote:
> 
> I caution against those approaches that would set such a high bar that they would require researchers to fork out hundreds of thousands of dollars on application fees alone plus who knows how much else for, as someone else wrote, an uncertain outcome.  They'll simply go elsewhere. That in itself would encourage squatting (or whatever you want to call it).  The benefits of avoiding squatting accrue not only to those researchers, but to those who use their technology, and others as well.

These are valid points Eliot and I agree with them - at least in principle. However the opposite PoV is equally valid IMO. Those who can’t/won’t go to ICANN to get their new TLD shouldn’t come to the IETF to get around ICANN’s policies. [Not that I’m suggesting this is what the GNS draft’s authors are doing.] IMO it’s the start of a very slippery slope if the IETF accommodates ad-hoc requests for “special” TLDs that are probably for ICANN to decide. Resolving those mutually exclsuive positions is why you get the big bucks Eliot, isn’t it? :-)

I suppose the question that needs to be asked is why on technical/engineering grounds MUST some new name space require a new TLD and why can’t that new name space be anchored elsewhere in the public DNS? OK, that’s two questions.

Perhaps we’re over-thinking this. Putting these magic strings into the root is a problem for both IETF and ICANN policies. So let’s not do that.

How about having an IANA registry of these experimental TLDs? Those strings don’t go in the root. And they don't get added to the IETF’s special use list and ICANN is still free to create these TLDs if/when they decide to create more. This hypothetical IANA registry would primarily be to avoid name collisions between those who are experimenting with new name spaces or running stuff inside them. For bonus points, entries in that registry have to be supported by (say) an Informational RFC. Those registry entries could also come with a health warning: if ICANN or the IETF one day creates your TLD for real, you’re out of luck.