[dns-at-ietf] Some observations on managing DNS activity at the IETF

Andrew Sullivan <ajs@anvilwalrusden.com> Wed, 26 November 2025 13:05 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dns-at-ietf@mail2.ietf.org
Delivered-To: dns-at-ietf@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 077C8910861F for <dns-at-ietf@mail2.ietf.org>; Wed, 26 Nov 2025 05:05:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b="KS1UJd27"; dkim=pass (1024-bit key) header.d=yitter.info header.b="Gzlts33S"
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 KhGPkfH-EB5Z for <dns-at-ietf@mail2.ietf.org>; Wed, 26 Nov 2025 05:05:18 -0800 (PST)
Received: from mx5.yitter.info (mx5.yitter.info [159.203.31.152]) (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 C8445910861A for <dns-at-ietf@ietf.org>; Wed, 26 Nov 2025 05:05:18 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx5.yitter.info (Postfix) with ESMTP id 403ECBD52E for <dns-at-ietf@ietf.org>; Wed, 26 Nov 2025 13:04:42 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1764162282; bh=KQgilPfqZLPPYUlEZjoOevd3k5T1rwUAbWXapgDhiiM=; h=Date:From:To:Subject:From; b=KS1UJd27S6XptWvvBuR+emtQ5yaGvAZk5uHaBMrUP+/WArqpS+chVT2fv+csaiQYQ WKcD00J51YDVStV87NxCagtjM7dN6FQ/pHfURDKttmbkdP7qYQELZdBw3t6oVdQkBb f26VgMQaDkuFwC+o9c9ZU7zZaxaH4U8ahspNp1DU=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx5.yitter.info ([127.0.0.1]) by localhost (mx5.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRon0cDDBvVM for <dns-at-ietf@ietf.org>; Wed, 26 Nov 2025 13:04:39 +0000 (UTC)
Date: Wed, 26 Nov 2025 08:04:37 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1764162279; bh=KQgilPfqZLPPYUlEZjoOevd3k5T1rwUAbWXapgDhiiM=; h=Date:From:To:Subject:From; b=Gzlts33Saabz14WyIic3pvjX7AOwjnqMeyqB1yFyGmVCFu7DWKArTgQJkvkzImkU7 OObR6VALqMzFiTCNHmMzHI/9My7+knp5/0Nrjq/6cUJPUv1wNJo6x6tpLHQOYtQmlU T4rlaht7zBFTB5soN7/vA/b+kCtohq9SqT/MKa2w=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dns-at-ietf@ietf.org
Message-ID: <yg55ivd2jt4dqvg6dqjq5t7fzjtj5656jplv7g4nduqynremf5@yivom4oi7n4a>
Mail-Followup-To: dns-at-ietf@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: QSZR77OOK7J6OEDCXZMNRL4MS3B2PFDS
X-Message-ID-Hash: QSZR77OOK7J6OEDCXZMNRL4MS3B2PFDS
X-MailFrom: ajs@anvilwalrusden.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [dns-at-ietf] Some observations on managing DNS activity at the IETF
List-Id: "This list is to discuss the structure of DNS work in the IETF, and DNSOP in particular." <dns-at-ietf.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-at-ietf/YvUQ4U-X_qah7cdWaHIahH4XYsw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-at-ietf>
List-Help: <mailto:dns-at-ietf-request@ietf.org?subject=help>
List-Owner: <mailto:dns-at-ietf-owner@ietf.org>
List-Post: <mailto:dns-at-ietf@ietf.org>
List-Subscribe: <mailto:dns-at-ietf-join@ietf.org>
List-Unsubscribe: <mailto:dns-at-ietf-leave@ietf.org>

Dear friends,

(I don't say "colleagues" since I'm not much involved in the IETF any more and don't think that is likely to change soon.)

I have noted with some interest the creation of this mailing list and the discussion that has happened on it so far (which I read in the archives).  It occurs to me that reminding people of some history and noting some questions might be useful to the purposes of this list.  I am going to try to avoid offering an opinion about what should happen on the grounds that I'm pretty unlikely to be part of whatever follows from the decisions, so my opinion about the best course of action is less valuable than the opinions of others who are likely to hang around.  I should note that I'm not subscribed to this list and don't currently plan to subscribe, so if you have a clarification question for me you'll need to copy me.

It is worth remembering that the IETF used to have a protocol-maintenance WG (DNSEXT) and an operations and management WG (DNSOP).  I was one of the chairs of DNSEXT at the time we decided to wind it down.  My view (I won't speak for my then-co-chair) was that we were unable to get anything like the level of attention and energy to complete work that was needed.  Given the large number of people who came to the room when we had an IETF meeting, one would have expected a certain degree of review activity, suggestions for document improvements, and so forth.  Alas, that was not our experience: many drafts went ahead with the barest minimum number of reviews, and many of those were extracted by begging.  Worse, the main reason for the continued existence of DNSEXT (the reason why I was appointed co-chair) was significant work contemplated to do (approximately) for the DNS protocol documents what 2821/2822 (and following) did for email. That work really didn't get out of the "contemplation" phase.

It is therefore with a little bit of concern that I note the suggestion in the archives to split DNSOP in two to do something like protocol maintenance and operations and management work.  I don't know whether there is evidence that the result will be different this time, but I think there is one bit of evidence to the contrary: DNSOP has had a fairly long history of the same basic problem of low progress on documents, with a lengthening queue without a whole lot of movement on even fairly simple items.  People definitely show up in the room at meetings.  Every now and then there is a flurry of activity on the list.  And people definitely seem keen to have DNSOP adopt drafts.  But it appears to me that drafts do not move forward, at least without fairly significant nagging from chairs.

There has been an observation on the list that there are venues outside the IETF that are undertaking significant discussions about DNS.  It strikes me that it might be worth asking whether this duplication of effort is entirely necessary, and whether the other activities represent an opportunity for the IETF to reduce its load.  If that were an approach to take, then what is undoubtedly necessary is some kind of DNS maintenance-like WG that allows for basic maintenance of the protocol, on the principle that by and large the protocol is as done as it needs to be.  Implicitly, this accepts that most novel uses of the DNS are going to use TXT records, possibly with a bunch of subfields, and with significant work and deployment already done (so there will be resistance to a new RRTYPE).  This is hardly new: the history of SPF, DKIM, and so forth all suggest that that's the way things are likely to happen; and anyway, new RRTYPEs don't really need a WG anyway.

The additional evidence here is that work going on in other WGs that require working with the DNS appears too often to do without "DNS experts".  One reason for this is supposedly because (if I read the archives correctly -- I simply don't know the facts) the DNSOP participants seem not to want to go to engage with the other WGs in question.  If that is true, then the idea that the IETF is the best place to be doing such work is at least up for debate: the whole point of doing such things in the IETF is supposed to be the broad co-operation.  If instead the IETF becomes the place where work involving the DNS goes to slow down, it brings discredit to the IETF community and frustrates people with live plans.  (Again, I am not claiming this is the state of affairs: I simply don't know.  I'm just reflecting on that claim in light of past experiences I have.)

So, as I said, I don't have any real opinion about how things ought to proceed.  But I do think the IETF ought to ask itself some pointed questions:

	1.  If a dual-WG arrangement is to be tried, what reasons are there to suppose something different will happen as compared to last time?

	2.  Is the DNS community within the IETF context healthy and viable?  Does the IETF really have the attention to spend on the topic to the extent it is committed to spend, given that there may be some significant duplication of effort with other Internet operational communities?

	3.  Does the relative success of WGs that are not catch-all DNS groups, but focussed groups for particular efforts, suggest a model for the future that reduces the importance of large, catch-all WGs for the DNS?

Finally, I will observe that long-running WGs at the IETF have, in my opinion, a recurring problem of low energy and low document progress even as the numbers in the room at meetings suggest a viable WG.  I have an idea (it'd maybe be a hypothesis if I had any idea how to test it) that this is because long-running WGs come to have a function as being the reason people "have to" go to an IETF meeting, which creates a perverse incentive for the WG not to complete its work because it means people don't have a reason to go to the IETF meetings.  (This is not an accusation of "tourism" or anything like that; but a recognition that, especially these days, corporate travel budgets are tight and it becomes something of a chore to justify travelling around the world.  A WG meeting close to one's important functions within one's employer seems likely to provide the reason, but reasons like that might be choking out important work that the IETF (overall) could be doing instead.

I hope these ruminations are helpful.  If not, feel free to dispose of them as would be appropriate :-)

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com