6. インターネット標準プロセス
- インターネット標準プロセス (THE INTERNET STANDARDS PROCESS)
インターネット標準プロセスのメカニズムには、仕様を標準トラックに昇格させること、または標準トラック仕様をある成熟度レベルから別のレベルに移動させることに関するIESGの決定が含まれる。仕様を標準トラック上、沿って、またはそこから移動させる決定においてIESGを導くために、多くの合理的に客観的な基準(以下およびセクション4で説明)が利用可能であるが、いかなる仕様についても、標準トラックへの昇格または標準トラックに沿った進行のアルゴリズム的保証はない。標準トラックでの昇格または前進のために提案された仕様の技術的品質に関するIESGの経験豊富な集団的判断は、意思決定プロセスの不可欠な要素である。
6.1 標準化アクション (Standards Actions)
「標準化アクション」 -- 特定の仕様を標準トラックに入れる、その中で前進させる、またはそこから削除する -- はIESGによって承認されなければならない。
6.1.1 アクションの開始 (Initiation of Action)
インターネット標準トラックに入る、またはその中で前進することを意図した仕様は、RFCとして公開されてから変更されていない限り、最初にInternet-Draft(セクション2.2を参照)として投稿する必要がある。アクションの推奨が開始された後、有用なコミュニティレビューを許可する、少なくとも2週間の期間、Internet-Draftとして残る必要がある。
標準化アクションは、仕様を担当するIETFワーキンググループからそのエリアディレクターへの推奨によって開始され、IETFセクレタリアトにコピーされる。または、ワーキンググループに関連しない仕様の場合は、個人からIESGへの推奨によって開始される。
6.1.2 IESGレビューと承認 (IESG Review and Approval)
IESGは、セクション6.1.1に従って提出された仕様が推奨されるアクションの該当する基準を満たしているかどうかを判断し(セクション4.1および4.2を参照)、さらに、仕様の技術的品質と明確性が、仕様が推奨される成熟度レベルで期待されるものと一致しているかどうかを判断する。
これらの判断を行うために必要なすべての情報を入手するために、特に仕様がインターネットまたはインターネットプロトコルスイートへの潜在的な影響の観点から、IESGによって非常に重要であると見なされる場合、IESGは、その裁量により、仕様の独立した技術的レビューを委託する場合がある。
IESGは、一般的なインターネットコミュニティによる最終レビューを許可するために、文書のIESG検討が保留されていることをIETFに通知する。この「Last-Call」(最終呼びかけ)通知は、IETF Announceメーリングリストへの電子メールで行われる。Last-Callに対するコメントは誰からでも受け付けられ、Last-Callアナウンスメントで指示されたとおりに送信する必要がある。
Last-Call期間は、提案された標準化アクションがIETFワーキンググループによって開始されなかった場合を除き、2週間以上とする必要がある。その場合、Last-Call期間は4週間以上とする必要がある。IESGがコミュニティの利益がより多くのコメント時間を許可することによって提供されると考える場合、より長いLast-Call期間を決定するか、現在のLast-Call期間を明示的に延長することができる。
IESGは、仕様が提出されたときに推奨されたアクションに拘束されない。たとえば、IESGは、要求されたものとは異なるカテゴリでの公開のために仕様を検討することを決定する場合がある。IESGがLast-Callが発行される前にこれを決定した場合、Last-CallはIESGの見解を反映すべきである。IESGは、Last-Callへの応答に基づいて公開カテゴリを変更することも決定できる。この決定により、元のLast-Callが対象としていたものよりも「高い」レベルで仕様が公開される場合、IESG推奨を示す新しいLast-Callを発行する必要がある。さらに、IESGは、IETFワーキンググループから発生していない仕様のLast-Callに対する重大な論争に応じて、新しいワーキンググループの形成を推奨することを決定する場合がある。
Last-Call期間の満了後、タイムリーな方法で、IESGは標準化アクションを承認するかどうかの最終決定を行い、IETF Announceメーリングリストへの電子メールでIETFにその決定を通知する。
6.1.3 公開 (Publication)
標準化アクションが承認された場合、通知がRFCエディターに送信され、IETFにコピーされ、仕様をRFCとして公開するよう指示される。仕様はその時点でInternet-Draftsディレクトリから削除される。
完了および保留中の標準化アクションの公式な要約は、Internet SocietyのニュースレターのすべてのIssueに掲載される。これは、インターネット標準化アクションの「公式記録の公開」を構成する。
RFCエディターは、すべてのインターネットプロトコルおよびサービス仕様のステータスを要約した「Internet Official Protocol Standards」RFC [1]を定期的に公開する。
6.2 標準トラックでの前進 (Advancing in the Standards Track)
セクション6.1で説明されている手順は、標準トラックに沿った仕様の前進に伴う各アクションに対して実行される。
仕様は、Proposed Standardレベルに少なくとも6ヶ月間留まる必要がある。
仕様は、Draft Standardレベルに少なくとも4ヶ月間、または少なくとも1回のIETF会議が開催されるまで、どちらか遅い方まで留まる必要がある。
これらの最小期間は、適時性に重大な影響を与えることなく、コミュニティレビューの適切な機会を確保することを意図している。これらの間隔は、対応するRFCの公開日から、またはアクションがRFC公開につながらない場合は、IESGによるアクションの承認の発表日から測定される。
仕様は、標準トラックを進むにつれて改訂される可能性がある(実際、改訂される可能性が高い)。各段階で、IESGは仕様の改訂の範囲と重要性を決定し、必要かつ適切な場合、推奨されるアクションを修正する。軽微な改訂が予想されるが、重大な改訂により、仕様が進行する前に現在の成熟度レベルでより多くの経験を蓄積する必要がある場合がある。最後に、仕様が非常に大幅に変更された場合、IESGは、改訂を新しい文書として扱い、標準トラックの最初から再入することを推奨する場合がある。
ステータスの変更は、最後の公開以降、仕様にまったく変更がなかったというまれなケースを除き、仕様のRFCとしての再公開につながる。一般的に、望ましい変更は、標準トラックの次のレベルでの組み込みのために「バッチ処理」される。ただし、仕様への次の標準化アクションへの変更の延期が常に可能または望ましいわけではない。たとえば、重要な誤植、または仕様の全体的な機能の変更を表さない技術的エラーは、すぐに修正する必要がある場合がある。このような場合、IESGまたはRFCエディターは、修正を含むRFC(新しい番号で)を再公開するよう求められる場合があり、これによりレベルでの最小時間時計がリセットされることはない。
標準トラック仕様がInternet Standardレベルに達していないが、24ヶ月間同じ成熟度レベルに留まっている場合、およびステータスが変更されるまで12ヶ月ごとに、IESGはその仕様を担当する標準化作業の実行可能性と技術の有用性をレビューする。各レビュー後、IESGは開発作業の終了または継続を承認し、同時に、IESGは仕様を同じ成熟度レベルに維持するか、Historicステータスに移動するかを決定する。この決定は、インターネットコミュニティにコメントの機会を提供するために、IETF Announceメーリングリストへの電子メールでIETFに伝えられる。この規定は、正当かつ活発なワーキンググループの取り組みを脅かすことを意図したものではなく、むしろ瀕死の取り組みを終了するための管理メカニズムを提供することを意図している。
6.3 標準の改訂 (Revising a Standard)
確立されたインターネット標準の新しいバージョンは、まったく新しい仕様であるかのように完全なインターネット標準化プロセスを経る必要がある。新しいバージョンがStandardレベルに達すると、通常は以前のバージョンを置き換え、以前のバージョンはHistoricステータスに移動される。ただし、場合によっては、インストールされたベースの要件を尊重するために、両方のバージョンがインターネット標準として残る場合がある。この状況では、以前のバージョンと新しいバージョンの関係は、新しいバージョンのテキストまたは別の適切な文書(たとえば、Applicability Statement; セクション3.2を参照)で明示的に述べる必要がある。
6.4 標準の引退 (Retiring a Standard)
技術が変化し成熟するにつれて、新しいStandard仕様が技術的に明らかに優れているため、同じ機能の1つ以上の既存の標準トラック仕様を引退させる必要がある可能性がある。この場合、または何らかの理由で既存の標準トラック仕様を引退させるべきであると感じられる場合、IESGは古い仕様のステータスのHistoricへの変更を承認する。この推奨は、他の標準化アクションに使用されるのと同じLast-Callおよび通知手順で発行される。既存の標準を引退させる要求は、ワーキンググループ、エリアディレクター、またはその他の関係者から発生する可能性がある。
6.5 紛争解決と上訴 (Conflict Resolution and Appeals)
IETFプロセスのさまざまな段階で論争が起こる可能性がある。可能な限り、プロセスは妥協が行われ、真のコンセンサスが達成されるように設計されているが、最も合理的で知識のある人々でさえ合意できない時がある。開放性と公平性の目標を達成するために、そのような紛争は、公開レビューと議論のプロセスによって解決されなければならない。このセクションでは、IETFワーキンググループおよびその他のインターネット標準プロセス参加者が通常コンセンサスに達する通常のプロセスでは解決できないインターネット標準の問題を処理するために従う必要がある手順を指定する。
6.5.1 ワーキンググループの紛争 (Working Group Disputes)
個人(関連するワーキンググループの参加者であるかどうかにかかわらず)は、(a) 自分の見解がワーキンググループによって適切に考慮されていない、または(b) ワーキンググループが、ワーキンググループの製品の品質および/または完全性を大幅に危険にさらす誤った技術的選択を行ったという信念に基づいて、ワーキンググループの推奨に同意しない場合がある。最初の問題はワーキンググループプロセスの困難である; 後者は技術的エラーの主張である。これら2種類の不同意はかなり異なるが、両方とも同じレビュープロセスによって処理される。
ワーキンググループの推奨に同意しない人は、常に最初にワーキンググループの議長と問題を議論する必要があり、議長はワーキンググループの他のメンバー(またはワーキンググループ全体)を議論に巻き込む場合がある。
この方法で不同意が解決できない場合、関係する当事者のいずれかが、ワーキンググループがチャーターされているエリアのエリアディレクターの注意を引くことができる。エリアディレクターは紛争を解決しようとする。
エリアディレクターによって不同意が解決できない場合、関係する当事者のいずれかがIESG全体に上訴することができる。その後、IESGは状況をレビューし、独自の選択の方法でそれを解決しようとする。
IESGレベルで当事者の満足に不同意が解決されない場合、関係する当事者のいずれかがIABに決定を上訴することができる。その後、IABは状況をレビューし、独自の選択の方法でそれを解決しようとする。
IABの決定は、インターネット標準化手順が従われたかどうかの問題、およびすべての技術的メリットの問題に関して最終的である。
6.5.2 プロセスの失敗 (Process Failures)
本文書は、インターネット標準プロセスの開放性と公平性、および作成される標準の技術的実行可能性を確保するために従う必要がある手順を定める。IESGは、この目的のためのIETFの主要なエージェントであり、必要な手順が従われたこと、および標準化アクションの必要な前提条件が満たされたことを保証する責任を負うのはIESGである。
個人がこのプロセスでIESGによって取られたアクションに同意しない場合、その人は最初にIESG議長と問題を議論すべきである。IESG議長が苦情申立人を満足させることができない場合、IESG全体が、苦情申立人からの入力とともに取られたアクションを再検討し、さらなるアクションが必要かどうかを判断する必要がある。IESGは、苦情のレビューに関するレポートをIETFに発行する。
苦情申立人がIESGレビューの結果に満足していない場合、IABに上訴を提出することができる。その後、IABは状況をレビューし、独自の選択の方法でそれを解決しようとし、そのレビューの結果をIETFに報告する。
状況が正当化する場合、IABはIESGの決定を無効にするよう指示することができ、状況はIESGの決定が取られる前の状態になる。IABはまた、IESGにアクションを推奨したり、適切と判断する他の推奨を行ったりすることができる。ただし、IABは、IESGのみが行う権限を持つ決定を発行することによって、IESGの役割を先取りすることはできない。
IABの決定は、インターネット標準化手順が従われたかどうかの問題に関して最終的である。
6.5.3 適用手順の問題 (Questions of Applicable Procedure)
さらなる救済は、手順自体(すなわち、この文書に記載されている手順)が公正かつ開放的なインターネット標準プロセスにおけるすべての当事者の権利の保護に不十分または不十分であると主張される場合にのみ利用可能である。この基準に基づく主張は、Internet Society理事会に対して行うことができる。Internet Societyの会長は、そのような上訴を2週間以内に認め、認めの時点で、理事会による上訴のレビューの予想期間を請願者に通知する。理事会は、独自の選択の方法で状況をレビューし、そのレビューの結果をIETFに報告する。
理事会によるレビュー完了時の決定は、紛争のすべての側面に関して最終的である。
6.5.4 上訴手順 (Appeals Procedure)
すべての上訴には、紛争の事実の詳細かつ具体的な説明を含める必要がある。
すべての上訴は、異議を申し立てるアクションまたは決定の公表から2ヶ月以内に開始する必要がある。
上訴プロセスのすべての段階で、決定を行う責任を負う個人または団体は、決定を下すプロセスで従う特定の手順を定義する裁量権を持つ。
すべての場合において、紛争の処分に関する決定、およびその決定の関係当事者への通知は、合理的な期間内に完了する必要がある。
[注: これらの手順は、意図的かつ明示的に、すべてのケースで「合理的」と見なされる固定の最大期間を確立しない。インターネット標準プロセスは、コンセンサスとそれを達成するための努力を重視し、より真正な技術的合意に達することができる範囲を優先して、決定論的に迅速な手順の実行を意図的に放棄する。]