概況
- IAB の最も強力な機能は認識論的（エピステミック）である：プロトコル層を超えた決定を結びつけ、長期的な依存関係を特定し、専門家を招集し、狭い最適化がシステム全体に害を及ぼす場合に警告することができる。
- 1992年の POISED 改革につながった論争は、なぜ助言と決定権を区別しなければならないかを示した。IAB がガイダンスとして理解していたコミュニケーションが、多くの人々にはインターネットの将来に関する決定として広く理解され、誰が決定し、誰が決定者を選ぶのかという問題を露呈した。
- 現代の選出、承認、公開性、リコールのルールにより、IAB は IETF システム内で説明責任を果たす。しかし、それによってメンバーがインターネットユーザー、ネットワーク事業者、政府、または外部コミュニティの選挙で選ばれた代表者になるわけではない。
- IAB の声明と連絡業務は、証拠、技術的制約、不確実性、アーキテクチャ上の結果を特定すべきである。外部機関は、アーキテクチャの名声を民主的な権限とみなすのではなく、分配、法的、または執行の選択のために独自の公共的権威を提供しなければならない。
インターネットには長期的な視点が必要だが、誰も地平線から委任を得るわけではない
ワーキンググループは限定されたタスクを中心に組織されている。プロトコルの問題を解決し、仕様を改訂し、レジストリを維持し、提案が十分なサポートとエンジニアリング品質を持って進展するかどうかを判断する。その焦点は生産的である。また、チャーター間でコストを見えなくすることもできる。
ある変更は、1つのプロトコルを改善しながら、システム全体の相関を高める可能性がある。不正防止メカニズムは不正を減らす一方で、アクセスを少数のアテスタントに依存させる可能性がある。パフォーマンス最適化は集中化圧力を高める可能性がある。プライバシー機能は他の場所での運用を複雑にする可能性がある。レジストリルールは1つの仕様内では事務的に見えるが、複数のサービスがそれに依存するとチョークポイントになる可能性がある。これらの影響は、狭い機能の提供に責任を負わない立場から最も容易に見ることができる。
IAB はそのような立場を占めるために部分的に存在している。その憲章は、アーキテクチャの監督、長期的な計画、エリア間の調整を規定している。新たな活動をレビューし、提案されたワーキンググループの憲章にコメントし、ワークショップを開催し、重要な問題を行動可能なグループに持ち込む。また、IETF の作業を RFC シリーズ、IANA、IRTF、インターネットソサエティ、外部標準化団体と結びつける関係を管理または監督している。
この機能は貴重である。なぜなら、アーキテクチャは累積的だからである。インターネットの特性は1つの文書から生まれるわけではない。アドレッシング、ネーミング、ルーティング、トランスポート、セキュリティ、アプリケーション、実装の選択、運用上のインセンティブ、公的なルールの相互作用から生じる。過去の失敗を記憶し、境界を越えて見ることのできる組織は、局所的な成功がグローバルな罠になるのを防ぐことができる。
しかし、遠くまで見通す能力は政治的な委任の源泉ではない。アーキテクトは脆弱性、集中、相互運用性の喪失、移行の行き詰まりを特定できる。しかし、それが誰がコストを負担すべきか、どのような権利が優先されるべきか、規制当局が何を強制できるか、どの集団が同意したかを確立するわけではない。技術的な能力は判断の質を説明する。代表は、発言者とその名の下で権力が行使される人々との関係を説明する。IAB はその人材と実践を通じて前者を所有している。後者はインターネット全体について語るだけで獲得するものではない。
この境界は沈黙を求めるものではない。技術的な組織が声を発することを可能にし、公的な選択を専門知識で洗練することを防ぐものである。
1992年の危機は IPv4 の将来と権威の所在に関するものだった
IAB 権力の現代的な制限は、外部の政治理論家によって発明されたわけではない。それはインターネット技術コミュニティ内部の紛争から生じた。
RFC 1640は、Internet Standards のプロセスに関するワーキンググループの報告書であり、状況を説明している。1991年と1992年、アドレス枯渇とルーティングテーブルの成長により、将来のインターネットプロトコルに関する決定への圧力が生じた。ROAD グループは短期的な勧告を行ったが、長期的な方向性を確定しなかった。IESG はさらなる探求のための計画を IAB に送った。1992年6月の会合の後、IAB は CLNP の側面を含む追加のアイデアに注意を払うべきだという懸念を伝えた。
この論争には技術的な側面と政治的な側面があった。技術的な問題は、IP を進化させる最善の道と OSI プロトコルファミリーからのアイデアの関連性に関するものだった。政治的な問題はより持続的だった：インターネットコミュニティで誰が決定を下し、誰がその人々を選ぶのか？
RFC 1640は、発言に関する顕著な意見の相違を記録している。多くの受信者は IAB のコミュニケーションを決定、または将来の決定の強い示唆として理解した。IAB メンバーは自分たちが議論を開始し、助言を提供していると理解していた。同じ言葉が、読者の発言者モデルに応じて異なる制度的な力を持っていた。
その曖昧さは、初期の小規模コミュニティではもっともらしかった。IAB は日常の技術作業に近く、広範な責任を持っていた。IETF が拡大し、IESG とエリア構造がさらに層を追加するにつれて、アーキテクチャ評議会の声明は、それがガイダンスか、承認か、命令かを説明するために個人の近接性に頼ることができなくなった。
即時の技術的議論は続いた。ガバナンスの結果は、標準権威とリーダーシップ選出に関する POISED の検討であった。参加者は、IAB が技術的なガイダンスではなく決定を下すべき範囲、および IAB と IESG がどのように関係すべきかを議論した。生まれた合意は、最終的な標準トラックのアクションをワーキンググループに近い IESG に移しつつ、アーキテクチャと監督機能を持つ IAB を維持するものだった。
教訓は、IAB の技術的な懸念が必ずしも間違っていたということではない。正しい懸念であっても、解読不能な権威構造を通じて伝えられる可能性があるということである。尊敬される組織からの助言は予測可能な行動を形成する。組織がどのような主張を行っているかを述べない場合、受信者は制度的な名声から権力を推測する。
改革前の憲章は技術的反映以上のものを集中させていた
1992年8月の IAB 憲章、RFC 1358は、なぜそのコミュニケーションがそれほどの重みを持ったかを説明するのに役立つ。IAB を Internet Society の技術諮問グループとして記述していたが、その責任には専門家によるアーキテクチャの監督、RFC シリーズの編集管理、インターネット標準の開発、レビュー、承認、Internet Society リーダーシップへの助言、外部の連絡関係における代表が含まれていた。
同じ組織が長期的な設計について助言し、標準を承認し、機関の利益を外部で代表することができた。そのメンバーシップルールは、IAB 自身、Internet Society 会長、または Internet Society 理事会からの指名を可能にしていた。メンバーは組織代表ではなく個人として務めた。これは今でも重要な原則であるが、選出設計は広範な IETF コミュニティによる直接の選択にはならなかった。
この構造には歴史的な論理があった。インターネットはより小さく、専門知識は集中しており、制度的な境界はまだ構築中だった。小規模で信頼されたグループによる調整は、分離された機能のシステムよりも速く、首尾一貫していた。アーキテクチャ自体は全体を見ることのできる人々から利益を得た。
成長は正当性のコストを変えた。より多くの実装者、事業者、研究者、企業、政府、ユーザーがインターネットに依存するにつれて、技術コア間の非公式な信頼は誰が最終的な権威を持っているかを説明できなかった。組織が標準を進めるかどうかを決定する場合、その承認が決定するならば、単なる諮問と呼ぶことはできない。個人としての奉仕も、その個人がどのように選ばれたかという別の問題に答えるものではない。
POISED は専門知識を大量投票で置き換えなかった。その合意はより実用的だった。標準アクションをアーキテクチャレビューから分離し、意思決定を IETF の作業構造に近づけ、リーダーシップ選出へのコミュニティ参加を発展させた。目的は議会ではなく、1つの専門家組織があいまいなタイトルの下で多くの種類の権威を組み合わせるのを防ぐことだった。
その歴史は、今日 IAB の声が説明されるたびに重要である。IAB の影響力は意図的に保持されていたが、その決定の役割は狭められ、分化された。現代のアーキテクチャ声明を、まるで古い標準承認委員会の布告であるかのように扱うことは、1992年の組織的学習を逆転させる。
現代の憲章は、代表者の会議室ではなく、個人の評議会を創設する
現在の中核憲章であるRFC 2850は、13人の正会員を定義している：12人の現職メンバーと IETF 議長。通常、6人の現職メンバーが毎年2年の任期で任命される。メンバーは個人として務め、企業、機関、またはその他の組織の代表ではない。憲章はまた、IAB、IETF、IRTF、IESG に対して忠実義務や注意義務を負わないと述べている。
個人としての奉仕は重要な保護である。ベンダー、事業者、大学、政府に雇用されているメンバーに対して、その席が雇用主からの指示チャネルではないことを伝える。また、所属を超えた判断を可能にし、組織が投票ブロックを交渉する正式な可能性を減らす。
同じルールは代表の限界を設定する。メンバーが雇用主の代表でないなら、ユーザーや事業者の代表でもない。人は運用知識、市民社会の視点、研究の深さ、公共セクターの経験を持つかもしれない。その知識は参加者に具体化された証拠であり、影響を受ける人々からの選挙委任ではない。
IAB は全会一致を目指すが、RFC 2850は少なくとも7人の正会員が同意し、2人以下の反対がある場合に行動を許可する。議事録を公開し、IETF 会議で公開会合を開催し、認識された公開チャネルを通じて調査結果を公開する。ただし、一部の人事、法律、または財務事項については限定的な秘密保持が適用される。これらは深刻な透明性管理である。コミュニティが組織が何をしたか、そして多くの場合なぜそうしたかを検査することを可能にする。
それらは構成員を変えない。7人の同意する専門家が制度的に有効な IAB 行動を発行できる。彼らの同意が、数十億のユーザー、数千の自律ネットワーク、各国議会、またはオープンプロトコルのすべての実装者の同意になるわけではない。憲章内の有効な権威と、憲章外の代表権威は異なる命題である。
この区別は言語に可視であるべきである。「IAB はこの設計がシステム全体の相互運用性リスクを生み出すと結論する」はアーキテクチャ能力内の主張である。「インターネットコミュニティはこのポリシーを承認する」は、IAB が構成しない構成員に関する主張である。前者はエンジニアリング証拠に対してテストできる。後者には、憲章が提供しない代表の理論が必要である。
NomCom の説明責任は現実的であり、限定されている
現代の IAB 選出は自己永続的な任命ではない。RFC 8713は、IAB、IESG、およびその他のリーダーシップ役割のための IETF 指名委員会システムを確立している。定義された適格性とランダム化ルールの下で10人の投票ボランティアが選ばれる。委員会はコミュニティの意見を求め、候補者を評価し、IAB 候補者を Internet Society 理事会に確認のために送る。任期はずらされ、現職者は自動的に更新されるのではなくレビューされる。
この取り決めは、複数の形の説明責任を提供する。現職の IAB メンバーがすべての後継者を選ぶわけではない。コミュニティ参加者はフィードバックを提供できる。毎年新しいボランティア委員会が構成される。確認は IAB の外部にある。選出ルールは IETF の公開標準プロセスを通じて改訂できる。
リコールも可能である。RFC 8713は、NomCom 投票メンバーとして適格な少なくとも20人の人々による IAB メンバーに関する請願を許可する。ただし、同じ主な所属を共有するのは2人までである。リコール委員会が調査し、メンバーおよび第三者から意見を聞き、メンバーを解任するには投票の4分の3の過半数が必要である。オンブズチームは定義された状況下で別のルートを持つ。
これらのメカニズムは、リーダーシップを IETF コミュニティに対して説明責任を負わせる。直接選挙ではなく、インターネットユーザーの選好を集約するように設計されていない。投票ボランティアは適格な IETF 参加者からのサンプルであり、世界の人口やすべてのネットワーク事業者のサンプルではない。候補者の審議は正当な理由で秘密にされ、そのため、なぜあるアーキテクチャの見解が別のものより好まれたかに関する公的な可視性も制限される。
Internet Society 理事会による確認はレビューを追加するが、大衆の委任ではない。リコールは個人の行動や適合性をテストする。それはすべてのアーキテクチャ声明に関する国民投票として機能するには重すぎ、個人的すぎる。1つの立場に同意しないコミュニティは、通常、立場に回答すべきであり、解任を脅かすべきではない。
NomCom の説明責任はしたがって、制度的と適切に記述される。それは、IAB が IETF のミッションに奉仕することが信頼されている人々によってスタッフされているかどうか、そして不正行為や持続的な失敗が修正できるかどうかを尋ねる。メンバーに、外部の人口が公共政策を選ぶために彼らを選んだと主張する権限を与えるものではない。
専門知識は理由に特別な重みを与えるが、自動的な優先権ではない
アーキテクチャの専門知識は、別の利益団体の選好ではない。いくつかの主張は実証可能である。設計は単一障害点を導入する可能性がある。メカニズムはインターネット規模では利用できない調整を必要とする可能性がある。提案された傍受能力は認証の前提を弱体化させる可能性がある。閉じたアテステーションゲートは、独立した実装が他の方法ではオープンなプロトコルにアクセスするのを防ぐ可能性がある。これらはシステムプロパティに関する主張であり、広範な技術経験を持つ人々がそれらを早期に特定し、より良く説明できる可能性がある。
適切な応答は認識論的な優先権である：主張を聞き、証拠を要求し、前提をテストし、理にかなった回答を要求する。それは政治的な優先権ではない：リスクを見たので、専門家組織にあらゆるトレードオフを決定させる。
この違いは、結果が分配されるときに明確になる。あるセキュリティ対策が1つの種類の悪用を減らすが、承認されたアテステーションを取得できない製造元のデバイスを除外するとする。アーキテクチャは集中点、相互運用性の喪失、硬化のリスクを明らかにできる。障害をモデル化し、代替案を特定できる。残った詐欺削減が除外を正当化するかどうか、誰が例外を提供しなければならないか、どの法的権利がアクセスを支配するかを単独で決定することはできない。
いくつかのエンジニアリングの選択は、公然と価値も含んでいる。RFC 3935は、開放性、公平性、分散制御、エンドユーザーエンパワーメントを IETF コミュニティの価値として記述している。この文書は、これらの概念が単に可能なテクノロジーではなく、コミュニティが作成することを選択するテクノロジーであることを珍しく率直に述べている。その率直さは強みである。価値判断が方程式を装うのを防ぐ。
また、主張を制限する。IETF コンセンサスを通じて承認された価値は、IETF 標準を導くことができる。それは自動的にすべての政府、サービス、ユーザーを拘束するルールではない。外部機関はそれを説得力があると見なすかもしれない、特にその行動が開かれた相互運用性を壊す場合。しかし、それらはそれを自分たちの法的な権限と影響を受ける公衆に結びつけなければならない。
したがって、IAB の最良の権威は理由を与えることである。声明は、因果メカニズム、実装証拠、代替案、不確実性、結論が変わる条件を提供するときにより強力であるべきである。制度的なタイトルは注意を促すべきであり、議論を終わらせるべきではない。
アーキテクチャの原則は記憶補助であり、憲法の永遠ではない
RFC 1958は1996年に公開され、IAB 自身の原則の使用を支配すべき警告で始まっている。技術的変化は継続的であり、一度不可侵と扱われた原則は後に非推奨になる可能性がある。文書は、絶え間ない変化が無期限に生き残る唯一のインターネット原則である可能性があり、教義を定める意図はないと述べている。
これは謙虚さのアーキテクチャである。単純性、モジュール性、フェイトシェアリング、エンドツーエンド動作、分散制御などの原則は、経験を圧縮するので価値がある。頻発する障害モードに注意を向ける。各ワーキンググループがすべての教訓を再発見するのを防ぐ。
圧縮は文脈を失う。ある技術的および経済的環境の下で革新を保護した原則は、別の環境で広く呼び出される可能性がある。「ネットワークを単純に保つ」は、どの当事者が複雑さを負担すべきかを特定しない。「エッジに関数を置く」は、すべてのエッジデバイスが必要なセキュリティを維持できるかどうかには答えない。「集中化を避ける」は、集中がプロトコル設計、規模の経済、規制、データ、アイデンティティ、または流通チャネルから来るかどうかを特定しない。
後の著作、例えばRFC 3439は、複雑性、階層化、結合、運用コストをより詳細に探求している。投票ルールではなく、ヒューリスティックと例を提供している。それが正しいモデルである。アーキテクチャはトレードオフと既知のパターンを暴露し、その後証拠に戻るべきである。
IAB の声明は、原則が切り札として使用されるときに危険になる。すべての反例が十分にアーキテクチャ的でないとして却下される場合、長期的な視点は現在の議論を閉じる方法になる。システムを記憶する任務を負った組織は、記憶するために選ばれた人々の世界観を不注意に凍結する可能性がある。
したがって、主要なアーキテクチャの結論はすべて、その経験的基礎、範囲、可逆性を述べるべきである。どの展開が主張を支持するか？どの人口がコストを経験するか？どの代替案が比較されたか？どの証拠が結論を反駁するか？原則は設計上の推定として使用されているか、それともカテゴリ的な禁止として使用されているか？この規律はアーキテクチャが神学になるのを防ぐ。
市場構造はアーキテクチャの選好を私的な権力に変える可能性がある
アーキテクチャは市場を通じて実装される。プロトコルは多くの独立した実装を許可するかもしれないが、流通、アイデンティティ、クラウドホスティング、アプリストア、ハードウェア供給は少数の実用的なゲートキーパーだけを残す。逆に、形式的に集中された技術的機能は、透明で制約のあるルールの下で運用され、裁量的な権力を減らすことができる。図だけではガバナンスの結果を明らかにしない。
これは IAB にとって重要である。なぜなら、アーキテクチャ言語は商業的交渉を変える可能性があるからである。あるアプローチが有害であるという声明は、それが標準でなくても、調達、投資、規制の監視に影響を与える可能性がある。その影響は有益である可能性がある。切り替えが不可能になる前に、顧客を脆い依存関係から遠ざけることができる。また、既存の設計がアーキテクチャのベースラインとして記述される既得権益者を有利にする可能性もある。
したがって、理事会はプロトコルの集中と市場の集中を分離すべきである。独立した実装はいくつ存在するか？流通と更新を誰が制御するか？ユーザーや事業者は、アイデンティティ、データ、相互運用性を失わずに切り替えることができるか？すべての viable な実装が1つのサービスに依存する場合、見かけの分散化は意味があるか？提案された救済策は新しいゲートキーパーを作り出すか？
これらの質問は、プロトコルテキストを超えた経済的および運用上の証拠を必要とする。IAB は権力が蓄積するインターフェースを特定できる。競争当局、購入者、事業者、影響を受けるユーザーは、市場シェア、強制、排除、法的救済を確立するのに適している。アーキテクチャの警告は、完全な市場判断を宣言するのではなく、その証拠を招くべきである。
同じ注意が公共インフラにも適用される。政府は、レジリエンスやセキュリティのために技術的メカニズムを義務付けるべきかどうかを尋ねるかもしれない。IAB は相関リスク、相互運用性の影響、障害伝播を説明できる。公的コストを納税者、事業者、ベンダー間でどのように配分するかを決定することはできない。代替案をテストせずに好ましい展開を「アーキテクチャ上必要」と呼ぶことは、争点のある補助金やコンプライアンス負担に中立的なエンジニアリングの外観を与える可能性がある。
長期的な視野はここで依然として有用である。なぜなら、市場インセンティブはしばしば短期的だからである。企業は自社のサービスを合理的に最適化する一方で、エコシステムの依存度を高める可能性がある。IAB は、単一の規制当局が全体を見る前に、その外部性を名指しできる。その民主的な限界は診断を減じるものではない。それは誰が分配的な応答をしなければならないかを特定する。
ワークショップは無視された問題を明らかにし、招待リストを再生産する
RFC 2850は、IAB が IETF、IRTF、および他の組織での作業を含むアーキテクチャ問題の深いレビューのために招待ワークショップを開催することを認可している。ワークショップは、問題が明らかなワーキンググループのホームを持つ前に関心を集中させることができる。研究者、実装者、事業者、政策専門家を同じ部屋に集め、耐久性のある報告書を生み出すことができる。
フォーマットは強力である。なぜなら、出席が問題の定義を形成するからである。ワークショップは単に回答を収集するだけではない。どの質問が解読可能か、どの証拠が提示されるか、どのトレードオフが中心的に見えるかを決定する。したがって、招待はアジェンダパワーの一形態である。
専門家の選択は避けられない。ルーティングセキュリティ、暗号化トランスポート、アイデンティティに関するワークショップは、ランダムなグローバルサンプリングによって構成することはできない。参加者は進歩するために十分な共通知識を必要とする。しかし、技術的な関連性は出版履歴や IETF 会議での可視性よりも広い。第一線の事業者は、プロトコル作者が見逃す展開制約を知っているかもしれない。アクセシビリティ研究者、小規模実装者、制約のある市場のユーザーは、大規模プラットフォームには見えない排除効果を観察するかもしれない。公的機関は法的義務を理解している一方、影響を受けるコミュニティはそれらの義務が実際にどのように機能するかを示すかもしれない。
報告書は、参加者が名前の挙げられたすべてのグループを代表していることを示唆すべきではない。選考の根拠を公開し、欠けている視点を特定し、ワークショップの合意と IETF コンセンサスを区別し、重要な意見の相違を記録し、公的な修正を招くべきである。参加コストや秘密保持が広がりを制限する場合、その制限は結論とともに伝わるべきである。
フォローアップは会合と同じくらい重要である。ワークショップの調査結果は、招待されなかった人々が前提に挑戦し、実装証拠を追加できるオープンな場所に入るべきである。IAB が後日声明を発行する場合、より広範なコメントが結果にどのように影響したかを示すべきである。
これはワークショップをプレビシットにするものではない。正直な専門家の手段にする。目的は人口統計的な完璧さではなく、慎重に選ばれた部屋がインターネットを語っているという誤った推論への抵抗である。
連絡権限は、聴衆が強力であっても狭い
IAB の外部役割は、アーキテクチャの声を外交的に見せることができる。RFC 4052は、IAB が他の標準化団体、コンソーシアム、業界フォーラムとの連絡関係を管理すると述べている。目的は、重複作業の回避、技術的依存関係の管理、IETF 仕様の品質向上を含む。RFC 4691は、連絡マネージャーのためのガイダンスを提供している。
これらの関係は不可欠である。インターネットプロトコルは他の場所で行われた作業に依存し、他の組織は IETF 仕様に依存する。あるフォーラムでの見落とされた変更は、互換性のない標準や重複作業を生み出す可能性がある。指名された連絡マネージャーは継続性を提供し、メッセージが適切な技術グループに到達することを確実にする。
継続性は委任された政策権力と誤解される可能性がある。連絡担当者はしばしば両方の組織に存在する数少ない人物の1人であり、IETF が立場を形成する前に「IETF の立場」を求められるかもしれない。繰り返しとアクセスは、情報提供の役割を代表に見せることができる。
救済策はメッセージの規律である。連絡担当者は事実を報告し、公開されたコンセンサスを説明し、関連作業を特定し、適切な場で明示的に認可された声明を伝えることができる。連絡担当者は個人のアーキテクチャの選好からコミュニティポリシーを推測すべきではない。受け取る組織は、個人の評価、IAB の見解、IETF ワーキンググループの結果、または承認された IETF コンセンサス文書を聞いているのかを知るべきである。
IAB の憲章言語自体は、関係を技術的および関連する組織問題に狭め、IETF の技術的任務への実証可能な価値を期待している。これは、規制当局や公的機関との関与を禁じるものではないが、連絡機能が「インターネット」の一般的な外務省になるのを防ぐ。
外部組織は、正当性を外部委託することなく、IAB の専門知識を歓迎すべきである。電気通信規制当局は BGP 依存関係のアーキテクチャ説明に頼るかもしれない。しかし、影響を受ける事業者に相談し、自らの法令を適用し、比例性を評価し、執行を所有しなければならない。標準化団体は IETF メカニズムを適応させるかもしれない。自らのルールの下でコンセンサスを確立しなければならない。IAB はシステム間の結果を可視化できる。別の組織の権威を供給することはできない。
公共政策への警告は価値と限界の両方を示す
IAB は標準開発以外の提案に対処するために声明を使用してきた。2019年のインターネットインフラへの意図しない害を避けることに関する声明は、法的なアクセスや制御要件がインフラサービス、信頼関係、将来のインターネット発展にどのように損害を与えるかを説明した。そして、広範な法的メカニズムがコア機能を危険にさらす可能性がある場合、ネットワーク事業者、DNS 事業者、認証局間の通信に対する明確な免除を促した。
その介入は、アーキテクチャ警告の公共的価値を示している。立法者は、同じ言語がルーティング、ネーミング、公開鍵インフラに及ぶことを見ずに、アプリケーションやサービスを規制するかもしれない。IAB はこれらの依存関係を追跡し、一見局所的な義務がシステムリスクを生み出す理由を説明できる。沈黙は中立ではない。関連する専門知識を差し控えることになる。
2023年のソフトウェアおよびハードウェアアテステーションに関する声明は、同様の機能を果たしている。アテステーションの不正防止効用を認識しつつ、オープンプロトコルへのアクセスを承認されたクライアント状態に依存させることが、開放性と独立した実装を減らす可能性があると警告している。読者を、より安全な展開モデルを探求できる IETF の作業に向けて誘導している。
どちらの声明も公的な国民投票として読まれるべきではない。IAB は政策に技術的結果があることを実証でき、設計者がそれらを避けることを推奨できる。しかし、すべてのユーザーが開放性、セキュリティ、詐欺削減、合法的なアクセスを同じようにランク付けすると主張することはできない。公的機関は、アーキテクトだけでなく、虐待の被害者、サービスプロバイダ、セキュリティ研究者、事業者、権利保持者の意見も聞かなければならない。
したがって、IAB 関与の最も強力な形式は4つの部分を持つ。技術的メカニズムを特定する。影響を受けるアーキテクチャ特性を述べる。不確実性と代替案を説明する。主張を支持できる結果に限定する。外部の意思決定者はその後、自らの名前で公共の選択を説明する。
この分割は警告を弱めない。技術組織が決して所有していなかった政治的委任を主張したように見えるため、反対者が健全なエンジニアリングを却下するのを防ぐ。
ユーザーと事業者はミッションに含まれているが、自動的に部屋にいるわけではない
RFC 3935は、IETF の作業は実装者、ネットワーク構築者、ネットワーク事業者、ユーザーに関連するべきであると述べている。また、組織ではなく個人が参加の基本単位であるとも述べている。この組み合わせは、オープンな技術的貢献を保護するが、代表のギャップを残す。
参加する事業者は運用証拠をもたらす。その人物は、すべての顧客や同様の条件のすべてのネットワークに代わって加重投票をするわけではない。ブラウザエンジニアは実装知識をもたらすが、ブラウザのすべてのユーザーを代表するわけではない。公務員は公共セクターの依存関係を説明できるが、州からの民主的な権威を持っているわけではない。個人参加はコーポラティストの席割り当てを防ぐ。しかし、制度を消すわけではない。
リソースは、誰の個人の声が持続するかを形成する。雇用主は旅費、会議時間、長年の専門家作業を支払う。英語の流暢さ、タイムゾーン、接続性、メーリングリストの議論への精通度は可視性に影響する。主にユーザーとして影響を受ける人々は、どのアーキテクチャの議論が将来のサービスを形成するかを知らない可能性があり、結果が可視になる頃には設計語彙は確定している。
IAB は代表を発明することでこれを解決できない。証拠を改善することはできる。主要な声明については、影響を受けるシステムを誰が運用しているか、代替手段を選べないのは誰か、移行コストを誰が支払うか、障害を誰が経験するかを尋ねることができる。展開調査を委託し、文書化された反例を招き、地域の運用者フォーラムを活用し、ユーザーの証拠が間接的である場合に報告することができる。
協議は劇場になるべきではない。会議の長いリストは、懸念が結論を変えたことの証明ではない。IAB は学んだこと、どの前提が改訂されたか、どの異議が未解決のままかを示すべきである。ユーザーや事業者の懸念を技術的理由で却下する場合、最も強いバージョンに回答すべきであり、会場の開放性を引用するべきではない。
結果は代表民主制ではない。コメントへのアクセスと統治の権限の違いを知っている、説明責任を負う専門知識である。
運用経験は結果の証拠であって、譲渡可能な投票権ではない
IETF は実行コードと運用経験を正しく重視している。紙上ではエレガントに見える設計が、ルートチャーン、部分的な展開、ミドルボックス、断続的な接続性、長期の機器交換サイクルの下で失敗する可能性がある。事業者はしばしばこれらの条件を標準作者より早く見る。彼らの証拠はその品質と関連性に比例した重みを持つべきである。
しかし、運用権限は過大評価される可能性がある。大規模ネットワークは大規模ネットワークを観察する。そのトラフィック、ベンダー関係、スタッフ、リスク許容度は、コミュニティ ISP、大学、モバイルネットワーク、公的機関、制裁下で限られた供給で運用されるネットワークとは異なるかもしれない。1人の事業者の展開可能性の結果は、事業者のプレビシットではない。
逆の誤りは、事業者が代表性を主張できないという理由で却下することである。証拠は真実であるために選挙委任を必要としない。単一の再現可能な障害は普遍的な技術的主張を否定できる。IAB は、観察が一般化できるかどうかを尋ねるべきであり、観察者がセクターを代表しているかどうかを尋ねるべきではない。
ユーザーの証拠は収集がより難しい。なぜなら、ユーザーはプロトコル層ではなくアプリケーションと機関を経験するからである。人はサービスにアクセスできなくなったことを知っていても、アテステーション、ネーミング、トランスポートポリシー、証明書処理が原因であることを知らないかもしれない。アーキテクトは、ユーザーがプロトコル専門家になることを要求せずに、報告された効果を技術的メカニズムに結びつける方法を必要とする。
これは層状の証拠実践を示唆している。観察された結果で始める：停止、排除、監視露出、切り替え不能、過剰な運用コスト。技術的依存関係を追跡する。効果が実装や地域を超えて現れるかテストする。その後、エンジニアリングの調査結果と受容性に関する規範的判断を分離する。
IAB の役割はトレーシングステップで最も強い。層を結びつけ、なぜ局所的な設計が遠くの効果を引き起こすかを説明できる。事業者とユーザーは事実ベースを強化する。公共または組織の意思決定者は分配と救済を判断する。いかなる層も他の層の権威を借用しない。
報告はこの分離を反映すべきである。声明は、複数のネットワーククラスの事業者が失敗を報告し、利用可能なテストが定義された条件下でそれを再現したと述べるかもしれない。「事業者がポリシーを支持している」とは、その命題を確立できる方法が実際に使用されない限り言うべきではない。同様に、公開コメント期間は受け取った見解を示すことができ、沈黙したユーザーの選好を示すことはできない。
経験を証拠として扱い、代表として扱わないことは、技術的品質と民主的な誠実さを同時に向上させる。小さなネットワークがグローバルな前提を修正することを可能にし、グローバルな構成員であるふりをする必要はない。
アーキテクチャの発言は可視的な主張の分類法を必要とする
多くの混乱は、行われている主張の種類にラベルを付けることで取り除くことができる。アーキテクチャの声明は通常、少なくとも5つを混在させている。
制約主張は、設計が特定された条件下で要求される要件を満たせないと言う。プロトコルロジック、測定、実装証拠によって支持されるべきである。リスク主張は、設計が障害の確率または影響を増加させると言う。メカニズム、露出、不確実性を必要とする。予測は、採用が集中、硬化、断片化を引き起こすと言う。後で確認できる前提と指標を必要とする。
価値主張は、開放性、プライバシー、分散化、ユーザー制御が優先されるべきと言う。IETF ミッションに関連付けられ、選択として認識され、技術的不可避性として偽装されるべきではない。管轄権勧告は、別の組織が行動すべき、または行動を控えるべきと言う。なぜ IAB が話す資格があるのか、そして受け取る組織の独立した権限がどこから始まるのかを特定しなければならない。
1つの文書がすべて5つを含むことができる。問題は混在ではなく曖昧さである。制約として提示された予測は議論を閉じる。価値がプロトコル事実として提示されると分布が隠れる。管轄権勧告が「アーキテクチャが要求する」として提示されると、実際の意思決定者から責任が移される。
したがって、各 IAB 声明には、コンパクトな権威と証拠の注記を含めるべきである：使用された憲章機能、見解が採用されたプロセス、基礎となる IETF コンセンサスのステータス、重要な証拠、既知の反対意見、協議された影響を受けるグループ、不確実性、要求される行動。これは短い技術注記を負担にしない。詳細は外部結果に応じて拡大縮小できる。
IAB はまた、自らのために話すことと IETF コンセンサスを伝えることを区別すべきである。RFC 2850は IAB 調査結果を認可する。すべての調査結果をすべての IETF 参加者によって承認された声明にするわけではない。正確な帰属は両方の組織を保護する。
外部の読者が最も恩恵を受ける。裁判所、規制当局、標準化団体は、権威の源泉を誤解することなく、技術的結論に適切な重みを与えることができる。ラベルが明確であればあるほど、IAB はより自信を持って声を使うことができる。
反対意見はアーキテクチャの証拠であり、広報上の欠陥ではない
RFC 2850は、定義された同意と反対の制限の下で全会一致なしでの行動を許可している。これは意見の相違が予想されていることを意味する。しかし、組織は首尾一貫した散文を必要とするため、公共の出力はしばしば単一に聞こえる。危険は首尾一貫性が不確実性を消し去ることである。
重大な反対意見は、システムの異なるモデル、多数派の証拠に欠けている展開条件、または最終声明が圧縮する価値の衝突を明らかにできる。反対者の同意を得て、個人化せずにその意見の相違の実質を公開することは、製品を改善する。
すべての異議が少数意見報告書に値するわけではない。無限の付録はアドバイスを使用不能にし、メンバーは審議中に考えを変える自由が必要である。関連する閾値は重要性である：外部の読者が、前提が争われていることを知っていれば、アーキテクチャリスクを異なって評価するだろうか？意見の相違は証拠、予測、価値、管轄権のどれに関するものか？
反対意見を記録することは、選出をイデオロギー的バランスに変える圧力も減らす。NomCom はすべてのアーキテクチャ学派や影響を受ける人口のために代表者を確実に任命することはできない。不確実性を可視化する文化は、将来のすべての意見の相違をメンバー構成にエンコードしようとするものよりも適応性が高い。
レビュー日付も同じ理由で重要である。新興技術に関する声明は、新しい展開証拠がいつ検討されるかを特定すべきである。RFC 1958の絶え間ない変化の原則は、制度的なアドバイスに適用される。IAB は、インターネットが変わるときに結論を改訂、狭め、撤回する用意があるべきである。
アーキテクチャ委員会は、時代を超えて正しいことではなく、訂正を可能にすることで信頼を得る。公開された反対意見とスケジュールされたレビューは、名声が慣性になるのを防ぐための管理手段である。
外部の意思決定者は、名声への訴えではなく、採用テストを必要とする
IAB の見解が立法、規制、調達、または別の標準システムに入るとき、受け取る組織は一連の質問に答えるべきである。
具体的にどの技術的主張が採用されているのか？どの IAB 文書と日付がそれを支持しているか？声明は IETF コンセンサス、IAB 結論、ワークショップ調査結果、個人の連絡評価を報告しているか？どの実装証拠が存在するか？どの前提が採用機関の領域に一致するか？公開以降何が変わったか？
採用者はその後、IAB が提供できないものを供給しなければならない。行動を許可する法的または制度的権限は何か？誰が影響を受けるか？どの代替案が検討されたか？コストはどのように分配されるか？どのような例外と救済が存在するか？技術的証拠が変わった場合、要件はどのように変わるか？
このテストは2つの対称的な誤りを防ぐ。1つはテクノクラシーである：「IAB がそう言う」だけでルールを課すのに十分になる。もう1つはポピュリスト的な却下である：専門家が選出されなかったため、専門家証拠が無視される。民主的な制度は日常的に専門知識に依存している。その責任は、評価し、公共行動への変換を所有することである。
他の技術組織も同じ規律を必要とする。連絡関係は、ある標準化団体を別の標準化団体に従属させるものではない。各組織には独自のスコープとコンセンサス手続きがある。IAB は依存関係と衝突を特定できるが、ピア組織はその任務の下で決定する。
外部機関が変換を説明できない場合、IAB を権威ではなく証拠として引用すべきである。その表現は責任の連鎖を保持する。アーキテクチャは選択を情報提供する。アーキテクチャ組織の外にいる人々に代わって選択をするわけではない。
IAB はシステムについて自信を持って、構成員について謙虚に話すべきである
1992年の論争は永続的な問題を確立した：組織は助言を意図するが、聴衆は決定を聞く。答えはアーキテクチャの発言を暫定的なコメントに減らすことではない。いくつかのリスクは直接的な言語に値する。脆い依存関係は、その説明に制度的謙虚さが含まれているからといって、脆弱性が減るわけではない。
制度的な聴衆にも義務がある。ジャーナリストは IAB の警告を「インターネットが決定した」に短縮すべきではない。ベンダーはアーキテクチャ観察を認証として宣伝すべきではない。政府は IAB 声明を協議の代わりに引用すべきではない。他の標準化団体は連絡メッセージを上位組織の指示として扱うべきではない。正確な受信は正当性の連鎖の一部である。
IAB は、重要な声明のための安定したカバーノートを公開することで、その受信を容易にできる。ノートは、承認組織、決定日、文書ステータス、関連する憲章役割、IETF コンセンサスとの関係、証拠期間、訂正の連絡先を特定すべきである。急速に変化する技術に対処する声明では、レビュー期間を特定すべきである。これらは小さな管理的行為であり、大きな解釈的価値を持つ。
訂正は元の主張と同じくらい広く伝わるべきである。展開証拠が後に警告を狭める場合、最初のバージョンが規制当局に送られたり、ベンダーによって広く引用されたりしたときに、静かなアーカイブエントリを更新するだけでは不十分である。IAB は既知の受信者に通知し、可視的な履歴を保持すべきである。組織が証拠がどのように考えを変えたかを示すとき、権威は弱まるどころか強まる。
自信は支持された命題に付くべきである。提案された制御がエンドツーエンド認証を壊すなら、そう言う。設計が排他的なアテステーションゲートを作り出すなら、特定する。利用可能な証拠が市場の結果を確立できないなら、それも言う。精度は制度的壮大さより強い。
謙虚さは構成員の主張に付くべきである。IAB は IAB として話すことができる。IETF が形成した立場を伝えることができる。相互運用性と長期的な技術的健康の利益を記述できる。すべてのユーザーと事業者を調査した、または選出されたことを示唆すべきではない。
その説明責任メカニズムは依然として不可欠である。NomCom 選出、Internet Society 確認、公開議事録、公開会合、公開調査結果、上訴義務、リコールは、組織が自己完結型の権威になるのを防ぐ。それらは、アクセシビリティ、集中、運用経験の多様性について評価されるべきである。しかし、これらのメカニズムの改善は技術評議会をグローバルな選挙民に変えるものではなく、その必要もない。
より良い憲法上の和解は差別化された権威である。ワーキンググループは仕様を開発する。IESG は標準アクションを管理する。IAB は地平線を見渡し、アーキテクチャをレビューし、調査を招集し、システムリスクを説明する。外部組織は自らの任務内で決定する。ユーザーと事業者は証拠を提供し、決定が固まる前に到達するように設計されたチャネルを通じて前提に異議を唱える。
長期的な技術ビジョンは、それを維持できる組織がほとんどないため、まさに公共財である。IAB は、狭い決定が後で何をもたらすかをインターネットに伝えるときに、その財を保護する。予見の名声が、予見者を選んだことのない人々を統治する主張に引き伸ばされるとき、それを危険にさらす。アーキテクチャの声は、知っていることについて明確であり、価値についてオープンであり、代表していない人々について正確であるときに最も正当である。