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

JPNIC RFC-JP
 トップ−Introduction to RFC(s)

Introduction to RFC(s)



[ページ目次]
標準化の各段階
- 標準への提唱(PS)段階
- 標準への草稿(DS)段階
- 標準(STD)段階

標準化過程の流れ
- IESGと標準化過程
- 標準化過程への提出
- 標準化過程内での状態の遷移
- 標準化過程からの除外
- より詳しく?

[章目次]
- はじめに
- RFCってなに?
- RFCの分類
- インターネット標準化過程

以下は順次公開予定
- RFC-index
- RFCの読み方
- RFCの探し方
- RFCができるまで
- I-DとRFC
- RFCの歴史
- 読み物RFC紹介
- 用語集RFC一覧
- Joke RFCって?
- RFCいろいろ
- RFC関連FAQ

著者について
[はじめに]

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

『標準化過程(Standards Track)』とはインターネット標準を形成するプロセスである。 RFCの分類で説明したように 標準化過程の発展段階は以下のようなRFCの分類の遷移によって表現される。
  • 標準への提唱(PS - Proposed Standard)
  • 標準への草稿(DS - Draft Standard)
  • 標準(STD - Standard)
    • これらのRFCがどのような基準で遷移していくのかを示すために、 標準化過程について簡単に紹介しよう。
    ここではまず各標準化状態について説明していく。

    ■標準への提唱(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と して採録される場合がある。その場合は 必要に応じて提出からやり直さなければならない。

    ■標準化過程内での状態の遷移

    仕様がRFC標準化過程で発展する際にも上記の流れに従った処理が適用される。 段階が遷移すると、ほとんどの場合仕様は再度RFCとして公開されることになる。
    各段階に仕様を据え置く期間は以下のように設定されている。
    • "標準への提唱(PS)"段階には6ヶ月以上
    • "標準への草稿(DS)"段階には、 4ヶ月以上またはIETF会合が少なくとも1回開催されるまでのどちらか遅い方

    標準化過程にある仕様が非常に大きく変更された場合には、 IESGは別の文書として再度はじめから標準化過程を経るように勧告する。
    また、インターネット標準(STD)段階に達する以前に 仕様が同一段階に24ヶ月以上ある場合などは、IESGによって
    • 標準化に向けての継続的な努力がおこなわれているか
    • 技術の有用性の再検討
    に関して検討される。 検討の結果によって
    • 据え置き
    • 歴史(Historic)への移行
    が決定される。 この決定はIETF通知メーリングリストで公示される。

    ■標準化過程からの除外

    標準化過程のRFCは場合によって、 標準化過程からはずれて歴史(Historic)に移行する場合がある。
    これは主に
    • 新しいプロトコルの出現などで該当プロトコルが利用されなくなった場合
    で、既にいくつかのRFCが歴史RFCに改訂されている。

    ■より詳しく?

    標準化過程に関してより詳細な情報が必要な場合は RFC2026(BCP9)『The Internet Standards Process -- Revision 3』 を読んでいただきたい。


    Copyright (c) UO Youjiro All Rights Reserved.
    Copyright (c) Japan Network Information Center. All Rights Reserved. | Contact