4. インターネット標準トラック
- インターネット標準トラック (THE INTERNET STANDARDS TRACK)
インターネット標準になることを意図した仕様は、「標準トラック」(standards track) として知られる一連の成熟度レベルを経て進化する。これらの成熟度レベル -- "Proposed Standard" (提案標準)、"Draft Standard" (ドラフト標準)、および "Standard" (標準) -- はセクション4.1で定義され議論される。仕様が標準トラックに沿って移動する方法は、セクション6で説明される。
仕様がインターネット標準として採用された後でも、経験と新しい要件の認識に基づいてさらなる進化がしばしば起こる。インターネット標準化の命名法と手順は、古いインターネット標準を新しいものに置き換えること、および「引退した」インターネット標準の状態を示すための記述的ラベルの割り当てを規定している。セクション4.2では、標準トラック上にあると見なされないこれらおよびその他の仕様をカバーするために、一連の成熟度レベルが定義されている。
4.1 標準トラックの成熟度レベル (Standards Track Maturity Levels)
インターネット仕様は、開発、テスト、および承認の段階を経る。インターネット標準プロセス内では、これらの段階は正式に「成熟度レベル」と呼ばれる。
このセクションでは、成熟度レベルと各レベルでの仕様の期待される特性について説明する。
4.1.1 Proposed Standard (提案標準)
標準トラックのエントリーレベルの成熟度は「Proposed Standard」である。IESGの特定の行動が、仕様を「Proposed Standard」レベルで標準トラックに移動させるために必要である。
Proposed Standard仕様は一般的に安定しており、既知の設計選択を解決し、十分に理解されていると考えられ、重要なコミュニティレビューを受けており、価値があると見なされるのに十分なコミュニティの関心を享受しているように見える。ただし、さらなる経験により、仕様が進む前に変更またはさらには撤回につながる可能性がある。
通常、仕様をProposed Standardとして指定するために、実装も運用経験も必要ない。ただし、そのような経験は非常に望ましく、通常はProposed Standard指定を支持する強い論拠を示すだろう。
IESGは、コアインターネットプロトコルに実質的に影響を与える仕様、またはインターネットに重大な運用上の影響を与える可能性のある動作を指定する仕様に対して、Proposed Standardステータスを付与する前に、実装および/または運用経験を要求する場合がある。
Proposed Standardは、それに課された要件に関して既知の技術的欠落を持つべきではない。ただし、IESGは、既知の技術的欠落があっても仕様が有用かつ必要(およびタイムリー)と考えられる場合、仕様がProposed Standard状態に進むことを許可するために、この要件を放棄することができる。
実装者はProposed Standardsを未成熟な仕様として扱うべきである。経験を得て、仕様を検証、テスト、および明確化するために実装することが望ましい。ただし、問題が見つかったり、より良い解決策が特定されたりした場合、Proposed Standardsの内容は変更される可能性があるため、このような標準の実装を中断に敏感な環境に展開することは推奨されない。
4.1.2 Draft Standard (ドラフト標準)
異なるコードベースから少なくとも2つの独立した相互運用可能な実装が開発され、十分な成功した運用経験が得られた仕様は、「Draft Standard」レベルに昇格することができる。このセクションの目的では、「相互運用可能」とは、それらが使用されるシステムまたはプロセスの機能的に同等または交換可能なコンポーネントであることを意味する。実装に特許またはその他の方法で制御された技術が必要な場合、個別の実装も、ライセンスプロセスの個別の行使から生じている必要がある。Draft Standardへの昇格は、仕様が成熟しており有用であるという強い信念を示す主要なステータスの進歩である。
少なくとも2つの独立した相互運用可能な実装の要件は、仕様のすべてのオプションと機能に適用される。1つ以上のオプションまたは機能が少なくとも2つの相互運用可能な実装で実証されていない場合、仕様は、それらのオプションまたは機能が削除された場合にのみDraft Standardレベルに進むことができる。
ワーキンググループの議長は、Draft StandardまたはInternet Standard ステータスの仕様を適格にする特定の実装を、これらの実装の相互運用のテストに関する文書とともに文書化する責任がある。文書には、個々のオプションと機能のそれぞれのサポートに関する情報を含める必要がある。この文書は、プロトコルアクション要求とともにエリアディレクターに提出する必要がある。(セクション6を参照)
Draft Standardは、その意味論においても、実装を開発するための基礎としても、十分に理解され、非常に安定していることが知られている必要がある。Draft Standardは、Draft Standard仕様に基づく実装が本番環境での大規模な使用にさらされると予期しない動作を示す可能性があるため、さらなるまたはより広範なフィールド経験を必要とする場合がある。
Draft Standardは通常、最終仕様と見なされ、変更は遭遇した特定の問題を解決するためにのみ行われる可能性が高い。ほとんどの状況では、ベンダーがDraft Standardsの実装を中断に敏感な環境に展開することは合理的である。
4.1.3 Internet Standard (インターネット標準)
重要な実装と成功した運用経験が得られた仕様は、Internet Standardレベルに昇格することができる。Internet Standard(単にStandardと呼ばれることもある)は、高度な技術的成熟度と、指定されたプロトコルまたはサービスがインターネットコミュニティに重要な利益をもたらすという一般的に保持されている信念によって特徴付けられる。
Standardのステータスに達する仕様には、RFCナンバーを保持したままSTDシリーズの番号が割り当てられる。
4.2 非標準トラックの成熟度レベル (Non-Standards Track Maturity Levels)
すべての仕様が標準トラック上にあるわけではない。仕様はインターネット標準になることを意図していない場合があり、または最終的な標準化を意図しているが、まだ標準トラックに入る準備ができていない場合がある。仕様は、より最近のインターネット標準に置き換えられたか、その他の方法で使用されなくなったか、支持されなくなった可能性がある。
標準トラック上にない仕様には、3つの「オフトラック」成熟度レベルのいずれかが付けられる: "Experimental" (実験的)、"Informational" (情報提供)、または "Historic" (歴史的)。これらのラベルを持つ文書は、いかなる意味でもインターネット標準ではない。
4.2.1 Experimental (実験的)
「Experimental」の指定は、通常、研究または開発の取り組みの一部である仕様を示す。このような仕様は、インターネット技術コミュニティの一般情報として、また作業の記録として、編集上の考慮事項と、標準化プロセスとの適切な調整が行われたことの検証のみを条件として公開される(以下を参照)。実験的仕様は、組織化されたインターネット研究の取り組み(例えば、IRTFの研究グループ)、IETFワーキンググループの成果物である場合もあれば、個人の貢献である場合もある。
4.2.2 Informational (情報提供)
「Informational」仕様は、インターネットコミュニティの一般情報のために公開され、インターネットコミュニティのコンセンサスまたは推奨を表すものではない。Informationalの指定は、編集上の考慮事項と、標準化プロセスとの適切な調整が行われたことの検証のみを条件として、多くのソースからの非常に広範囲の責任ある情報文書のタイムリーな公開を提供することを意図している(セクション4.2.3を参照)。
インターネットコミュニティの外部で準備され、セクション10のいずれかの規定によってインターネット標準プロセスに組み込まれていない仕様は、所有者の許可とRFCエディターの同意を得て、Informational RFCsとして公開される場合がある。
4.2.3 ExperimentalおよびInformational RFCsの手順
IETFワーキンググループのアクションの結果でない限り、ExperimentalまたはInformationalステータスで公開されることを意図した文書は、RFCエディターに直接提出する必要がある。RFCエディターは、まだそのように公開されていないすべてのそのような文書をInternet-Draftsとして公開する。これらのInternet-Draftsを区別するために、I-Dディレクトリでラベル付けまたはグループ化され、簡単に認識できるようにする。RFCエディターは、さらに進める前に、この公開後2週間コメントを待つ。RFCエディターは、ExperimentalまたはInformationalステータスでの公開のための文書の編集上の適合性に関して自身の判断を行使することが期待され、RFCエディターの専門家の意見において、インターネット活動に関連しない、またはRFCsの技術的および/または編集上の基準を下回る文書の公開を拒否する場合がある。
非標準トラックのExperimentalおよびInformationalの指定がインターネット標準プロセスを回避するために悪用されないようにするため、IESGとRFCエディターは、RFCエディターの意見において、IETFコミュニティ内で行われている、または行われることが予想される作業に関連している可能性があるExperimentalまたはInformationalの公開のために提出された文書をIESGに照会することに同意した。IESGは、そのような照会された文書を合理的な期間内に検討し、元の提出のまま公開するか、インターネット標準プロセスへの貢献としてIETFに照会することを推奨する。
(a) IESGが文書をIETF内に持ち込み、IETFのコンテキストで進めることを推奨したが、著者がそれを拒否した場合、または(b) IESGが文書が確立されたIETFの取り組みと矛盾する、または実際に有害であるものを提案していると判断した場合、文書は依然としてExperimentalまたはInformational RFCとして公開される場合がある。ただし、これらの場合、IESGは、その公開の状況を読者に明確にするために、"Status of this Memo"セクション内または直後に適切な「免責事項」テキストをRFCに挿入する場合がある。
IETFワーキンググループによってExperimentalおよびInformational RFCsとして提案された文書は、IESGレビューを経る。レビューは、セクション6.1.1に記載されているプロセスを使用して開始される。
4.2.4 Historic (歴史的)
より最近の仕様に置き換えられた、またはその他の理由で廃止されたと見なされる仕様は、「Historic」レベルに割り当てられる。(純粋主義者は、その単語は「Historical」であるべきだと示唆している; しかし、この時点で、「Historic」の使用は歴史的である。)
注: 標準トラック仕様は、通常、より低い成熟度レベルにある他の標準トラック仕様、または他の標準化団体からの参照仕様以外の非標準トラック仕様に依存してはならない。(セクション7を参照。)