要約
- IETF の「動作するコード」の伝統は証拠の規律である。実装により、曖昧なテキスト、互換性のない前提、欠落したエラーハンドリング、機能しないステートマシン、誤ったパフォーマンス期待が明らかになる。独立したコードベース間の相互運用性は1つのデモンストレーションよりも強力な証拠であり、実際の展開はさらに強力である。
- ラベルは重要である。IETF コードスプリントは、Datatracker、Mailarchive、および標準コミュニティが使用するその他のツールを改善する。IETF ハッカソンは、既存および進化中の標準を実装またはテストする。相互運用性イベントは、複数の実装の組み合わせを実行する。ワーキンググループ、IETF ラストコール、IESG が標準に関する決定を処理する。ある活動への参加が、他の活動からの権限を黙って移譲することはない。
- ハッカソンチームは、チャンピオン、コード、設備、参加可能なメンバーがいるプロジェクトの周りに自己選定される。その結果は、明示された条件下での実現可能性を確立できる。しかし、プロトタイプを持たない事業者、間接的に影響を受けるユーザー、エンジニアをリリースできない企業、異なる要件を持つ管轄区域、移行コストと機会費用が実験室でのパフォーマンスを上回る組織を代表するものではない。
- 適切な対応は、動作するコードを弱めることではない。各成果が裏付ける主張にラベルを付け、実装の独立性と適用範囲を開示し、成功だけでなく失敗も公開し、テスト結果をワーキンググループの未解決の問題に結び付け、実装の勢いを幅広い受容として扱う前に、運用上、経済上、権利上、移行上の個別の証拠を要求することである。
「コードスプリント」は非常に異なる権限を持つ活動をカバーする
この言葉は決定的に聞こえる。グループが集まり、ソフトウェアを書き、システムを接続し、バグを修正し、標準会議が始まる前に結果を提示する。仮説的な動作についての長い議論と比較して、コードは現実を提供するように見える。「実装が機能した」から「プロトコルの選択が検証された」へ、そしてそこから「コミュニティがその選択を受け入れた」へと直接移行したくなるかもしれない。
その連鎖は、異なる制度と異なる主張を混同している。IETF は、集中コーディング活動の少なくとも3つの関連する形態を使用している。ツールチームが主催するコードスプリントは、IETF 自身のオープンソースインフラストラクチャ（Datatracker、Mailarchive、xml2rfc、および仕様の開発と公開に使用されるその他のサービス）に取り組む。コードスプリントへの貢献は、制度の運用を改善する。通常、ネットワークプロトコルが技術的に健全であるか、展開されるべきかについては何も述べない。
2015年に初めて開催された IETF ハッカソンは、既存または進化中のインターネット標準の実装を中心に、開発者と専門家を集める。チームはプロトタイプを作成し、オープンソースプロジェクトにプロトコル機能を追加し、組み合わせをテストし、テストハーネスを改善し、ドラフトを明確化し、問題を再現することができる。これらの結果は、ワーキンググループの議論に直接つながる可能性がある。
相互運用性イベントはさらに狭い。定義された条件下で2つ以上の実装を接続し、それらが仕様を互換的に解釈するかどうかを発見する。そのようなイベントは、ハッカソン内、その隣、または他の場所で発生する可能性がある。その証拠力は、独立性、適用範囲、環境、テスト設計、および結果の透明性に依存する。
標準権限は他の場所にある。ワーキンググループは問題を検討し、おおまかな合意を求める。IETF ラストコールは提案された行動をより広いレビューにさらす。IESG は公開とステータスを評価する。メーリングリストは、コーディングルームにいなかった人々のための経路を保持する。実装者は非常に重要な証拠を提供するが、イベント名簿は会員名簿ではなく、結果発表は投票ではない。
この分類は衒学的ではない。コードスプリントがハッカソンと混同されると、制度ソフトウェアのメンテナンスが修辞的にプロトコルの正当性に結び付けられる可能性がある。ハッカソンがワーキンググループと混同されると、週末にコードをまとめることができる人々が仕様を決定しているように見える可能性がある。相互運用性が展開と混同されると、制御されたテストが数年分の運用、経済、ユーザー体験に取って代わる可能性がある。
したがって、タイトルの警告は精度から始まる。集中コーディングへの参加は、実際に実行された作業に関する主張を権限付ける。一般的なプロトコルの権限を与えるものではない。
動作するコードは反修辞学的チェックである
実装証拠のケースは強力である。仕様は自然言語と形式言語で書かれた抽象化である。著者は、2つの実装が同じように動作すると信じることができるが、同じ仮定を暗黙のうちに保持している可能性がある。ステートマシンは紙の上では完全だが、メッセージが遅延、並べ替え、重複、または失われた場合に失敗する可能性がある。フィールドは構文的に定義されているが、一貫して入力することが不可能な場合がある。エラー動作は誰もが明白だと想定するために省略されるが、2つのコードベースが反対のデフォルトを選択するまで。
コードを書くことは選択を強制する。独立したコードベースを接続することは、それらの選択が一致するかどうかを明らかにする。それらを通じてトラフィックを実行すると、議論だけでは明らかにならないリソース使用、タイミング、相互作用、障害回復、エッジケースが明らかになる。実装の失敗は、成功したデモンストレーションよりも価値がある。なぜなら、仕様の信頼がその明確さを超えた正確なポイントを特定するからである。
RFC 3935（IETF ミッションステートメント）は、おおまかな合意と動作するコードを、参加者のエンジニアリング判断と、仕様の実装および展開における実際の経験の組み合わせと説明している。この組み合わせが重要である。実装のない判断は、エレガントだが使用不可能な設計に漂流する可能性がある。合理的な合意のないコードは、たまたま最初に実装した者のニーズを最適化する可能性がある。
動作するコードはまた、ステータスを制約する。ベンダーは機能が簡単であると主張できるが、オープンな実装は予期しない複雑さを示す可能性がある。著者は相互運用性の懸念を却下できるが、再現可能なテストがそれを実証できる。支配的な実装は1つの読み取りを具体化するが、独立したコードベースはドキュメントが別の読み取りを許可することを明らかにする。証拠は議論を評判から行動に変える。
これは、会議に不平等な自信と制度的地位が含まれている場合に特に重要である。失敗したトレースを持つ新人は、直感を持つ上級参加者よりも強力な証拠を持つ可能性がある。小さな実装は、大規模ベンダーに文書化されていない依存関係を説明するよう強制できる。コードは、議論を整理するためのテスト可能な何かを議長やレビューアに提供する。
ガバナンスの誤りは、そのような証拠に過度の技術的重みを与えることではない。それは間違った種類の重みを与えることである。合格したテストは、その設定によって制限された命題の証拠である。それは、影響を受けるすべての当事者からの同意、収益性の高い展開の証明、または権利とインセンティブの完全な評価ではない。
実現可能性、相互運用性、展開、受容は異なる発見である
有益な証拠のはしごは実現可能性から始まる。1つの実装が提案された動作を実行する。これは、少なくとも1つのチームが1つの環境で仕様のバージョンをコードに変換できたことを証明する。また、パフォーマンスや複雑さを明らかにする可能性がある。別のチームがテキストを同じように読むことを証明するものではない。
次の段は独立した実装である。決定的な実装の選択を共有せずに構築された2番目のコードベースは、成功が一般的な文書化されていない仮定から生じた可能性を減らす。独立性は、異なる製品名によって確立されるわけではない。同じライブラリの2つのラッパー、1つのリポジトリからの2つのフォーク、または同じ参照コードを使用する2つのチームは、解釈の多様性なしに名目上の多重性を生み出す可能性がある。
相互運用性はより強力である。独立した実装が有効なメッセージを交換し、実行された機能全体で意図された機能を達成する。テストでは、バージョン、オプション、トポロジ、データ、期待される結果、失敗、およびカバーされていない機能を特定する必要がある。ハッピーパスのデモンストレーションは、エラー回復、セキュリティ特性、スケール、またはオプションの組み合わせを確立するものではない。
運用経験は、期間と環境を追加する。コードは、実際のルーティングポリシー、トラフィック分布、アップグレード、停止、監視システム、ハードウェアのバリエーション、ミドルボックス、スタッフ手順、顧客の期待の中で実行される。事業者は、障害が診断可能かどうか、ロールバックが機能するかどうか、状態を移行できるかどうか、機能が既存のシステムと安全に相互作用するかどうかを発見する。
展開の幅は多様性を追加する。1つのハイパースケールネットワークで機能するプロトコルは、アクセスプロバイダー、エンタープライズ、コミュニティネットワーク、モバイル事業者、公共部門環境、または小規模ホスティング会社には適合しない可能性がある。最新の機器で検証された機能は、交換サイクルの長い既存のベースでは経済的でない可能性がある。幅は普遍的な採用を必要としないが、成功が1つの組織のアーキテクチャに依存しているかどうかをテストする。
受容はさらに異なる。事業者は、プロトコルが技術的に実装可能であることに同意しても、移行コスト、ライセンス条件、責任、プライバシーへの影響、顧客の混乱、または商業関係の変更を拒否する可能性がある。エンドユーザーは、レイテンシが低くなる代わりに、意味のあるコントロールを失う可能性がある。政府ネットワークは、テスト環境にはない法的義務に直面する可能性がある。これらの立場は、実現可能性の反論ではない。それらはそれを超えた結果についての証拠である。
はしごは、過大評価と軽視の両方を防ぐ。プロトタイプは、世界的な採用を証明できなかったことで批判されるべきではない。それが仕事ではなかったからである。また、そのように提示されるべきでもない。各成果は、その主張が正確であるときにより有用になる。
標準プロセスはすでにこれらのレベルを区別している
正式な標準アーキテクチャは、すべての実装を権限として扱うわけではない。2011年に採用されたRFC 6410は、標準化過程を Proposed Standard と Internet Standard に削減した。最初のレベルは、実装経験が蓄積されるにつれてまだ進化する可能性がある。Internet Standard への昇格には、少なくとも2つの独立した相互運用可能な実装と、広範な展開と成功した運用経験、相互運用性を壊すエラッタがないこと、および複雑さを大幅に増加させる未使用の機能がないことが必要である。
これらの基準は、週末の結果よりも厳しい。それらは、実装の複数性を展開と運用に結合する。また、実装されていない機能は、野心の兆候ではなく負債になる可能性があることを認識している。仕様が成熟しているのは、誰かがそれを一度実行したからではなく、独立したシステムが相互運用し、設計が使用に耐え、複雑さが実証されたニーズに対応しているからである。
RFC 7942は、より軽量で初期のメカニズムを提供する。インターネットドラフトには、組織、実装、成熟度、適用範囲、バージョン互換性、ライセンス、経験を説明する実装状況セクションを含めることができる。慣行は推奨されるが必須ではない。ワーキンググループは、情報の使用方法を決定する。議長とエリアディレクターは、セクションがマーケティングの場になるのを防ぐよう求められており、時間に敏感なセクションは通常、RFC 公開前に削除される。
その設計には、重要な制度的保護手段が含まれている。実装状況は審議に情報を提供する。標準に永久的に埋め込まれたバッジではない。推奨されるテキストは、実装のリストが推奨を意味しないと明示的に述べている。ワーキンググループは、実験とフィードバックを適切に考慮しながら、実装が独立しているか、部分的か、最新か、ライセンスされているか、そして目の前の問題に関連しているかを問うことができる。
以前のガイダンスも同様に慎重であった。RFC 5657は、実装名のリストは相互運用性を実証するのに不十分であると警告した。有用なレポートは、相互運用性がどのように確立されたか、何がテストされたか、何が失敗したか、メーリングリストでの明確化が必要だったかどうかを説明する。製品リストと証拠レポートの区別は、まさに参加と証明の区別である。
したがって、IETF はすでに権限のインフレーションに抵抗するために必要な概念ツールを備えている。弱さは、社会的勢いが正式なラベルよりも速く動くときに生じる。混雑したデモンストレーション、磨かれた結果発表、または著名なコードベースによる繰り返しの使用は、運用上および分布上の問題が同等の注意を受けていないにもかかわらず、オプションが決着したように感じさせることがある。
おおまかな合意はラップトップをカウントしない
ワーキンググループの合意は、実装の数やハッカソンのテーブルにいる人々の数によって決定されるわけではない。RFC 7282は、優位性を量や持続性から推測すべきではなく、少数意見に対処しなければならないと説明している。目標は、未解決の問題を特定し、異議を理解し、グループがそれらを検討したかどうかを判断することである。
動作するコードは異議を解決できる。誰かがフィールドを明確に解析できないと主張する場合、独立した実装がそうでないことを示すかもしれない。提案された移行が不可能と言われている場合、プロトタイプは実行可能なメカニズムを特定するかもしれない。パフォーマンスの根拠で2つの設計が議論されている場合、再現可能な測定が推測に取って代わることができる。
コードはまた、異議を解決するのではなく、明確にすることができる。プロトタイプは、特権アクセス、専有コンポーネント、最新のハードウェア機能、または展開制御に関する前提でのみ機能するかもしれない。その結果は、一般的な懸念を特定の境界に変換する。グループは、その境界が許容できるか、削除できるか、文書化する必要があるかを決定しなければならない。
他の異議は、実装だけでは答えられない。事業者は、移行に顧客ベース全体で利用できない調整が必要であると主張するかもしれない。市民社会の参加者は、プライバシーの害を特定するかもしれない。小規模ベンダーは、必須機能がコスト障壁を生み出すことを示すかもしれない。権利保有者はライセンス条件を開示するかもしれない。コードはこれらの主張を明らかにすることができるが、1つのチームがコストを受け入れた、または権利を所有していたという事実は、他のチームにとってそれらに答えるものではない。
イベントからの事業者の欠席は同意ではない。企業からの1人のエンジニアの存在は、その企業、ましてやそのセクターを拘束する権限ではない。IETF の参加者は個人として行動する。所属は文脈を開示するが、貢献を企業投票に変換するものではない。企業が議席を所有するのを防ぐのと同じ原則は、企業に所属する実装者のテーブルが業界の権限になるのを防ぐ。
したがって、議長は成功したデモンストレーションの後に2つの質問をするべきである。この結果はどの技術的問題に答えたか？テストの範囲外にある異議はどれか？2番目の質問を動作するコードへの敵意と誤解することは、証拠の規律を抵抗と間違えることである。
ハッカソン参加は準備状況によって選択される
IETF ハッカソンは無料で開かれており、開発者ではない新人や専門家を意図的に歓迎している。RFC 9311は、その目的をオープンソースコラボレーションを標準活動に持ち込み、開発者やキャリア初期の専門家を IETF に紹介することと説明している。これらは意味のあるアクセス上の強みである。
オープンな登録は、影響を受ける当事者の代表的なサンプルを生み出さない。プロジェクトにはチャンピオンが必要である。チャンピオンはトピックを投稿し、チームを引き付け、リポジトリや機器を準備し、作業を整理する。参加者は、スキル、関心、雇用主の優先順位、利用可能なコード、および進歩の見込みに基づいてプロジェクトを選択する。積極的なチャンピオンと成熟したオープンソースベースを持つテクノロジーは、開発者を派遣できない組織が抱える運用上の懸念よりも、容易に目に見える結果をまとめることができる。
したがって、準備状況は証拠を選択する。実装に最も近いアプローチは、標準テキスト、ハードウェアの変更、調達、またはクロスオペレーターの調整を必要とする代替案よりも、より多くの成果物、デモンストレーション、参加者を生み出す可能性がある。そのため、準備のできたアプローチが間違っているわけではない。それは、目に見えるコードが部分的にその周りにすでに蓄積されたリソースを測定することを意味する。
ベンダーサポートは効果を増幅する可能性がある。会議の前に実装を構築するためにエンジニアに支払う企業は、コード、テストの専門知識、機器、および時間を持って到着する。独立した開発者が参加して改善することができるが、初期のアーキテクチャは利用可能なタスクを形作る。小規模な競合他社は技術的に同意しても、イベントのスタッフを欠く可能性がある。事業者は関心があるが、本番機器を公開できない可能性がある。ユーザーグループは、もっともらしいコーディングプロジェクトを持たずに結果を経験する可能性がある。
イベント形式はまた、境界のあるタスクに報いる。パーサー、テストベクトル、プロトコルオプション、相互運用性修正は、数時間で進捗を示すことができる。コスト配分、プライバシー、長期的な保守性、市場依存性には異なる方法が必要である。それらは、展開が正当かどうかを決定する場合でも、迅速な結果発表に現れる可能性が低い。
これらの選択効果は結果を無効にするものではない。それらは結果が生じる母集団を定義する。情報源を認識するワーキンググループは、誰が実装したか、どのリソースが共有されたか、コードベースが真に独立していたか、どの影響を受ける役割が欠席していたかを記録するべきである。これにより、参加は暗黙の権限から透明な証拠の文脈に変わる。
最初のハッカソンは価値と境界を示した
最初の IETF ハッカソンは、2015年の IETF 92の前に約50人の参加者で開催された。イベントは急速に成長した。2018年のロンドンでの IETF 101までに、公式報告では約220人の現地参加者と20人のリモート参加者が35のプロジェクトに参加した。TLS 1.3の作業は、進化する仕様と並行して開発される実装の顕著な例を提供した。
IETF 101ハッカソンの報告は、2016年から2018年の仕様承認まで繰り返される TLS 1.3プロジェクトを説明している。価値は技術的だけでなく時間的でもあった。実装者は RFC を待たずに曖昧さと相互運用性の問題を発見できた。フィードバックは選択肢が開かれている間にドキュメントを改善することができた。
これがコードと標準の近接性の最も強いケースである。公開後に構築された実装は、修正が高価なときに欠陥を明らかにする可能性がある。並行実装は、インストールされたシステムがそれに依存する前に、ドラフトを現実に答えさせる。複数のチームは、改訂が互換性を壊すかどうか、拡張ポイントが意図したとおりに動作するかどうかをテストできる。
しかし、ケースは依然としてハッカソンを主権者にしない。TLS 1.3が重要になったのは、プロジェクトテーブルが出会ったからではない。その仕様は、ワーキンググループの開発、レビュー、ラストコール、IESG のアクションを受けた。実装とその後の展開が証拠を提供した。ブラウザ、サーバー、ライブラリ、コンテンツプロバイダー、エンタープライズ、事業者の決定が採用を提供した。セキュリティ分析と実際の使用は公開後も続いた。
イベントの貢献はインフレーションなしに述べることができる。仕様と実装フィードバックの間の距離を短縮した。欠陥の検出、明確さの改善、実装者の接続、独立したコードが進化する設計に従えるという自信の創出に役立った。これらは主要な成果である。
確立できなかったのは、すべての結果の普遍的な受容である。部屋にいなかった組織は、いつ展開するかをまだ決定した。既存のインフラストラクチャとの互換性はまだ重要だった。セキュリティ特性は、成功したハンドシェイクを超えた分析をまだ必要とした。実装間の市場集中は別の問題のままだった。
動作するコードの成熟した説明は、フィードバックループを祝福しながら、後の各テストを保持する。TLS 1.3からの教訓は、ハッカソンがプロトコルを承認できるということではない。タイムリーな実装証拠が承認された標準プロセスをより良くできるということである。
L4S 相互運用性イベントは主張ラベルが重要な理由を示す
2022年の IETF 114ハッカソンは、異常に具体的なケースを提供する。L4S 相互運用性イベントには、15の組織から32人のエンジニアが集まった。公式イベント報告によると、DOCSIS、Wi-Fi、5G のコンテキストにわたる7つのネットワーク機器実装全体で、5つの輻輳制御アルゴリズムの組み合わせをテストした。チームはバグを発見して修正し、パラメータを調整し、初期のベンチマークを生成した。報告された1つの結果は、テストされた条件下で、Cubic フローと比較してパケット遅延変動の最大50倍の削減を示した。
これは高価値の実装証拠である。複数のコードパス、複数の組織、いくつかのアクセステクノロジー、直接テストが含まれている。広範な展開の前に発見されたバグは公共の利益である。パラメータ調整と実装経験は、仕様と展開ガイダンスを改善できる。チームは、イベントを孤立したショーケースとして扱うのではなく、関連するワーキンググループに結果を提供した。
同じ事実が境界を定義する。「最大」は観察された最良の結果を特定し、普遍的な効果ではない。4日間のイベントは、すべてのトラフィックミックス、キュー構成、レガシーデバイス、運用ポリシー、障害モード、インセンティブを再現することはできない。15の組織は1つのベンダーよりも実質的に広いが、すべてのアクセスプロバイダー、アプリケーション開発者、機器ベンダー、規制当局、公共ネットワーク、輻輳動作の影響を受けるエンドユーザーではない。
イベント報告はプロジェクトの要約であり、独立した監査ではない。それは信頼性を損なうものではない。読者が一般化する前に、テスト定義、構成、生の測定値、コードバージョン、失敗した組み合わせ、フォローアップの展開証拠を必要とすることを意味する。結果発表は進捗を迅速に報告するように設計されている。標準決定は、イベントが何をテストしなかったかを尋ねるべきである。
商業的な結果もベンチマークの外部にある。事業者は、機器サポート、アップグレードの順序、監視、トラブルシューティング、顧客機器、容量ポリシー、スタッフトレーニング、共存を評価しなければならない。ベンダーはどのアルゴリズムを維持するかを決定しなければならない。アプリケーション開発者は、アクセスネットワークとは異なるインセンティブに直面するかもしれない。ユーザーは、トラフィックと展開の選択に応じて利益または害を経験するかもしれない。
正しい解釈は、「イベントがすべての人に L4S を証明した」でも「イベントは単なるデモだった」でもない。指定された組み合わせが実装され実行可能であり、欠陥を露呈し、限定的なパフォーマンス証拠を生成したことを証明した。欠席した事業者に代わって話すことも、技術的成功を展開する義務に変換することもなかった。
動作する実装は運用上不完全なままである可能性がある
プロトコルコードは通常、サービスの内部にある。事業者は、インストール、設定、監視、アラーム、ロギング、ロールバック、容量計画、セキュリティ対応、会計、スタッフ手順を必要とする。パケット交換は成功しても、サービスを安全に大規模に実行することは不可能なままである可能性がある。
RFC 5706は、運用および管理の考慮事項がしばしば遅すぎるため書かれた。展開が議論されたかどうか、仕様が運用上スケールするかどうか、共存がどのように機能するか、正しい運用がどのように検証されるか、どのメトリクスが重要か、プロトコルが新しい依存関係やトラフィック効果を生み出すかどうかを尋ねる。これらは「本当の」プロトコルの後の飾りではない。それらはプロトコルが維持可能かどうかを決定する。
ハッカソンは、プロジェクトがそのために設計されていれば、これらの質問の多くをテストできる。チームはテレメトリを構築し、障害を注入し、ダウングレードとロールバックをテストし、設定エラーを実行し、実装間の監視を比較できる。問題は会場ではない。典型的な成功パスからの推論である。緑のデモンストレーションは、診断、回復、コストよりも到達可能性と基本機能をより明確に答えていることが多い。
スケールは別のギャップを生み出す。機能は少数のエンドポイント間で機能するが、数百万にわたって状態、CPU、メモリ、シグナリング、サポートの負担を生み出す可能性がある。テストのハードウェアは最新かもしれない。展開されたハードウェアは10年間サービスを続けるかもしれない。事業者は、イベントにないベンダーの組み合わせを持つかもしれない。著者にとって単純な設定は、分散運用チーム全体で危険かもしれない。
したがって、運用証拠は環境と期間を特定しなければならない。いくつのノードが実行されたか？どのようなトラフィックと障害があったか？どの監視が障害を検出したか？ロールバックは試みられたか？独立したチームは仕様から機能を設定したか？既存のサービスは中断されたか？どのような人的介入が必要だったか？何がテストされていないままか？
実装報告は、失敗が保存されるときにより強力になる。チームが文書化されていないフラグ、メーリングリストでの明確化、専門家の支援を必要とした場合、それは恥ずかしいノイズではない。それは通常の展開が同じ障壁に直面するかもしれないという証拠である。それを記録することで、ワーキンググループはテキストを改善し、事業者は採用を正直に価格設定できる。
動作するプロトコルと運用可能なサービスの違いは、欠席した事業者の関心の多くが存在する場所である。
展開はパケットだけでなくインセンティブによっても支配される
技術的な互換性は、採用を自動実行しない。組織は、独自の制約の下で便益がコストを上回るときに展開する。それらのコストには、エンジニアリング、ハードウェア、サポート、トレーニング、法的レビュー、顧客コミュニケーション、調整、およびピアが互換性がないまま早期になるリスクが含まれる。
RFC 8170は、移行計画を別個の分野として扱う。信頼できる計画は、既存の展開を理解し、関連する各エンティティのインセンティブを説明し、フェーズと成功基準を定義し、失敗のための緊急時対応を提供し、影響を受けるエンティティと通信するべきである。ドキュメントは特に、障壁が非技術的であり、運用慣行、人員トレーニング、会計、請求、法律、規制のインセンティブを含む可能性があると述べている。
これがプロトタイプの支持者が見えるようになるポイントである。コードを書く人々は直接的な利益を受け取るかもしれない。新しい機能、よりクリーンなアーキテクチャ、製品機能、研究結果、または実装の不確実性の低減。事業者は移行プロジェクトを受け取るかもしれない。顧客はより良いパフォーマンスを受け取るが、互換性リスクに直面するかもしれない。小規模ベンダーは、単に代替可能であり続けるために複雑な機能を実装する必要があるかもしれない。
RFC 5218は、技術的品質とプロトコルの成功を同様に区別する。実装の可用性、使用制限、ビジネスモデル効果、コスト、インセンティブと展開の適合性について議論する。自由に利用可能なコードは採用を大幅に改善できるが、利用可能な実装はすべての運用上または商業上の障壁を取り除くわけではない。
したがって、ワーキンググループは、プロトコルが組織境界を越えて動作を変更するときにインセンティブマップを要求するべきである。どのアクターが最初にアップグレードしなければならないか？利益が現れる前に誰が支払うか？展開は段階的に可能か？1つのアクターが別のアクターにコストを課すか？ロールバックは利用可能か？支配的なベンダーのみが実装するとどうなるか？参照コードは参入コストを削減するか、1つのアーキテクチャを固定化するか？
これらの質問は、IETF がビジネスモデルを規制することを必要としない。技術的主張を正直に保つ。成功に調整または補助金が必要な場合、仕様は十分なリソースを持つチームがそれを実装したことを示すことだけによって防御されるべきではない。インセンティブが IETF の能力の範囲外にある場合、その限界は受容の仮定によって埋められるのではなく、見えるようにされるべきである。
コードは知的財産権を解決しない
実装は実行できるが、その実行権限は不確かなままである。チームはライセンスを所有しているか、オープンソースの許可に依存しているか、特許機能を回避しているか、単に請求が存在することを知らないかもしれない。技術的成功と法的自由は別個の命題である。
RFC 8179は、定義された状況での開示を要求し、ライセンス情報がワーキンググループの評価に情報を提供することを許可する。また、IESG、IAB、Internet Society、IETF Trust がすべての関連権利を特定したり、適用可能性を評価したり、有効性と範囲について立場を取ったりしないと述べている。実装者は、利用可能な開示やその他のアドバイスを使用して法的および商業的な決定を行う。
この境界は、権限の主張を直接制限する。2つの実装の存在は、必ずしも2つの独立した当事者が許容可能な条件で出荷、配布、運用、維持するための耐久性のある権利を所有していることを意味しない。したがって、RFC 6410は、Internet Standard に制御技術が必要な場合、ライセンスプロセスの少なくとも2つの独立した別個の成功した使用を要求する。それは2つの合格したテスト実行以上である。
オープンソースコードは役立つが、分析を崩壊させない。リポジトリライセンスは、その条件の下でコードの著作権許可をカバーする。第三者の特許、商標、データ権利、輸出管理、契約上の依存関係を自動的に解決するものではない。寛容な参照実装はまた、法的に敏感なメカニズムを回避するオプションパスを含む場合があり、名目上の実装証拠を完全なカバレッジに対して誤解させる。
したがって、ハッカソン報告には、RFC 7942が推奨するようにライセンスとカバレッジを含めるべきである。コードは関連機能を実装したか？どのソフトウェアライセンスの下で利用可能か？クリーンな独立した実装か、それとも派生か？既知の IPR 開示はリンクされているか？成功した相互運用性は制御技術に依存していたか？これらは証拠の質問であり、イベントによる法的判断ではない。
権利はまた、実装者を超えて広がる。プロトコルは、すべてのソフトウェアライセンスが明確であっても、ユーザーのプライバシー、コントロール、アクセス、データフローに影響を与える可能性がある。RFC 8890は、技術的决定がいくつかの使用を可能にし、他を阻害し、IETF は参加者の経験がすべてのエンドユーザーを代表すると想定するのではなく、影響を受けるコミュニティに相談すべきであると警告している。
コードは何が可能になるかを実証できる。成功裏に実行することによって、有効なすべての使用が正当であるかを決定することはできない。
欠席した事業者は黙認の承認ブロックではない
ネットワーク事業者は、単一の構成員であるかのようにしばしば呼び出される。「事業者はこれが必要」「事業者はそれを展開しない」「運用コミュニティは代表されていた」。実際には、アクセスネットワーク、クラウドプロバイダー、エンタープライズ、モバイルキャリア、交換所、公共ネットワーク、コミュニティネットワーク、小規模ホスティング会社は、異なる機器、インセンティブ、規制、顧客に直面する可能性がある。
1つの事業者の実装は、その環境に関する貴重な証拠である。すべての事業者についての声明を許可するものではない。テストイベントの10の事業者は、特にアーキテクチャが異なる場合、より広い証拠を提供する。それでも非参加者を拘束しない。IETF の個人参加原則はこれを特に明確にする。人々は専門知識を貢献する。組織票を投じるわけではない。
欠席には多くの意味がある。事業者は旅行やスタッフの予算を欠いているか、提案を時期尚早と見なすか、ベンダーのロードマップに依存するか、システムを公開できないか、インシデントとサービス継続に集中するかもしれない。小規模ネットワークは、展開効果を負担するにもかかわらず、プロトコル開発者を持たないかもしれない。沈黙は満足、無関心、リソース不足、または無知を反映する可能性がある。同意に安全に変換することはできない。
これはワーキンググループに実用的な負担を生み出す。影響を受けるすべてのネットワークが参加するのを待つことはできない。また、すでに存在する人々から広範な運用受容を宣言することもできない。彼らは対象を絞った証拠を必要とする。運用エリアのレビュー、関連する事業者フォーラムへの働きかけ、制限を明記した展開調査、実装と移行報告、文書化された異議は、ハッカソンにはない条件を露出させることができる。
標準自体は自発的なままである。RFC 3935は、IETF 標準を、適合を主張する場合に何かを行う方法の説明として定義しており、IETF が使用を義務付けたり、展開を取り締まろうとする試みではない。その原則は、越権に対する保護であり、採用の源泉についての声明である。事業者は、実装者が十分なテーブルを占めたからではなく、展開決定、契約、規制、顧客需要、相互接続のニーズを通じてプロトコルを受け入れる。
自発的なステータスは、IETF の選択を無害にするわけではない。支配的なプラットフォームが採用し、調達がそれを要求し、規制がそれを組み込むとき、標準は商業的に避けられなくなる可能性がある。そのため、ワーキンググループは市場の勢いが固まる前に欠席した事業者を考慮すべきである。しかし、後の外部の力は、ハッカソンが権限を提供したという主張にさかのぼって日付を付けるべきではない。
エンドユーザーはコーディングテーブルから遠い
多くのプロトコルはエンドユーザーに直接見えない。ルーティング変更、名前解決メカニズム、トランスポート機能、認証形式、管理プロトコルは専門家によって実装されるかもしれない。影響を受ける人は、どの標準がレイテンシ、プライバシー、アクセシビリティ、セキュリティ、スイッチングコスト、サービス可用性を形成したかを決して知らないかもしれない。
RFC 8890は、この距離を責任として扱い、ユーザーを無視する許可として扱わない。IETF はエンドユーザーにとって何が良いかについて独自の洞察を持っておらず、特に決定が彼らを害する可能性がある場合、影響を受けるコミュニティと関わるべきであると述べている。また、政府参加者や市民社会組織が自動的に管轄区域または大義のすべてのユーザーを代表するという想定を拒否する。
ハッカソンチームは、ユーザー擁護者や専門家を含むことができる。プライバシー漏洩、ユーザビリティ、アクセシビリティ、スイッチングのためのテストを構築できる。これは証拠を広げる。しかし、ユーザーは通常、明確な成功シグナルを持つ実装可能なエンドポイントとして現れない。機能は、すべてのパケットテストに合格しながら、コントロールを集中させ、監視を増加させ、退出を高くする可能性がある。
違いは能力と福祉の間である。コードはメカニズムがアクションを実行できることを証明する。速度、失敗、互換性を測定するかもしれない。アクションがユーザーに役立つかどうかは、誰が利益を得るか、誰がさらされるか、どの代替案が残っているか、コントロールがどのように行使されるかのモデルを必要とする。これらは反技術的な質問ではない。それらはコードが現実にするアーキテクチャに関するものである。
影響を受けるコミュニティはまた、翻訳コストに直面する。ワーキンググループは、彼らに進化するドラフトを読み、長いリストに従い、リポジトリの周りに組織されたイベントに参加するよう求めることができる。その招待は正式には開かれているが、実際にはアクセスできないかもしれない。アウトリーチは、結果をコミュニティの言葉でフレーム化し、まだ開かれている選択肢を特定し、フルタイムのプロトコル著者にならずに証拠を提出する経路を提供すべきである。
実装の勢いは、そうでなければタイミングの罠を生み出す可能性がある。ユーザーが効果を認識するまでに、複数のコードベースと製品が選択された動作に依存する。再検討は高すぎると説明される。反修辞学的チェックとして意図された動作するコードは、経路依存性の源になる。
保護手段は、実装と並行して、その後ではなく、早期の影響分析である。コードが速く進むほど、ワーキンググループは、成功シグナルによって代表されていない利害は誰かと早期に尋ねるべきである。
コードスプリントの権限はさらに狭い
IETF コードスプリントは別個の扱いに値する。その結果は運用上重要であるが、憲法上過大評価しやすいからである。ツールチームは、Datatracker、Mailarchive、ドキュメント作成ツールなどのサービスを改善するためにボランティアを招集する。IETF 114では、18人のコードスプリント参加者が Datatracker と xml2rfc の作業にわたって30以上のプルリクエストを生成し、週を通して貢献が続いた。
これらの変更は参加に実質的に影響を与える可能性がある。検索、アジェンダ、提出、レビュー、アイデンティティ、メタデータ、公開機能は、人々が標準作業を発見し貢献する容易さを形作る。貧弱なツールは排除する。良いツールはコストを下げる。したがって、ツールメンテナーは結果的なエンジニアリング判断を行使する。
しかし、制度プラットフォームにコードを貢献することは、ボランティアにプロトコルコンテンツに対する権限を与えるものではない。関連実装を記録する機能は、証拠の可視性を改善できる。リンクされた実装を推奨するものではない。アジェンダの改善はセッションを読みやすくする。どの技術的提案が合意を持つかを決定するものではない。ドキュメントツールは構文を強制できる。その構文によって表現されるポリシーを決定するものではない。
逆の境界も重要である。ワーキンググループは、コードが存在するという理由だけで、ツールの現在のデータモデルを実質的な制限として扱うべきではない。Datatracker が重要な区別を表現できない場合、答えはツールを改善することであり、制度の推論を利用可能なフィールドに圧縮することではない。インフラストラクチャは、公共の決定に黙って定義するのではなく、奉仕すべきである。
コードスプリントの変更は、それ自身の説明責任を必要とする。レビュー、テスト、セキュリティ、プライバシー、アクセシビリティ、保守性、展開、および IETF サービスに依存する人々からのユーザーフィードバック。権限は、ツールチームの役割と採用されたメンテナンス取り決めから生じ、それらのサービスに限定される。プルリクエストの数から生じるものではない。
コードスプリントとハッカソンの権限を分離することは、両方を強化する。ツール貢献者は、彼らの作業がプロトコル検証として誤って説明されることなく、制度の維持に対して功績を得る。プロトコル実装者は、制度システムを維持していると暗示することなく証拠を報告できる。ワーキンググループは、技術的合意に対して責任を負い続ける。
「動作するコード」というフレーズは、これらの活動を文化的に結びつける。それはそれらの権限を消去しない。
ベンダー集中は実装の複数性の背後に隠れることができる
2つの相互運用する実装は1つよりも強力な証拠であるが、数値的な複数性は共通の支配を隠すことができる。コードベースは、ライブラリ、企業親会社、主要著者、テストスイート、資金源、ハードウェア依存性、商業的インセンティブを共有するかもしれない。真に独立したチームでさえ、市場の同じセグメントを代表するかもしれない。
独立性の目的は認識論的である。異なる実装者は、同じ隠された決定に依存せずにテキストにアプローチするため、曖昧さを露出できるべきである。組織名は不完全なプロキシである。フォークは意味のある分岐ができる。2つの企業製品はほとんどすべてを共有できる。報告は、コードの系統と決定的な依存関係を説明するべきであり、単にロゴを数えるのではない。
市場の多様性は別の質問である。2つの支配的なプラットフォームからのサーバーとクライアントは完全に相互運用するかもしれないが、小規模な実装者は法外な複雑さに直面する。オープンな参照実装はその障壁を下げることができるが、唯一の実用的なコードパスになることもできる。すべての製品がそれを埋め込む場合、プロトコルの相互運用性は高いが、実装の多様性は低いかもしれない。
RFC 9518は、実装と展開の多様性をユーザーのスイッチング能力に結び付ける。技術的に開かれた標準は、代替案の実装や維持が高すぎる場合、集中化をサポートできる。複雑さ、専有拡張、データ優位性、粘着性のある仲介者は、パケット互換性とともに関係する。
したがって、ハッカソンメトリクスは、参加者数、組織数、独立したコードベース数、依存関係の多様性、役割の多様性、最終的な展開の多様性を区別すべきである。どれも単独で正当性を提供しない。一緒に、動作するコードが仕様を複数の方向からテストしているのか、1つの実装ファミリーを繰り返し実行しているのかを明らかにする。
これは大規模ベンダーを排除する議論ではない。彼らのエンジニア、製品、機器、展開データはしばしば不可欠である。懸念はマークされていない集中である。ワーキンググループは、成功したテストが競合する実装、共有コンポーネント、事業者、アプリケーション、制約された環境に及んでいるかどうかを知るべきである。
透明性はまた、ベンダーを不当な推論から保護する。所属は協調を証明せず、スポンサーシップは技術的結果の支配を証明しない。証拠は、すべての従業員を指示された企業代表として扱うのではなく、実際のコードと依存関係を特定すべきである。
ガバナンスの目的は、最初にそれを生み出すのに最も適した組織の外でも生き残るのに十分なロバストな結果である。
失敗は証拠であり、成功とともに伝わるべきである
ハッカソン報告は当然進捗を祝う。チームには限られた発表時間があり、スポンサーや主催者は価値を示したい、参加者は認知に値する。結果は、完了した機能、修正されたバグ、改善されたベンチマークを強調し、失敗した構成、未解決の曖昧さ、セットアップ依存性を圧縮する可能性がある。
標準品質にとって、失敗はより重要かもしれない。相互運用しなかったペアは、仕様または実装の問題を特定する。誰も試みなかった機能は、複雑さまたは需要の欠如を示す可能性がある。機器が利用できずに放棄されたテストは、証拠のギャップを定義する。著者が意図された動作を説明した後にのみ可能であった結果は、テキストが独立して十分でなかったことを示す。
報告形式は、イベントを監査法廷に変えずにこれらの事実を保存すべきである。各プロジェクトは、コンパクトなマトリックスを公開できる。実装と系統、仕様バージョン、試みられた機能、成功した組み合わせ、失敗した組み合わせ、逸脱、必要な明確化、パフォーマンス環境、コードリンク、ライセンス、未解決の質問。チームは、欠落した証拠を成功に変換するのではなく、不明をマークできるべきである。
ワーキンググループの議長は、マトリックスを問題にマッピングできる。どの失敗がドラフトテキストを必要とするか？どれがコードバグか？どれが展開の前提を露出させるか？どれが依然として議論の余地があるか？会議はハイライトスライドだけを受け取るべきではなく、非同期でレビューできる一連の主張を受け取るべきである。
否定的な結果はまた、実装の劇場を防ぐ。磨かれたデモンストレーションだが狭い適用範囲のプロジェクトは、根本的な困難を発見したプロジェクトよりも上位にランクされるべきではない。RFC 3935は、失敗した実験が特別な場合にのみ有用な技術的に有能な標準よりも関連性がある可能性があると明示的に認識している。
長期的なフォローアップが重要である。イベントからの修正はリリースされたコードに入ったか？仕様は変更されたか？後の実装は結果を再現したか？展開は異なる失敗を露出させたか？1回限りの報告は瞬間を確立できる。標準の成熟度は、その後何が生き残るかに依存する。
「動作するコード」というフレーズには、クラッシュした、同意しなかった、過剰な状態を消費した、または設計が非経済的であることを証明したコードを含めるべきである。現実は、不便な結果が可視のままであるときに最も効果的に標準を制約する。
証拠台帳は権限インフレーションを防ぐべきである
すべての実装の主張は、5つの境界を特定すべきである。
第一に、命題。作業は正確に何を実証したか？例としては、解析可能性、機能カバレッジ、相互運用性、指定された負荷の下でのパフォーマンス、障害回復、移行、展開。1つのパスのみが実行された場合、「動作する実装」は広すぎる。
第二に、母集団。どのコードベース、組織、役割、ネットワーク、ユーザーが代表されたか？独立性とコードの系統を説明すべきである。欠席は、反対または同意として扱うのではなく、役割ごとに記録すべきである。
第三に、環境。どのハードウェア、トポロジ、トラフィック、バージョン、設定、期間、サポートが必要だったか？チームは著者の支援なしに公開資料から結果を再現できたか？失敗とテストされていない機能は保持されたか？
第四に、結果。どの運用上、経済上、法律上、プライバシー上、セキュリティ上、アクセシビリティ上、市場上の質問が残っているか？どれがワーキンググループの技術的能力の内部に属し、どれが協議または外部の決定を必要とするか？制限は省略によって解決されない。
第五に、決定経路。結果はどこで検討されるか？ハッカソン発表は、関連するドラフトと公開問題にリンクすべきである。ワーキンググループは、証拠がテキストまたは合意にどのように影響したかを記録すべきである。ラストコールは未解決の実質的な懸念を露出すべきである。展開の主張は、経験が蓄積されるにつれて更新されるべきである。
この記録は、比例して保たれれば官僚的な負担ではない。曖昧な威信を再利用可能な技術的知識に置き換える。実装者は正確な発見に対して認知を得る。議長は異議を評価するための基礎を得る。事業者は自らの環境との関連性を評価できる。後の研究者はデモンストレーションと展開を区別できる。
最も重要なのは、記録が主張タイプのシフトを防ぐことである。「2つの実装がこのトポロジでメッセージを交換した」は黙って「業界がプロトコルをサポートしている」になることはできない。「15の組織がイベントに参加した」は「事業者がコストを受け入れた」になることはできない。「オープンソースコードが存在する」は「すべての実装者が必要な権利を所有している」になることはできない。それぞれのより大きな主張は追加の証拠を必要とする。
動作するコードはこのモデルで中心的なままである。それは単にその権限を無傷に保つのに十分強いラベルを運ぶ。
動作するコードは借りた権限を拒否するときに最も強力である
IETF ハッカソンは、仕様をより早く実装に答えさせるため、その地位を獲得した。開発者を標準作業に持ち込み、曖昧さを捕らえ、テストツールを作成し、独立したコードを接続し、議論だけでは提供できない証拠をワーキンググループに与える。コードスプリントは、制度自体が機能するツールを維持する。相互運用性イベントは、製品が通信できるかどうかを明らかにする。これらは明確で価値のある機能である。
参加が権限として説明されるとき、それらの価値は減少する。実装者の部屋は、準備状況、リソース、関心、プロジェクトチャンピオンによって選択される。それはまれにすべての種類の事業者、ベンダー、ユーザー、または影響を受ける制度を含む。広範なイベントでさえ、境界のある環境を実行する。動作するコードは、操作が困難で、移行コストが高く、1つの依存関係に集中し、使用が制限され、パケットテストが測定しない方法で有害なままである可能性がある。
標準の伝統はすでに違いを認識している。Proposed Standard は進化できる。Internet Standard の成熟度は、独立した相互運用、広範な展開、成功した運用経験を必要とする。実装状況セクションは情報提供であり、時間に敏感である。合意は頭数を数えるよりも異議に対処する。IPR ルールは、IETF がすべての権利を裁定するふりをせずに情報を開示する。移行ガイダンスは、インセンティブと失敗計画について尋ねる。
実用的なルールは単純である。プロトタイプは実現可能性の主張を権限付ける。独立したペアは、テストされた機能と条件に対する相互運用性の主張を権限付けることができる。展開は、観察された環境に対する運用経験の主張を権限付けることができる。これらのどれも、欠席した当事者が商業的負担を受け入れ、権利を放棄し、決定権を委譲したという主張を権限付けない。
ワーキンググループは、その連鎖を公開記録に保存すべきである。コード、系統、バージョン、カバレッジ、環境、失敗、ライセンス、未回答の質問を名前付けする。結果をドラフトの問題に結び付ける。実装者を超えた運用およびユーザー証拠を求める。展開後に前提を再検討する。失敗した実験に成功した実証と同じ分析上の尊厳を与える。
「おおまかな合意と動作するコード」は、どちらの半分も主権者ではないために機能する。コードのない合意は現実を無視できる。境界のない合意のないコードは、初期の実装者のリソースを未検討のアジェンダに変えることができる。一緒に、技術的権威が獲得され、限界が見え、採用が誰も与えなかった権限ではなく証拠に依存する標準を生み出すことができる。