JPNIC
社団法人 日本ネットワークインフォメーションセンター

JPNIC RFC-JP
トップWhat is IETF

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




[章目次]
- 概要
- はじめに
- IETFの背景と歴史
- IETFの組織構造
- IETFにおける標準化プロセス
- IETF会合の様相
- むすび

著者について
[RFC-JPトップページ]



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な仕様を作成し、 相互接続実験や実運用を通じて、詳細な仕様が実装される。これは、次の 2つの理由によるものと考えられる。(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の違いを簡単にまとめた。

    インターネットシステムの思想図
    図4. IETFインターネットシステムの思想

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

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




    Copyright (c) Hiroshi Esaki All Rights Reserved.
    Copyright (c) Japan Network Information Center. All Rights Reserved. | Contact