[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
- [DNSOP] draft WG chapter: 30/6/25 Jim Reid
- [DNSOP] Re: [Ext] draft WG chapter: 30/6/25 mohamed.boucadair
- [DNSOP] Re: [Ext] draft WG chapter: 30/6/25 Paul Hoffman
- [DNSOP] Re: [Ext] draft WG chapter: 30/6/25 Michael De Roover
- [DNSOP] Re: [Ext] draft WG chapter: 30/6/25 Jim Reid
- [DNSOP] Re: [Ext] draft WG chapter: 30/6/25 Paul Wouters
- [DNSOP] Re: [Ext] draft WG chapter: 30/6/25 Benno Overeinder
- [DNSOP] Re: [Ext] draft WG chapter: 30/6/25 Benno Overeinder