要約
- IETF への参加は個人単位であり、ラフコンセンサスは投票ではない。会場にいる雇用主を数えればアクセスの不均衡は明らかになるかもしれないが、誰が最終的な仕様を支配したのか、あるいは異議によって設計が変わったのかを確定することはできない。
- 本格的なキャプチャ評価は、時間をかけて4つの連動する集中度を比較する。すなわち、著者と編集権限、特許とライセンスの影響力、独立したコードとプロトコルライブラリの系譜、そして製品・ネットワーク・デフォルトにわたる展開状況である。それぞれの台帳は異なる問いに答え、単独でキャプチャを証明するものはない。
- 対策はメカニズムに一致させるべきである。著者の集中には独立したレビューと編集者のバランスが必要であり、権利の集中には早期のライセンス分析と代替案が必要であり、コード系譜の共有には別の実装ルートが必要であり、展開依存には移行、オープンなテストスイート、サプライヤの移植性が必要である。目的は実装の競争可能性であって、会議でのマイク使用の割当てではない。
会議室は影響力が見える場所であり、支配が必ずしも存在する場所ではない
標準化の観測者は、しばしば会議の写真から始める。何人が参加したか、バッジにどの雇用主が表示されているか、誰がマイクを握ったか、どの陣営が最も大きなハム音を出したか。これらの事実は数えるのが簡単である。渡航の不平等、雇用主によるスポンサーシップ、地域的な排除、または組織的な流入を明らかにすることができる。これらは保存する価値がある。
しかし、それらは成果の支配とは同じではない。小企業の参加者が、すべての実装で使用される中心的なテキストを編集することがある。あるベンダーから10人の参加者が無関係な詳細について発言しても、独立した設計が勝つこともある。会議に欠席した企業が、唯一成熟したコードを所有し、関連特許を保持し、支配的な製品のデフォルトを設定し、またはすべての実装が依存するサービスを制御していることもある。大規模なオープンソースコミュニティが数十の個人名で現れながら、1つのコードルートを継承していることもある。
したがって、キャプチャは長期的な問題である。ある連携した利害関係者が、利用可能な選択肢を定義し、代替案を高価にし、その好ましい振る舞いを実装と展開に持ち込む持続可能な能力を得たかどうか。その答えは登録リストから読み取れるものではない。仕様の寿命を通じて現れる。
この区別は、批判と正当性の両方を保護する。多様な会議室を、キャプチャが発生しなかった決定的な証拠としてベンダーが指摘することを防ぐ。また、批判者が雇用主の人数を、技術者が指示の下で行動した、または結果として得られたプロトコルに独立したサポートがないことの証拠として扱うことを防ぐ。証拠は結果に従わなければならない。
1992年の格言は工学上の権威に関するものであり、人口調査ではない
1990年代初頭からの期間は、1992年に定式化された後、RFC 7282で繰り返された「ラフコンセンサスと実用コード」という言葉に要約されることが多い。このフレーズは、支配者による決定、正式な投票、または実践から切り離された理論を拒否する。コードが勝つのは企業が最も多くの開発者に資金を提供できるからだとか、最大の雇用主グループが会場を埋めるからコンセンサスが存在する、ということを言っているのではない。
RFC 3935（IETF ミッションステートメント）は、個人を参加の基本単位として特定し、プロセスは組織、企業、政府、利益団体ではなく人々に焦点を当てたときに最も効果的に機能すると述べている。また、標準の価値は、インターネットユーザーに有用な機能を提供する複数の製品間の相互運用性にあると位置づけている。
これらの原則は生産的な緊張を生み出す。個人は自分のために発言し推論するが、組織は給与、旅費、特許、コード、機器、クラウド容量、製品流通、展開権限を提供する。組織を無視すれば経済力が見えなくなる。各参加者を企業の投票とみなせば、プロセスの個人性と技術的特性は破壊される。
実装中心のキャプチャテストはこの緊張を解決する。従業員の貢献が政治的に雇用主に属すると推定するものではない。出力に関する観察可能な質問を投げかける。すなわち、誰がテキストを執筆しマージできたか、誰が権利を管理したか、どの独立して開発されたコードが設計を実現したか、誰がユーザーのサポートをオンにできたか。組織の力は、技術的に結果に影響を及ぼす場所で測定される。
ワーキンググループのルールはすでに単一ベンダーのリスクを認識している
RFC 2418（1998年発行のワーキンググループガイドライン）は、エリアディレクターと IESG に対し、提案されたグループが単一ベンダーの活動に過ぎないと見なされないよう、利害が十分に広いかどうかを検討するよう指示している。関心を持つエンドユーザーの基盤があるか、既知の知的財産問題が理解されているか、取り組みが本当にオープンであり、IETF がほとんど影響を与えられない技術に対して IETF 承認を得ようとする試みではないか、と問うている。
これらの質問は出席の割当てよりも洗練されている。数値的な閾値を満たすのに十分な名前がありながら、問題定義、ドラフト、編集者、実装、テスト環境、顧客ベースのすべてを1つのベンダーが提供することもあり得る。逆に、専門性が稀なため狭い専門分野は少数の実装者から始まることもある。重要なのは、作業が競争可能になり得るかどうか、そしてインプットがまだそれを変更できるかどうかである。
RFC 2418はまた、メーリングリストで十分に検討されなかった事項について会議で下された決定は、そこでレビューされることを要求している。電子メールは出張よりも広い参加を可能にすることが認識されていた。この原則は新しいツールにも受け継がれている。単一の会場の人口がグループ全体を定義するわけではない。
したがって、単一ベンダーの問題は、チャータリング時だけでなく繰り返し問われるべきである。採用時、ラストコール時、実装レビュー時、大規模展開時には、グループは独立性が高まったか狭まったかを検討すべきである。1つの貢献を中心に始まったグループは多様化するかもしれない。名目上広範な取り組みが、1つのサプライヤのコードと運用モデルに収束するかもしれない。
ラフコンセンサスは意図的に企業ブロックのカウントを拒否する
RFC 2418は、支配は量や持続性によって確立されるものではなく、メッセージ数だけではコンセンサスの信頼できる指標にはならないと述べている。RFC 7282はこの点を発展させている。ラフコンセンサスは、技術的な異議が検討され回答されたかどうかに依存し、大多数が1つの選択肢を好むかどうかではない。ハミングは、意見の相違が残る場所を明らかにするためのものであり、選挙を行うためのものではない。
これは、企業が多数の従業員を動員して同じ立場を表明する場合に重要である。RFC 7282は、販売・マーケティングスタッフが関与する極端な例を用いて、技術的な関与のない繰り返しの異議は決定を左右する必要がないことを示している。議長は、どのような問題が残っているのか、答えが十分かどうかを問うべきである。実装の直接的な証拠を持つ新しい技術者は決定的な問題を提起するかもしれないが、50の同一の声明は新しい情報を追加しないかもしれない。
出席の指標は依然として手続き上のリスクを明らかにすることができる。もしすべての活動的な編集者とほとんどの発言者が雇用主を共有しているなら、議長は独立したレビューを求めるべきである。影響を受ける事業者クラスが欠席しているなら、グループはコストを聞き取れないかもしれない。1つの論争の多い電話のためにだけ新顔が現れるなら、調整は精査に値する。しかし、正当性のテストは証拠と異議の合理的な取り扱いである。
単に雇用主による投票を再導入するキャプチャ評価は、この設計に矛盾する。また、子会社、請負業者、買収企業、ベンダーから資金提供を受けた大学、または同じコードに依存する無所属の貢献者を通じて操作するのは容易である。支配は座席表から推測するのではなく、機能的に追跡されなければならない。
キャプチャとは、競争可能な選択肢の持続可能な狭まりである
ベンダーの影響は正常であり、しばしば不可欠である。企業は困難な問題、経験豊富な技術者、相互運用可能な製品、テスト施設、展開規模をもたらす。仕様は大部分が1つのベンダーによって書かれても、オープンになり、独立して実装され、制限がなく、広く有用になることができる。集中自体は不正行為ではない。
キャプチャは、集中が、名目上オープンなプロセスが効果的に争うことのできない支配へと固まるときに始まる。1つの利害関係者が、どの問題が重要かを定義し、唯一の使用可能な実装を維持し、代替案を既存システムと互換性がなくし、参入コストを引き上げる権利を付与し、重要な運用依存関係を管理し、またはデフォルトを非常に広く展開して、後のコンセンサスが実質的な効果を持たなくなるようにすることができる。
核心は意図ではない。ベンダーは、技術的卓越性、先発者の優位性、顧客需要、または他の者が作業に資金を提供できないことを通じてこの地位を達成するかもしれない。ガバナンスの結果は同じである。標準化団体は、実用的な選択肢セットが狭まった後で選択を追認する。動機は説明責任にとって重要だが、構造的依存は設計にとって重要である。
キャプチャはまた機能固有である。プロトコルに5つの独立した実装があっても、1つのサプライヤが管理する1つのオプショナル拡張があるかもしれない。基本プロトコルは競争可能でありながら、拡張が支配的な市場へのゲートウェイになる。一般的なオープンソースライブラリはアプリケーションを多様化させるかもしれないが、パーサーの振る舞いを集中させる。測定は、プロトコル全体をブランド化せずに、制御面を発見できるほど詳細でなければならない。
最初の台帳は著者と編集権限である
RFC メタデータは著者と編集者を指名する。ドラフト履歴、問題記録、バージョン管理は、誰がテキストを提供し変更をレビューしたかを示すことができる。これらは有用な出発点である。なぜなら、文書管理が抽象的なコンセンサスをどのように規範的な言語に変換するかを決定するからである。議長は決定を宣言するかもしれないが、編集者は実装者が直面する表現を選択する。
単純な著者数は弱い。表紙の名前は、何年もの設計、遅れての編集支援、歴史的なクレジット、またはリストされる著者の形式的な制限を反映しているかもしれない。企業は1人の編集者を雇用しながら、多くの独立した貢献者がテキストを形成することができる。複数のリスト著者がすべて1つの設計系譜を共有しているかもしれない。所属は初期ドラフトから公開までの間に変化する可能性がある。
より強力な測定は実質的な権限に従う。初期アーキテクチャを執筆したのは誰か。採用時、ラストコール時、最終解決時に編集者を務めたのは誰か。誰が変更をマージできたか。どの人々が必須動作、デフォルト、拡張ポイント、エラー処理に関するテキストを提案したか。設計上の問題のうち、独立したレビューで解決されたのはいくつか。代替案は文書化され比較されたか、それともグループは1つの継承された実装を洗練しただけか。
著者台帳は時間と役割を保存すべきである。雇用主の所属は貢献時のものであり、後の変更は書き換えではなく記録される。請負業者、買収されたエンティティ、二重役割は限定された注釈を必要とする。目的は、すべての文を企業の主体に割り当てることではない。規範的な核心が、1つの連携したグループだけがコンセンサスからテキストへの翻訳を行うことなく改訂可能かどうかを確認することである。
Git 履歴は可視性を向上させるがコンセンサスを定義しない
RFC 8874は、ワーキンググループが文書編集、問題、プルリクエスト、追跡可能な決定に GitHub をどのように使用できるかを説明している。ポリシーを要求し、編集上の問題と設計上の問題を区別し、GitHub での作業には特別なステータスがないことを明確にしている。争点のある決定とコンセンサスは、メーリングリストを含むより広いワーキンググループプロセスを依然として必要とする。
この区別はキャプチャ指標を形成するべきである。コミット数は活動を測定するものであり、権限ではない。貢献者は数百のフォーマット変更を行う一方で、別の者が単一の必須デフォルトを決定することがある。リポジトリ所有者は、議長と公開コンセンサスによって制約される技術的権限を持つかもしれない。マージされたプルリクエストは、他の場所で下された決定を反映するかもしれない。マージされなかった提案が、間接的に最終設計を変えたかもしれない。
したがって、有用なリポジトリ測定は、問題タイプと決定効果を重み付けする。誰が設計問題を開始し解決したか。誰が編集者グループ外からの変更をレビューしたか。独立した異議はどのくらいオープンのままであったか。提案された代替案は安定したドラフトとテストを受けたか。遅れての実質的な変更はメーリングリストに公開されたか。1つの組織が、独立した議長の監督なしに編集者とリポジトリ管理者の両方の役割を保持したか。
ツールの選択はそれ自体のサンプルバイアスを生み出す。メーリングリストをフォローする参加者はすべての問題を監視しないかもしれないが、ソフトウェア開発者はリポジトリでの議論を好むかもしれない。RFC 8874は、GitHub だけですべての関心のある参加者に届くと想定できないと警告している。キャプチャレビューは、会場を比較し、決定的な推論がそれら全体で可視のままであったかどうかを尋ねるべきである。
第二の台帳は特許、ライセンス、および管理された技術である
コードは公開されていても、実装権は集中している可能性がある。RFC 8179は、IETF 参加と、貢献者、雇用主、スポンサーが合理的かつ個人的に知っている権利とを結びつける。その目的は、ワーキンググループが潜在的な知的財産制約について十分な情報を得て技術的な選択肢を比較できるようにすることである。IETF に有効性や侵害を判断するよう求めるものではない。
キャプチャ分析にとって、関連する測定は集中度とタイミングである。必須コアに付随する重要な開示はいくつあるか。それらは1つの権利者または連携したグループによって管理されているか。ライセンス条件は、代替案がまだ実行可能な間に明確であったか。2つの無関係な実装者が、実行可能な条件でライセンス経路を使用できるか。オープンソース実装は、製品ベンダーは吸収できるがコミュニティプロジェクトはできない条件に直面しているか。
生の特許数は誤解を招く可能性がある。1つの広範なクレームが、大きな防御的ポートフォリオよりも重要かもしれない。開示は、ライセンスが必要であることを証明せずに、可能性のある権利を特定するかもしれない。ロイヤリティフリーの条件は影響力を減らすかもしれない。曖昧な合理的条件の文言は、小規模実装者に不確実性を残すかもしれない。権利者は幅広い実装をサポートする一方で、グループ外の第三者制約を生み出すかもしれない。
したがって、台帳は、開示された各ポジションを、影響を受ける機能、要件ステータス、権利者、開示日、ライセンス姿勢、および独立した成功した使用の証拠に結びつけるべきである。不確実性を保存すべきである。結論は「ベンダーが特許を所有している、したがってキャプチャ」ではない。権利が、誰が実装できるかを実質的に狭めるか、またはグループと市場がコミットした後に1つの利害関係者に影響力を与えるかどうかである。
第三の台帳はコード系譜であり、製品数ではない
RFC 7942は、インターネットドラフトが既知の実装（責任組織、成熟度、カバレッジ、バージョン互換性、ライセンス、実装経験、相互運用性テストを含む）を記述することを許可している。このセクションは任意であり、通常は公開前に削除されるが、別途維持される記録が使用されることがある。
このガイダンスは、実行コードが仕様の成熟度を向上させることを認識しているが、すべての実装が独立しているわけではない。10の製品が同じプロトコルライブラリを組み込むことがある。ベンダーは1つのリポジトリからクライアントとサーバのバリアントを公開することがある。2つのチームが共有パーサー、テストオラクル、暗号ライブラリ、または同じ解釈と欠陥を持つリファレンスステートマシンを使用することがある。フォークは異なる名前を持ちながら、アップストリームの変更をほぼすべて受け取ることがある。
RFC 5657はより鋭いテストを提供する。実装レポートに関するガイダンスは、独立した実装は通常、異なる人、組織、コード、プロトコルライブラリから提供されるべきであると述べている。2つの実装しかない場合は、その系譜を特定すべきである。目的は、相互運用性が仕様に従うものであり、プライベートな理解や共通コードによるものではないことを示すことである。
その系譜は、キャプチャ測定の適切な単位である。問題は、いくつのパッケージがサポートを宣伝しているかではない。規範的な振る舞いを実装し、共有された暗黙の仮定なしに相互運用でき、1つのメンテナやベンダーが撤退しても継続できる独立したコードルートがいくつあるかである。
コードルートマップはいくつかの層で制御を測定すべきである
実装の系譜は二値ではない。2つの製品が独立したアプリケーションコードを持っていても、トランスポートライブラリを共有するかもしれない。別々のプロトコルスタックが1つの暗号プロバイダに依存するかもしれない。独立したオープンソースプロジェクトが、元のベンダーによって維持される単一の適合テストスイートを使用するかもしれない。クラウドサービスは、多くのクライアントを通じてプロトコルを公開しながら、決定的なサーバの振る舞いをプロプライエタリに保つかもしれない。
有用なマップは、パーサーとステートマシンから始める。パケットフォーマット、遷移、エラー、ネゴシエーションは独立して実装されているか。次に、セキュリティクリティカルなライブラリ、生成コード、コードジェネレータ、リファレンスアルゴリズム、テストベクトルを追跡する。フォーク関係と、アップストリームから取り込まれた変更の割合を記録する。誰がリリースとセキュリティ修正を承認できるかを特定する。
マップはまた、リファレンスの影響と制御を区別すべきである。高品質のリファレンス実装は曖昧さを減らし、採用を加速することができる。それは有益である。依存は、書かれた仕様がリファレンスをコピーせずに別の実装をサポートできない場合、テストが文書化されていない振る舞いをエンコードしている場合、または展開されたすべての製品が1人のメンテナのリリースを待つ場合にリスクとなる。
測定には、独立したルート数、依存集中度、メンテナ集中度、レビューアの多様性、テストスイートの独立性、および代替時間が含まれる。どれも機械的な合格スコアになるべきではない。小さく慎重にレビューされた暗号ライブラリは、多くの質の低い再発明よりも安全かもしれない。ガバナンスの問題は、標準が、1つの連携した利害関係者が保持する許可または独自の知識なしに実装可能かつ維持可能であるかどうかである。
相互運用性は、成功したデモだけでなく不一致もテストすべきである
2つの実装が通信できるのは、著者が非公開で調整したり、同じ例をコピーしたり、困難な機能を回避したからかもしれない。公開デモは、ある構成で何かが機能したことを証明する。仕様が完全であること、実装が独立していること、またはオプショナルブランチが相互運用することを証明するものではない。
RFC 5657は、レポートをすべての規範的声明で埋め尽くさずに、意味のあるカバレッジを確立するのに十分な機能詳細を推奨している。展開の証拠を重視し、未実装または問題のある機能を特定することを奨励している。その率直さはキャプチャ分析にとって重要である。提案ベンダーによってのみサポートされる機能は、独立した需要がないにもかかわらず標準に残るかもしれない。
テストは、解釈が分かれる可能性のある場所を対象とすべきである。無効な入力、バージョンネゴシエーション、フォールバック、拡張順序、エラー処理、セキュリティ境界、リソース枯渇、オプショナルな組み合わせなどである。独立したチームは、振る舞いを比較する前に、仕様から期待値を導き出すべきである。リファレンス実装とテストスイートがテキストと異なる場合、解決策は公開されるべきである。
失敗は独立性の証拠となり得る。真に別々の実装は、しばしば、1つの共有コードルートが隠す曖昧さを露呈する。洗練されたデモのみを報いるプロセスは、チームを共通ライブラリに押し込み、否定的な結果を抑制する可能性がある。より良い指標は、独立した不一致がテキストを改善したかどうか、そして結果として得られる振る舞いが再現可能になったかどうかである。
第四の台帳は展開、有効化、およびデフォルトの力である
実装は1つのステップに過ぎない。RFC 5218は、プロトコルの成功を評価する際に、実装、展開、および使用を区別している。コードは存在してもインストールされないことがあり、インストールされたサポートは無効のままであることがあり、有効化されたサポートは意味のあるトラフィックを運ばないことがある。標準化キャプチャ分析は同じ区別をしなければならない。
展開力とは、設計を他者が直面するデフォルトの環境に変える能力である。ブラウザ、オペレーティングシステム、ルータプラットフォーム、クラウドエッジ、モバイルネットワーク、広く組み込まれたライブラリは、巨大な規模で振る舞いを確立することができる。それは迅速なセキュリティと相互運用性の利益を生む可能性がある。同時に、後の代替案を技術的には準拠させるが商業的には無関係にすることもできる。
指標は、有効化されたエンドポイント、測定可能な場合のトラフィックシェア、製品クラス、管理ドメイン、デフォルトステータスを特定すべきである。1つの中央管理サービスと多くの独立した事業者を区別すべきである。1つのリリース権限の下にある100万のインスタンスは、規模であってガバナンスの多様性ではない。1つのホストされた仲介者を通じて多くのネットワークで使用されるプロトコルは、広い使用と狭い運用管理を持つかもしれない。
台帳はまた、依存の方向を必要とする。小規模な実装者は直接相互運用できるか、それとも支配的なサービスを通過しなければならないか。事業者は、プロトコル ID、資格情報、データ形式を変更せずにプロバイダを変更できるか。拡張ポイントはオープンに使用可能か、それとも支配的な展開がどの拡張が実行可能かを決定するか。キャプチャは、基本パケットフォーマットではなく、これらのスイッチングコストに存在することが多い。
デフォルトは、テキストが MAY と言っても標準の力を持つ
規範的要件レベルは展開を完全に説明しない。支配的な実装によって有効化されたオプショナル機能は、到達性を求めるサービスにとって事実上の必須になるかもしれない。ほとんどの製品によって無効化された必須機能はほとんど効果がないかもしれない。ベンダー固有の拡張は、ワーキンググループが標準化を決定する前にトラフィックを形成するかもしれない。
したがって、キャプチャ評価はテキストとデフォルトを比較すべきである。誰が出荷時の振る舞いを選択したか。それは設計問題として議論されたか。事業者は安全に変更できるか。ネゴシエーションはベンダーのモードを優先するか。テストとドキュメントは代替案を等しく実行可能にするか。別の準拠オプションを選択するクライアントをサービスが拒否するか。
デフォルトは有益な調整を生み出すことができる。安全な振る舞いが設定なしで有効化されるとき、ユーザーは保護を得る。パフォーマンスの改善は迅速に広がる。懸念は、人気のある実装がリーダーシップを避けなければならないことではない。展開が依存を生み出した後でも、標準化プロセスが振る舞いを評価し変更できるかどうかである。
透明なデフォルト台帳は、バージョン、日付、製品クラス、事業者の設定可能性、フォールバック、規範的テキストとの関係を記録する。また、プロプライエタリなデフォルトが後で標準に入るときも記録する。その履歴は、独立したコンセンサスと既成事実の認識とを区別するのに役立つ。
4つの集中度は、平均化するのではなく、組み合わせる必要がある
著者、権利、コード、展開はそれぞれ異なる形態の支配を明らかにする。広範な著者グループは特許のボトルネックを打ち消せない。複数の特許保有者は1つのコードルートを補償できない。複数のコードルートは、1つの展開プラットフォームが実効的なデフォルトを設定するのを妨げない。多様な市場は、規範的テキストが1つの編集者グループを通じてのみ変更できる仕様を治癒しない。
最も強いキャプチャの懸念は、集中度が一致するときに現れる。同じベンダーまたは連携した利害関係者が、必須コアを執筆し、重要な権利を保持し、リファレンスとテストコードを維持し、支配的な展開を運用する。各ポジションは他方を強化する。インストールベースは設計を検証し、設計はコードを優遇し、コードは文書化されていない振る舞いを具現化し、権利またはスイッチングコストが代替案を阻む。
逆のパターンは正当性を支持する。集中した初期著者は独立した編集レビューによって続かれる。権利は存在しないか、無関係な実装者によって使用される条件で利用可能である。複数のコード系譜が相互運用する。展開は独立した事業者と製品にまたがる。システム全体が競争可能であり続けるなら、単一の層が完全な平等を必要とするわけではない。
そのため、キャプチャレビューは1つの複合スコアではなくマトリックスを使用すべきである。平均は拒否権ポイントを隠す。レポートは各層の集中度、証拠の質、傾向、結果を評価し、次に層間の一致を特定することができる。赤い特許セルは緑の出席セルによって治癒されない。
所属データは日付を付け、慎重に解釈しなければならない
雇用主の所属は有用だが不安定である。技術者は職を変え、企業は互いを買収し、オープンソースメンテナは助成金を受け、コンサルタントは複数のクライアントにサービスを提供し、学術研究は商業的にスポンサーされることがある。現在の雇用主の下で歴史的貢献を書き換えることは、存在しなかった調整を発明する可能性がある。後の買収を無視することは、現在メンテナンスに影響を与える統合を隠す可能性がある。
記録は、貢献時、公開時、レビュー時（関連する場合）の所属を保存すべきである。雇用、スポンサーシップ、請負、リポジトリ権限、特許管理、展開権限を区別すべきである。これらの関係は重なるが同一ではない。
自己申告の所属は一般に適切な出発点である。公開された企業およびプロジェクトの記録は、所有権とメンテナンスの役割を明確にすることができる。プロセスは個人の忠誠心について推測したり、私的な雇用情報を要求したりすべきではない。目的は観察可能な支配をマッピングすることであり、信念を調査することではない。
帰属は不確実性を許容すべきである。貢献者は雇用にもかかわらず独立して行動することがある。財団はプロジェクトをホストする一方で、1つの企業がほとんどのメンテナを供給することがある。名目上無所属の専門家は実質的なつながりを全く持たないかもしれない。結論は、支持された層で表現されるべきである。「3人の編集者が雇用主を共有した」は事実であり、「雇用主が彼らの投票を指示した」は異なる証拠を必要とし、誤りである可能性がある。
出席は早期警告の分母として依然として有用である
出席を最終指標として拒否することは、それを無価値にするものではない。会議およびリストへの参加は、誰が情報にアクセスできたか、どの利害関係者クラスが欠席していたか、1つの雇用主が突然動員されたかどうか、独立したレビューアが関与し続けたかどうかを示すことができる。これらは手続き上の健全性指標である。
分母は正直でなければならない。登録参加者は活動的な貢献者ではない。マイクの出現は独自の異議ではない。メーリングリストのアドレスは検証された人物や雇用主ではない。リポジトリアカウントは自動化または重複している可能性がある。1人の参加者が複数の会場に貢献することがある。雇用主の総計は請負業者を省略したり、子会社を一貫性なくカウントしたりする可能性がある。
より良い出席報告は、登録、セッション出席、実質的な貢献、文書著者、問題参加、コンセンサス応答を分離する。方法と不確実性を示す。機密性の高い個人プロファイルを公開したり、参加を監視に変えたりすることを避ける。
最も重要なのは、出席の発見は評決ではなく質問を引き起こすべきである。1つのベンダーがセッションを支配する場合、独立した実装レビューを求める。事業者が欠席している場合、展開の証拠を求める。部屋が多様でもコードが集中している場合、問題は解決済みと宣言しない。指標の役割は、支配が固まる可能性のある層に注意を向けることである。
特許とコードは逆方向に引っ張ることがある
キャプチャは必ずしも単一ベンダーの物語ではない。プロトコルは独立したオープンソース実装を持ちながら、商業的な展開を不確実にする権利ポートフォリオに直面するかもしれない。別のプロトコルは既知の請求から自由でありながら、小さなメンテナグループによって管理される1つのオープンソースコードベースにほぼ完全に依存するかもしれない。対策は異なる。
権利の集中に対しては、グループは負担のない代替案を比較し、早期のライセンス明確化を求め、無関係な実装者が条件を使用できるかテストし、または影響を受ける機能を必須にしないようにすることができる。開示がないことから安全性を推測するよう実装者に求めるべきではない。IETF ポリシーは普遍的な特許検索を実行しないからである。
コードの集中に対しては、ライセンスは許容的でありながら運用上の依存を残すことがある。対策は、別のコードルートに資金を提供または奨励し、仕様の完全性を改善し、独立したテストベクトルを作成し、文書化されていない振る舞いを文書化し、レビュー権限を分散させることを含むことができる。すべてのフォークが即座にアップストリームに従う場合、フォーク数だけでは十分ではない。
層間分析はカテゴリの誤りを防ぐ。オープンコードは特許を中和しない。ロイヤリティフリーの権利は第二の実装を生み出さない。複数の製品は複数のルートを証明しない。多くの事業者は、1つのホストされたサービスから離れられることを証明しない。各主張は独自の証拠を必要とする。
市場シェアは関連するが、競争審判になるべきではない
標準化団体は競争裁判所ではなく、キャプチャレビューは企業が独占禁止法に違反したかどうかを判断すべきではない。市場シェアはそれでも技術的証拠となり得る。デフォルトがなぜ回避不能になるのか、拡張がなぜ実装の注目を集めるのか、独立したサプライヤーがなぜ意味のある規模でテストできないのかを説明するのに役立つ。
記録は必要最小限の測定値を使用すべきである。観測されたプロトコルトラフィックのシェア、製品クラスにおける有効化されたエンドポイント、サーバの到達可能性、クライアント能力、またはホストされた仲介者への依存。広範な企業収益や無関係な市場支配力は、標準を明確にせずに熱を加える。
測定ソースにはバイアスがある。トラフィック観測者は自分の視点のみを見る。ベンダーテレメトリは他の製品を除外するかもしれない。ダウンロード数はアクティブな使用を示さない。公開スキャンはプライベートネットワークを見逃し、倫理的な懸念を引き起こす可能性がある。調査は関与する事業者を過剰代表する。レポートは方法、日付、分母、盲点を述べるべきである。
高いシェアはキャプチャの証明ではない。優れた実装はオープンフィールドで採用を獲得できる。シェアが閉じた依存関係、文書化されていない振る舞い、制限的な権利、または準拠する代替案が相互運用する実質的な不能と組み合わさるとき、懸念は増大する。標準化の対策は、成功を罰するのではなく、移植性と競争可能性に焦点を当てる。
再現可能なキャプチャレビューは7つのテストを使用できる
最初のテストは変更可能性である。独立した技術的異議が依然として必須の振る舞いを変更できるか、それとも展開が答えを事実上不可逆にしたか。2番目は実装可能性である。有能な無関係なチームが、1つのリファレンスコードベースをコピーしたり、私的な説明に依存したりせずに、仕様から実装できるか。
3番目は権利の使用可能性である。既知の重要な権利とライセンスポジションが代替案のために早期に可視化され、無関係な実装が必要なライセンス経路を行使したか。4番目は相互運用性の独立性である。異なるコードとライブラリの系譜が、一般的なハッピーパスだけでなく、困難な機能、エラー、拡張をテストしたか。
5番目は展開の複数性である。有効化された展開は複数の独立した事業者とサプライヤによって制御されているか、それとも見かけの規模は1つのリリース権限から来ているか。6番目は代替可能性である。ユーザーまたは事業者は、ID、データ、資格情報、到達可能性、または重要な拡張を失うことなく、実装やサービスを変更できるか。
7番目はメンテナンスの複数性である。主要ベンダーがスタッフを撤退させた場合、セキュリティ修正、正誤表、将来のバージョンが進行できるか。編集者、レビューア、テストメンテナ、リリース権限は標準を維持するのに十分に分散しているか。
これらのテストは、非難ではなく、理由のあるプロファイルを生成する。弱い結果は、管理ポイントと必要な証拠を特定する。レビューはリスクが現在進行中か、新興か、減少中か、未知かを述べるべきである。
閾値は自動的な非難ではなく、セーフガードをトリガーすべきである
機械的な制限はゲーミングを招く。どの雇用主も著者の半数以上を供給してはならないというルールは、飾りの名前を奨励する。2つの実装の要件は浅いフォークを奨励する。特許数の上限は請求範囲とライセンスを無視する。展開シェアの制限は成功した標準を罰し、IETF の役割を超える。
閾値はレビュートリガーとしてよりよく使われる。1つの雇用主が現在のすべての編集者を供給している場合、独立した文書レビューと第二の編集者検索が必要になる。すべての既知の製品にわたる1つのコード系譜は、ラストコールの前に公開実装ギャップ声明を必要とする。1つの利害関係者によって管理される重要な権利は、ライセンスの明確化と明示的な代替分析を必要とする。観測された使用のほとんどを担う1つの展開権限は、移植性とデフォルトの文書化を必要とする。
セーフガードは比例すべきである。3人の専門家を持つ専門化されたプロトコルは、記録が狭い分野を説明しレビュー経路を作成すれば進行してよい。1人の残ったメンテナを持つ成熟したプロトコルは、拒否ではなく継承作業を必要とするかもしれない。1つのプラットフォームによってすでに展開された新しい拡張は、グループがまだ変更でき、独立した実装が実行可能であれば標準化されるかもしれない。
中心的な規律は、トリガーを証明に変換することを避けることである。集中は説明と緩和を必要とする。キャプチャは、集中が競争可能な選択を損なったか、持続可能な支配を生み出したという証拠を必要とする。
対策は依存を生み出した層を標的とすべきである
著者が集中している場合、独立したレビューアを追加し、編集者と設計の役割を分割し、代替案を文書化し、議長が実質的な変更をより広いグループ全体で確認するようにする。単に数を改善するために有能な編集者を置き換えることは質を低下させる可能性がある。目標は競争可能性を追加することである。
権利が集中している場合、影響を受ける機能と条件を明確にし、早期開示を求め、設計を比較し、無関係な実装者が進められるかテストする。グループは自分の能力を超えた法的判断を下すべきではない。不確実性が技術的嗜好を変えると判断できる。
コードが集中している場合、別の独立したルートを生み出し、仕様を改善し、公開テストマテリアルを維持し、障害経路をテストし、系譜を開示する。資金提供が必要かもしれない。なぜなら、欠けている実装は単なる競合製品ではなく、公開相互運用性資産だからである。
展開が集中している場合、オープンインターフェース、データと資格情報の移植性、拡張の中立性、移行経路、および1つのホストされた仲介者なしで運用する能力を優先する。理論的には代替案を許容するが、切り替えメカニズムを省略する標準テキストは依存関係を解決していない。
すべての層が一致する場合、レビューは進展の前にいくつかのセーフガードを必要とするかもしれない。独立した実装、権利分析、より広範な運用テスト、デフォルトの開示、およびメンテナンス計画。出版がベンダー製品を不可逆的な標準に変換する場合、遅延は正当化される。遅延は境界があり、具体的な証拠に結び付けられるべきであり、有用な技術を無期限に排除するために使用されるべきではない。
公開報告は個人をプロファイリングせずに構造を暴露すべきである
キャプチャレポートは、参加者のファイルを公開せずに厳密になることができる。単位は役割と組織関係であるべきであり、関連する場合：編集者のその時点での所属、権利者、コードメンテナ、ライブラリ系譜、展開権限、テストスポンサー。個人の住所、報酬、私的契約、推測された動機は不要である。
小グループには、集約が人を特定できるため注意が必要である。レポートは、事業者からの調査回答をグループ化しながら、公開著者とすでに作業に結びついたメンテナを指名できる。機密の商業展開数値は、範囲で表現されるか、独立したレビューアによって検証される。セキュリティセンシティブな実装詳細は、独立性を確立するために必要なレベルで要約できる。
レポートは反対証拠を保存すべきである。著者集中度は高いがコード多様性が強いなら、そう述べる。実装レポートが自己申告で未検証なら、そう述べる。市場データが1つの地域または視点のみをカバーするなら、一般化しない。特許の適用可能性が争われているなら、開示と法的結論を区別する。
正確さは正当性を構築する。キャプチャ言語は強力であり、貢献者を不当に傷つける可能性がある。発見は、企業やワーキンググループを腐敗しているとラベル付けするのではなく、メカニズム、結果、証拠を特定すべきである。
評価は公開後も継続しなければならない
RFC 7942は通常、RFC 公開前に実装ステータスセクションを削除する。情報は時間とともに変化するからである。それはアーカイブ仕様を古い主張から保護するが、メンテナンスの課題を生み出す。キャプチャは、買収、コード収束、サービス統合、特許譲渡、または支配的なデフォルトを通じて公開後に現れることがある。
別の生きた実装記録はスナップショットを保存すべきである。採用時には提案コードを示すことができる。ラストコール時には成熟度と相互運用性を示すことができる。公開後には新しいルート、フォーク、展開、既知の未サポート機能、および変化する制御を示すことができる。各スナップショットには日付と方法が必要である。
公開後のレビューはイベント駆動型であるべきである。トリガーには、1つのサプライヤによる別の実装の買収、独立したコードベースの引退、重要な権利の譲渡、集中度の閾値を超える大規模展開、以前はオプションだった拡張が到達性に必要になった場合、または1つの利害関係者外のすべての編集者の退任が含まれる。
対策は逆転ではなくメンテナンスであるかもしれない。プロトコルは技術的に健全でありながら、そのエコシステムは脆弱になる可能性がある。継承、新しいテストマテリアル、仕様の明確化、別の実装が、ワイヤフォーマットを変更せずに競争可能性を回復できる。
強い発見がどのように見えるか
防御可能な発見はスローガンを避ける。例えば、ワーキンググループラストコール時に、4つの製品がサポートを主張したが、すべてが文書の発信元ベンダーによって維持される1つのライブラリからプロトコルステートマシンを派生させており、独立した実装が2つの必須エラーパスをテストしておらず、同じベンダーが唯一のリポジトリリリース権限を保持し、観測された展開のほとんどがその中央管理サービスから来ていた、と言うかもしれない。悪意についての結論は必要ない。
発見はその後、反対証拠を記録する。仕様とコードライセンスは公開されている。重要な権利制約は知られていない。独立したレビューアがいくつかの規範的セクションを変更した。別のチームが別の実装を開始した。事業者は拡張を無効にできるが、そうすると主要なサービス機能へのアクセスを失う。
結論は「高い実装および展開集中度、中程度の現在のキャプチャリスク、実証された特許ボトルネックなし」であり得る。セーフガードには、2つのエラーパスの独立した完了、移植性テスト、デフォルトの文書化、6ヶ月の展開レビューが含まれる。それは、1つのベンダーが部屋の40％を占めていたと言うよりも実行可能である。
低リスクの発見も同様に具体的であり得る。集中した初期著者、異なるプロトコルライブラリを使用する3つの無関係なコードルート、困難な機能にわたる相互運用テスト、既知の必須権限制約なし、独立した事業者間の展開、および到達性にサプライヤ固有の拡張が不要。記録は、標準がなぜ競争可能であり続けるかを示す。
各決定時点で何を公開すべきか
チャータリング時には、技術の起源、既知の実装、予想ユーザー、既存の権利情報、およびオープン参加によって作業が変更可能な理由を公開する。採用時には、著者の役割、検討された代替案、コードルート、およびドラフトが1つの展開製品から洗練されているかどうかを公開する。
ワーキンググループラストコール時には、編集者の所属、重要な設計貢献者、未解決の異議、実装系譜、機能カバレッジ、権利姿勢、デフォルトの振る舞いを更新する。1つの利害関係者によってのみ実装された機能を特定する。IETF ラストコール時には、より広いレビューと依存仕様の結果を追加する。
公開時には、変更セクションがアーカイブ RFC から離れても、日付入り実装記録へのリンクを保持する。何が実証され、何が実証されなかったかを述べる。公開後には、展開の複数性、買収、引退したコードルート、主要なデフォルト、メンテナンス権限を更新する。
進展または大幅な改訂には、RFC 6410の基準を適用する。独立した相互運用実装、広範な展開、運用経験、正誤表、未使用機能、および管理技術が必要な場合の別個のライセンス使用である。これらは成熟度基準であり、完全なキャプチャテストではないが、機関の最高標準ステータスを出席以上の証拠と整合させる。
目的はコードで異議を唱えられるエコシステムである
オープンな議論は、異議と代替案が表面化することを可能にするので重要である。個人の参加は、技術的推論が企業の命令に還元されるべきではないので重要である。多様な出席は、欠けている経験が盲点を残すので重要である。これらの美徳のどれも、独立した実装者が結果を読み、私的な知識なしに構築し、相互運用し、支配的な貢献者からの許可なしに展開できるまで完全ではない。
コードで異議を唱える能力は厳しいテストである。それは、別の実装が同じワイヤ動作の背後で異なるアーキテクチャを選択できることを意味する。曖昧さを露呈し、デフォルトに挑戦し、オプショナル拡張を辞退し、それでもエコシステムに参加できる。リファレンスベンダーの撤退を生き残ることができる。事業者は、標準を放棄せずに製品とサービスを比較できる。
これが、実装集中度が手続き的開放性と市場実態との間の決定的な橋渡しである理由である。すべての経路が1つのコードルート、サービス、権利者、またはリリース権限に戻るなら、標準はテキストではオープンであり、実践では閉じている可能性がある。独立したルートと展開が繁栄するなら、ベンダーの強い会議プレゼンスは結果をキャプチャしていない。
測定は反ベンダーではない。それはベンダーが行える最も強い貢献、すなわち他者が独立して理解、実装、テスト、運用、改善できる技術を報いる。また、曖昧な告発に対してベンダーに公正な答えを与える。彼らは、出席者総数で自分を守るのではなく、別々のルート、使用可能な権利、相互運用テスト、移植性、分散展開を指し示すことができる。
制度的正当性は実装の痕跡に従う
IETF の正当性は、1人、1社、1国、1票に決して依存してこなかった。それは、オープンな技術的競争、異議に対処するラフコンセンサス、独立した実装に十分明確な仕様、およびユーザーに役立つ相互運用可能な製品に依存している。ベンダーリソースはその連鎖のすべての部分を強化できる。また、依存関係が測定されないままであれば、それを狭めることもできる。
既存の公開ルールにはすでにピースが含まれている。RFC 2418は、グループが1つのベンダー以上であり、外部からのインプットが技術に影響を与えられるかを問う。RFC 3935は個人と相互運用可能な製品を中心に据える。RFC 7282は数値投票を拒否し、回答された異議を優先する。RFC 8179は関連する権利を公開する。RFC 7942は実装成熟度を記録する。RFC 5657は異なる人、組織、コード、ライブラリ、系譜を求める。RFC 8874は編集を追跡可能にするが、リポジトリ活動に特別な権限を与えない。RFC 5218はコードを展開と使用から区別する。
欠けているステップは、決定の時点でこれらのピースを結合することである。重要な仕様ごとに、4つの日付入り台帳を維持する。著者と編集管理、特許とライセンス、コードとライブラリ系譜、展開とデフォルトと切り替え。出席を手続き上の警告信号として追加し、結論としては扱わない。層間の一致を調査し、境界のある発見を比例的なセーフガードとともに公開する。
標準化団体は平等な商業的結果を保証できない。自らの承認が、オープンな会議の背後にある実装独占を隠すために使用されないようにすることはできる。最も意味のある質問は、何人のベンダーが部屋に入ったかではない。仕様が部屋を出るときに、いくつの独立した経路が残っていたかである。