Re: [Last-Call] OT: change BCP 83 [Re: Last Call: BCP 83 PR-Action Against Dan Harkins]

Eliot Lear <> Sun, 02 October 2022 15:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9A187C14F738; Sun, 2 Oct 2022 08:36:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.899
X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Oi8Fk-DVMIWm; Sun, 2 Oct 2022 08:36:54 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 035A9C14F732; Sun, 2 Oct 2022 08:36:52 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.15.2/Debian-18) with ESMTPSA id 292FaiYW1062200 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sun, 2 Oct 2022 17:36:48 +0200
Authentication-Results:; dmarc=none (p=none dis=none)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=upstairs; t=1664725009; bh=F3deh1unc1UiYRixWn3/YXVERnRVW4LRG4MC3twjO0A=; h=Date:To:References:From:Subject:In-Reply-To:From; b=uIXQF/xxCIYY/7Ys63pJGGpb7bcKkfTtGRVLW+gG1xgAkXpoRWMV4LoCbytGkR+Fl 2MkxRMlsBp7DgJFqoRcxKpvNn5FkiSmXJbne7Jyvy3gFZmkmOeI76ZfpOf3i5jqdgY Dy4nbxE+mKO1Gn5S+vBPR0E1MIIMc7bzDnVh1E6s=
Message-ID: <>
Date: Sun, 02 Oct 2022 17:36:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.3.1
To: Adam Roach <>,, IETF Chair <>
References: <> <> <> <>
Content-Language: en-US
From: Eliot Lear <>
In-Reply-To: <>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------zxALlNGuPuo0aoVFO7wBLN5H"
Archived-At: <>
Subject: Re: [Last-Call] OT: change BCP 83 [Re: Last Call: BCP 83 PR-Action Against Dan Harkins]
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 02 Oct 2022 15:36:58 -0000

Hi Adam,

On 02.10.22 11:12, Adam Roach wrote:
> For what it's worth, the SAA team has a formal policy of handling 
> matters of "uncivil commentary and disruptive behavior" off-list 
> unless and until the poster persists in their behavior. See 
> <>. 
> Subsequent actions are publicly announced, because they carry at least 
> nominal consequences for the people being disruptive, and because the 
> community has historically demanded a radical amount of transparency 
> when anything like that happens.

Two point heres:

  * I think it was a mistake to delegate this function away from the
    chair.  It is the chair and the IESG who are accoutable to NOMCOM,
    and the chair in particular is a voice of authority on behalf of the
    IESG and the IETF.  There is nothing like having the parent in the
    room, rather than people who report to mommy or daddy.  Yes, I know
    chairs don't want to play that role.
  * I am not sure a broadcast message is the appropriate way to inform
    the community of an action.  For one thing, it leads to endless
    debates, like this one ;-)  And that in turn pulls us further afield
    from what we should be talking about- networking.

> As your anecdote demonstrates, these kinds tools are already entirely 
> within the purview of WG chairs (and their analogs for other mailing 
> lists). The introduction to BCP 83 explicitly calls out that actions 
> of this sort have historically been undertaken, and does nothing to 
> remove permission for them to continue to be applied to this day. 

As long as the chair has them in the toolkit, that's fine- I'll confess 
I'm not an expert on this aspect of IETF process.  My issue with BCP 83 
has to do with steps 2, 3, and 5 of the process.  2 and 3 are not 
necessary, and the community needn't make a decision about an 
individual.  It's a poor use of our time, and subjects the individual to 
humiliation.  We should stop that.