RFC 3774

IETF Problem Statement

📅 published May 2004, from ietf

IETF Problem Statement 🎀

Okay bestie, this one is RFC 3774 and it's giving "we need to talk about the group chat." 💅 It's an Informational doc by E. Davies, Ed. from Nortel Networks, dated May 2004. It doesn't obsolete or update anything, since its header lists no other RFCs for either. It's a Network Working Group document, Category: Informational. 🦋

Status of this Memo ✨

This memo is for information only, so the Internet community can read it. It is not an Internet standard of any kind 🙅‍♀️ and it can be shared freely with no limits on distribution. 🌸

Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract 💜

Okay so this memo is basically a list of the problems people have noticed in how the IETF is structured, how it works, and how it runs its processes. 🙈 The goal is to name those problems clearly so the IETF community can actually fix them. Lowkey iconic. ✨

The problems were sorted into categories from a big discussion on the 'problem-statement' mailing list that ran from November 2002 to September 2003. Then the team dug into the list to find the root causes underneath it all. 🔥 That result is what the Problem Statement working group uses as its guide for the next step, which is recommending the structures and processes that will actually make the fixes happen. 👑

Table of Contents 🧚

1.  Introduction: Issues/Problems in the IETF Process  . . . . . .  2
    1.1.  Consequences of Past Growth  . . . . . . . . . . . . . .  3
    1.2.  The Aim is Improvement, not Finger-pointing  . . . . . .  4
    1.3.  Perceived Problems - Consensus on Solutions  . . . . . .  4
2.  Root Cause Problems  . . . . . . . . . . . . . . . . . . . . .  5
    2.1.  Participants in the IETF do not have a Common
          Understanding of its Mission . . . . . . . . . . . . . .  5
    2.2.  The IETF does not Consistently use Effective
          Engineering Practices  . . . . . . . . . . . . . . . . .  7
    2.3.  The IETF has Difficulty Handling Large and/or Complex
          Problems . . . . . . . . . . . . . . . . . . . . . . . .  9
    2.4.  Three Stage Standards Hierarchy not properly Utilized  . 11
    2.5.  The IETF's Workload Exceeds the Number of Fully
          Engaged Participants . . . . . . . . . . . . . . . . . . 12
          2.5.1.  Lack of Formal Recognition . . . . . . . . . . . 13
    2.6.  The IETF Management Structure is not Matched to the
          Current Size and Complexity of the IETF  . . . . . . . . 13
          2.6.1.  Span of Authority  . . . . . . . . . . . . . . . 13
          2.6.2.  Workload of the IESG . . . . . . . . . . . . . . 13
          2.6.3.  Procedural Blockages . . . . . . . . . . . . . . 15
          2.6.4.  Consequences of Low Throughput in IESG . . . . . 15
          2.6.5.  Avoidance of Procedural Ossification . . . . . . 15
          2.6.6.  Concentration of Influence in Too Few Hands  . . 16
          2.6.7.  Excessive Reliance on Personal Relationships . . 17
          2.6.8.  Difficulty making Technical and Process Appeals. 18
    2.7.  Working Group Dynamics can make Issue Closure Difficult. 18
    2.8.  IETF Participants and Leaders are Inadequately Prepared
          for their Roles  . . . . . . . . . . . . . . . . . . . . 19
3.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
    5.1.  Normative References . . . . . . . . . . . . . . . . . . 21
    5.2.  Informative References . . . . . . . . . . . . . . . . . 21
6.  Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 21
7.  Full Copyright Statement . . . . . . . . . . . . . . . . . . . 22

1. Introduction: Issues/Problems in the IETF Process 🦋

Okay so the second half of 2002 was when people started noticing that a lot of problems seem to exist in how the Internet Engineering Taskforce (IETF) operates. 😭 Before anyone touches the IETF's procedures and rules to fix them, everyone needs to agree on exactly what problems they're trying to solve. Literally step one. 💅

The Problem Statement working group was set up to write this document. It describes the problems and uses that analysis to suggest processes for tackling them. 🎀

Real talk, read on its own this document can sound super negative. ngl that's a little unfair 🙈 The IETF has put out a huge pile of high quality work, and that's how we ended up with an incredibly successful and everywhere network infrastructure. ✨ So think of this doc as a necessary bit of self-criticism that leads to renewal and more success, not a hit piece. The positive side is covered on purpose in the IETF Problem Resolution Processes document [5], which looks at the core values the IETF has to keep while it fixes the problems participants feel are hurting it right now. 🫶

The raw material came from summarizing two mailing list discussions: the 'wgchairs' list at first, and then the 'problem-statement' list from November 2002 through to September 2003. 🍓 Extra input came from relevant drafts published in that window (see [2], [3] and [4]), plus the minutes from recent plenary discussions. The result was a list of perceived problems, sorted into groups using a classification that comes from the way IETF processes already work. 🌸

This document boiled those perceived problems down to a small set of root cause issues, plus a short list of subsidiary issues that seem to be the most pressing things those root causes are producing. 🔥 That list lives in Section 2.

Section 1.1 explains how the team got to its current view of the root causes. 🧚

The original summary of perceived problems was posted to the Problem Statement Working Group mailing list so it can be looked at in the future. 💜 It still keeps the original classification, so the raw data is there if someone wants to try a different root cause analysis later. Smart, right? 👑

1.1. Consequences of Past Growth 🌈

As the team looked at the IETF's problems, it became clear they aren't brand new, and they aren't symptoms of anything unusual in the science of organizations either. 🙌

The IETF began as a small, focused organization with a clear mission and participants who had been working in the area for a long time. From 1989 to 1999, the IETF grew by a factor of ten or more in both number of participants and volume of work in progress. 📈 That growth got a boost from the IETF's expanding scope, which made the work way more varied. Meanwhile the Internet got more complex, and the requirements placed on it by a much bigger user community changed as the network became central to so many areas of life. 🌍

A lot of the problems and symptoms look like they come from one core issue: the organization didn't fully adapt its management structure and processes to its new, bigger size and the more complicated work. 🙈 The IETF also hasn't clearly defined its future mission now that the original one has been finished or outgrown. Oof. 💀

These are the same struggles plenty of small organizations go through when they try to move from a small group, where things can run informally and basically everyone shares the aims, values, and motivations of the leadership, into a medium sized organization. 🍓 At that point there are too many participants for informal leadership, and newer arrivals either don't fully get the organization's ethos or see it differently. Relatable. 💅

Some IETF participants have been aware of these issues for ages. Records going back to at least 1992 reached similar conclusions. 🦋

1.2. The Aim is Improvement, not Finger-pointing 💖

Many of the problems in this memo have been weirdly persistent over a 15-year period, and they've survived a bunch of personnel changes. 🫠 The team sees them as structural problems, not personnel problems. Nobody should be blamed for any of the perceived problems, no individuals, no exceptions. 🫶 The only goal of this review is to figure out how the IETF can improve itself, so it knows what it's about and gets fit for that purpose as fast as possible. Main character growth arc, but for a whole organization. 👑

1.3. Perceived Problems - Consensus on Solutions 🎀

The working group participants stress that both the long list of problems and the root cause issues derived from them are problems believed to exist by a significant constituency, whether that's on the mailing list, in private discussions, or both. 💜 Many of these problems are also long standing. A very similar list survived from the discussions in the first POISED working group, which happened before the IETF organizational changes approved in 1992. 🧚

The team, along with lots of mailing list contributors, thinks it's important to try and identify what look like the root causes of the perceived problems. Trying to rank the problems or assign them relative importance wouldn't be useful, though. ✨ Rough consensus on an unordered list of real and important root causes is enough. The root causes will guide the work of setting up the processes needed to fix the problems, and the perceived problems can be seen as multiple symptoms of those root causes. That gives people trying to resolve things a solid starting point for reaching consensus on solutions. 🔥

2. Root Cause Problems 🌸

This section is the heart of the analysis 💖. It lists the issues we think sit at the core of the problems. Apart from the first issue, which is fundamental, the problems aren't in any particular priority order, but you'll see they're linked to each other in all kinds of ways. It's giving interconnected web. 🕸️🧚

2.1. Participants in the IETF do not have a Common Understanding of its Mission 🎀

Okay so the big problem here is that the IETF doesn't have a clearly defined, commonly understood Mission 😭. Because of that, the goals and priorities for the IETF as a whole, and for any Working Groups (WGs) that get chartered, are also kind of fuzzy 🌫️.

The IETF needs to figure out its mission in light of how much bigger and more complicated the Internet has gotten, and how much the requirements have changed for the way bigger user community that all its past success created 💅.

Not having a shared mission causes a bunch of problems, and the main ones look like this:

  • The IETF isn't sure what it's trying to achieve, so it can't know what its best internal organization should be to reach those aims 🧩.
  • The IETF can't pin down its 'scope', so it can't decide whether a proposed piece of work is in-scope or out-of-scope 🙈.
  • The IETF isn't sure who its stakeholders are. As a result, some stakeholder groups who could give really important input have basically been sidelined, because they feel the organization doesn't give their input due weight 💔.
  • Working Groups can get hijacked by sectional interests, and that hurts the IETF's mission 😤.
  • That foggy vision has made it hard to build roadmaps that would show stakeholders where we're headed long term. It has also kept the architectural views stuck at an outline top-level picture that doesn't fully capture how the Internet is still developing 🗺️. It would be great to have roadmaps and architectural views for pieces of work that stretch beyond a single working group. It may also be the case that the whole Internet can no longer fit inside a single architecture 🌐.
  • The IETF can't explicitly say what effect it wants to have in the marketplace, so it can't figure out what timeliness requirements make sense when planning work and setting expectations for stakeholders in a way that moves the mission forward ⏰.
  • Because the goals aren't precise, WG charters and requirements end up poorly thought out and/or not lined up with the overall architecture 📉. Those poorly defined charters are a major reason some WGs deliver poor quality and/or late, and why other WGs flat-out fail 💀.
  • The IETF needs to avoid focusing on too narrow a scope of technology, because that would likely blinker its view of 'the good of the Internet' and harm the long-term goal of making the Internet useful to the greatest number of stakeholders 🌈. This is why a relatively wide range of topics should be worked on in the IETF. Cross-fertilization has always been one of the IETF's strengths 🧚.

Another barrier to a common understanding is that the IETF doesn't have a recognized forum where all stakeholders take part and where organization-wide consensus could be reached 🫠. Plenary meetings during regular IETF meetings let a big cross-section of the community share views, but there usually isn't enough time to reach consensus, and there's no single mailing list that every stakeholder can be guaranteed to monitor 📭.

The IETF creates standards, so it's necessarily a Standards Development Organization (SDO). But lots of participants want to set the IETF and its way of working apart from the 'conventional' SDOs, which put a lot of emphasis on corporate involvement and mandated delegates ✨. Outsiders often lump the IETF in with those conventional SDOs, especially detractors, because the differences in the IETF's mission and processes, and the reasons for them, aren't clear 🙄. That can lead to the IETF being misunderstood by other SDOs, which makes communication between SDOs less effective and harms the IETF's ability to achieve its mission 😩.

2.2. The IETF does not Consistently use Effective Engineering Practices 🛠️

Okay, the IETF is literally an organization with 'engineering' in its name, and its participants are super likely to say "Trust me, I'm an engineer!" when they hit a really knotty problem 💅. But at least in some cases, the IETF's engineering practices are extremely ineffective 💀. When I say effective engineering practices, I mean both the techniques used to derive and verify the technical solutions we need, and the management and organizational strategies that are commonly accepted to help with the engineering process 📋.

A major symptom of this gap is that WGs don't consistently produce timely, high-quality, and predictable output 😬. As we talked about in Section 2.1, this is made worse because the IETF currently has a hard time figuring out what's timely, and so what the right deadlines are for delivering WG output ⏳. Some of the contributing problems that get in the way of effective engineering in WGs include:

  • Not making sure the WG has a uniform view of the scope of the WG activity, especially the intended purpose of the solution 🎯.
  • Not identifying the issues that need resolving at an early stage (before the design is frozen), and/or not making sure the WG has a uniform view of the issues that need resolving to bring the work to a satisfactory conclusion 🧊.
  • Not identifying and spelling out the engineering trade-offs that might be needed to hit the deadlines the WG has set, without inappropriately reducing the 'fitness for purpose' for the intended customers ⚖️.
  • Continuing to refine the solution past the point where it's already adequate to meet the requirements placed on it by its intended purpose 🔁.

The IETF standards engineering process isn't set up to deliver iterative process improvement 🙅‍♀️. The particular areas that need work include:

  • The charter may not be detailed enough to document the process and timeline the WG will follow. Additional documents may be needed, such as a roadmap or detailed plans 📝.
  • Success criteria for WGs and individual documents are poorly defined 🤷‍♀️.
  • There's a lack of written guidelines or templates for the content of documents (as opposed to the overall layout), and a lack of matching lists of review criteria designed to achieve appropriate quality in output 📚.
  • There's a lack of auditing against explicit criteria throughout the standards development process 🔍.
  • There's a lack of review, especially early review, by reviewers who aren't directly interested members of the WG, and by subject matter experts for topics that are related to the document but aren't necessarily its immediate focus 👀.
  • There's a lack of documentation about likely problem areas that might come up from interactions with other popular IETF protocols 🔗.
  • There's a lack of metrics to measure whether the desired quality is being achieved, and how WGs and the whole IETF are performing 📊.
  • There's a lack of metrics and 'post mortem' procedures to drive the improvement of standards development and other IETF processes 🪦.
  • There's a lack of criteria for deciding when a piece of work is overrunning and/or is unlikely to be concluded successfully, either at all or within an acceptable time frame. There's also no process for extending the time frame, adjusting the scope, or terminating the work item or the whole Working Group 🚨.
  • Automated tools to support the engineering process are minimal 🤖.
  • Despite its commitment to 'running code', the IETF isn't proactive about providing ways for developers to verify their implementations of IETF standards 🏃‍♀️.

On top of that, IETF processes, and Working Group processes especially, suffer because commonly accepted Project Management techniques aren't regularly applied to the progress of work in the organization 💼. Specifically:

  • Project entry, goal setting, dependency identification, coordination, and tracking processes are either missing or implemented less effectively than the norm for commercial organizations doing related activities. Dependencies and coordination should cover both other WGs within the IETF and any outside SDO the IETF is collaborating with 🤝.
  • Charters regularly fail to set enough milestones, with small enough granularity, for progress of WGs, individuals, and documents to be evaluated. WGs also often don't make more detailed work plans to refine the charter plans 🪜.
  • The acceptable deadlines for finishing a piece of work, and the criteria used to determine them, are rarely, if ever, documented. The estimated time needed to complete the work also often differs widely from the time actually taken. Put together, these factors make it extremely difficult to determine whether delivery within the required time frame is feasible, and then to adjust the scope of the work to fit that time frame 😵‍💫.

One thing the IETF doesn't seem to suffer from is excessive bureaucracy. Information transfer is generally kept to the minimum needed to get the task done 🙌. Any changes introduced need to make sure they don't significantly increase the bureaucratic load, while still recording enough information to allow process improvement 🧠.

Finally, even where the IETF does have Engineering Practices defined, there are often cases where they get ignored or distorted 🫣. One area of particular concern is the tendency for protocols to be assessed and for issues to be resolved mainly through static analysis of the written specification, rather than through practical experiment with 'running code' 🧪. Bestie, we need to fix that, fr fr 💖.

2.3. The IETF has Difficulty Handling Large and/or Complex Problems 🧩

okay so the IETF has historically been most successful with tightly focused problems that don't have a ton of interactions with other parts of the whole solution 💅 but the Internet has gotten way more complex, so those tiny clean problems are becoming the exception, not the rule 😭 the IETF doesn't always seem to be aware of the interactions between protocols that are bound to pop up once something gets deployed in more complicated situations, so it doesn't fully minimize the chances of unwelcome consequences showing up unforeseen when a new protocol goes out 🙈 and this can get worse with inadequate review from outside the WG, as mentioned in Section 2.2 🫶

IETF standardization procedures are optimized for tightly constrained working groups, and they're generally less effective when "engineering in the large" is needed to reach a satisfactory solution ✨ engineering in the large can cover a lot of system design, including:

  • Architecture 🏛️
  • Frameworks 🧱
  • Security 🔐
  • Internationalization 🌍

the IETF has historically standardized protocol components rather than complete systems 🧩 but as we've learned more about how systems on the Internet interact, component design has to take more and more external constraints into account 🦋 and understanding those constraints tends to require more engineering in the large 💜

part of the cause of this difficulty might be that the formal reporting structure of the IETF emphasizes communication between the Internet Engineering Steering Group (IESG) through the ADs and the WGs, and doesn't really rely on inter-WG communications 👀 like, it's giving lonely:

  • The IETF is not consistently effective at resolving issues that cross WG or area boundaries. 😬
  • The IETF does not possess effective formal mechanisms for inter-WG cooperation, coordination, or communication, including the handling of dependencies between deliverables and processes specified in WG charters. 🕸️
  • The IETF does not have an effective means for defining architectures and frameworks that will shape the work of multiple WGs. 🏗️

the IETF also has to work with other SDOs, and the liaison mechanisms for coordination and cooperation don't always work efficiently 🌸 this needs to be fixed, because some of the interactions IETF work has to account for will involve protocols and systems standardized by those other SDOs 💅

a possible consequence of needing more engineering in the large is that protocol specifications have gotten bigger, and as a result they now take longer to develop ⏳ some people perceive this as happening because the IESG has tended to require protocol specifications to specify an entire system, instead of simple component protocols, which leads to feature bloat and applicability only to a narrow range of applications (see also Section 2.4) 🙃 on the other hand, others believe the IESG has approved simple component protocols without an adequate understanding of the systems and contexts they might be used in 🤔 these problems seem to be two more aspects of the general problem the IETF has with handling large and/or complex systems 💖

2.4. Three Stage Standards Hierarchy not properly Utilized 🪜

the current hierarchy of Proposed, Draft, and Full Standard maturity levels for specifications isn't being used the way it was envisioned when the stratification was originally proposed 😭 in practice, the IETF currently has a one-step standards process that subverts the IETF's preference for demonstrating effectiveness through running code in multiple interoperable implementations 🚫 this squashes the process that used to let specifications mature as experience was gained with actual implementations:

  • Relatively few specifications are now progressed beyond Proposed Standard (PS) to Draft Standard (DS) level, and even fewer to Full Standard (FS). 📉
  • It is widely perceived that the IESG has 'raised the (quality) bar' that standards have to pass to be accorded a PS status. Protocol developers may be required to specify a complete system rather than an interface in order for their specification to be approved as a PS (see also Section 2.3). 🧗
  • In spite of the apparently higher quality hurdle, implementation or deployment experience is still not required, so the IETF's guiding principle of 'rough consensus and running code' has less of a chance to be effective. 🥲
  • There appears to be a vicious circle in operation where vendors tend to deploy protocols that have reached PS as if they were ready for full production, rather than accepting that standards at the PS level are still under development and could be expected to be altered after feature, performance, and interoperability tests in limited pilot installations, as was originally intended. 🔁 the enthusiasm of vendors for a rapid time to market seems to have encouraged the IETF in general, and the IESG in particular, to try to ensure that specifications at PS are ready for prime time, and that subsequent modifications will be minimal as they progress to DS and FS, assuming effort can be found to create the necessary applicability and interoperability reports 📝
  • The three stage hierarchy is, accordingly, seen to be excessive. 🙄
  • There is no formal bug reporting or tracking system in place for IETF specifications. 🐛
  • The periodic review of protocols at PS and DS levels specified in [1] is not being carried out, allowing protocols to persist at these lower maturity levels for extended periods of time, whereas the process would normally expect them to progress or be relegated to Historic status. 🕰️
  • No individual or body is given the task of 'maintaining' a specification after the original WG has closed down. Specifications are generally only updated when a need for a new version is perceived. No attempt is normally made to correct bugs in the specification (whether they affect operation or not), and the specification is not updated to reflect parts that have fallen into disuse or were, in fact, never implemented. This is, in part, because the current procedures would require a standard to revert to the PS maturity level, even when specification maintenance is carried out. This occurs even if the changes can be demonstrated to have no or minimal effect on an existing protocol at the DS or FS level. 🧹

2.5. The IETF's Workload Exceeds the Number of Fully Engaged Participants 🙋‍♀️

there are a bunch of ways IETF participants and contributors seem to have become less fully engaged with the IETF processes, like:

  • Although there may be large attendance at many WG meetings, in many cases, 5% or less of the participants have read the drafts under discussion or that have a bearing on the decisions to be made. 📚
  • Commitments to write, edit, or review a document are not carried out in a timely fashion. ⏰
  • Little or no response is seen when a request for 'last-call' review is issued, either at WG or IETF level. 📢

this might be because contributors have less time in their work schedule during the downturn of the Internet business climate between 2001 and 2003 💸 yet that's not the whole story, because there were signs of this effect way back at the height of the Internet's boom in 2000 🤷‍♀️

this problem makes the IETF's existing trouble with timely delivery even worse, and it may weaken the authority of IETF specifications if decisions are seen to be taken by badly informed participants and without widespread review 😬

2.5.1. Lack of Formal Recognition 🏅

beyond RFC Authorship, WG Chair positions, Directorate positions, or IESG and Internet Architecture Board (IAB) membership, the IETF doesn't offer formal recognition of contributions to the IETF 🥺 this is a disincentive to continued engagement and can lead to useful, effective participants leaving because they can't get any recognition (the only currency the IETF has to pay participants 💰), which they use to fuel their own enthusiasm and to justify their continued attendance at IETF meetings to cost-constrained employers 🫠

Note: Using Leadership positions as rewards for good work would probably be damaging to the IETF. This paragraph is meant to indicate the need for other types of rewards. 🚨

2.6. The IETF Management Structure is not Matched to the Current Size and Complexity of the IETF 🏢

the management and technical review processes currently in place were adequate for the older, smaller IETF, but they're apparently not scalable to the current size of the organization 💀 the form of the organization hasn't been significantly modified since 1992, and since then it has undergone considerable further growth 📈 the scope of IETF activities has also been extended as the Internet has become more complex 🌐

2.6.1. Span of Authority 👑

overt authority in the IETF is concentrated in the small number of people sitting on the IESG at any given time 👀 existing IETF processes work to funnel tasks onto this small group (primarily the Area Directors (ADs) in the IESG) 🌀 this concentration slows things down and puts a very large load of responsibility on the shoulders of these people, who are required to act as senior management for Working Group (WG) chairs, as well as acting as quality backstops for the large number of documents the IETF issues 😭 the situation hasn't been helped by the widening of the IETF's scope, which has resulted in somewhat more WGs and a need for a very broad spectrum of knowledge within the set of ADs 🧠✨

2.6.2. Workload of the IESG 🥵

Okay so the IESG workload is giving burnout 😭. With how the IETF and IESG are set up right now, the load on each AD is almost certainly way past what one person can handle 💀.

The current job description for an AD includes at least these tasks:

  • Interacting with WGs
  • Understanding network and computer technology in general, and their own area in detail
  • Cross-pollinating between groups
  • Coordinating with other areas
  • Potentially, managing their Area Directorate team
  • Effectively providing technical management, people-management, and project supervision for their WGs
  • Reading (or at least skimming) every formal document which the IETF produces, and having an opinion on all of them, as well as all the Internet Drafts produced by the WGs in the area, and understanding the interactions between all these specifications.

Bestie, look at that list 😵‍💫. With so many active WGs, the work and the tech getting more complicated, and documents piling up everywhere, it's clear that only superhumans could do this job well 🦸‍♀️. And it gets worse: on paper this is a 'part time' gig 🙃. ADs usually have a regular job, with IETF stuff as just one piece of it. Recent resignations from the IESG back this up, with the size of the workload cited as a main reason 😭. The IETF also has no way to nominate a temporary replacement or an assistant if an AD is incapacitated, fully or partly, for a while 🩹.

The overload has some seriously gross effects 💀:

  • Wear on the IESG: IESG members are overworked, which is bad for their health, humor, and home life 🙈. It can also cause conflicts with their employers if the IETF work starts messing up their 'day job'.
  • Unhappiness in the IETF: Stakeholders feel like IESG members are responding slowly, aren't fully up-to-date with their tech, don't proactively manage problems in their WGs, and can't keep communication channels open with other groups 😤.
  • Recruiting shrinkage: Fewer and fewer people can even imagine taking an IESG post 📉. It's mostly limited to people at large companies that can afford to send IESG members to the IETF for their whole appointment. In today's business climate, fewer companies can justify pulling an important engineering and business resource away for that long, so they're more likely to send 'standards professionals' instead of their best engineers 🥲.

2.6.3. Procedural Blockages 🚧

Here's the tea ☕. The current procedural rules, combined with the management and quality roles of the ADs, can lead to situations where WGs or document authors think one or two ADs are deliberately blocking a WG document without a good reason or a public justification 👀. Appeal options in these situations are limited, and the only sanction that could be applied to those ADs is recall. That's been seen as way out of scale with the apparent offense, so it's almost never invoked 🙅‍♀️. This feeling of invulnerability has led people to believe that the IESG in general, and ADs in particular, aren't accountable enough to their WGs and the IETF at large 😒. The recent introduction of the Internet Draft Tracker tool does help, though, since it makes it easier to see if and how a document has gotten blocked, so people can take the right steps to release it ✨.

2.6.4. Consequences of Low Throughput in IESG 🐢

If documents get delayed or blocked because of IESG (in)action, whether on purpose or by accident, it causes a lot of frustration inside the organization 😩. From the outside, it looks like the IETF is disunited 🫠. It can also delay standards so much that they're too late to match market requirements. Work that has been properly authorized as being within the scope of the IETF, and properly quality checked during development, should almost never run into a blockage like that 🙏.

Delays in authorizing a BOF or chartering a new WG can start the process late too, with similar effects ⏰.

It also seems like IESG delays are sometimes used to excuse what is actually slow work in WGs 👀. Iykyk 💅.

2.6.5. Avoidance of Procedural Ossification 🧱

The IETF's systems and processes are generally designed around having firm general principles, plus a lot of IESG discretion within those principles 🧠. Lowkey, though, the IETF is showing a worrying habit of turning IESG 'rules of convenience' into rigid rules that can't be broken or even bent 😬.

Up to now, IETF discussions about procedures have been driven by a model where the procedural BCPs set up a framework for doing the work, and the IESG fills in the details 🧩. When issues or crises came up, the IETF usually avoided making specific procedural changes to make up for them. The reasoning was that we couldn't predict every case, and 'fighting the last war' is not a good way to go 🪖.

This only keeps working if participants continue to trust the IESG to act fairly when filling in the details and making sensible exceptions, without a ton of debate, when it's clearly the right call 🤝. Right now, the IETF seems to have lost sight of that flexibility. It's getting tangled up in procedures that started as organizational conveniences and have turned into encumbrances 🥴.

2.6.6. Concentration of Influence in Too Few Hands 👑

Until the last couple of years, successive IETF Nominating Committees gave heavy weight to keeping IESG and IAB membership continuous 🔁. So the IETF kind of built an affinity group, which kept re-selecting the same leaders from a small pool of people who had proven themselves competent and committed in the past 🫂.

Members of this affinity group tend to talk more freely with each other and with former members 🗣️. This might be because the group has also developed a cultural outlook that matches the IETF's dominant culture (North American, English speaking) 🌎. Newcomers and others outside the affinity group are reluctant to challenge its apparent authority during debates, so influence stays concentrated in a fairly small group of people 😮‍💨.

This reluctance can get worse for participants from a different cultural background than the dominant one 🌏. They also tend to find it harder to follow the fast, colloquial speaking style of native English speakers, and they can end up effectively left out of the discussion, even when there's maximum help available, like real time Jabber logs and lots of text on presentation slides 📊. Even on mailing lists, people from other cultures may be less forthright than is common in discussions between North Americans 🙊. A person whose first language isn't English might also be daunted by the sheer volume of mail on some lists. Colloquialisms and euphemisms can cause misunderstandings too, if the people using them don't realize it's a problem 🍓.

Another part of the concentration problem happens when ADs have sometimes acted as WG chairs 🪑. That can create a conflict of interest in discussions between the IESG and any WG with an AD as its chair ⚠️. Care is usually taken to have a newly selected AD give up any WG chair positions in their own area. But the conflict can still happen when an AD ends up chairing a WG because it's clearly the right (or only possible) solution from an engineering and know-how point of view 🤓. Plus, given the known workload problem for IESG members, there are real doubts about whether an AD can, or should, take on that extra load 😵.

2.6.7. Excessive Reliance on Personal Relationships 🫶

The IETF is an intensely personal and individualistic organization 💜. Its basic structure is built around individuals as actors, rather than countries, organizations, or companies like in most other SDOs 🧑‍💻.

That shows up in how the IETF gets its work done 🛠️. The NOMCOM process, the WG Chair selection processes, and the activities of WGs all rely on personal knowledge of what other individuals can do, plus an understanding built on experience of what they actually deliver. That's because there are almost no sanctions beyond not asking someone to do a similar task again 🙅‍♀️. It works best when it goes both ways: the person being asked to do a task needs to be able to rely on how the person doing the asking behaves 🤝.

Basically, the IETF runs on a particular kind of one-to-one personal trust 💞. It's a super powerful model, but it doesn't scale well, because trust isn't transitive 🚫. Just because you trust one person doesn't mean you trust everyone that person trusts (like, you don't automatically know what they can do or whether you can rely on them) 🙃.

The disruption is clearest when an AD gets replaced 🔄. The IETF doesn't keep personnel records or written plans, and formal process documentation is very sparse. So incoming ADs have very little information to build new relationships with WG chairs or Directorate members they don't already know 📂.

A new AD has to build up, or bring along, their own set of trusted people 🧑‍🤝‍🧑. They'll tend to prefer people from that set as WG chairs, unless there's a suitable outsider who was part of the team that brought the WG idea to the IETF 🎯. This can really limit the AD's options, especially when they need a 'stabilizing', 'advising', or 'process' chair to work with an enthusiastic newcomer in a difficult area 😓. And when an established relationship breaks down (like between an AD and a WG chair), it can seriously damage the IETF's work, and outsiders might not even notice why 🥀.

Relying on personal relationships also means the IETF has very little institutional 'memory' outside the heads of the people in the process at any given time 🧠. That makes it more likely that failures get repeated, and makes process improvement harder (see Section 2.2) 🔁.

2.6.8. Difficulty making Technical and Process Appeals ⚖️

When someone thinks the process has produced a result that's harmful to the Internet, or thinks IETF processes haven't been followed, there's no mechanism to help that person try to change the result 😭. Not me feeling helpless about it 🥺.

2.7. Working Group Dynamics can make Issue Closure Difficult 🌸

okay so the IETF kinda struggles to make decisions that are timely and reasonable 😭 and that everyone can actually count on sticking around for the rest of a process, unless someone shows they were wrong 💅

The problems in this section are probably the result of the IETF being non-hierarchical and most participants being volunteers 🧚 The enforcement tools you'd find in a more conventional hierarchical corporate setting are mostly not available here, so it's unlikely that applying some well-known procedure or practice will fix these problems 🙈

Participants are frequently allowed to re-open issues that were already closed, just to replay parts of the old discussion without bringing in any new material 💀 This might happen because the decision was never clearly documented, or it might be a sneaky maneuver to get a decision changed because the participant didn't agree with the consensus in the first place. Either way, reopening stuff stops the process from moving forward, and in the worst cases it can completely derail a working group 😩 That said, the decision making process must allow discussions to be re-opened if significant new information comes to light, or if additional experience is gained that appears to justify alternative conclusions for a closed issue. Re-opening isn't bad by itself, it just can't become a habit 🦋

One cause of legitimate attempts to re-open an apparently closed issue is what's called 'consensus by exhaustion' 😮‍💨 Off-topic or overly dogmatic mail storms can subvert the consensus process, and they can push out knowledgeable participants who simply can't devote the time needed to counter the storm. The result may be an unrepresentative and unsatisfactory consensus, which tends to get re-opened, often leading to repeat discussions. Mailing lists are at the heart of the IETF WG process, but they're becoming increasingly ineffective at resolving issues and achieving consensus because of this phenomenon 📭

A single vocal individual or a small group can be a real challenge to WG progress and to the authority of the chair 👑 The IETF doesn't have a strategy for dealing effectively with an individual who is inhibiting progress, while still making sure that someone with a genuine reason for revisiting a decision gets to make their point. That balance is tricky, bestie 🫶

2.8. IETF Participants and Leaders are Inadequately Prepared for their Roles 🎀

Participants and leaders at all levels of the IETF need to be taught the principles of the organization (Mission and Architecture(s)) and trained in carrying out the processes they have to use when developing specifications, etc. ✨

Part of the reason training in the principles is lacking is that there isn't currently an explicit formulation of these principles that's generally agreed upon by all stakeholders 🥺 Section 2.1 identifies that this shortage is a major problem.

The IETF currently has voluntary and inconsistent processes for educating its participants 📚 which may be why significant numbers of participants seem to fail to conform to the proper principles when working in the IETF context. Not ideal, ngl 💀

The people in authority have generally been steeped in the principles of the IETF (as they see them), and first-time non-compliance by newer participants is sometimes treated as an opportunity for abuse, rather than as recognition of a training failure 😤

The IETF culture of openness also tends to tolerate participants who, while understanding the principles of the IETF, disagree with them and actively ignore them. This can be confusing for newer participants, but they need to be made aware that the IETF does not exclude such people 🌈 The IETF does not currently have a strategy for dealing with the conflicts that can result from participants who disagree with the principles of the organization.

Lack of training, compounded with the perceived concentration of influence in the affinity group documented in Section 2.6.6, can lead to newcomers being ignored during discussions. They then become ineffective, either in their own eyes or in their employers' eyes 😭 This may result in their departure from the IETF 💔

In addition, some participants aren't aware of the problems that participants who don't have English as their first language may have with rapid speaking and the use of colloquialisms, in both spoken and written communication 🗣️ They're also not always aware of the possible cultural nuances that may make full participation harder for those who don't share the same outlook 🌍

3. Security Considerations 🔐

This document does not, of itself, have security implications 🙂 but it may have identified problems which raise security considerations for other work. Any such implications should be considered in the companion document which will be produced setting out how the IETF should set about solving the identified problems. Please don't skip that companion doc, it's serious business 🚨

4. Acknowledgements 🫶

Apart from the contributions of all those who provided input on the problem statement mailing list, the final reduction of the problems was especially assisted by the following people:

  • Rob Austein <sra@hactrn.net>
  • Marc Blanchet <Marc.Blanchet@hexago.com>
  • Dave Crocker <dcrocker@brandenburg.com>
  • Spencer Dawkins <spencer@mcsr-labs.org>
  • Avri Doria <avri@psg.com> (WG co-chair)
  • Jeanette Hoffmann <jeanette@wz-berlin.de>
  • Melinda Shore <mshore@cisco.com> (WG co-chair)
  • Margaret Wasserman <margaret@thingmagic.com>

Special thanks are due to Margaret Wasserman for extensive reviewing of, and contributions to, the wording of Section 2 🏆

The early part of the reduction of the problem statement mailing list input was done by Harald Alvestrand, and the latter part by Elwyn Davies and the team acknowledged above. In total, there were approximately 750 extensive and thoughtful contributions (some making several points) 🤯 The thread was started by a call for volunteers in helping draft a problem statement, but it quickly turned into a discussion of what the problems were 😂

In addition to the editorial team, the following people have provided additional input and useful feedback on earlier versions of this document: Harald Alvestrand, Randy Bush, Brian Carpenter, James Kempf, John Klensin, John Loughney, Keith Moore. ✨

5. References 📚

5.1. Normative References

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

5.2. Informative References

  • [2] Huston, G. and M. Rose, "A Proposal to Improve IETF Productivity", Work in Progress.
  • [3] Blanchet, M., "Suggestions to Streamline the IETF Process", Work in Progress.
  • [4] Hardie, T., "Working Groups and their Stuckees", Work in Progress.
  • [5] Davies, E. and J. Hofmann, Eds., "IETF Problem Resolution Processes", Work in Progress.

6. Editor's Address 📬

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

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

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; nor does it 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 and 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. 🌟

📦 where this page comes from