Re: Revised IETF LLC Draft Strategic Plan 2020 to address feedback raised

Jay Daley <> Fri, 29 May 2020 20:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F151E3A1066 for <>; Fri, 29 May 2020 13:36:59 -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 zlfSpWWjyIq8; Fri, 29 May 2020 13:36:58 -0700 (PDT)
Received: from jays-mbp.localdomain (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 67D833A0B0B; Fri, 29 May 2020 13:36:57 -0700 (PDT)
From: Jay Daley <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B0028A65-CCBE-429F-B217-33FB37C6B0A3"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Subject: Re: Revised IETF LLC Draft Strategic Plan 2020 to address feedback raised
Date: Sat, 30 May 2020 08:36:55 +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: Fri, 29 May 2020 20:37:00 -0000


> On 30/05/2020, at 2:38 AM, Eric Rescorla <> wrote:
> Jay,
> Thanks for sending this. Some comments below. I've also sent
> you a PR to convert the tables to Markdown, which would
> make this rather easier to read.

I personally find html tables far easier to read and manipulate than markdown tables, which is why I used them but I’ll look at the PR to see how easy you’ve made them to read.

> > 6. To deliver a toolchain that is up-to-date and well regarded by users.
> This seems in conflict with "evidence-led". Suppose the toolchain
> was well-regarded by users but empirically less efficient than
> other toolchains.

I’m not convinced that there is another toolchain we can measure against or that measured user satisfaction is that distant from empirical observation of efficiency. However, I’m happy to add something about efficiency.

> > Sponsors, in addition to supporting the IETF for the value it
> > delivers, are also increasingly concerned about how the organisations
> > they sponsor operate, how they treat their volunteers and staff and
> > what opportunities they provide for a diverse range of new
> > participants.  To be able to explain this, we need to document the
> > participant journey, a map of the different stages of participation
> > (e.g. newcomer, leadership), at what stages people start their
> > participation in the IETF, how they transition between them and at
> > what stages they end their participation.
> There seems to be an implicit assumption here that people should
> have a "career arc" in IETF that starts with newcomer and
> ends with leadership, but I don't think that's obviously
> true. Many of our most valuable contributors have never served
> in leadership and some of them do lots of reviewing but not
> a lot of RFC writing.

No implicit assumption at all. This is simply documenting what exists though admittedly that information could be used for that purpose if the community so desired (I have no views at all on whether it should or should not). 

> > With particular regard to the services that are provided to
> > participants by the LLC, a culture has built up where decisions are
> > taken more on the basis of opinion and debate than evidence.  For
> > example, someone has a good idea that we should provide X for
> > participants and rather than ask participants if they want X, how they
> > already obtain it and if it is a priority for them, a debate takes
> > place on the merits of us providing it or not.  Sometimes this debate
> > results in stalemate and issues get put into the “too hard” basket as
> > a result.
> > 
> > We need to shift from this to a culture where data is the starting
> > point for identifying what needs to change and why and what the impact
> > will be.  As the transformation says, we need to shift people from
> > lining up next to people with the same opinions and standing opposite
> > those who disagree, to lining up together facing the data and working
> > together to interpret it.
> > 
> > We already have some data available, such as stats on meeting
> > attendees and the post-meeting survey, but making this cultural change
> > requires much more data.  For example, there is a big set of questions
> > on non-participation and barriers to participation which are crucial
> > to providing better service to the community overall. Obtaining this
> > data will require a wide ranging plan backed up with a major programme
> > of surveys and technical analysis.
> Well, maybe. I certainly do think that data-driven decision
> making is important, but in my experience it is often
> infeasibly expensive to make one's decisions based entirely
> on data. In many cases, the cost of gathering the data to
> make a decision whether to implement a feature far exceeds the
> cost of implementing the feature. This can be necessary
> in cases where the feature might have large negative
> impacts, but generally when the cost is just the feature
> itself, this is not true. Good product management is about
> judgement that is informed by data, not by replacing judgement
> with data, as this sort of suggests.

I agree and this does push too far in one direction.

> > | 15 | Lack of clarity on why we need additional income, how much and in what form |
> Perhaps this should be framed in a less loaded way in terms
> of lack of clarity on how much income is needed. If it's unclear,
> perhaps we need *less* income (though I doubt that is true).

Yes good point.

> > Running a cycle of three global meetings per year is a difficult and
> > expensive task, and one that is going to get harder because of four
> > growing issues.
> This seems to be a list of three issues (1) meeting requirements (2)
> carbon and (3) COVID


Thanks for the review. 

Jay Daley
IETF Executive Director

> -Ekr
> On Thu, May 28, 2020 at 9:35 PM Jay Daley < <>> wrote:
> All except for three of the issues raised in response to feedback are now addressed by a revised version.  This includes major rewrites of a number of areas (tools, engagement), a new linkages section to address a set of related issues, and multiple other changes.
> You can either read the whole thing in one go
> <>
> or you can read the individual commits, each of which tackles a related set of issues
> <>
> I would be grateful if those of you who provided feedback could let me know if these rewrites address your feedback or if more work is needed, and I welcome new feedback from anyone.
> For the remaining three issues
> 1. <> "Needs to explicitly reference the mission statements of IETF/IRTF/IAB"
> The submitter has agreed with me that this is handled by other changes
> 2. <> "Emphasis on accessibility for non-native english speakers needed"
> Is out of scope for the LLC to decide on this and to do it without clear community guidance
> 3. <> "No reference to support being developed for community members who promote the IETF in different communities"
> We have done this some time ago but not clear if that was off our own back (and therefore out of scope) or following community lead. Checking.
> thanks
> Jay
> -- 
> Jay Daley
> IETF Executive Director
> <>