IETF Logo Mail Archive

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

Harald Alvestrand <harald@alvestrand.no> Wed, 02 November 2022 08:40 UTC

Return-Path: <harald@alvestrand.no>
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 9503FC14CE44 for <dnsop@ietfa.amsl.com>; Wed, 2 Nov 2022 01:40:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.115
X-Spam-Level:
X-Spam-Status: No, score=-1.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no 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 uU1-S1nVEPMu for <dnsop@ietfa.amsl.com>; Wed, 2 Nov 2022 01:40:31 -0700 (PDT)
Received: from smtp.alvestrand.no (unknown [IPv6:2a01:4f9:c010:a44b::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BFF6C14F730 for <dnsop@ietf.org>; Wed, 2 Nov 2022 01:40:30 -0700 (PDT)
Received: from [192.168.3.110] (unknown [78.156.11.215]) by smtp.alvestrand.no (Postfix) with ESMTPSA id 52EF642EFC for <dnsop@ietf.org>; Wed, 2 Nov 2022 09:40:28 +0100 (CET)
Message-ID: <962c9485-9828-97dd-3f26-da0a9990e48f@alvestrand.no>
Date: Wed, 02 Nov 2022 09:40:27 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0
Content-Language: en-US
To: dnsop@ietf.org
References: <91abb9ac-9d3b-87bf-5639-174581d625fd@rfc-editor.org> <CAHbrMsBhEzVYx+qd+XA=X6Hy+gFxY8HF-hp8dtkxsXs9_5E7jw@mail.gmail.com>
From: Harald Alvestrand <harald@alvestrand.no>
In-Reply-To: <CAHbrMsBhEzVYx+qd+XA=X6Hy+gFxY8HF-hp8dtkxsXs9_5E7jw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/pZeAGr3oTqr4aWMPEU2V969C1lU>
Subject: Re: [DNSOP] 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: Wed, 02 Nov 2022 08:40:35 -0000

On 8/1/22 15:58, Ben Schwartz wrote:
> 
> 
> On Mon, Aug 1, 2022 at 8:32 AM Independent Submissions Editor (Eliot 
> Lear) <rfc-ise@rfc-editor.org <mailto:rfc-ise@rfc-editor.org>> wrote:
> ...
> 
>     I do agree with Martin that it would be helpful to have some
>     registration of names so that conflicts between name spaces can be
>     avoided.
> 
> I think we already have such a mechanism: ICANN.  People who want unique 
> registrations can acquire them via the existing ICANN and registry 
> processes.

Note: .myfancymechanism is not currently registerable, and the 
likelyhood is that it will take a few more years before it is. So new 
TLDs aren't a *current* solution to anything.

However, myfancymechanism.info (or whatever existing, operational TLD 
you prefer) is probably registerable, gives an unique prefix that is 
guaranteed to conflict with zero names in the DNS, and can be 
implemented without asking anyone.

The monetary cost of myfancymechanism.info above myfancymechanism.alt is 
on the order of 10 dollars; the 10 dollars also gives you guarantees 
about nobody else registering the same name in that space.

If "invoke the ICANN mechanisms" is an answer, then you're talking about 
second level domains - cheap, available, and with no conflicts.
But they're not "special".

> 
> I do not think that the IETF should introduce another mechanism for 
> third parties to acquire non-conflicting domain names.  Any such 
> mechanism would appear to compete with ICANN and the registries, without 
> the benefit of ICANN's extensive, hard-won process and governance.
> 
>     This would also encourage formal documentation of those projects.
> 
> This raises the interesting question of when use of non-ICANN 
> registration is appropriate.  I think RFC 6761 has the right answer: 
> "Standards Action or IESG Approval".  In other words, the IETF should 
> only be taking control of DNS namespaces that correspond to IETF 
> standards-track protocols, with an escape hatch via the IESG for special 
> situations.
> 
> Projects that need a non-ICANN domain name can seek IETF 
> standardization, which represents both formal documentation and 
> consensus that this use constitutes "part of the internet itself".
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

v2.23.0 | Report a Bug | By Email