まとめ
- BCP ステータスは、IETF の定義された出版成果です。これは、大まかな合意、公開レビュー、および IESG の承認を反映しています。これは、著者の意見以上のものですが、インターネット標準とは異なり、決して世界的な国民投票ではありません。
- 「最新」という言葉は、実装と展開にさらされ続けなければならない証拠的主張です。BCP は更新可能であり、複数の RFC で構成され、トポロジーによって制限されたり、運用上および制度的な変化によって覆されたりする可能性があります。現在のインデックスと展開された記録は、孤立した最初のページのラベルよりも重要です。
- 外部の採用者は、借用する正確な命題、影響を受ける集団、現実世界への適合性の証拠、代替案、バージョン管理、および自らの権限を特定する必要があります。IETF の大まかな合意を、すべての実装者またはすべてのインターネットユーザーが同意したという主張に変換してはなりません。
BCP は、標準と呼ばずに承認されたプラクティスを命名するために作成されました
ベスト・カレント・プラクティスカテゴリは、分類の問題を解決することから始まりました。IETF は、プロトコル成熟度ラダーに属さない有用な技術情報を承認する方法を必要としていました。文書によっては運用ガイダンスに関するものもあれば、原則を述べたもの、管理機能を説明したもの、IETF 自身の働き方を記録したものもありました。これらすべてをインターネット標準と呼ぶと、内容と効果の両方を誤って説明することになります。
RFC 1818は、1995年8月に発行され、BCP サブシリーズを作成しました。それによると、レビューパスは標準化過程の提案と類似し、IESG レビューと IETF ラストコールを含むことになります。承認後、文書は IETF の技術的承認を帯びますが、公式のインターネット標準にはならず、なり得ません。このメモは現在は Historic ですが、その創設時の区別は今でも教訓的です。
RFC 2026は、翌年に耐久性のある枠組みを提供しました。BCP は、プラクティスとコミュニティの審議結果を標準化する方法として説明されています。すなわち、原則の声明、好ましい運用方法、IETF 機能です。これは、異なる目標を持つ組織が運営するネットワークでも、共通のガイドラインが必要であることを認識しています。これらのガイドラインは、同等の合意形成を必要とする場合でも、プロトコル仕様とは異なります。
したがって、このカテゴリは同時に2つのメッセージを伝えています。承認が重要です。文書は単なる回覧ノートやベンダーの提案ではありません。IETF のレビューパスにさらされ、コミュニティの最良の現在の思考として承認されています。分類も重要です。文書が重要だから、規範的な用語を使っているから、または展開に影響を与えるからといって、インターネット標準ではありません。
誤解は、一方の半分が落とされたときに始まります。BCP をカジュアルなアドバイスとして扱うことは、レビューと集団的な技術的判断を無視します。それを普遍的な命令として扱うことは、カテゴリ、範囲、採用、および合意に達した主体の限界を無視します。忠実な読み方は、両方の命題を一緒に保持しなければなりません。
ラベルは、制度的結論を特定するものであり、有権者ではありません
現代の BCP 定型文は、IETF ストリームの BCP が IETF コミュニティのコンセンサスを表し、公開レビューを受け、インターネットエンジニアリングステアリンググループによって承認されたことを述べています。これらの記述は、機関、レビュー、承認団体を特定します。すべての実装者、事業者、政府、ベンダー、ユーザーが同意したとは述べていません。
この違いは、意味論的な謙虚さではありません。それが、正当に推論できるかを決定します。IETF 参加者は、オープンな技術コミュニティで個人として行動します。参加は、人口、管轄区域、市場シェア、ネットワークサイズ、またはプロトコルに影響を受ける人の数によって配分されません。組織は知識のある参加者を派遣し、相当な作業に資金を提供しますが、法人投票は行いません。エンドユーザーは、インターネットへの依存度に見合った数で現れることはめったにありません。
BCP の結論は、そのモデル内で権威を持つことができます。オープンなアーカイブ、理由のある異議処理、技術的能力、経験豊富なレビューは、代表的な選挙なしに信頼できる推奨事項を生み出すことができます。多くの技術的質問は、国の人口や製品ユーザーを数えることでうまく決定されることはありません。問題は、IETF が正当かどうかではなく、どのような種類の正当性を持っているかです。
その正当性は、命題が相互運用可能な技術的行動、プロトコル運用、その責任範囲内のレジストリメカニズム、または独自の手続きに関する場合に最も強力です。推奨が当事者間でコストを割り当てる場合、特定の市場構造を前提とする場合、または IETF の権限外の法的結果を正当化するために使用される場合、より条件的になります。同じ文書が、特定の外部使用に対して技術的に説得力がありながら、政治的に不完全であることがあり得ます。
したがって、「IETF コンセンサス」というフレーズは文字通りに読むべきです。誰がどのような審議を通じて結論に達したかを述べています。インターネットの同意の略語ではありません。メーリングリストの公開可用性は部外者に参加機会を与えますが、影響を受けるすべてのクラスが通知、リソース、専門知識、言語アクセス、または最終的な使用を予期する理由を持っていたことを証明するものではありません。
この限定的な解釈は、ラベルを強化します。何十億もの人々について不可能な主張ではなく、実際の機関について防御可能な主張を行います。
ラフコンセンサスは、拒否権と人数カウントの両方を避けるように設計されています
BCP ステータスは、全会一致ではなくラフコンセンサスに基づいています。RFC 7282は、その方法を、単純なサポート総数ではなく、問題への注意として説明しています。重要な技術的異議は理解され、対処されなければなりません。グループが懸念が回答されたか、作業を停止することを正当化しないと結論付けた場合、対応する必要はありません。
これにより、1人の持続的な反対者に拒否権を与えることなく進捗が可能になります。また、多数派が単に多いという理由だけで勝利するのを防ぎます。少数の参加者が、望ましい設計を無効にする欠陥を特定できます。多数派がその欠陥に回答することなく提案を支持できます。議長の仕事は、未解決の問題と十分なサポートに関する判断であり、全会一致の同意の認定ではありません。
この方法は、エンジニアリングに特に適しています。相互運用性の失敗は、ほとんどの人がその機能を支持しているからといって無害になるわけではありません。再現可能な攻撃は、挙手で消えません。逆に、別の構文に対する好みが、健全な設計を無期限にブロックすることはありません。議論、実装、証拠は、決定的な問題と好みを区別できます。
しかし、ラフコンセンサスは、その意味を破壊することなく普遍的な同意に変換することはできません。それは明示的に反対を許可します。影響を受けるすべての人を列挙しません。欠席している実装者を支持者として数えません。沈黙を権利の積極的な放棄に変えません。IETF 外の当事者が、文書の名の下に後で課されるコストを受け入れたことを証明しません。
アクティブなグループ内でも、コンセンサスはすべての文に対する個人的な同意ではありません。参加者は、異議が適切に回答されたため、あまり魅力的でない結果を受け入れることがあります。制度的決定は、投票よりも強いが、共有選好の主張よりも狭いです。
外部の団体は、その精度を維持すべきです。BCP がレビューされた IETF ラフコンセンサスを反映していると言うことができます。「グローバルインターネットが同意した」または「業界が同意した」と言うべきではありません。その区別は、コンセンサスキャプチャに対する最初の防御であり、限定的な技術的决定が他の場所で普遍的な義務として提示されるのを防ぎます。
公開参加は機会であり、代表性の証明ではありません
IETF の公開性は、実質的なセーフガードです。RFC 3935は、関心のあるすべての人が参加し、何が決定されているかを知り、意見を述べることができると述べています。文書、メーリングリスト、出席情報、議事録は公開されています。この公開性は、BCP に、閉じたベンダー調整や非公開の管理慣行に欠ける可能性のある正当性を与えます。
しかし、開かれたドアは代表的なサンプルを作成しません。参加には、時間、技術的リテラシー、信頼性の高い接続性、英語優位の技術的議論への慣れ、決定的な選択が固まる前の作業の認識が必要です。雇用主は、長期間の関与を維持できる多くの人々を後援します。緊急のインシデントに直面している事業者は、レビュー全体をフォローすることなく展開知識を提供するかもしれません。間接的に影響を受けるユーザーは、エンジニアリング用語が後でアクセス、プライバシー、コストを形成することに気づかないかもしれません。
これらの事実のどれも出力を無効にしません。それらは参加から行うことができる主張を制限します。公開会議は、小規模ネットワークを過小評価しながら、優れたプロトコル判断を生み出すことができます。ワーキンググループは、実質的な通知を欠いた地域からの異議を聞かないことがあります。ラストコールは、文書を公開しますが、すべての沈黙した人を同意する参加者に変えるわけではありません。
関連する対応は、架空の世界的な投票ではありません。それは、命題固有のアウトリーチと証拠です。BCP がアクセスネットワークの運用に実質的に影響を与える場合、レビューアはさまざまなアーキテクチャからの事業者を求めるべきです。実装コストをエンドポイントにシフトする場合、実装者と影響を受けるユーザーの意見を聞くべきです。番号レジストリに関する場合、それらのリソースを管理および消費する機関が記録に情報を提供する必要があります。
外部採用には、別の参加ステップが必要です。規制当局、RIR コミュニティ、調達機関、業界団体には、独自の影響を受ける集団と手続きがあります。IETF の公開性を代替として扱うのではなく、それらの取り決めの下で協議する必要があります。IETF の外部での質問は、誰かが理論的に IETF リストに参加できたかどうかではありません。それは、採用機関が課そうとする結果について意味のある通知を行ったかどうかです。
参加は結論をサポートできます。欠席から同意を製造することはできません。
「ベスト」「カレント」「プラクティス」はそれぞれ制限を持っています
カテゴリの3つの単語は、しばしば最上級の命令として聞かれます。注意深く読むと、それぞれがより規律正しいです。「ベスト」は、IETF コミュニティが利用できる証拠と価値観に基づいて行われた比較判断です。これは、完璧、無料、またはあらゆる環境で独自に有効であることを意味しません。
「カレント」は時間を示します。運用条件、脅威、ルーティングアーキテクチャ、実装サポート、制度的取り決めは変化する可能性があります。公開時に最新の推奨事項は、健全なまま、資格を必要とし、または置き換えられる可能性があります。アーカイブされた RFC は不変のままですが、ステータス、正誤表、更新関係はその周りで発展します。
「プラクティス」は、抽象的な真実ではなく行動を指します。BCP は、事業者にリスクの軽減方法を指示したり、レジストリの管理方法を文書化したり、規範的な言葉の使用方法を述べたり、IETF がレビューを実施する方法を定義したりします。プラクティスが機能するかどうかは、論理的な一貫性だけでなく、制度やネットワークでの行動にも部分的に依存します。
一緒に、これらの言葉は継続的な証拠の負担を示唆しています。IETF は、これがスコープされた問題を処理するための好ましい現在の方法であるというレビューされた判断に達しました。ユーザーはその判断を真剣に受け止めるべきです。また、スコープが一致するか、後の文書がそれを修正するか、展開された経験がそれをサポートするか、代替案が実質的に異なる環境にうまくサービスするかを尋ねるべきです。
ラベルは「想像できる最良の」を意味しません。BCP は、現在の制約の下で最も展開可能な応答であるかもしれません。精度と運用上の安全性をトレードオフしたり、既存の機器でサポートされる方法を選択したりするかもしれません。それはしばしば正しいエンジニアリングの答えです。制約が隠され、妥協が時代を超越した必然性として販売されるときにのみ誤解を招きます。
また、カレントは人気を意味しません。インセンティブがずれているため、展開が低くても技術的に好まれるプラクティスがあります。広く展開されていても、インストールベースの依存関係が欠陥を隠すため、改訂が必要な場合があります。展開は重要な証拠ですが、普及とメリットは同一ではありません。
BCP ステータスは、質問を促すべきであり、調査を終わらせるものではありません。何のためのベストか、どの証拠に基づいて最新か、誰によってどの条件で実践されているか？
BCP サブシリーズは、凍結されたページではなく、維持された命題です
RFC 番号はアーカイブ文書を識別します。BCP 番号は、複数の RFC によって表され、更新や廃止によって変更される可能性のあるサブシリーズの命題を識別します。RFC 7841は、サブシリーズ番号が複数の RFC に現れる可能性があり、文書関係が Updates および Obsoletes 参照を通じて記録されることを説明しています。
BCP 14 は身近な例です。RFC 2119 は規範的な要求語を定義します。RFC 8174 は後に、特別な意味が指定された定型文がそれらを呼び出す場合の大文字使用に適用されることを明確にします。一方を他方なしで読むと、不完全な解釈が生じる可能性があります。安定した BCP 番号は維持されたルールを接続し、各 RFC はその公開記録を保持します。
BCP 9 はさらに明らかに複合的です。RFC 2026 はコア標準フレームワークを定義し、後の BCP 文書がその一部を更新します。たとえば、RFC 8789 は、IETF ストリーム RFC の公開にラフコンセンサスを要求します。現在のプラクティスは、1996年のテキストを何も変わっていないかのように扱うことでは回復できません。
この構造はガバナンスの利点です。アーカイブは引用と歴史的説明責任のために安定したままです。サブシリーズは、コミュニティが学習するにつれて進化できます。しかし、それは採用者に義務を課します。古い RFC のみを名前付ける契約やポリシーは、廃止された断片を凍結する可能性があります。BCP 番号を動的に組み込むルールは、採用者自身のレビューなしに外部の義務を変更する可能性があります。
責任ある使用は、現在のインデックスから始まります。どの RFC が BCP を構成するか？どれがどれを更新するか？検証された正誤表はあるか？文書は Historic ステータスに移動したか？引用された要件はまだ有効か、それとも単に履歴の一部か？RFC に印刷されたステータス段落は、文書が公開後に自身を書き換えることができないため、十分ではありません。
採用者は次にバージョン方法を選択しなければなりません。静的組み込みは確実性を提供しますが、レビュートリガーが必要です。動的組み込みは技術的な最新性を保持しますが、重要な変更に対する通知と制御が必要です。どちらの規律もなしに「現在の BCP」への参照は、曖昧さを実装者と執行者に移します。
「カレント」という言葉は、関係、証拠、再検討を通じて維持されます。最初のページのタイポグラフィによって保存されるわけではありません。
BCP にはいくつかの種類の権威が含まれています
BCP カテゴリは、すべて同じ外部の力で解釈されるべきではない文書に及びます。いくつかは IETF 自身を統治します。BCP 9 は標準フレームワークに関するものです。BCP 25 はワーキンググループの運営に関するものです。その主な権威は、その行動を規制する機関による採用に由来します。
いくつかは、起草と調整の慣行を定義します。BCP 14 は規範的な語彙を提供します。BCP 26 (現在は RFC 8126) は、IANA の考慮事項とプロトコルパラメータ登録ポリシーに関するガイダンスを提供します。これらの文書は、IETF プロトコルに関連する仕様とレジストリ間の一貫性をサポートします。
いくつかはネットワーク運用を推奨します。BCP 38 は、偽造された送信元アドレスに対する入力フィルタリングを扱います。BCP 84 はマルチホームネットワークのフィルタリングを扱います。その影響は、実装能力、トポロジ、事業者のインセンティブ、測定可能な展開に大きく依存します。
いくつかはミッションまたはアーキテクチャの原則を述べています。BCP 95 は IETF のミッションと基本原則を記録しています。そのような文書は、ルーター設定プロファイルとして機能するのではなく、制度的判断を導きます。その権威は、IETF コミュニティ内での解釈的かつ憲法的なものです。
いくつかの BCP は、IETF 作業に関する法的または管理的取り決めに関するもので、貢献権や知的財産開示を含みます。その適用は、IETF 活動への参加とそれらの取り決めをサポートする法的構造に依存します。
共有ラベルは、資料が BCP 処理に適しており、該当する IETF 承認を受けたことを読者に伝えます。これらの主題を1つの命令強度にまとめることはありません。内部手続きは、機関がそれを採用したため、IETF の役割に拘束力を持つことができます。運用推奨は、トポロジ固有の実装を許可しながら、事業者に説得力を持つことができます。起草慣行は、呼び出された場合にのみ解釈を統治します。ミッションステートメントは、パケット動作を指定せずに選択肢を導きます。
外部ユーザーは、効果を割り当てる前に命題を分類する必要があります。それは自己統治、プロトコルレジストリ調整、運用セキュリティ、起草セマンティクス、または原則ですか？意図された主体は誰ですか？文書は実際にどのような行動を推奨していますか？どの機関がそれを執行できますか？BCP ラベルは、これらの質問のどれにも単独で答えません。
ステータスはレビューの系譜を確立します。内容と範囲が意味を確立します。
BCP 14 は、規範的言語がグローバルな法律ではない理由を示しています
RFC 2119は、MUST を仕様の絶対要件として定義し、SHOULD を、含意が理解され比較検討された場合に有効な逸脱が存在し得る推奨として定義します。RFC 8174は、特別な解釈を、文書が慣行を呼び出す場合の大文字用語に限定します。
これらのルールは、技術文書をより正確にします。独立した実装者は、適合に必要な動作と、理由のある変動を許可する動作を区別できます。レビューアは、不当な MUST や安全でない MAY に挑戦できます。テスト設計者は期待される結果を識別できます。
この慣行は、大文字が立法すると主張しません。MUST は、仕様内での適合の意味を拘束します。契約、規制、ポリシー、または表明がその仕様を有効に組み込む場合、当事者は法的に義務付けられます。外部の義務の源泉は、BCP 14 が意味内容を提供する場合でも、採用手段です。
この区別は、2つの一般的な誤りを暴露します。1つ目は誇張です：「IETF はすべての企業にこれを行うよう要求している」と RFC が MUST を使用しているから。2つ目は希釈です：「SHOULD はオプションである」と、理解し慎重に逸脱を比較検討する要件を検討せずに。両方とも規範的言語の範囲的役割を無視しています。
外部採用者は SHOULD を必須にすることができますが、それは実質的な変更です。それは技術文書によって選択された例外構造を削除します。採用者は、対象環境が有効な逸脱を認めない理由を説明するか、同等の状況に対する免除を定義する必要があります。逆に、採用者は、プロトコル適合ではなく結果を規制する場合、MUST の代替を許可できますが、仕様がそうでないと言う場合、代替を適合動作と呼ぶべきではありません。
BCP 14 は、したがって、制限された権威のモデルです。それは、数え切れない文書と実装が共通の語彙に依存しているため、非常に影響力があります。その成功は、一貫した使用と解釈可能性に由来します。IETF が大文字の単語に遭遇するすべての人に対して立法管轄権を持っているふりをする必要はありません。
BCP 38 は、なぜ展開が推奨を解釈しなければならないかを示しています
RFC 2827(BCP 38) は、プロバイダーがその起点近くで偽造された送信元アドレスを持つトラフィックをフィルタリングすることを促します。技術的論理は強力です。プロバイダーは、どのプレフィックスが顧客に正当に関連付けられているかを知っており、明らかに偽の主張が広範なインターネットに到達するのを防ぐことができます。他の場所の被害者は保護を獲得し、攻撃の追跡が改善されます。
推奨には明示的な境界もあります。有効な送信元アドレスを使用する攻撃を停止しません。フィルタリングはモビリティや特別なサービスと相互作用する可能性があります。単純なリバースパステストは、トラフィックが非対称ルートをたどるネットワークでは失敗する可能性があります。RFC 3704はしたがって、アクセスリスト、厳格、到達可能パス、ルーズリバースパスアプローチを含むいくつかのメカニズムを説明し、マルチホーミングを検討します。
BCP ステータスは、IETF が送信元アドレス検証について真剣な結論に達したことを事業者に伝えます。すべてのインターフェースに対する1つの普遍的なコマンドを特定するものではありません。事業者はまだ、トポロジ、顧客のアドレッシング、ルーティング変更、障害処理、監視、および正当性を正確にテストできる場所を理解する必要があります。
展開証拠はまた、インセンティブ構造を明らかにします。設定に支払い、誤検知リスクを負うネットワークは、主要な保護を受けるネットワークとは限りません。その価値について広範な合意があるにもかかわらず、プラクティスは展開不足のままである可能性があります。低い採用は BCP が間違っていることを証明しません。コンセンサスがそれ自体で調整とコストを解決しなかったことを示します。
逆の推論も同様に安全ではありません。ベンダーサポートと広範な設定は、すべての実装が効果的であることを証明しません。名目上の機能は、無効化され、間違った境界で適用され、古いプレフィックス情報を供給され、またはテレメトリなしで運用される可能性があります。適合性の主張は、パケットレベルおよび運用上の証拠を必要とします。
したがって、BCP 38 は、普遍的な同意の神話を2つの方向で打ち破ります。公開は普遍的な展開を証明しません。展開は普遍的な同意や最適性を証明しません。正しい解釈は、レビューされた推奨事項とメカニズムがどこでどのように機能するかについての証拠を組み合わせます。
レジストリガイダンスは、権威が定義された役割に依存する可能性があることを示しています
RFC 8126(BCP 26) は、仕様が IANA プロトコルパラメータレジストリの登録ポリシーをどのように述べるべきかを説明します。その目的は実用的です。プロトコル拡張ポイントは、独立した使用が衝突しないように調整された割り当てを必要とします。文書はよく知られたポリシー用語を定義し、指定された専門家について議論し、レビューと上訴を扱います。
ここで BCP の権威は、特定の制度的取り決めに接続されています。IETF はプロトコル名前空間を定義し、関連する登録機能のオペレーターを選択します。仕様は IANA の考慮事項を使用して、値の割り当て方法を指示します。専門家レビュー、仕様必須、標準アクションなどのレジストリポリシーは、それらのプロトコルパラメータに対する決定責任を割り当てます。
これは、BCP 26 が世界のすべてのレジストリを統治するという主張ではありません。土地登記所、企業登録、RIR 割り当てデータベース、アプリストア、プライベート API 名前空間には、異なる権威と影響を受ける利益があります。技術は参考になるかもしれませんが、レジストリという単語が共有されているという理由だけで IETF の役割は移動しません。
プロトコルレジストリ内でも、ポリシー用語は自動執行されません。仕様は、名前空間サイズ、相互運用性リスク、枯渇、レビューの必要性に基づいて適切な登録ポリシーを選択します。IANA は結果の指示を管理します。指定された専門家は、文書化された基準に対して判断を行使します。上訴と公開記録は説明責任を提供します。
このケースは、重要な種類の BCP 正当性を示しています。役割の正当性です。IETF がプロトコル機能に対して責任を持ち、オペレーター、専門家、仕様作成者が定義された役割を持っているため、推奨は強力です。外部団体が同じ用語を借用する場合、BCP がそれを提供すると想定するのではなく、権威とレビュー構造を再作成しなければなりません。
レジストリガバナンスはまた、技術的調整が共有インターフェースで必須である理由を示していますが、普遍的な社会的同意を意味するわけではありません。一意のコードポイントは、一貫性なく割り当てられると相互運用できません。調整の必要性は、技術的ルールの強度を確立します。誰が値を受け取るべきか、またはそれにどのような外部権利が付随するかについてのすべての質問を解決するわけではありません。
コンセンサスは、異議が対処されたことを述べていますが、世界が同意したわけではありません
BCP 承認の最も防御可能な解釈は、手続き的かつ実質的です。手続き的には、文書は該当するレビュールート（IETF ラストコールと IESG 承認を含む）を通過しました。実質的には、IETF コミュニティは、プラクティスまたは原則がその述べられた目的に適切であるというラフコンセンサスに達しました。
その結論は反対を生き残ることができます。参加者は別のメカニズムを好み続けるかもしれません。反対者は、グループが問題を検討したことを認めながら、判断が間違っていると信じるかもしれません。ベンダーはオプションのプラクティスを実装しないことを選択するかもしれません。ネットワークは展開を遅らせるかもしれません。これらの事実は BCP を消し去りません。
しかし、それらは誰かが同意を主張するときに重要です。同意は主体固有です。誰がどのような結果に同意したかを特定する必要があります。IETF ラフコンセンサスは、非参加事業者がコストに同意した、ユーザーがプライバシー効果に同意した、または政府が政策権限を委任したという声明を許可しません。せいぜい、公開参加は、これらの当事者が技術的議論に貢献する公的な機会を持っていたことを示すことができます。
正式な上訴がないことも、普遍的な受け入れを証明しません。上訴には知識、時間、問題内の立場、継続する意欲が必要です。参加者は関与をやめることができます。実装者は公開後にのみ問題を発見するかもしれません。展開条件は変化する可能性があります。耐久性のある機関は、沈黙があらゆる結果を批准したという推定ではなく、公開後の修正を必要とします。
コンセンサス記録は、それが証明できることに使用されるべきです。特定された異議が検討されたこと、なぜトレードオフが選択されたか、結論の範囲を示すことができます。後の採用者に、推奨が未レビューの主張ではなかったという信頼を与えることができます。また、展開がテストすべき不確実性を特定することもできます。
記録は、別の機関の決定の代用として呼び出されるときに悪用されます。規制当局は、IETF がラフコンセンサスに達したため、影響を受けるプロバイダーが同意したと言うことはできません。ベンダーは、動作が BCP に現れるため、顧客がデフォルトを受け入れたと言うことはできません。RIR は、IETF コンセンサスを地域割り当てポリシーのコンセンサスとして扱うことはできません。各団体は独自の承認を確立しなければなりません。
実装者は証人であり、第二の普遍的な会議室ではありません
BCP がプラクティスに関係するため、実装者は異常な証拠的価値を持ちます。彼らは、テキストが明確か、メカニズムが利用可能か、独立した製品が一貫して動作するか、運用コストが管理可能かを示すことができます。彼らの報告は、議論では見えない仮定を暴露することができます。
しかし、実装者も代表的な有権者ではありません。初期の実装は、文書作成者、大規模ベンダー、研究チーム、または異常な能力を持つ事業者から来ることがよくあります。共有ライブラリは、一見独立した製品に1つの解釈を継承させることができます。支配的な実装は、バンドルやインストールベースを通じて採用を獲得できます。小規模ネットワークや制約のあるデバイスは遅れて現れるかもしれません。
したがって、証拠は等級付けされるべきです。1つのプロトタイプは実現可能性をサポートします。相互運用する2つの独立した実装は、明確さと互換性をサポートします。多様な展開は、観察された条件下での運用適合性をサポートします。障害報告は境界を特定します。長期間の測定は、有効性と保守負荷に関する主張をサポートします。市場浸透率だけでは、なぜ採用が発生したかを明らかにできません。
実装者の反対は、数えるのではなく分析されるべきです。複数のチームが独立して要件を実装できない場合、文書は曖昧か非実用的かもしれません。1つのベンダーが、要件がプロプライエタリアーキテクチャと衝突するため反対し、競合他社が成功裏に展開する場合、証拠は異なる重みを持ちます。小規模事業者が人員やテレメトリの負担を特定する場合、技術的方法は健全なままでありながら、外部義務は移行またはサポートを必要とするかもしれません。
IETF の実行コードの伝統は、これらの事実を技術的判断に戻すルートを与えます。BCP は、公開が発生したため、反対の展開から隔離されるべきではありません。新しい証拠は、明確化、更新、代替プラクティス、またはステータスの変更を動機付ける可能性があります。
同時に、展開は BCP を黙って書き換えることはできません。支配的な製品の動作は修正ではありません。事業者は効果的な代替案を開発するかもしれませんが、インストールされたプラクティスはレビューされた推奨事項と公然と比較されるべきです。そうでなければ、市場の力が変更を認めることなくラフコンセンサスを置き換えます。
実装者は、「ベスト・カレント・プラクティス」が真実であり続けるかどうかを判断するのに役立ちます。彼らは、スコープされた IETF の結論を実装することによって、それを普遍的な同意に変換するわけではありません。
非展開は証拠ですが、それ自体で評決ではありません
疎らに展開された BCP は不快な質問を提示します。推奨は技術的に正しいが、インセンティブが弱いかもしれません。ローカルコストをリモートベネフィットのために課すかもしれません。ゆっくりと到着した製品機能に依存するかもしれません。ネットワークが所有していない運用データを必要とするかもしれません。または、複雑すぎる、リスクが高い、または範囲が不適切かもしれません。
最初のタスクは診断です。採用数だけではこれらの原因を区別できません。レビューアは、ネットワーククラス、トポロジ、製品能力、設定状態、観察された障害、人員負担、事業者が代替案を選択した理由を必要とします。「BCP 38 をサポート」と言う調査は、ソース検証がアクティブでどのトラフィックを拒否するかを示す証拠よりも有用性が低いです。
2番目のタスクは、技術的妥当性を政策対応から分離することです。プラクティスが強い集合的利益を生み出すが弱い私的インセンティブしか生み出さない場合、調整、調達、保険、または規制が検討される可能性があります。その外部行動は独自の正当性を必要とします。展開不足の事実は、IETF が規制当局になる権限を与えるものではなく、BCP ステータスは規制当局が比例性を証明する責任を軽減しません。
非展開が技術的危害から生じる場合、BCP は再検討を必要とします。事業者は、前提がもはや成り立たない、有効なトラフィックを区別するのが難しい、または制御が攻撃を軽減するのではなく移動させることを発見したかもしれません。証拠は、プライベートサポートケースに留まるのではなく、責任ある IETF コミュニティに届くべきです。
非展開が低コストと明確な利益にもかかわらず無知や慣性を反映する場合、より強力なガイダンスとより良い実装サポートで十分かもしれません。ベンダーのデフォルトは、観察可能で安全であれば役立ちます。相互運用性イベントと共有テストは不確実性を減らすことができます。
すべての非展開者を非準拠と呼ぶことは、これらの可能性を曖昧にします。BCP は、なぜプラクティスが推奨から乖離するのかを学ぶことを拒否することによって強化されません。現在であるという主張は、乖離を情報として扱うことに依存しています。
正しい結果は依然として強固な外部要件かもしれません。しかし、その要件は診断に従い、達成可能な目的を定義し、レビューを保持する必要があります。ステータスは強い推定で調査を開始しますが、それを終了しません。
広範な展開も普遍的な同意ではありません
反対のケースは祝賀が容易で、同じくらい過剰解釈されやすいです。BCP は製品、運用トレーニング、契約、ネットワーク期待に埋め込まれる可能性があります。逸脱はコストがかかります。その時点で、支持者は展開をインターネットによる批准として説明するかもしれません。
展開はいくつかの価値あることを証明します。メカニズムは規模で実装できます。事業者はそれを維持する十分な価値または必要性を見いだしました。ベンダーはサポートに収束しました。障害モードはよく知られるようになりました。新規参入者はインストールされたベースラインに依存できます。いくつかの相互運用性機能については、この証拠は決定的です。
それはすべての動機を明らかにしません。採用は、互換性圧力、支配的なデフォルト、買い手要件、規制、責任の恐れ、または調整された移行パスの欠如を反映する可能性があります。ネットワークは、別の設計が優れていると信じながら、ピアがそれを要求するため展開するかもしれません。ユーザーは何の選択もせずに効果を受けるかもしれません。
また、展開は公平性を確立しません。プラクティスは技術的に機能しながら、制御を集中させ、小規模な主体に不均衡なコストを課し、または害を外部化する可能性があります。これらの影響は、プラクティスを放棄することが今や困難であっても、レビューに属します。インストールベースは制約であり、道徳的承認ではありません。
最も強い結論はより狭いです。広く多様な展開は、運用可能性と依存性への信頼を高めます。互換性のない変更のコストを引き上げ、慎重な移行のケースを強化します。それは「カレント」という言葉をサポートするかもしれません。それはユーザーを有権者に変えたり、普及を生み出した採用決定を消し去ったりしません。
この境界は改訂を保護します。展開が普遍的な同意であった場合、成功した BCP を変更することは、決着した社会契約を裏切るように見えるでしょう。実際には、IETF は証拠が改善されたときに技術的ガイダンスを更新でき、外部機関は依存性を処理する方法を決定します。アーカイブは古い命題を記録し、現在のサブシリーズは移動できます。
実行コードはプラクティスの証人です。それはそのトラフィックを通過するすべての人によって投じられた投票ではありません。
外部採用者は欠けている憲法層を提供しなければなりません
BCP は、事業者ポリシー、調達仕様、レジストリルール、業界保証、または規制の優れた基盤かもしれません。採用者の最初の義務は、正確な命題を特定することです。文書全体の引用だけでは十分ではありません。どの主体、行動、例外、条件が関連していますか？
2番目の義務は、制度的権限を説明することです。規制当局は法律に基づいて行動します。購入者は契約を通じて行動します。レジストリはそのガバナンスとコミュニティポリシーに基づいて行動します。ベンダーは製品設計と表明を管理します。どれも IETF の正当性を自己の代替として借用することはできません。
3番目は範囲をテストすることです。IETF コミュニティはインターネット相互運用性のために最適化したかもしれませんが、採用者はより狭いセクターまたはより広いクラスのシステムをカバーします。サービスプロバイダーエッジを対象とした BCP は、エンタープライズコアに適合しないかもしれません。IETF の自己統治ルールは、技術コミュニティで機能したからといって、公共行政の一般的なモデルにはなりません。
4番目は証拠です。適切な実装は利用可能ですか？独立したシステムは期待通りに動作しますか？展開は有効性、誤検出、保守、コストについて何を示していますか？どの影響を受けるクラスが欠けていますか？BCP は強いレビューされた仮説としばしば相当な経験を提供しますが、採用者は自己の結果に対して証拠を必要とします。
5番目は翻訳です。MUST は適合用語のままですか、それとも法的義務になりますか？SHOULD の例外は保持されますか？同等の管理は受け入れられますか？どの BCP バージョンが適用されますか？後の更新とステータス変更はどのように処理されますか？
6番目は説明責任です。誰がコンプライアンスをテストしますか？影響を受ける当事者は証拠を検査し、代替案を示し、理由を得て、上訴できますか？失敗に続く救済手段は何ですか？技術的推奨はこれらの質問のすべてに答えられません。なぜなら、それらは外部機関に属するからです。
記録がこれらの層を提供するとき、BCP 引用は強みです。ポリシーを公開技術基盤に接続します。層が欠けている場合、引用は権威のロンダリングになります。採用者は、決して主張された結果を含まなかったコンセンサスに選択を帰する一方で、権力を行使します。
結果的使用には展開と範囲の声明を伴うべきです
BCP へのすべての結果的な依存には、短い展開と範囲の声明をペアにする必要があります。それは文書の身元から始まります。BCP および RFC 番号、現在の更新関係、正誤表、公開ステータス、使用された正確なセクション。
次に、命題を平易な言葉で述べます。「対象となるアクセスネットワークは、顧客トラフィックがその顧客に正当に関連付けられていない送信元アドレスを使用するのを防がなければならない」は、「BCP 38 に準拠する」よりも明確です。平易な言葉の声明は、採用者が結果、特定のメカニズム、またはプロトコル適合を規制するかどうかを明らかにします。
次の部分は証拠を特定します。どの製品と独立した実装が動作をサポートしますか？どのトポロジで展開されていますか？どの測定が有効性を示していますか？どの障害モードと代替案が知られていますか？何が不確かですか？
範囲が続きます。誰がカバーされ、誰が利益を得て、誰がコストを負担し、どのネットワークまたは制度的条件が想定されていますか？BCP の意図された対象が規制または契約された集団と異なる場合、採用者は拡張を説明する必要があります。
声明は、誇張せずに参加を記録する必要があります。BCP が IETF ラフコンセンサスと公開レビューを反映していると言うかもしれません。採用者の影響を受ける当事者間の協議を別途説明する必要があります。一方が他方の代わりになることはできません。
最後に、時間と修正を指定します。どのバージョンが制御しますか？展開証拠はいつレビューされますか？どのイベントが再検討をトリガーしますか？当事者は同等の措置またはトポロジ固有の例外を示すことができますか？どの上訴が利用可能ですか？
この声明は、カテゴリラベルが決して設計されていない仕事をするのを防ぎます。また、実装者に具体的な目標、レビューアに挑戦の基礎、IETF にそのガイダンスが元の審議設定外でどのように機能するかについての有用なフィードバックを提供します。
規律は控えめです。良いアドバイスに従う前に、すべての事業者が憲法論文を書く必要はありません。BCP 引用が排除、罰則、リソース拒否、または市場アクセスを伴う場合に最も重要です。結果が説明の深さを決定する必要があります。
現在のプラクティスは変更する積極的な能力を必要とします
BCP カテゴリの整合性は修正に依存します。文書は公開時に優れていても、後に不完全になる可能性があります。脅威は変化します。実装は曖昧さを明らかにします。展開は新しい外部性を生み出します。手続きは高コストになります。制度的責任が移動します。より良いメカニズムが利用可能になります。
RFC アーカイブは、黙示的な変更に適切に抵抗します。参加者と実装者は、ある時点で正確に何が承認されたかを知る必要があります。更新、廃止、正誤表、サブシリーズ関係により、歴史を書き換えることなく現在の命題が進化できます。
そのアーキテクチャは、ユーザーがそれに従う場合にのみ機能します。廃止された RFC を引用する外部ポリシーは、死んだガイダンスを生かし続けることができます。更新を省略するベンダーの主張は、適合性を誤って述べる可能性があります。監査人は、ステータス行が古い文書で見えるままであるため、歴史的な推奨事項を執行できます。現在のインデックス情報は、アーカイブ引用に付随する必要があります。
IETF はまた、展開からの信号を必要とします。障害報告は、尊敬される BCP に挑戦する場合でも歓迎されるべきです。事業者は、教訓を保存するのに十分な抽象度で敏感なインシデントを説明できるべきです。ベンダーは、不可能または矛盾する要件を報告すべきです。研究者は、期待される利益が発生するかどうかをテストすべきです。
再検討は反転を意味する必要はありません。更新は、適用可能性を明確にし、代替案を追加し、実装ガイダンスを記録し、主張を狭め、または新しい証拠が推奨を変更しない理由を説明することができます。重要なのは、「カレント」が推論された結論であり、儀式的な言葉のままであることです。
外部採用者は独自のレビュークロックを必要とします。IETF の更新が自動的に法律や契約を変更すると想定すべきではありませんが、無期限に無視するべきでもありません。実質的な技術的変更は、採用、移行、および依存性についての公的な決定を正当化します。害の証拠は、公式の改訂が完了する前の暫定的な救済を正当化する可能性があります。
BCP は、公開で修正可能であることにより、耐久性のある尊敬を得ます。普遍的な同意の主張は、改訂を想像上の全会一致の解決への攻撃に変えるため、その強みに反します。
正確な主張は十分に強力です
BCP ステータスを膨らませる必要はありません。正確な主張は実質的です。IETF ストリーム上の BCP は、未レビューのブログ投稿、プライベートベンダーの好み、一過性の会議の発言ではありません。それは公開技術審議、ラフコンセンサス、IESG 承認を反映しています。それは、プラクティスまたは原則を導くことを意図した判断を記録します。
その判断は、実装者と外部機関に重みを持つべきです。十分にサポートされた BCP から逸脱する事業者は、結果を理解する必要があります。同等を主張するベンダーは証拠を示すべきです。政策立案者は、その技術的根拠に関与することなく IETF 推奨を却下すべきではありません。レジストリは、IETF の責任内のアーキテクチャと調整要件を尊重する必要があります。
限界も同様に明確です。BCP は、普遍的な参加、展開、同意、法的権威、または適用可能性を証明しません。ラフコンセンサスは反対を許可します。公開参加は代表的な同意ではありません。規範的用語は、外部義務の前に仕様要件を定義します。広範な展開は依存性と実現可能性を示しますが、世界的な投票ではありません。
したがって、解釈は規律ある順序で進むべきです。現在の BCP とその構成 RFC を読む。意図された主体とドメインを特定する。異議と範囲の記録を回復する。独立した実装と展開を検討する。相互運用性の必要性を政策の好みから区別する。外部団体が結果を課す場合、自己の権限、証拠、翻訳、救済を述べるよう要求する。
この順序は、エンジニアリングと正当性の両方を保護します。IETF は、皆を統治するふりをすることなく明確な推奨を発行できます。実装者は、ネットワークからの証拠を犠牲にすることなく BCP を真剣に扱うことができます。外部団体は、選択した政策に対して説明責任を保ちながら、強力な技術基盤を採用できます。
ベスト・カレント・プラクティスは、来歴、範囲、日付を持つ結論です。それは普遍的な同意ではありません。誰もそれがそうであることを求めないときに、より有用です。
証拠と分析の限界
RFC 1818は、1995年の BCP サブシリーズの起源と、IETF の技術的承認と公式のインターネット標準との初期の区別をサポートしています。RFC は現在 Historic であるため、創設の歴史として使用されており、現在の手続きとしてではありません。
RFC 2026は、現在のフレームワークの BCP の目的、レビュー、IETF ラストコール、IESG 承認、上訴、コミュニティコンセンサス、標準化トラック成熟との区別の核となる説明をサポートしています。後の RFC によって更新されており、変更されていないスタンドアロンコードとして読まれるべきではありません。
RFC 8789は、IETF ストリーム RFC に IETF ラフコンセンサスを要求する現在の要件をサポートしています。それは普遍的な同意を定義したり、外部機関が BCP をどのように採用すべきかを規定したりしません。
RFC 7282は、ラフコンセンサスを問題焦点の判断として説明し、異議に対処する必要があるが必ずしも対応する必要はないこと、投票集計を決定ルールとして拒否することをサポートしています。それは IETF コンセンサスに関する Informational なガイダンスであり、すべての実装者の調査ではありません。
RFC 3935は、オープンプロセス、技術的能力、ラフコンセンサスと実行コード、プロトコル所有権、個人参加の原則をサポートしています。代表的な限界の分析は制度的推論であり、ミッションステートメントが組織の従業員の参加を拒否するという主張ではありません。
RFC 7841は、RFC ストリームとカテゴリの区別、複数の RFC にわたるサブシリーズ番号の使用、更新関係、不変の RFC の印刷されたステータスが後のステータス変更を反映しない可能性があるという警告をサポートしています。
RFC 2119とRFC 8174は、BCP 14 の例と規範的キーワードの制限された意味をサポートしています。契約または規制効果の議論は外部機関の分析であり、特定の法律の解釈ではありません。
RFC 2827とRFC 3704は、入力フィルタリングの例、そのセキュリティ目的、技術的制限、複数の実装方法、マルチホーミングの懸念をサポートしています。すべての事業者がこれらのプラクティスを展開している、または1つの設定がすべてのトポロジに適合するという主張はありません。
RFC 8126は、プロトコルパラメータレジストリの例、登録ポリシーの用語、指定専門家の役割、上訴構造をサポートしています。それは、IETF プロトコルパラメータ調整外のレジストリに対する権威として提示されていません。