[dns-at-ietf] Re: managing workload within and across DNS WGs
Shumon Huque <shuque@gmail.com> Fri, 07 November 2025 21:16 UTC
Return-Path: <shuque@gmail.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 A687A85BC1DE for <dns-at-ietf@mail2.ietf.org>; Fri, 7 Nov 2025 13:16:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 gkneMqL-L8et for <dns-at-ietf@mail2.ietf.org>; Fri, 7 Nov 2025 13:16:37 -0800 (PST)
Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 2AC3F85BC16A for <dns-at-ietf@ietf.org>; Fri, 7 Nov 2025 13:16:10 -0800 (PST)
Received: by mail-oi1-x22d.google.com with SMTP id 5614622812f47-45015646170so555060b6e.0 for <dns-at-ietf@ietf.org>; Fri, 07 Nov 2025 13:16:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762550169; x=1763154969; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=NZ51Wm7MVH/3hORds9dJGwWvviEqcXbUJ0lW0KhrOG8=; b=DPC9gdviH3yFzJRxQy9B149hYe+MFo5t/kHE6lSny9cI8Jvjg1BC74n48jMJCf7y/d +fjE2Mm01sSkSDjz9L6r8dJR95oSIx8011zJ7/AYOSxIsZdMx/D5BCjyOxbIO2mA0pR0 kdhFc370qfCRoBISbMTCTdy21C0sHaCUFWFoxIXWjAmPEuc38ZhDmfcdvAwCwmbabBu8 XyVif9+h/FgIffIHfIzLydxLFFBn9/vCzysSA325L+1AOfdiOfd2XEERPWNrHh75cabD Ql4qqtTp9x9hWI1TRAG6MasTKv9UCdqnktxkJm7XBbGb6TL83V5wExwJ+P0wn0bb7qxw uTUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762550169; x=1763154969; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=NZ51Wm7MVH/3hORds9dJGwWvviEqcXbUJ0lW0KhrOG8=; b=w3L4n105NVRPg988GMBC5qYHBml5n0JA2GdjfcgiyZuUuifqcBv755WPpfyEo1iX7S xBSWfdyYVjBVDPemWcFuD5Ja+jFExkVp8nKEv4Vk98TWbZ/ctJ27Rk50aqZdQbrWBOWs 85mAieZDK9DPhqh+XxjtxnydK6mhNDtktExn2Kqq+vZy277d1DzQSPdl6NxpH0XXaubC qVE1oQnmm20mwe0GW1n8+kTy7Q5ccMg5AhwuuJ8rlAcW/uDtT0ItRZ+wGuZ8B9a7o5pb QsgPVLl18vckwZytXyTVLqTnTmOa1tRm187N/ND+0WyeY8dHBY4eHukVlmbbSldNersc Lg2Q==
X-Forwarded-Encrypted: i=1; AJvYcCUh+HrVwq7oX2ISZK1D6TylYmQcvNP4AuRREl3/JC/C2ikflX0c+6krS6qxiJnKh7+4+HiF9dhpDRYk5Q==@ietf.org
X-Gm-Message-State: AOJu0YwRmNorIXCHolOdvmnq7N/fBmyh7KPlxdiLbvW9MAc510PjVM5M bjPOxogzh8HGsXj1KgQdAgD2NMPohBdzKv97HcZTdGgM8NT2HUZVt0OnNqWg9Tqb3YKkQ4Qa/A7 nBL/Gdny4pFip+5Nmbgtb+QhdWDimehk=
X-Gm-Gg: ASbGnctWqwkGe/XfMEF1BFe4rxRk54XpkTNfeP9OPaYN7VVDXdcu5nPW+DhCDSQMOn6 D52f+pkTex9TirbSYtRf2AxIbBjBefBIqjKKI+qrlSOYqKYlmN6u11SCteGXMM6IZleorVZpnOP LfCxcdUDHV2BFfjPA5vy4nh5Z/LXfDPC2+ll4sYy52G3KMltkmfo91sgBYV5r8nj3gGdu/BjqZJ YoOSVbCyVyaLFeIj/FjgLYAWtANFUO+vr3Yq2sVFX0cwTaaMYxQXlO40blCj6hQOyM5aX4=
X-Google-Smtp-Source: AGHT+IElBj98OkeHF8awlo9kYeujpjV1SjzFzjAl6ObZqI0iVjjkcupHn7Nh+EVvXy5DC/LpmO97+xvOsb31gzikq0A=
X-Received: by 2002:a05:6808:1587:b0:44d:9c73:633 with SMTP id 5614622812f47-4502a403742mr394745b6e.62.1762550169420; Fri, 07 Nov 2025 13:16:09 -0800 (PST)
MIME-Version: 1.0
References: <yblwm4259bs.fsf@wx.hardakers.net> <3B7B6340-D218-4992-A11A-335B0DAF6007@sury.org> <ybla50x62zj.fsf@wx.hardakers.net> <42051fc6-570f-47fe-a28e-480417a370ec@isc.org>
In-Reply-To: <42051fc6-570f-47fe-a28e-480417a370ec@isc.org>
From: Shumon Huque <shuque@gmail.com>
Date: Fri, 07 Nov 2025 16:15:58 -0500
X-Gm-Features: AWmQ_bkDQCRdV1ujjm5TloDypFPmV2IUSScDp5PAXiKIvVJdaQiizcntxlatL98
Message-ID: <CAHPuVdXZtj-oUcbtZCgxxCr5zN0On4NEXPv43SjphrYgN4STpQ@mail.gmail.com>
To: Petr Špaček <pspacek@isc.org>
Content-Type: multipart/alternative; boundary="000000000000bf47df064307b0f2"
Message-ID-Hash: BEUJBL436FYEV7LHPDXPR2BPWQWJDNNT
X-Message-ID-Hash: BEUJBL436FYEV7LHPDXPR2BPWQWJDNNT
X-MailFrom: shuque@gmail.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
CC: Wes Hardaker <wjhns1@hardakers.net>, Ondřej Surý <ondrej@sury.org>, dns-at-ietf@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [dns-at-ietf] Re: managing workload within and across DNS WGs
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/cyYcWh5edTLjt5LHCdP1Z2kv8Pc>
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>
On Fri, Nov 7, 2025 at 3:54 PM Petr Špaček <pspacek@isc.org> wrote: > On 07. 11. 25 14:45, Wes Hardaker wrote: > > Ondřej Surý <ondrej@sury.org> writes: > >> With groups large in content and people like dnsop, one of the problem > >> that I have as a chair are the following indicators: > >> > >> - Is there enough interest in the draft? > >> - Has there been enough reviews? > >> - Has the consensus been reached? > > > > I think those are good helpful questions, thank you. Do they work for > > satisfying whether or not a draft is ready for last call though? One of > > the load issues, IMHO, is not just can we take it on (interest and > > enthusiasm are common) but also "was it actively worked on"? A common > > pattern with overloaded groups can be that Last Calls bring up a ton of > > issues because people ignored it until that point. How do you work > > around this sort of problem? > > I think requiring implementations before it is allowed to progress > through a suitable point in the process is a good filter. If authors are > not committed they will not spend time fiddling with code. > > Ad the argument 'but that would create a group of gatekeepers': > On this point, I think I heard Warren already make the observation in the OPSARA meeting that in some other WGs, a small group of influential implementers have been perceived to gate keep accepted work. While on balance, I agree that we need implementations, we need to avoid the situations that Warren cites. We need to balance implementer interest, with operator interest, and IETF principles (e.g. what is good for the Internet, not what is good for the business of a specific set of implementers). For me, one of the most important benefits of implementation work is to prove out protocol designs, identify gaps in our understanding of they would work in the field, and thus inform our work to develop technically correct solutions. Shumon.
- [dns-at-ietf] managing workload within and across… Wes Hardaker
- [dns-at-ietf] Re: managing workload within and ac… Ondřej Surý
- [dns-at-ietf] Re: managing workload within and ac… Wes Hardaker
- [dns-at-ietf] Re: managing workload within and ac… Petr Špaček
- [dns-at-ietf] Re: managing workload within and ac… Shumon Huque
- [dns-at-ietf] Re: managing workload within and ac… Ondřej Surý
- [dns-at-ietf] Re: managing workload within and ac… Paul Wouters
- [dns-at-ietf] Re: managing workload within and ac… Petr Špaček
- [dns-at-ietf] Re: managing workload within and ac… Tim Wicinski
- [dns-at-ietf] Re: managing workload within and ac… Ted Lemon
- [dns-at-ietf] Re: managing workload within and ac… Geoff Huston
- [dns-at-ietf] Re: managing workload within and ac… Philip Homburg
- [dns-at-ietf] Re: managing workload within and ac… Paul Ebersman
- [dns-at-ietf] Re: managing workload within and ac… Ondřej Surý
- [dns-at-ietf] Re: managing workload within and ac… Peter Thomassen