IETF Logo Mail Archive

[DNSOP] Re: [Ext] Re: Call for Adoption: draft-davies-internal-tld

Jim Reid <jim@rfc1035.com> Wed, 23 April 2025 16:20 UTC

Return-Path: <jim@rfc1035.com>
X-Original-To: dnsop@mail2.ietf.org
Delivered-To: dnsop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 6892F201B5FF for <dnsop@mail2.ietf.org>; Wed, 23 Apr 2025 09:20:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tv2g7UXsuKS for <dnsop@mail2.ietf.org>; Wed, 23 Apr 2025 09:20:04 -0700 (PDT)
Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 96122201B1F6 for <dnsop@ietf.org>; Wed, 23 Apr 2025 09:19:37 -0700 (PDT)
Received: from smtpclient.apple (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 38E6E242109E; Wed, 23 Apr 2025 16:19:36 +0000 (UTC)
From: Jim Reid <jim@rfc1035.com>
Message-Id: <C78BB567-F6AA-445E-B587-A52E78A46D35@rfc1035.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_49881DC7-BD51-4D8E-B982-B8967D65AEEE"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\))
Date: Wed, 23 Apr 2025 17:19:35 +0100
In-Reply-To: <deee1bc6-da57-4c64-9093-584475dfb770@desec.io>
To: Peter Thomassen <peter=40desec.io@dmarc.ietf.org>
References: <m1u5h1G-0000LcC@stereo.hq.phicoh.net> <83666fd3-a51f-46e1-a5ac-0b9a46361480@desec.io> <49E3B1B6-E960-4A46-9C5D-2721FD57132D@depht.com> <3b5fb9e7-8a2b-420f-a2fb-dd6f6a0b88ae@isc.org> <89047B78-A2B1-43F2-A996-94DF1E90538A@depht.com> <cc84f69c-c349-4d91-b942-80221b564a9b@isc.org> <ac48e27d-479f-42f3-b87f-891220ef2fe8@app.fastmail.com> <BE721880-6254-48F4-9F91-567A99E0511B@icann.org> <m1u7asT-0000MtC@stereo.hq.phicoh.net> <deee1bc6-da57-4c64-9093-584475dfb770@desec.io>
X-Mailer: Apple Mail (2.3826.400.131.1.6)
Message-ID-Hash: 4IA7PCYWTTUMATDI6TX5VXWG3WIYWAEI
X-Message-ID-Hash: 4IA7PCYWTTUMATDI6TX5VXWG3WIYWAEI
X-MailFrom: jim@rfc1035.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: dnsop@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: [Ext] Re: Call for Adoption: draft-davies-internal-tld
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/KB23903Chc1ASVkWGm0vi0dJyyM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>


> On 23 Apr 2025, at 16:16, Peter Thomassen <peter=40desec.io@dmarc.ietf.org> wrote:
> 
> That said, I think it would still be a good idea to invoke the liaison and ask about ICANN's view on this (potential?) mistake, and how their definition of "delegation" (to NS? to registry?) plays into this. What's the process for such an interaction? 

I think that'll be a bad idea Peter. IMO it'll just create a lot of hot air and burn too many cycles on mostly pointless make-work: bickering over what its meant by "delegation" for instance. Or developing/extending process machinery that's unlikely to be used all that often.

The WG should be able to apply common sense and treat these SUDN requests on a case-by-case basis. Anything fancier can wait until the number and frequency of these requests justifies an exercise in process engineering.

v2.31.3 | Report a Bug | By Email | System Status