Re: Extended: Consultation on IETF LLC Draft Strategic Plan 2020

Jay Daley <> Thu, 28 May 2020 23:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14D053A0FAE for <>; Thu, 28 May 2020 16:31:12 -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 YEgGbJSGaFfP; Thu, 28 May 2020 16:31:09 -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 1EC4F3A0FAB; Thu, 28 May 2020 16:31:08 -0700 (PDT)
From: Jay Daley <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3621BEAF-AAB4-4ABB-91F3-3D03A5ABFD71"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Subject: Re: Extended: Consultation on IETF LLC Draft Strategic Plan 2020
Date: Fri, 29 May 2020 11:31:06 +1200
In-Reply-To: <>
Cc: "" <>
To: Mirja Kuehlewind <>
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, 28 May 2020 23:31:12 -0000

> On 28/05/2020, at 9:03 PM, Mirja Kuehlewind <> wrote:
> Hi Jay,
> I didn’t look at the issue below, however, I also don’t really feel that my point are covered.

I’ve provided more details below

> Further, while the ultimate point of the review is of course to potentially adapt the strategic plan, I would first like to get answers to the questions of who is responsible for things like participation “journey”/edu, culture, and tools

Again, see the details below.

> and also how and if needs have been gather as described in RFC8711?

As RFC 8711 notes "the IETF community should document its needs in consensus-based RFCs" and so the assessment of needs comes from reading the documented consensus RFCs.

However, there are plenty of gaps in those and so some text was proposed on how to bridge that gap:

	 "As the IETF LLC is a support organisation to the IETF/IRTF/IAB, the strategic goals should ideally reflect their strategic goals.  However, as those are neither well understood nor well defined, some assumptions are required."

There was feedback that this was insufficient, which has been captured in:

- <> "Needs explicit recognition that the LLC strategy will shift to follow the IETF consensus"
- <> "Introduction to Strategic Goals needs clarification regarding how it deals with IETF/IRTF/IAB not having specific strategic goals"

I have proposed addressing those by adding a Linkages section and including in that better text.  The full change is at <> 

Additionally, the link to ensure that the primacy of consensus RFCs is followed is in the 'responsive' value: "The LLC will act consistently with the documented consensus of the IETF community, adapt its decisions in response to consensus-based community guidance, and engage with the community to obtain consensus-based guidance for how it operates where none exists.".

>> thanks for putting this together and sharing. In general I think it is good and important to have a long term plan and have it clearly documented transparently to the community. Thanks for that!
>> I finally found the time to review it and I am actually to some extend surprise by some of the content as I would not see that in scope for the LLC. I agree to the general problems that are described but my understanding of who is responsible to address them (even thought that entity might not set up in the most efficient way to address these problems) is different. 

Noted and the intent of consulting on it is to flush out those problems and try to fix them.  
>> I would think the problem or task of, as it is called in the plan, engagement (of new participants) entirely is a responsibility of the IESG. I understand there is some interconnection with fund raising but that is listed as a different topic in the plan anyway. We have the edu team for that which is managed by the GEN AD. I'm not sure I understand the role of the LLC here.

Previously captured in

- <> "Strategic goal #4 about understanding the value of the IETF is too broad"
- <> "Narrative for Engagement Transformations needs to identify what is community-led and what is LLC-led"
- <> "Strategic goal #4 about value needs to be more specific about who is targeted"
- <> "Narrative for strategic transformation #4 needs to be clearer that ideally the community will take the lead and define the content"

>> I have a similar concern regarding tooling. We have the tools team for that. There are more interconnections here because we have payed contractors which are managed by the LLC but the strategy for tools development should come from the tools team and not the LLC. 

Previously captured in:

- <> "Strategic goal #6 about the toolchain needs adjusting to clarify vision"
- <> "Tools Transformations need to be written in terms of implementing requirements of the TAS"

>> As similar point is connected to culture. I don't think it's the LCC responsiblility to set or impact the culture. The text there seems to indicate that the LLC wants to take a task to provide data as background information. That does makes some sense to me for those parts where the LLC is in charge of the data, e.g. meeting and registration stats, but the actual transformation goals seem to target more than that.
I guessed that the transformation you are referring to are those about LLC operations and therefore the issue you raise was previously raised and captured in:

- <> "Need to be clear that Operations Transformations are about the operations of the LLC only"

>> Also more generally, rfc8711 does talk about setting the strategic direction for the LLC (not the IETF as a whole) but then focuses mostly on policies, contracts, funding,  and budget in general. Beyond that it further says:
>> "The role of the Board is to ensure that the strategy and conduct of
>>   the IETF LLC is consistent with the IETF's needs -- both its concrete
>>   needs and its needs for transparency and accountability.  The Board
>>   is not intended to directly define the IETF's needs; to the extent
>>   that is required, the IETF community should document its needs in
>>   consensus-based RFCs..."
>> It seems to me that the first step here would have been to assess the IETF's needs and then only take actions of those needs that were identified and agree on. Was that done? How was that done?

Answered above.

Finally, for clarity, the GitHub issues above are capturing the feedback raised and the next step is to propose new text to address that feedback.  This has been done for some of the issues with more to follow and I can then ask for feedback on the updated strategic plan.


Jay Daley
IETF Executive Director