2000年9月27日
2016年7月4日追記

インターネット標準化過程

『標準化過程(Standards Track)』とはインターネット標準を形成するプロセスである。 RFCの分類で説明したように標準化過程の発展段階は以下のようなRFCの分類の遷移によって表現される。

標準への提唱(PS - Proposed Standard)
標準への草稿(DS - Draft Standard)
標準(STD - Standard)

これらのRFCがどのような基準で遷移していくのかを示すために、標準化過程について簡単に紹介しよう。ここではまず各標準化状態について説明していく。

2016年7月4日追記
RFC 6410により、 RFCの標準化過程は従来の3ステージから、 Proposed Standard (PS) -> Internet Standard (STD)の2ステージへと変更となった。日本語による解説資料として、 IETFの構造とインターネット標準の標準化プロセスを参照されたい。

標準への提唱(PS)段階

標準化過程の最初に公開されるRFCは"標準への提唱(PS)"として公開される。名前は『提唱』であるが、この段階のRFCであっても、まったく考えられていないわけでは無い。既にRFCの前段階の文書であるインターネットドラフトによって十分に議論された仕様となっている。対象となるインターネットドラフトは IESG(Internet Engineering Steering Group)による承認を経てRFCとなる。

標準への提唱(PS)段階の仕様として要求されるのは、

安定していること
設計上の方針が確定していること
よく理解されていると考えられること
インターネットコミュニティにおいて十分に検討されていること
インターネットコミュニティにおいて価値があるとみなされ興味を持たれていること

である。仕様の実装や運用実験は必須ではない。

この段階の仕様に関する制約事項として

仕様として成熟しきっていないことを認識すること
実装をする際には、その主目的とし仕様に関する試験および実験とすること
将来仕様が変化する可能性が高いことを認識し、変更が容易でない環境における実装はしないこと

などがある。

標準への草稿(DS)段階

標準化過程の次の段階に進んだRFCは"標準への草稿(DS)"として公開される。 "標準への草稿(DS)"となった仕様として要求されるのは、

インターネットコミュニティでよく理解されていること
仕様の内容が非常に安定していること

である。この事実を証明するための条件として

(すべての要素が)少なくとも2つの独立し相互運用可能な実装で運用されていること
十分な運用実績が得られていること

ということ、つまり、その仕様が成熟し有用であると確信できるようになっている必要がある。そのため、前の段階である標準への提案(PS)段階からこの段階に進むためには、

複数の団体による仕様の実装や運用経験
6ヶ月以上の時間経過
IESGの承認

の条件を満たさなければならない。この段階の仕様が次の標準化過程の段階である標準(STD)段階に移行するためにはさらに大規模な運用実験による問題検出が必要な場合があるが、一般的にはこの段階の仕様が最終的だと見なされる。したがって、特別な場合を除いて変更されることはめったになく、安心して実運用実装に用いて良い。

標準(STD)段階

インターネット標準として認定されたRFCは"標準(STD)"として公開される。 "標準(STD)"は標準化過程の最終段階で、 RFC番号に加えてSTDシリーズ番号が割り当てられる。この段階に達することができるのは重要な実装と十分な運用実績が得られた仕様のみである。この段階のプロトコル仕様は技術的に成熟しており、インターネットコミュニティにとって重要なプロトコルまたはサービスを提供する。

"標準(STD)"段階の仕様は、

IPプロトコル層以上のインターネット全体に適用されるプロトコル
ネットワーク依存のプロトコル

の2種類に分類される。 "標準(STD)"段階に達した後にもまだ仕様が発展する可能性はあるが、この場合は標準化過程での昇格ではなく、新しいRFCでの置換という形をとることになる。

標準化過程の流れ

続いて『標準化過程の遷移』に着目する。標準化過程内では、

標準化過程への提出
標準化過程内での状態の遷移
標準化過程からの除外

の3つの動きがある。これらの動きについて簡単に説明していこう。

IESGと標準化過程

標準化過程におけるすべての決定はIESGによって行われる。そのための客観的基準は多数存在しているが、単純にその基準を満たせば良いわけではない。 IESGの経験に基づいた判断も重要視される要素となっている。

標準化過程への提出

仕様は標準になることを目的として標準化過程に『提出』される。提出される仕様は以下の3段階を経ることになる。

提出
検討および認可
公開

これらの段階での手続きを以下に示す。

標準化過程への提出

標準化過程へ提出される仕様は、通常インターネット・ドラフト(ID)として公開されている。新しいIDとして公開された場合は、一般の目にさらして検討してもらうために、少なくとも2週間公開していなければならないことになっている。仕様の標準化過程への提出は、

担当のIETF分科会によるエリア・ディレクターへの推奨
個人によるIESGへの推奨(関連分科会がない場合)

のいずれかの方法でおこなわれる。

仕様の検討と認可

仕様が提出されると、IESGは

適当な基準を満たしているか
期待される品質に達しているか

について検討する。場合によってはIESG以外の外部機関に技術的な検討を委託する場合もある。

検討が終了すると、IESGはIETFに対し、 IETF通知用メーリングリストへの電子メールなどで「最終告知(Last-Call)」の通知を送る。これはインターネットコミュニティ全体による最終的な検討をうながすもので、広くコメントを求めるものである。最終告知期間は、 IETF分科会によって提出された仕様の場合は2週間以上、それ以外の場合は4週間以上である。 IESGによってさらに時間が必要だとみなされた場合にはさらに長い期間が設定されることもある。

最終告知期間満了後、IESGは適宜その仕様に対する処置を決定し、その決定をIETF通知メーリングリストへの電子メールを通してIETFに通知する。

公開

仕様の標準化過程への受け入れが決まると、 RFCエディターにRFCとしての公開を指示する通知が送られ、この仕様はIDディレクトリから削除される。場合によっては標準化過程としてではなく実験(Experimental)なRFCとして採録される場合がある。その場合は必要に応じて提出からやり直さなければならない。