Re: [admin-discuss] Consultation on IETF Administrative Strategic Plan 2023

Jay Daley <exec-director@ietf.org> Thu, 16 November 2023 13:00 UTC

Return-Path: <jay@staff.ietf.org>
X-Original-To: admin-discuss@ietfa.amsl.com
Delivered-To: admin-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250D7C14F747 for <admin-discuss@ietfa.amsl.com>; Thu, 16 Nov 2023 05:00:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=staff-ietf-org.20230601.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TZQMKijRhxO for <admin-discuss@ietfa.amsl.com>; Thu, 16 Nov 2023 05:00:18 -0800 (PST)
Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6E30C14CE5E for <admin-discuss@ietf.org>; Thu, 16 Nov 2023 05:00:18 -0800 (PST)
Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-40891d38e3fso5712495e9.1 for <admin-discuss@ietf.org>; Thu, 16 Nov 2023 05:00:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=staff-ietf-org.20230601.gappssmtp.com; s=20230601; t=1700139616; x=1700744416; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=V+6FRHHqNqSpLZVMOkMfvcB+XGRVq40GlGS+U0LBiHE=; b=Fz0F+l/bX4QhjvG6p5Y/Wc2K2dZgzdYulMLlqPVe2Op1rfIgVLHs6SRp83WyqHMWFq ppCUdkU4ddQ2AY0IQyIcDDs0yRGyoXRvcf1qYPM5nzP0QfQTy+EijQkfucbhHPb85t5N gEgDLPPlupiKBYYQo4s55qJYfbwPFiqukbpAC7PJ+YFt189mt63D8hVy7Cwjts8dL0ip 90CixPpnjtr7MvY7/g9X2l8t7D+sOZ9OpjqfuEHvgcLPwMlyV4LdxxPR8nfzhdZTDEQ1 zjL6neeYcqgAiHXfIUpMzlou03e8mgKX0DLE0CNI1xzre8XomhlQYtktUV7s92bZNuxW 2Ngg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700139616; x=1700744416; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=V+6FRHHqNqSpLZVMOkMfvcB+XGRVq40GlGS+U0LBiHE=; b=M5uW+iDL7pfFxyzFRjvfNOAr4yd/MSza2djKc0K8Mk0rmuHDAdA7cYe4h1Js7SlAan rRSZTnuBQIL2S9scvfcbcDbrAkldQsVZm87tur0Y+agGqOk1ggSjEy2pHHYJZoDa7JoX nqw+xOTOEdCUZg4mWe6uC0JNO4gA91FJ0C37Ow23Xo+Srf1BbbSxiKWOPFuiQvuzj8N3 cfUIGFAXyYO0RyxDGxwJfEp3h2tdgdjaETzwZRUnsHMYVRiPnUkk7nTbUXpuw2N8dsyn 9xibCRGvPAhfvIqprzdGGOzDT+oREITFrPyf2XKzYPJTL7PglfUpkQKYpUWj9aqidnV7 WamQ==
X-Gm-Message-State: AOJu0YypGJMBA6TG2sf54kkPdtrAal0q1TPH8dNl8MdrYhK4Nq59gYfI x5fTKm/ckE82JEjQ4a+Bnuh8ryLl
X-Google-Smtp-Source: AGHT+IFioZtoCui/xXaITaRzPNsKiNdN9hfyjaUk+wZsLdRdTmD2eScZ1SAzFgXTh5G8NV6RZFzRCA==
X-Received: by 2002:a05:600c:4d01:b0:406:8c7a:9520 with SMTP id u1-20020a05600c4d0100b004068c7a9520mr11768007wmp.36.1700139616071; Thu, 16 Nov 2023 05:00:16 -0800 (PST)
Received: from smtpclient.apple (host-92-27-125-209.static.as13285.net. [92.27.125.209]) by smtp.gmail.com with ESMTPSA id bi27-20020a05600c3d9b00b004097881d5f0sm3553413wmb.29.2023.11.16.05.00.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2023 05:00:15 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\))
From: Jay Daley <exec-director@ietf.org>
In-Reply-To: <6DFA5AB6-1C7B-4701-B711-280461B6A956@ericsson.com>
Date: Thu, 16 Nov 2023 13:00:06 +0000
Cc: "admin-discuss@ietf.org" <admin-discuss@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, IAB <iab@iab.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F61C1FCD-55C4-4DCC-8460-F67D62DF4113@ietf.org>
References: <309BA4FC-7129-4F7B-894C-E64FADA24DD0@ietf.org> <6DFA5AB6-1C7B-4701-B711-280461B6A956@ericsson.com>
To: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
X-Mailer: Apple Mail (2.3774.200.91.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/admin-discuss/_yE6SpSC-CvW1NvL-Da9quBLTEU>
Subject: Re: [admin-discuss] Consultation on IETF Administrative Strategic Plan 2023
X-BeenThere: admin-discuss@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Discussion list for IETF LLC administrative issues <admin-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/admin-discuss>, <mailto:admin-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/admin-discuss/>
List-Post: <mailto:admin-discuss@ietf.org>
List-Help: <mailto:admin-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/admin-discuss>, <mailto:admin-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2023 13:00:23 -0000

Hi Mirja

Thank you for such detailed feedback.  Some thoughts below:

> On 15 Nov 2023, at 22:09, Mirja Kuehlewind <mirja.kuehlewind@ericsson.com> wrote:
> 
> Hi Jay,
> 
> sorry for my late input. But I have to say putting the deadline on a Monday after an IETF meeting is not really ideal, at least not if you want feedback from leadership.

This consultation set a four week period for feedback, starting sufficiently in advance of an IETF meeting that people are caught up in planning for that, and intentionally finishing just after an IETF meeting so that the community has an opportunity to raise any issues directly with the IETF LLC Board including asking questions at plenary.  

> I do have quite some concerns about the direction of the new strategic plan. While I generally agree to the most of the goals, I'm uncertain about the responsibility and role of the LLC for some of these goals. I believe this aligns with the concerns raised by Brian and Stephen,

Theirs was a separate point about ensuring that the nomcom-appointed community members remain in control of any strategic process, and wording has been proposed to clarify the IETF LLC position on that [1].  This was a concern raised in 2020 when the first IETF LLC strategy was consulted on and many in the community have been watching for this carefully but since then, very few concerns have been raised about that, suggesting that the IETF LLC has both understood this concern and worked within its boundaries.  

> however, I think we already crossed the line for some proposed transitions at least the way they are formulated right now. The main points are about the webpage and meeting, where I think the IESG is the main responsible party in order to ensure productivity and quality. Please see my detailed comments below.

Will do.

> I also would like to comment on one thing that I'm missing in the strategic plan. In March the LLC published a statement on Remote Meeting Participation (https://www.ietf.org/blog/ietf-llc-statement-on-remote-meeting-participation/). In this statement the LLC commits to certain operational principles including the following one:
> 
> 5. The long-term aspirational goal is for all participation in the IETF to be free, including IETF Meetings.
> 
> I don't see this reflected in the strategic plan. I don't know what you mean by aspirational, but I hope it doesn't mean that you don't take it seriously. However, I think a strategic plan needs to reflect these long-term goals. More concreate I would like to see the follow transition added:
> 
> From: Remote participants need to pay a registration fee which can be a barrier to participation -> To: Sufficient funding is raised to enable remote participation without requiring a fee

That wasn’t added because it did not seem even close to achievable within the three year timeframe of this strategy.  However, I will note this as a possible amendment for the board to review.


> Please see more comments below!
> 
> Mirja
> 
> 
> -------------------------
>> 1) From: IESG and IAB neither seek nor receive any professional support for any strategic planning they might wish to adopt. -> To: IESG and IAB use the LLC to provide professional support for their strategic planning, as required.
> 
> I really don't understand how you can make the IESG/IAB "use" the LLC. I think it's on the IESG/IAB to decide if they want that support or not. The IESG is from time to time discussion long-term strategy, and yes there are things were some support would be helpful, however, the outcome of most of those effort was more limited due to how the IETF is structural set up. But again, it's on the IESG/IAB to decide where and if they want to do strategic planning and not the LLC. Also, at minimum I think you should have discussed this point with the IESG/IAB which didn't happen.

This is a shift that is already well underway and has been for some time and so this was included in order to be transparent about that. That shift is primarily something that individual members of those bodies are instigating and I agree that a more explicit discussion about this would be valuable and that this wording gives the impression that has already happened.

>> 2) From Slow progress by the IETF in addressing some long-standing and important strategic issues. -> To: The IETF makes significant progress on addressing long-standing and important strategic issues.
> 
> Again, I think these issues are more structural, so I don't see the role of the LLC here. And again, this is a goal for the IESG/IAB and not the LLC, especially this this very generally talks about "strategic issue" without narrowing down to things that the LLC has responsibility for.

In this transformation, and in many others with a similar broad scope, the IETF LLC is not asserting any form of ownership or control of either the problem or the solution.  These are common issues across the whole IETF that all parts need to work towards and the IETF LLC is aiming to be transparent in both recognising the existence of issues and that it will contribute to the work on these.

A good example here is the the long-standing issue of the gender balance of IETF participants.  The IETF LLC has recently commissioned and published a report aimed to help understand the underlying problem and the impact of that, and assist all parts of the community who wish to have a role here.  I have yet to see anything but support for this action, which I think demonstrates well that the IETF LLC understands the difference between ownership and contribution.

Looking through the full text, I can see that this is not explicitly explained, so I will consider some text to propose to the board that makes this clear.

>> 3) From: No overall strategy for the development of content and engagement channels, with sporadic use of measurement and partially defined participant journey -> To: Content and engagement channels developed and managed under an overall strategy, based on comprehensive measurement and a well defined participant journey.
> 
> There might be a role here for the LLC to provide measurement data, however, the responsible for the content of the webpage lies not with the LLC, at least not for the most parts; of course the LLC maintains the info about the LLC and maybe some other operational aspects as well. This should be a goal, at least as it is phrased currently for the IESG and not the LLC.
> 
> 4) From: Website and other channels beset with out of date content, poor information architecture, poor content coordination across sites and with important gaps in content. -> To: Up to date, effective content with all the important subjects/paths covered, good content coordination between sites and channels, and an established process to keep it this way.
> 
> I don't really understand how this point is different from the previous one as I would think the reason to have a strategy is to make sure it's up-to-date. However, the same comment as above applies and even more thought because this explicitly talks about content where I think the responsibility mostly sits by the IESG. Btw. I agree that the IESG is not working enough on this responsibility, and I think we need to develop a process where LLC staff can work on content for the IESG but that's not what the transition goal states. And again, the IESG needs to decide on that strategy.

IETF staff have had operational control of the website and related communications for far longer than the IETF LLC has been in existence, with the same member of staff doing this for many years.  However, as is clear from the list of problems identified, there has been a significant gap in site/content design and the IETF LLC has indeed been moving to fix that by rewriting content, producing plans, commissioning web development etc.  All of which has been based as closely as possible on existing community content, community feedback and website analytics.

This is happening entirely transparently and with significant community engagement including regular updates to the IESG and discussions on tao-discuss and reporting to open tools meetings.  In all of that engagement there have been no objections to the IETF LLC doing this and considerable support for the aims.  For example, one key aim is to have as much web content as possible on GitHub to greatly reduce the barrier for community contributions.  I have yet to hear from the IESG that it objects to this and where the IESG specifically wants control, such as for the I-D Guidelines, then this has been maintained.

The outputs of this work include some real successes such as the consolidation of multiple disparate data sources into authors.ietf.org and wgchairs.ietf.org, the replacements of 100+ trac wikis with wiki.ietf.org and new guides drawn from the Tao and other sources. [2]

Looking forward, the IETF LLC would like to see a better defined community structure to oversee, contribute and engage on this topic and it has previously suggested that something like a content team could be formed to do that.  But that is a community decision to make and not for the IETF LLC. 

>> 5) Form: The IETF hoards old content and old data, long past the point of usefulness. -> To: A strategy in place for archiving and/or deletion of old content and data.
> 
> While I agree that we have a lack of a strategy to archive content, I find the "from" statement rather provocative and a bit ungrounded. First step here is to make an assessment about what is old and useless and again I don't think that sits in the responsibility of the LLC.

There is significant evidence to support the "from" though I agree it should be worded better.  For example, we keep old websites [3] [4] with no plan at all for why and how long, and some of it is clearly past the point of usefulness.

The IETF LLC is responsible for preserving all of this data and ensuring access to it, which comes with a non-trivial cost and effort, and so it seems quite reasonable for the IETF LLC, through the tools team, to be the one to try and manage this to ensure we meet community needs.  There certainly doesn’t appear to be any other body that has either the time or inclination to do this.  The IESG has two tools liaisons who are actively engaged in any such discussions.

>> 6) From: Community engagement on IETF LLC services is often based on opinion and personal perspective, not data or broader principles. -> To: Community engagements on IETF LLC services largely based on data and broader established principles.
> 
> On this point I have some guesses, but I actually don't understand this point really the way it is phrased.  What does community engagement based on data mean? Doesn't that contradict each other. If you want community feedback it always about getting different view. If you want to base your decision on data, you don't need community input...?

Perhaps "interpretation of data" might explain this better?

This was much the same in the 2020 strategy and is close to being achieved, so it may be hard to remember that some years ago, much of the feedback we received was based solely on personal opinion whereas now it regularly considers (or requests) data and/or considers the broader principles. 

I will propose to the board that this one can be removed given the progress made on it.

>> 7) From: Current implementation of RFC 8718 (venue selection) guidance leads to a restricted choice of venues, difficult judgment calls and does not fairly distribute the pain. -> To: New implementation of RFC 8718 (and if necessary a -bis document) that provides more venue options, more fairly distributes the pain and reduces the difficult judgment calls.
> 
> How can there be a new and an old implementation of an RFC? I thought the idea of having a spec in an RFC is to guidance the implementation!? However, the text also talks about the bis and it is for sure not the role of the LLC to push changes to RFCs though the community process. As soon as anybody from the LLC (or leadership) writes a draft, that person should do that as an individual community member. If that person then edits a wg document, it does it on behave of the group reflecting the group consensus and not any goals of the LLC.

All policies need an implementation that has all the operational details that are inappropriate for the policy, and this refers to the IETF LLC reviewing and changing its implementation.  This has already been proposed [5] and a response to the consultation is to be discussed at the IETF LLC board meeting next week.

On the question of changes to the RFC - at the gendispatch session at IETF 116 Yokohama, the IETF LLC presented an I-D asking the community to consider some questions and provide guidance, presumably in the form of an RFC, to address these questions.  In other words, maintaining that separation you are advocating for above.  The feedback from this session was that the community wanted the IETF LLC to take the lead on this, which then led to a second version of the I-D [6] that takes this approach.  This role for the IETF LLC was then explicitly checked at the genarea session at IETF 118 Prague and no objections were raised and it was noted in the report back to the community of that session [7] and again no objections were raised. 

>> 8) From: RFC 8719 (geographic rotation) is too restrictive -> To: Less restrictive geographic rotation rules.
> 
> Again, I think we have a problem with our venue selection, however, we don't have establish consensus that RFC8719 is too restrictive, so I don't think it is correct to set this as a strategic goal overruling the community consensus. You can take the task of starting a community discussion on the rules in RFC8719 but you can't dictate the outcome.

I agree, this is a community decision to make and so i will propose to the IETF LLC board that this is removed.

>> 9) From: Little measurements and analysis of interims and their impact -> To: Better data on interims and how they are used, to inform the IESG
> 
> I don't think the "From" statement is for the LLC to make an assessment. Yes, you can support the IESG with data and in this specific case the IESG is discussing it and requested some data, however, the data providing part is already covered by other goals. I don't think there should be any specific to _impact_ of interim meeting in the LLC's strategic plan as assessing that is a responsibility of the IESG.

As you have noted yourself, the "from" statement reflects a request from the IESG and it has been checked by the IETF Chair.  There is nothing in this transformation that even suggests that the IETF LLC will be assessing impact, this is clearly just a data gathering excercise that is again included for transparency.

>> 10) From: Complex and difficult I-D authoring tools and technical process -> To: A simple to use and fully featured I-D authoring tool and simplified technical process.
> 
> What do you mean by "technical process" here?

Validating, converting and submitting an I-D

> Also, the assessment that authoring tools are complex and different is unfounded.

> I know there is an issue that people have barriers in editing their "first" draft, however, I don't know if your conclusion that tools are too complex is correct. I think there are many other barriers and many other ways to help first time authors. For long term authors I think we actually have a very good set of tools. That doesn't stop anybody from developing additional tools but the starting statement is not correct in my point of view.

The 2021 survey of I-D authors [8] had "ease of use" has the highest importance/satisfaction gap of any characteristic of the authoring tools.  Since then, while much progress has been made, this point has been discussed in many different fora, including iirc the IETF 118 Prague plenary, and the views expressed overwhelmingly agree with this assessment.

>> 11) From: Low utility and low authority RFC Editor website -> To: High utility and high authority RFC Editor website
> 
> I think the responsibility for the RFC editor website clearly lies with the RFC editor and RPC. Yes, the LLC needs to support the RPC with tooling and funding but the goal as stated should not be a goal for the LLC.

Similar to the discussion on websites and content above, there is a gap here, which you acknowledged during the RFC Editor Future discussions [9].  This was resolved as something for the IETF LLC and RPC to work together on, supported by the RSCE, and engage with the community on [10].  

A major project to revamp the website was well discussed in the RSWG [11] and this transformation sets the key goal, as discussed and agreed with the RPC, for that project.  Including it here provides necessary transparency and ensures that the IETF LLC ensures that the RPC delivers this.

>> 12) From: Significant external (outside of the IETF) misunderstanding of the status of RFCs (and I-Ds). -> To: Where it is important, external people understand the status of I-Ds and RFCs.
> 
> This very last point is in my few far overstepping the responsibility of the LLC. This is an issue that is not easy to fix and effectively the reason why we have the RFC editor model v3 and that's where the responsibility sits.

As noted above, there has been a staff communications function for many years longer than the IETF LLC has been in existence, and this has been a long-standing goal for that function. This function is largely driven by IESG requirements and has a specific advisory group with IESG members and keeps the IESG well informed on its work.  

thanks again for the feedback
Jay


[1]  https://mailarchive.ietf.org/arch/msg/admin-discuss/xsdpMO2BYUjRbKUGb59zGagiw_U/
[2]  https://www.ietf.org/how/meetings/guide-ietf-meetings/
[3]  https://www6.ietf.org/
[4]  https://iaoc.ietf.org/
[5]  https://www.ietf.org/blog/proposed-response-to-meeting-venue-consultations-and-the-complex-issues-raised/
[6]  https://datatracker.ietf.org/doc/draft-daley-gendispatch-venue-requirements/
[7]  https://mailarchive.ietf.org/arch/msg/mtgvenue/Y-_o_ZKYNHIJy4GMCW5IsguGeXw/
[8]  https://www.ietf.org/media/documents/REPORT__Survey_of_I-D_Authors_on_Formats_and_Tools.pdf (page 13)
[9]  https://mailarchive.ietf.org/arch/msg/rfced-future/2JTjAgB1ciDeqwYkLwZcbKa3qfE/
[10] https://mailarchive.ietf.org/arch/msg/rfced-future/b76RoT8_jCFNQaYteNQgCd3xb0w/
[11] https://mailarchive.ietf.org/arch/msg/rswg/qivBngIXNfzgtTyAAmUsec-Q0w4/

-- 
Jay Daley
IETF Executive Director
exec-director@ietf.org