[DNSOP] Re: Roman Danyliw's No Objection on charter-ietf-dnsop-04-00: (with COMMENT)

Jim Reid <jim@rfc1035.com> Tue, 24 June 2025 13:08 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 6D60038C1773; Tue, 24 Jun 2025 06:08:12 -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=ham 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 qLwluAkjUY14; Tue, 24 Jun 2025 06:08:11 -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 A66AA38C176C; Tue, 24 Jun 2025 06:08:11 -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 21CBE2420E4A; Tue, 24 Jun 2025 13:08:10 +0000 (UTC)
From: Jim Reid <jim@rfc1035.com>
Message-Id: <9955BC19-EB63-49A8-907D-CFC85FF4A797@rfc1035.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7FD324C2-4031-41A0-8A6F-A62C15882EE9"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.600.51.1.1\))
Date: Tue, 24 Jun 2025 14:08:08 +0100
In-Reply-To: <175075949076.538928.11087287399020246480@dt-datatracker-6754d69b7c-p2xd7>
To: Roman Danyliw <rdd@cert.org>
References: <175075949076.538928.11087287399020246480@dt-datatracker-6754d69b7c-p2xd7>
X-Mailer: Apple Mail (2.3826.600.51.1.1)
Message-ID-Hash: TTY3E6S2TRIUHOLOAG2LZXOTINJ4K4BW
X-Message-ID-Hash: TTY3E6S2TRIUHOLOAG2LZXOTINJ4K4BW
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: The IESG <iesg@ietf.org>, dnsop-chairs@ietf.org, dnsop@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: Roman Danyliw's No Objection on charter-ietf-dnsop-04-00: (with COMMENT)
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/7pRe3XEF8kN9dADaCbpK7OHDbFY>
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 24 Jun 2025, at 11:04, Roman Danyliw via Datatracker <noreply@ietf.org> wrote:
> 
> ** What DNS topics are out of scope in the WG?  As framed, it appears that
> nearly everything related to the “DNS protocol” would be in scope – BCPs for
> “DNS protocols (Sentence 1), documents from DNS operators (Sentence 2), and
> “maintenance, updates, and extensions to the DNS protocol” (Sentence 3).
> 
> In what way is this scope different than DPRIVE, DELEG, or DNSSD that are also
> defining elements of the "DNS protocol"?

Those WGs each have a narrowly defined scope Roman. The dnsop WG is (for now at least), the IETF home for just about anything else that's DNS related. I suppose the new charter could include text which says it won't tread on the toes of those WGs. Though since that's just a statement of the bleedin' obvious...

> ** Per “DNSOP provides a venue for DNS operators and other interested parties
> to engage in discussions around the operational requirements of DNS and publish
> documents”, what kind of documents are being published?

I-Ds and RFCs. Worst case, I suppose the WG might generate the occasional Liaison Statement though AFAIK it's never done that.

> ** Without specificity, isn’t this statement of “The WG will engage with
> relevant WGs and other appropriate organizations whenever collaboration is
> needed” true for any WG.  How does this shape the behavior of the WG?  Can it
> be more specific?

It's not clear how being more specific would help. It may well be counter-productive. DNS organisations outside the IETF come and go all the time. IMO it would not be helpful to enumerate these => rechartering every time a new one emerges or another goes away. Any collaboration is likely to be "That's an interesting idea you've got there. Please write up an I-D and bring it to the WG." or "can the WG provide clue?". This sort of thing doesn't need to go in the charter text: ie just say collaborate and don't get bogged down in the detail of what that might (not) be in practice.

I think the behaviour of the WG is unlikely to be influenced by collaboration with the likes of (say) ICANN or DNS-OARC. Besides, there's quite a lot of overlap in participants between them. In my experience it's mostly the same people talking about the same DNS-related stuff, albeit in different fora.