[DNSOP] Re: [Ext] draft WG chapter: 30/6/25

Michael De Roover <ietf@nixmagic.com> Sat, 31 May 2025 00:07 UTC

Return-Path: <ietf@nixmagic.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 35AA82F056A4 for <dnsop@mail2.ietf.org>; Fri, 30 May 2025 17:07:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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_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 yJXrHb9YeEqW for <dnsop@mail2.ietf.org>; Fri, 30 May 2025 17:07:21 -0700 (PDT)
Received: from nixmagic.com (e1.nixmagic.com [116.203.235.171]) by mail2.ietf.org (Postfix) with ESMTP id C5AB52F0569D for <dnsop@ietf.org>; Fri, 30 May 2025 17:07:21 -0700 (PDT)
Received: from workstation.vm.ideapad.lan (dhcp13.lan [192.168.10.213]) by nixmagic.com (Postfix) with ESMTPSA id 248F311395B; Sat, 31 May 2025 00:07:21 +0000 (UTC)
From: Michael De Roover <ietf@nixmagic.com>
To: IETF DNSOP WG <dnsop@ietf.org>
Date: Sat, 31 May 2025 02:07:20 +0200
Message-ID: <6780131.SRmo7RyYC7@workstation.vm.ideapad.lan>
Organization: workstation.vm.ideapad.lan
In-Reply-To: <A1464E84-0CE6-4B1E-B5B2-4DDDA891C42A@icann.org>
References: <2C06E83A-950C-4665-BC50-AEB516B7CD1B@rfc1035.com> <A1464E84-0CE6-4B1E-B5B2-4DDDA891C42A@icann.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="nextPart5698346.SSjj9NsSJo"
Content-Transfer-Encoding: 7bit
Message-ID-Hash: Z2R6AB2I73UUPCNNHKI35LHPB6PDBYPI
X-Message-ID-Hash: Z2R6AB2I73UUPCNNHKI35LHPB6PDBYPI
X-MailFrom: ietf@nixmagic.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
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: [Ext] draft WG chapter: 30/6/25
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/LFvI86gvHii9iyKwctOQV0mcnU4>
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 Friday, May 30, 2025 8:13:05 PM CEST Paul Hoffman wrote:
> - "The DNSOP WG is also responsible for maintenance, updates and extensions
> to the DNS protocol." There has been growing discussion that there should
> be a DNS development (DNSDEV) working group that works on new developments;
> the quoted wording prevents that.


TL;DR: Overall I am in agreement that one WG's charter should not block the formation of 
another. What follows is a cautionary tale.


When I started working on computers professionally, I did so as a sysadmin at first. It was 
years later that I took up development too. When I did so, is when I started to realize just 
how wildly different our respective viewpoints and requirements are.


In response to that (pretty much industry-wide) status quo, Google coined the term "Site 
Reliability Engineering", to increase cross-collaboration between development and 
operations. They also wrote a book about it, and published it at https://sre.google[1].


My concern with the split of development (DNSDEV) and operations (DNSOP), is that this 
would pigeonhole these craftspeople into only one or the other, with less oversight from 
the other. This may well make things move faster, and raise less conflict. So maybe that 
would make drafts move a little bit faster, and reduce the risk of rat-holing (love the term 
by the way). But, it would also risk having one WG step on the toes of the other, from lack 
of understanding about the viewpoints of the other.


This is not unique to software engineering either, e.g. civil engineers and architects have a 
similar such.. strife, let's call it. Because "the architects only care about the looks, not how 
it's going to be built", or something along those lines. At least that's how one civil 
engineer I know portrayed it as, and it really struck a chord with me.


Maybe the discussion about whether we should make a split like this or not deserves its 
own dedicated thread. Overall though, like I said before, this charter should not prevent 
that action to be taken, if that's something we want to do eventually.


-- 
Met vriendelijke groet,
Michael De Roover


Mail: ietf@nixmagic.com
Web: michael.de.roover.eu.org

--------
[1] https://sre.google