要約
- IETF のランニングコードの伝統は、反修辞学的規律として最もよく理解される。独立した実装、相互運用性テスト、運用経験は、曖昧さ、隠れた状態、スケーリングの限界、安全でないデフォルト、紙面上でしか機能しない主張を明らかにすることができる。
- 証拠は均一でも自己解釈的でもない。プロトタイプは独立した相互運用可能な実装よりも証明力が低い；制御されたテストは多様な展開よりも証明力が低い；広範な展開は有用性を示す一方で、先発者の優位性、バンドル配布、切り替えコストを反映することもある。
- ランニングコードは、認可された標準化プロセス内で工学的な質問に答える。非技術的政策を誰が決定するかを特定したり、オペレーターを有権者に変えたり、未解決の権利異議を無効にしたり、IETF の責任範囲を超えたプロトコルや機能にその権限を拡大したりするものではない。
コンパイルは証人を伴う議論である
技術会議は特定の確信に対して脆弱である。提案は、クリーンなアーキテクチャ、シーケンス図、相互に互換性があるように見える一連の要件とともに提示される。語彙は正確である。各批判には回答がある。しかし、見かけ上の一貫性は、同じマシンを占有したことがなく、同じ管理境界を越えたことがなく、同じ障害に耐えたことがない仮定に依存している可能性がある。
ランニングコードはその確信を中断する。パーサーは、不十分に指定されたフィールドが何を意味するかを決定しなければならない。ステートマシンは、ある状態を離れて別の状態に入らなければならない。2つの独立した実装は、ハッピーパスだけでなく、不正な入力、再送、ダウングレード、タイムアウト、リカバリ、バージョンスキューについても合意しなければならない。オペレーターは、作者のメンタルモデルにアクセスすることなく、午前3時に何が起こったかを知らなければならない。展開は、設計チームが制御していなかった機器やポリシーと共存しなければならない。
これが、実装が反修辞学的チェックとして機能できる理由である。設計が実装可能であるという主張を、誰かが実装したという証拠に置き換える。仕様が明確であるという主張を、独立した読者が互換性のある動作を生み出したという証拠に置き換える。機能が運用上有用であるという主張を、ネットワークがそれを選択し、維持し、サポートできたという証拠に置き換える。証拠は議論を終わらせるものではないが、一部の議論形式を維持するコストを高くする。
このチェックは特に IETF において重要である。なぜなら、同組織は採用を強制しないからである。インターネット標準は、自律的なネットワーク、製品、法域、商業関係を超えて自発的に従われる。ドキュメントは承認され、公開されても、一般的な慣行にならないことがある。逆に、実装は仕様が安定する前に広がることがある。したがって、標準化プロセスはテキストと使用の間にある。どちらも他方の完全な説明として安全に扱うことはできない。
誤りは、有用な規律を権威の理論に変えることである。コードはパケット処理に関する主張を反証できる。実行によって、作者が好むコスト配分が公平であると確立することはできない。展開は、オペレーターがメカニズムを許容していることを示すことができる。影響を受けるユーザーがすべての結果に同意したことを証明することはできない。市場の成功は、選択に関する調整を示すことができる。IETF がその技術的使命の外にある事項を規制すべきであることを示すことはできない。コードの証拠力は、その限界が述べられることができるからこそ現実的である。
1992年の信条は姿勢による決定の拒否であった
よく知られたフレーズは、David Clark 氏の1992年全体会議での発表を通じて IETF の記憶に入った：王、大統領、投票の拒否；ラフコンセンサスとランニングコードへの信念。RFC 7282は後に、この信条を使用して制度的な選好を説明した。単一の人物が答えを指示するのではなく、頭数を数えることが決定ルールではなく、工学的判断は実践的な経験なしに進むべきではない。
2つの半分は異なる誘惑を制約する。ラフコンセンサスは、実装された提案がそのスポンサーが最初に到着したという理由だけで勝つのを防ぐ。グループは技術的異議、特に少数派によって提起された異議を考慮しなければならない。ランニングコードは、言葉で魅力的なコンセンサスが物理的証拠から隔離されるのを防ぐ。参加者は設計に同意しても、それが記述されたとおりに実装できない、相互運用できない、または議論が見落としたコストを課すことを発見することがある。
その組み合わせは、スローガンがしばしば聞こえるよりも要求が厳しい。デモンストレーションを持っている人が支配するルールではない。実装者間の国民投票ではない。1つのコードベースが動作するという理由だけで議論が終わったと議長が宣言する許可ではない。コードは、その出所、カバレッジ、独立性、関連性が疑問視される審議プロセスに入る。コンセンサスは、主張がテストにさらされたままの工学的プロセスに入る。
RFC 3935、IETF ミッションステートメントは、その組み合わせに制度的な形を与える。参加者の統合された工学的判断と、仕様の実装と展開に関する実際の経験に基づく標準を記述する。また、オープンプロセス、技術的能力、自発的なコア、プロトコルの所有権を列挙する。これらの原則は互いに崩壊しない。実際の経験は判断に情報を提供する；オープンな参加を置き換えるものではない。技術的能力は技術的事項に関する IETF の発言を支える；一般的な管轄権を付与するものではない。
ミッションステートメントはまた、有用性を具体的にする。インターネット標準の価値は相互運用性にある：標準を実装する複数の製品が連携して有用な機能を提供できること。その定式化は、劇場的なプロトタイプから離れ、複数の証拠に向かう。関連する質問は、コードが実行されるかどうかではない。実装、ユーザー、ネットワークが、重要な条件下で仕様を通じて調整できるかどうかである。
したがって、ランニングコードは、未獲得の抽象化の制度的拒否として最もよく読まれる。著者は洗練されたドラフト以上のものを示さなければならない。ワーキンググループは、支持の大きさ以上のものを検討しなければならない。議長は、異議への真の回答と集団的不耐性を区別しなければならない。IESG は、提案された標準の品質と運用上の影響を考慮しなければならない。すべてのレベルで、主張は利用可能な最強の証拠に直面すべきである。
RFC 2026は経験を目標にしたが、普遍的なゲートにはしなかった
RFC 2026は、インターネット標準化プロセスを、技術的優秀さ、事前の実装とテスト、明確な文書化、公開性と公平性、タイムリーさを追求するものとして説明する。成熟したインターネット標準は、安定しており、よく理解され、技術的に有能であり、複数の独立した相互運用可能な実装と substantial な運用経験によって支えられ、公的に支持され、認識可能なほど有用であると説明する。
これは実践からの証拠の重要な承認である。標準は、時間が経過したり、連続する委員会が承認したからといって成熟するわけではない。経験は仕様を変更すべきである。曖昧さは除去されるべきである。互換性のない動作を生み出す実装の選択は明示的になるべきである。運用上の危険は、適用可能性、デフォルト、セキュリティガイダンスに影響を与えるべきである。誰も使用できない標準は、正式なラベルを取得しても良くならない。
しかし、プロセスは1996年以降変更されており、標準トラックの構造も含まれる。さらに重要なことに、実装は IETF のすべての出版物に対して同一の前提条件として機能したことはない。RFC 7942は、実装は RFC として公開するために必須ではないと直接述べ、Proposed Standard がそれなしで公開されたことを指摘している。また、Routing Area がかつて実装要件を適用していたこと、一般的な要件が後に解除されたこと、個々のワーキンググループが独自のルールを課すことができることを記録している。
その変動性は、ランニングコードが空であることの証拠ではない。スローガンが機械的なゲートではなく判断の方法であることの証拠である。一部の仕様は早期に実装されるべきであり、できる。一部は依存関係が成熟するまで意味のあるテストができない動作を調整する。一部はアーキテクチャまたはプロセスを文書化する。一部は緊急の相互運用性ニーズに応答し、公開を遅らせると悪質な断片化が維持される。証拠要件は、主張と成熟度レベルに一致すべきである。
強制的な普遍的なルールはまた、ゲームを招くだろう。スポンサーは、容易なパスのみをカバーする名目上の実装を生成できる。2つの製品はライブラリを共有しながら独立としてカウントされる可能性がある。テストは仕様ではなく実装を中心に設計される可能性がある。コードはユーザー、運用サポート、セキュリティレビュー、または信頼できるメンテナンスなしに存在できる。コンプライアンスの外観は、ルールが作成することを意図した規律を置き換えるだろう。
RFC 2026のより良い読み方は累積的である。事前の実装とテストはプロセス目標の1つである。独立した相互運用性と substantial な運用経験は、成熟した標準化における強力な証拠である。公開性、公平性、文書化、公的支持は別個の要件のままである。実装は技術的ケースを強化する；プロセスの残りからの免除を購入するものではない。
すべてのランニングコードが同じ証拠的重みを持つわけではない
このフレーズはいくつかの異なるものを圧縮している。最低レベルでは、コードはコンパイルされるかもしれない。それは、1つのプログラミング言語が設計の1つの表現を受け入れたことを示す。それはまだパケットを交換したり、敵対的な入力を処理したり、再起動に耐えたりしないかもしれない。コンパイルは著者にとって有用であり、相互運用性の主張にはほとんど無関係である。
単一のプロトタイプはより多くを証明する。それはステートマシンが一貫しているか、必要なデータが利用可能か、基本メカニズムが計算的に可能かを明らかにできる。ドラフトの省略を明らかにできる。しかし、同じチームがテキストとコードの両方を書いた可能性があり、同じ暗黙の前提をそれぞれに持ち込んでいる。それらの成果物間の一致は自己一致であり得る。
独立した実装は基準を引き上げる。2番目のチームは、最初のチームが利用できるすべてのプライベートな説明に依存せずに仕様を解釈する。違いは曖昧さに関する証拠になる。それでも、2つの実装は互いにテストされていないか、依存関係を共有しているか、異なるサブセットを実装している可能性がある。独立性は事実の問題であり、テーブル内のカウントではない。
相互運用性テストは、バージョン、オプション機能、障害経路、拡張処理、回復をカバーする場合に強力である。1つのスクリプト化された交換を完了する実装のペアは、複数のシステムがさまざまな条件下で通信することを示すマトリックスよりも確立するものが少ない。否定的なテストが重要である。すべての入力が整形式で、すべてのメッセージが順番に到着した場合にのみ相互運用できるプロトコルは、インターネットに適合していない。
運用展開は別の層を追加する。ネットワークは、異種の機器、管理境界、不完全なアップグレード、監視の制約、テストイベントにはないインセンティブを導入する。オペレーターは、プロトコルが診断可能か、障害が封じ込められているか、設定が理解可能か、利益が継続的なコストを正当化するかを発見する。長期にわたる展開は、ラボが効率的にシミュレートできない相互作用を明らかにすることができる。
広範な使用は客観的なはしごの最終段ではない。それは有用性、安定性、または実装者の関心の優れた証拠であり得る。また、支配的なベンダー、バンドル、デフォルト設定、レガシー依存、契約上のレバレッジ、調整された移行経路の欠如を反映することもある。メカニズムが展開されるほど、技術的メリットとそれを離れるコストを分離するのが難しくなる。
したがって、ワーキンググループは各実装事実がどの命題を支持するかを尋ねるべきである。「コードがある」は存在を支持する。「2つの独立した実装が相互運用する」はある程度の明確さと互換性を支持する。「複数のオペレーターが混合条件下で何年も実行した」はそれらの条件下での運用可能性を支持する。これらの記述のどれも、単独で普遍的な安全性、最適性、公平性、または制度的管轄権を支持するものではない。
RFC 7942は民間伝承を控えめな証拠実践に変えた
RFC 7942の実装状況メカニズムは、コードがそれ自体を語るふりをしないので価値がある。著者は、既知の実装を記述する一時的なセクションをインターネットドラフトに含めることができる。推奨される情報には、責任組織、成熟度、機能カバレッジ、互換性のあるドラフトバージョン、ライセンス、経験、連絡先詳細、更新日が含まれる。相互運用性レポートとテストの説明も記録できる。
各フィールドは予測可能なインフレーション源に答える。成熟度は研究プロトタイプと実運用を区別する。カバレッジは、1つの機能の実装が提案全体の実装として表現されるのを防ぐ。バージョン互換性は、デモンストレーションが審査中のドラフトを追跡しているか、古い設計かを明らかにする。ライセンスは、他者が実装を検査またはテストできるかどうかに影響する。日付は、古い主張が最新であるように見えるのを防ぐ。
メカニズムは意図的に非必須である。ワーキンググループは情報の使用方法を決定する。セクションは RFC 公開前に削除される。なぜなら、実装状況は時間とともに変化し、アーカイブ仕様で凍結されるべきではないからである。議長とエリアディレクターは、それがマーケティングの場になるのを防ぐように求められ、標準的な文言はリストが IETF の推奨を意味しないことを警告する。
これらは管理上の詳細ではない。彼らは正しい認識論的姿勢を表現している。実装は利害関係者によって寄与された証拠である。すべての点で検証されていなくても有用であり得る。作業の優先順位付け、プロトコルの欠陥の露呈、相互運用性テストの支援、困難な機能が実装可能であることの示唆に役立つ。出所と限界が消えると広告にもなり得る。
RFC 7942は重要な限界を含んでいる：コードは明確な仕様の代わりになるべきではない。実装はそれ自体のために曖昧さを解決できるが、インターネット標準は他の人が公開テキストから意図された動作を再現できるようにしなければならない。「支配的なコードベースを読め」は相互運用性ではない。それは権限をオープンドキュメントから、より狭いグループによって管理される維持された成果物に移す。
その限界は後の参入者も保護する。新しい実装者は、必要な動作を発見するために元のチームへの個人的なアクセスを必要とすべきではない。オペレーターは障害を理解するために1つのベンダーをリバースエンジニアリングすべきではない。レビューアーは、コードを仕様として扱うのではなく、コードを仕様と比較できるべきである。ランニングコードは、テキストがコードを規律できる状態を維持する場合にのみテキストを規律する。
相互運用性は私的な意味に対する証拠である
独立した実装の最も強いガバナンス特性の1つは、私的な仮定を可視化することである。ドラフトは、著者が何年もの議論、共通のライブラリ、および文が「明らかに」何を意味するかの感覚を共有しているため、完全に見えることがある。2番目の実装はその背景なしに到着する。異なる動作をする場合、その違いは標準が私的な意味を含んでいることを明らかにできる。
私的な意味は常に意図的ではない。それはデフォルト、単位、順序、エラー処理、またはタイマーが開始するポイントに存在することがある。元のチームの全員が覚えている遷移を省略した図から生じることがある。意図に関係なく問題は制度的である。すべてが利用可能な仕様は、内部関係者だけが正しく実装できる場合、真にオープンではない。
したがって、相互運用性テストはアクセシビリティのテストとして機能できる。公開された成果物が組織の境界を越えて十分な情報を伝えるかどうかを尋ねる。答えは、実装が異なる言語、製品アーキテクチャ、運用環境のチームから来る場合に特に重要である。多様性の下で達せられた一致は、密接に関連するコードベース間の一致よりも強い証拠である。
同じ論理が拡張性にも適用される。プロトコルは元のペアの間で機能するが、未知のフィールド、新しいメッセージタイプ、部分的な展開に対して安全な動作を残さないことがある。独立した実装者は、多くの場合、グループに古いシステムが新しいシステムが現れたときに何を行うかを指定させる。拡張ポイントが本物か装飾かを明らかにする。
しかし、相互運用性は相互運用可能な動作が望ましいことを証明しない。2つの実装は、プライバシー漏洩、処理コストの不公平な配分、危険なデフォルトを忠実に再現できる。互換性は特性であり、道徳的評決ではない。テキストが動作を調整できることをグループに伝える。グループは、その動作がインターネットに役立ち、IETF の正当な技術的役割の範囲内にあるかどうかをまだ決定しなければならない。
それが政策の越権に対する最初の境界である。技術的事実は、システムが同意することを確立できる。それだけで、同意がすべての影響を受ける利害を尊重することを確立することはできない。オープンレビューと理由あるコンセンサスは、実装がメカニズムをテストするが、それを選択することの完全な正当性をテストするわけではないため、依然として必要である。
展開証拠はデモンストレーションより強く、ドクトリンより乱雑である
オペレーターはプロトコルを論文ではなく依存関係として遭遇する。彼らはアップグレードを計画し、アラームを解釈し、部分的な採用を管理し、スタッフを訓練し、障害を説明しなければならない。彼らの経験は、ドラフトでオプションと見なされた機能が運用上必須になること、安全なデフォルトが展開するには高すぎること、障害信号が通常の損失と区別できないことを明らかにできる。そのような発見は、アーキテクチャがエレガントであるという繰り返しの保証よりも多くの重みに値する。
展開はまた、インセンティブの互換性をテストする。すべての参加者が他者がコストを負担する場合にのみ利益を得る場合、自発的な採用は停滞する可能性がある。早期採用者が到達不能になると、移行設計は標準が求める行動を罰する可能性がある。セキュリティが受信者が顧客が期待するトラフィックを拒否することに依存する場合、商業的压力がルールを打ち負かす可能性がある。コードは実行できるが、展開モデルは失敗する。
オペレーターの証拠は、具体的である場合に最も強い。どのネットワーク条件が存在したか？どのバージョンと機能が有効になったか？いくつの管理ドメインが参加したか？どのような障害が発生したか？どのフォールバックが使用されたか？どのメトリクスが変化したか？何が観測されなかったか？「オペレーターはこれを支持する」という声明は、基礎となる経験が検査されない限り修辞である。
また、欠落しているオペレーターを探す必要がある。大規模なバックボーンネットワーク、コンテンツプラットフォーム、アクセスプロバイダー、エンタープライズネットワーク、コミュニティネットワーク、小規模サービスプロバイダーは同じ制約を持たない。専任のプロトコルエンジニアを持つチームにとって容易な設計は、小規模オペレーターにとって実用的でないかもしれない。大規模な送信者に利益をもたらす機能は、交渉力の弱いネットワークに状態やトラフィックをシフトさせるかもしれない。
展開レポートは、失敗した試行が消え、企業がインシデントの詳細を保護し、否定的な経験を持つエンジニアがドラフトを書く時間がないため、失敗を過小評価することがある。成功した実装者は、機能が彼らにとって重要であるため、しばしばワーキンググループに積極的に留まる；それを放棄した者は去るかもしれない。したがって、生き残った記録は、誰も主張を偽造することなく成功を過大評価する可能性がある。
救済策はオペレーターを割り引くことではない。証拠を改善することである。ワーキンググループは、条件、反例、失敗した試行、独立した測定、明示的な不確実性を要求できる。ベンダーの製品ロードマップとネットワークの観測結果を区別できる。異なるコストを負担するオペレーターを招待できる。実践的な経験は、異議のない資格として到着するのではなく、会合を規律すべきである。
コードは構成員になり得るが、有権者にはならない
実装者とオペレーターは、他者が持たない情報をもたらすため、IETF の審議において正当な立場を持つ。彼らは仕様がどこで曖昧か、展開のコスト、どの仮定が失敗するかを知っている。IETF ミッションステートメントの技術的に有能な入力をあらゆる情報源から受け入れるというコミットメントは、その証拠を聞くことを支持する。
しかし、証拠と権威は異なる。IETF は、オペレーターチェンバーやベンダーフランチャイズを持つ会員組織ではない。RFC 7282は、誰が投票するかを定義する難しさが、IETF の決定が投票によって行われない理由の1つであると説明している。コードを持つ者のみに投票権を与えることは問題を解決しない。エンジニアリング予算、既存の製品、テストインフラへのアクセス、展開システムの制御を持つ参加者を優先する新しい境界を作り出すだろう。
実装加重の有権者もまた、循環性を招くだろう。既存事業者に有利な設計は、既存事業者が実装しやすい。その実装はコンセンサスの証拠となる。代替チームは、係争中の選択がそれを生産するコストを引き上げるにもかかわらず、ランニングコードがないと言われる。最初の展開は、市場と手続き上の両方の利点を獲得するだろう。
これらのどれも、支持されていない異議が作業を停止すべきであることを意味しない。ラフコンセンサスは、技術的異議が誠実に考慮され不十分であると判断された後、進行を許可する。RFC 7282は、異議を却下する多数の合意だけでは十分ではなく、グループはそれについて推論しなければならないと明示している。コードが答えを提供するかもしれない。テストは、予測された障害が関連条件下で発生しないこと、または緩和策が機能することを示すかもしれない。
議長の任務は、リポジトリを数えるのではなく、問題を評価することである。再現可能な障害を提示する異議申立人は、ハッピーパスでの成功を報告する10人の実装者よりも多くの注意を受けるに値するかもしれない。逆に、反対の測定に関与せずに繰り返し失敗を予測する人は拒否権を得ない。重みは制度的地位ではなく、技術的問題と証拠から来る。
したがって、オペレーターは専門家証人および影響を受ける参加者として扱われるべきであり、隠れた上院としてではない。彼らの経験は工学的な主張を打ち負かすことができる。彼らの選好は、自動的に権利問題を解決したり、IETF が外部の政策事項を決定することを許可したりするものではない。
市場採用は強制、慣性、切り替えコストを隠すことができる
標準コミュニティはしばしば展開を遡及的な投票として使用する。プロトコルが広がれば、市場がそれを選択したと言われる。これは有益であり得るが、ガバナンスには単純すぎる。
採用は、メカニズムが技術的に優れているために発生することがある。また、主要プラットフォームがデフォルトで有効にした、調達要件がそれを指定した、支配的なベンダーがバンドルした、インストールベースが代替を高価にしたために発生することもある。ユーザーはプロトコル選択が見えないサービスを採用することがある。オペレーターは、調整された交換が継続的な露出よりもリスクが高いため、弱いメカニズムを保持することがある。互換性圧力は、ネットワークレベルでの自発的な遵守を、個々のアクターにとって実質的な強制に変えることができる。
これらの経路は、展開証拠が標準決定に使用されるときに重要である。ワーキンググループは、採用が利益を示すのか、それとも単なる依存を示すのかを尋ねるべきである。誰が選択したか、誰が支払ったか、誰が退出できたか、誰が相談されなかったかを特定すべきである。10億のエンドポイントはリーチの証拠であり得るが、情報に基づく選好についてはほとんど語らない。
その区別はプライバシーとセキュリティにおいて深刻になる。展開された識別子はオペレーターに有用であり、ユーザーにとっては侵害的であるかもしれない。認証メカニズムは1つの攻撃を減らす一方で、少数のサービスに制御を集中させるかもしれない。フィルタリング信号はネットワーク管理を改善する一方で、スピーチやアクセスに負担をかけるかもしれない。コードはいくつかの効果を測定できる。コードの存在は、競合する利益がどのようにバランスされるべきかを決定できない。
IETF は技術的外部性を考慮することができ、またそうすべきである。プロトコル設計はプライバシー、セキュリティ、集中化、アクセシビリティ、運用の自律性に影響を与える。それらの影響を検討することを拒否することは、人為的に狭い工学的アイデアだろう。しかし、影響を検討することは、それが現れる社会的領域を規制する無制限の権限を与えるものではない。組織は、その行動をプロトコル設計、相互運用性、安全な運用、定義されたミッションに結び付ける必要がある。
したがって、展開証拠は分解されるべきである。技術的採用、ユーザー選択、オペレーターの必要性、ベンダー配布、法的義務は同義語ではない。それらのすべてに1つの単語を使用する会合は、市場力を工学的真実を装って潜入させる。
ワーキンググループは主張と証拠の台帳を必要とする
実践的な対応は、すべてのドラフトの周りに新しい官僚機構ではない。それは訓練された習慣である：主張を述べ、それを支持または反証できる証拠を特定し、観察されたことの限界を記録する。
実装可能性については、プロトタイプがコアアルゴリズムが妥当なリソース内で実行できることを示すのに十分かもしれない。記録は、省略された機能とテストされていない環境を特定すべきである。明確さについては、独立した実装と差異レポートが重要である。相互運用性については、グループはバージョン、オプション、障害経路のマトリックスを検討すべきである。スケーラビリティについては、制御された負荷テスト、モデリング、実運用測定が必要かもしれない。展開可能性については、アップグレードシーケンス、フォールバック動作、監視、運用コストが重要である。
セキュリティの主張は、敵対的なテストと明示的な脅威モデルを必要とする。プライバシーの主張は、データフロー分析とリンカビリティ、保持、観察者に関する証拠を必要とする。信頼性の主張は、障害インジェクションと回復結果を必要とする。分散化の主張は、ドラフトに記述されたプロトコル役割の数だけでなく、制御ポイントと現実的な集中に関する証拠を必要とする。
各エントリは観察と推論を分離すべきである。「3つの独立した実装がこれらのメッセージを交換した」は観察である。「拡張設計は相互運用可能である」はテストされたバージョンと機能によって制限される推論である。「プロトコルはインターネット規模で動作する」は追加の証拠を必要とするより広い推論である。台帳は距離を可視化する。
グループはまた、否定的で欠落している証拠を記録すべきである。どの実装が停止したか？どの試行が失敗したか？どのオペレータークラスが不在だったか？どのオプション機能に独立したコードがなかったか？どの測定が商業的利益を持つ当事者から来たか？開示は証拠を無効にしない；参加者が知的に重みを割り当てることを可能にする。
最後に、台帳は証拠が決定できないことを述べるべきである。メカニズムがポリシービットを強制できることを示すかもしれない。誰がビットを設定する権利があるかを確立できない。ブロッキング方法がテストコーパスの下で正確であることを示すかもしれない。ブロッキングがすべての法域や文脈で正当であることを確立できない。集中調整が効率を改善することを示すかもしれない。より広い推論なしに集中が許容可能であると決定できない。
この控えめな実践は、ランニングコードをより影響力のあるものにし、より少なくはないだろう。誇張された主張が取り除かれると、証拠は力を得る。
ラフコンセンサスとランニングコードは互いに修正し合わなければならない
RFC 7282はコンセンサスをパーセンテージではなく未解決の問題を中心に枠組みする。異議は受け入れられる必要はないが、対処されなければならない。ランニングコードは、グループが予測された欠陥をテストできるようにするため、特に強力な対処形態を提供できる。また、多数派が異議を誤解したことを明らかにすることもできる。
異議申立人が、2つの許容される状態遷移が互換性のない解釈を生み出すと主張するとする。著者は、すべての合理的な実装が同じ選択をすると答える。2つの独立した実装が異なる選択をする。コードは自動的に正しい遷移を選択しないが、テキストが明確であるという主張を打ち負かす。ワーキンググループは仕様を修正するか、なぜ1つの動作が非準拠であるかを説明しなければならない。
今度は異議申立人が、再試行メカニズムが特定の損失パターンの下で崩壊すると予測するとする。いくつかの実装がテストされ、パターンが再現され、緩和策が現実的な条件の下で保持される。グループは、異議が回答されたと合理的に決定できる一方で、テスト境界を文書化する。異議申立人は、RFC 2026のプロセスを通じてコンセンサスコールに挑戦する権利を保持するが、実質的な拒否権を取得するわけではない。
逆のケースも同様に重要である。支配的な実装は、ドラフトで要求されていない動作を示すことがある。参加者は、それがネットワークが行うことであるため、その動作を標準として説明し始める。ラフコンセンサスは区別を回復できる。グループは、影響と代替案を検討した後、その動作を指定するか、推奨しないか、沈黙するかを決定できる。インストールされたコードは現実に関する証拠であり、修正手続きではない。
議長は、コードが遅れて現れる場合に特に注意すべきである。コンセンサスコールの直前のデモンストレーションは、独立した再現を許可せずに社会的圧力を生み出す可能性がある。実装レポートは、バージョン、カバレッジ、テスト条件を応答に十分な早期に特定すべきである。コードが重要な前提を変更する場合、焦点を絞った問題を再開することは手続き上の弱点ではない。反修辞学的チェックのポイントである。
理想的な相互作用は反復的である。議論は主張を特定する。実装はそれらをテストする。結果はテキストを洗練する。独立した実装は洗練をテストする。展開は追加の条件を明らかにする。コンセンサスは残りの問題を評価し、証拠が十分である理由を記録する。インターネットの条件が変化するため、コードもコンセンサスも恒久的に最終的な言葉を受け取らない。
失敗の証拠は制度的保護に値する
成功は失敗を保存するよりも実証する方が簡単である。相互運用可能な交換を完了したチームは、プレゼンテーションをスケジュールし、リポジトリを公開し、トレースを示すことができる。実装を放棄したチームはレポートを残さないかもしれない。インシデント後に機能を無効にしたオペレーターは、顧客の機密性、セキュリティ露出、または商業的当惑によって制約されるかもしれない。したがって、標準記録は可視的な成功を蓄積する一方で、実際の境界を定義した実験を失う可能性がある。
この非対称性は重要である。なぜなら、1つのよく記述された失敗は、多くの日常的な成功よりも情報価値が高いからである。10の実装が通常の入力を解析し、1つが標準準拠の拡張でクラッシュする場合、関連する質問は成功率ではない。拡張ルールが曖昧か、実装が欠陥か、仕様が危険な状態を許可するかである。いくつかの大規模ネットワークが正常に展開する一方で、小規模アクセスプロバイダーが部分的な障害を診断できない場合、その結果は無視すべき外れ値ではなく、スタッフ規模によって隠された運用負担を明らかにする可能性がある。
ワーキンググループは、すべての欠陥を公開に対する議論に変えることなく、実装と展開の失敗を報告することを安全にするべきである。失敗ノートは、ドラフトバージョン、試行された機能、環境、観測された結果、推定原因、チームが継続するかどうかを特定できる。技術的教訓を保存しながら、機密詳細を保護できる。肯定的な証拠が異常に均一に見える場合、議長は放棄されたアプローチと否定的なテストを明示的に求めるべきである。
組織はまた、証拠の欠如と不在の証拠を区別すべきである。報告された失敗がないことは、メカニズムが堅牢であることを意味するかもしれない。誰も危険な条件をテストしなかった、実装者が1つのライブラリを共有している、成功しなかったチームが会話を去ったことを意味するかもしれない。「どのオペレーターもこの問題を観測していない」という主張は、観測ウィンドウ、参加ネットワーク、測定方法、報告チャネルを特定してから重みを受け取るべきである。
反例も精査を必要とする。失敗したプロトタイプはドラフトを誤読するかもしれない。展開インシデントはプロトコルに関係ない設定から生じるかもしれない。異議申立人は非現実的なワークロードを選択するかもしれない。答えはステータスによる却下ではなく、再現と診断である。他のチームがその動作を生成できるか？仕様はそれを許可するか？その条件は標準がサービスを提供すると主張するネットワークで発生するか？緩和策を記述し、独立してテストできるか？
ここで、実装証拠は制度的不公平を改善できる。影響力の少ない参加者は、雄弁、会議出席、または繰り返しのメーリングリストの存在を通じて勝つために苦労するかもしれない。再現可能な成果物は異議にポータブルな形式を与える。レビューアーはそれを実行し、検査し、結果を比較でき、申立人の評判に完全に依存する必要がない。成果物は判断を排除しないが、部屋から要求される信頼の量を減らす。
失敗アーカイブは決定に接続されたままであるべきである。グループが進む場合、コンセンサス記録は、失敗が再現されたか、どの変更または制限がそれに回答したか、どの不確実性が残っているかを述べるべきである。後の展開が同じ境界に達した場合、将来のレビューアーは条件が予想されたか、仮定が変更されたかを見ることができる。その継続性は、反対を摩擦の瞬間から再利用可能な工学的知識に変換する。
したがって、否定的証拠の制度的保護はランニングコードの伝統の一部である。ポイントは失敗に報いることやすべての実験を永続的にすることではない。洗練された成功のデモンストレーションが唯一のカウントされるコードになるのを防ぐことである。反修辞学的チェックは、批評家とスポンサーの両方が利用できるべきである。
ランニングコードは非技術的政策権限を許可できない
最も強い境界は IETF 自身のミッションから来る。RFC 3935は、IETF はプロトコルまたは機能の所有権を取得するときにそのすべての側面に対する責任を受け入れ、逆に、その問題がインターネットに触れるという理由だけで、責任を持たないプロトコルまたは機能に対して制御を行使しようとしないと述べている。これは近接による管轄権に対するルールである。
プロトコルは必然的に政策と相互作用する。命名は発見可能性に影響する。暗号化は監視に影響する。識別子はプライバシーに影響する。ルーティングとフィルタリングは到達可能性に影響する。標準化されたフォーマットはアクセシビリティと市場参入に影響する。IETF は、これらの結果が非技術的ノイズであるふりをして責任を持って設計することはできない。
しかし、結果は無制限の任務と等しくない。組織はプロトコルの動作方法を指定し、予見可能な影響を特定し、より安全なデフォルトを選択し、インターネットを悪化させる設計を拒否できる。ソフトウェアがそれらの主題に関連するルールを実装できるという理由だけで、雇用、刑法、プラットフォームモデレーション、競争、国家安全保障、人権裁定に対する権限を導出することはできない。
ランニングコードは、実装が不可避性のオーラを作り出すため、越権への橋として特に危険である。メカニズムが存在すると、参加者は「これを構築できる」から「標準化すべき」へ、そして「IETF が基礎となる政策を決定した」へ移行することがある。各ステップは別個の正当化を必要とする。実現可能性は望ましさを証明しない。標準化は法的命令を作成しない。技術的コンセンサスはすべての外部の正当性問題を解決しない。
同じ境界は IETF を捕獲から保護する。ベンダーは展開コードを持って到着し、市場の成功の認識として標準ステータスを要求できない。政府は機能する制御メカニズムを提示し、実装を政策が標準化レイヤーに属する証拠として扱うできない。オペレーター連合は、インフラ所有権を異なる利害を持つユーザーに対する権限に変換できない。
提案が重要な非技術的効果を持つ場合、ワーキンググループはその技術的目標を特定し、影響を受ける当事者を特定し、代替案を検討し、選択された動作が憲章とミッションの範囲内である理由を説明すべきである。通常のサークルの外から有能な入力を求めるべきであり、立法府になるふりはしない。出力はプロトコル要件を展開政策や法的義務から区別すべきである。
それは臆病ではない。制度的な能力である。組織は正当に行使できない権限を拒否することによって、その技術的権威を強化する。
プレッシャー下の会合のための3つの繰り返しテスト
最初に、洗練されたテキストと実装のない提案を考える。コードの欠如は現在の IETF 慣行の下で自動的に致命的ではない。ワーキンググループは、実装がなぜ欠けているか、提案がこの段階で実装可能か、どのリスクが推測的なままか、提案された成熟度レベルでの公開が適切かを尋ねるべきである。作業を進めたり、プロトタイプを求めたり、Experimental ステータスを選択したり、主張を狭めたりするかもしれない。答えは儀式ではなく証拠に依存する。
次に、著者によって制御された1つの実運用展開を持つ提案を考える。これは実現可能性と関心の意味のある証拠である。独立した読みやすさと相互運用性の弱い証拠である。グループはコードの出所、ドラフトバージョン、機能カバレッジ、運用条件、他の実装者が動作を再現できるかを検討すべきである。実際の経験を却下することと、1つの展開を義務として扱うことの両方に抵抗すべきである。
最後に、係争中の外部性を作り出す広く展開されたメカニズムを考える。グループは展開を無視すべきではない。なぜなら、メカニズムを置き換えることは深刻な互換性コストを課す可能性があるからである。また、インストールベースが政策問題を終わらせると言うべきでもない。現在の依存関係、技術的代替案、移行経路、影響を受ける利害、IETF 権限の正確な範囲を文書化すべきである。レガシーの重みは工学的分析に属し、王座にはない。
これらのテストは一貫した方法を示している。どのような主張が行われているか尋ねよ。コードが実際に何を示しているか尋ねよ。誰が証拠を生産し制御しているか尋ねよ。どの環境と影響を受ける当事者が欠けているか尋ねよ。提案された決定が組織の技術的責任の範囲内にとどまるか尋ねよ。何が結論を変えるか尋ねよ。
結果は依然として争われるかもしれない。標準化作業は不確実性の下での判断を含む。目的は裁量を排除することではなく、それを証拠に答えさせ、ミッションによって制限することである。
信条のより良い意味
ランニングコードの永続的な価値は、ソフトウェアが人間よりも真実であることではない。ソフトウェアは人間の仮定、インセンティブ、エラー、権力を具現化する。その価値は、実行が散文が先延ばしにできるいくつかの主張を結果にさらすことである。他者が検査、テスト、比較、破壊できる成果物を作り出す。
成熟したワーキンググループは、お守りではなく証拠の連鎖を求めるべきである。明確なテキストは独立した実装を可能にする。独立した実装は共有された意味をテストする。相互運用性は調整をテストする。展開は運用適合性をテストする。多様な展開は、結果がスポンサーの環境を超えて生存するかどうかをテストする。公開された推論はそれらの事実を決定に結び付ける。
各ステップで、組織は支持と権威の区別を保持すべきである。ランニングコードは、設計が理解可能、相互運用可能、回復力がある、または有用であるという発見を支持するかもしれない。異議が単に理論的であるという主張を打ち負かすかもしれない。好ましい提案を修正または放棄することを正当化するかもしれない。移行が技術的に可能であることを確立するかもしれない。
大規模な展開者が小規模ネットワークを代表することを示さない。ユーザーを同意当事者に変えない。ベンダーのデフォルトをコミュニティ決定にしない。ワーキンググループが、執行が効率的であることを示すことによって権利に関する異議を回避することを許可しない。パケットによって触れられるすべての社会的問題に対する IETF の制御を拡大しない。
ラフコンセンサスはコードに欠けているオープンな判断を供給する。ランニングコードはコンセンサスに欠けている実践的な摩擦を供給する。RFC 2026は公平性、明確さ、テスト、タイムリーさの目標を追加する。RFC 3935はミッションとスコープを供給する。RFC 7942は、実装証拠を推奨に変えることなく記述する透明な方法を提供する。一緒に、これらの資料は要求が厳しいが制限された原則を支持する。
主張を実行させよ。独立したシステムを出会わせよ。展開条件を可視化せよ。そして、証拠が実際の質問に答え、IETF がそれを決定する権限があるかどうかを尋ねよ。ランニングコードは優れた証人である。それは主権者ではない。
証拠と分析の限界
RFC 7282は、1992年の信条の歴史的属性と、ラフコンセンサスを投票集計ではなく未解決の問題への注意として分析することを支持する。それは情報提供であり、原則を説明する；必須の実装閾値を確立したり、実装者に決定権を付与したりするものではない。
RFC 2026は、標準化プロセス目標、事前の実装とテストの重要性、成熟した標準と独立した相互運用可能な実装および運用経験との関連付けの説明を支持する。現在の標準化プロセスは後の RFC によって更新されているため、記事はすべての元の成熟度ルールを変更されていないものとして扱っていない。
RFC 3935は、IETF のミッション、オープンプロセスと技術的能力の原則、実際の実装と展開経験の役割、標準の価値としての相互運用性、プロトコル所有権によって提供される境界を支持する。工学的証拠と非技術的権威の区別は、それらの述べられた原則からの制度的推論である。
RFC 7942は、オプションの実装状況セクション、その推奨内容、その利点と限界、コードが明確な仕様を置き換えてはならないという警告の説明を支持する。ここで提案された主張と証拠の台帳は、分析的な推奨であり、既存の IETF 要件ではない。
ワーキンググループに関する IETF ガイドは、議長がラフコンセンサスを決定し、投票は正式な投票ではなく、少数派の懸念は受け入れられない場合でも対処されなければならないという現在の公開説明を支持する。記事は、すべてのワーキンググループが実装証拠を同じ方法で適用する、またはすべての展開レポートが独立して検証されると推論していない。