RFC 3844

IETF Problem Resolution Process

📅 published August 2004, from ietf

IETF Problem Resolution Process ✨

Okay bestie, let's get into it 🦋 This is RFC 3844, an Informational doc from the Network Working Group, dated August 2004. The authors are E. Davies, Ed. from Nortel Networks and J. Hofmann, Ed. from Wissenschaftszentrum Berlin. The header doesn't list any Obsoletes or Updates lines, so this one doesn't replace or change any other RFC 🌸

Status of This Memo

This memo is just information for the Internet community 💖 It does not specify an Internet standard of any kind, and distribution of it is unlimited ✨

Copyright (C) The Internet Society (2004). 🎀

Abstract

Okay so this Informational doc is basically a diary of the Problem WG's chats during 2003 about how to fix the problems in the IETF Problem Statement 🧚 It breaks each problem into a few areas for improvement and sorts them into two buckets: problems hitting the routine processes used to make standards, and problems hitting the fundamental structure and practices of the IETF. The routine-process fixes are proposed as quick, non-disruptive solutions 🔥

It also lists suggested ways to handle developing the structure and practices solutions that came up in IETF discussions. Nobody in the working group or the wider IETF has reached consensus on a recommendation for any of them 💀 So the doc basically says the search for structure and practices solutions should be handed back to the IESG 👑

There was working group consensus on the short-term and medium-term process improvements, but not on the longer-term proposals. So the longer-term stuff is only in here as a matter of record. It's not recommendations from the working group, so don't treat it like one 🙈

Table of Contents

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  IETF Purpose and Core Values . . . . . . . . . . . . . . . . .  3
       2.1.  Non-Core Values  . . . . . . . . . . . . . . . . . . . .  4
   3.  Building on our Success  . . . . . . . . . . . . . . . . . . .  4
   4.  Problem Decomposition  . . . . . . . . . . . . . . . . . . . .  5
       4.1.  Decomposition of Mission Problem . . . . . . . . . . . .  6
       4.2.  Decomposition of the Engineering Practices Problem . . .  7
       4.3.  Decomposition of the Complex Problems Problem  . . . . .  7
       4.4.  Decomposition of the Standards Hierarchy Problem . . . .  8
       4.5.  Decomposition of the Engagement Problem  . . . . . . . .  8
       4.6.  Decomposition of the Management Scaling Problem  . . . .  9
       4.7.  Decomposition of the Working Group Practices Problem . . 11
       4.8.  Decomposition of the Preparedness Problem  . . . . . . . 11
   5.  Process Recommendations  . . . . . . . . . . . . . . . . . . . 11
       5.1.  Improvements to Routine Processes  . . . . . . . . . . . 12
             5.1.1.  Suggestions to Improve WG Quality Processes  . . 13
             5.1.2.  Suggestions to Increase the Use of Tools . . . . 14
             5.1.3.  Suggestions to Improve Training. . . . . . . . . 14
             5.1.4.  Suggestions to Increase WG Chair Communication . 14
             5.1.5.  Suggestions to Improve Maintenance of Standards. 15
       5.2.  Changing the Structure and Practices of the IETF . . . . 15
   6.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
       Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
       Normative References . . . . . . . . . . . . . . . . . . . . . 18
       Informative References . . . . . . . . . . . . . . . . . . . . 18
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20

1. Introduction 🌈

Okay so this doc suggests processes to tackle several problems the IETF is facing, which are described in the IETF Problem Statement [1] 💅

It starts with what the purpose and core values of the IETF are thought to be, and then gives a reminder of the good stuff we really don't want to lose while we're fixing things 🫶

Each problem in the problem statement gets analyzed and broken into a few areas for improvement. Those areas seem to fall into two categories:

  • Areas that are basically independent of the other problems, so they can be fixed right away with discrete, minimally disruptive changes or improvements to the 'routine' processes of the IETF 🍓
  • Areas that depend on each other and will probably affect the structural stuff that defines how the IETF operates. Fixing these will probably need a more integrated approach, since they might mean fundamental changes to our organizational structure or standards-track processes 😭

The suggestion is to work on these two classes in parallel. That way we get some near-term wins while the bigger structural changes get carefully considered and carried out ✨

Concrete suggestions are included for how to begin or continue work on the independent routine improvements 🎀

Because there's no consensus, there are no firm suggestions for the more structural changes that might be needed 🙈 The doc lists the various proposals that the working group and the wider IETF considered at the IETF 57 plenary session in Vienna, July 2003. It can only suggest, as some participants proposed, that the IESG itself control the development of any solutions to the structural problems 👑

2. IETF Purpose and Core Values 💜

As we think about fixing the problems with IETF processes and organizational structure, it's super important to keep in mind the things we don't want to change: our sense of purpose, and the core values that give the IETF its unique identity 🧚

At two IESG plenary meetings in 2002, the chair of the IETF gave presentations outlining his view of the purpose and core values of the IETF. Those presentations may be a useful basis for focusing on our mission and core values 🦋

At the IESG plenary in London in July 2002, it was stated that the purpose of the IETF is to "produce high quality, relevant, and timely technical standards for the Internet". Our organizational structure and processes should be judged by how well they help us achieve that mission 👑

At the following IESG plenary in Atlanta, Georgia in November 2002, five core values of the IETF were presented [8]:

  • "Cares for the Internet"
  • "Technically Competent"
  • "Open Process"
  • "Volunteer Core"
  • "Rough Consensus and Running Code"

2.1. Non-Core Values 🌸

Understanding our core values also helps us spot the long-standing features of the IETF that we can change without compromising our values or sacrificing our unique identity 🔥

During the November 2002 IESG Plenary, the IETF chair also presented the following "non-core values" [8]:

  • The division into WGs and Areas
  • The three-step standards process
  • The ASCII format for RFCs and I-Ds
  • The format of IETF meetings
  • The structure of WG mailing lists
  • The powers of the IESG and IAB

These things were designed to help us achieve our goals in a way that's consistent with our core values 💖 If they're no longer effective, we can and should change them 🫶

3. Building on our Success 🌟

While we focus on our operational problems, we shouldn't forget that the IETF is a seriously successful organization 👑 We're responsible for some of the most widely used communications standards in the world, and we've contributed to the creation and growth of the Internet, one of the greatest technical and social achievements of our time 😭✨

In good times it's easy to succeed despite operational inefficiencies, so organizations tend to ignore operational problems and focus on their success 💅 In bad times, organizations can get overly critical of their own structure and processes, blaming the organization for problems that are actually caused by outside forces 💀

We're going through difficult times in the IETF and across the communications industry right now 🌧️ The IETF should be careful not to unjustly blame its own organizational structure or processes for the effects of industry-wide changes such as:

  • Economic issues in the global communications industry, which are causing increased scrutiny regarding expenses and return-on-investment. These same factors are causing job changes and uncertainty for many IETF participants.
  • The commercialization of the Internet, which has drastically increased the financial impacts of standardization.
  • The convergence of the datacom and telecom sectors of the communications industry, which has led to an influx of experienced people into the IETF with a different culture and industry perspective.

Although it's important to recognize and correct the serious organizational problems the IETF is facing, many of these problems have existed for years, and the IETF has been successful in spite of them 🧚 We shouldn't overreact with sweeping revolutionary changes to the IETF structure and processes 🙅‍♀️ Instead, we should focus on building a culture of continuous operational improvement, so we can evolve our organizational structure and processes to make them more scalable and effective 🦋 This is also our chance to develop the mechanisms and processes we can use to continually monitor and improve our organizational effectiveness, in both good times and bad 🎀

The IETF currently has a large amount of valuable work underway, and care should be taken not to disrupt or delay that work while we address our organizational problems 🫶

The IETF is also lucky to have a large number of extremely talented and dedicated individuals who serve in formal and informal leadership roles throughout the organization 🌈 We should be careful not to alienate or disenfranchise the IETF's key contributors, and the people who drive the work forward, while we make organizational or process changes 💜

4. Problem Decomposition ✨

okay so the problem statement doc lists seven root cause problems facing the IETF 🫠 (the list below actually has eight bullets, so the count is a little off, but we're keeping it as written). It doesn't rank them, except that the first one is the most important 💅

  • Participants in the IETF do not share a common understanding of its mission;
  • The IETF does not consistently use effective engineering practices;
  • The IETF has difficulty handling large and/or complex problems;
  • The three stage standards hierarchy is not properly utilized;
  • The IETF's workload exceeds the number of fully engaged participants;
  • The IETF management structure is not matched to the current size and complexity of the IETF;
  • Working group practices can make issue closure difficult; and
  • IETF participants and leaders are inadequately prepared for their roles.

Once you break these down, they split into several areas for improvement 🧩 Some can be fixed right away with independent actions, and others need more thought and a more structured plan 🎀

Also, the problem statement lists problems that some IETF members have reported 🗣️ All of them are believed to be real, but they don't show up everywhere in the IETF, and some might just be symptoms of other problems 🤔 bestie, that's a whole vibe.

4.1. Decomposition of Mission Problem

So, to figure out the best organization and processes for the IETF to do its job and hit its goals, the org needs a shared understanding of its current mission and goals 🎯 It could get there as an independent action with zero disruption to current processes, but it's way more valuable when it's part of lining up the org and its priorities with the mission 💖

As part of understanding the mission, the IETF needs to figure out who its stakeholders are and how it serves them 👀 We also need to define the scope, so it's clear what's in-scope and out-of-scope 🧠 And we need to set our goals and priorities, and learn how to recognize and measure our own progress and success 📈

The mission and goals need a continuing review 🔄 so they stay aligned with tech developments, the needs of the industry in general, and especially our stakeholders 🫶

Once the mission and goals are clearly articulated, we should train new participants on those principles 🌱 That way they can get acclimated to IETF culture super fast ✨

4.2. Decomposition of the Engineering Practices Problem

The IETF lacks effective engineering practices in four major areas 💅

  1. Failure to clearly define the scope of the work, engineering trade-offs and acceptance criteria for each project.
  2. Lack of effective mechanisms for issue tracking and/or document change control.
  3. Lack of effective processes to ensure quality throughout the development of IETF work items, such as intermediate acceptance criteria or formal review processes.
  4. Sufficient focus on milestones, and recognition or rewards for individuals or groups that achieve timely, high quality execution.

Some of these areas (issue tracking and revision control) would need tools made available to WG chairs and editors 🛠️ and IETF participants (at various levels) would need to be educated on how to use them 📚

The other areas are about forming and managing IETF WGs, and they'd need documented and adopted engineering processes inside those WGs 🦋

4.3. Decomposition of the Complex Problems Problem

The IETF is actually really good at well-defined problems with limited scope 🙌 Those get handled well in IETF WGs, where experts in a given technology can get together and solve problems for that one technology area 🎀 But we are way less effective at complex problems that touch more than one IETF WG or area 😭

Right now, most communication between WG chairs goes through the IESG, especially across area boundaries 📮 Some inter-WG and inter-area communication problems could be eased by more direct communication and coordination between the chairs of related WGs 🤝 There are also some immediate efforts underway to increase communication between WG chairs 🫶

Other complex problems involve higher-level stuff, like a unified architecture or highly coordinated multi-area efforts 🏗️ As part of any IETF reorganization, we should think about management structures that help us focus better on architectural and cross-area issues 🧚

4.4. Decomposition of the Standards Hierarchy Problem

There are several problems with the IETF's three-track standards process 🛤️ They can be grouped like this:

  • The three standards-track steps are not used effectively within the IETF.
  • The IETF standards-track is not well understood by the users of IETF standards.
  • The current standards process does not make it easy for users to locate a set of related documents, such as an architectural framework and associated protocols.
  • The IETF does not have an effective way to maintain IETF standards.

Major changes to the standards-track should only be considered as part of an integrated structural review that includes understanding our mission and goals 🔍

That said, there might be immediate changes we could make to maintain current IETF standards better, or to make them more accessible to users 🌸

4.5. Decomposition of the Engagement Problem

The engagement problem breaks down into three main issues 💜

  • Some WGs don't have enough participation, and WG documents are often produced by very small groups of people, maybe with limited expertise in some relevant areas 😬
  • WG documents aren't adequately reviewed by people outside the originating WG 👀
  • People lose interest in longer-lived WGs, especially when protocols take a really long time to develop 🥱

When too few people, or people representing too few areas of expertise, review WG documents, the output can end up low quality 💀 We need to find ways to make document review more effective at all levels 🔎

Quality processes that rely entirely on a gatekeeper at the end, whether that gatekeeper is the IESG or a WG review board, tend to make other participants focus less on quality 🙈 So instituting better quality processes all through document development, including acceptance criteria and review at several stages, would likely make WG participants focus more on document quality 💖

When the interest of document editors or key contributors starts to lag, that can cause serious problems for a WG 😩 This mostly happens when WGs are floundering, or when charters are so loose that WGs lose focus 🌀 It also happens when WG documents get stuck in AD review and/or IESG review for long periods with little feedback, or when the WG lacks consensus to move its documents forward 🐢 Better processes for chartering, tracking, or managing WGs could help with a lot of these problems 🛠️

We also need to better understand what motivates people to get deeply engaged in the IETF and stay engaged 🌈 Expanding the number of formal leadership positions and/or finding more effective ways to recognize our top technical contributors could encourage more people to become, and remain, deeply engaged in the IETF 👑

4.6. Decomposition of the Management Scaling Problem

Several issues are grouped under the idea that the IETF's management structure isn't well matched to the size and complexity of the organization 📏 One or two of these might be fixed with immediate solutions, but solving the main problem will take some type of IETF reorganization 🏢

There are five major areas for improvement under this problem 🧩

  • The current organization of the IETF does not scale. IESG members are running too many WGs, reviewing too many documents, etc. Most IESG members have dozens of direct reports (WG chairs, directorate members, etc.). In its current form, there are very few people who could do a good job as an IESG member, and the huge time commitment and responsibilities of this role make it very difficult to find qualified people who are willing to serve on the IESG 😵‍💫
  • Current IESG members and other IETF leaders are overloaded 🥵
  • The IETF selection processes have tended to select leaders (IESG, IAB and WG chairs) from the same small pool of people. The IETF needs to identify and develop additional leadership, and to delegate real authority and influence to a larger group 🫱🏽‍🫲🏼
  • The IETF is not effective at identifying and developing new leaders, and we lack sufficient recognition for the contributions of IETF participants 🌟
  • One or two IESG members can block WG documents indefinitely (in AD review or IESG review) 🚫

Some level of IETF reorganization is needed to improve the first two areas 🏗️ This should be done as part of the structural improvement effort 💅

In parallel with any more structural reorganization, some relief could come from modifying IESG internal processes so that one or two IESG members can't indefinitely delay a WG document, whether on purpose or because of work overload 🙅‍♀️ The I-D tracker has already helped in this area, since it creates visibility into how and why a document is being delayed 👁️ but it may not have resolved all of the issues here 🤷‍♀️

The IESG may also be able to take near-term steps, with community visibility and agreement, to delegate more work to WG chairs, to directorates, to the IAB, or to other people in formal or informal leadership positions 🤝 If more leadership positions are needed for this, the IESG should consider creating them 🎀

The IESG could also help expand the IETF's leadership pool by actively seeking interested and qualified people for leadership positions, and by using more open processes to select WG chairs and other influential positions 🌈

4.7. Decomposition of the Working Group Practices Problem

Okay, "rough consensus" is considered a core value of the IETF 💜 but consensus-based decision making works best in smaller groups with a common viewpoint and common goals 🥹 Somehow we need to resolve the apparent conflict between our core values on rough consensus and our desire to be an effective organization with several thousand participants 🧩

Consensus-based decision making has some inherent issues 😅 and there are also some problems in the IETF that make those issues worse:

  • WG chairs may lack the skills and training to deal with common behavior problems that undermine or prevent consensus.
  • IETF participants are often unaware of how the IETF decision-making processes are intended to work.
  • WG chairs and participants often lack good conflict resolution skills.

Each of these issues could be addressed through training or other educational resources 📚✨

4.8. Decomposition of the Preparedness Problem 🎀

okay so the IETF could seriously benefit from training and learning resources that make participants and leaders at every level more prepared 💖

we do have formal training for brand-new attendees and new working group chairs ✨ but ngl our current training programs could use a glow-up 🫶 and a bunch of other groups could benefit from training or other kinds of development too 🌸 (web tutorials, on-line resources, references, mentoring, etc.). that includes continuing attendees, experienced WG chairs, document editors, and IESG members. everyone deserves to level up 🧚

there's already an effort underway to improve the IETF's internal education programs, and we recommend that it keep going 💅

5. Process Recommendations 🦋

the big-picture recommendation here is to pursue near-term improvements to the IETF's routine problems in parallel with an integrated effort to reorganize the IETF and improve our standards processes 💜 none of the efforts suggested in this document should get blocked while we wait for this document to be finished and published 🙅‍♀️ ongoing efforts should keep going, and new efforts should start as soon as there's IETF consensus that they're worth it ✨

also, in our improvement processes, we should focus our near-term improvements on areas of routine that are less likely to get substantially modified by any proposed structural changes 🎯 that way we avoid making the same thing change twice (a double change is so not it 😭)

5.1. Improvements to Routine Processes 🌈

a lot of the problems the IETF is dealing with right now can be resolved, or at least mitigated, through near-term improvements to our current organization and routine processes 💅 lots of these improvements are completely separable, so there's no reason to lump them all into one single IETF WG 🙅‍♀️ it's also not necessary for all of these changes to be directed by the (already overworked) IESG 😩

BUT, to avoid the chaos and confusion that could happen if we tried to change everything at once, it's recommended that we pick a few high priority areas and focus on improving those 🔥

when we're choosing which areas to tackle first, we should consider these criteria 👑

  • We should address our most urgent, important problems.
  • The areas chosen should be cleanly separable, so multiple improvements can happen in parallel with minimal interference.
  • We should maximize the benefit vs. the cost of the improvements (aka look for low hanging fruit 🍓).
  • As much as possible, we should focus on improvements that are less likely to be completely invalidated by an overhaul of the IETF management structure. This might be done by focusing on improvements at the WG and participant levels, rather than at the IESG/IAB level.

in the sections above, we spotted several areas of routine that could benefit from near-term improvements 👀 they are:

  1. Improve WG quality processes and the effectiveness of document reviews at all levels.
  2. Increase the availability and use of issue tracking and document sharing/revision control software in the IETF.
  3. Improve training and resources for IETF leaders and participants at all levels.
  4. Improve communication between WG chairs to identify and resolve inter-WG and inter-area problems.
  5. Consider IETF processes or structures to better maintain IETF standards.
  6. Modify IESG-internal processes to make it impossible for one or two IESG members to indefinitely delay a document.
  7. Modify IESG processes to delegate more responsibility to WG chairs, to directorates, to the IAB, or to people in other formal or informal leadership positions.
  8. Modify the WG chair selection processes to widen the group of people considered, and consider ways to develop more leaders for the IETF.
  9. Initiate regular AD review of WG milestones and progress.

applying the criteria from above, it makes the most sense to tackle areas 1, 2, 3, 4, and 5 through immediate near-term efforts 🫶 these are high-priority issues, they're separable enough to run in parallel, they add minimal extra burden on the IESG, and they're the least likely to get affected by an IESG/IAB-level reorganization or by changes to the standards-track document maturity level classification and process 🦋 specific recommendations for each of these areas are in the following sections.

the IESG should consider internal changes to address areas 6, 7, and 8. area 9 would need a substantial time commitment from IESG members, so near-term improvements in this area aren't suggested, unless the IESG believes the near-term benefits would justify the effort 🤔

5.1.1. Suggestions to Improve WG Quality Processes ✨

a working group should be formed in the General Area of the IETF to oversee improvements to WG quality processes 🎀 that includes: the WG (re-)chartering process, the quality processes used by IETF WGs, and the effectiveness of IETF reviews at all levels. the goal of this WG should be to improve the quality and timeliness of WG work output 🚀 it would be chartered to resolve the non-tools-related portions of the Engineering Practices problem (Section 4.2), the WG-related portions of the Engagement Problem (Section 4.5), and the non-training-related portions of the WG Practices problem (Section 4.7) 💖

a great deal of efficiency and synergy can come from adopting common processes throughout an organization 🌈 but the IETF's strength is that WG chairs get a lot of latitude to choose their own processes and tools, based on the size and nature of their WGs 🧚 so, in general, processes and tools should be made available to WGs and WG chairs, not forced on them 🫶

5.1.2. Suggestions to Increase the Use of Tools 🛠️

ideally, the spread of tools across the IETF would happen through grass-roots efforts organized by participants 🌱 one example of this kind of effort is the recent adoption of Jabber for use during IETF meetings 💬

it's also possible that the IESG could designate functional leaders for specific tools-related efforts and support those leaders in organizing them 👑 it might also be helpful for the IETF to set aside some technical and systems resources to make useful tools available to WGs and participants throughout the IETF 🍓

these efforts should resolve the tools-related portions of the Engineering Practices problem (Section 4.2) 💅

5.1.3. Suggestions to Improve Training 📚

the current WG chairs and newcomer's training efforts should keep going and be expanded as appropriate to cover training for other groups 🌸 this effort is expected to address the Preparedness problem (Section 4.8), along with the training-related portions of the Mission Problem (Section 4.1) and the WG Practices problem (Section 4.7) 🎀

5.1.4. Suggestions to Increase WG Chair Communication 💬

some efforts are already underway to let WG chairs meet each other and give them chances to set up communication channels 🫶 these include WG chair socials and training sessions for experienced WG chairs ✨ these efforts should keep going 💖

the IESG could help promote chair-to-chair communication by encouraging direct communication between WG chairs when multi-WG issues come up 🙌

but ngl, most of the responsibility for building effective chair-to-chair communication channels lies with the individual WG chairs 😤 we should stop relying on the IESG to resolve inter-WG issues, and start talking to each other directly about them 🗣️✨

these efforts may help ease the Complex Problems problem (Section 4.3), although a full solution to that one would probably need some changes to the IETF management structures 🦋

5.1.5. Suggestions to Improve Maintenance of Standards 📜

the IETF should consider proposals to improve the way IETF standards are maintained 🌈 it might be possible for the IESG to document and implement a mechanism to maintain IETF standards without needing a WG to make this change 🧚

this effort should address the maintenance-related portions of the Standards Hierarchy problem (Section 4.4) 💜

5.2. Changing the Structure and Practices of the IETF ✨

okay bestie, here's the big one 👀 A whole bunch of the problems from the IETF Problem Statement seem to need changes to the actual structure of the IETF and/or the core practices that basically make the IETF the IETF 💅 Looking back at what we found in Section 4, the problems that might need that kind of change are:

  • The Mission Problem (Section 4.1, [7]),
  • the Complex Problems problem (Section 4.3, [3], [6]),
  • the Standards Hierarchy problem (Section 4.4, [4]),
  • the Management Scaling problem (Section 4.6, [6], [3], [2]), and
  • The longer-term portions of the Engagement Problem (Section 4.5, [5])

(The extra references on each item point to documents that might need updating as a result, so keep an eye on those 📚)

ngl, messing this up could cause irretrievable damage to what makes the IETF effective 😭 But it's also super important that we figure out the necessary changes and get the community to accept them as fast as we can. To get buy-in from as many IETF stakeholders as possible, as many of them as possible should be involved in building the changes. The development and acceptance processes have to be as open as possible, in line with normal IETF principles 🫶

Developing the changes under a General Area Working Group got a lot of debate, and a proposal was floated in a previous version of this document. That proposal included a draft charter for the working group. Honestly, this path has now been rejected by the Problem working group because of:

  • the perceived slow progress of such groups,
  • the difference in the nature of the problem from the usual technical problems solved by IETF working groups, and
  • the difficulty in achieving acceptance by all segments of the community for work driven by a small group.

Another idea was coordinating the structural changes through a 'Strategy and Answers Panel' made up of delegates from IESG, IAB, and ISOC, plus a number of members from the wider IETF community (forming a small majority of the panel) selected using the nomcom selection process. You can find that proposal in [9]. The selection process was meant to build a panel that represents the interests of the whole IETF community, so the solutions it comes up with would be acceptable to everyone. This one hasn't gotten much love from the Problem working group either 😅

Other proposals that came up in discussions are:

  • Delegating the development of solutions to a team of 'wise men' appointed by the IESG.
  • Development of solutions by a design team with final approval by the IESG.
  • Development and implementation of the solutions by the IESG.

Discussions of alternative processes on the mailing list, at the Problem WG meeting at IETF 57, and in the IETF 57 plenary didn't reach a consensus. Some contributors even took the view that the problems could be overcome without (major) structural changes 🤔

So, given the lack of consensus and the lack of extra responses to a previous appeal for alternative suggestions, this document has to fall back on asking the IESG to take responsibility for controlling the development of solutions to the structural problems identified, wherever it believes they are necessary 🎀

6. Conclusion 🌈

The IETF has problems, and we need to work on solving them. That means focused, immediate improvements, and possibly an integrated effort to build an IETF organizational structure and develop processes that can better handle our current size and complexity 💪

BUT, the IETF is also an effective organization with a long tradition of excellence, and it has core values we really don't want to compromise while we improve our organization and processes 💜 So any major changes made in the IETF should include an articulation of the IETF's mission and our core values. That way we can make sure we're building an organization that can carry out our mission while staying in line with those values ✨

The Problem WG hasn't been able to reach a consensus on a process that could address the structural changes that may or may not be needed. This is kind of in line with previous experience with discussing high-level concepts in the IETF. The organization is generally much better at discussing and agreeing on detailed, concrete proposals 🙈 This document really has little alternative but to suggest that the IESG control the development of solutions to any of the structural problems where they feel changes are necessary.

In the meantime, nobody should see this as a reason to hold up discussions on actual solutions for these problems. For example, the active discussions on alternatives to the current maturity level system for IETF standards are still going, and that's a good thing 🙌 Authors of solutions should keep the points from Section 3 in mind: evolutionary rather than revolutionary proposals are more likely to be acceptable, and an orderly transition must be possible 🦋

Working together, we can resolve the problems currently facing the IETF and make it an even more effective, successful, and fun place to work 🌸🫶

7. Security Considerations 🔐

This document contains suggestions for processes the IETF could use to resolve process-related and organizational problems with the IETF. The structure and quality of the IETF's processes may have an effect on the quality of the IETF's security-related work, BUT there are no specific security-related issues raised in this document. Phew 😌

Acknowledgements 💖

The contents of this document were greatly influenced by members of the Problem Statement WG editorial team: Rob Austein, Dave Crocker, Elwyn Davies, Spencer Dawkins, Avri Doria, Jeanette Hofmann, Melinda Shore, and Margaret Wasserman. Thank you all, you're literally the best 👑

Previous versions of this document were edited by Margaret Wasserman, who was responsible for the original structuring of the solution 🧚

In addition to the editorial team, the following people provided useful feedback on earlier versions of this document: Harald Alvestrand, Randy Bush, Brian Carpenter, Leslie Daigle, James Kempf, John Klensin, John Loughney, and Keith Moore. Iconic behavior 🫶

Normative References 📚

[1] Davies, E., "IETF Problem Statement", RFC 3774, May 2004.

[2] Galvin, J., "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", RFC 2727, February 2000.

Informative References 📖

[3] Alvestrand, H., "An IESG charter", Work in Progress, April 2003.

[4] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

[5] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998.

[6] Internet Architecture Board and B. Carpenter, "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000.

[7] Harris, S., "The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force", RFC 3160, August 2001.

[8] IETF, "Minutes of IESG Plenary at IETF55, Atlanta, GA, USA", Nov 2002, <http://www.ietf.org/proceedings/02nov/slides/plenary-2/sld4.htm>.

[9] Davies, E., Doria, A., and J. Hofmann, "IETF Structural Problems Improvement Process", Work in Progress, September 2003.

Authors' Addresses 🖊️

Elwyn B. Davies (editor) Nortel Networks Harlow Laboratories London Road Harlow, Essex CM17 9NA UK

Phone: +44 1279 405 498 EMail: elwynd@nortelnetworks.com

Jeanette Hofmann (editor) Wissenschaftszentrum Berlin Reichpietschufer 50 Berlin 10785 Germany

Phone: +49 30 25491 288 EMail: jeanette@wz-berlin.de

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property ⚖️

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 💌

Acknowledgement 🌷

Funding for the RFC Editor function is currently provided by the Internet Society. The end, bestie 🎀💅

📦 where this page comes from