RFC3774 日本語訳

3774 IETF Problem Statement. E. Davies, Ed.. May 2004. (Format: TXT=55172 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                     E. Davies, Ed.
Request for Comments: 3774                               Nortel Networks
Category: Informational                                         May 2004

ワーキンググループのE.デイヴィース、エドをネットワークでつないでください。コメントのために以下を要求してください。 3774 ノーテルはカテゴリをネットワークでつなぎます: 情報の2004年5月

                         IETF Problem Statement

IETF問題声明

Status of this Memo

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

Copyright(C)インターネット協会(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.

このメモはインターネット・エンジニアリング・タスク・フォース(IETF)の構造、機能、および過程による知覚された問題をまとめます。 私たちは、IETF共同体がそれらを記述して、修正できるように、これらの問題を特定するのを試みています。

   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.

問題は、'問題声明'メーリングリストで2002年11月から2003年9月まで行われた大規模な議論から、読みこなされて、分類されました。 問題リストは知覚された問題の心で根本的原因を決定する試みでさらに分析されました: 結果は、Problem Statementワーキンググループにおける修正を行う構造と過程を推薦することである過程の次のステージを誘導するのに使用されるでしょう。

Davies                       Informational                      [Page 1]

RFC 3774                 IETF Problem Statement                 May 2004

[1ページ]RFC3774IETF問題声明2004年5月の情報のデイヴィース

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. 序論: IETFの問題/問題は.21.1を処理します。 過去の成長. . . . . . . . . . . . . . 3 1.2の結果。 AimはFinger-指す.41.3ではなくImprovementです。 ソリューション. . . . . . 4 2で問題--コンセンサスを知覚しました。 原因問題. . . . . . . . . . . . . . . . . . . . . 5 2.1を根づかせてください。 IETFの関係者はMission. . . . . . . . . . . . . . 5 2.2のCommon Understandingを持っていません。 IETFはどんなConsistentlyにも使用Effective Engineering Practices. . . . . . . . . . . . . . . . . 7 2.3しません。 IETFには、困難の取り扱いの大きい、そして/または、複雑な問題. . . . . . . . . . . . . . . . . . . . . . . . 9 2.4があります。 3Stage Standards Hierarchy、適切でない、Utilized. 11 2.5 IETFのワークロードは完全に従事した関係者. . . . . . . . . . . . . . . . . . 12 2.5.1の数を超えています。 正式な認識. . . . . . . . . . . 13 2.6の不足。 IETF Management StructureはCurrent SizeとIETF. . . . . . . . 13 2.6.1のもののComplexityへのMatchedではありません。 権威. . . . . . . . . . . . . . . 13 2.6.2の長さ。 IESG. . . . . . . . . . . . . . 13 2.6.3のもののワークロード。 手続き上の封鎖. . . . . . . . . . . . . . 15 2.6.4。 IESG. . . . . 15 2.6.5における、少ないスループットの結果。 手続き上の骨化. . . . . . 15 2.6.6の回避。 あまりにわずかの影響の集中は.7に.162.6を手渡します。 個人的な関係. . 17 2.6.8への過度の信用。 TechnicalとProcess Appealsを作ることにおける苦労。 18 2.7. 作業部会DynamicsはIssue Closure Difficultを作ることができます。 18 2.8. IETF ParticipantsとLeadersは彼らのRoles. . . . . . . . . . . . . . . . . . . . 19 3のためのInadequately Preparedです。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 20 4。 承認. . . . . . . . . . . . . . . . . . . . . . . 20 5。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.1。 引用規格. . . . . . . . . . . . . . . . . . 21 5.2。 有益な参照. . . . . . . . . . . . . . . . . 21 6。 エディタのアドレス. . . . . . . . . . . . . . . . . . . . . . . 21 7。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 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.

2002年の後半に始められた議論は、多くの問題がインターネットEngineering Taskforce(IETF)が作動する方法で存在すると信じられているのを示しました。 これらの問題に対処するためにIETF手順と規則を変えるのを試みる前に、IETFには、私たちがどんな問題を解決しようとしているかに関する明確で、同意している記述があるはずです。

Davies                       Informational                      [Page 2]

RFC 3774                 IETF Problem Statement                 May 2004

[2ページ]RFC3774IETF問題声明2004年5月の情報のデイヴィース

   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.

Problem Statementワーキンググループは、問題の記述を含むこのドキュメントを作成して、その特定された問題を訴えるために過程を示すのにこの分析を使用するためにチャーターされました。

   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.

孤立で取って、このドキュメントはきわめて否定的であるように見えるかもしれません。 IETFは、今日の挑戦を記述するためにその管理と過程をリフレッシュする必要がありますが、IETFが非常にうまくいっていて普及しているネットワークインフラにリードを持っている高品質の仕事の大きいボディーを生産したのを忘れるべきではありません。 このバックグラウンドに対して、私たちは、必要な片の更新への自己批判先導であると現在のドキュメントをみなすべきであり、成功を続けていました。 肯定的な面の議論は故意にIETFが関係者が現在のところIETFに影響するとして知覚する問題を修正している間、維持する必要がある基本的価値観を考えるIETF Problem Resolution Processesドキュメント[5]に閉じ込められました。

   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.

このドキュメントのための原料は初めは'wgchairs'メーリングリストの上と、そして、次に'問題声明'メーリングリストの上で2003年9月に終えた2002年11月から行われた大規模な議論をまとめることによって、誘導されました、この期間、発表された関連草稿から追加入力を取り入れて。(最近の本議論の[2]、[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.

このドキュメントは小さいセットの根本的原因問題、および根本的原因によって生み出された項目を押しながら大部分であるように見える副次的な問題の短いリストの中に問題であると知覚されたこれらを読みこなしました。 このリストはセクション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.

セクション1.1は根本的原因の現在の視点に来る際に行われた考えの短い説明をします。

   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.

知覚された問題のオリジナルの概要は、これからそれについて言及できるようにProblem Statement作業部会メーリングリストに掲示されました。 代替の原因解析が必要であるなら生データが利用可能であるように、それがオリジナルの計画分類されていたままで残っていることに注意してください。

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.

IETFの問題が調べられたとき、それらが新しくどちらもでなく、また組織の科学が目新しい問題の兆候でないことは明確になりました。

Davies                       Informational                      [Page 3]

RFC 3774                 IETF Problem Statement                 May 2004

[3ページ]RFC3774IETF問題声明2004年5月の情報のデイヴィース

   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.

IETFは小さくて、集中している組織として明確に定義された任務と重要な期間の間にこの領域で働き続けていた関係者で始めました。 期間1989-1999、IETFは関係者の数、およびたくさんの仕事に関する10以上の要素で進行中になりました。 仕事をはるかに変えさせるIETFの範囲の拡大でこの成長の効果を合成してあります。 この期間も、インターネットは、より複雑になっています、そして、ネットワークが人生の多くの領域の極めて重要な役割を持つようになるのに応じて、はるかに大きいユーザーコミュニティによってそれに置かれた要件は変化しました。

   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.

問題と兆候の多くが完全に新しいより大きいサイズと仕事の増加する複雑さにその経営組織と過程を適合させるというわけではない組織によって基本的に引き起こされるように見えます。 また、初期の任務が完成されるか、または大きくなっていたので、IETFは明確に将来の任務を定義していません。

   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.

IETF関係者の中には長い間これらの問題を意識している人もいました。 少なくとも1992までさかのぼる記録が同様の結論に達しました。

1.2.  The Aim is Improvement, not Finger-pointing

1.2. AimはFinger-指すのではなく、Improvementです。

   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.

このメモで特定された問題の多くが15年の期間、著しくしつこいです、人員における多くの変化を乗り切っていて。 私たちは人員問題ではなく、構造上の問題であるとそれらをみなします。知覚された問題のどれかの非難をどんな個人にも向けるべきではありません。 この吟味の過程の唯一の目的は、その目的のために最短時間のフレームでIETFがそれ自体を改良できるのでそれが、何であるかをどのように知っているかを特定して、適任になることになっています。

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

ワーキンググループの関係者は、問題に関する長い一覧表とそれらから得られた根本的原因問題の両方がどちらかメーリングリスト個人的な議論で重要な選挙民を生きさせると信じられている問題であると強調します。 また、私たちは、これらの問題の多くがaとして長年があるように見えることに注意します。

Davies                       Informational                      [Page 4]

RFC 3774                 IETF Problem Statement                 May 2004

[4ページ]RFC3774IETF問題声明2004年5月の情報のデイヴィース

   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.

非常に同様のリストは議論から1992年に承認されたIETF組織変動の前で行われた最初のPOISEDワーキンググループで存続しました。

   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の関係者はMissionのCommon Understandingを持っていません。

   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.

IETFは明確に定義されて、一般的に理解されているMissionを欠いています: その結果、また、全体でIETFとどんな貸し切りであることのWorking Groups(WGs)のための目標とプライオリティも不明瞭です。

   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.

IETFは、インターネットの大いに増加する範囲と複雑さの文脈、および前の仕事の成功が生み出したはるかに大きいユーザーコミュニティの変化要件における任務を理解する必要があります。

   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は、'範囲'が何であるべきであるかを決定できないで、したがって、範囲か範囲の外のどちらかで1つの提案された仕事がそうかどうか決めることができません。

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

o IETFは利害関係者がだれであるかが不確かです。 その結果利害関係者のあるグループ。(その利害関係者は、別の方法で提供できました)。

Davies                       Informational                      [Page 5]

RFC 3774                 IETF Problem Statement                 May 2004

[5ページ]RFC3774IETF問題声明2004年5月の情報のデイヴィース

      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の任務の損傷への地方偏重的な利害は潜在的に働くGroupsをハイジャックできます。

   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 私たちの目標に関する精度の不足は不十分に考え抜かれる、そして/または、総合的な構造に並べられないWG特許と要件につながります。 結果として起こる不十分に定義された特許は、劣った品質における重要な要因、そして/または、いくつかのWGsからの納品遅延と他の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.

o IETFは、これがIETFのものが見る'インターネットの利益'のウインカーにありそうであるだろう、インターネットを最大数利害関係者の役に立つようにするという長期目標に害を及ぼすので技術のまた、狭い範囲に焦点を合わせるのを避ける必要があります。 これはIETFで扱われる話題の比較的広範囲を許容するために論争します--いつも他家受精はIETFの強さの1つです。

   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.

一般的な理解を達成することへの追加バリアは、IETFにはすべての利害関係者が参加する認識されたフォーラムがないということであり、どの組織の広いコンセンサスで達するかもしれないか。 一般に、コンセンサスを達成できるくらいの時間がありません、そして、共同体の大きい断面図は定期的なIETFミーティングの間の全体会議で意見を提供できますが、モニターにはすべての利害関係者を保証できるどんなただ一つのメーリングリストもありません。

   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'

IETFは規格を作成して、したがって、必ずStandards Development Organization(SDO)ですが、多くの関係者が'従来'からIETFとその働き方を微分したがっています。

Davies                       Informational                      [Page 6]

RFC 3774                 IETF Problem Statement                 May 2004

[6ページ]RFC3774IETF問題声明2004年5月の情報のデイヴィース

   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.

法人のかかわり合いと強制された代表を強調するSDOs。 外部的に、IETFはこれらの従来のSDOsと共にしばしば分類されます、特に中傷者で、それらの違いのためのIETFの任務における分化、過程、および原理が明確でないので。 これはSDOsのコミュニケーションをより有効でなくすることができる他のSDOsによって誤解されるIETFに通じることができます、任務を達成するIETFの性能に害を及ぼして。

2.2.  The IETF does not Consistently use Effective Engineering Practices

2.2. IETFはどんなConsistently使用にも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.

'工学'がそのタイトルと関係者にある特にやっかいな問題の解決を見つける必要性に立ち向かわれていると「私を信じてください、そして、私は技術者です!」という声明を持ち出しそうな組織のために、IETFは少なくともいくつかの場合で非常に効果がないエンジニアリング方式を開きます。 有効な工学は工学の過程で助けるために一般的に受け入れられるここで使用されるような技術的解決法について引き出して、確かめるのにおいて中古の両方のテクニックが必要としたカバー、管理、および組織戦略を練習します。

   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:

この不足の主要症状はWGsが一貫してタイムリーで、高品質で、予測できる出力を起こさないということです。 セクション2.1で議論するように、IETFが、現在何がタイムリーであるか、そして、したがって、何がWG出力の配送のための適切な締め切りであるかを決定するのが難しいのがわかるので、この問題は悪化させられます。 WGsの有効な工学を妨げる貢献問題のいくつかは:

   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 そこでそれを確実にしないことはWG活動(特に解決策の本来の目的)の範囲のWGの一定の視点です。

   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 初期(デザインが凍っている前に)のときに決議される必要がある問題を特定して、そして、一定の視点が仕事を満足のいく結末にもたらすために決議される必要がある問題のWGにあるのを保証しないこと。

   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 WGが意図している顧客のために'目的のためのフィットネス'を不適当に減少させないで設定した締め切りに間に合うのに必要であるかもしれない特定する失敗とはっきりものが言えている工学トレードオフ。

   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 本来の目的によってそれに置かれた必要条件を満たすのが適切であるポイントを超えた解決策の継続的な気品。

Davies                       Informational                      [Page 7]

RFC 3774                 IETF Problem Statement                 May 2004

[7ページ]RFC3774IETF問題声明2004年5月の情報のデイヴィース

   The IETF standards engineering process is not set up to deliver
   iterative process improvement.  Particular areas that need
   improvement include:

規格工学が処理するIETFは、繰り返し作業改良を提供するためにセットアップされません。 改良を必要とする特定の領域は:

   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 特許はWGによって続かれるように過程とスケジュールを記録するくらいには詳しく述べられないかもしれません。 追加ドキュメントが道路地図や綿密な計画のように必要であるかもしれません。

   o  Poorly defined success criteria for WGs and individual documents.

o WGsと個々の文献の不十分に定義された成功評価基準。

   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 必ずドキュメントの即座の焦点ではなく、レビューの不足、WGの直接関心があるメンバーでない評論家、および関連する話題のための内容の専門家による特に早めのレビュー。

   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の改良を追い立てる'ポストmortem'手順の不足は処理されます。

   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規格の実現について確かめる提供方法で先を見越しません。

   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.

さらに、一般的に受け入れられたProject Managementのテクニックが定期的に組織における、仕事の進歩に適用されないので、IETFの過程、および特に作業部会の過程に苦しみます。

Davies                       Informational                      [Page 8]

RFC 3774                 IETF Problem Statement                 May 2004

[8ページ]RFC3774IETF問題声明2004年5月の情報のデイヴィース

   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の中の他のWGsと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 憲章は定期的にWGs、個人、およびドキュメントの進歩を評価できる十分小さい粒状で十分な重大事件を設定しません。 また、WGsは、特許プランを洗練するためにしばしばより詳細な作業計画を作るというわけではありません。

   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.

IETFが、どれから苦しむように見えないかが、過度の官僚制度であるのにおける1つの問題、一般に、意味で、情報のその転送はタスクを達成するのに必要な最小限に保たれます。 工程改善を許容するためにまだ十分な情報を記録している間導入されたどんな変化も官僚の負荷をかなり増加させないのは、重要です。

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

最終的に、ケースがそれらが無視されるか、または歪められているところにIETFがEngineering Practicesを定義させるところにさえ頻繁にあります。 特別の関心の1つの領域が、'走行コード'のプロトコルが評価される傾向と主として実用的な実験でというよりむしろ書かれた仕様の静態分析で解決された問題です。

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は歴史的に最もうまくいっています。 インターネットが、より複雑になったなら、そのようなしっかり集中している問題は例外になっています。 必ずより複雑な状況における展開で吐かれるプロトコルの間の相互作用を意識しているようにいつも思えるというわけではないので、IETFは新しいプロトコルが配備されると起こる予期しない歓迎されない結果の機会を最小にしません。 これはセクション2.2に示されるようにWGの外からの不十分なレビューで悪化させられるかもしれません。

Davies                       Informational                      [Page 9]

RFC 3774                 IETF Problem Statement                 May 2004

[9ページ]RFC3774IETF問題声明2004年5月の情報のデイヴィース

   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:

'大きさの工学'が満足な解決に達するのに必要であるなら、IETF標準化手順は、しっかり強制的なワーキンググループのために最適化されて、一般に、それほど効果的ではありません。 取り囲んで、:大きさの工学はシステム設計の多くの局面を取り囲むことができます。

      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.

完全なシステムよりむしろ、しかし、私たちがインターネットのシステムが相互作用する方法に関してもう少し学んだようにIETFはプロトコルコンポーネントを歴史的に標準化しました、そして、コンポーネントの設計は、ますます外部の規制を考慮に入れる必要があります、そして、これらの規制の理解は大きさでさらに設計するのが必要である傾向があります。

   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:

この困難の原因の一部はIETFの正式な報告構造がADsを通したインターネットEngineering Steering Group(IESG)とWGsの間でコミュニケーションを強調して、相互WGコミュニケーションに多くの信用を置かないということであるかもしれません:

   o  The IETF is not consistently effective at resolving issues that
      cross WG or area boundaries.

o IETFはWGに交差する問題かエリアの境界を解決するところで一貫して効果的ではありません。

   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には、相互WG協力、コーディネート、またはコミュニケーションのための有効な正式なメカニズムがありません、WG特許で指定された提出物と過程の間の依存の取り扱いを含んでいて。

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

o IETFには、複数の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.

IETFも他のSDOsと共に働かなければなりません、そして、コーディネートと協力のための連絡メカニズムはいつも効率的に動作するというわけではありません。 これは、IETF仕事が考慮に入れなければならない相互作用のいくつかがこれらの他の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

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

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.

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

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

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

Davies                       Informational                     [Page 11]

RFC 3774                 IETF Problem Statement                 May 2004

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

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

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:

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

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.

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

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.

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

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

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

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

Davies Informational [Page 13] RFC 3774 IETF Problem Statement May 2004

2.6.2.  Workload of the IESG

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.

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:

The current job description for an AD encompasses at least the following tasks:

   o  Interacting with WGs

o Interacting with WGs

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

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

   o  Cross-pollinating between groups

o Cross-pollinating between groups

   o  Coordinating with other areas

o Coordinating with other areas

   o  Potentially, managing their Area Directorate team

o Potentially, managing their Area Directorate team

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

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.

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.

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:

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

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

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

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.

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

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.

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.

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

Davies Informational [Page 15] RFC 3774 IETF Problem Statement May 2004

2.6.5.  Avoidance of Procedural Ossification

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.

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.

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.

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

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.

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

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

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.

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.

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

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.

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.

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.

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

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.

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

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

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

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.

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

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.

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.

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

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.

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

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

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.

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.

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.

さらに、何人かの関係者は関係者(彼らの母国語としてイギリス人がいません)には両方における急速な話しとcolloquialismsの使用が話されて、書かれている状態でコミュニケーションがあるかもしれないという問題を意識していません。 また、それらもいつも全面参加を同じ見通しを共有しない人には、より難しくするかもしれない可能な文化的なニュアンスを意識しているというわけではありません。

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.

このドキュメントには、それ自体についてセキュリティ意味がありませんが、それは他の仕事のためにセキュリティ問題を提起する問題を特定したかもしれません。 どんなそのような含意もIETFが、特定された問題を解決するのにどう着手するはずであるかを出して、製作される仲間ドキュメントで考えられるべきです。

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

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

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

特別な感謝はセクション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

問題声明メーリングリスト入力の減少の早めの部分がElwynデイヴィースによるハラルドAlvestrandと後半と上で承認されたチームによって行われました。 合計で、およそ750の大規模で考え深い貢献があった、(何らかの作成

Davies                       Informational                     [Page 20]

RFC 3774                 IETF Problem Statement                 May 2004

[20ページ]RFC3774IETF問題声明2004年5月の情報のデイヴィース

   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.

編集チームに加えて、以下の人々はこのドキュメントの以前のバージョンで追加入力と役に立つフィードバックを提供しました: ハラルドAlvestrand、ランディ・ブッシュ、ブライアン大工、ジェームス・ケンフ、ジョンKlensin、ジョンLoughney、キース・ムーア。

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] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」

5.2.  Informative References

5.2. 有益な参照

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

[2] 「IETFの生産性を改良するという提案」というヒューストン、G.、およびM.ローズは進行中で働いています。

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

[3] M.、「IETFの過程を能率化する提案」というBlanchetは進行中で働いています。

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

[4] T. ハーディー、Progressの「Groupsと彼らのStuckeesを扱う」Work。

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

[5] デイヴィースとE.とJ.ホフマン、Eds、「IETF問題解決の過程」は進行中で働いています。

6.  Editor's Address

6. エディタのアドレス

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

Elwyn B.デイヴィースノーテルネットワークハーロー研究所ロンドン街道ハーロー、エセックスCM17 9NAイギリス

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

以下に電話をしてください。 +44 1279 405 498はメールされます: elwynd@nortelnetworks.com

Davies                       Informational                     [Page 21]

RFC 3774                 IETF Problem Statement                 May 2004

[21ページ]RFC3774IETF問題声明2004年5月の情報のデイヴィース

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.

Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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.

IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。

Acknowledgement

承認

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

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Davies                       Informational                     [Page 22]

デイヴィースInformationalです。[22ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

フロート要素内でポジショニングを行うと指定どおりに配置されない

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る