Re: New-comers (was Re: the old fellowship program)

Michael Thomas <> Sat, 17 April 2021 22:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 321CF3A34C8 for <>; Sat, 17 Apr 2021 15:03:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.751
X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kmaxKVog66-b for <>; Sat, 17 Apr 2021 15:03:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A3B553A34C5 for <>; Sat, 17 Apr 2021 15:03:08 -0700 (PDT)
Received: by with SMTP id m11so20680255pfc.11 for <>; Sat, 17 Apr 2021 15:03:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=fluffulence; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=lkl5i8vqkNFyE+6TbuW3bNKE65o1Mm/sn3JCOUck9N8=; b=gQ+tsRnAqrOOJkFrv2RerZst30EoNymO+29Rw2dUZrshB/YqQkAHrpsMj8C1zKtLGs Dl4iic13Ellhabw9lytzqef4hAT4vwrWdq8Ki7O3WSn075LzLF7LOoidQS8TIvbyuuBV UBZNS53CyP1b1DaH8PyfBdeE0e/r8cviUsLRGjjSRb0SLx2H8cwRM0KgUWU4lHqkvCT1 Qt5S76Fs+hQ4S0ohvwJ7rDKXABCr3qJep1OIprhYIezXZ+Tdcjs4vWaVqRA8DvJYxPuW DUh9xzvx+0kgOg8OgWow9agNfcAIth/t/nNlh2RspsOvV+Di2BgkTCw62HFK6KaYn7h+ zBJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=lkl5i8vqkNFyE+6TbuW3bNKE65o1Mm/sn3JCOUck9N8=; b=hJF6NxthmnMvw/vThlRP1lSjboGK3FTdmPt5GjcFa3QX/Eb1McLvm7KZGnZWfdYS9W 5GG5cY+oUD3hfWJByHYDdgYbTfn5OjGqatvwwcR7fZc4CWXlJXHCuF6fnHK1MgsT7OIw 8fsKk47/7DvAXh4Gx+KI8J5U4SSBKtjDqojwvJ1LPjwyfqe+pvGX+WpBj5HwOx45qLCF cvxEeGWJFAeYMDJwozx/Fj1gLdDtpus0ikUXD5MAc44N0juuc3v2V43i+a/54oX45Lwq iDkxtsrjebFQyKX0OSNiXuCYXh1VOC10mjZZZXFYzig4lncFSRinOTKDJKjRXykW0pV7 Pkew==
X-Gm-Message-State: AOAM533u0hSD7OaeOL1TIYR6VkxMLDuImOhcCHro/7/ap0sEEh91w8Eh DIyA5TIjYEWt7y3bnsCiDAuntw==
X-Google-Smtp-Source: ABdhPJxOtGeFxVRvm7irmtIp5k3NN5f52yZm3nUv8z8m+DHTb9zHsCVmcawtG1SjY3LDEQaJGaIa/A==
X-Received: by 2002:a05:6a00:158b:b029:241:a969:4da6 with SMTP id u11-20020a056a00158bb0290241a9694da6mr13468491pfk.27.1618696987247; Sat, 17 Apr 2021 15:03:07 -0700 (PDT)
Received: from mike-mac.lan ( []) by with ESMTPSA id x13sm11252412pja.3.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 17 Apr 2021 15:03:06 -0700 (PDT)
Subject: Re: New-comers (was Re: the old fellowship program)
To: John C Klensin <>,
References: <> <> <> <> <> <> <> <> <> <> <> <> <433863C0CD9449636063CDE3@PSB> <> <71A3F4ECF01DBB59C3038E1D@PSB>
From: Michael Thomas <>
Message-ID: <>
Date: Sat, 17 Apr 2021 15:03:05 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <71A3F4ECF01DBB59C3038E1D@PSB>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 17 Apr 2021 22:03:13 -0000

On 4/17/21 10:28 AM, John C Klensin wrote:
> Indeed, that is at least a key part of the problem -- and a
> problem that I believe Andrew, myself, Randy, and probably Brian
> were trying to address from our different perspectives.  It is
> the part of this problem that I think has gotten worse in the
> last decade or so.  It is one that the anti-harassment
> procedures and guidelines for conduct developed during that
> period either do not address or have proven inadequate to
> prevent or remedy.  I suggest that guidelines for improved
> terminology will not help either.  People can jump down the
> throats of others (or snarl at them) for departing from
> homogeneous opinion or the preference of leadership in a WG (or
> even in other contexts) without violating any specific rules
> (even though it is fairly clear from RFC 7154 that it is bad
> behavior) with impunity.

Part of the failing is that passive aggressive behavior is tolerated in 
my experience. But outright hostility is certainly tolerated way too 
much too. Just because you aren't couching something as an ad hominem 
doesn't mean that you aren't being aggressive. Part of the problem is 
passive working group chairs and that AD's don't scale to deal with 
that. Indeed, if you're an AD about the last thing you want on your 
plate is wg chairs behaving badly I would think. Essentially you're 
talking about taking the time to get the back story for somebody who can 
only keep loose tabs on the tech, let alone how the wg is being run and 
its day to day operation.

>> Who needs that kind of grief? Especially when you're not
>> getting paid to take it.
> Exactly.
> I don't see any way to stop that behavior -- and stop it from
> driving people away from those WGs at least and probably the
> IETF more generally -- unless:
> (1) The IESG, perhaps borrowing ideas for other SDOs, will not
> tolerate (i.e., charter or allow to continue) WGs whose
> participation represents only a narrow range of interests.
> (2) The IESG and community will not tolerate WGs (or other
> groups) in which shutting down dissent or questions that differ
> from the opinions of WG leadership (including de facto
> leadership by those you describe as manor lords) is a regular
> practice.
Dang it, I knew my spelling looked suspect for manor :)
> (3) The community has effective ways to push back on individuals
> who exhibit that sort of shutting down or snarling behavior
> regularly, whether it is confined to one WG or not.
It often becomes just a war of attrition until you ask why you're doing 
this. For a newbie that question gets asked a lot sooner rather than later.
> Of course a WG should not need to tolerate someone who raises
> the same questions or proposals repeatedly after they have been
> fairly considered and rejected, but that is disruptive behavior
> and we have many years of mostly-successful experience in
> dealing with it.
Right, I'm not talking about religitation on an individual basis. But it 
can be really hard from the outside to understand why various decisions 
were made and frankly I don't know of any other way to do that than just 
ask. Do we record hums and/or working group consensus calls and what 
they represent? Even that would go some way to help get up to speed. The 
document is the distillation of what the protocol is, but the back story 
of *why* it is the way it is is often just as important.
> Independent of the impact on feelings and participation, the
> behavior you describe damages the credibility of the IETF and
> its work if a cabal, especially one with shared commercial
> interests, can take over (or initiate) a WG, push documents into
> and through IETF Last Call, and then successfully claim IETF
> consensus and standards status for the results.
What change was that?
> And none of the above would likely be meaningful or effective
> unless there is also a mechanism for reporting problems and
> having them considered that does not put the reporter at risk
> for further abuse.  In that regard, the recent IESG statement
> about Last Calls may be a step backward. If someone feels a need
> to make a Last Call comment identifying ways in which claimed
> consensus (in a WG, on a mailing list, etc.) is invalid because
> those who disagreed were silenced or driven away, it should be
> possible to make that comment to the IESG with the same degree
> of anonymity associated with the Ombudsteam process.  More
> generally, someone should be able to make such a report to an AD
> or the whole IESG at any time and have it taken seriously
> without disclosing the identity of the reporter.  At least for
> Last Calls, that seems to be precluded by the new process
> description.
This of course has the same AD scaling problem as above. Real Supreme 
Courts spend considerable time and effort with themselves and their 
staff to scale up, and that's their day job. AD have no such staff and 
working group squabbles are hopefully not a significant portion of their 
day job.