IETFのタオ:初心者のためのインターネット技術タスクフォースガイド

Paul Hoffman, Editor


About This Document

Copyright © 2012 IETF Trust. All rights reserved.

The current version of this web page can always be found at http://www.ietf.org/tao.html; that page can also be retrieved protected by TLS. To contribute to this document or to discuss its content, please join the "tao-discuss" mailing list. A history of the major versions of the Tao can be found here. This particular version was created on 2012-11-02.

このウェブページは日本語翻訳版です。「The Tao of the IETF」の翻訳リストです。


1. はじめに

発足以来、インターネット技術タスクフォース(IETF)のface-to-faceミーティングの参加者は飛躍的に増えました。 毎回、多くの人々が新たに参加し、そのうちの多くが常連となりました。 このミーティングの規模が小さかった時は、新しい参加者がもっと気軽に振舞えたものです。 しかし今日では、新しい参加者は以前よりずっと多くの人々と出会うことになり、その中にはドキュメントや示唆に富んだメールで名前を見たことがあるような人も混じっています。

このドキュメントはIETFの多様な側面と目的について説明したもので、新規の参加者にとってIETFがどのような意味を持つのか、その道筋を示しています。 これにより、暖かくゆったりとした気持ちになり、ミーティングやワーキンググループでの皆さんの議論がより活発になるはずです。 このドキュメントは、最初はかなり簡素なものでしたが、face-to-faceミーティングの前に何を知っておくべきか、ワーキンググループでどの様に活動していけば良いのか といった質問をIETFの新規の参加者から受けるにつれ、この様に発展してきました。

もちろん、多くのIETFの関係者がface-to-faceミーティングに全く出席してないのも事実です。 その代り、彼らはいくつものIETFワーキンググループのメーリングリストに参加して活動しています。 ワーキンググループ内部の活動は初めて参加する人にとっては分かりにくいかもしれませんが、このドキュメントを見ればその様な人でも積極的に参加できるようになるでしょう。

IETFは常に変化し続けています。このドキュメントの本筋は時が経っても大きく変わることはないと思いますが、実際には細かい部分がその時々によって変わっていきます。 例えば、何かの処理の依頼を行なう際にEメールアドレスの代わりにウェブツールが用いられる様になりました。

IETFのドキュメントの多くはタオでは、BCP、RFC、STDで記載されています。 BCPはインターネット内では「Best Current Practices(現時点における最善の実践)」という意味です。 RFCはIETFのテクニカルドキュメントでよく使われ、「Requests for Comments(コメント募集)」という意味です。 STDは「standards(標準)」とみなされるRFCです。 実際、これら3つのタイプは全てRFCsです。 詳しい情報はSection 6を見て下さい。

このウェブページは一連の「IETFのタオ」RFCを引き継いだものです。 RFCからウェブページに変更になった経緯は、[RFC6722]を見て下さい。 このタオのウェブ版は、 [RFC4677]を元にSusan Harrisが共同執筆しました。このドキュメントのオリジナル版は1994年にGary Malkinによって執筆されました。

では、なぜ「タオ」か? 中国語で「ダオ」と発音し、タオは中国の哲学者である老子の教えの基本原則です。 象徴となるマークは、白と黒の陰陽の円です。 タオイズムは宇宙をひとつの有機体ととらえていて、人間は宇宙全体のパーツとして互いに依存し合っているとされます。 タオは「道」と訳されることもありますが、タオ哲学による本当の意味を言い表してはいません。

1.1 タオで使用される略語

このドキュメント中の略語を幾つかを以下に示します。

用語 意味
AD エリアディレクター
BCP 現時点における最善の実践
BOF インフォーマルなミーティング、討論会
FAQ よくある質問とその回答
FYI インターネットで使用される標準技術の周知を目的とする文書(RFC)
IAB インターネットアーキテクチャ評議会
IAD IETFアドミニスレイティブディレクター
IANA インターネット上のアドレス資源の標準化や管理を行っていた組織
IAOC IETFの事務および関連職務を監督する組織
IASA IETF標準化過程を支持してIETFの技術的活動を支持するのに必要な運営機構を提供する組織
ICANN IANAの後継にあたる組織でインターネット上のアドレス資源の標準化や管理を行う
I-D インターネットドラフト
IESG インターネット技術標準化運営グループ
IETF インターネット技術標準化タスクフォース
IPR 知的財産権
IRTF インターネット研究タスクフォース
ISOC インターネット協会
RFC コメント募集
STD 標準(RFC)
WG ワーキンググループ

2. IETFとは

IETFはインターネットテクノロジーの科学と発展に貢献したい人々の緩やかで自律的に組織されたグループです。 インターネットの標準仕様を開発することがその主目的です。 IETFは一般的な組織ではなく、ひとつひとつの出来事の集合体のようなもので、会社でもなく、取締役も存在せず、正式メンバーもいなければ、義務もありません。 詳しい情報は [BCP95]「IETFの基本規約」を見て下さい。

IETFのミッションは以下の内容も含んでいます。

IETFミーティングはカンファレンスではありませんが、テクニカルプレゼンテーションがあります。 IETFは一般的な組織ではありませんが、標準規格となる仕様を数多く作り出しています。 IETFはボランティアで構成されていて、IETFの使命を実現するために年に3回集まります。

IETFに会員資格はありません。誰でもミーティングに参加できます。 IETFの会員(実際には会員という定義はありませんが)になる方法は、IETFミーティングに参加するかワーキンググループのメーリングリストに入ることです。 (参照Section 2.3) そこでIETFの活動や方向性に関する多くの情報が得られます。

もちろん、何かしらの構造がないとIETFのように成功する組織はできません。 IETFの構造は他の組織の協力を受けています。詳細は[BCP11]「IETFの標準化プロセスに関わった組織」に記述されています。 もしIETFに参加して何かBCPを読むとすれば、まずこれを読んでみてください。

IETFのウェブサイト http://www.ietf.org はミーティング、ワーキンググループ、インターネットドラフト、RFC、IETFメールアドレス等に関する最良の情報源です。

IETFは様々な方法で参加者の信念に沿って動いています。IETFの「設立の信念」の一つがDavid Clarkによって初期に刻まれています。 「私達は王様、大統領、投票を拒否します。 大まかな合意と動作するコード(プログラム)を信じます」 もうひとつ、広く支持されているJon Postelの言葉があります。 「送るものには保守的であれ、受け取るものには寛容であれ」

IETFは正に参加者のものなのです。IETFは興味を持っている全ての人を歓迎しているので、世界中から様々なインターネット業界の人達が参加します。 IETFは英語のみを使用して活動しています。 多くの人がIETFに融け込んでいる方法に関しては、 Section 3.12を見て下さい。

もうひとつ、新規の参加者にとって大事なことがあります。たとえ誰かが間違って「インターネットを動かす」と言ったとしても、IETFではそのようなことはありえません。 IETFは、インターネットユーザーによって採用された自主基準を作ることがしばしばありますが、インターネットをコントロールしたりパトロールすることはありません。 もし、あなたがインターネットの支配者になりたくてIETFに興味を持っているのであれば、ひどく失望してしまうかもしれません。

2.1 静かな始まり

最初のIETFミーティングは、1986年1月に21人の参加者でサンディエゴのLinkabit社で開催されました。 4回目は、1986年10月にメンローパークのSRI社で開催され、この時に初めてベンダーが参加しました。 ワーキンググループのコンセプトは、1987年2月にカリフォルニアのNASAエームズ研究センターで開催された5回目のIETFミーティングにおいて導入されました。 1987年7月にバージニア州マクリーンのMITRE社で開催された7回目のIETFミーティングで、初めて参加者が100人を超えました。

14回目のIETFミーティングは、1989年7月にスタンフォード大学で開催されました。その時、IETFの世界の構造に大きな変化が起きました。 それまで多くの「タスクフォース」を監督してきたIAB(その時の名前はInternet Activities Boardで現在のInternet Architecture Board)の構造が変わり、IETFとIRTFに別れました。 IRTFは、インターネットにおける長期的な問題点を考えていくことに専念することになりました。 IETFもまた、その時変化しました。

1992年1月にインターネット協会(ISOC)が形成された後、IABの活動はISOCの下に置かれるべきであると、IABがISOCに提案しました。 INET92が日本の神戸で開催された際に、ISOCの理事はこのIABの提案を反映した新しい憲章を承認しました。

1993年7月には、オランダのアムステルダムでIETFミーティングを開催しました。これはヨーロッパで行われる最初のIETFミーティングとなり、参加者の半分がアメリカ人、半分がアメリカ人以外でした。 2000年には、アジアで初めてとなるオーストラリアのアデレードでIETFミーティングを開催しました。

今では、IETFミーティングは北アメリカ、ヨーロッパ、アジアで開催されています。各地域で年に一度開催することになっていますが、スケジューリングの問題のため、より多くのミーティングが北アメリカで開催され、アジアとヨーロッパでも時々開催されています。 アメリカ人以外の参加者は年々増え続け、— アメリカで開催されるミーティングですら半数を占めるようになりました。

2.2 ヒエラルキー

2.2.1 ISOC (インターネット協会)

ISOCは、インターネットの拡大を助長するための国際的非営利会員組織です。 ISOCが行っている事のひとつとして、他の「I」グループ(特にIETF)の財政および法的なサポートがあります。 ISOCは、IETFの運営でリーダーシップ的地位を持っている人々の多くに保険を掛けてくれていて、「I」グループが何かをメディアに伝えたい時には広報チャネルとして動いてくれます。 ISOCは、表には出てきませんがインターネットの主要なヒーローの一人です。

また、2005年春からは、ISOCはIETFが直接雇用している管理スタッフの拠点となっています。 この部分は[BCP101]「IETF Administrative Support Activity (IASA)の構造」で、さらに詳しく説明しています。 スタッフは最初、フルタイムでIETFミーティングの計画、運用面でのサポート(事務、IANA(Internet Assigned Numbers Authority)、この章の後ろで説明するRFCエディター)や予算の監督を行なう管理ディレクター(IAD)一人だけでした。 この人がIETF Administrative Support Activity(IASA)を統率して、ミーティング料金を徴収したり、支払いを行ったり、IETFワーキンググループ、IESG、IAB、IRTF(この章の後ろで詳しく説明)の作業のツールをサポートしたりしています。

IETF Administrative Oversight Committee(IAOC)はボランティアで構成されており、ISOCやIETFのメンバーから適当なリーダーを選出するのと同じく、すべてのメンバーは直接または間接的にIETFコミュニティから選出されています。 IASAとIADは、IAOCによって監督されています。

IADもIAOCも、IETFが行っている標準化作業への影響力は全くありません。

2.2.2 IESG (インターネット技術運営グループ)

IESGは、IETFの活動とインターネット標準化過程の技術面でのマネージメントに責任を持っています。 また、ISOC理事会によって批准された規則や手続きに従って運営および管理されています。 しかし、IESGでは一般の組織で見られるようにリーダーが直接指示するようなことはありません。 名前が示すように、その役割は、何かを命令するというよりむしろ方向性を示すということです。 IESGは、IETFワーキンググループ(WG)からの成果の批准や導入、WGの立ち上げから完了、RFCになろうとしている非WGドラフトが正しいかの確認、といったことを行っています。

進行中のドラフト、発行されたRFC、ドキュメントのラストコールに関する最新情報、IETFの月次進行報告などは IESGのウェブページhttp://www.ietf.org/iesg.htmlをチェックして下さい。

IESGは、エリアディレクター(「AD」と呼ばれることがある)が中心となって活動し、ディレクターはNominations Committee(通常「NomCom」と呼ぶ)によって選出され、任期は2年です。 IESGのメンバーを選出するプロセスは、ここで詳細に説明しています。 [BCP10]IAB、IESGの選出、承認、リコールのプロセス:委員会の指名とリコールの手順

現在のエリアと略名称は、以下の通りです。

エリア 詳細
アプリケーション(APP) メールやウェブといったユーザープログラムで見られるプロトコル
ジェネラル(GEN) IETFのプロセスと既存のエリアにはフィットしないWG(あまり存在しませんが)
インターネット(INT) IPパケットを転送する方法とDNS情報
オペレーションとマネージメント(OPS) 運用面、ネットワーク監視、コンフィギュレーション
リアルタイムアプリケーションおよびインフラ(RAI) 遅延が重要となる対面コミュニケーション
ルーティング(RTG) パケットを目的地に送る
セキュリティ(SEC) 認証およびプライバシー
トランスポート(TSV) 特定のパケットのための特定のサービス

IESGはインターネットドラフトがRFCになるかどうか大きな影響を与えるので、多くの人々は神の様なものを見るかのごとくADを見ています。 IETFの参加者は、エリアディレクターに対して特定の問題に関する意見を崇めるように聞くことがあります。 しかし、ほとんどのADは普通の人とまったく区別がつかず、上から目線で話すようなことはありません。 実際、特別テクニカルなコメントを質問した時などは、ADよりもその事に関して多くの知見を持っているIETF参加者の言うことに従う場合もあります。

各エリアのADは、そのエリアのWGの全体の作業について誰よりも詳しく知っています。 それに対し、IESG全体としては、RFCになるべく提案されるインターネットドラフトを一つずつ検討していきます。 ADがそのドラフトについて重大な懸念を持っていれば、「議論(DISCUSS)」というポジションを取る場合があります。 議論によってこの懸念が解決しない場合は、オーバーライドという手続きに進み、2名以上のIESGメンバーがそれに対しての懸念を発言した場合、ドラフトは次の段階へ進めないことになっています。 これらの手続きにより、ADの「お気に入りのプロジェクト」であっても他のIETFプロトコルにマイナスの影響を与えるならば標準化過程に組み込まれることはなく、またADの「苛立ちのタネ」が何かを永遠に妨げるようなことも起こりません。

これは、IESGが決して力を行使しないと言っているわけではありません。もしワーキンググループが本来の憲章から外れていったり、WGがあまり良くない設計のプロトコルを標準にする様なリクエストをしたと思う場合には、IESGはそれなりの対処をします。 実際には、IESGは常に多くの作業量を抱えているので積極的にこういうことを行うことはありません。 IESGはインターネットドラフトを目指すRFCのWGからの請求をほとんど承認しており、何かとても間違っていると思われる場合だけこのようなプロセスに入ります。 言い換えれば、そもそもADはただプロセスを実行するのではなく全体を考えるポジションであり、そのために選出されているのです。 IETF標準の品質は、ワーキンググループの審査とそのWGをさらにADが審査することによって保たれています。

IETFは大まかな合意によって動いていて、IESGはWGがIETFコミュニティコンセンサスの結果を出したかどうかをが判断することになっています。 Section 4.2(WGコンセンサスを詳しく見る)IESGがWGで作り出したものを拒否する主な理由は、その結果がIETF全体すなわち全エリアの全ワーキンググループの合意を得られなかった場合などです。 例えば、あるWGの出した結果が、他の(おそらくは別のエリアに属する)ワーキンググループで開発された技術と矛盾するかもしれません、 IESGの重要な仕事は、すべてのWGの成果を監視し、IETFのプロトコル同士が対立するのを防ぐことです。 それが、ADが自分のエリアだけでなく他のエリアのドラフトも確認すべきである理由です。

2.2.3 IAB (インターネット体系委員会)

IABはインターネットの「全体像」を見守る責任があり、IETFの活動の様々なエリアの長期的計画を見守り調整を行います。 IABは、インターネットにおける重要な長期的問題に関して常に知識を蓄え続け、これらの話題をその専門家に知ってもらうよう喚起しています。

IABメンバーは、IETFの中で発生する活動に特に注意を払っています。新しいIETFワーキンググループが提案されるとき、IABは設立の一貫性と統合を保つためにその憲章を検討します。 グループが公認される前でも、IABメンバーはそれを提案した人々と新しいアイデアについて積極的に議論したいと思っています。

IABはまた、インターネット研究タスクフォースを後援および組織化し、インターネットのある部分の構造的な問題を徹底的に再検討するために、その専門家を招待してワークショップを開催します。 一般的に、ワークショップの報告書の中で、IETFコミュニティとIESGに対する提言が行われます。

IABのその他の活動

IESGと同様、IABメンバーはNomComによって選任され任期は2年間でISOC理事会によって承認されます。

2.2.4 IANA (インターネット番号割り当て機関)

IETFの活動における中心となるレジストラはIANAです(詳しく見る http://www.iana.org)。 多くのインターネットプロトコルでは、そのプロトコルが登場した後に他の人によって加えられたプロトコルアイテムが追跡可能になっている必要があります。 このようなレジストリが必要となる典型的な例には、TCPポートナンバーやMIMEタイプがあります。 IABは、これらのことを実行するためにIANAという組織を設立し、IANAの活動は財政的にはICANN(Internet Corporation for Assigned Names and Numbers)によってサポートされています。 IABはICANNの支援を受け、IANAの活動は必要に応じて無料で提供されます。 [RFC2860]

10年前、IANAの名前が新聞の第一面に登場するなど誰も考えていなかったと思います。 IANAの役割は、とても控え目なものでした。 実際、IANAがドメイン名システムの根本を支えていたことによりやむを得ず名前が前面に出てきて、その役割がどのようなものであるか見ようともせず、ひどい中傷にさらされたこともありました。 現在は、IETFはもうIANAのドメイン名とIPアドレス指定機能にかかわっておらず、その機能はICANNによって監視されています。

レジストラという存在はあまり面白くないものと感じるかもしれませんが、IETFの参加者の多くが、IANAがインターネットにとっていかに重要であるかを証言してくれると思います。 慎重かつ控えめに運営されているので、安定して長期的な蓄えを持っており、誰もが何も心配することなく新しいことに挑戦できる環境を整えています。 インターネットは飛躍的発展を遂げ続けましたが、これはIANAの創立者Jon Postelが理路整然とその職務を果たした結果であり、1998年に死亡する直前まで偉大な仕事を続けてきました。

2.2.5 RFCエディター

RFCエディターは、インターネットドラフトをRFCとして編集、フォーマット、公開することができ、IESGと連携して動いています。 そのもうひとつの重要な役割は、1つの完成したリポジトリをすべてのRFCに提供することです。 (参照http://www.rfc-editor.org) RFCがいったん発行されると、それは改訂されることはありません。 もしその仕様が変わった場合は、その標準規格は別のRFCとして再発行され、以前のものは「廃棄」となります。

IETFコミュニティ内で最も多い誤解の1つは、RFCエディターの役割がIANAによって管理されているということです。 同じ人達が何年にも渡ってRFCエディターとIANAの両方にかかわっていましたが、RFCエディターは別の仕事です。 現在、これらの仕事は別々の組織によって管理されています。IABは、RFCエディターとして動く組織、そしてRFCエディターの基本方針を承認しています。 RFCエディターは、IASAによって設立されました。

2009年の終わりまで、RFCエディターは独立したものでした。その機能はIABによって分割され、IETFコミュニティと連携して、様々な人達や組織によって実行できるいくつもの役割に分け、IABが指定したRFCシリーズエディターへと引き継がれました。 RFCエディターのモデルは[RFC6635]で記述されています。

2.2.6 IETF事務局

実際は、IETFを維持するために数人に給与を支払っています。IETFは一般的な組織ではなく、ひとつひとつの出来事の集合体のようなもので、会社でもなく、取締役も存在せず、正式メンバーもいなければ、義務もありません。 IETF事務局は、日々後方から支援をしており、主に、face-to-faceミーティングをコーディネートしたり、IETF用のメーリングリストを管理したりしています。 また、事務局は公式インターネットドラフトのディレクトリを規則的に最新の状態に保ったり、IETFウェブサイトを管理し、IESGが円滑に仕事をできるよう、日夜働いています。 そして、コミュニティとIESGが使用する様々なツールを提供しています。 IETF事務局はIASAの契約下にあり、その代りface-to-faceミーティングの費用から財政的なサポートを受けています。

2.2.7 IETFトラスト

2005年の終わり頃に、IETFの知的所有権の保持とライセンスのために、IETFトラストが設置されました。 IETFトラストが設置された理由は、誰かが知的所有権を保持しなければならず、安定していて、法的に身元保証されている存在が必要だったからです。 IETF理事会は、その時点におけるIAOCのメンバーとして選任された人達で構成されます。 IETFトラストに連絡をとるIETFの参加者はわずかで、皆黙って仕事をこなしていることがよく分ります。 IETFトラストについては、このウェブサイト http://trustee.ietf.org で詳しく見ることができます。

2.3 IETFメーリングリスト

IETFミーティングに参加しようと計画している人は、まずIETFアナウンスメーリングリストに加入する必要があります。 (参照 https://www.ietf.org/mailman/listinfo/IETF-Announce) ここに、ミーティング情報、RFCアナウンス、IESGプロトコルアクション、ラストコールすべてが投稿されます。 また、「技術を習得したい人」はIETFの一般的なディスカッションリストに加わると良いでしょう。 (参照https://www.ietf.org/mailman/listinfo/ietf) ここで、非常に幅広いトピックのディスカッションがなされています(ワーキンググループはそれぞれメーリングリストを持っていて、そこで関連する作業の議論をしています)。 もうひとつメーリングリストがあり、全インターネットドラフトの最新版が発行されるとアナウンスされます。 (参照https://www.ietf.org/mailman/listinfo/I-D-Announce)

これらの購読とIETFが運営する他のメーリングリストは「Mailman」と呼ぶプログラムで動いています。 Mailmanは、購読メッセージのフォーマットに関して少し気むずかしいところがあり、メールメッセージをHTMLファイルに変換するメールプログラムがおなしな動きをすることがあります。 しかし、メッセージをうまくフォーマットしておけば、Mailmanはきちんと働いてくれます。

IETFディスカッションリストには、管理人(モデレータ)がいません。すべての人がインターネットに関わる問題に関して意見を言うことができます。 しかし、[BCP45] 「IETF Discussion List Charter」で説明している通り、企業もしくは個人が何かを請求したり広告したりする場所ではありません。 IETFディスカッションリストに投稿する前に、このRFC(短いです)を一通り読んでみるのもよいでしょう。 実際に、リストには不適当な投稿に対して目を光らせる2人の「代理人」がいて、リストからしつこい犯罪者を追放するためのプロセスがありますが、幸いにもめったに起きることはありません。

事務局と一部のIETFリーダだけがアナウンスリストに送られたメッセージを承認することができますが、さまざまな人達からそのようなメッセージが送られてきます。

IETFメーリングリストがIETF参加者みんなの「意見を述べる」ものだといっても、重要なことは、IETFミーティングに参加すると自動的にメーリングリストに加えられるわけではないということです。


3. IETFミーティング

コンピュータ業界の中では、会議、セミナー、エキスポ、あらゆる種類のミーティングが数多く開催されています。 しかし、IETFface-to-faceミーティングは、これらとは全く異なるものです。 年に3回開催されるミーティングは、1週間続く「部族の集会」のようなものであり、主な目標はタスクを完了させるためにWGを活性化することであり、もうひとつの目標はWGとエリアの間で十分な交流を促進することです。 ミーティングの費用は参加した人達が支払い、ミーティングによっては主催した会社(もしそういう会社があれば)が支払うことになっていますが、ワーキンググループセッションの音声ストリーミングのようなものに関してはIASAが支払います。

多くの人達にとって、一般的なコンピュータ業界の会議と比べると、IETFミーティングは爽やかな感じのものです。 展覧会ホールがなく、チュートリアルはごくわずかで、業界のセレブも登場しません。 その代わり、多くの作業があり、多くの参加者みんなが社交的に接する時間がたくさん設けてあります。 IETFミーティングは、営業やマーケティング関係者にそれほど関心があるものではありませんが、技術者と開発者にとってはとても興味深いものです。

IETFミーティングの一般的な流れは、日曜日にチュートリアルと気楽な雰囲気の集まりから始まって、WGとBoFミーティングが月曜日から金曜日まで続きます。 WGミーティングはそれぞれ1時間から2.5時間くらい続き、WGによっては1週間の間に何回かミーティングを行いますが、その想定目標次第で変化します。

全体ミーティングは2つあり、1つは技術的、もう1つは管理的な内容で、1週間のうちの夜に開催します。 テクニカルミーティングはIABによって進められ、通常、WGやエリアにまたがった興味深いトピックの専門家を1~2人招待しています。 管理に関するミーティングはIETF議長によって進められ、RFCエディターからの進捗レポートや次回のミーティングのアナウンスのような事柄になります。 全体ミーティングは、IESGやIAOCと時間を共有する良い機会です。 賛辞も歓迎しますが、心配や不平の方を数多く取り上げるようにしています。

現在、IETFミーティングは北アメリカ、ヨーロッパ、アジアの各地域で1年に約一回開催しています。 過去数回のミーティングの参加者は約1,200人でした。 今までで80回以上IETFミーティングを開催し、そして、次回のミーティングの予定は以下のIETFウェブページで見ることができます。 http://www.ietf.org/meeting/upcoming.html

IETF face-to-faceミーティングの新規参加者は、少しショックを受けることがあるようです。彼らは他の標準化団体やコンピュータ会議のようなものを想像していたようです。 幸いなことに、ショックは1日か2日で次第になくなるようで、みんながどんなに楽しんでいるかを見て、多くの新しい参加者はかなり活気づけられるようです。 他方で、IETF参加者は驚くほどがさつな場合があるようで、だれかがマイクロホンで話しているときに大声でしゃべっていたり、食物や飲み物を取りにいくのに人ごみの中を押しのけて通ったりするようです。 このような非社交的な振る舞いは、IETFミーティングではコンピュータ会議より一般的なようです。

3.1 登録

IETFミーティングに参加するには、まず登録して、登録料を支払う必要があります。 ミーティングの場所と事前登録の情報は、できるかぎりミーティング—の約2カ月前までに告知されます。 告知はIETF告知メーリングリストのメールへ送られ、情報は同じ日にIETFウェブサイトに投稿されます。 http://www.ietf.org

ミーティングの前にウェブで登録して支払うことができますが、ミーティングの時に直接支払うこともできます。 登録料を安くするには、事前登録締切り日(ミーティングの約1週間前)までに支払う必要があります。 登録料には、1週間のミーティング、日曜日の夜の歓迎会(バーは有料)、毎日の軽い朝食、午後の休憩時の飲み物とスナックが含まれています。

登録は、ミーティングを開催している週の途中でもいつでも可能です。しかし、事務局は参加者の早めの到着、すなわち通常は日曜日の正午から日曜日の夜の歓迎会までの到着を強く勧めています。 歓迎会は人気があるイベントで、軽食を食べることができ、早く到着すれば他の人との社交の場となります。

参加者の名前と住所、IETFメーリングリストはいずれも売り出されたことがなく、これは注目に値することです。

登録する時に、「要注意事項(Note Well)」という題のウェブページを見ると思います。IETF知的所有権に関する規則が羅列してあるので、それを注意深く読んで下さい。

他の参加者へメッセージを残す場合には、たいていは登録デスクの近くにコルクボードがあるのでそれを使ってください。 また、時間ぎりぎりのミーティングの変更や部屋の変更も、このコルクボードを使います。

また、遺失物の取扱も登録デスクで行っています。ミーティングの最後に、遺失物取扱所に残ったものは、通常、ホテルに渡されるか、または事務局のオフィスに戻されます。

ちなみに、IETF登録デスクは、一般的に待ち合わせに便利な場所にあります。 「レジストレーションで会おう」と言われたら、IETF登録デスクなのか、ホテルのフロントデスクなのかはっきりさせておいた方がよいでしょう。 この点の思い違いが待ち合わせの失敗の大きな原因となります。

3.2 思い切って1週間の滞在を!

IETF WGミーティングは、月曜日の朝から金曜日の午後まで予定されています。 関連する非WGミーティングは、前週か翌週に開催される場合もあります。 ワーキンググループから廊下などでの簡単なディスカションまで、様々な人達と一緒になって収穫を得るためには、1週間全部の予定を空けておくのがよいでしょう。 この様に議題は流動的であり、参加者が予定を決めた後にぎりぎりで予定が変わって重要なセッションに出られなくなったという例はたくさんあります。 1週間ずっとその場にいるのが、こういう事が起こらない唯一の方法です。

もし、1週間のうちで関心があるミーティングがない時間があるならば、いろいろなセッションに出てIETFミーティングを有効に利用することができます。 ほとんどのIETF参加者はラップトップコンピュータを持ち運び、端末ルームかミーティングセッションの間に廊下で使っている光景をよく見ます。 ミーティング開催地(レストラン、喫茶店など)では、たいていの場合はワイヤレスインターネットが届くので、IETF参加者はミーティングがないときにそういう作業をするのが良いでしょう。

3.3 新規参加者向けトレーニング

新規参加者は、日曜日の午後に新参者のためのオリエンテーションに出席することが推奨されています。これは特に1回目の参加者のために企画しています。 オリエンテーションは、IETF EDUチームによって組織され実行されており、役に立つ情報を提供する目的を持っています。 このセッションは、名札の上にある点(ドット)の意味やIETFの構造などIETFの初心者にとって必要で啓発的なトピックをたくさん用意しています。

夕方前頃に、新規参加者の顔合わせと歓迎を行いますが、この時は新規の参加者とWG議長だけが参加します。 あなたが興味を持っている分野の知識を持っている人を探すにはとてもよい機会となります。 興味がある分野だけでなく、WG議長に気兼ねなく近づいていき、彼らのWGについて教えてもらったり、興味がある分野の人を探すのを手伝ってもらいましょう。

3.4 ドレスコード

参加者は名札を身につけることが定められており、シャツかブラウスを着なければなりません。 ズボンかスカートもとてもお勧めです。皆がTシャツやジーンズ(天気が良いなら、ショーツ)、サンダルをはいているのに、真剣に考えすぎて、月曜日の朝にスーツを着て登場し、しばしば当惑している新規参加者をよく見かけます。 スーツ以外の服を着るのを拒否する人もIETFにはいます。 幸いなことに、よく知られている人達(他の理由で)なので、変わった出で立ちでも許されています。 一般的なルールは「天気に合った服装」です。もし、一所懸命働いて外に出る予定がないなら「快適な服装」がルールです!

3.5 WGミーティング

IETFミーティングの中心はWGミーティングです。 WG議長によってスタイルは全く異なるので、WGミーティングをどう感じるかを一般的に説明することはできません。 ほとんどすべてのWGはミーティングのための議題がありますが、ミーティングの間しっかりとその議題に従っているものもあれば、もっと緩やかに行っているものもあります。

IETFミーティングのすべてのWGミーティングにおいて、重要なことがいくつかあります。 ミーティングの始まる頃に、議長は「青いシート(blue sheets)」を参加者に手渡します。名前とEメールアドレスを記入する用紙です。 長期的な保存目的のために使用されるもので、何人がどのミーティングに参加したか、稀なケースには誰が参加したかを把握するためです。 一般的な作法は、青いシートがどこから回ってきたかをよく見ておき、それを同じ方向に渡すことです。

ミーティングで話すときは、必ず部屋にあるマイクのところへ行くようにしてください。 議論を呼ぶような話題の場合は、マイクに列ができることもありますが、その議論に対して質問や意見があるとには積極的にマイクを使ってください。 WG議長または司会者が、いつ話して良いか教えてくれます。 座ったままで手をあげるほうが簡単かもしれませんが、マイクは、リモートでの参加者や、部屋中の人にあなたの質問やコメントを聞いて貰うのにとても役に立ちます。 マイクで話すときは名前を言うようにすれば、議事録をとっている人が誰が発言したのかを記録してくれるでしょう。

3.6 目の前の点に注目

IETFでは、名札の上に色がついた小さい点がある人がいます。 中には、点がいくつも付いている人がいます。この点が付いている人達は、多くの時間外労働をして様々なボランティアをしています。 点の色にはそれぞれ意味があり、その意味は以下の通りです。

意味
ワーキンググループ/BOF議長
ホストグループ
IABメンバー
IESGメンバー
オレンジ 指名委員会メンバー
IAOC
ピンク IRSG
青緑 RSE

(プレスメンバーはオレンジ色のバッジを付けています)

ローカルホストは、端末ルーム、レストラン、その地域の面白い場所等に関して答えてくれる人です。

IETFの新規参加者は、これらの点の付いた名札を付けている人達と物怖じせずに会話を始めてみましょう。 IAB、IESGメンバー、ワーキンググループ、BOF議長は、誰とでも気軽に話してくれます。そうでなければ点を付けたりはしません。 しかし、IETFミーティングはエリアディレクターにとってとても忙しい期間になります。 IETFミーティングの期間にADと話をしようとすれば、2週間後くらいにメールを送るように言われることもあります。 もし、エリアディレクター(ついでに言えばWG議長も)と廊下で会話をする時には、30秒くらいの話題を準備しておくと良いかもしれません。

3.7 端末ルーム

ホストが行うことの中で(参加者にとって)最も重要なことの1つが、ミーティング参加者にインターネットアクセスを提供することです。 一般的に、ワイヤレス接続はすべてのミーティングルームやほとんどの共有エリアで問題なく繋がりますが、ケーブル接続は端末ルームで提供しています。 それらの設備、サービス、時間を寄贈してくれている人達もしくは会社に、心からの賛辞と感謝を送りましょう

ミーティングの事前に準備をしておいたほうがよいでしょうが、「土壇場」で様々なことが起こり間に合わないこともあるので、そういう場合は端末ルームで作業することができます。 また、出張報告書や状況報告書を作成する必要がある人達にとっては、いろいろな事を覚えているうちに済ませられるので便利でしょう。

もし端末ルームに入るなら、バッジを付けておく必要があります。 端末ルームでは、多数の電源、ラップトップ用イーサネットポート、無線(イーサネットは必要ないが電源が必要な人々のため)、共用のプリンター、ワークステーション(場所によっては)を供給しています。 端末ルームには端末(パソコン)はありません。昔はそこに端末があったので、そういう名前なのです。 端末ルームのヘルプデスクはネットワークの障害に関しての質問を尋ねるには良い場所ですが、他のネットワークスタッフに質問するように指示されることもあります。

3.8 食事とお菓子

Marshall Roseは、IETFは「たくさんのすばらしい昼食と夕食」を食べに行く場所だと言ったことがあります。 実際に、IETFで非常によく食事する人達がいますが、彼等は自分達で食事を見つけてきます。 昼食と夕食は登録料には含まれていません。 事務局は、日曜日の夜の歓迎会の前菜(夕食の代わりではありません)、月曜日から金曜日の朝の軽食(会議によって時間が変わる)、午後の休憩時間のクッキー(これが最高!)、ブラウニー、果物、および他のおいしいものを用意しています。 これらは、ミーティングホストやミーティングスポンサーが支払うことが多いです。

もし、ホテルを出て食事をしたいならば、ローカルホストがミーティング会場から簡単に行けるレストランのリストを提供してくれることがあります。

3.9 ソーシャルイベント

ホストが組織して管理することの中で最も重要なもうひとつの内容が、IETFソーシャルイベントです。 ソーシャルイベントはハイテク関連のイベントであったり、美術館で行われたり、会場ホールの場合もあります。 しかし、IETFミーティングで必ずソーシャルイベントが行われるとはかぎりません。

IETFの新規参加者は、ソーシャルイベントに参加することが奨励されます。 皆が、自分の名札をつけて、ラップトップは部屋に置いてくるように言われます。 ソーシャルイベントは、技術的というよりは、むしろ社会的に人に会う機会を作るように考えられています。

3.10 議題

IETFミーティングの議題は、とても流動的なものです。ミーティングの数週間前から、ウェブで議題を見ることができます。 小さいサイズの議題リストを登録デスクでもらうことができるので、視力が良い人なら、ポケットにコピーを持っておいたり、バッジの裏側に貼っておくと便利です。 もちろん、IETFの言う「最終」は世界中のほかの場所で言うものとは意味が違います。 議題の最終バージョンとは、単にプリンタから出力したもののことです。 事務局は、IETF登録デスク(ホテルのフロントデスクではありません)の近くの掲示板で議題の変更を投稿しています。 ぎりぎりでの議題の変更は単なる気まぐれではありません。セッション議長や発表者の予想外のスケジュールの衝突によって「ぎりぎりの」タイミングで変更されることもあります。 IETFは議題について考え続けていて、何週間も前から変わり続けています。

会議室の場所を示した地図も、議題といっしょに書いてあります。議題が変わっていくと同時に、会議室が変わる場合があります。 同じワーキンググループが複数のミーティングを行なうこともあり、そのような場合はできるだけ同じ会議室を割り当てる様に最善の努力をしています。

3.11 救援のための教育(EDU)

もし、IETFについてよくわからない点があるならば(タオを読み終えた後にでも)、教育(EDU)チームが提供しているオンサイトの講義に参加してみるとよいでしょう。 これらの非公式のクラスは、新規参加者や長年のIETF参加者のために企画されているものです。 新規参加者のトレーニングに加えて、EDUチームはドキュメントエディター、ワーキンググループ議長、緻密なセキュリティチュートリアル(初心者と長年のIETF参加者の両方にとって不可欠)等のワークショップを提供しています。 一般的に、EDUセッションは日曜日の午後に開催されます。EDUチームの詳細については http://www.ietf.org/edu/ を見て下さい。

3.12 私はどこへ行けば?

IETFは人それぞれにとって、それぞれの意味があります。IETFミーティングに一度も参加したことがない人でも、IETFで活発に活動している人もいます。 IETFがどんなものかを感じるために、IETFミーティングに参加するのを義務付けているわけではありません。 以下のガイドライン(非常に一般的なものをベースにしています)を見れば、実際に参加したほうがよいかどうか決める事ができると思いますし、最初のミーティングはいつがよいのかも見当がつくと思います。

3.12.1 ISマネージャー

このドキュメントで終始言っているように、IETFミーティングはあなたが今まで参加したことがあるトレードショーとは全く違うものです。 もし、インターネット業界で来年何が流行るか知るのが目的ならば、IETFミーティングは著しく好ましくないところです。 ワーキンググループミーティングでは、業界の現在や未来の出来事を知るどころか混乱が待っているだけだと思った方がよいでしょう。

業界関係者はIETFミーティングに行くべきでないと言いたいわけではありません。 ISマネージャーとしては、IETFで開発中の技術を担当する人材をミーティングに送り込みたいと思うでしょう。 最新のインターネットドラフトを読んだりワーキンググループリストのトラフィックなどから、ミーティングに参加することが、会社やワーキンググループにとってどんな価値があるのか、もしくはないのかという感覚が分ると思います。

3.12.2 ネットワークオペレーターとISP

新しいプロトコルや、今使っているものの新しいバージョンのプロトコルがなければ、ネットワークを動かすのはとても難しいことです。 もし、最新のハードウェアとソフトウェアを使用してネットワーク関連の仕事をしているならば、もしくは自由な時間を使って関心のあるワーキンググループをフォローしているならば、ミーティングに参加してIETFの価値を見出すことができるでしょう。 IETFの多くの作業は、IPSや大企業のオペレーションの多くの部分もカバーしているので、オペレーターからの情報はこの作業を強力で妥当なものにするためにとても価値があります。 IETFの優秀なオペレーションドキュメントの多くは、ベンダや学会のものではなく、実際のオペレーターによるものです。

3.12.3 ネットワーク関連ハードウェアおよびソフトウェアベンダー

IETFのイメージは、かつては現実社会からかけ離れた学会のようなもので、実際にその通りでしたが、現在の参加者の多くは業界で働いている人達です。 IETFのほとんどのエリアでは、ベンダーの社員がプロトコルを書いてワーキンググループを先導しているため、ベンダーの参加はとても理にかなっています。 もし、インターネットのハードウェアやソフトウェアを開発していて、会社から誰もIRTFミーティングに参加したことがないのならば、ミーティングがどの程度仕事に関連しているかに関わらず、参加しない理由はどこにもありません。

IETFミーティングの週にみんながミーティングに参加できるように会社を閉めたほうがよい、などと言うつもりはありません。 会社の技術部の人がミーティングに参加してさえいれば、マーケティング部の人あるいは技術マーケティング部の人がIETFに欠席していても問題はありません。 同様に、技術部署のみんなが参加する必要はなく、おそらく役に立たないでしょう。特にインターネットドラフトを読んでワーキンググループメーリングリストに入っていなければ、参加する意味はありません。 多くの会社は、数人の適任者を選出しミーティングに参加させて、出張報告書を会社に提出させることになるのでしょう。 また、多くの会社は、内部調整や標準規格戦略を持っています。 会社の事業の一部または全部がインターネットに頼っているならば、その戦略にIETFを組み込むべきでしょう。

3.12.4 アカデミズム

IETFミーティングは、コンピュータサイエンスの人達が公開間近のプロトコルの開発過程で何が起こっているかを見るにはよい機会となることがあります。 ネットワークや通信の研究をしている教授、大学院生(優秀な大学生も)は、彼らの興味があるフィールドに関するワーキンググループをフォローすることによって、豊富な情報を得ることができるでしょう。 さまざまなワーキンググループミーティングをあちこち覗いてみれば、シンポジウムやセミナーに行くのと同じ効果があります。 もちろん、研究者もIRTFの活動には関心をもつでしょう。

3.12.5 コンピューター業界誌

もし、出版社のメンバーで、IETFに出席しようと考えているならば、このタオの中でそのような人のためのセクションがあります。— 詳細はここを見てください。 Section 8.2

3.13 議事進行

IETFの議事内容は、各ミーティングの後2カ月かけて編集し、ウェブで閲覧可能となります。 コピー— に目を通せば、議事内容は他のどこでも手に入れられるようなものではない、IETFに関する情報が満載されているのがわかるでしょう。 例えば、ミーティングの時のほとんどのWGのスナップショットがあり、取り組みの進化をより良く理解できるようになっています。

議事録は、有益な(そしてとても面白い)メッセージから始まることがあります。 各巻には、最終的な(後知恵的な)議題、IETF概要、エリア、ワーキンググループ報告書、プロトコルおよびテクニカルプレゼンテーションのスライドが載っています。 ワーキンググループ報告書とプレゼンテーションは、 資料が出版時までに事務局に届いていない場合、未完のままになっていることもあります。

参加者リストも含まれており、登録用紙で提供された名前と所属が載っています。 議事内容のコピーの入手に関する情報は、ウェブのリストを見てください。 http://www.ietf.org/meeting/proceedings.html

3.14 その他の一般事項

一般的に、IETF参加者はとても近づきやすい人達です。何も心配せず、誰にでも近づいて自己紹介してください。 また、ためらわずに何でも(特に、専門用語や略語など)質問してください。

廊下での会話はとても重要です。ミーティングとミーティングの間、昼食中や夕食中に皆と一緒に会話をすると、非常に役に立つ多くのものを得られます。 IETFでのすべての時間は、仕事の時間と考えることができます(一部の人々は落胆するかもしれませんが)。

WGミーティングとWGミーティングの間や夜遅くに、サイドミーティング(伝統的に、しばしば不正確に「バーBOF」呼ばれます)が非公式に開かれ、その間も多くの作業を行っています。 これらのサイドミーティングは、レストラン、喫茶店、未使用のホールスペース、プール(ラッキーな場合は)といったIETFミーティングの近くの様々な場所でいつのまにか発生します。

廊下での会話がどんなに楽しくても、空腹なIETF参加者(つまり、あらゆる参加者)をコーヒーブレイクブラウニーやクッキーと引き離すのは賢明ではありません。 最初のIETF事務局長であるSteve Coyaは「クッキーを取れ。そして、すぐにテーブルから離れろ」と、よく言っていました。

IETF参加者は、ものすごく独特です。意見を聞いてそれに対して答えるのが一般的ですが、IETF参加者がその通りにすると思ってはいけません。

IETFミーティング、特に本会議は、ベンダーが商品を売ろうとする場所ではありません。 みんな、会社や商品についてきちんと質問に答えますが、IETFはトレードショーではないことを覚えておいてください。 しかし、IETF関連のTシャツ、ボタン、ポケットプロテクターを売って費用を賄うのはかまいません。

「資料配布テーブル」が登録デスクの近くに必ずあります。 このデスクは、ふさわしい情報(例えば、ワークグループセッションで議論した何かのコピー、IETF関連のオンライン情報の説明文)を出席者が利用できるようにするために使います。 資料をデスクに置く前に、事務局に問い合わせてください。 事務局には、適切でないと感じる資料を排除する権利があります。

もし、ミーティングでラップトップを使おうと思っているならば、予備バッテリーを持って来たほうがよいでしょう。 ミーティングルームに必ずコンセントがあるとはかぎらず、無線を使用するとバッテリーの減りが予想より速くなります。 ミーティングルームの電源の差込口近くに座っている場合は、回りにいる他の人からプラグを挿したり抜いたりするよう頼まれます。 電源タップ付きの延長コードを持って来る人がいますが、ミーティングで周りの人達と友だちになる良い機会になります。 特殊な形状の電源アダプターは本国のほうが見つけやすいので、もし電源アダプターが必要なら事前に購入するようにしてください。


4. ワーキンググループ

IETFの膨大な作業の大半は、数多くのワーキンググループによって処理されています。これを書いている時点で、約115のWGがあります。 [BCP25]「IETFワーキンググループのガイドラインと手続き」の内容はWGディスカッションに参加するすべての人にとって素晴らしいものです。

WGは、本当は少しだけ大人の監視があるメーリングリストです。メーリングリストに加入することによって、WGに「参加」できます。 すべてのメーリングリストは誰でも参加できます。 だれでもWGメーリングリストに投稿できますが、ほとんどのリストは非参加者の投稿を抑制処理しています。 各ワーキンググループは、1人か2人(ときには3人)の議長がいます。

もっと重要な事として、各WGにはWGが従うべき憲章があります。 憲章はワーキンググループの目標と同時に、ディスカッションの範囲を示します。 WGのメーリングリストとface-to-faceミーティングは、憲章の中にあることだけに焦点を絞るようにして、他の「興味がある」話題にそれていかないようにします。 もちろん、WGの範囲の外を少しだけ見てみるのは役に立つこともありますが、ディスカッションの大部分は憲章でリストアップされた話題にするべきです。 実際、憲章を企画している時、特に魅力的であるが漠然とした話題が持ち出された場合などは、WGが何をしてはいけないかをWG議長が指定することもあります。 すべてのWG憲章のリストは、他のワーキンググループが何をしているか知りたい人にとっては読んでいて面白いものです。

4.1 ワーキンググループの議長

WG議長の役割は、[BCP11][BCP25]で説明しています。

猫の集団をボランティアで管理するような議長の最初の仕事は、WGの共有の目標とマイルストンを決定することであり、憲章を常に最新にしておくことです。 次に、WG秘書やドキュメントエディターの力を借りたりしながら、議長はWGディスカッションの管理をします。リストの管理や、必要であればミーティングの予定を立てます。 議論が論争に発展し暗礁に乗り上げることもありますが、そんな時は、議長はみんなを生産的な会話に導いていく必要があり、大まかな合意が得られたら、議論の終了を宣言します。 特にWGドキュメントが公開に近づくにつれ、議長は非WG参加者やIESGとの相互関係を調整しなければならない事があります。 議長には、WGの成果物について技術的または非技術的な品質に対する責任があります。 事務的な問題、個人間の問題、技術的な要求を想像してみれば分る通り、ワーキンググループの議長は他のどれよりも有意義な仕事です。

WG議長は、IETFミーティングに先行し、通常日曜日に開催されるWGリーダーシップトレーニングに行くように強く推奨されます。 通常、ミーティングの週の半ばにWG議長ランチがあり、そこで議長に特定した話題についての提言があり、それについてディスカッションします。 もし、そこで何をしているか興味があるなら、以下のスライドを見てください。 http://edu.ietf.org

4.2  ワーキンググループでの作業

多くの初心者がややこしく感じる事実の1つとして、face-to-faceのWGミーティングは他のほとんどの組織で重要であるほどIETFでは重要ではないということです。 また、face-to-faceミーティングで決定されたどんな内容も、WGメーリングリストで合意を得なければなりません。 WGミーティングで決定された重要な内容が、後にメーリングリストでひっくり返されたという例が多数ありますが、 これはミーティングに参加できなかった誰かが、決定された内容で使っているロジックの重大な欠陥を発見したといったことなどで起こります。 WGミーティングは「ドラフティングセッション」ではありません。それらはIETFの他の標準化団体の傘下です。つまり、ドラフトの作成は他で行われます。

多くの人々を困惑させるワーキンググループのもう一つの側面は、投票という形式がまったくないという事実です。 話題について議論する時の一般的な規則は、ワーキンググループが「大まかな合意」に達しなければならないということで、関わっている人の大多数が同意しなければならないということです。 ワーキンググループによって、大まかな合意を決める方法はそれぞれ少しずつ異なります。 合意は「ハミング」—によって決まることもあり、もし提案に同意するなら議長にうながされた時にハミングします。 質問に対し2つのパートで「ハミング」して答えます。もし提案に同意するなら最初のパートにハミングし、もし提案に同意できないなら、2番目のパートにハミングします。 新規参加者にはかなり異様だと思いますが、それでも機能します。IESGはインターネットドラフトを目指すRFCのWGからの請求をほとんど承認しており、何かとても間違っていると思われる場合だけこのようなプロセスに入ります。 ワーキンググループがいつ大まかな合意に達したかを決めるのは、議長次第です。

投票という形式がないために、提案の決定が非常に遅れることもありますが、激しい議論の後に大まかな合意に達した場面を目撃したIETF参加者の多くが、遅れたことによってより良いプロトコルをもたらされたと感じています。 (もし投票について考えるなら、関心を持つあらゆる人々を大勢集めたグループで「投票」するとしたらどんなことになるか、参加者を数えることが不可能なときはどうするのか考えてみてください) 大まかな合意は、様々な方法で定義されています。簡単に言えば、根強い反論に対して、ほとんどの人がこの反論が間違っていると納得するまで討論しなければならない、ということを意味しています。

関連する問題としてWGで議論すべきだと一部の人々が考える提案を、WG議長が議論さえしないことがあります。 例えば、提案した作業があまり憲章にのっとっていない場合は、WG議長はWGが憲章からはずれないように提案の議論を制限することもあります。 WG議長が憲章からはずれていると考えWGに取り込まない話題をWGで議論したいと思っている人がいる場合、その人はAD話をすることができます。 ADがそのトピックを憲章へ追加することもありますし、それがすでに憲章でカバーされていることもありますし、 あるいはWG議長は間違えておらず提案者はそのWG以外の場所で提案について検討することもあります。

WGドキュメントについてすべて議論しつくしたら、通常はワーキンググループラストコール (WGLCと略称が使われることもあります)へ進みます。 これは、WGが問題に決着をつける最後の場となります(上手くいけば)。 WGLCはとても多くの問題を持ち出してくることもあり、改編版ができた後で2回目のWGLCが行われます。 WGLCの必要性にも関わらず、どうやってWGLCが始めるかの公式規則はなく、WG議長に一任されています。

他の方法として、ドキュメントと変更を扱うためのワーキンググループ「秘書」を持つという方法を採用しているワーキンググループがあります。 秘書は何か問題があればそれを追求していく、もしくは単純に、メーリングリストで決定された内容がドキュメントの新しいバージョンに反映されているかを確認する担当者になります。

WGが憲章を完了させたとき、それは作業を終了するということになります。 (WGが閉鎖された後もWGメーリングリストが続くことが多く、ワーキンググループで行っていたのと同じように、同じ話題について議論しています) IETFでは、憲章が完了したということなので、WGを閉じるというのは成功の印です。 これが、他の標準化団体での経験を持っている新規参加者がIETFを理解するのに苦労する側面の1つです。 しかし、WG議長によってはWGを終わらせるように管理しなかったり、WG議長が新しいタスクを憲章に追加し続けてワーキンググループが何年(何10年間というのもいくつか)もだらだらと続いたりすることもあります。 これらの年老いたWGの成果物は、昔の製品と同じくらいの性能しかないこともあり、やっかいな成果のせいで「経年劣化ワーキンググループ症候群」と呼ばれることがあります。

4.3 ワーキンググループのドキュメント

WGドラフトと個人ドラフトには公式に区別がありますが、実際には、その手続きにはそれほど多くの違いがないこともあります。 例えば、多くのWGメーリングリストで(WG議長の裁量において)個人ドラフトについて議論しています。 WG議長は、どのドラフトがWGドラフトになるか、だれがドラフトの著者またはエディターになるのかを、通常はWGでの議論に基づき、時にはエリアディレクターと相談しながらこれを決めていきます。 このプロセスは、多くの人々がドラフトの著者になりたがっているケースでは扱いにくい場合がありますが、だれもドラフトの著者になりたがっていないのにWGが何らかの作業を計画している場合も同様です。 インターネットドラフトの手続きは、このドキュメントの中でもっと詳細に扱っています。

ワーキンググループによっては、複雑なドキュメントもしくは複雑なセットのドキュメント(または両方とも)を持つことがあります。 複雑なドキュメントからすべてのバグを取り除くのは、とても大変な作業です。 この問題を何とかするために、ワーキンググループは「問題トラッカー」を使用することがあります。これは、未解決の問題があるドキュメント、問題の状況、提案された解決法などのオンラインリストです。 問題トラッカーを使用することは、WGが何か重要なことをし忘れないようにすることに役立つだけではなく、後になってからなぜそれがそういうやり方で解決できたのかという質問に答えることにも役立ちます。

WG議長の意向により、ドキュメントエディターがワーキンググループドキュメントを編集することがあります。 特に複雑なドキュメントの場合など、ワーキンググループドキュメントを複数のエディターで担当することもあります。 ドキュメントエディターは、ワーキンググループの決定をドキュメントに正確に反映することに責任を持っています。 特に新しいプロトコルやエクステンションを作成するときなどとても役に立ちます。 ドキュメントエディターがWGの決定に従わない場合は、WG議長は決定に合致するように強く要請するか、もしくはWGにもっと相応しいドキュメントエディターに切り替えます。 ワーキンググループドキュメントが進展するにつれ、参加者はワーキンググループメーリングリスト上でドキュメントの変更を要求するようになります。 エディターはこのディスカッションをフォローしており、合意があれば変更を加えます。

参加者が大きな貢献をした場合、ドキュメントエディターか議長は、その参加者に共著者か共同エディターになるよう誘うことができ、WG議長によってその要求が承認されます。 ワーキンググループドキュメントとして特定のインターネットドラフトを選定する前に、ワーキンググループはいくつかの選択肢を考慮します。 ワーキンググループは、一つのワーキンググループドキュメントを作成するために、いくつもの選択肢からアイデアを取り込むことがあります。 このような場合には、議長はだれが著者としてタイトルページに表示されるか、だれが貢献者としてドキュメントのボディーに表示されるかを決定します。

WGドキュメントがWGの手を離れて次の段階に進むときに、WG議長は最終的なプロセスを引き継ぐための「見張り役(Shepherd)」を決めます。 ドキュメントの見張り役の役割については、[RFC4858]で説明しています。

4.4 ワーキンググループミーティングの準備

最も重要なのは、全ての人(新規参加者や毎回参加のエキスパート)がface-to-faceミーティングの前にインターネットドラフトとRFC読んでおく事です。 WGミーティングは教育目的ではないことを明示しており、グループドキュメント開発をその目的としています。 ミーティングで何も発言するつもりがなくても、参加する前にグループドキュメントを読んでおくべきであり、少なくとも拾い読みくらいしておけば、何を言っているか理解できるでしょう。

会議の議題を用意するのはWG議長次第ですが、通常は数週間前です。 もしミーティングで何か議論したい事があれば、それに関して議長に必ず知らせておいてください。 すべてのWGミーティングの議題は、あらかじめIETFウェブサイトで見ることができますが、WG議長によってはそういうことに(まったく無視はしないとしても)だらしない人もいます。

事務局はわずか数週間前にWGミーティングの計画を行いますが、スケジュールはミーティングが始まる1週間前まで頻繁に変わります。 もし、1つのWGミーティングのためだけに参加する場合は、ワーキンググループミーティングのスケジュールが変更されても小さな告知があるだけなので、 飛行機を予約するのに苦労するかもしれません。 飛行機とホテルの予約をするために、議題の変更状況を頻繁にチェックするようにしてください。 しかし、結局のところ、あなたはたった1つのWGミーティングのために来るべきではないでしょう。 おそらくあなたの知識はいくつかのWGで役に立つはずです。その様なグループのドラフトとRFCを読んでおきましょう。

face-to-faceミーティングで、あなたの発表が議題にあるならば、あなたはスライドを準備しているはずです。 しかし、チュートリアルを目的とすべきではありません。皆、あらかじめドラフトを読んできているはずです。 ラップトップで行うプレゼンテーション用のプロジェクターはすべてのミーティングルームで使用可能です。

WGや総会(プレナリ)でのプレゼンテーション用スライドに関してちょっとしたお知らせがあります。 会社のロゴを一切入れないで下さい、たとえロゴを入れるのがIETF以外では常識であってもです。 IETFはこのような企業広告(総会でのプレゼンテーションのミーティングスポンサーを除いて)を禁止しており、発表者はスライドの最初のページにもロゴを入れてはいけません。 IETFは技術的内容の場であり、企業の売り込みをする場ではありません。 スライドは鮮明に見えるように白黒の方が好ましく、分りやすくするときだけ色を使うようにしましょう。 スライドは内容が一番重要であって、どう綺麗に見えるかということではありません。

とても役に立つ(もしくは楽しむこともできるかもしれない)だろうことが1つ、ワーキンググループセッションの間、ワーキンググループに関連する 実況中継をJabberルームでフォローできます。 実況中継は議事録の元となる資料としてしばしば使用されることがありますが、冗談、ため息、まったく関係ないおしゃべりも含まれます。 Jabberは無料で、主にインスタントメッセージングに主に使用されるストリーミングXML技術です。 多くのプラットホーム向けのjabberクライアントをここで見つけることができます。 http://xmpp.org/xmpp-software/jabberチャットルームには「@jabber.ietf.org」がフォローしているワーキンググループの名前があります。 実際、これらのルームはIETFミーティングの時だけでなく年中使用可能となっていて、プロトコル開発の間ワーキンググループの参加者によって頻繁に使用されているものもあります。

4.5 ワーキンググループのメーリングリスト

前に言及したように、IETFのアナウンスとディスカッションメーリングリストはIETFの活動の中心となるメーリングリストです。 しかし、IETFの作業に関連するメーリングリストが他にも数多くあります。 例えば、すべてのワーキンググループがそれら自身のディスカッションリストを持っています。 さらに、あるトピックのために特別に作成されたリストで、IETFのリストから外された以後も技術的な議論が長い間続いていることもあります。 あなたが参加したいと思っているワーキンググループのメーリングリストのディスカッションをフォローするのを強くお勧めします。 メーリングリストで多くの作業が行われれば、それだけミーティングで行われる作業は少なくなりますが、お互いの結び付きを活性化できます。 (例えば、自分が作業している以外のワーキンググループに参加することにより視野を広げることができます。)

メーリングリストは、ワーキンググループをフォローしたり、貢献する意欲はあってもIETFミーティングには参加できない人達にフォーラムとなる場所を提供しています。 そのため、IETFの手続きは「リストの中」ですべて決定することを義務付けられており、WG議長がディスカッションを終了する時に「リストに持って行こう」と言っているのをしばしば聞くことがあります。

多くのIETFのディスカッションリストはMailman、もしくはもうひとつのリストマネージャーであるMajordomoを使用しています。 これらには、リストに加入や退会する時の詳細な管理を扱うための「-request」アドレスがあります。 (Mailmanの詳しい情報はSection 2.3 を見て下さい) 一般的には、そのような事務的な内容がディスカッションメーリングリストに表示されるのは好まれません。

IETFディスカッションリストはアーカイブ化されます。すなわち、リストに送られたメッセージはすべてホストに自動的に保存され、HTTPもしくはFTPで匿名アクセスできます。 保存された情報はすべてここで公開しています。 ftp://ftp.ietf.org/ietf-mail-archiveもしくは、ウェブベースで保存されています。 もし、探しているリストが見つからない場合は、リストの「-request」アドレス(リスト自体ではありません!)にメッセージを送りましょう。ワーキンググループ用リストはこちらにあります。 http://datatracker.ietf.org/wg役に立つ情報元です。 http://www.ietf.org/wg/concluded 完了したWGの古いリストです。

WGリストによってはメッセージのサイズに制限を設けていますが、これは巨大なドキュメントやプレゼン資料が皆さんのメールボックスに届くのを避けるためです。 ブロードバンド接続がない(旅行中などは、ブロードバンド接続があったとしてもメールを受け取るのでさえ時間がががることがあります)参加者もいることを常に認識しておいて下さい。短いメッセージの方が喜ばれます。 ドキュメントはインターネットドラフトとして投稿することができます。 プレゼンテーションの資料は送信者が自分で管理しているウェブサイトに投稿するか、または要求があった時に個人的に送ったりします。 WGによっては大きいドキュメントを保存するための特別なサイトを用意しているので、送信者は最初にそこに投稿し、そのドキュメントのURLをリストに送ります。

4.6 ワーキンググループの中間ミーティング

ワーキンググループは、IETFミーティングの間に中間ミーティングを開くことがあります。 中間ミーティングはIETFミーティングの代わりのものではありません、—ワーキンググループは気に入らない場所という理由でミーティングをスキップして 3週間後に例えば、メキシコのカンクーン(または世界中のどこかで)でミーティングを行なうといったことはできません。 中間ミーティングを開くにはADの許可が必要で、少なくとも1カ月前にはアナウンスされます。 場所と時期は、すべての参加者が公平に行けるような所を選びます。 定期的なIETFミーティングと同様に、だれかが議事録を取る必要があり、グループは参加者の出席を取ります。 中間WGミーティングで暫定的に行った決定は、メーリングリストで最終決定を行う必要があります。

近年、いくつかのワーキンググループがface-to-faceミーティングの代わりに、電話やオンラインを使った「バーチャル中間ミーティング」を始めました。 バーチャル中間ミーティングは、通常のIETF face-to-faceミーティングの時期の中間の時点で、ワーキンググループの作業をチェックすることができ、 参加者からするとface-to-faceの中間ミーティングのような費用がかかりません。 バーチャル中間ミーティングには、face-to-faceミーティングと同様の報告義務があります。

IESGには、ワーキンググループ中間ミーティングの時間と場所を事前報告しなければいけない規則があり、同様にミーティングの結果も報告する規則もあります。 これらの規則の目的は、中間ミーティングの結果をできるだけ多くのワーキンググループメンバーにアクセスしてもらい、ワーキンググループのプロセスの透明性を保つことです。


5. BOF

ワーキンググループを作るには、まず憲章とだれか議長ができる人が必要です。 これらをそろえるためには、興味がある人を集め、憲章作りに専念し、そのプロジェクトがどんなに価値があるものなのかエリアディレクターが納得するように手伝ってもらう必要があります。 face-to-faceミーティングがその役に立ちます。 実際、エリアディレクターがWGを開始する例はわずかです。ほとんどのものはface-to-face BOFで参加者がその話題に興味があることを表明した後に始まります。

類友(Birds of a Feather:BOF)ミーティングは、それを予定する前に関連するエリアのエリアディレクターの承認を受ける必要があります。 もし、本当に新しいWGが必要だと思うなら、提案を持って非公式にADに近づき、どう考えるか様子を見ましょう。 次のステップでは、次回のface-to-faceミーティングでのミーティング枠を要求します。 もちろん、何らかの作業をするのにミーティングを待つ必要はなく、メーリングリストを設定して、憲章について議論し始めることができます。

BOFミーティングの雰囲気は、WGミーティングと比べるとかなり異なります。BOFの目的は、良いマイルストンを作成できる適任の議長と標準を作成する意欲に富んだ人々を確保することです。 既に存在するインターネットドラフトを行っているBOFもあり、ゼロから始めているのもあります。

BOFを作る前にドラフトが既にあることの利点は、ディスカッションの焦点を合わせやすいということです。 その反面、ドラフトがあると、BOFの他の人々が憲章の範囲でやりたがっていることが制限されてしまう傾向があります。 重要なのは、ほとんどのBOFは将来のワーキンググループのサポートを得るために開かれているのであって、特定のドキュメントのサポートを得るためではないということです。

ほとんどのBOFは、さまざまな理由によってWGにはなりません。共有する問題は、その作業に集中することに同意できる人を十分に確保できないことです。 もうひとつの典型的な理由は、例えばドキュメントの著者が管理をWGに任せたくないといった理由で、標準規格—にする作業が終わらないことです。 (このドキュメントの後半で管理の変更について議論しています) 1つの議題についてのBOFミーティングは、2回だけスケジュールすることができます。その結果、WGが作られなければ議題は取り下げられます。


6. RFCとインターネットドラフト

新しいIETF参加者で、特定のRFCやインターネットドラフトを探しているなら、RFCエディターのウェブページへ行きましょう。 http://www.rfc-editor.org/rfc.htmlこのサイトは、他のRFCコレクションへのリンクがあり、様々な検索をすることができます。 探しているRFCの番号を知っているなら、RFCエディターのRFCページへ行きましょう。 http://www.rfc-editor.org/rfc.html インターネットドラフトに関しては、IETFウェブサイトに良い資料があります。https://datatracker.ietf.org/docではタイトルとキーワードで検索することができます。

6.1 RFCを発行する

IETFスタッフが新規の参加者から聞かれる最も一般的な質問の1つに「どうやってIETF標準を発行できますか?」というものがあります。 「IETF標準を書くべきですか?」というもっとましな質問もありますが、答えは「そうです」とはかぎりません。 もし、IETF標準規格になるようなドキュメントを書こうとするするなら、それぞれのステップは簡単であっても、総合的なプロセスは困難かもしれませんが、 ほとんどの人はプロセスは無事に切り抜けます。著者のわがままをそれなりに通すことに役立つ多くの文書化されたガイダンスがあります。

最初に決めなければならない事の1つとして、ワーキンググループであなたのドキュメントを見て欲しいのか、IETFに従属する個人(すなわち、非WGとして)として見て欲しいのかを決める事です。 ほとんどのIETF標準規格はワーキンググループからのものですが、個人の取り組みのものもあります。適当なワーキンググループがないかもしれないし、 適当なワーキンググループがあったとしても他の作業が忙しくてあなたの考えを検討する暇がないかもしれません。

全てのIETF標準規格はRFC(「Request for Comments」)として公開され、全てのRFCはインターネットドラフト(「I-D」もしくは「ドラフト」と呼ばれることがある)として始まります。 IETF標準規格として何かを公開するための基本ステップは次の通りです。

  1. ドキュメントをインターネットドラフトとして公開する
  2. ドラフトのコメントを受け取る
  3. コメントに応じてドラフトを編集する
  4. この1から3のステップを数回繰り返す
  5. IESGにドラフトを提出するようにエリアディレクターに依頼(個人に属するものであれば) ドラフトが公式のワーキンググループの製品ならば、WG議長がADにIESGへ提出するように依頼する
  6. エリアディレクターが提案を受け付けると、最初の審査を行い、大抵の場合何らかのアップデートを求めてくる。
  7. 幅広くIETFメンバーから意見を集める。エリアによっては審査チームがあり、IESGへすぐに提出可能かどうかドラフトをチェックします。 特に、Security Directorate(SecDir)とGeneral Area Review Team(Gen-Art)の2つの審査チームは活発に審査を行っています。 これらすべての審査によって、最終的なRFCの品質を改良していくことができるのです。
  8. IESGメンバーと懸念事項を議論する。その懸念事項が簡単な確認で解消されるかもしれませんし、ドキュメントへ追加や変更が必要となるかもしれません。
  9. ドキュメントがRFCエディターによって公開されるのを待つ。

これらのステップに関する全ての説明が[BCP9]「インターネット標準化プロセス」に書いてあります。 IETF標準になるかもしれないドラフトを書く人はBCP9を読む必要があり、このプロセスを通してドキュメントの経過を追っていくことができます。 IETFデータトラッカーを使って経過を追うことができます。 http://datatracker.ietf.orgBCP9(さらに、それを更新する他の様々なドキュメント)は、毎回参加している様なIETF参加者でさえ頻繁に誤解して いる、異なったタイプのRFCは、異なったプロセスを辿っていき、異なったランキングを持っているといったトピックについて詳細に説明しています。 RFCには以下の6種類があります:

提案標準とインターネット標準だけがIETF内の標準です。 このことに関する適切な要約は、[RFC1796]「すべてのRFCが規格基準ではありません」という適切なタイトルの文書の中にあります。

BCPとSTDという、RFCの2つのサブシリーズがあります。現状での最良の慣行(Best Current Practice)ドキュメントは、インターネットにおける様々な技術のアプリケーションについて説明しており、IETFプロセスの多くのパーツを記録するのに一般的に使用されています。 FYIのサブシリーズは、上に列挙している中での「情報ドキュメント」の一部であり、特別なタグ付けがされています。 (以前は紹介的なもの、より広い対象にアピールするために「For Your Information」というRFCのサブシリーズが存在しましたが、そのシリーズは公式に閉鎖されました)

STD RFCサブシリーズは、事実上インターネット標準を指定するRFCを特定するために作成されました。 いくつかのSTDは実際にはRFCのセットであり、「標準」の指定はドキュメントのセット全体に適用されます。

6.2 優雅に行きましょう

ドキュメントをIETF標準化トラックに入れて欲しくないという人の最も大きな理由は、プロトコルの変更のコントロールを放棄しなければならないということです。 すなわち、プロトコルがIETF標準規格になるよう提案すると、その場でプロトコルに対するコントロールを完全に放棄する必要があります。 もし一般的な合意があれば、プロトコルの一部を完全に変更することができ、セクション全体を取り除くことができ、新しい内容を加えることができ、名前を変更することもできます。

気に入っているプロトコルの制御をなかなかあきらめたくないという著者もいます。 もしあなたがそういうタイプの人ならば、プロトコルをIETF標準にしようと考えないほうがよいでしょう。 それとは逆に、もし世界中で実用化されるような標準規格を作るのが目標ならば、IETFのプロセスが好きになるかもしれません。

ちなみに、プロトコルが標準化トラックに置かれても、インターネット標準のコントロールの変更は終わっただけではありません。 プロトコル自体を変更することは様々な理由があって可能となっていて、その大きな理由として、標準規格を実装するときに問題を発見することがあるからです。 このような後になっての変更は、標準規格のドキュメントのエディターではなく、IETFの管理下で行なわれます。

IETF標準は、皆がそれを使ってインターネットプログラムを書いて、相互にやりとりするために存在します。 それらは著者のアイデア(たぶん素晴らしいでしょう)をドキュメント化するために存在するのではなく、会社が「IETF標準を持っている」と言うために存在するのでもありません。 もし、標準化されたRFCの実装が1つしかなかったとしたら(実際は標準化トラックを前進していくためには2つ以上の実装必要なのですが)、 最初にそれを標準化プロセスに入れたのが間違いということになります。

新しい著者が他の誰かのドキュメントを取ってきて、それを自分のものとすることはできません。 詳しくは[BCP78]セクション5.6、ポイント(a)を見て下さい。

6.3 インターネットドラフト

重要なものから先に言います。RFCリポジトリに置かれた全てのドキュメントは、最初はインターネットドラフトとして作られます。 インターネットドラフトは一時的なドキュメント—読者にとってはコメントを入れるためもので、 著者はそのコメントをよく考えながらどれをドラフトに組み込んだらよいかを決めることができます。 一時的なものであることを知らせるために、インターネットドラフトは6カ月後にアクティブオンラインディレクトリから自動的に取り除かれます。 ほとんどは標準ではありません。 [BCP9]に記述されているように、

「インターネットドラフトは規格を「発行する」手段ではありません。規格はRFCの仕組みを通して発行されます… インターネットドラフトは形式的な段階のようなものを持っていないので、いつでも変更や削除が行われます。 インターネットドラフトを、論文、報告書、提案依頼書等によって参照することは固く禁じられており、ベンダがインターネットドラフトに準拠していることを主張することも禁止されています。」

インターネットドラフトを発行したと自慢する人がいた場合、それはIETFを理解していない人(もしくは、故意にだまそうとしている人)と言えます。 実は大した手間はかかりません。

インターネットドラフトを提出した時点で、公開する権利のある部分をIETFに与えたことになります。 よって、インターネットドラフトは誰でも自由に読んだりコメントしたりすることができます。 IETFに対して与えた権利、与えていない権利については[BCP78]「貢献に対するIETFの権利」で説明しています。

ここにとても便利なチェックツールがあります。 http://tools.ietf.org/tools/idnits事前にこのツールを使えば、インターネットドラフトがフォーマットエラーのためにつき返されてしまうのを防いでくれます。

I-DはRFCとほぼ同じフォーマットであるべきです。多くの人が思っている事とは異なり、I-DはRFCのように見える必要はありません。 しかし、I-Dを作成するときに、RFCエディターが利用している同じフォーマット方法を用いることによって、RFCを発行する際の RFCエディターの負担を軽くすることができます。 [RFC2223] 「RFC著者への説明」では、提出用のフォーマットについて説明しています。 「xml2rfc」と呼ばれるツールがhttp://xml.resource.orgにあります。 これは、XMLフォーマットのテキストを有効なインターネットドラフトに変換します。

インターネットドラフトには、ワーキンググループのドラフトと個人として提出したものがあります。 ワーキンググループのドラフトは、一般的にWGアイテムとして受け付けられる前にワーキンググループによって審査されますが、最終決定権は議長が持っています。

もし、特定のドラフトの状況をチェックしたいのにその名前を正確に覚えていない、もしくはどのドラフトがWGで進行しているか知りたいといった場合には、2つの便利なツールが使えます。 「インターネットドラフトデータベースインターフェイス」https://datatracker.ietf.org/docは、著者、ワーキンググループ、日付、ファイルでドラフトを検索します。 ドラフトが公開プロセスまで進んだかどうか、その状況を追跡したいという著者にとって役に立つツールです。

何年もの間に発展してきた、非公式のインターネットドラフトの命名規則があります。 既に存在するRFCを改編したインターネットドラフトには名前に「bis」が入っていることがあります。これは「再び」もしくは「2回」を意味しています。 例えば、「draft-someone-rfc2345bis-00.txt」という様な名前になります。

6.3.1 著者の方はぜひお読みください

インターネットドラフトの最初の原稿を作成する前に、4つのドキュメントを読んでください:

また、IETFツールのウェブページを見ておいてください。 http://tools.ietf.orgここで、IETFの作業のいくつかを自動化する他のツールを見つけることができます。

6.3.2 ファイル名とその他の要件

インターネットドラフトを提出する用意ができたら、ここで http://datatracker.ietf.org/submit ウェブページの指示に従って必要なステップを辿っていってください。もし、個人的なヘルプが必要ならばEメールアドレスが書いてあります。

ドラフトの最初のバージョンを提出したら、ドラフトのために申請したファイル名をドラフト管理人に伝えます。 もしドラフトが公式のワーキンググループの製品なら、ファイル名は「draft-ietf-」で始まり、次に対象WGの名前が続き、その次に説明的な単語が続き、最後は「00.txt」となります。

例えば、S/MIMEに関するWGのドラフトでキーを作成するものであれば「draft-ietf-smime-keying-00.txt」と命名されるでしょう。 もしワーキンググループの製品でないなら、ファイル名は「draft-」で始まり、次に著者の苗字、その次に説明的な単語が続き、最後は「00.txt」となります。 例えば、スミスという人が書いたドラフトならば「draft-smith-keying-00.txt」と命名されるでしょう。 ドラフトが個人に属するものの特定のワーキンググループに関連するものなら、著者はワーキンググループの名前に従い「draft-smith-smime-keying-00.txt」と命名されることもあります。 命名ガイドラインhttp://www.ietf.org/ietf/1id-guidelines.txtに従っていれば、 あなたの提案したファイル名はまず問題ないでしょう。

初版のドラフトの後は、ファイル名の数の部分が増えていきます。 例えば、上で命名されたS/MIMEドラフトの第2版のファイル名は「draft-ietf-smime-keying-01.txt」になります。 個人で取り組んでいたものがワーキンググループに引き込まれていった時などは、いくつかの版が出た後でもファイル名が変わることがあるので、注意してください。 ドラフトの名前が変わった時はファイル名も変わり、数は-00に戻ります。 そのような名称変更があった時は、WG議長は古いドラフトの名前をインターネットドラフト管理人に知らせて、データベースを正確に保つようにします。

6.4 標準規格トラック-RFC

標準規格の作成と進捗のための手続きは、[BCP9]で説明しています。 インターネットドラフトについて十分議論した後に、それが役に立つ標準規格になるという大まかな合意があったならば、ドラフトをIESGに審査のために提出します。 ドラフトが公式のWGドラフトならば、WG議長は適切なエリアディレクターにそれを送ります。 ドラフトが個人に属するものならば、ドラフトの著者かエディターが適切なエリアディレクターにそれを提出します。 BCP9は、ワーキンググループ議長、AD、IESGが標準規格の作成や規格の改良について間違った決定したと感じている人々がアピールするためのプロセスについて説明しています。

I-DがIESGに提出された後に、IESGはIETF全体のラストコール(Last Callを省略して「LC」)を発表します。 これにより、ドラフトの進捗をフォローしていない人の注意を引き付けることができ、ドラフトへの今後一層の興味を引き起こすことができます。 また、意見を聞いて貰えていないと感じているWG内の人が、コメントを多数の人に向けて送るきっかけとなります。 IETFラストコールは、WGからドラフトが来てから少なくとも2週間、個人からの場合は4週間継続されます。

IETFラストコールの目的は、IESGがそれらを検討する前にドキュメントでコミュニティ全体のディスカッションをすることです。 「ディスカッション」という言葉に注意してください。 読んでもいないドキュメントのコメントをIETFラストコールに送ったり、 議論する準備ができていないのにコメントを送ったりするのは、一般的に無作法だと思われるでしょう。 IETFラストコールは投票でなく、多くの人の賛同を得るため、もしくは逆にドキュメントに対する反対意見を募るためのキャンペーンです。 ちなみに、初めてドキュメントを読んだ人が出したIETFラストコールのコメントがIETFの問題を浮き彫りにし、WGの常連が完全に間違っていた、ということもあり得るため、 このようなことからディスカッションはすべての人々に対して開かれています。

IESGが、ドラフトが標準化トラックのRFCになることを承認したら、提案標準としてそれを発行するようにRFCエディターに依頼します。 ここで、普通はいくつかのことが起こります。まず最初に、標準の仕様書の一部の記述を書き換えるのはよくあることです。 なぜなら、ある文章について、ある人はこう解釈していたが他のある人は違う解釈を考えていた、という事が起こるからです。 他によくあるのは、どの実装も標準の中のある機能を実際には組み込んでいなかったというケースです。 この機能は、だれもテストをしなかったから分らなかったという理由だけでなく、そもそも必要でなかったからという理由で削除されます。

標準が、提案基準からインターネット標準まで発展していかなくても驚いてはいけません。 インターネット標準になるには、RFCは複数の相互運用可能な実装が必要で、提案標準の中で未使用の機能があればそれを取り除く必要があります。 追加の要求が[BCP9]に書いてあります。 一般に使用されている標準のほとんどは提案標準であり、その先へ進んでいません。 これは、だれもわざわざインターネット標準にしようと時間をかけなかったか、ドキュメント内で引用されている規格のいくつかがまだ提案標準の状態であったとか、 もっと他にやるべき重要なことが見つかった、などがその理由です。

6.4.1 ただありのままに— MUST、SHOULD、およびMAYの使用

あなたが望むように実装して貰える仕様書を書くのは、ちょっとした芸術みたいなものです。 仕様書を単なる要求リストにして短くすることも可能ですが、それだと実装者が時間がかかりすぎる傾向があります。 反対に、仕様書に多くの事をくどくど書き込み多くの提案を入れておいたら、実装者は要求を間違える傾向があります(そしてあなたの提案に反対することもあります)。 最適の仕様書とは、その中間あたりにあります。

開発者が標準の相互運用可能な実装を作成するのを可能にするひとつの方法は、仕様書で何を強制しようとしているか明確にすることです。 初期のRFCでは説明するのに必要なあるあらゆる表現方法を使っていましたが、作成者はどの部分が提案で、どれが要求であるか全て分っていたわけではありません。 結果として、IETF標準規格の著者は、言葉を制限しいくつか特定の言葉と意味だけを使うということで同意しました。

[STD3]「インターネットホストのための要件、アプリケーションとサポート」1989年著、には有用な単語のリストとして「must」「should」「may」がありました。 この定義は、[BCP14]「要求レベルを示すRFCで使用するキーワード」で更新されにより洗練され、現在のインターネット標準で広く参照されるようになりました。 BCP14は「must not」「should not」を特別に定義し、それらのいくつかの同義語をリスト化しました。

標準では、BCP14の定義を使用していることを明らかにするために、2つのことを行ってください。 まず最初に、BCP14(多くの人々はRFC2119として参照しているようですが、それがまさにBCP14のことです)を参照し、読み手がどのように言葉を定義しているがを確認します。 2番目に、使用している言葉のどのインスタンスがBCP14のものかを確認します。 慣例として、その言葉を大文字で書くことになっています。 それが、「MUST」と「SHOULD」がIETF標準規格で大文字で書かれている理由です。

BCP14は短いドキュメントであり、IETF標準を読んだり書いたりしている人は皆読むべきです。 「must」と「must not」の定義はかなり明快ですが、「should」と「should not」の定義は多くのWGの間で様々な議論を引き起こします。 インターネットドラフトを再検討するとき、しばしば疑問が起こります、「その文の中MUSTまたはSHOULDが入っているべきか?」 これは本当に良い質問です、なぜなら仕様書では、相互運用性に関して根拠もなくMUSTを使用すべきでなく、MUSTを用いるべき箇所でSHOULDを使用すべきでもないからです。 これが標準における過剰すぎる仕様と簡素すぎる仕様の問題のポイントとなります。

6.4.2 標準における引用

多くの初心者(長く携わっている人でも一部の人)を混乱させるIETF標準の書き方のひとつに、非IETFドキュメントまたは標準の他のRFCへの「標準引用」に関する規則があります。 標準引用は標準を実装するにあたって従わなければならないドキュメントのリファレンスです。 非標準引用(「informative reference:参考引用」とも呼ばれる)は、実装する人にとっては役立ちますが、必須のものではありません。

IETF標準では、同程度かそれより高いレベルの他の標準化トラックRFC、もしくはIETFの外で開発された「オープン標準」を標準引用としてもよいことになっています。 「同程度かそれより高い」規則というのは、標準が提案からドラフトへ移る際には、標準引用の中のRFCのすべてがドラフトまたはインターネット標準でなければならない言うことです。 この規則は[BCP97]で説明しています。この規則は実装者に対し、インターネット標準では外部で参照している場合も含めてすべてが安定している、という保証を与えます。 またこのことは、他のドキュメントが追いつくまで、何カ月も(時には何年も)ドラフトやインターネット標準の公開を遅らせてしまうことがあります。

「オープン標準」とは何かという厳密な規則はありませんが、一般的にだれでもコピーして使う(その代価を払わなければならないことがあるかもしれませんが)ことができる安定した標準規格を意味し、 標準化グループと認識されているものによって作られています。 外部の標準が変わるなら、仕様書の中でその標準の特定の導入部分を参照しなければならず、標準規格の日付の指定も必要になってきます。 外部の標準化団体によっては、古いバージョンの標準規格は利用できないようにしており、IETF標準が将来使用される時に問題となります。 疑問があれば、ドラフトの著者は、特定の外部の標準をIETF標準で使用して良いかどうか、WG議長か適当なエリアディレクターに尋ねるべきでしょう。

6.4.3 IANAに関する問題

今では多くのIETF標準規格が、プロトコルパラメータの登録(例えばプロトコルにおけるオプションの名前など)を必要としています。 Section 2.2.4で述べているように、長い間、すべてのIETF標準規格の主なレジストリはIANAでした。 標準が必要とするさまざまな種類のレジストリのために、IANAはどうやってパラメータを登録するか、何を登録しないか、何を登録すべきかを誰(もし誰でもいいなら)が決めるか といったことに関する情報が必要なのです。

新しいIANAレジストリや現在のIANAレジストリに新しい変数を必要とする様なインターネット標準を書いている人は、 [BCP26]「ライターのためのガイドライン、RFCのIANA考慮事項セクション」を読む必要があります。 このドキュメントは、どうやってRFCの著者が、レジストリを始めるまたは引き継ぐよう適切にIANAに依頼するかを説明しています。 IANAはBCP26が作られたずっと前からレジストリの管理を始めています。

6.4.4 セキュリティ問題

全てのRFCとインターネットドラフトで必要とされるのが、「セキュリティ問題」セクションです。 このセクションでは、考えられ得るプロトコルの脆弱性や潜在的な脅威、それらに対処するためのメカニズムまたはストラテジー等を説明する必要があります。 特にこのセクションはいい加減にやってはいけません—「セキュリティが必要ならプロトコルがあるよ、IPsecを使うだけ」などと言ってはいけません。 これでは、IPsecとこのプロトコルがどのように相互に影響を与えるのかという質問に答えていません。 より優れたセキュリティ問題セクションの書き方については、 [BCP72]「ライターのためのガイドライン、セキュリティ問題のRFCテキスト」を見て下さい。

6.4.5 IETF標準と特許

過去数年の間で、知的所有権の問題、特に特許に関するものがますます増えています。 IETFの目標は、標準が広く使用されるように努力し、市場で有効であると認めてもらえるようにすることです。 もし標準を使用する製品を作るのに特許の使用料が必要ならば、誰も標準を実装しようとはしないでしょう。 当然ながら、一般的なルールは「可能であれば、特許がない優れた技術を使用せよ」です。

もちろん、これはいつでも可能というわけではありません。標準が確立された後に、特許が出てくることもあります。 非常に高価な特許があって、特許がないものに代替となるものがない、ということもしばしばあります。 標準の実装者に対しロイヤリティのいらないライセンスを与えてくれる寛大な特許所有権者もたまにいますが、その場合は、特許が全く存在しなかったかのごとく簡単に実装できるようになります。

標準の特許に対処するためのIETFの方法について、多くの議論がなされています。 IETFドキュメント(特許だけではない)のすべての知的所有権(IPR)に対するオフィシャルルールは、ここで扱っています。 [BCP78][BCP79]「IETFテクノロジーの知的所有権」ワーキンググループに参加する全ての人は、おそらくこのドキュメントを興味を持って見ており、皆がこのルールに従っている理由が分るでしょう。

IETF標準を実装している人に対して自由に特許を使用できるようにしてくれている特許所有者は、IETFでは皆から多くの好感を得ています。 そのような寛大さは想像以上に一般的なものです。 例えば、RFC1822はあるプロトコルコンテキストにおけるセキュリティ特許に関して IBMからライセンスされており、 セキュリティコミュニティはこれに対してとても好感を持ちました。(他の多くの会社はセキュリティ特許に関して頑なだったのでのけ者になってしまいました)。

もしインターネットドラフトを書いていて、その技術に関連しそうな特許があることを知っているなら、ドキュメントにその特許をリストしてはいけません。 その代わりに、どうやって続けるかを IETF IPRページhttp://www.ietf.org/ipr で相談してください。 RFCは発行された後に変更されることは決してないのですが、IPRの認識はいつでも変わりことがあります。 したがって、RFCのIPRリストは不完全なものであり、読み手をミスリードすることがあるかもしれません。 [BCP79]は、IPR問題に気づいた著者がRFCに加えなければならない文章を提供しています。

6.5 情報RFCと実験RFC

前に書いたように、すべてのRFCが標準というわけではありません。実際、多くの重要なRFCは全く標準化トラックにありません。 現在、標準規格を目指していないRFCであることを表すために、このタオのような情報(Informational)や実験(Experimental)という2つのタイプがあります。 (実際は3番目のタイプとして、過去に標準化されたものの現在では使われなくなったものを示したり、最新の研究で その技術が実はインターネットに有害であると判断されたものを示す歴史的(Historic)というものもあります)

情報RFCの役割はIETFでしばしば議論されます。特にIETF以外で作成された規格をIETFドキュメントから参照するような場合など、このようなRFCの存在を好む人は大勢います。 また、IETFワーキンググループで作業中のものに対する先行技術の仕様書としても役に立ちます。 その一方、自分が販売したりサポートしているものについて、無知な人をだまそうという意図で、 情報RFCを「標準」(標準でないにもかかわらず)として参照する人がいます。 このようなことが起こると、情報RFCに関する議論がまた行われます。

実験RFCは関心はあるものの、実装するほどのものなのか、実際に広く普及させて問題ないのかが不明確な規格のためのものです。 例えば、ある種の規格がある問題を解決してくれるものの、多くの人がその問題を重要と考えているか、 この規格で解決するのが良いのかが明確ではない場合に、実験RFCとしてラベルされることがあります。 後にこの規格が多くの人の関心を集めた(もしくは、うまく動作すると立証できた)場合、標準化トラックRFCとしてもう一度再提出できます。 実験RFCは、標準化トラックの素材となるかもしれない技術で未解決の疑問点がある場合に、実験を行なう人のために利用されることもあります。

IESGは、情報と実験のステータスをどうやって選ぶかに関するガイドラインを作成しました。 http://www.ietf.org/iesg/informational-vs-experimental.html あなたが実験RFCになるかもしれないドキュメントを作成しているなら、現時点の考え方を知ることによって、あなたの選択を正当化するのに役立つでしょう。


7. IETFに貢献するには

7.1 あなたにできること

読む — あなたの専門的技術のエリアのインターネットドラフトを査読し、ワーキンググループでそれについてコメントしてください。 ディスカッションにはフレンドリーで親切な態度で参加し、最高のインターネット標準ができることを目標としてください。 話すより聞くようにしてください。意見が異なるなら、技術的な課題を議論してください。決して攻撃的にならないでください。

実装する — 現在のインターネット標準を使用するプログラムを書きましょう。 インターネットユーザにとって、利用できなければ標準はあまり価値がありません。 たとえ「マイナーな」標準でも実装して下さい。多くのソフトウエアに実装されていけばマイナーではなくなっていきます。 標準の問題を発見したら、どんな内容でも適当なワーキンググループに報告してください。その標準は後の改訂で修正されます。 IETFで標語となっている主義の1つに「動いているコードが勝ち」というものがあり、より多くのコードを作成して動かすことによって、標準をより広範囲にサポートできるようになります。 標準規格になる前にプロトコルの開発を手伝うことがでます。I-Dから実装(配布はしないで)することによって、著者が良い仕事をしているのを確認することができます。 意見が異なるなら、技術的な課題を議論してください。決して攻撃的にならないでください。 間違いや足りないものを見つけたら、あなたの経験に基づく改良方法を提供してください。

書く — 専門技術のエリアでインターネットドラフトを編集するか、共著者になりましょう。 ドキュメントに名前(会社名はもってのほかです)を載せることを目的にやってはいけません。 インターネットコミュニティの利益のためにこれをしましょう。 ドラフト著者はあらゆる種類の技術的(ときには個人的なものも)な批判を受けることがあります。 冷静に受け止め、ドラフトを改良し、高品質で相互運用性の高い標準を作成するために利用しましょう。

7.2 あなたの会社ができること

共有する — 独占的標準を避けましょう。 あなたが実装者なら、IETF標準への強い意欲を示しましょう。もしあるIETF標準が独占的な規格に劣るなら、そのIETF標準をより良くするよう努力しましょう。 購買者であるなら、IETFの標準と競合する独占的標準を使用した製品は購入せずに、そのことを会社に伝えましょう。

公開する — IETF標準の中で使用している特許をコントロールしようとする会社があれば、標準を実装している 全ての人に対して特許を無料で利用できるように会社に納得させましょう。 標準を実装することを自由にできないようにしている会社のために、過去数年間に、特許はインターネット標準に関する多くの深刻な問題を引き起こしました。 幸い、多くの会社が特定の特許を気前よく無制限にライセンス提供してくれていて、IETF標準が普及する助けとなっています。 通常、これらの会社は他の特許所有者ほど貪欲でなく、また長い目で見て利益が得られるよう考えているので、積極的に公開しています。

参加する — ISOCのメンバーになりましょう。より重要な事として、ISOCの法人会員になるようにインターネットから利益を得ている全ての会社に促しましょう。これにはグループにとって最も大きい財政的な恩恵があります。 もちろんインターネット全体にも恩恵があります。


8. IETFと外の世界

8.1 IETFと他の標準化団体

IETF参加者の多くがそうではないと考えたがっていますが、IETFだけが標準化組織ではありません。 その決定がインターネットに影響を与える多くの(多過ぎるようです)標準化組織が他にもあります。 長い間インターネットを拒否してきて、今になって分け前を得ようとしているかなりの数の標準化団体があります。

一般に、IETFは他の標準化団体と親密な関係でいようとしています。 他の多くの団体はIETFとは全く異なった構造になっていることや、 IETFは、他の団体の代表に会ったりするより標準を書いているのが好きなボランティアによって運営されていることなどから、 このことは必ずしも簡単ではありません。 それでも、明らかに異なる文化があるにもかかわらずIETFと交流を深めようとしてくれる他の標準化団体もあります。

これを書いている時点で、IETFにはすでに大きな標準化団体との繋がりがあります、ITU-T(電気通信標準化部門)、W3C(ワールドワイドウェブコンソーシアム)、IEEE(アイトリプルイー)、ユニコードコンソーシアム等です。 IAB憲章[BCP39]では、こう述べています。 「リエゾンはできるだけ格式張らずに、IETF標準の品質を改善させる価値を示さなければならない。」 より公式な関係とリエゾンドキュメントをバックアップの役割として使いながら、実際にはIETFではワーキンググループのレベルに直接リエゾンを置くようにしています。

これら連絡作業のいくつかはIESGが担当し、他のものはIABが担当します。 細かい事が好きなリーダーは、[BCP102]「IABプロセス:IETF連絡関係の運用」や、 [BCP103]「IETFの連絡取り扱いステートメントの手続き」かあら 他の標準化団体と付き合っていくための形式的な手法をたくさん学べるでしょう。 IETFにどのような公式のリエゾンがいるかを確認するのに最も良い場所はIETFリエゾンリストです。 http://www.ietf.org/liaison このリストでは、ISO/IEC JTC1小委員会への連絡が数多くあるのが分ります。

8.2 IETFと報道

IETFは、インターネットの未来を担う最もよく知られている団体のひとつであるので、コンピュータ雑誌(業界誌でさえ)がIETFの動きをカバーし続けているのは、当然です。 近年では、いくつかの雑誌が長期間にわたってIETFを徹底的にカバーするためにレポーターと編集者を選任しました。 これらのレポーターには、間違って書いた記事による大きな打撃、インターネットドラフトの状況に関する不正確な発表、IETFの作業に関係ない人からの引用など、いろいろな問題があります。

出版社の主な間違いには2つの種類があります。ワーキンググループのインターネットドラフトが存在することでIETFが何かを検討したとか、 情報RFCが発行されたことで何かをIETFが承認したとか、そういう事です。 どちらの場合も、自分達が開発または少なくともサポートしているプロトコルを宣伝しようとする会社の話が少し変更されて伝ったことが 原因だったりするので、レポーターが完全に悪いという問題ではありません。 もちろん、レポーターがもう少し調査したら、WG議長やエリアディレクターといっただれかに連絡して、それを正すことができたでしょう。 レポーターがIETFに連絡を取るときに最初に探すべき場所は、 <http://www.ietf.org/media.html>です。

一度間違ったことがあるレポーターが、またIETFミーティングに戻ってくるような場合、いつかは正しく理解できるのではないかとも思えます。 しかし、IETFミーティングは、IETFプロセスに無知なレポーターのためのものではありません(あなたがレポーターで、このドキュメントを読んでいるなら大いに見込みがあります!)。 また、あなたがIETFミーティングに出席することで、何かホットな記事をものにすることを期待しているなら、失望してしまうかもしれません。

このすべてを考慮すると、レポーターがミーティングにでき限り近付かないことを望むIETF参加者がいても、驚くべきものではありません。 ほぼ完成に近く翌年には業界で重要になっているかもしれないプロトコルにとっては、ある程度のメディア露出は良いことかもしれません。 しかし、できあがったばかりのプロトコルをインターネットの救世主のように過剰に宣伝する誘惑に抵抗できようなレポーターはめったにいません。 そのような話は、記事の読者とIETF両方にとって、利益どころかはるかに多くの害を与えてしまいます。

レポーターがIETFミーティングに出席したがっている主な理由は、最新の技術(快適なオフィスでメーリングリストを読めば済むような内容です)をカバーすることではなくて、 人々に直接会うことです。 残念ながら、レポーターが最も注目している人はIETFミーティングの間最も忙しい人でもあるので、レポーターバッジを見ると逃げ出してしまう人すらいます。 しかしながら、IETFミーティングは、ドキュメント著者とワーキンググループ議長に会って話ができる素晴らしい場所です。 プロトコルの進化をカバーしているレポーターにとって、これはかなり貴重なものとなるでしょう。

「IETFが何をしているか」という話題についてレポートしたいレポーターなら、その話題に関して活躍している複数のIETFの人と話すことを強くお勧めします。 そして、たぶんどのような場合でもWG議長と話をするよう試みるべきでしょう。 ドラフトを見たり、またはドラフトの著者と話すことによってドラフトに何が起こるかを判断するのは不可能です。 幸い、すべてのWGがドラフトに関する最近の動向や進捗に関するアーカイブを持っているので、レポーターはそれに目を通すことができます。 残念ながら、この種類の調査を行うやる気や時間があるレポーターはあまりいませんが。 IETFには報道の連絡係がいないので、間違えた記事を掲載する雑誌や新聞は直接IETFから話を聞いていなかったりするものが多く、それらが間違っていたことすら知ることができず、後に再び同じ間違いをしてしまいます。


9. セキュリティ問題

Section 6.4.4において、各RFCがなぜセキュリティ問題セクションを持つ必要があるかを説明しており、何を含んでいて、 何を含むべきでないかに関するヒントを示しています。 その情報以外に、このドキュメントはインターネットセキュリティには触れていません。

10. 有用な情報入手先

[BCP9] Bradner, S., “インターネット標準規格プロセス-第3版”, BCP 9, RFC 2026, RFC 6410, October 1996.
[BCP10] Galvin, J., “IABおよびIESG選出、承認、リコールプロセス:指名とリコール委員会のオペレーション”, BCP 10, RFC 3777, June 2004.
[BCP11] Hovey, R. and S. Bradner, “IETF標準過程に関する組織”, BCP 11, RFC 2028, October 1996.
[BCP14] Bradner, S., “指示要求レベルへのRFCsの使用のためのキーワード”, BCP 14, RFC 2119, March 1997.
[BCP22] Scott, G., “インターネット標準規格の著者のためのガイド”, BCP 22, RFC 2360, June 1998.
[BCP25] Bradner, S., “IETFワーキンググループガイドラインと手続き”, BCP 25, RFC 2418, September 1998.
[BCP26] Narten, T. and H. Alvestrand, “RFCのIANA検討セクション記述のガイドライン”, BCP 26, RFC 5226, May 2008.
[BCP39] インターネットアーキテクチャ評議会 and B. Carpenter, “インターネットアーキテクチャボード(IAB)の憲章”, BCP 39, RFC 2850, May 2000.
[BCP45] Harris, S., “IETFディスカッションリスト憲章”, BCP 45, RFC 3005, November 2000.
[BCP72] Rescorla, E. and B. Korver, “セキュリティ問題のRFCテキスト記述のガイドライン”, BCP 72, RFC 3552, July 2003.
[BCP78] Bradner, S., “貢献に関するIETFの権利”, BCP 78, RFC 5378, November 2008.
[BCP79] Bradner, S., “IETF技術の知的所有権”, BCP 79, RFC 3979, March 2005.
[BCP95] Alvestrand, H., “IETFの基本規約”, BCP 95, RFC 3935, October 2004.
[BCP97] Bush, R. and T. Narten, “標準トラックドキュメントが低レベルのドキュメントを基準参照することが許されるケース”, BCP 97, RFC 3967, December 2004.
[BCP101] Austein, R. and B. Wijnen, “IETF管理用サポート活動(IASA)の構造”, BCP 101, RFC 4071, April 2005.
[BCP102] Daigle, L. and インターネットアーキテクチャ評議会, “IETFリエゾン関係の運用に関するIABプロセス”, BCP 102, RFC 4052, April 2005.
[BCP103] Trowbridge, S., Bradner, S., and F. Baker, “IETFにおけるリエゾンステートメントの取扱い手続き”, BCP 103, RFC 4053, April 2005.
[RFC1796] Huitema, C., Postel, J., and S. Crocker, “全てのRFCが標準ではない”, RFC 1796, April 1995.
[RFC2223] Postel, J. and J. Reynolds, “RFC著者への指示”, RFC 2223, October 1997.
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, “インターネット割り当て番号権限の技術的作業に関する覚書”, RFC 2860, June 2000.
[RFC6635] Kolkman, O. and J. Halpern, “RFCエディットモデル(第2版)”, RFC 6635, March 2012.
[RFC4677] Hoffman, P. and S. Harris, “IETFのTao:初心者のためのインターネット技術タスクフォースガイド”, RFC 4677, September 2006.
[RFC4858] Levkowetz, H., Meyer, D., Eggert, L., and A. Mankin, “ワーキンググループ公開へのラストコールからのドキュメント指導”, RFC 4858, May 2007.
[RFC6722] Hoffman, P., “「IETFのTao」ウェブでの公開”, RFC 6722, August 2012.
[STD3] Braden, R., “インターネットホストのための要求ーアプリケーションとサポート サポート”, STD 3, RFC 1123, October 1989.

A. IETFにおいて従うべき原則

タオのここまでたどり着いたのなら、IETFの仕事がどのようなものか大いに学んだはずです。 この付録には、これまでの要約と考察のために新たなポイントを収録しています。 すべての原則を必ず読み通してください。 全体として見ることで、IETFの仕事について新たな観点を得ることができるでしょう。

A.1 一般事項

IETFはオープンなプロセスと大まかな合意によって動いています。 これは、IETFドキュメントの作成や使用されたプロセスを含む、IETFのオペレーションの全てに適用されます。 しかし、IETFは興味をもって実験や動作しているコードを見守り、これは組織の操作上のプロセスにも適用されるべきです。

IETFは、技術的な資産がある、もしくは見つけられる領域で活動します。

IETFは積極的なボランティアの参加者に頼っています。

IETFやそのWGへの参加は、報酬や特定の組織に依存するものでもなく、自己認識と積極的な参加に基づいています。

A.2 マネジメントとリーダーシップ

IETFは、リーダに対してリーダーシップの地位と決定権を与えますが、決定は上訴を受けることがあります。

権限と責任の委任は、IETFの作業を効率的にするには不可欠です。 できるだけ多くの個人がIETF事業のリーダーシップと取り組んでいくことを奨励します。

異議、苦情、訴えは、IETFの自然な結果であり、正常な事象と見なされるべきですが、最終的にある種の決定には有効に上訴できないというのも人生の真実です。

リーダーシップの地位には一定の任期があります。(しかし、公式な再選回数の制限のようなものはありません)。

実際のコミュニティの中で将来のリーダを育てるのは重要なことです。

コミュニティのプロセスは、リーダーシップを選択するのに使用されます。

リーダーは、大まかな合意が実証された事を判断する権限を与えられます。 正式なメンバーシップがないので、合意のための公式な規則もありません。

A.3 プロセス

IETFには通常のケースのための明確でオープンな明文化されたプロセスルールが必要ですが、 例外的なケースを常識的な判断で扱う柔軟性もあるべきです。 個人的な判断を適用し、確信のあるときだけ成文化します。(しかし、誰が個人的な判断をできるかは成文化します)

技術的な開発作業は、憲章や焦点がしっかり合っているワーキンググループによって行れるべきです。

非実用的だと判明したプロセスのパーツは、消すか、またはオプションにします。

A.4 ワーキンググループ

ワーキンググループ(WG)は主に成果の品質に責任を持つべきです。 IETFリーダーシップによってバックアップされたWGリーダとしてのWG議長は、品質保証の安全装置として機能すべきです。

WGは主としてインターネット全体の中での負の面を考えることに責任を持つべきであり、したがって、関連するエリアの審査を必要としています。 IETFリーダーシップは関連するエリアの安全装置として機能すべきです。

早い段階でのドキュメントのレビュー(特にWGによる)は、大きな問題に対処するには効果的です。

エリアディレクター(AD)は、WGの構成と特権を誘導すること、必要に応じて方向性を与えること、終了することに対しての責任があります。 WG議長は対応するADに仕えます。

WG議長は、WGが憲章を実行し、マイルストンを満たし、公開の準備ができている提出物を生産する作業を確実にする責任があります。 ドキュメントエディターはWG議長に仕えます。

ADは安全対策としての審査の手配と最終ドキュメントの承認に責任をもちます。

A.5 ドキュメント

IETF標準規格は、個人的なドラフトから始まることがあり、WGドラフトになることもあり、WGから独立したリーダーシップ団体か著者によって 永続的な発行が承認されています。

IETF標準は著者ではなく、コミュニティに属します。 しかし、著者は、すべてではなくても一定の寄与があると認識および評価されます。

技術的な品質と正当性は、ドキュメントに対する合意が得られるための主要な基準です。

IETFの仕様書は、情報、実験、標準化トラック、歴史的、現時点での最良の慣行(Best Current Practice)として発行されます。

IETF標準規格トラックの仕様書は、相互利用できる独立した実行が実証されるまでは、完璧な標準であるとはみなされません。 (これは「動いているコード」というスローガンの現れです) しかし、IETFは相互利用テストに責任を持ちませんし、相互利用性を保証しません。

IETFプロセスは現時点での最良の慣行(Best Current Practice)ドキュメントとして発行されます。

仕様書ではなくプロセスでもない役に立つ情報は、情報RFCとして発表されます。

時代遅れになった、または推奨しない仕様書やプロセスは歴史的RFCに格下げされることがあります。

標準化トラックは、相互運用を実証したものとそうでないものを区別します。

標準化トラックと現時点での最良の慣行(Best Current Practice)ドキュメントは、IETFの広い大まかな合意(ラストコールプロセス)を必要としています。 一般的に、他のドキュメントにもWGの大まかな合意が適用されます。

IETFラストコールまたはIESGの評定の結果、大規模な変更が行われた場合は、WGへ差し戻さなければなりません。

IETFはドキュメントの公開と記録に関する必要事項を決定します。