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

[Eric Rescorla <[e-mail]>]

On Thu, Nov 16, 2023 at 6:30 AM Jay Daley <[e-mail]> wrote:

> 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?
>

No, I don't think so. I don't think these should be part of the LLC's
strategic plan at all, because they're not part of the LLC's strategy, but
are rather responsive to other groups.

The LLC's overall strategy in many of these areas is "be available to
support the IESG/IAB". So there may be a need to note it for resource
planning, but it's not part of the LLC's independent strategy in that if
the IESG stopped caring then the LLC would just stop providing resources
for it.

-Ekr



> 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]
>
>