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

[Jay Daley <[e-mail]>]

Hi Eric

> On 16 Nov 2023, at 13:48, Eric Rescorla <[e-mail]> wrote:
> 
> While I think the text you write above in response to Mirja is largely reasonable, the relevant text is actually what is in this document, which in fact does look like the LLC *is* asserting ownership and control over this and other similar items. So I think rather than providing more context in email it would be better to edit the document to make these matters clear.

There are two approaches to this, a general disclaimer in the document or addressing it for each transformation. The first approach is much less work but doesn’t ensure full clarity while the second captures the subtleties but will lead to a less readable document.  My proposed text for the first approach is:

> The listing of a transformation below does not imply that the IETF LLC takes responsibility for that, as many of these have a different group as the lead responsible body, or broad community responsibility, and the role of the IETF LLC in these cases is to support and contribute to that transformation.


Is that sufficient?

Jay

> 
> -Ekr
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 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
> [e-mail]
> 
> -- 
> admin-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/admin-discuss
> -- 
> admin-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/admin-discuss


-- 
Jay Daley
IETF Executive Director
[e-mail]