Network Working Group                                     E. Davies, Ed.
Request for Comments: 3774                               Nortel Networks
Category: Informational                                         May 2004
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.




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.


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  . . . . . .  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
1. 导言:IETF过程中的问题

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.


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.

本文件的原材料是通过总结2002年11月至2003年9月在“wgchairs”邮件列表上以及随后在“问题陈述”邮件列表上进行的广泛讨论得出的,包括在此期间发布的相关草案的额外投入(见[2]、[3]和[3])[4] )和最近全体会议讨论的记录。这产生了一个感知问题列表,使用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
1.1. 过去增长的后果

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.


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
1.2. 目标是改进,而不是指责

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
1.3. 感知问题-解决方案共识

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


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
2. 根本原因问题

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

2.1. IETF的参与者对其任务没有共同的理解

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 IETF不确定其试图实现的目标,因此无法知道其最佳内部组织应该是什么来实现其目标。

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 IETF无法确定其“范围”应该是什么,因此无法决定一项拟议工作是在范围内还是在范围外。

o The IETF is unsure who its stakeholders are. Consequently, certain groups of stakeholder, who could otherwise provide

o IETF不确定其利益相关者是谁。因此,某些利益相关者群体可能会提供

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 工作组可能会被部门利益劫持,从而损害IETF的使命。

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 模糊的愿景阻碍了向IETF的利益相关者告知我们的长期意图的路线图的开发,并将相关的架构视图限制在一个不能完全反映互联网发展本质的概要顶层视图中。对于超出单个工作组的部分工作,最好有路线图和体系结构视图:也可能不再可能在单个体系结构中容纳整个互联网。

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 IETF无法明确确定其希望在市场上产生什么样的影响,因此无法确定在规划工作和为利益相关者设定期望(这将推进IETF的使命)时,什么样的及时性要求是合适的。

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 我们的目标缺乏精确性,导致工作组章程和需求没有得到充分考虑和/或与总体架构不一致。由此产生的不明确的租船合同是导致某些工作组交付质量差和/或延迟以及其他工作组完全失败的一个主要因素。

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.

o IETF需要避免将重点放在过于狭窄的技术范围上,因为这可能会使IETF对“互联网的好处”的看法模糊不清,并且会损害使互联网对最大数量的利益相关者有用的长期目标;这表明允许在IETF中研究相对广泛的主题——交叉施肥一直是IETF的优势之一。

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'


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
2.2. IETF没有始终如一地使用有效的工程实践

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 未能确保工作组对工作组活动的范围,特别是解决方案的预期目的有统一的看法。

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 未能在早期阶段(冻结设计之前)确定需要解决的问题,和/或随后未能确保工作组对需要解决的问题有一致的看法,从而使工作圆满结束。

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 未能确定和阐明可能需要的工程权衡,以满足工作组设定的最后期限,而不会不适当地降低预期客户的“适用性”。

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.

o 持续改进解决方案,使其超出足以满足预期目的对其提出的要求的程度。

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 章程可能不够详细,无法记录工作组应遵循的流程和时间表。可能需要其他文件,如路线图或详细计划。

o Poorly defined success criteria for WGs and individual documents.

o 工作组和个别文件的成功标准定义不清。

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 缺乏文件内容(与总体布局相反)的书面指南或模板,以及旨在实现适当输出质量的审查标准匹配列表。

o Lack of auditing against explicit criteria throughout the standards development process.

o 在整个标准开发过程中缺乏针对明确标准的审计。

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 非工作组直接相关成员的审查员以及主题专家对与文件相关但不一定是直接关注的主题缺乏审查,尤其是早期审查。

o Lack of documentation about likely problem areas that might arise due to interactions with other popular IETF protocols.

o 缺乏关于与其他流行IETF协议交互可能产生的问题区域的文档。

o Lack of metrics to measure the achievement of the desired quality and the performance of both WGs and the whole IETF.

o 缺乏衡量WGs和整个IETF达到预期质量和绩效的指标。

o Lack of metrics and 'post mortem' procedures to drive the improvement of the standards development and other IETF processes.

o 缺乏度量和“事后”程序来推动标准开发和其他IETF过程的改进。

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 缺乏确定某项工作何时超限和/或不可能成功完成的标准,无论是在任何情况下还是在可接受的时间范围内。缺乏延长时限、调整范围或终止工作项目或整个工作组的程序。

o Automated tools to support the engineering process are minimal.

o 支持工程过程的自动化工具很少。

o Despite its commitment to 'running code', the IETF is not proactive in providing ways for developers to verify their implementations of IETF standards.

o 尽管IETF致力于“运行代码”,但在为开发人员提供验证IETF标准实现的方法方面,IETF并不积极主动。

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.


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 项目进入、目标设定、依赖关系识别、协调和跟踪过程都缺失,或者执行效率低于商业组织在相关活动中的标准。依赖关系和协调应涵盖IETF内的其他工作组和IETF与之合作的任何外部SDO。

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 章程经常未能以足够小的粒度设置足够多的里程碑,以评估工作组、个人和文档的进度。此外,工作组通常不会制定更详细的工作计划来完善章程计划。

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.

o 完成一项工作的可接受的最后期限,以及用于确定这些期限的标准,很少(如果有的话)被记录在案。此外,完成工作所需的估计时间通常与实际花费的时间相差很大。这些因素的结合使得确定在要求的时间范围内交付的可行性,然后调整工作范围以满足时间范围要求变得极其困难。

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
2.3. IETF难以处理大型和/或复杂问题

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.


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 IETF在解决跨工作组或区域边界的问题时并不始终有效。

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 IETF不具备工作组间合作、协调或沟通的有效正式机制,包括处理工作组章程中规定的交付物和过程之间的依赖关系。

o The IETF does not have an effective means for defining architectures and frameworks that will shape the work of multiple WGs.

o IETF没有一种有效的方法来定义将影响多个工作组工作的架构和框架。

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


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
2.4. 未正确使用三阶段标准层次结构

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 相对较少的规范现在已经发展到提议的标准(PS)到起草标准(DS)级别,甚至更少到完全标准(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 人们普遍认为,IESG“提高了(质量)标准的门槛”,这些标准必须通过才能被授予PS地位。协议开发人员可能需要指定一个完整的系统,而不是接口,以便将其规范批准为PS(另见第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 尽管存在明显更高的质量障碍,但仍然不需要实施或部署经验,因此IETF的指导原则“大致共识和运行代码”不太可能有效。

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 在运行中似乎存在一个恶性循环,供应商倾向于部署已达到PS的协议,就好像他们已经准备好进行全面生产一样,而不是接受PS级别的标准仍在开发中,并且可能在特性、性能、,以及在有限的试点安装中进行互操作性测试,这与最初的计划是一致的。供应商实现快速上市的热情似乎鼓励了IETF,特别是IESG,努力确保PS的规范在黄金时段准备就绪,并且随着其发展到DS和FS,后续修改将最小化,假设可以努力创建所需的必要适用性和互操作性报告。

o The three stage hierarchy is, accordingly, seen to be excessive.

o 因此,三阶段的等级制度被认为是过度的。

o There is no formal bug reporting or tracking system in place for IETF specifications.

o IETF规范没有正式的缺陷报告或跟踪系统。

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 未在[1]中规定的PS和DS级别上对协议进行定期审查,允许协议在这些较低的成熟度级别上持续较长时间,而该过程通常预期协议会进展或降级到历史状态。

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.

o 在原工作组关闭后,没有任何个人或机构被赋予“维护”规范的任务。通常,只有在意识到需要新版本时,才会更新规范。通常不会试图纠正规范中的错误(无论它们是否影响操作),规范也不会更新以反映规范中已废弃或实际上从未实现的部分。这在一定程度上是因为当前程序将要求标准恢复到PS成熟度水平,即使在进行规范维护时也是如此。即使可以证明这些更改对DS或FS级别的现有协议没有影响或影响很小,也会发生这种情况。

2.5. The IETF's Workload Exceeds the Number of Fully Engaged Participants

2.5. IETF的工作量超过了完全参与的参与者数量

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 尽管许多工作组会议的出席人数可能很多,但在许多情况下,5%或更少的与会者阅读了正在讨论的草案或与将要作出的决定有关的草案。

o Commitments to write, edit, or review a document are not carried out in a timely fashion.

o 未及时履行编写、编辑或审查文件的承诺。

o Little or no response is seen when a request for 'last-call' review is issued, either at WG or IETF level.

o 当在工作组或IETF级别发出“最后一次呼叫”审查请求时,很少或根本看不到响应。

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.


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
2.5.1. 缺乏正式承认

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

2.6. IETF管理结构与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
2.6.1. 权限

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.


2.6.2. Workload of the IESG
2.6.2. 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 与WGs交互

o Understanding network and computer technology in general, and their own area in detail

o 了解网络和计算机技术的一般情况,并详细了解自己的领域

o Cross-pollinating between groups

o 群间异花授粉

o Coordinating with other areas

o 与其他领域协调

o Potentially, managing their Area Directorate team

o 潜在地,管理他们的区域董事团队

o Effectively providing technical management, people-management, and project supervision for their WGs

o 有效地为其工作组提供技术管理、人员管理和项目监督

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.

o 阅读(或至少略读)IETF编制的每一份正式文件,并对所有文件以及该地区工作组编制的所有互联网草案发表意见,了解所有这些规范之间的相互作用。

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'.

o 穿在IESG上:IESG成员工作过度,这不利于他们的健康、幽默和家庭生活,如果IETF工作影响IESG成员的“日常工作”,也可能导致与雇主发生冲突。

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 IETF中的不愉快:IETF利益相关者认为IESG成员反应缓慢,没有完全跟上他们的技术,未能主动管理工作组中的问题,并且无法保持与其他组的沟通渠道畅通。

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.

o 招聘减少:可以想象担任IESG职位的人数正在稳步减少。它主要局限于在大公司工作的人,他们有能力在任命期间派遣IESG成员到IETF。在当前的商业环境中,很少有公司能够证明在相当长的一段时间内抢占重要的工程和业务资源是合理的,并且比他们最好的工程师更有可能提出“标准专业人士”。

2.6.3. Procedural Blockages
2.6.3. 程序性障碍

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
2.6.4. 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.


2.6.5. Avoidance of Procedural Ossification
2.6.5. 避免程序性骨化

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
2.6.6. 影响力集中在少数人手中

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


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
2.6.7. 过度依赖人际关系

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.


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
2.6.8. 技术和程序上诉的困难

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
2.7. 工作组的动态会使问题难以解决

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.


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

2.8. IETF参与者和领导者对自己的角色准备不足

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


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
3. 安全考虑

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
4. 致谢

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

特别感谢Margaret Wasserman对第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

减少问题陈述邮件列表输入的早期部分由Harald Alvestrand完成,后期部分由Elwyn Davies和上述团队完成。总的来说,大约有750项广泛而有思想的贡献(有些贡献是

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.

除编辑团队外,以下人员还就本文件的早期版本提供了额外的投入和有用的反馈:Harald Alvestrand、Randy Bush、Brian Carpenter、James Kempf、John Klesins、John Loughney、Keith Moore。

5. References
5. 工具书类
5.1. Normative References
5.1. 规范性引用文件

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

[1] Bradner,S.,“互联网标准过程——第3版”,BCP 9,RFC 2026,1996年10月。

5.2. Informative References
5.2. 资料性引用

[2] Huston, G. and M. Rose, "A Proposal to Improve IETF Productivity", Work in Progress.

[2] Huston,G.和M.Rose,“提高IETF生产率的建议”,正在进行中。

[3] Blanchet, M., "Suggestions to Streamline the IETF Process", Work in Progress.

[3] Blanchet,M.,“精简IETF流程的建议”,正在进行的工作。

[4] Hardie, T., "Working Groups and their Stuckees", Work in Progress.

[4] Hardie,T.,“工作组及其障碍”,进展中的工作。

[5] Davies, E. and J. Hofmann, Eds., "IETF Problem Resolution Processes", Work in Progress.

[5] Davies,E.和J.Hofmann编辑,“IETF问题解决过程”,正在进行中。

6. Editor's Address
6. 编辑地址

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

Elwyn B.Davies Nortel Networks哈洛实验室伦敦路哈洛,英国埃塞克斯CM17 9NA

   Phone: +44 1279 405 498
   Phone: +44 1279 405 498
7. Full Copyright Statement
7. 完整版权声明

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.

版权所有(C)互联网协会(2004年)。本文件受BCP 78中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。



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.

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息,请参见BCP 78和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


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




Funding for the RFC Editor function is currently provided by the Internet Society.