概況
- IETF の「ランニングコード」の伝統は証拠の規律である。実装は、あいまいなテキスト、互換性のない仮定、不足しているエラー処理、機能しないステートマシン、誤ったパフォーマンス期待を明らかにすることができる。独立したコードベース間の相互運用性は単一のデモンストレーションよりも強力な証拠であり、成功した展開はさらに強力である。
- ラベルは重要である。IETF コードスプリントは、Datatracker、Mailarchive、および標準コミュニティが使用するその他のツールを改善する。IETF ハッカソンは、既存および進化する標準を実装またはテストする。相互運用性イベントは、実装の組み合わせを試験する。ワーキンググループ、IETF ラストコール、IESG が標準の決定を処理する。ある活動への参加が、他の活動から暗黙のうちに権限を移譲することはない。
- ハッカソンチームは、チャンピオン、コード、設備、参加可能なメンバーを有するプロジェクトを中心に自己選択される。その結果は、明示された条件下での実現可能性を確立できる。彼らは、プロトタイプを持たない事業者、間接的に影響を受けるユーザー、エンジニアを派遣できない企業、異なる要件を持つ管轄区域、または移行コストと機会費用が実験室でのパフォーマンスを上回る組織を代表するものではない。
- 適切な対応は、ランニングコードを弱めることではない。各成果物が裏付ける主張をラベル付けし、実装の独立性と範囲を開示し、成功と同様に失敗も公表し、テスト結果をワーキンググループの未解決課題に結び付け、実装の勢いを広範な受容として扱う前に、運用、経済、権利、移行に関する個別の証拠を要求することである。
「コードスプリント」は非常に異なる権限を持つ活動を包含する
このフレーズは決定的に聞こえる。グループが集まり、ソフトウェアを書き、システムを接続し、バグを修正し、標準会議が始まる前に結果を発表する。仮想的な動作に関する長い議論と比較すると、コードは現実を提供しているように見える。「実装が動いた」から「プロトコルの選択が検証された」、そしてそこから「コミュニティがその選択を受け入れた」へと直接進むのは魅力的である。
その連鎖は、異なる制度と異なる主張を混同している。IETF は、少なくとも3つの関連する集中コーディング活動の形式を使用している。Tools Team が主催するコードスプリントは、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は、より軽量で早期のメカニズムを提供する。Internet-Draft には、組織、実装、成熟度、カバレッジ、バージョン互換性、ライセンス、経験を説明する実装状況セクションを含めることができる。この慣行は必須ではなく推奨されている。ワーキンググループは情報の使用方法を決定する。議長とエリアディレクターは、このセクションがマーケティングの場になるのを防ぐよう求められており、この時期依存のセクションは通常、RFC 公開前に削除される。
その設計には重要な制度的保護が含まれている。実装状況は審議に情報を提供する。標準に恒久的に埋め込まれたバッジではない。推奨テキストは、実装をリストしても承認を意味しないことを明示的に述べている。ワーキンググループは、実験とフィードバックを適切に考慮しながら、実装が独立しているか、部分的か、最新か、ライセンスされているか、そして目の前の課題に関連しているかを問うことができる。
以前のガイダンスも同様に注意深かった。RFC 5657は、実装名のリストだけでは相互運用性を実証するのに不十分であると警告した。有用なレポートは、相互運用性がどのように確立されたか、何がテストされたか、何が失敗したか、メーリングリストでの明確化が必要かどうかを説明する。製品リストと証拠レポートの違いは、まさに参加と証明の違いである。
したがって、IETF はすでに委任インフレーションに抵抗するための概念的ツールを備えている。弱点は、社会的な勢いが正式なラベルよりも速く動くときに生じる。混雑したデモ、洗練された結果発表、または著名なコードベースによる繰り返しの使用により、運用上および分配上の質問が同等の注意を受ける前に、オプションが決定されたように感じられることがある。
ラフコンセンサスはラップトップを数えない
ワーキンググループの合意は、実装の数やハッカソンのテーブルにいる人数によって決定されるわけではない。RFC 7282は、支配は量や粘り強さから推測されるべきではなく、少数意見に対処しなければならないと説明している。目標は、未解決の課題を特定し、反対意見を理解し、グループがそれらを論理的に検討したかどうかを判断することである。
ランニングコードは反対意見を解決できる。誰かがフィールドを曖昧さなく解析できないと主張する場合、独立した実装がそうでないことを示す可能性がある。提案された移行が不可能であると言われる場合、プロトタイプが実現可能なメカニズムを特定する可能性がある。2つの設計がパフォーマンスの理由で議論されている場合、再現可能な測定が推測を置き換えることができる。
コードはまた、反対意見を解決するのではなく、明確にすることもできる。プロトタイプは、特権アクセス、独自コンポーネント、最新のハードウェア機能、または展開制御に関する仮定でのみ機能する場合がある。その結果は、一般的な懸念を特定の境界に変換する。グループは、その境界が許容可能か、削除できるか、文書化する必要があるかを決定しなければならない。
他の反対意見は、実装だけでは答えられない。事業者は、移行に顧客ベース全体で利用できない調整が必要であると主張する場合がある。市民社会の参加者は、プライバシーへの害を特定する場合がある。小規模ベンダーは、必須機能がコスト障壁を生み出すことを示す場合がある。権利保有者はライセンス条件を開示する場合がある。コードはこれらの主張を照らすことができるが、1つのチームがコストを受け入れたか、権利を所有しているという事実は、他のチームにとってそれらに答えない。
イベントからの事業者の不在は同意ではない。企業からの1人のエンジニアの存在は、その企業を拘束する権限ではなく、ましてやそのセクターを拘束する権限ではない。IETF 参加者は個人として行動する。所属は文脈を開示するが、貢献を企業投票に変換するものではない。企業が議席を所有することを防ぐのと同じ原則が、企業所属の実装者のテーブルが業界の委任になることを防ぐ。
したがって、議長は成功したデモの後、2つの質問をするべきである。この結果はどの技術的課題に答えたか？テストの範囲外にある反対意見はどれか？2番目の質問をランニングコードへの敵意として扱うことは、証拠の規律を抵抗と間違えることである。
ハッカソン参加は準備状況によって選択される
IETF ハッカソンは無料で開かれており、新参者や開発者ではない専門家を意図的に歓迎している。RFC 9311は、その目的をオープンソースコラボレーションを標準活動に持ち込み、開発者や初期キャリアの専門家を IETF に紹介することとして説明している。これらは意味のあるアクセス強みである。
開かれた登録は、影響を受ける関係者の代表的なサンプルを生み出さない。プロジェクトにはチャンピオンが必要である。チャンピオンはトピックを投稿し、チームを集め、リポジトリや設備を準備し、作業を整理する。参加者は、スキル、興味、雇用者の優先順位、利用可能なコード、進捗の可能性に基づいてプロジェクトを選択する。活動的なチャンピオンと成熟したオープンソースベースを持つ技術は、開発者を派遣できない組織が抱える運用上の懸念よりも容易に目に見える結果を生み出すことができる。
したがって、準備状況は証拠を選択する。実装に最も近いアプローチは、標準テキスト、ハードウェア変更、調達、または事業者間の調整を必要とする代替案よりも、多くの成果物、デモ、参加者を生み出す可能性がある。それは準備のできたアプローチを間違ったものにするわけではない。目に見えるコードは、部分的にその周りにすでに蓄積されたリソースを測定することを意味する。
ベンダーサポートはその効果を増幅する可能性がある。会議の前にエンジニアに実装を支払う企業は、コード、テストの専門知識、設備、時間を持って到着する。独立した開発者が参加して改善する可能性があるが、初期のアーキテクチャが利用可能なタスクを形成する。小規模な競合他社は技術的に同意しても、イベントにスタッフを派遣できない場合がある。事業者は関心があっても、本番設備を公開できない場合がある。ユーザーグループは、妥当なコーディングプロジェクトを持たずに結果を経験する可能性がある。
イベント形式はまた、境界のあるタスクを報いる。パーサー、テストベクトル、プロトコルオプション、相互運用性修正は数時間で進捗を示すことができる。コスト配分、プライバシー、長期的な保守性、市場依存性は異なる方法を必要とする。それらは、展開が正当であるかどうかを決定する場合でも、迅速な結果発表に現れる可能性が低い。
これらの選択効果は結果を無効にするものではない。それらは結果が生じる母集団を定義する。情報源を認識するワーキンググループは、誰が実装したか、どのリソースが共有されたか、コードベースが本当に独立していたか、どの影響を受ける役割が欠席していたかを記録すべきである。これにより、参加が暗黙の委任から透明な証拠の文脈に変わる。
最初のハッカソンは価値と境界を示した
最初の IETF ハッカソンは、2015年の IETF 92の前に約50人の参加者で開催された。イベントは急速に成長した。2018年のロンドンでの IETF 101までに、公式報告によると、35のプロジェクトに約220人のオンサイトと20人のリモート参加者がいた。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 コードスプリントは、その結果が運用上重要であるが、憲法上誇張しやすいため、別の扱いに値する。Tools Team はボランティアを集めて、Datatracker、Mailarchive、文書作成ツールなどのサービスを改善する。IETF 114では、18人のコードスプリント参加者が Datatracker と xml2rfc の作業にわたって30以上のプルリクエストを生成し、貢献はその週を通じて続いた。
これらの変更は参加に実質的に影響を与える可能性がある。検索、アジェンダ、提出、レビュー、アイデンティティ、メタデータ、公開機能は、人々が標準作業を発見し貢献する容易さを形成する。貧弱なツールは排除し、良いツールはコストを下げる。したがって、ツールメンテナーは結果的なエンジニアリング判断を行使する。
しかし、組織プラットフォームへのコードの貢献は、ボランティアにプロトコルコンテンツに対する権限を与えない。関連する実装を記録する機能は、証拠の可視性を改善できる。リンクされた実装を承認するものではない。アジェンダの改善はセッションを読みやすくできる。どの技術提案が合意を持つかを決定しない。文書ツールは構文を強制できる。その構文によって表現されるポリシーを決定しない。
逆の境界も重要である。ワーキンググループは、コードが存在するという理由だけで、ツールの現在のデータモデルを実質的な制限として扱うべきではない。Datatracker が重要な区別を表現できない場合、答えは組織の推論を利用可能なフィールドに圧縮するのではなく、ツールを改善することである可能性がある。インフラストラクチャは、暗黙的に定義するのではなく、公開決定に役立つべきである。
コードスプリントの変更は、独自の説明責任を必要とする：レビュー、テスト、セキュリティ、プライバシー、アクセシビリティ、保守性、展開、および IETF サービスに依存する人々からのユーザーフィードバック。権限は、Tools Team の役割と採用された保守契約から来ており、それらのサービスに限定される。それはプルリクエストの数から生じるものではない。
コードスプリントとハッカソンの権限を分離することで、両方が強化される。ツール貢献者は、その作業がプロトコル検証として誤って説明されることなく、機関の維持に対して信用を得る。プロトコル実装者は、機関システムを維持していることを暗示することなく、証拠を報告できる。ワーキンググループは技術的合意に対して責任を負い続ける。
「ランニングコード」というフレーズは、これらの活動を文化的に結び付ける。それはそれらの権限を消去するものではない。
ベンダー集中は実装の複数性の中に隠れることができる
2つの相互運用する実装は1つよりも強力な証拠であるが、数値的な複数性は共通の制御を隠すことができる。コードベースは、ライブラリ、企業親会社、主著者、テストスイート、資金源、ハードウェア依存性、商業的インセンティブを共有する可能性がある。真に独立したチームでも、市場の同じセグメントを代表する可能性がある。
独立性の目的は認識論的である。異なる実装者は、同じ隠れた決定に頼らずにテキストにアプローチするため、曖昧さを露呈できるべきである。組織名は不完全なプロキシである。フォークは意味のある分岐ができる。2つの企業製品はほとんどすべてを共有できる。報告では、ロゴを単に数えるのではなく、コードの系統と決定的な依存関係を説明すべきである。
市場の多様性は別の問題である。2つの支配的なプラットフォームからのサーバーとクライアントは完全に相互運用できるが、小規模な実装者は法外な複雑さに直面する可能性がある。オープンなリファレンス実装はその障壁を下げることができるが、唯一の実用的なコードパスになる可能性もある。すべての製品がそれを埋め込む場合、プロトコルの相互運用性は高いが、実装の多様性は低い可能性がある。
RFC 9518は、実装と展開の多様性をユーザーのスイッチング能力に結び付ける。技術的に開かれた標準でも、代替案の実装や維持がコスト高すぎる場合、集中化を支えることができる。複雑さ、独自拡張、データ優位性、粘着性のある仲介者は、パケット互換性とともに関連する。
したがって、ハッカソンメトリクスは、参加者数、組織数、独立したコードベース数、依存関係の多様性、役割の多様性、最終的な展開の多様性を区別すべきである。どれも単独で正当性を提供しない。一緒になって、ランニングコードが仕様を複数の方向からテストしているのか、それとも1つの実装ファミリーを繰り返し行使しているのかが明らかになる。
これは大規模ベンダーを排除する議論ではない。彼らのエンジニア、製品、設備、展開データはしばしば不可欠である。懸念はマークされていない集中である。ワーキンググループは、成功したテストが競合する実装、共有コンポーネント、事業者、アプリケーション、制約された環境に及ぶかどうかを知るべきである。
透明性はまた、ベンダーを不当な推論から保護する。所属は協調を証明せず、スポンサーシップは技術的結果の制御を証明しない。証拠は、すべての従業員を指示された企業代表として扱うのではなく、実際のコードと依存関係を特定すべきである。
ガバナンスの目標は、最初にそれを最も生み出せる組織の外側でも十分に堅牢な結果である。
失敗は証拠であり、成功とともに伝わるべきである
ハッカソンの報告は当然進捗を祝う。チームのプレゼンテーション時間は限られており、スポンサーや主催者は価値を示したいと考え、参加者は認識を受けるに値する。結果は、完了した機能、修正されたバグ、改善されたベンチマークを強調する一方で、失敗した構成、未解決の曖昧さ、セットアップ依存性を圧縮する可能性がある。
標準の品質にとって、失敗はより重要かもしれない。相互運用しなかったペアは、仕様または実装の問題を特定する。誰も試みなかった機能は、複雑さまたは需要の欠如を示す可能性がある。設備が利用できずに放棄されたテストは、証拠のギャップを定義する。著者が意図された動作を説明した後にのみ可能だった結果は、テキストが独立して十分でなかったことを示す。
報告形式は、イベントを監査審判に変えることなく、これらの事実を保存すべきである。各プロジェクトはコンパクトなマトリックスを公開できる：実装と系統、仕様バージョン、試みられた機能、成功した組み合わせ、失敗した組み合わせ、逸脱、必要な明確化、パフォーマンス環境、コードリンク、ライセンス、未解決の質問。チームは欠落している証拠を成功に変換するのではなく、不明とマークできるべきである。
ワーキンググループの議長は、そのマトリックスを課題にマッピングできる。どの失敗がドラフトテキストを必要とするか？どれがコードバグか？どれが展開の仮定を露呈するか？どれが依然として論争中か？会議はハイライトスライドのみを受け取るべきではない。非同期でレビューできる主張のセットを受け取るべきである。
否定的な結果はまた、実装演劇から保護する。洗練されたデモンストレーションを持つがカバレッジが狭いプロジェクトは、基本的な困難を発見したプロジェクトよりも上位にランクされるべきではない。RFC 3935は、失敗した実験が特別な場合にのみ有用な技術的に有能な標準よりも関連性が高い可能性があることを明示的に認識している。
長期的なフォローアップが重要である。イベントからの修正はリリースされたコードに入ったか？仕様は変更されたか？後の実装が結果を再現したか？展開が異なる失敗を露呈したか？1回限りの報告は瞬間を確立できる。標準の成熟度は、その後に何が生き残るかに依存する。
「ランニングコード」というフレーズには、クラッシュしたコード、同意しなかったコード、状態を消費しすぎたコード、設計が不経済であることを証明したコードを含めるべきである。現実は、不便な結果が可視のままであるときに標準を最も効果的に制約する。
証拠台帳は委任インフレーションを防ぐべきである
すべての実装主張は5つの境界を特定すべきである。
第一に、命題：作業は正確に何を実証したか？例には、解析可能性、機能カバレッジ、相互運用性、指定された負荷下でのパフォーマンス、障害回復、移行、展開が含まれる。「動作する実装」は、1つのパスのみが実行された場合には広すぎる。
第二に、母集団：どのコードベース、組織、役割、ネットワーク、ユーザーが代表されたか？独立性とコードの系統を説明すべきである。欠席は、反対または同意として扱うのではなく、役割ごとに記録すべきである。
第三に、環境：どのハードウェア、トポロジ、トラフィック、バージョン、設定、期間、サポートが必要だったか？チームは著者の支援なしに公開資料から結果を再現できたか？失敗とテストされていない機能は保持されたか？
第四に、結果：どの運用上、経済上、法律上、プライバシー上、セキュリティ上、アクセシビリティ上、市場上の質問が残るか？どれがワーキンググループの技術的能力の内部にあり、どれが協議または外部の決定を必要とするか？制限はそれを省略することで解決されない。
第五に、決定経路：結果はどこで考慮されるか？ハッカソンのプレゼンテーションは、関連するドラフトと公開課題にリンクすべきである。ワーキンググループは、証拠がテキストや合意にどのように影響したかを記録すべきである。ラストコールは未解決の重要な懸念を露呈すべきである。展開の主張は、経験が蓄積されるにつれて更新されるべきである。
この記録は、比率を保てば官僚的負担ではない。それは漠然とした威信を再利用可能な技術的知識に置き換える。実装者は正確な発見に対して認識を得る。議長は反対意見を評価するための基盤を得る。事業者は自らの環境への関連性を評価できる。後の研究者はデモンストレーションを展開から区別できる。
最も重要なのは、記録は主張タイプのシフトを防ぐことである。「2つの実装がこのトポロジでメッセージを交換した」は、暗黙的に「業界がプロトコルをサポートしている」になることはない。「15の組織がイベントに参加した」は、「事業者がコストを受け入れた」になることはない。「オープンソースコードが存在する」は、「すべての実装者が必要な権利を持っている」になることはない。それぞれのより大きな主張は追加の証拠を必要とする。
ランニングコードはこのモデルで中心的なままである。それは単に、その権限を無傷に保つのに十分強力なラベルを運ぶ。
ランニングコードは借りた権限を拒否するときに最も強い
IETF ハッカソンは、仕様を実装に早期に答えさせることでその地位を獲得した。開発者を標準作業に引き込み、曖昧さをキャッチし、テストツールを作成し、独立したコードを接続し、ワーキンググループに議論だけでは提供できない証拠を与える。コードスプリントは、機関自体が機能するためのツールを維持する。相互運用性イベントは、製品が通信できるかどうかを露呈する。これらは明確で価値のある機能である。
参加が委任として説明されるとき、それらの価値は低下する。実装者の部屋は、準備状況、リソース、関心、プロジェクトチャンピオンによって選択される。それはめったにあらゆる種類の事業者、ベンダー、ユーザー、または影響を受ける機関を含まない。広範なイベントでさえ、境界のある環境を行使する。動作するコードは、運用が困難であったり、移行コストが高かったり、1つの依存関係に集中していたり、使用が制限されていたり、パケットテストが測定しない方法で有害であったりすることがある。
標準の伝統はすでに違いを認識している。Proposed Standard は進化できる。Internet Standard の成熟度は、独立した相互運用性、広範な展開、成功した運用経験を必要とする。実装状況セクションは情報提供であり、時間に依存する。合意は頭数を数えるのではなく反対意見に対処する。IPR ルールは、IETF があらゆる権利を裁定するふりをせずに情報を開示する。移行ガイダンスはインセンティブと失敗計画について尋ねる。
実用的なルールは単純である。プロトタイプは実現可能性の主張を正当化する。独立したペアは、テストされた機能と条件に対する相互運用性の主張を正当化できる。展開は、観察された環境に対する運用経験の主張を正当化できる。これらのどれも、欠席している当事者が商業的負担を受け入れ、権利を放棄し、決定権を委譲したという主張を正当化するものではない。
ワーキンググループは、その連鎖を公開記録で保存すべきである。コード、系統、バージョン、カバレッジ、環境、失敗、ライセンス、未解決の質問を命名する。結果をドラフト課題に結び付ける。実装者を超えた運用およびユーザーの証拠を求める。展開後に仮定を再訪する。失敗した実験に成功したデモンストレーションと同じ分析の尊厳を与える。
「ラフコンセンサスとランニングコード」は、どちらの半分も主権者ではないため機能する。合意のないコードは現実を無視できる。コードのない境界のある合意は、初期の実装者のリソースを未検討のアジェンダに変える可能性がある。一緒に、技術的権威が獲得され、限界が可視であり、採用が誰も与えなかった委任ではなく証拠に基づく標準を生み出すことができる。