The Internet Engineering Task Force

インターネット・エンジニアリング・タスクフォース


Scott Bradner
スコット・ブラドナー
Translation by Akira Kurahone


 インターネット・エンジニアリング・タスクフォース(IETF)は、インターネットのよりよいアーキテクチャやスムーズなオペレーションを目的に、インターネットの標準化を中心にボランティア活動を展開している団体である。しかし法人としては設立されていない。それゆえ、法的実態のない活動上だけの存在である。だが、インターネットのコミュニティに対する影響力は大きい。TCP/IPは別として、インターネットの基本テクノロジーはIETFのメンバーによって開発されたり、改良されてきている。IETFのワーキンググループは、インターネットのルーティング、管理、そしてトランスポート等の仕様に関して、様々な標準を定めている。これらの標準がきちっと定められていなければ、いまだにインターネットはこの世に存在していないだろう。IETFのワーキンググループは、セキュリティについての標準化も行なっている。インターネットのサービスの質についても、いろいろ発言してきている。IETFが頑張ってきたおかげで、いまインターネットは、本当に安心して使えるものになっている。質の高いサービスが受けられる環境になっている。これらの活動に加えて、IETFは、インターネットの次世代プロトコルの標準化も推進している。
 IETFが音頭をとって定めた標準は、非常に効果的に作用し、すばらしい成功をおさめ、インターネットはこれまでに登場したどんなテクノロジーよりも急速に発展している。誕生してそれほど間もないのに、その発展・普及の勢いたるや、鉄道、電灯、電話、そしてテレビもしのぐほどだ。しかもそのすべてが、「自主的な」標準化活動のたまものとしてなしとげられている。これまで、様々な世界的標準が生まれては消えていった。中には政府が強制したものもあった。しかし、IETF標準はいまだに生き残っている。しかも、そのどれをとっても、政府によって要求されたものではない。とはいえ、IETFの提案した標準のすべてが成功し、生き残っているわけではない。IETF標準のうち、現実世界の具体的な要求に応えられたものだけが、実質的に真の標準として生き残っているのである。
 IETFとその各種標準は、オープンソースコミュニティが花開いたのと同じ理由によって受け入れられ、成功している。IETFにおける標準化活動には、希望するものは誰でも参加できる。IETFの各種標準は、来る者を拒まずの開かれたプロセスで作成されている。IETFが作成するドキュメントは、何に関するものであれ、インターネット経由ですべて入手できる。自由にコピーして再配布できる。実際問題、IETFがドキュメントを公開するプロセスは、オープンソースソフトウェア運動の可能性を探るケーススタディでもある。
 本章では、IETFの歴史を簡単に述べていきたい。具体的には、IETFがどのように組織され、どのように機能しているかについて簡単に振り返りながら、オープンスタンダード、オープンドキュメント、そしてオープンソースがいかに重要であるかについて考察していくことにする。


IETFの歴史
 IETFは一九八六年一月、アメリカ政府の資金提供を受けている研究者が年四回開くミーティングという形で始まっている。しかし同年十月の四回目のミーティングからは、民間ベンダーの代表も招かれ参加するようになり、そのとき以来、誰でも出席できることになった。当初の規模はこぢんまりしたものであった。ちなみに、第一回から第五回までは、出席者が三十五人に達していない。十三回まででもっとも出席者が多かったのは一九八九年一月のミーティングである。それでも百二十人が参加しただけである。ミーティングへの出席者数はその後急速に増加し、一九九二年三月の第二十三回では五百人以上が参加している。一九九四年三月の第二十九回では出席者数が七百五十人を超え、一九九四年十二月の第三十一回ではついに千人を超えている。そして一九九六年十二月の第三十七回の参加者は、二千人近くにまで膨れあがった。その後、増加の勢いは少し鈍り、一九九八年十二月の第四十三回では二千百人ほどになっている。なお、オフラインで開催されるミーティングの頻度は、一九九一年以降、年四回から三回になっている。
 IETFは、小さな事務局をバージニア州レストン市に持っている。また、(インターネットに関する技術や提案などが書かれたドキュメントである)RFCもオンラインで発行されており、現在は南カリフォルニア大学の情報科学研究所がRFCエディタとしてドキュメントの公開をボランティアベースで担当している(RFCは、Request For Commentsの略称である)。
 本章の最初のところで述べたように、IETF自体は法人として設立されているわけではなく、法的実態のない活動上だけの存在である。活動にともなう経費も、一九九七年末までは、アメリカ政府の補助金と会合参加費収入だけでまかなわれていた。一九九八年からは、会合参加費とインターネットソサエティからの支援で運営されている。
 インターネットソサエティは、IETFにおける標準化活動に法的保護を与え、関連活動に多少なりとも資金を提供することを目的に一九九二年に設立されている。インターネットソサエティは、国際的な非営利組織として、インターネットを普及させていくための啓蒙活動もしている。いまのところIETFは、インターネットソサエティの支援のもと、インターネットの標準化活動をする団体として機能している、と考えるのがいちばん適切であろう。
 IETFは、技術分野ごとのワーキンググループ単位に活動している。この概念は、一九八七年二月の第五回IETF会合で導入されたものであるが、現在活動中のグループは総数で百十を超えている。


IETFの組織とその特徴
 IETFは会員資格をとくに定めていない会員組織と言うことができる。個人であれば誰でも会員になれるが、組織が会員になることはできない。入会手続きなどはとくになく、IETFのメーリングリストに加入するか、年三回開かれるIETFのオフラインミーティングに参加すれば、誰でも個人レベルで会員になれる。
 IETFから正式に認可を受けているワーキンググループは、本章の執筆時点で百十五グループある。ワーキンググループは、次の八つのエリアに分類されている−アプリケーション(Applications)、一般(General)、インターネット(Internet)、運用と管理(Operations and Management)、ルーティング(Routing)、セキュリティ(Security)、トランスポート(Transport)、ユーザサービス(User Service)。各エリアは一人ないし二人のエリアディレクタにより管理されている。エリアディレクタと、IETFの代表で構成されるのが、IESG(Internet Engineering Steering Group)と呼ばれる管理機構である。IESGはIETFの活動の技術的な管理とインターネットの標準化を受け持ち、IETFの標準承認機関の役目を果たしている。この外にも、IETFにはIAB(Internet Architecture Board)と呼ばれる十二人構成の組織がある。IABは、ワーキンググループの編成やアーキテクチャ面などについて、IESGにアドバイスする役回りを担っている。
 IABのメンバーとエリアディレクタは、毎年、直前の三回のオフラインミーティングに少なくとも二回出席したボランティアの中から、選考委員会が無作為に選出する。任期は二年である。


IETFのワーキンググループ
 IETFはボトムアップでの活動を主体とする組織である。ここがIETFと他の組織とが大きく異なる点である。組織の編成もボトムアップであるから、IESGやIABが、何らかの問題を重要視してワーキンググループを(トップダウン的に)設けるということはまずない。関心のある人びとが自発的に集まって、エリアディレクタにワーキンググループの結成を提案するケースがほとんどなので、IETF自体が将来の計画を主導的立場から立案することはできない。しかし、様々な提案がボトムアップで持ち上がってくるので、IETFは、ワーキンググループの活動を成功させるための熱意と専門知識を十分に持ち合わせている、と言える。
 ワーキンググループを結成したいとの提案があると、エリアディレクタは、その提案の当事者たちと話し合い、そのグループをどのような性格のものにするかを決める。グループの活動内容をどのようなものにするか、他のグループとの連絡はどのようにとるかを決定し、最後に、グループの活動範囲を定義する(この決定がもっとも重要である)。様々な決定事項は文書化され、コメントや意見を仰ぐために、草案としてIESGとIABのメーリングリストに投稿される。一週間以内に重大な問題点が指摘されなければ、草案は外部向けのメーリングリストにポストされる。標準化の活動をしている他団体と連絡をはかるために使用されているメーリングリストにもポストされ、他のフォーラムで似たようなワーキンググループがすでに立ち上がっていないかが確認される。ここでも一週間の猶予期間を設けたのち、IESGが発足を承認した時点で、そのワーキンググループが正式に誕生する。


IETFの発行するドキュメント
 IETFはすべてのドキュメントを公開している。それらは、インターネットの様々な配布元から誰でも自由に無料で入手できる。IETFはドキュメントを公開するとき、その継続的な入手性を確保するために著者から限定的な著作権を得ている(そのため著者といえども、いったん公開したドキュメントを取り下げることはできない)。公開ドキュメントは、誰でも自由に再配布できる。ほとんどの場合、公開ドキュメントの取り扱いに関するIETFの標準手続きの範囲内で、二次著作物(たとえば翻訳)を作成することもできる。これら以外の著作権は、すべて著者に帰属する。
 IETFの発行する文献の多くは、RFCである。「Request for Comments」の略語であるRFCは、コメントを仰ぐ性格の文献としてスタートしているが、現在では公開に先立って内容が徹底的に検討されるので、暫定的な文献というニュアンス抜きで通用するようになっている。RFCは、標準化について記述したものと、標準化以外の事柄について記述したものとに大別される(前者が「標準トラックRFC」、後者が「非標準トラックRFC」である)。標準トラックRFCは、そのステータスによって提案標準(Proposed Standard)、草案標準(Draft Standard)、インターネット標準(Internet Standard)の三つの種類に分類される。非標準トラックRFCは、情報(Informational)、実験(Experimental)、履歴(Historic)の三つに分類される。
 IETFではRFCのほかに、インターネットドラフトも活用している。これは暫定的な草案で、RFC本来の“`request for comments”の概念に近く、進行中の作業に関するもの以外は引用したり、参照されたりすることはない。インターネットドラフトは、公開後六か月で自動的にインターネット上から削除される。


IETFにおける承認手続き
 IETFは、「コンセンサスは大ざっぱに、しかしコードは使えるものに」をモットーとしている。したがって、提案は、必ずしもワーキンググループのメンバー全員の同意が得られなくても採用されうる。ただし、どんな提案でも、採用される場合には、メンバーの大半が同意していることが前提となっている。90%以上の賛成が得られれば、たいていの提案は採用されるが、だからといって、採用に必要な支持率が明示的に定められているわけではない(ちなみに、支持率が%未満だと、却下されることが多い)。ワーキンググループ内で票決は行なわれないが、メンバー個人の意志をはっきり確認するため挙手を求めることはある。
 非標準トラックRFCは、ワーキンググループが提出することもあれば、自分の考えや技術提案をインターネットコミュニティに伝えたい個人が作成することもある。提案が出されると、IESGがそれを検討し、その後、それを公開すべきか否かについてIESGがRFCエディタにアドバイスする。それを受けてRFCエディタは、公開するか否かを決定する。なお、IESGは、提案内容に警告に値する内容が含まれていると判断した場合、その点を注釈の形で記述したものをRFCエディタに渡すことができる。RFCエディタは、公開ドキュメントにそれを含めるか否かについても決定する。
 標準トラックRFCの場合、ワーキンググループはまずインターネットドラフトを作成し、それを推敲したものをRFCとして公開するのが普通である。提案に対するワーキンググループ内での最終段階は、「ラストコール」と呼ばれる、通常二週間の猶予期間である。その間にワーキンググループ内では、代表者が、メーリングリストを使って、提案内容に著しい問題点があるかについての呼びかけを行なう。ワーキンググループ全体の意志が確認されると、ドキュメントはIESGに渡され、そこでの評価を受けることになる。IESGは、まず、IETF全体としてのラストコールを、メインのメーリングリストに掲示する。それまでそのワーキンググループの活動を把握していなかった人たちが、提案について意見を述べることができるようにするためである。IETF全体のラストコール期間は、提案がワーキンググループからの場合は二週間、それ以外の場合は四週間となっている。
 IESGは、ラストコールの結果を参考にして、提案を吟味し、ドキュメントを承認してRFCとしての公開を求めることができる。IESGでの評価結果をもとに、提案者(たち)に対して、ドキュメントの修正を求めることもできる。標準トラックRFCも、同様な手続きを踏んで承認される。
 通常の提案は、提案標準(Proposed Standard)として標準トラックRFCに持ち込まれるが、提案によっては技術面で不確定な要素があることもある。追加テストが必要と思われることもある。そのような提案は、まず実験RFCとして公開される。提案標準は、技術的な観点から、優れたアイデアと判断されるものでなくてはならない。実験RFCとしての公開から六か月を経過すると、提案は草案標準とみなされる。草案標準として受け入れられるためには、記述が明快でなければならない。知的所有権に関する諸問題が理解され、解決可能となっていなければならない。そのために、共通の操作性を有する実装系が最低二種類用意されていなければならない。可能な場合には、複数のライセンス形態も用意されていなければならない。提案がプロトコルに関するものである場合には、複数の実装方法が可能になっていなければならない。そして、これらの条件に適さない部分は、提案内容から削除される。こうしてIETF標準は、承認手続きが進むごとに簡素化されていく。IETFは、提案内容を使用可能なコードのレベルにまで磨き上げていくこの手続きを、「コードは使えるものに」というモットーで表現している。
 標準RFCの最終段階が、インターネット標準である。草案標準として最低四か月経過し、市場で成功する見込みを示せた提案がインターネット標準として採用される。これが、IETFにおける標準承認の最終手続きである。
 IETFの標準トラックは、他の団体における標準の採用と二つの点で大きく異なっている。ひとつはステータスの違いである。たいていの標準化団体では、IETFで言うところの草案提案ステータス扱いにすぎない提案が最終提案として承認されることが多い。優秀なアイデアではあるが、実際に使えるコードのレベルを含む提案ではない。もうひとつの違いは、全員一致ではなくゆるやかなコンセンサスを得るだけで提案承認手続きを進めていけるので、ただ声の大きな人間が変な影響力を行使できない、という点である。
 IETFは、ボトムアップ方式で組織を運営し、「fly before you buy」(実際に動作することを確かめてから、決定を下すポリシー)を実践している。


オープンスタンダード、オープンドキュメント、そしてオープンソース
 IETFがこれほど成功したのは、標準採択のプロセスや関連ドキュメントをすべて公開しているからである。IETFでは、あらゆるドキュメントが自由に入手できる。メーリングリストや会合への参加も自由である。標準化団体で、そこまでオープンなところはあまりない。昔からある標準化団体の多くは、ドキュメントの入手をメンバーだけに限定しているところが多い。新しいインターネット関連のグループの中にも、そのような制約を設けているところがある。また、会合への参加資格をメンバーに限定しているところもある。団体参加費を支払った場合にだけ、そのようなことができるところもある。運営資金を確保するためにやむなく金銭を徴収している団体もあるが、組織によっては、会費を払わなければメンバーになれず、メンバーにならなければ非公開の標準設定のプロセスに参加できない。非公開の採択過程の標準にアクセスできない。
 誰もが自由に標準設定のプロセスに参加できない場合、標準がユーザやベンダーのニーズに十分対応できないものになってしまうことがある。現場がサポートできないくらい複雑なものになってしまうこともある。採択過程のドキュメントが非公開でアクセスできないと、標準内の特定の仕様が何に由来しているのかがよくわからない。どんな根拠でそこにあるのかがよくわからない。その結果、標準が正しく実装されない危険性がある。標準にアクセスできる者が限られていると、学生や小さい新興企業の開発者が、その標準について理解し、活用する機会が奪われてしまう。
 IETFは、オープンソース運動が始まるずっと前から、ソースコードレベルで情報を公開し共有するという、オープンソースの概念を支持してきた。たとえば、最近まで、IETFは、標準トラックRFCの承認プロセスにおいて、プロトコルなどの技術提案がリファレンス実装(参照実装とも訳す)であることをひとつの条件としてきている(「リファレンス実装」とは、第三者が開発時に実例として(ソースコードレベルで)参照できる実際に機能する標準的な実装例を含む、という意味である)。「リファレンス実装」は、IETFの正式な要求ではない。しかし、この条件が非常に有効に作用していることは事実である。残念なことに、標準の内容がますます複雑になり、その経済的な影響が大きくなっている昨今、「リファレンス実装」が以前ほど有効的に作用していないきらいがあるが、IETFがそれを技術提案に求めなくなってしまったわけではない。オープンソース運動によって「リファレンス実装」が再び積極的に求められるようになれば、これからも大いに役立つはずである。
 オープンソース運動にとって、プロトコルなどの標準化プロセスをオープンにすることと、すべてのドキュメントを公開することは不可欠である。オープンソース運動のような分散型の開発作業では、標準ドキュメントを使って作業内容の仕様を明確にする。標準ドキュメントがなければ、開発の意思統一がとれず、作業はばらばらで収集のつかないものになってしまう。オープンスタンダード、オープンドキュメント、そしてオープンソースは、もともとパートナーの関係にあるものである。インターネットを生み出したこのパートナーシップは、これからも多くの偉業をなしとげるにちがいない。