Community considerations on DNS WG structures at IETF
draft-hardaker-dns-wgs-at-ietf-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Wes Hardaker , Lars-Johan Liman , Joe Abley | ||
| Last updated | 2026-03-30 | ||
| RFC stream | (None) | ||
| Intended RFC status | Informational | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | Mohamed Boucadair | ||
| Send notices to | (None) |
draft-hardaker-dns-wgs-at-ietf-03
Domain Name System W. Hardaker
Internet-Draft Google, Inc.
Intended status: Informational L. Liman
Expires: 1 October 2026 Netnod
J. Abley
Cloudflare
30 March 2026
Community considerations on DNS WG structures at IETF
draft-hardaker-dns-wgs-at-ietf-03
Abstract
There has been an increasing level of discussion within the IETF
about the best Working Group (WG) structures for handling the wide
array of DNS work being conducted within the IETF. Wes Hardaker was
asked to gather information from the community at large through
email, hallway discussions, and meetings and create a small team to
discuss potential structural changes to be shared with the community.
This document is the result of that effort.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-hardaker-dns-wgs-at-ietf/.
Discussion of this document takes place on the Domain Name System
Working Group mailing list (mailto:ietf@ietf.org), which is archived
at https://mailarchive.ietf.org/arch/browse/ietf/. Subscribe at
https://www.ietf.org/mailman/listinfo/ietf/.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Hardaker, et al. Expires 1 October 2026 [Page 1]
Internet-Draft Community considerations on DNS WGs March 2026
This Internet-Draft will expire on 1 October 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Working Group Names Used In This Document . . . . . . . . 3
2. Findings . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Observed Commonality in Feedback Received . . . . . . . . 4
2.2. Feedback That Did Not Achieve Common Agreement . . . . . 5
3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Example Dispatch Scenarios . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Original project announcement . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
There has been an increasing level of discussion within the IETF
about the best Working Group (WG) structures for handling the wide
array of DNS work being conducted within the IETF. Wes Hardaker was
asked to gather information from the community at large through
email, hallway discussions, and meetings and create a small team to
discuss potential structural changes to be shared with the community.
See Appendix "Original project announcement" for the announcement.
This document is the result of that effort.
The DNS@IETF recommendation small team (which consisted of Wes
Hardaker, Joe Abley and Lars-Johan Liman) reviewed all materials
collected between September 2025 through March 2026 about what
respondents thought about the effectiveness of the DNS related WGs
within the IETF. Material reviewed (118 pages) included relevant
e-mail (both public and private), notes taken during discussions, and
Hardaker, et al. Expires 1 October 2026 [Page 2]
Internet-Draft Community considerations on DNS WGs March 2026
WG/Area recordings from IETF meeting proceeding archives. After
review, the small team met multiple times in early 2026 to extract
any commonality among the expressed opinions and developed
recommendations based on them to offer the DNS community and the
IESG.
This document describes the small team’s findings (Section 2), their
derived recommendations (Section 3) and topics where the team did not
find sufficient commonality within the collected opinions
(Section 2.2).
1.1. Working Group Names Used In This Document
The team use a few new working group names below, but recognize both
these recommendations and these not-yet-existing working group names
are subject to change and thus should be considered placeholders. It
will be up to the IESG and the community to decide what groups and
their names should actually be used. These are terse definitions
that are further defined in the rest of the document.
* DNSPROT: A potential new working group dedicated to the
development of the DNS protocol features itself.
* DNSDEP: A working group dedicated to developing documents related
to the deployment of the DNS protocol. Note that in discussions,
some believe this should be called DNSOP still or potentially
DNSOPS.
* DNSDISPATCH: A working group dedicated to recommending where new
DNS proposals should be directed for potential adoption.
* DNSOP: the still existing (in March 2026) DNSOP working group.
Note that at the time this writing the current charter of the
DNSOP working group includes all of the tasks described above in
the DNSPROT, DNSDEP and DNSDISPATCH group.
2. Findings
The small team found some clear points within the collected opinions.
These findings are listed here and were later distilled into
recommendations (Section 3). Note that items listed here do not
necessarily indicate unanimous agreement, but do reflect a
significant majority among the opinions. Note that some of the
concerns listed below are at least partially addressed later in the
recommendations section.
Hardaker, et al. Expires 1 October 2026 [Page 3]
Internet-Draft Community considerations on DNS WGs March 2026
2.1. Observed Commonality in Feedback Received
* A separated DNSDISPATCH mechanism would be beneficial for helping
decide where and how new work should be conducted.
- Working groups can then concentrate on the work they are
chartered for.
- DNSDISPATCH followers know where to track new works of
interest.
- A downside of this approach could be a potential slow down of
new work, and an increase in agenda time in face-to-face IETF
meetings.
* It would help DNS engineers within the IETF to create two groups:
one for operations and one for protocol development.
- One group should concentrate on operations and hopefully
streamline the process to get these from drafts to RFCs.
- One group should concentrate on longer term protocol
development efforts, potentially in a higher-volume discussion.
- An issue mentioned with splitting of work into separate groups
is that some people would need to attend and participate in
both groups anyway. Though this is clear for some IETF
participants, there were indications it doesn’t apply to
everyone. Some participants may also be able to concentrate
more centrally on one, and merely watch the other.
* No structure can solve the "human problems".
- It will still be up to the area directors and chairs to deal
with common management issues and disagreements, for example.
- This includes how and where work is handled in more nuanced
cases.
- WG chairs need to be supported in handling these situations.
- WG chairs MUST coordinate within their own groups and between
their group and other related groups. Collaboration needs to
occur between all DNS@IETF WGs and IESG Area Directors (ADs)
about all current DNS topics of concern.
* Narrowly chartered working groups are necessary for more
challenging development problems.
Hardaker, et al. Expires 1 October 2026 [Page 4]
Internet-Draft Community considerations on DNS WGs March 2026
- DELEG and ADD were two examples referred to in discussions and
comments, with DELEG being an especially agreed-upon example of
a body of work that needed a separated, dedicated working
group.
* We did not receive enough feedback indicating that the other DNS
groups not mentioned here, like DNSSD and REGEXT, need structural
modifications. Thus we have no findings related to these groups
and do not provide recommendations that affect them.
2.2. Feedback That Did Not Achieve Common Agreement
* Always requiring running code.
- Requiring running code before adoption had a wide set of
opinions with no commonality among them.
- Requiring running code before document publication had
generally more agreement, but opinions varied about whether
this was required for all types of documents.
- Based on this, we believe each group will need to make their
own decision on this matter.
* Where to develop BCP documentation is an open question.
- Some believe operational groups like DNS-OARC should drive BCP
development.
- However, there was general agreement that the publication of
BCPs should remain in the IETF to ensure multiple protocol
reference commonality remain within the IETF.
- It may be that interim meetings held in conjunction with
external conferences would be a good idea to better gather
input from network operators managing DNS infrastructure.
* Although a few people did suggest splitting the main DNS groups
into three or more groups, most of the feedback received indicated
that two primary groups would be sufficient. For example, some
IETF participants believe there should be a DNSAPP or similar
group focused on applications and protocols that make use of the
DNS protocol. Furthermore, some people offered opinions that more
than two would impose additional complications.
* There was general disagreement about whether or not to close the
existing DNSOP WG if new ones were formed, or whether it should be
rechartered in the process.
Hardaker, et al. Expires 1 October 2026 [Page 5]
Internet-Draft Community considerations on DNS WGs March 2026
- Some believed that a clean break would be beneficial to signal
the change in structure.
- Others believed that DNSOP was already the right name and there
was no need to change it, aside from narrowing its charter.
3. Recommendations
Based on the findings above (Section 2), the DNS@IETF small team
extrapolated information from discussions to derive a set of suitable
recommendations that the IESG ADs should consider:
* Create a new DNSPROT (DNS Protocol) or similar group for working
on protocol development and maintenance.
- This group should have a fairly wide charter that tasks it with
work on the DNS protocol itself.
- One potential recommendation for deciding whether things belong
in this group is whether or not the work was likely to develop
special processing rules.
- Documentation about protocol semantics should progress in
DNSPROT.
* Create a new DNSDEP (DNS Deployment) group for working on protocol
deployment and operational concerns.
- This group should have a fairly wide charter that tasks it with
work that doesn’t require special processing rules, needs
algorithms or other simple IANA actions, or are BCPs that
document existing behaviors.
- Work should include guidance documents about "How you use the
protocol". Examples such as algorithm rollover guidance, BCPs,
split horizon considerations.
* Create a DNSDISPATCH working group for providing guidance to
authors about where new DNS work should be conducted.
- This will alleviate the current DNSOP WG from needing to
fulfill this role.
Hardaker, et al. Expires 1 October 2026 [Page 6]
Internet-Draft Community considerations on DNS WGs March 2026
- To avoid introducing delays and agenda constraints (as
discussed in Section 2), this group should conduct its work
almost entirely over a mailing list. Only the more complex or
difficult cases should require interim or, worst case, in-
person meeting time. Ideally, in-person meetings should be
rare.
- A significant portion of submissions to DNSDISPTACH can likely
be handled quickly and efficiently.
- DNSDISPATCH can recommend dispatching work to any areas of the
IETF, including but not limited to DNSPROT, DNSDEP, AD-
sponsored, another-WG, a BOF, or the ISE.
- The DNSDISPATCH chairs should require that documents clearly
articulate the problem space and proposed solution before
consideration.
- DNSDISPATCH may decline to provide a recommendation for
documents. This would include documents not within scope of
the IETF or were not sufficiently mature to understand the
problem or solution space, for example.
- Chairs of the DNSDISPATCH group need to be strict in managing,
enforcing and carrying out its objective.
- The DNSDISPATCH group will not prioritize work within the other
groups, and its dispatch decisions cannot result in automatic
adoption. Each group will continue to follow its own processes
for formal adoption.
- The DNS directorate will be a resource available to the
DNSDISPATCH working group, just as it is available to other
working groups.
- The DNSDISPATCH group might use a pool of willing shepherds to
assist the chairs and authors with process related help for
incoming documents.
- The dispatch group will make informed recommendations to
authors and document where they should take their work.
o The output of a dispatch discussion should include a short
shepherd write up (perhaps a paragraph in length)
o These should be light weight write ups that are sent to the
mailing list for archiving. This should not require
datatracker changes.
Hardaker, et al. Expires 1 October 2026 [Page 7]
Internet-Draft Community considerations on DNS WGs March 2026
o DNSDISPATCH chairs should create a light template as a
boiler plate to be used by most cases.
- DNS WGs MAY require, in their charter, that new work proposals
first get a dispatch suggestion before being considered in
their WG.
- After a dispatch recommendation, document authors are
encouraged to follow the recommendation and approach the
relevant WG chairs, AD, ISE, etc with a follow-on request
(including but not limited to adoption requests).
- The chairs of the DNSDISPATCH group should work closely with
the chairs of the other groups. They may need to work together
for handling more difficult topics and to collaborate on advice
or questions for the DNSDISPATCH WG participants.
* Group management may be significantly different in each of these
groups.
- With an effective split in functionality, each group may choose
to have different forms of execution, meeting, progression, and
publication requirement strategies.
- For example, some groups may require running code, while others
may not.
* Documents may occasionally (hopefully rarely) need to move after
being dispatched when the problem or solution scope changes during
its development and refinement.
- For example, problems that become large may need to move to an
entirely new group.
- Sometimes, however, the dispatch and adoption location decision
might have been wrong, but might as well stay in the current
group.
- The area director and WG chairs will need to handle this (rare)
problem on a case by case basis.
3.1. Example Dispatch Scenarios
The DNS@IETF small team recognized that some examples might be
helpful in better understanding how the envisioned DNSDISPATCH group
might process incoming work. As such, we offer the following three
example scenarios that highlight how dispatch workflows might happen.
Hardaker, et al. Expires 1 October 2026 [Page 8]
Internet-Draft Community considerations on DNS WGs March 2026
1. Maxwell Coulomb writes a document that describes a new way that
DNS can be used by DHCP clients. They take this document to
DNSDISPATCH where, after some discussion (including references to
other discussions in DHCP working groups), the chairs post a
recommendation drawn from consensus to the list saying that in
their opinion the best DNS working group for this document would
be DNSDEP. Maxwell then approaches the DNSDEP chairs by sending
a message to the chairs that includes a mailing list archive link
to the DNSDISPATCH recommendation. The chairs review and decide
that this is a good candidate document for DNSDEP and send a
request for comment to the DNSDEP mailing list.
2. Marie Ampère writes a document that describes a new protocol for
encoding video into linked, short ASCII messages, including
examples of how this allows video to be published in the DNS.
They take this document to DNSDISPATCH where, after some
discussion, the chairs post a recommendation that this is not a
good fit for any DNS working group since it does not really
represent DNS-specific work. Thus, the chairs draw a consensus
that a dispatch recommendation will not be provided.
3. Marmaduke Nxdomain writes a document in response to some
operational problems that have been discussed in another forum,
proposing some changes to DNS best practices to avoid such
failures. After some discussion, including references to
presentations and related observations surfaced in a recent DNS-
OARC meeting, the chairs decide that this is a good candidate
document for DNSDEP but that the document would benefit from some
restructuring and rewriting first so that the substantive issues
can be better considered in the working group. The chairs
solicit a volunteer shepherd to help Marmaduke with the next
steps. The shepherd helps Marmaduke update the text and later
discuss the document with the DNSDEP chairs, including a
reference to the DISDISPATCH recommendation.
4. Security Considerations
None
5. IANA Considerations
None
Hardaker, et al. Expires 1 October 2026 [Page 9]
Internet-Draft Community considerations on DNS WGs March 2026
Acknowledgments
Wes greatly thanks the small team members (Lars-Johan Liman and Joe
Abley) he corralled into helping him consume all of the review
content, and for the insights they brought to the discussion about
this problem space.
A significant number of people offered their opinions on this subject
and we greatly appreciate everyone's time, energy and desire to help
the IETF be as efficient as possible in the DNS space.
Original project announcement
The following text is the announcement about this opinion collection
project that was sent to various DNS IETF lists on 2025-10-06 by
Mohamed Boucadair in his role as the opsarea AD.
``` text
From: mohamed.boucadair@orange.com Subject: Kick-off DNS work
structure consultation Date: Mon, 06 October 2025 07:49 UTC
Hi DNSOP, all, (+ all concerned WGs: opsawg, intarea, deleg, dnssd,
add, dconn, regext)
Background
As you know, DNS-related activities in the IETF are wide, affecting
many other protocols within the IETF's standardization efforts.
Because of this, the DNS and its adjacent work is carried out in a
wide number of WGs and even areas (INT, OPS, ART).
Currently, DNSOP is acting as the central hub for much of the core
DNS work and has been for the past decade or more (and prior to that
in DNSEXT as well). But, the full history of the slowly evolving
structure of the DNS related WGs is beyond the scope of this message
(although certainly the lessons learned from the changing structure
over time remain important to consider).
Hardaker, et al. Expires 1 October 2026 [Page 10]
Internet-Draft Community considerations on DNS WGs March 2026
Recently there has been a flurry of hallway discussions about whether
the current DNS-related WGs structures are working as efficiently as
possible, and whether it is time to make some changes about where
recommended DNS related work gets dispatched to and subsequently
developed in. It may be that change is needed. It may be that no
change is needed. However, it has become clear that a discussion
needs to happen, and the results of that community discussion should
drive any change to be implemented. See also the provisions about
this discussion in the recent DNSOP Charter 1
(https://datatracker.ietf.org/doc/charter-ietf-dnsop/).
As indicated in my message 2 (https://mailarchive.ietf.org/arch/msg/
dnsop/9aztqcxfpgCEkhQT3LGxkWuMui8/), and now that the first
intermediate DNSOP chartering step is done, we want to hear from
everyone about what is working, and what is not, with the current
structure of DNS WGs. What are the requirements for creating the
most optimal work environment? Specifically, should the current
DNSOP structure be maintained, modified, etc.?
Mission
The main goals of this effort are as follows:
* Provide an overview of current IETF DNS landscape & interactions
* List issues/features with the current work structure
* Propose options to soften/mitigate the issues
* Sketch a transition plan
* Propose Charter(s) (New and/or Updates to existing ones)
Task leader, team, and Call for Feedback
In order to avoid impacting ongoing DNSOP work and given the load the
DNSOP Chairs already experience, I decided that this discussion is
better moderated by other community members than the DNSOP WG Chairs.
I'm delighted to announce that Wes Hardaker has agreed to collect
information from the community to help me, other ADs/IESG decide what
the best path forward is.
Wes and a small team will gather the thoughts and opinions of those
working on the DNS within the IETF and distill them down to a set of
recommendations for the IESG about whether the community believes
that structural changes are needed or not and, if so, to what
existing or new charters.
Hardaker, et al. Expires 1 October 2026 [Page 11]
Internet-Draft Community considerations on DNS WGs March 2026
To accomplish this, we need help from the community. Specifically,
we want feedback from everyone with an opinion on the subject
(including from those who think "everything is fine as is").
Below is provided a list of sample questions that are worth
considering (thanks Wes for the inputs), but opinions of any sort on
the subject are welcome. Note that though Wes has his own opinions,
he intends to only collect information from the community and will
only respond with an acknowledgment and maybe follow on questions, if
needed. Wes is willing to meet with anyone wanting to discuss this
during IETF#124 in person or over a virtual meeting before hand.
After thoughts, opinions, and suggestions are collected from the
community, Wes will be convening a small discussion team of
interested parties to help review the collected material. If you're
interested in helping on the review and recommendation team, please
let Wes know. Responsible ADs, with Wes help, will decide on the
small team membership later this year.
A timeline is included below detailing the course of events over the
next 6 months.
Mailing List to collect feedback & discuss
A new mailing is created to collect public opinions and discussion:
dns-at-ietf@ietf.orgdns-at-ietf@ietf.org (mailto:dns-at-
ietf@ietf.org).
If you have opinions you don't want to share publicly, please send
them to dns-structure-anon@hardakers.netdns-structure-
anon@hardakers.net (mailto:dns-structure-anon@hardakers.net) or to me
and Wes or only to me and I will anonymize them before bringing them
to the discussion team.
Information to be gathered
* How do we deal with the quantity of work that approaches DNSOP or
similar?
* Is one overarching group like DNSOP good, or do we need an ops/
protocol split like DNSOP and DNSEXT were in the past
- and how do we ensure WGs/Chairs communicate and collaborate
efficiently?
* What is the right combination of operational vs protocol
maintenance group(s)?
Hardaker, et al. Expires 1 October 2026 [Page 12]
Internet-Draft Community considerations on DNS WGs March 2026
* How to make sure that new work takes into account operational and
deployment considerations?
* How do we dispatch new work coming into the IETF related to the
DNS protocol?
- DNSOP did this for the past few years.
- Should small, contained proposals generally be dispatched to
OPSAWG or similar?
- Do we need a DNSDISPATCH group or leverage DISPATCH WG?
- What is the right balance between a bunch of small groups vs
one or a couple larger ones?
- How to address different problem spaces and attract interested
people?
- What is the overhead on the participants that need to attend
all these meetings?
- How do we ensure there is enough expertise available?
* How do we ensure that there is sufficient support for things that
are adopted (before they're adopted)?
* Do we have an over-arching policy for requiring running code/
deployment(-promises) first, or is it per-WG?
* Is the current split between mDNS/EPP/RDAP/RPP, and full DNS
working well?
* What should change?
* What shouldn't change?
Timeline
Hardaker, et al. Expires 1 October 2026 [Page 13]
Internet-Draft Community considerations on DNS WGs March 2026
+=============================================+===============+
| Event | Expected Ends |
+=============================================+===============+
| OPSAREA Session discussion | IETF#124 |
+---------------------------------------------+---------------+
| Collect feedback, suggestions, etc. | Nov 31 |
+---------------------------------------------+---------------+
| Analysis team craft recommendation(s) | Jan 2026 |
+---------------------------------------------+---------------+
| Team recommendations given to the community | Feb 2026 |
+---------------------------------------------+---------------+
| Analysis team meets with IESG members | Feb 2026 |
+---------------------------------------------+---------------+
| IESG announces plans | IETF#125 |
+---------------------------------------------+---------------+
Table 1
Thank you
Cheers, Med
```
Authors' Addresses
Wes Hardaker
Google, Inc.
Email: ietf@hardakers.net
Lars-Johan Liman
Netnod
Email: liman@netnod.se
Joe Abley
Cloudflare
Email: jabley@cloudflare.com
Hardaker, et al. Expires 1 October 2026 [Page 14]