メインコンテンツへジャンプする

JPNICはインターネットの円滑な運営を支えるための組織です

ロゴ:JPNIC

WHOIS 検索 サイト内検索 WHOISとは? JPNIC WHOIS Gateway
WHOIS検索 サイト内検索

2001年2月8日

IETFにおける標準化プロセス

Internet-Draft、RFC

Internet-Draftは、各個人が自由に投稿することができ、6か月間、 IETFのFTPサーバおよびWebサーバに置かれる。 Internet-Draftは、 6ヶ月でArchive から消えていくWorking-in-Progressのドキュメントである。 各個人および各Working Groupは、Internet-Draftが、 広くインターネット業界に有用な情報を含んでいると判断すると、 これを、RFC(あるいはBCP, Best Current Practice)にするようIESGに申請する。 申請が承認されると、 ドキュメントにはRFC番号(あるいはBCP番号)が割り当てられ、 公式にIETFのFTPおよび Webサーバを通じて恒常的に参照可能なドキュメントとなる。 なお、RFCには、4種類のドキュメント種別が存在していおり、 情報の性質により区別される。 図3に、IETFにおけるInternet-DraftのRFC化のプロセスを示した。

図:Internet-DraftのRFC化プロセス
図3. Internet-DraftのRFC化プロセス
Informational RFC
標準化トラックではないが、業界にとって有用な情報。 例えば、各組織固有の仕様であっても、それが、 標準仕様の議論や策定に有効と認められる場合に、 RFCとすることができる。 企業が、標準化を待たずに製品展開を行うような場合に、 Informational RFCとしてその仕様を広く公開し、 De Facto Standard の地位を確立するための手段としてもしばしば利用されている。
Standard Track RFC
Working Groupでコンセンサスが取られた業界での国際標準とすべき仕様をまとめたドキュメント。 PS(Proposed Standard)、DS(Draft Standard)を経て、 S(Standard)となる。 PSは複数の組織での独立な実装テストと相互接続性の確認が条件、 DSは実質的かつ広範囲での運用テストが条件となっている。 S(Standard)の状態になると、STD番号が割り振られる。 現在、STD番号を割り振られているドキュメントは非常に少数であり、 実質的には、DSのRFCになると、国際標準とみなすことができる。
Experimental RFC
標準化が目的ではなく、 研究等の目的で検討される技術仕様に関するドキュメント。 純粋な研究目的の場合と、企業が企業固有の仕様を使ってそれを、 De Facto化しようする場合などに用いられる。
Historical RFC
標準化の過程での議論の経過など、 過去の記録として残すべき情報に関するドキュメント。 IPv6技術の検討経過などが、Historical RFCとなっている。

各組織は、各自のIETFにおける発言力とビジネス戦略に基づいて、 どのトラックを用いて技術仕様のDe Facto化を進めるんべきかを検討している。 Standard Trackでの活動は王道であるが、ドキュメントが作成され、 RFCとなるまでは、1年以上の月日を必要とするのが一般的であり、 Informational RFCやExperimantal RFCを用いて、 より迅速な仕様の公開と普及(= De Facto化)を図る組織も少なくない。

Rough Consensus, Running Codeの重視

IETFにおける技術仕様の策定は、ITU-TやISOとは異なり、 非常に詳細な部分までは規定しないのが一般的である。 すなわち、Roughな仕様を作成し、相互接続実験や実運用を通じて、 詳細な仕様が実装される。 これは、次の二つの理由によるものと考えられる。

  1. 実装者に工夫が可能な領域を残すことにより、よりよい実装が登場する可能性を与える(e.g., TCP)。
  2. 実装や運用を通じて必要な仕様が明かになる場合が非常に多い。

これが、Rough Consensusの意味である。 また、RFCがProposed Standardとして認められるためには、 複数の組織での独立な実装と相互接続性の確認が必要とされる。 これは、実際に動作したことが、 その仕様の正当性を証明していると考えているからである。 すなわち、Running Codeがないと、標準仕様としては、認められない。

これは、ITU-TやISOと大きく異なる点である。 IETFでは、基本的には、実装(Running Code)のない仕様は認められることはない。 また、仕様の作成は、非常にRoughであり、 ITU-TやISOでの仕様の作成手順とは、大きく異なる。 これは、ITU-TやISOは「標準は変わらないもの」で誰でも 「仕様通り」に実装すれば相互接続可能なシステムを作ることができなければならないという思想であるのに対して、 IETFは「標準は変わるもの」で相互接続可能なシステムを作るにはさまざまな実装上の工夫を行うのが当然であるという思想であることの現れであろう。 別の言い方とすれば、ITU-TやISOはトップダウンの標準化であり、 一方、IETFはボトムアップの標準化であると言えよう。 図4に、ITU-T/ISOとIETFの違いを簡単にまとめた。

図:IETFとインターネットシステムの思想
図4 ITU-T/ISOとIETFの違い

知的所有権に関する考え方

過去のIETFにおける知的所有権に関する考え方は、 フリーソフトウェアあるいはシェアウェアの考え方に基づき、 知的所有権としては、著作権は主張するが、 仕様の利用やソフトウェアの改変や利用に対しては、 ほとんど制限をしなかった。 しかし、インターネット産業が発展成長するのに伴い、 徐々に知的所有権に関する考え方が変化してきた。 標準化された仕様は、広く利用されることが重要なので、 標準化される仕様は、特許などで押さえられており、 その所有者が技術の普及を妨げない対価以下のみしか要求しないということが保証された技術に基づいたものであることが望ましいと考えられるようになってきた。

文責 江崎 浩 (Hiroshi Esaki) 東京大学大学院情報理工学系研究科 教授/WIDE Projectボードメンバー

このページを評価してください

このWebページは役に立ちましたか?
よろしければ回答の理由をご記入ください

それ以外にも、ページの改良点等がございましたら自由にご記入ください。

回答が必要な場合は、お問い合わせ先をご利用ください。

ロゴ:JPNIC

Copyright© 1996-2024 Japan Network Information Center. All Rights Reserved.