[Gendispatch] Re: [procon] dispatching draft-carpenter-rfc7221bis

Joel Halpern <jmh@joelhalpern.com> Thu, 27 March 2025 17:35 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: gendispatch@mail2.ietf.org
Delivered-To: gendispatch@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 5735613608F6; Thu, 27 Mar 2025 10:35:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=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=joelhalpern.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 fWyctnwkRo-f; Thu, 27 Mar 2025 10:35:35 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.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 9D34A135FFC7; Thu, 27 Mar 2025 10:34:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1743096858; bh=rCSsqIjqBSMDsgTyuOJd/KaK8+mJ+fz+DpgnhpgUSCo=; h=Date:Subject:To:References:From:In-Reply-To:From; b=pxeZ3yIaYVax9plUPgyEk7TvTmXW7uJ9HG6clQCzWabDk2Em9FkTk6xI4SnDeayw7 3ysVIYzUCX1PKmi3owJ5NgXEw1T/XlzKKebrwMxAviUWUJ3/WFYos/XLBqZ676uGBh znvG8kLhXYrBlpLxra3n1TPOPMz8uXzAluPLhMhc=
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4ZNrPQ6dtfz6H73l; Thu, 27 Mar 2025 10:34:18 -0700 (PDT)
X-Quarantine-ID: <3FggafFjJcxR>
X-Virus-Scanned: Debian amavis at a2.tigertech.net
Received: from [192.168.21.83] (unknown [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4ZNrPQ35tQz6G7pp; Thu, 27 Mar 2025 10:34:18 -0700 (PDT)
Message-ID: <8b13b71e-e43a-40ff-807e-96710dd11441@joelhalpern.com>
Date: Thu, 27 Mar 2025 13:34:16 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: procon@ietf.org, gendispatch@ietf.org
References: <1212677.1742733409@dyas> <IA1PR17MB6421A795D03F694B92CBF9EDCDA52@IA1PR17MB6421.namprd17.prod.outlook.com> <E86893FA-05FC-48E9-9100-99FFC98C7C80@tzi.org> <1308918.1742898219@dyas> <1B003401-4E91-4087-BA13-3CBBE130C6AC@tzi.org> <1378215.1742979216@dyas> <6.2.5.6.2.20250326021416.15e67690@elandnews.com> <1506377.1743078829@dyas>
Content-Language: en-US
From: Joel Halpern <jmh@joelhalpern.com>
In-Reply-To: <1506377.1743078829@dyas>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Message-ID-Hash: G4RXW6MVXTK67TT4EPF2X5YU74YLVMBE
X-Message-ID-Hash: G4RXW6MVXTK67TT4EPF2X5YU74YLVMBE
X-MailFrom: jmh@joelhalpern.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: [Gendispatch] Re: [procon] dispatching draft-carpenter-rfc7221bis
List-Id: General Area Dispatch <gendispatch.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/gendispatch/57aYjJ4XpeR8PQ5RZj0FA5smkV8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gendispatch>
List-Help: <mailto:gendispatch-request@ietf.org?subject=help>
List-Owner: <mailto:gendispatch-owner@ietf.org>
List-Post: <mailto:gendispatch@ietf.org>
List-Subscribe: <mailto:gendispatch-join@ietf.org>
List-Unsubscribe: <mailto:gendispatch-leave@ietf.org>

Regarding authors supporting their own documents, I think Michael is 
correct that there is confusion.  As a result, I do two contradictory 
things:

1) A a chair when asking for support I make clear I am looking for 
support from those not named as writing the document, and I simply 
discount any support from those named individuals

2) As a document author / editor, unless the chairs explicitly state 
they are not interested in support from the authors / editors, I state 
my support (with reasons).

Yours,

Joel

On 3/27/2025 8:33 AM, Michael Richardson wrote:
> S Moonesamy <sm+ietf@elandsys.com> wrote:
>      > Hi Michael, Carsten,
>      > At 01:53 AM 26-03-2025, Michael Richardson wrote:
>      >> When it comes to adopting documents, the WG chairs are 100% responsible.
>      >> It's fiat.  THIS PROCESS IS NOT WELL KNOWN.
>      >> Instead, we have a poorly understand (by WG chairs) cargo culting of asking
>      >> people if they support a document.  It does not produce good results, and
>      >> somehoe turns into voting.
>      >> I've even had chairs ask why I didn't +1 my own document.
>      >> (In 2020 several people were surprised that the above was NOT a documented
>      >> process)
>
>      > I agree that the process is poorly understood.  Sometimes, there is a call
>      > for objections to adopting a draft.  That is not one of the considerations
>      > which RFC 7221 (Section 2.2) suggests.
>
> No, but it is a key part of RFC7282 (On Consensus and Humming..)
> So it's a legiimate way for WG chairs to learn about technical objections,
> and understand who is in the rough.
>
>      > I have seen authors "vote" on the adoption of their drafts.  There is an
>      > assumption that the authors of a draft will be in favour of adoption of their
>      > draft.  The authors are free to "vote".  That vote is not supposed to be
>      > counted as an expression of support for adoption.
>
> It's just a silly waste of time; and since the process differs between WGs,
> it's confusing.
>
>      > I vaguely recall reading that a new working Chair was paired with another
>      > working group Chair who has been doing that for a few years.  The rationale
>      > is that the latter will help the former understand the documented process.
>      > Did that happen and did it produce the desired results?
>
> Yes, but what also occurs is that the new chair about undocumented
> processes that the older chair *thought* were BCPs/standards, but actually
> were not.
>
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>   -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*
>
>
>
>