From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3774.txt | 1235 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1235 insertions(+) create mode 100644 doc/rfc/rfc3774.txt (limited to 'doc/rfc/rfc3774.txt') diff --git a/doc/rfc/rfc3774.txt b/doc/rfc/rfc3774.txt new file mode 100644 index 0000000..845518a --- /dev/null +++ b/doc/rfc/rfc3774.txt @@ -0,0 +1,1235 @@ + + + + + + +Network Working Group E. Davies, Ed. +Request for Comments: 3774 Nortel Networks +Category: Informational May 2004 + + + IETF Problem Statement + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). All Rights Reserved. + +Abstract + + This memo summarizes perceived problems in the structure, function, + and processes of the Internet Engineering Task Force (IETF). We are + attempting to identify these problems, so that they can be addressed + and corrected by the IETF community. + + The problems have been digested and categorized from an extensive + discussion which took place on the 'problem-statement' mailing list + from November 2002 to September 2003. The problem list has been + further analyzed in an attempt to determine the root causes at the + heart of the perceived problems: The result will be used to guide the + next stage of the process in the Problem Statement working group + which is to recommend the structures and processes that will carry + out the corrections. + + + + + + + + + + + + + + + + + + + +Davies Informational [Page 1] + +RFC 3774 IETF Problem Statement May 2004 + + +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 + + Discussion started in the second half of 2002 has shown that a + significant number of problems are believed to exist in the way the + Internet Engineering Taskforce (IETF) operates. Before attempting to + change the IETF procedures and rules to deal with these problems, the + IETF should have a clear, agreed-upon description of what problems we + are trying to solve. + + + + + +Davies Informational [Page 2] + +RFC 3774 IETF Problem Statement May 2004 + + + The Problem Statement working group was chartered to create this + document, which contains a description of the problems, and to use + this analysis to suggest processes to address the identified + problems. + + Taken in isolation, this document may appear to be exceedingly + negative. The IETF needs to refresh its management and processes to + address today's challenges, but it should not be forgotten that the + IETF has produced a large body of high quality work which has lead to + an extremely successful and pervasive network infrastructure. + Against this background, we should see the current document as a + necessary piece of self-criticism leading to renewal and continued + success. The discussion of the positive aspects has been + deliberately confined to the IETF Problem Resolution Processes + document [5] which considers the core values that the IETF needs to + maintain whilst correcting the problems that participants perceive as + affecting the IETF at present. + + The raw material for this document was derived by summarizing the + extensive discussions which initially took place on the 'wgchairs' + mailing list and subsequently on the 'problem-statement' mailing list + from November 2002 through to September 2003, incorporating + additional input from relevant drafts published during this period + (see [2], [3] and [4]), and the minutes of recent plenary + discussions. This produced a list of perceived problems which were + classified into a number of related groups using a classification + suggested by the processes which go on in the IETF. + + This document has digested these perceived problems into a small set + of root cause issues, and a short list of subsidiary issues which + appear to be the most pressing items engendered by the root cause. + This list is set out in Section 2. + + Section 1.1 gives a short explanation of the thinking that has taken + place in coming to the current view of the root causes. + + The original summary of perceived problems has been posted to the + Problem Statement Working Group mailing list so that it can be + referred to in future. Note that it remains classified according the + original scheme so that the raw data is available if alternative root + cause analysis is needed. + +1.1. Consequences of Past Growth + + As the problems of the IETF were examined, it became clear that they + are neither new nor are they symptoms of a problem which is novel in + the science of organizations. + + + + +Davies Informational [Page 3] + +RFC 3774 IETF Problem Statement May 2004 + + + The IETF started off as a small, focused organization with a clearly + defined mission and participants who had been working in this area + for a significant period of time. Over the period 1989-1999, the + IETF grew by a factor of ten or more in terms of number of + participants, and volume of work in progress. The effects of this + growth have been compounded by the extension of the scope of the IETF + which makes the work much more varied. Also during this period, the + Internet has become more complex and the requirements placed on it by + a far larger user community have changed as the network has come to + have a pivotal role in many areas of life. + + Many of the problems and symptoms appear to be fundamentally caused + by the organization failing to fully adapt its management structure + and processes to its new larger size and the increased complexity of + the work. The IETF has also failed to clearly define its future + mission now that the initial mission has been completed or outgrown. + + These failures are just those that afflict many small organizations + trying to make the transition from a small organization, which can be + run informally and where essentially all participants fully share the + aims, values, and motivations of the leadership, to a medium sized + organization, where there are too many participants for informal + leadership and later arrivals either do not fully understand or have + a different perception of the ethos of the organization. + + Some IETF participants have been aware of these issues for a long + time. Records dating back to at least 1992 drew similar conclusions. + +1.2. The Aim is Improvement, not Finger-pointing + + Many of the problems identified in this memo have been remarkably + persistent over a 15-year period, surviving a number of changes in + personnel. We see them as structural problems, not personnel + problems. Blame for any of the perceived problems should not be + directed to any individual. The sole aim of this review process is + to identify how the IETF can improve itself so that it knows what it + is about and becomes fit for that purpose in the shortest possible + time frame. + +1.3. Perceived Problems - Consensus on Solutions + + The working group participants emphasize that both the long list of + problems and the root cause issues that were derived from them are + problems that are believed to exist by a significant constituency, + either on the mailing list and/or in private discussions. We also + note that many of these problems appear to be of long standing, as a + + + + + +Davies Informational [Page 4] + +RFC 3774 IETF Problem Statement May 2004 + + + very similar list has survived from the discussions in the first + POISED working group that took place prior to the IETF organizational + changes approved in 1992. + + We, in line with many contributors to the mailing list, believe that + it is important to try and identify what appear to be the root causes + of the perceived problems, but trying to prioritize or assign a + relative importance to the problems would not be useful: rough + consensus on an unordered list of real and important root causes will + be sufficient. The root causes identified will provide a guide in + setting up the processes needed to resolve the problems: the + perceived problems can be viewed as multiple symptoms of the root + causes which should provide input to those trying to resolve the + problems in achieving consensus on solutions. + +2. Root Cause Problems + + This section forms the heart of this analysis, and lists the issues + which we believe lie at the core of the problems. Apart from the + first issue which is fundamental, the problems are not necessarily in + priority order, but they will be seen to be interlinked in various + ways. + +2.1. Participants in the IETF do not have a Common Understanding of + its Mission + + The IETF lacks a clearly defined and commonly understood Mission: as + a result, the goals and priorities for the IETF as a whole and any + Working Groups (WGs) that are chartered are also unclear. + + The IETF needs to understand its mission in the context of the + greatly increased scope and complexity of the Internet, and the + changing requirements of the much larger user community that the + success of its previous work has engendered. + + The lack of a common mission has many consequences, of which the + principal ones appear to be: + + o The IETF is unsure what it is trying to achieve and hence cannot + know what its optimum internal organization should be to achieve + its aims. + + o The IETF cannot determine what its 'scope' should be, and hence + cannot decide whether a piece of proposed work is either in-scope + or out-of-scope. + + o The IETF is unsure who its stakeholders are. Consequently, + certain groups of stakeholder, who could otherwise provide + + + +Davies Informational [Page 5] + +RFC 3774 IETF Problem Statement May 2004 + + + important input to the process, have been more or less sidelined + because it has seemed to these stakeholders that the organization + does not give due weight to their input. + + o Working Groups can potentially be hijacked by sectional interests + to the detriment of the IETF's mission. + + o The misty vision has inhibited the development of roadmaps that + would inform the IETF's stakeholders of our longer term + intentions, as well as restricting the associated architectural + views to an outline top level view which does not fully reflect + the developing nature of the Internet. It would be desirable to + have roadmaps and architectural views for portions of work which + extend beyond a single working group: it may also be the case + that it is no longer possible to fit the whole Internet within a + single architecture. + + o The IETF is unable to determine explicitly what effect it desires + to have in the marketplace, and is therefore unable to determine + what requirements of timeliness are appropriate when planning work + and setting expectations for stakeholders which will further the + IETF's mission. + + o The lack of precision regarding our goals leads to WG charters and + requirements that are poorly thought out and/or not aligned with + the overall architecture. The resulting poorly defined charters + are a major factor in poor quality and/or late deliveries from + some WGs and the total failure of other WGs. + + o The IETF needs to avoid focusing on a too-narrow scope of + technology because this would be likely to blinker the IETF's view + of 'the good of the Internet', and will harm the long-term goal of + making the Internet useful to the greatest number stakeholders; + this argues for allowing a relatively wide range of topics to be + worked on in the IETF - cross-fertilization has always been one of + the IETF's strengths. + + An additional barrier to achieving a common understanding is that the + IETF does not have a recognized forum in which all stakeholders + participate and in which organization wide consensus might be + reached. Plenary meetings during regular IETF meetings allow a large + cross-section of the community to offer views, but there is not + generally sufficient time to achieve consensus and there is no single + mailing list which all stakeholders can be guaranteed to monitor. + + The IETF creates standards and is therefore necessarily a Standards + Development Organization (SDO), but many participants would like to + differentiate the IETF and its way of working from the 'conventional' + + + +Davies Informational [Page 6] + +RFC 3774 IETF Problem Statement May 2004 + + + SDOs which emphasize corporate involvement and mandated delegates. + Externally, the IETF is often classified with these conventional + SDOs, especially by detractors, because the differentiation in the + IETF's mission and processes and the rationale for those differences + are not clear. This can lead to the IETF being misunderstood by + other SDOs which can make communications between SDOs less effective, + harming the IETF's ability to achieve its mission. + +2.2. The IETF does not Consistently use Effective Engineering Practices + + For an organization with 'engineering' in its title and participants + who are likely to trot out the statement "Trust me, I'm an engineer!" + when confronted with the need to find a solution to a particularly + knotty problem, the IETF has, at least in some cases, extremely + ineffective engineering practices. Effective engineering practices, + as used here, covers both the techniques used to derive and verify + the technical solutions needed, and the management and organizational + strategies that are commonly accepted to help with the engineering + process. + + A major symptom of this lack is that WGs do not consistently produce + timely, high-quality, and predictable output. As discussed in + Section 2.1, this problem is exacerbated because the IETF currently + finds it difficult to determine what is timely, and hence what are + appropriate deadlines for the delivery of WG output. Some of the + contributing problems which interfere with effective engineering in + WGs include: + + o Failure to ensure that there is a uniform view in the WG of the + scope of the WG activity, especially the intended purpose of the + solution. + + o Failure to identify the issues that need to be resolved at an + early stage (before the design is frozen), and/or then to ensure + that there is a uniform view in the WG of the issues that need to + be resolved to bring the work to a satisfactory conclusion. + + o Failure to identify and articulate engineering trade-offs that may + be needed to meet the deadlines that the WG has set without + inappropriately reducing the 'fitness for purpose' for the + intended customers. + + o Continued refinement of the solution beyond the point at which it + is adequate to meet the requirements placed on it by the intended + purpose. + + + + + + +Davies Informational [Page 7] + +RFC 3774 IETF Problem Statement May 2004 + + + The IETF standards engineering process is not set up to deliver + iterative process improvement. Particular areas that need + improvement include: + + o The charter may not be sufficiently detailed to document the + process and timeline to be followed by the WG. Additional + documents may be needed, such as a roadmap or detailed plans. + + o Poorly defined success criteria for WGs and individual documents. + + o Lack of written guidelines or templates for the content of + documents (as opposed to the overall layout) and matching lists of + review criteria designed to achieve appropriate quality in output. + + o Lack of auditing against explicit criteria throughout the + standards development process. + + o Lack of review, especially early review, by reviewers who are not + directly interested members of the WG, and by subject matter + experts for topics related to, but not necessarily the immediate + focus of the document. + + o Lack of documentation about likely problem areas that might arise + due to interactions with other popular IETF protocols. + + o Lack of metrics to measure the achievement of the desired quality + and the performance of both WGs and the whole IETF. + + o Lack of metrics and 'post mortem' procedures to drive the + improvement of the standards development and other IETF processes. + + o Lack of criteria for determining when a piece of work is + overrunning and/or is unlikely to be concluded successfully, + either at all or within an acceptable time frame. Lack of process + for extending the time frame, adjusting the scope, or terminating + the work item or the whole Working Group. + + o Automated tools to support the engineering process are minimal. + + o Despite its commitment to 'running code', the IETF is not + proactive in providing ways for developers to verify their + implementations of IETF standards. + + In addition, IETF processes, and Working Group processes in + particular, suffer because commonly accepted Project Management + techniques are not regularly applied to the progress of work in the + organization. + + + + +Davies Informational [Page 8] + +RFC 3774 IETF Problem Statement May 2004 + + + o Project entry, goal setting, dependency identification, + coordination, and tracking processes are all either missing or + implemented less effectively than the norm for commercial + organizations in related activities. Dependencies and + coordination should cover both other WGs within the IETF and any + outside SDO with which the IETF is collaborating. + + o Charters regularly fail to set enough milestones with sufficiently + small granularity at which progress of WGs, individuals, and + documents can be evaluated. Also, WGs often do not make more + detailed work plans to refine the charter plans. + + o The acceptable deadlines for finishing a piece of work, and the + criteria used to determine them, are rarely, if ever, documented. + Also, the estimated time required to complete the work often + differs widely from the time actually taken. The combination of + these factors makes determining the feasibility of delivering + within the required time frame, and then adjusting the scope of + the work to fit the time frame requirements, extremely difficult. + + One problem which the IETF does not appear to suffer from is + excessive bureaucracy, in the sense that transfer of information is + generally kept to the minimum necessary to accomplish the task. It + is important that any changes introduced do not significantly + increase the bureaucratic load whilst still recording sufficient + information to allow process improvement. + + Finally, even where the IETF does have Engineering Practices defined, + there are frequently cases where they are ignored or distorted. One + area of particular concern is the tendency for protocols to be + assessed and issues resolved primarily through static analysis of the + written specification rather than by practical experiment with + 'running code'. + +2.3. The IETF has Difficulty Handling Large and/or Complex Problems + + The IETF has historically been most successful when dealing with + tightly focused problems that have few interactions with other parts + of the total problem solution. Given that the Internet has become + more complex, such tightly focused problems are becoming the + exception. The IETF does not always seem to be aware of the + interactions between protocols that are bound to be thrown up by + deployment in more complex situations and so fails to minimize the + chances of unwelcome consequences arising unforeseen when a new + protocol is deployed. This may be exacerbated by inadequate review + from outside the WG as suggested in Section 2.2. + + + + + +Davies Informational [Page 9] + +RFC 3774 IETF Problem Statement May 2004 + + + IETF standardization procedures are optimized for tightly constrained + working groups and are generally less effective if 'engineering in + the large' is needed to reach a satisfactory solution. Engineering + in the large can encompass many aspects of system design including: + + Architecture + Frameworks + Security + Internationalization + + The IETF has historically standardized protocol components rather + than complete systems, but as we have learned more about the ways in + which systems on the Internet interact, design of components needs to + take into account more and more external constraints, and the + understanding of these constraints tends to require more engineering + in the large. + + Part of the cause of this difficulty may 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 + does not place much reliance on inter-WG communications: + + o The IETF is not consistently effective at resolving issues that + cross WG or area boundaries. + + o 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. + + o 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 do not always work efficiently. + This needs to be remedied because some of the interactions which IETF + work has to take into account will involve protocols and systems + standardized by these other SDOs. + + A possible consequence of the need for more engineering in the large + is that protocol specifications have become larger: as a result they + now take longer to develop. Some people perceive that this is + because the IESG has tended to require protocol specifications to + specify an entire system, instead of simple component protocols, + leading to feature bloat and applicability only to a narrow range of + applications (see also Section 2.4). On the other hand, others + believe that the IESG has approved simple component protocols without + + + +Davies Informational [Page 10] + +RFC 3774 IETF Problem Statement May 2004 + + + an adequate understanding of the systems and contexts in which the + protocols might be used. These problems appear to be two additional + aspects of the general problem that 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 is no longer being used in the way that 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 + compresses the process that previously allowed specifications to + mature as experience was gained with actual implementations: + + o Relatively few specifications are now progressed beyond Proposed + Standard (PS) to Draft Standard (DS) level, and even fewer to Full + Standard (FS). + + o 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). + + o 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. + + o 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 to achieve a rapid time to market seems to + have encouraged the IETF in general and the IESG in particular to + attempt to ensure that specifications at PS are ready for prime + time, and that subsequent modifications will be minimal as it + progresses to DS and FS, assuming effort can be found to create + the necessary applicability and interoperability reports that are + needed. + + o The three stage hierarchy is, accordingly, seen to be excessive. + + + + + +Davies Informational [Page 11] + +RFC 3774 IETF Problem Statement May 2004 + + + o There is no formal bug reporting or tracking system in place for + IETF specifications. + + o The periodic review of protocols at PS and DS levels specified in + [1] are not being carried out, allowing protocols to persist in + these lower maturity levels for extended periods of time, whereas + the process would normally expect them to progress or be relegated + to Historic status. + + o 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 of the + specification 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 number of respects in which IETF participants and + contributors appear to have become less fully engaged with the IETF + processes, for example: + + o 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. + + o Commitments to write, edit, or review a document are not carried + out in a timely fashion. + + o 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 available in their + work schedule during the downturn of the Internet business climate + between 2001 and 2003. Yet, this is not the whole story, as there + were signs of this effect back at the height of the Internet's boom + in 2000. + + + + + + +Davies Informational [Page 12] + +RFC 3774 IETF Problem Statement May 2004 + + + This problem exacerbates the problems the IETF has had with timely + delivery and 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 does + not offer formal recognition of contributions to the IETF. This + potentially acts as a disincentive to continued engagement and can + lead to useful and effective participants leaving because they cannot + obtain any recognition (the only currency the IETF has to pay + participants), which they use to fuel their own enthusiasm and help + 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 are apparently not scalable + to the current size of the organization. The form of the + organization has not been significantly modified since 1992, since + when the organization 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 that time. Existing IETF processes + work to funnel tasks on to this small number of people (primarily the + Area Directors (ADs) in the IESG). This concentration slows process + and puts a very large load of responsibility on the shoulders of + these people who are required to act as the senior management for + Working Group (WG) chairs, as well as acting as quality backstops for + the large number of documents issued by the IETF. The situation has + not been helped by the widening of the scope of the IETF, which has + resulted in somewhat more WGs and a need for a very broad spectrum of + knowledge within the set of ADs. + + + + + + + + +Davies Informational [Page 13] + +RFC 3774 IETF Problem Statement May 2004 + + +2.6.2. Workload of the IESG + + With the current structure of the IETF and IESG, the workload imposed + on each of the ADs is almost certainly well beyond the capabilities + of a single person. + + The current job description for an AD encompasses at least the + following tasks: + + o Interacting with WGs + + o Understanding network and computer technology in general, and + their own area in detail + + o Cross-pollinating between groups + + o Coordinating with other areas + + o Potentially, managing their Area Directorate team + + o Effectively providing technical management, people-management, and + project supervision for their WGs + + o 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. + + Given the number of WGs which are now active, the increasing + complexity of both the work being undertaken and the technology in + general, together with the volume of documents being produced, makes + it clear that only superhumans can be expected to do this job well. + To make matters worse, these tasks are, in theory, a 'part time' + occupation. ADs will normally have a conventional job, with the IETF + activities as just one part of their job specification. This view + has been reinforced by recent resignations from the IESG, citing the + size of the workload as a primary factor. The IETF also has no + mechanisms to nominate a temporary replacement or an assistant should + an AD be incapacitated wholly or partially for a period. + + The malign effects of this overload include: + + o Wear on the IESG: The IESG members are overworked which is bad + for their health, humor, and home life, and may also result in + conflicts with their employers if the IETF work impacts the IESG + member's performance of their 'day job'. + + + + + +Davies Informational [Page 14] + +RFC 3774 IETF Problem Statement May 2004 + + + o Unhappiness in the IETF: IETF stakeholders perceive that IESG + members are responding slowly, are not fully up-to-date with their + technology, fail to pro-actively manage problems in their WGs, and + are unable to keep communication channels with other groups open. + + o Recruiting shrinkage: The number of people who can imagine taking + on an IESG post is steadily decreasing. It is largely limited to + people who work for large companies who can afford to send IESG + members to the IETF for the duration of their appointments. In + the current business climate, fewer companies are able to justify + the preemption of an important engineering and business resource + for a significant period of time, and are more likely to put + forward 'standards professionals' than their best engineers. + +2.6.3. Procedural Blockages + + The current procedural rules combined with the management and quality + roles of the ADs can lead to situations where WGs or document authors + believe that one or two ADs are deliberately blocking the progress of + a WG document without good reason or public justification. Appeal + processes in these circumstances are limited and the only sanction + that could be applied to the relevant ADs is recall, which has almost + always been seen to be out of scale with the apparent offense and + hence almost never invoked. This perception of invulnerability has + led to a view that the IESG in general and the ADs in particular are + insufficiently accountable for their actions to their WGs and the + IETF at large, although the recent introduction of the Internet Draft + Tracker tool makes it easier to determine if and how a document has + become blocked, and hence to take appropriate steps to release it. + +2.6.4. Consequences of Low Throughput in IESG + + If documents are inappropriately (or even accidentally) delayed or + blocked as a result of IESG (in)action, this can cause much + frustration inside the organization, a perception of disunity seen + from outside the organization, and delay of standards, possibly to + the point where they are too late to match market requirements: work + which has been properly authorized as being within the scope of the + IETF and properly quality checked during development, should almost + never come up against such a blockage. + + Delay in authorizing a BOF or chartering a new WG can delay the start + of the process with similar effects. + + It also appears that IESG delays are sometimes used to excuse what is + actually slow work in WGs. + + + + + +Davies Informational [Page 15] + +RFC 3774 IETF Problem Statement May 2004 + + +2.6.5. Avoidance of Procedural Ossification + + The systems and processes used by the IETF are generally designed + around having firm general principles and considerable IESG + discretion within those principles. It appears that the IETF is + showing a disturbing tendency to turn IESG 'rules of convenience' + into rigid strictures that cannot be violated or deviated from. + + Up to now, IETF discussions of procedures have been driven by a model + in which the procedural BCPs construct a framework for doing work, + but the details of the framework are left for the IESG to fill in. + When issues or crises have arisen, the IETF has generally avoided + making specific procedural changes to compensate, instead realizing + that we could not anticipate all cases and that 'fighting the last + war' is not a good way to proceed. + + This can only continue to work if the participants continue to trust + the IESG to act fairly in filling in the details and making + appropriate exceptions, without a great deal of debate, when it is + clearly desirable. At present, the IETF appears to have lost sight + of this flexibility, and is entangling itself in procedures that + evolve from organizational conveniences into encumbrances. + +2.6.6. Concentration of Influence in Too Few Hands + + Until the last couple of years, successive IETF Nominating Committees + have chosen to give heavy weighting to continuity of IESG and IAB + membership. Thus, the IETF appeared to have created an affinity + group system which tended to re-select the same leaders from a + limited pool of people who had proved competent and committed in the + past. + + Members of this affinity group tend to talk more freely to each other + and former members of the affinity group - this may be because the + affinity group has also come to share a cultural outlook which + matches the dominant cultural ethos of the IETF (North American, + English speaking). Newcomers to the organization and others outside + the affinity group are reluctant to challenge the apparent authority + of the extended affinity group during debates and consequently + influence remains concentrated in a relatively small group of people. + + This reluctance may also be exacerbated if participants come from a + different cultural background than the dominant one. Such + participants also tend to find it more difficult to follow the rapid + and colloquial speaking style of native English speakers, and may + consequently be effectively excluded from the discussion, even if + maximum assistance is available by such means as real time Jabber + logs and extensive text on presentation slides. Even on mailing + + + +Davies Informational [Page 16] + +RFC 3774 IETF Problem Statement May 2004 + + + lists, people from other cultures may be reluctant to be as + forthright as is often the case in discussions between North + Americans; also, a person whose first language is not English may be + daunted by the volume of mail that can occur on some mailing lists + and the use of colloquialisms or euphemisms may cause + misunderstandings if correspondents are not aware of the problem. + + A further instance of the problems of concentration of influence + potentially occurs when, from time to time, ADs have acted as WG + chairs: conflict of interest might well arise in discussions between + the IESG and any WG with an AD as its chair. Whilst care is usually + taken to have a newly selected AD vacate any WG chair positions which + might be held in his or her own area, the conflict can arise on the + occasions when an AD has been used as the chair of a WG because it is + clearly the right (or only possible) solution for the WG from an + engineering and know-how position. Furthermore, given the known + problem of workload for IESG members, there must be doubts as to + whether an AD can or ought to be taking on this extra load. + +2.6.7. Excessive Reliance on Personal Relationships + + The IETF is an intensely personal and individualistic organization. + Its fundamental structure is based on individuals as actors, rather + than countries, organizations, or companies as in most other SDOs. + + This is also reflected in how the IETF gets its work done: the NOMCOM + process, the WG Chair selection processes, and the activities of WGs + are all reliant on personal knowledge of the capabilities of other + individuals and an understanding built on experience of what they can + be expected to deliver, given that there are almost no sanctions that + can be applied beyond not asking them to do a similar task again. + The relationship works best when it is two way - the person being + asked to perform a task needs to be able to rely on the behavior of + the person doing the asking. + + In essence, the IETF is built on a particular kind of one-to-one + personal trust relationship. This is a very powerful model but it + does not scale well because this trust is not transitive. Just + because you trust one person, it does not mean that you trust (i.e., + know the capabilities of and can rely on) all the people that person + trusts in turn. + + The disruption caused when one set of relationships has to be + replaced by another is clearest when an AD is replaced. The IETF + does not keep personnel records or written plans, and formal process + documentation is very sparse, so that incoming ADs have little + information on which to base new relationships with WG chairs or + Directorate members not already known to them. + + + +Davies Informational [Page 17] + +RFC 3774 IETF Problem Statement May 2004 + + + A new AD has to build or bring along his or her set of trusted + individuals. The AD will tend to prefer individuals from this set as + WG chairs, unless there is a suitable outsider who was part of the + team that brought the WG idea to the IETF. This tends to limit the + AD's field of choice, particularly when asking for a 'stabilizing', + 'advising', or 'process' chair to work with an enthusiastic newcomer + in a difficult area. A breakdown of an established relationship + (such as between an AD and a WG chair) can be very damaging to the + work of the IETF, and it may not be immediately obvious to outsiders. + + Another consequence of the reliance on personal relationships is that + the IETF has very little institutional 'memory' outside the memories + of the people in the process at a given time. This makes it more + likely that failures will be repeated and makes process improvement + more difficult (see Section 2.2). + +2.6.8. Difficulty making Technical and Process Appeals + + When an individual thinks that the process has produced a result that + is harmful to the Internet or thinks that IETF processes have not + been adhered to, there is no mechanism to aid that individual in + seeking to change that result. + +2.7. Working Group Dynamics can make Issue Closure Difficult + + The IETF appears to be poor at making timely and reasonable decisions + that can be guaranteed to be adhered to during the remainder of a + process or until shown to be incorrect. + + The problems documented in this section are probably consequences of + the non-hierarchical organization of the IETF and the volunteer + status of most participants. The enforcement measures available in a + more conventional hierarchical corporate environment are mostly not + available here, and it is unlikely that application of some well- + known procedure or practice will fix these problems. + + Participants are frequently allowed to re-open previously closed + issues just to replay parts of the previous discussion without + introducing new material. This may be either because the decision + has not been clearly documented, or it may be a maneuver to try to + get a decision changed because the participant did not concur with + the consensus originally. In either case, revisiting decisions stops + the process from moving forward, and in the worst cases, can + completely derail a working group. On the other hand, the decision + making process must allow discussions to be re-opened if significant + new information comes to light or additional experience is gained + which appears to justify alternative conclusions for a closed issue. + + + + +Davies Informational [Page 18] + +RFC 3774 IETF Problem Statement May 2004 + + + One cause that can lead to legitimate attempts to re-open an + apparently closed issue is the occurrence of 'consensus by + exhaustion'. The consensus process can be subverted by off-topic or + overly dogmatic mail storms which can lead to the exclusion of + knowledgeable participants who are unable to devote the time needed + to counter the mail storm. The consequence may be an + unrepresentative and unsatisfactory consensus which will tend to be + re-opened, often leading to repeat discussions. Mailing lists, which + are at the heart of the IETF WG process, are becoming increasingly + ineffective at resolving issues and achieving consensus because of + this phenomenon. + + A single vocal individual or small group can be a particular + challenge to WG progress and the authority of the chair. The IETF + does not have a strategy for dealing effectively with an individual + who is inhibiting progress, whilst ensuring that an individual who + has a genuine reason for revisiting a decision is allowed to get his + or her point across. + +2.8. IETF Participants and Leaders are Inadequately Prepared for + their Roles + + Participants and leaders at all levels in the IETF need to be taught + the principles of the organization (Mission and Architecture(s)) and + trained in carrying out the processes, which they have to use in + developing specifications, etc. + + Part of the reason for the lack of training in the principles of the + organization is that there is not currently an explicit formulation + of these principles that is 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. + + 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 recognition of a training failure. + + The IETF culture of openness also tends to tolerate participants who, + whilst 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 + + + +Davies Informational [Page 19] + +RFC 3774 IETF Problem Statement May 2004 + + + 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, consequently being + ineffective, either in their own eyes or their employers. This may + result in their departure from the IETF. + + In addition, some participants are not aware of the problems that + participants, who do not have English as their first language, may + have with rapid speaking and the use of colloquialisms in both spoken + and written communication. They are also not always aware of the + possible cultural nuances that may make full participation more + difficult for those who do not 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. + +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 + Marc Blanchet + Dave Crocker + Spencer Dawkins + Avri Doria (WG co-chair) + Jeanette Hoffmann + Melinda Shore (WG co-chair) + Margaret Wasserman + + 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 + + + + + +Davies Informational [Page 20] + +RFC 3774 IETF Problem Statement May 2004 + + + several points). The thread was started by a call for volunteers in + helping draft a problem statement, but 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 + + + + + + + + + + +Davies Informational [Page 21] + +RFC 3774 IETF Problem Statement May 2004 + + +7. Full Copyright Statement + + 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. + + + + + + + + + +Davies Informational [Page 22] + -- cgit v1.2.3