Re: Consultation on *revised* IETF LLC Draft Strategic Plan 2020

Jay Daley <> Thu, 04 June 2020 23:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3D5653A108A for <>; Thu, 4 Jun 2020 16:54:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kEg4AcD3txNY; Thu, 4 Jun 2020 16:54:12 -0700 (PDT)
Received: from macbook-pro.localdomain (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id BE9DE3A1089; Thu, 4 Jun 2020 16:54:11 -0700 (PDT)
From: Jay Daley <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A2CB260E-3624-4AEA-999A-B4571D0B4677"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Subject: Re: Consultation on *revised* IETF LLC Draft Strategic Plan 2020
Date: Fri, 5 Jun 2020 11:54:09 +1200
In-Reply-To: <>
Cc: ietf <>
To: Eric Rescorla <>
References: <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3608.
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: Thu, 04 Jun 2020 23:54:14 -0000

> On 5/06/2020, at 11:22 AM, Eric Rescorla <> wrote:
> On Thu, Jun 4, 2020 at 4:18 PM Jay Daley < <>> wrote:
>> In either case, I think this text should be removed.
> Thanks again, I’m going to stick with it though.
> Perhaps it's worth taking a step back here and asking what you think the terms of engagement are on this consultation.
> Your text above seems to imply that you are putting this out for comment but are the ultimate decider on whether to accept those comments, as opposed to this requiring community consensus. Is that in fact your position?

The question about consensus is a very complex one.  This consultation is clearly not a substitute for a community consensus process but then it’s not trying to establish a community consensus, it’s trying to find out what the community thinks and what changes need to be made to make it a better fit with community expectations.  Some very significant changes have been made to the draft as a result of the feedback received so far.

The pertinent difference here between a consultation and the community consensus process is that those that will accept that result are no longer actively engaged, whereas they remain so in a consensus process until the outcome and so outliers can be judged as such and rough consensus declared.

With a consultation we need to ask "do we have to address every issue raised to the satisfaction of the person who raised it?"  My answer is, ideally yes but sometimes no we don’t - there are boundaries and I think it is both transparent and honest to state when those are reached.  

The LLC board is the ultimate decider on this not me but I choose what I propose to them.  I will note that you and Stephen disagree and they will decide what to do with that information.


Jay Daley
IETF Executive Director