Re: hampering progress

Keith Moore <> Wed, 21 April 2021 17:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 687C83A3144 for <>; Wed, 21 Apr 2021 10:57:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ocLHwuF9r5Kg for <>; Wed, 21 Apr 2021 10:57:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 71B2F3A315F for <>; Wed, 21 Apr 2021 10:56:41 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 7F3281C12 for <>; Wed, 21 Apr 2021 13:56:39 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute5.internal (MEProxy); Wed, 21 Apr 2021 13:56:39 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=GyYRtBqwI0TTaJU+DFUI9FWL/H8laBHa3/J1guFDZ 2o=; b=BeanfbAoSLFqnE/nF6t5NRHIbjFqSqOdmPDvHKfHTgUwRxeB3MvQ35n6a z046xGKzbGnPdG61rEXUO0P6pIJ6oOB038laUdu6AucPwQ49ab+JNYz/pn/olH1F SZRCBTZmcdHx17pWmId8FNXDE+c6jH+/ea2mAwdzoMOM4cPqEo245zHi0oaHJx53 cXNLi2jvzycR3QnMyx1mYtmbZ6voYl4za+B/lG+lq2zYN5Gv53YWA0vQW2dGqwfa +0/cnmIwQ9mGJZgxx7MRW9paMyO2NOSucFf5qPTw17OhYMACqS4LK7/qZvSk/auk a5aYWwKaRp8QhX6bPZXQh96eXcITw==
X-ME-Sender: <xms:VmeAYDQvlZzyjT3xU36lPpYrqkLvVtww_2fMthXV19t6O6QNEP60qw> <xme:VmeAYOFAyzPgUKSk34bCkaNt8_h1JHcNDSE8oYaxXiif30skfgoP8Idq5he7q_6hl Xaxm5FIuPs4eQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvddtkedguddvtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesth ekredttdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvght fihorhhkqdhhvghrvghtihgtshdrtghomheqnecuggftrfgrthhtvghrnhephefhuedthe efgfefgffhkeehgfeugfeiudeugeejkeefleelueeiffetfeeuudeunecukfhppeejfedr uddufedrudeiledriedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhm
X-ME-Proxy: <xmx:VmeAYAGVtv12nxE8fjPFMMEefgYUEK0qAP58DvudJPcRazp6lJRRWw> <xmx:VmeAYER2uNr8f3G7ol8MnGOwZpHiHoWCHvlvzKeu4jdBSOLYUcGXFQ> <xmx:VmeAYJLpg-e9-5fsmTbLb-FJyLeGczerWxTGXOUWpYAhD_Z_coDhPg> <xmx:V2eAYAaoH5VXNtxQCIS0UuVig6tj4Yzo1qCWls9YyM-Iijn004tIng>
Received: from [] ( []) by (Postfix) with ESMTPA id 5E205240054 for <>; Wed, 21 Apr 2021 13:56:38 -0400 (EDT)
Subject: Re: hampering progress
References: <> <> <> <> <> <> <>
From: Keith Moore <>
Message-ID: <>
Date: Wed, 21 Apr 2021 13:56:37 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
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: Wed, 21 Apr 2021 17:57:09 -0000

On 4/21/21 1:35 PM, Michael Thomas wrote:

>> In other words, if a dispute can be handled by existing process, 
>> trying to let that process work might be the best thing to do. If you 
>> try the process and it doesn't work for whatever reason, maybe 
>> there's a bigger problem there.
> Sorry, I have no interest in "appealing" or chasing other process. The 
> point here isn't to "win".

I guess I thought the point was to make IETF less likely to discourage 
participation.   But in this case, I find myself asking, how could IETF 
be different?   There will always be some input that is distracting 
enough to a WG (however that's defined) that the chairs see a need to 
rule it out-of-scope.   You seem to be saying that the chairs don't need 
to be quite so strict. Well, perhaps, but it's always going to be a 
judgment call on the chairs' part as to what will derail a WG, just as 
it's a judgment call on the part of a person who believes they've been 
unfairly ruled out-of-scope to decide whether to appeal it.

So basically it sounds like you're asking for a culture change rather 
than a process change.   I guess in my experience most IETF WG chairs 
are willing to tolerate quite a bit of deviation from a group's charter, 
at least for a while, and some participants would probably prefer a bit 
less tolerance.   This will necessarily vary from one WG to another, but 
sometimes a tight focus is absolutely necessary.

Things I find myself wondering: Were you treated respectfully even 
though the chairs didn't want to discuss your draft in the group?   Did 
anyone suggest alternative ways of building support for your proposal?

Bottom line: Anyone who wants to promote an idea within IETF has to find 
some way of building consensus around that idea.   And any time there's 
inertia opposing that idea, building that consensus isn't likely to be 
easy, even if it's a very good idea.    It's still the job of the 
proponents of that idea to try to build consensus; nobody else is going 
to do it for them.