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

David Conrad <drc@virtualized.org> Tue, 02 August 2022 17:01 UTC

Return-Path: <drc@virtualized.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 0B829C13C518 for <dnsop@ietfa.amsl.com>; Tue, 2 Aug 2022 10:01:13 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=virtualized-org.20210112.gappssmtp.com
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 t6r1qqhxAUPC for <dnsop@ietfa.amsl.com>; Tue, 2 Aug 2022 10:01:11 -0700 (PDT)
Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 32103C147930 for <dnsop@ietf.org>; Tue, 2 Aug 2022 10:01:11 -0700 (PDT)
Received: by mail-qv1-xf2a.google.com with SMTP id ct13so7458640qvb.9 for <dnsop@ietf.org>; Tue, 02 Aug 2022 10:01:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=virtualized-org.20210112.gappssmtp.com; s=20210112; h=to:references:message-id:cc:date:in-reply-to:from:subject :mime-version:from:to:cc; bh=JvkTv/Sp7cqgARdDzR6XXheV/lfqShSdWkc76WxuIVk=; b=LRnr93Vhj3iEITAPxTwXtDB+pDdwsVZaxO7C6etkboX+fL4Ylv1mbYHHusW1Zg1jzf N3jD5YOvzFoclypq4O99mJi80pUd8pqC6D5G0DFIF0FMhvy+0/nmYXMYQXlwdoerDpba JFtZ2BiQe8KgsMArFIkt4J35IrBrFxAvom1ZkKO8Jvmv1Z3hF9zYuWFmvaK6pNHU0NRZ ulYwxbASFWFlp1c+5ekfT+lA/jYS5hbBCqXgsLqk8iWWpxUMfvD1IBC3Ya//SVHSNE1S l2GTYS5pmFQkkSYEwzDbGp+4TTSkinqwDu24QUXBooMmcJul9CT/OnHjUasuBr5+KYUp rseQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:cc:date:in-reply-to:from:subject :mime-version:x-gm-message-state:from:to:cc; bh=JvkTv/Sp7cqgARdDzR6XXheV/lfqShSdWkc76WxuIVk=; b=GFEuUDkmOsvA67A0YNWimGAIKn4rjlKX/LBLiZMUIvqKfMEVQPD/3sdmiz/t3xzlhN 9dhQRI455A71Sy6YmvJ9L9Pmxux714VErGI+aiS5l+ZpbcIIC8pB/rwBeoiGd1IZCMHZ GP8bqg6IJ7V0z5ulpSyIaNljDZ6zndBtoYrwqrbTHIykiOVrNHV+QhdLjXUxrmDs1JQH Goi8RX0DnIAcxoKAqVac1q8Un8ePb6I84jATZ7bKZsSkutWhFkSShQ3GRCJmAkHWp7PZ KXJ4gSEBbW17I1zCGvp4nVvsql+prf2KcwVYp19u4AE4Y5Q0JGNL5DQNjgIC9U0GpUhM /p+Q==
X-Gm-Message-State: ACgBeo2gJAR1MSoKvrl+O9a0r5betuIORQf49wz3QiJZSZWMC9S7jDwB MFAw/FzmX+Cf5IPiO3uKdC3ZRw==
X-Google-Smtp-Source: AA6agR6KtM/rpx+rQCfo8PQl/5pcd/u+6FaVaDpefqAK88zgPq74TDDJn4EYd6gCh3u+dvLsxLB6/w==
X-Received: by 2002:a05:6214:e41:b0:473:915c:3efe with SMTP id o1-20020a0562140e4100b00473915c3efemr18951808qvc.10.1659459670179; Tue, 02 Aug 2022 10:01:10 -0700 (PDT)
Received: from smtpclient.apple ([12.25.173.26]) by smtp.gmail.com with ESMTPSA id x22-20020a05622a001600b0033d1ac2517esm175908qtw.64.2022.08.02.10.01.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Aug 2022 10:01:08 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_42001984-A9CA-4777-878B-F1E61BE78530"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: David Conrad <drc@virtualized.org>
In-Reply-To: <248B0DC8-F27A-4958-BA76-E6941B4126B8@apnic.net>
Date: Tue, 02 Aug 2022 10:01:06 -0700
Cc: "Independent Submissions Editor (Eliot Lear)" <rfc-ise@rfc-editor.org>, Joe Abley <jabley@hopcount.ca>, "dnsop@ietf.org" <dnsop@ietf.org>
X-Mailbutler-Message-Id: 7CC80808-BE54-4A50-9835-35A4AE6CA4B6
Message-Id: <2FD0DB21-B5CC-4498-BC72-26D2B2B21E71@virtualized.org>
References: <402f6c32-08bb-b046-64f6-2ebbb42abf70@rfc-editor.org> <E390AC10-02E2-408B-84C0-2B93F49BBEC3@hopcount.ca> <e59b1998-e30d-1bdc-cec3-56def2920b88@rfc-editor.org> <248B0DC8-F27A-4958-BA76-E6941B4126B8@apnic.net>
To: Geoff Huston <gih@apnic.net>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/tbN2O33Mrn7lRTBYgeme2TLAKLM>
Subject: Re: [DNSOP] draft-schanzen-gns and draft-ietf-dnsop-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: Tue, 02 Aug 2022 17:01:13 -0000

Hi,

On Aug 2, 2022, at 8:00 AM, Geoff Huston <gih@apnic.net> wrote:
>> I came to this group because of concerns that Warren raised, and because the draft sits before me.  I have reviewed what discussion I could find in the logs relating to Warren's draft, which amounts to either (a) this is ICANN's problem or (b) there is nobody willing to make use of the space.  Please feel free to inform me if I have missed something.
>> 
>> Regarding (a), that is not my interpretation of RFC 6761.  RFC 6761 drops special use domains firmly in the lap of the IETF, which is presumably why Warren brought his draft here and why I came here and didn't go to ICANN.  Regarding (b), we have someone here willing to at least have the conversation.
> 
> ICANN was not created out of thin air. It was created in part as an admission by the IETF at the time that the dimensions of the discussions relating to name spaces, alternate roots, name space expansion and such was far broader than the IETF at the time and the discussions on this topics necessitated a host and a community that was not isomorphic to the IETF.
> 
> Regarding your interpretation of RFC6761 and your conclusion, as ISE, that this is not matter for ICANN, I respectfully disagree with the ISE here, and I believe that such matters are well beyond the more limited scope and remit of the IETF and the considerations of some 20 years ago in this space remain relevant today.

I agree with Geoff.

I’ll be a bit more blunt: RFC 6761 was a mistake in a number of different ways that I won’t bother going into here. There is a reason its application has been halted. The idea that it “drops special use domains firmly in the lap of the IETF” presupposes a clear definition of “special use domains” that can be distinguished at a namespace as opposed to a protocol level. Unfortunately, distinguishing at the namespace level is unappealing as it would necessarily impact users (e.g, force them to use a “_”). That leaves partitioning the namespace. However, partitioning the singular domain name space involves non-technical policy considerations which is exactly why ICANN was created.

There are many reasons why the ICANN gTLD process is so Byzantine and painful. One of those reasons is because trying to distinguish why one group should get a chunk of the namespace and another shouldn’t is a very hard, almost always non-technical problem. The IETF has not shown a whole lot of interest or skill in dealing with those sorts of problems, something I believe RFC 2860 recognized.

To me, the right answer here is as obvious as it is painful: requests for namespace partitioning (i.e., creation of top-level domains) should be punted over to ICANN (regardless of the protocol underlying the implementation of that namespace).  If a particular usage of the namespace doesn’t fit the model ICANN has come up with, it’s indicative a brokenness/failure within ICANN, not justification for bypassing the clear intent of RFC 2860. There has been a reluctance/inability on the part of both ICANN and the IETF to deal with this for more than 20 years. Given the proliferation of “alternative roots”, I don’t think this is desirable or even tenable.

Regards,
-drc