Zenn
⚖️

RFC 9518: 集権化、分権化、そしてインターネット標準

2023/12/27に公開
RFC
informational
tech

要旨

インターネット標準の取り組みに関連する集権化の側面について論じる。標準化団体には多くの集権化の形態を防ぐ能力に限界はあるものの、それでもインターネットの分権化を支援する貢献はできる、というのが本文書の主張である。

本文書の位置付け

本文書はインターネット標準化過程の仕様書ではない。情報提供を目的として公開する。

これは、RFCシリーズへの貢献であり、他のRFCストリームとは無関係である。RFC 編集者はその裁量でこの文書の公開を選択したものであり、実装や展開におけるこの文書の価値について何ら表明するものではない。RFC編集者によって発行が承認された文書は、あらゆるレベルのインターネット標準の候補となるわけではない。RFC 7841のセクション2を参照のこと。

文書の現在の位置付け、正誤表、フィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9518 で入手できる。

著作権表示

Copyright (c) 2023 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。

本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。

1. はじめに

インターネットの決定的な特徴の1つは、技術的、政治的、経済的制御の単一点が存在しないことである。おそらく、その特徴がインターネットの早期採用と広範な普及に役立ったことは間違いない。インターネットに接続したり、インターネット上にアプリケーションを展開したり、特定の目的のためにインターネットを使用することに許可は必要ないため、インターネットは多様なニーズを満たし、さまざまな環境で展開することができる。

このような状態を維持することは、依然として広く共有されている目標ではあるが、人々が「インターネット」と見なすさまざまなサービスやアプリケーションの範囲において、一貫してこの状態を維持することは難しい。Network News Transfer Protocol (NNTP)や電子メールのような初期のサービスには、複数の相互運用可能なプロバイダが存在したが、今のコンテンツやサービスのプラットフォームの多くは、相互運用可能な代替手段がないまま、単一の営利組織によって運営されている。その中にはインターネットそのものと間違われるほど有名になり、人々の経験にとって重要なものになっている[Komaitis]。

このような難しさは、インターネットの集権化を抑制するために、アーキテクチャ設計、特にIETFのようなオープン標準化団体が監督するアーキテクチャ設計が、どのような役割を果たすことができるのか、また果たすべき役割に疑問を投げかけている。

本文書では、インターネット機能の集権化を回避するためには分権型の技術標準が必要かもしれないが、集権化は標準化団体のコントロールの及ばない非・技術的要因によって引き起こされることが多いため、その目標を達成するには分権型の技術標準だけでは十分ではないと論じている。その結果、標準化団体はあらゆる形態の集権化を防ぐことに固執すべきではなく、むしろ、作成する仕様は分権型運用を保証するための措置を講じるべきである。

本文書は、IETFコミュニティで広く議論されてはいるが(謝辞のセクションを参照)、コミュニティの総意ではなく、著者の見解を表しているに過ぎない。主な対象読者は、インターネット・プロトコルを設計し、標準化するエンジニアである。プロプライエタリなプロトコルやアプリケーションの設計者は、特に、最終的な標準化の検討を意図している場合、これらの問題を考慮することで利益を得ることができる。政策立案者は、集権的なプロトコルやアプリケーションが関与する不正行為を特徴づけ、それらに対する改善案を評価するために、この文書を利用できる。

セクション2では、集権化を定義し、集権化は望ましくないことが多いが、場合によっては有益なことがある理由を説明し、インターネット上で集権化がどのように生じるのかを考察する。セクション3では、分権化について検討し、いくつかの関連する戦略とその制限について説明する。セクション4では、集権化をコントロールする上でインターネット標準が果たすことのできる役割について提言する。セクション5では、今後の作業領域を確認して締めくくる。

2. 集権化 (Centralization)

本文書において、「集権化」(centralization)とは、単一の存在またはその少数のグループが、インターネット機能の運用や利用を独占的に監視、捕捉、コントロール、または利益を得る状態をいう。

ここでいう、「存在」(entity)とは、個人、グループ、企業などである。組織は、集権化のリスクを軽減するガバナンスの対象となるかもしれないが(セクション3.1.3を参照)、その組織は依然として集権化された存在である。

「インターネット機能」(Internet function)は、本文書では広く使用されている。最も直接的には、IP[RFC791]、BGP[RFC4271]、TCP[RFC9293]、HTTP[HTTP]などの標準によってすでに定義されている実現プロトコル(enabling protocol)かもしれない。また、新しい実現プロトコルの提案や、既存のプロトコルの拡張の場合もある。

人々のインターネット体験は、標準で定義されたプロトコルやアプリケーションに限定されるものではないため、この文書では、ソーシャル・ネットワーク、ファイル共有、金融サービス、ニュース配信など、標準の上に構築された機能の集権化についても検討する。同様に、インターネットを実現するテクノロジーとして機能するネットワーク機器、ハードウェア、オペレーティング・システム、ソフトウェアも集権化に影響を与える可能性がある。特定の地域や状況にあるエンドユーザへのインターネット接続の提供は、ネットワーク間のトランジット(いわゆる「ティア1」ネットワーク)の提供と同様に、集権化を示すことがある。

この集権化の定義は、すべての種類の集権化を網羅しているわけではない。特に、技術的な集権化(例えば、機器やネットワーク・リンクが単一障害点となるような場合)は、エンジニアに比較的よく理解されている。これは、通常、機能を複数のコンポーネントに分散させることで軽減できる。後述するように、このような技術は、この種の集権化に対処できるかもしれないが、機能のコントロールが少数の手に渡ってしまうことを防ぐことはできない。ケーブルの切断、停電、サーバの故障による障害は、技術コミュニティではよく理解されているが、インターネットの中核機能にゲートキーパーが存在する場合に遭遇する問題とは質的に異なる。

同様に、政治的な集権化(例えば、ある国がインターネット全体に、ある機能をどのように提供するかをコントロールできる場合)も同様に懸念されるが、ここでは深く検討しない。

現在、ある機能に集権化が存在しない場合でも、状況によっては将来、集権化が生じる可能性が高くなる。この文書では、その可能性を特徴付けるために「集権化リスク」を用いる。

2.1. 集権化は有害になる可能性がある

インターネット標準の取り組みに参加している多くのエンジニアは、インターネットの歴史とアーキテクチャを集権化とは相容れないものと考えているため、集権化を阻止し、それに対抗しようとする傾向がある。「相互接続されたシステムの大規模な寄せ集め(heterogeneous collection)」[BCP95]として、インターネットはしばしば、「ネットワークの中のネットワーク」として特徴付けられ、そのオペレータは、他者への強制や服従を要求するのではなく、コミュニケーションを促進することに同意する仲間として関係を結ぶ。このような行動の独立性を重視する考え方は、例えば「自律システム」(autonomous system)の概念など、インターネットの設計に広く浸透してる。

また、集権化を容認できないという態度は、それに関連する次のような潜在的に有害な影響にも根ざしている。

  • 力の不均衡: 第3者が通信に不可避的にアクセスできるようになると、その第3者は、行動の監視(「パノプティコン効果」)や方向付け、さらには拒否(「チョークポイント効果」)を可能にする情報面・地位面の優位性を獲得する。これらの当事者(あるいは当事者に対して権限を持つ国家)は、強制的な目的のため[FarrellH]、あるいは社会そのものを混乱させるために、その能力を利用する可能性がある。マディソン[Madison]がアメリカの州のすぐれた統治について述べているように、インターネットのすぐれた統治には、適切な抑制と均衡なしに、あらゆる機能に対する力が1 か所に集約されないことが必要である。
  • イノベーションの制限: コミュニケーションをコントロールする能力を持つ当事者は、「許可なきイノベーション」(permissionless innovation)の可能性、つまり、コミュニケーションの相手以外の相手との調整を必要とせずに、予期しない新しいアプリケーションを導入する能力の可能性を排除できる。
  • 競争の制約: インターネットとそのユーザは、多くのプロバイダからアプリケーションやサービスが提供され、特にユーザが相互運用可能な標準に基づいて独自のアプリケーションやサービスを構築できる場合、激しい競争から恩恵を受ける。適切な代替手段がないために集権的なサービスやプラットフォームを使わなければならない場合、それは事実上不可欠な機能となり、権力乱用への扉を開くことになる。
  • 可用性の低下: インターネット(およびその上に構築されたアプリケーションやサービス)の可用性は、アクセスする方法が多数ある場合に向上する。サービスの可用性は、集権的な大規模プロバイダの集中的な配慮(focused attention)から恩恵を受けることができるが、そのプロバイダに障害が発生すると、可用性に過度の影響が及ぶ可能性がある。
  • モノカルチャー: 集権的なプロバイダが利用できる規模は、些細な機能の欠陥が拡大し、広範な影響を与える可能性がある。例えば、ルータの単一のコードベースはバグや脆弱性の影響を大きくする。コンテンツの単一の推奨アルゴリズムは、社会的に深刻な影響を与える可能性がある。多様性のある機能の実装は、「進歩は、多くのエージェントが自由に対話する試行錯誤の進化プロセスの結果」であるため、体系的に見た場合、より堅牢な結果につながる[Aligia]。
  • 自己強化: 広く指摘されているように(例: [Abrahamson]を参照)、集権的なプロバイダがデータにアクセスすることで、提供するサービスを改善する機会を得ることができる一方で、他のプロバイダにそのようなアクセスを拒否することができる。

これらの弊害と集権化の関係は複雑なことが多い。集権化が必ずしもこうした弊害につながるとは限らず、そうであったとしても、常に直接的かつ単純なトレードオフがあるとは限らない。

例えば、集権化と可用性の関係を考えてみる。中央で運用されるシステムは、大規模オペレータが利用できるリソースのため、より可用性が高くなる可能性はあるが、その規模が大きいため、障害が発生したときの影響はより大きくなる。分権型システムは、ある種の障害に対して、回復力は高くなるが、他の点ではそれほど回復力が高くなるわけではない。例えば、システム的な問題への対応能力が低下し、全体としてとより多くのセキュリティ脆弱性にさらされるかもしれない。このように、集権化がすべての場合において可用性を低下させるとは言い切れないし、すべての場合において可用性を向上させるとも言い切れない。

この葛藤は、クラウドやモバイル・インターネット・アクセスのような分野で見られる。人気のあるクラウド・ホスティング・プロバイダが(技術的な理由であれ、他の理由であれ)利用できなくなった場合、多くのインターネット体験が中断される可能性がある(特に、最近のウェブサイトには複数の依存関係があることが多いため、[Kashaf]参照)。同様に、大手電話会社で発生した問題が広範な障害を引き起こしたように[PHONE]、大規模なモバイル・インターネット・アクセス・プロバイダが、数十万人以上のユーザに影響を与える障害を起こすかもしれない。

どちらの場合も、サービスは技術的には集権化されていない。これらの事業者には、複数の冗長性を確保し、さまざまな技術を使用して1つのコンポーネントに障害が発生するリスクを軽減するという強いインセンティブがある。しかし、一般的には、単一のコードベース、限られたハードウェアの選択、一つにまとめられたコントロール・プレーン、規則正しい管理慣行に依存しており、それぞれが広範な障害を引き起こす可能性がある。

(昔の電話ネットワークのように)これらのサービスを提供するプロバイダが1社しかなければ、可用性に深刻な影響を与える形で集権化されていると考えられる。しかし、多くのクラウド・プロバイダが同様のサービスを提供している。ほとんどの場所で、複数の携帯電話会社が利用できる。そのため、機能の利用者が他のプロバイダに切り替えたり、複数のプロバイダを同時に利用することができるため、集権化とその可用性の間に関連性があるという議論は弱くなる。セクション4.4を参照。

このような状況は、集権化と特定の機能の可用性との関係を検討する際に、探求すべき分野の1つであることを示唆している。それは、他のプロバイダに切り替えたり(これにより、中断を一時的なものにし、管理可能にする)、複数のプロバイダを同時に利用することに、どのような障壁があるのかということである(一つの事業者の障害を覆い隠す)?

競争上の制約を評価する際にも、ニュアンスの必要性を示す例が見られる。さまざまなインターネット機能の提供の競争力を高めることは、多くのエンジニアにとっての動機付けとなるかもしれないが、関連市場を定義し、ある行為が反競争的であると判断する権限を有するのは裁判所(場合によっては規制当局)だけである。特に、市場集中(market concentration)は必ずしも競争上の問題を示すとは限らない。したがって、技術コミュニティでは望ましくない集権化とみなされるものは、競争規制の対象にならないかもしれない。

2.2. 集権化が役立つ

上記のような集権化がもたらす潜在的な悪影響は、広く認識されている。あまり広く調べられてはいないが、一部のプロトコルやアプリケーションがその機能を提供するために集権化に依存しているものがある。

集権化は、技術的な必要性から行われることが多い。例えば、グローバルに調整された「信頼できる情報源」(source of truth)は、本質的に集権的である。例えば、人に優しい名前をグローバルに一貫した方法でネットワークアドレスに変換することができるドメインネームシステム(DNS)のルートゾーンなどである。

また、IPアドレスの割り当てを考えてみる。インターネットのルーティングでは、アドレスが一意に割り当てられる必要があるが、もし単一の政府や企業がアドレス割り当て機能を掌握すれば、インターネット全体がその存在によって悪用される危険にさらされることになる。同様に、ウェブの信頼モデルは、ブラウザとサーバ間の通信の信頼のルートとなる認証局(CA)を必要とし、集権化のリスクを持っている。これは、システムの設計で考慮される必要がある。

「ランデブー問題」を解決する必要のあるプロトコルは、直接接触していない2者間の通信を調整するため、集権化を必要とする。例えば、チャット・プロトコルは、会話を希望する2者間の通信を調整する必要がある。実際の通信は2者間で直接行うことができるが(プロトコルがそれを容易にする限り)、エンドポイントの相互発見は通常、ある時点で第3者を必要とする。この2者の観点から見ると、ランデブー機能には集権化のリスクがある。

厳密には必要でない場合でも、集権化は機能の利用者や社会に利益をもたらすことがある。

例えば、規模の経済がもたらす効率性が集権化につながる可能性があることは、古くから認識されている[Demsetz]。こうした効率性は、より質の高い製品やより低いコストとして利用者に還元され、小規模では実現できなかった機能の提供も可能にすることさえある。

金融サービス(例: クレジットカード処理)のような複雑でリスクの高い機能は、必要な集中的な注意と専門知識を受けることができる少数の専門組織に集中することが多い。

集権化は、有益なコントロールを課す機会を提供することもある。シュナイダー[Schneider2]は、「集権的な構造には、国民が限られた注意を監視に集中させることができたり、より説明能力の低いブロック(bloc)が出現しても、それに対抗できる権力ブロックを形成できるといった利点(virtues)があると指摘している。政府、企業、非・営利組織など、ここ数世紀で広く敬意を集めてきた集権的構造は、その構造に組み込まれた意図的な設計による部分が少なからずある。」

これは、ある機能が共通の目標を実現し、少数派の利益を守るためにガバナンスを必要とする場合に見られる。例えば、コンテンツ・モデレーション機能は、コミュニティの価値を押し付けるものであり、それは多くの人にとってメリットとなる。もちろん、ガバナンスの仕組みの監視、透明性、説明責任が不十分であれば、不適切なコントロールが課せられるチョークポイントとみなすこともできる。

結局のところ、どのような場合に集権化が有益かを判断するのは、判断の分かれ目である。プロトコルの中には、集権化された機能がなければ運用できないものもあれば、ある機能が集権化された方が、特定のユースケースにおいて大幅に強化されるものもあるし、単に効率が良くなるだけのものもある。しかし、一般的には、集権化が最も懸念されるのは、集権化が必要または有益であると広く認められていない場合である。それは、抑制、均衡、その他の説明責任の仕組みがない場合、置き換えるが難しい(または不可能な） 「お気に入り」を選択する場合、そして、インターネットを成功に導いているアーキテクチャ上の特徴を脅かす場合である。

3. 分権化

「分権化」(decentralization)という用語は、経済、政治、宗教、国際開発において使用されてきた長い歴史がある。バラン[Baran]は、コンピュータ・ネットワークに関連する最初の定義の1つを、「単一点への完全な依存が必ずしも必要ではない」場合の条件として示した。

このような技術的な集権化は(重要なテーマではないが)比較的よく理解されている。技術的なツール(プロトコル設計など)のみを用いて、非・技術的なものを含むあらゆる形態の集権化を回避することは、かなり難しい。いくつかの問題に直面している。

まず、最も批判的に言えば、技術的な分権化対策は、非・技術的な形態の集権化に対して、せいぜい限定的な効果しか持たないということだ。または、シュナイダー[Schneider1]によれば、「分権化されたテクノロジーだけでは分権化された結果は保証されない。」セクション3.1で後述するように、技術的措置は必要ではあるが、機能の完全な分権化を達成するには不十分である、と特徴づけられる。

第2に、機能を分散させるには、集権化された機能では直面しない課題を克服する必要がある。分権化された機能は、多くのさまざまなアクター間の調整が必要になることが多いため、ユーザのニーズ(例えば、新機能の導入やユーザ・インタフェースの実験など)に適応することがより難しくなる場合がある[Marlinspike]。機能設計を改良するために使用できるデータと同様に、規模の経済は集権化された機能ほど有効である。これらの要因はすべて、サービス・プロバイダにとって集権型ソリューションがより魅力的なものとし、場合によっては、分権型ソリューションが不経済になる可能性がある。

第3に、機能のどの側面を分権化するかを特定するのが難しい場合がある。というのも、集権化のさまざまなタイプや原因には多くの相互作用が存在することが多く、また、集権化が明らかになるのは、その機能が大規模に展開された後であることもあるからである。分権化の取り組みは、集権化を単に別の場所(例えば、ガバナンス、実装、展開、補助的機能など)に移す効果だけをもたらすことが多い。

例えば、ウェブはその初期には分権化の力であると構想され、広く信じられていた。大規模なウェブサイトがネットワーク効果をうまく活用し(そして、相互運用を禁止する法的規制を確保し、その結果、スイッチング・コストが増加した。[Doctorow]参照)、ソーシャル・ネットワーキング、マーケットプレイス、および同様の機能で優位に立ったときに初めて、集権化を実現する手段としてのその可能性が明らかとなった。

第4に、当事者によっては、「十分に分権化される」とは何を意味するのかについて、それぞれの信念、認識、目標に基づき、善意の相違を持つかもしれない。集権化が連続体(continuum)であるように、分権化も連続体であり、「正しい」レベルやタイプは何か、さまざまな形態の集権化を相互に比較検討する方法、あるいは潜在的な集権化を他のアーキテクチャ上の目標(セキュリティやプライバシーなど) とどのように比較検討するかについて、誰もが同意するわけではない。

こうした葛藤は、例えばDNSで見られる。システムのいくつかの側面は分権化されているが -- 例えば、検索機能をローカルサーバに分配し、ユーザが上書きするオプションを持つなど -- DNSの本質的に集権的な側面は、名前空間としての運用にある。つまり、単一のグローバルな「信頼できる情報源」であり、その管理には(有益であるとしても)固有の集権化がある。ICANNは、マルチステークホルダーのガバナンスを通じて、関連リスクを軽減している(セクション3.1.3を参照)。多くの人は、この取り決めで十分であり、望ましい性質(名前空間の運用にコミュニティ標準を課す能力など)を備えている可能性さえあると考えているが、ICANNによるDNSの監視を不当なものとして拒否し、ヒューマン・ガバナンスではなく分権型合意プロトコル[Musiani]に基づく分権化を支持する人もいる。

第5に、分権化には、特に集権化の可能性を他の場所で開く場合、プロトコル参加者間の力関係の調整は避けられない。シュナイダー[Schneider2]が指摘するように、分権化は「提案された社会秩序のある側面に注意を向けさせ、他の側面から注意をそらす修辞的戦略として機能するように見える」ため、「社会的、文化的、政治的考慮事項を真剣に考慮するための代替品としてテクノロジーを受け入れることはできない」。あるいは、もっと率直に言うと、「ガバナンス・メカニズムが整備されていなければ、ノードが共謀し、人々が互いに嘘をつき、市場が不正に操作され、市場に出入りする人々に多大なコストがかかる可能性がある。」[Bodo].

例えば、ブロックチェーン・ベースの暗号通貨は、技術的な手段によって既存の通貨に内在する集権化に対処することを目的と称しているが、その多くは投票/マイニング力、資金の分配、コードベースの多様性によって、かなりの力の集中を示している[Makarov]。技術的手段への過度の依存は、集権化を含む独自のリスクを伴う潜在的で非・公式な権力構造を生み出す機会ももたらす[Freeman]。

全体として、機能の分権化にはかなりの労力が必要であり、本質的に政治的であり、結果についてはかなりの不確実性を伴う。分権化をより大きな社会的目標として考える場合(この用語は他のコンピューティング以外の文脈でどのように使われるかという精神に則って)、単に技術的機能を並び替えるだけでは失望につながるかもしれない。「分権型ネットワークは、自動的に平等主義的、公平、公正な、または単なる社会的、経済的、政治的景観をもたらすわけではない」 [Bodo]。

3.1. 分権化戦略

このセクションでは、インターネット機能を分権化するために採用されているいくつかの一般的な戦略を検討し、その限界について説明する。

3.1.1. フェデレーション

プロトコル設計者は、フェデレーション、つまり、接続性と相互運用性を維持する独立したインスタンスを使用して単一の一貫したサービスを提供する方法で機能を設計することによって、集権化に対処しようとすることがよくある。フェデレーションは、ユーザが関連付けるインスタンスを選択できるようにし、あるインスタンスから別のインスタンスへの置き換えに対応することで、切り替え(スイッチング)コストを下げることを約束する。

しかし、フェデレーションだけでは機能の集権化を防いだり、和らげるには不十分である。技術的要因以外のものが、集権的なソリューションを使用する圧力を生み出す可能性があるためである。

例えば、電子メール・プロトコル・スイートは、ユーザがネットワークの場所を変更した場合や、長期間切断された場合でも、ユーザにメッセージをルーティングする必要がある。これを容易にするために、SMTP[RFC5321]は、ユーザのメッセージをルーティングする特定の役割、メッセージ転送エージェント (MTA)を定義している。誰でもMTAを展開できるようにし、MTAを相互接続するルールを定義することで、このプロトコルはその役割を担う単一の中央サーバの必要性を回避している。ユーザは、それを他の誰かに委任するか(多くの場合、そうする)、独自のMTAを実行するかを選択できる。

独自のMTAを実行することは、迷惑メールに対抗するために導入されたメカニズムが複雑化したこともあり、年々かなり負担が大きくなっている。こうしたコストは、適切な専門知識とリソースを持つ第3者にMTAを委任するインセンティブを生み出し、市場の集中化を助長している[Holzbauer]。

さらに、MTAが迷惑メールを特定するために使用する手段は、多くの場合、サイト固有である。大規模なMTAは非常に多くのアドレスを処理するため、小規模なMTAでは力の不均衡が生じる。大規模なMTAが小規模なMTAからのメールが不要と判断した場合、そのMTAの機能に大きな影響があり、救済手段はほとんどない。

Extensible Messaging and Presence Protocol (XMPP)[RFC6120]は、フェデレーションに関する別の問題、つまり技術標準の自発的な性質(voluntary nature)を示すチャット・プロトコルである。

電子メールと同様に、XMPPは、許可されている場合に、別のシステムからユーザのランデブーを容易にするために連携する。一部のXMPPの展開では、真のフェデレーション・メッセージングをサポートしている(つまり、サービスAを使用しているユーザがサービスBを使用しているユーザと相互運用的にチャットできる)が、大規模展開の多くはサポートしていない。フェデレーションは自発的(voluntary)であるため、一部の事業者はユーザを単一のサービスに取り込み、グローバルな相互運用性のメリットを意図的に否定している。

上記の例は、フェデレーションによって機能が分散されるために必要な条件を作り出すことはできても、その結果が保証されるわけではないことを示している。

3.1.2. 分権型コンセンサス

分権型コンセンサス技術(ブロックチェーンなど) が集権化の解決策として注目されることが増えている。急速に変化しているこの分野を完全に調査することは、この文書の範囲を超えているが、その特性について一般化することはできる。

これらの技術は通常、暗号技術(多くの場合、追記型トランザクション台帳)を使用して機能の適切な性能を保証する。プロトコルの参加者からなる、時には大規模プールのメンバーに機能の操作を分散させることで、集権化を回避しようとするものである。通常、参加者は未知で信頼されておらず、特定のタスクがノードに割り当てられて処理されることを予測したりコントロールすることはできない。

シビル攻撃(合意形成の判断に影響を与えるだけの参加者を、ある参加者や協調した動きを取る参加者が手軽に作り出す攻撃)は、攻撃者の手に権力を集中させる効果があるため、これらのプロトコルにとって大きな懸念事項である。そのため、プルーフ・オブ・ワーク(各参加者がリソースの大幅な消費を示さなければならない)やプルーフ・オブ・ステーク(各参加者が正しく実行するための他のインセンティブを持つ)のような間接的な手法を使用して、参加者のプールの多様性を奨励している。

このような対策は機能の運用を分権化するのに効果的だが、設計のガバナンス、共有実装の作成、ワイヤー・プロトコルの文書化など、機能の提供の他の側面は依然として集権化される可能性がある。調整の必要性は、機能の運用が分散化されたままであっても、集権化の手段となる。例えば、イーサリアムの「マージ」は、ブロックチェーンが環境問題に対処できるがことを実証したが、それはコミュニティの協調的な努力とガバナンスを通じてのみ可能だった。協調はほとんどの人の目から見れば無害だったが、それでも、集権的であった[ETHEREUM]。

さらに、多くの機能で構成されるプロトコルやアプリケーションは、一部の機能では分権型コンセンサスを使用しても、他の機能では分権化できないため、依然として他の機能で集権化なことがある(最も一般的なのは、ランデブーとグローバル・ネーミングである。セクション2.2参照)。それは、他の機能が分権化できない、あるいは設計者が関連するコストや機会損失を理由に、分権化しないことを選択したためである。

これらの潜在的な欠点はすべての事例において、分権型コンセンサス技術の使用を排除するものではないが、集権化を回避または軽減するために、無批判にこれらの技術に依存することには注意が必要である。分権型コンセンサスを使用すると、プロジェクトのすべての部分に「分権化」が組み込まれると受け取られがちである。

3.1.3. 運用ガバナンス

フェデレーションと分権型コンセンサスはどちらも、複数のプロバイダによる機能提供のための条件を作り出すことはできるが、それを保証することはできない。しかし、プロバイダがそのサービスを提供するために、リソースへのアクセスや他者の協力を必要とする場合、そのチョークポイント自体が、集権化に対抗する方法など、プロバイダの行動に影響を与えるために使われることがある。

このような状況で、望ましい結果を確実に保証するため、チョークポイントに対する何らかの形のガバナンスが必要となる。多くの場合、マルチステークホルダー機関の設立を通じて行われる。マルチステークホルダー機関とは、システムの運用に影響を受けるさまざまな種類の関係者 (「ステークホルダー」) の代表を含む機関であり、合理的で正当かつ権威ある決定を行おうとするものである。

この技術が広く研究されている例は、DNS名前空間のガバナンスであり、これは「唯一の信頼できる情報源」としての集権化を示している[Moura]。この信頼できる情報源は、Internet Corporation for Assigned Names and Numbers (ICANN) <https://www.icann.org/resources/ Pages/governance/governance-en>によって監督されている。ICANNは、エンドユーザ、政府、事業者などの代表からなるグローバルなマルチステークホルダー組織である。

もう1つの例に、ウェブの信頼モデルのガバナンスがある。これは、ユーザのプライバシーとセキュリティを保護する強いインセンティブを持つ依拠当事者(relying parties)としてのウェブブラウザと、ブラウザの信頼ストアに含まれる強いインセンティブを持つトラストアンカーとしてのCAによって実装される。望ましい特性を提供するために必要な運用とセキュリティの要件を推進するために、両当事者が利害関係者として関与する監視機関としてCA/ブラウザフォーラム <https://cabforum.org >が設立された。

これらの例は、ガバナンス・メカニズムがプロトコル文書に直接規定されているのではなく、むしろ運用上、ガバナンスの強制を可能にするプロトコル機能を活用する形で階層化されているという点で注目に値する。

この方法でのガバナンスは、上記の例のような非常に限定された機能に適している。その場合でも、ガバナンス・メカニズムの設定と継続的な運用は簡単なものではなく、その正当性を確立して維持するのが難しい(例: [Palladino]を参照)。その性質上、ガバナンスの対象となる利害関係者によって捕捉されやすい。

4. インターネット標準に何ができるのか?

フェデレーションや分権型コンセンサスのような分権化手法の限界、標準準拠の自発的な性質、そして集権化を推進する強力な力を考えると、関連する弊害を回避しつつ、有益な集権化に対応するためには、IETFのような標準化への取り組みでどのような対応ができるかを問うのは当然のことであり、その特徴(distinction)自体に判断の余地(judgment call)があり、したがって本質的に政治的であることを認識しなければならない。

以下のサブセクションでは、標準化団体が実行できる具体的で有意義な手順をいくつか提案する。

4.1. 正当性の強化

技術標準はインターネットの集権化をコントロールする能力が限られているのに対し、法的標準(規制、法律、判例のいずれであっても) はより見込みがあり、さまざまな管轄区域で積極的に検討および実装されている。しかし、技術的な観点から得られるアーキテクチャへの影響にしっかりとした根拠がなければ、インターネットを規制することは危険である。

そのような見方は、インターネット標準コミュニティによって提供される可能性がある、またそうあるべきである。これを効果的に行うには、その機関が関連する当事者(例えば競争規制当局など)から正当であるとみなされなければならない。もし、IETF が「ビッグテック」を代表しているとか、「ビッグテック」に支配されているとか、米国に本拠を置く企業のみを重要視していると見なされれば、インターネットに影響を与える決定を導く能力は大幅に低下するだろう。

IETFは、間違いなくかなりの正当性を提供する特長をすでに備えている。これらの特長の例には、企業ではなく個人によるオープンな参加と代表があり、どちらも情報(input)の正当性を強化する。スループットの正当性に寄与する何重ものアピールと透明性を備えた、明確に定義されたプロセスがある。そして、インターネット標準を成功させてきた長い歴史が、おそらくIETFの正当性、その成果物の最も強力な源泉となっている。

しかし、IETFへの参加を成功させるには (金銭面だけでなく) かなりのコストがかかるため、中小企業よりも大企業が有利になる傾向があることも広く認識されている。さらに、この作業は専門的かつ高度に技術的な性質を持っているため、技術的知識のない利害関係者にとっての参入障壁となっている。これらの要因は、少なくとも一部の見方では、IETFの決定の正当性を低下させる可能性がある

これらの欠点に対処する取り組みが進行中である。例えば、[RFC8890]を参照。全体として、IETFの正当性を強化することは継続的な取り組みとして見なすべきである。

対外的な取り組みに参加する場合、IETFコミュニティ(特にそのリーダーシップ)は、技術的およびアーキテクチャ上の影響に焦点を当てたときに、その意見が最も権威のあるものになることをしっかりと心に留めておくべきである。

4.2. 集権化について重点的に議論する

技術標準の議論において、集権化と分権化が取り上げられることが多くなっている。どのような主張も批判的に評価する必要がある。セクション2で説明したように、すべての集権化が自動的に有害になるわけではない。セクション3によれば、分権化技術はすべての集権化の弊害に自動的に対処するのではなく、それ自体がリスクをもたらす可能性がある。

しかし、分析には技術的要素だけでなく、経済的、社会的、商業的、法的な側面も含まれるため、標準化の参加者がこれらの主張を完全に評価するだけの専門知識や情報を持っていることはほとんどない。例えば、規模の経済は、関連する効率によって集中を引き起こす可能性があるので[Demsetz]、その集中が適切かどうかを判断するには、技術標準化団体の範囲外である詳細な経済分析が必要となる。さらに、集権化の主張には別の動機がある場合もある。特に、競合する利害を持つ関係者間の権力闘争の代理人となる可能性があり、集権化の主張は、市場参加者や(おそらくより重要な)利用者に標準化の利点を否定するために利用される可能性がある。

したがって、文書に「集権化に関する考慮事項」のセクションを要求したり、集権化の見直しに関する発表を情報制限したり(gatekeeping)、あるいはプロトコルの集権化の探求に多大なリソースを投入するようなアプローチでは、インターネットが改善される可能性は低い。

同様に、あらゆる形態の集権化を積極的に防いでいないという理由でプロトコルの標準化を拒否することは、標準化の取り組みが持つ非常に限られた力を無視することになる。IP、TCP、HTTP、DNSなど、ほとんどの既存のインターネット・プロトコルは、集権的なアプリケーションの使用を防ぐことはできない。標準化過程[RFC2026]の承認(imprimatur)は価値がないわけではないが、単に保留するだけでは集権化を防ぐことはできない。

したがって、議論は非常に焦点を絞って限定的に行う必要があり、分権化に関するあらゆる提案は、その効果を十分に評価できるように詳細に説明する必要がある。シュナイダー[Schneider1]は、分権化を提案する人たちに対して、「ある制度設計が分権化を目指している制度の特定の特徴について、本当に明確に」するように促し、「古い、制度的にリベラルな政治理論」に基づく三権分立や説明責任のようなツールの熟慮された利用を促している。

ある提案が集権化されているという主張を評価する場合、その発言の文脈から、前提、仮定、省略がないかどうかを調べる必要がある。バッキ[Bacchi]は、批判的な尋問のための1つの枠組みを提示しているが、これは集権化関連の議論に適応させることができる。

  1. 問題があるとされる集権化の本質とは何か?
  2. この「問題」の表象の根底には、どのような根深い前提や仮定(概念的論理)があるのか?
  3. このような問題の表象はどのようにして生まれたのか?
  4. この問題の表象において、何が問題視されずに残されているのか? 沈黙はどこにあるのか? 「問題」は別の方法で概念化ができるのか?
  5. この「問題」の表象によって、どのような影響が生じるのか?
  6. この「問題」の表象は、どこでどのように生み出され、広まり、擁護されてきたのか? そして/あるいは、どのように破壊され、置き換えることができるのか?

4.3. 対象となる独自機能

広く利用されているにもかかわらず、相互運用性に欠けている機能は、標準化の取り組みの機が熟している。プロプライエタリな機能(例: チャット)を対象にすることは適切だが、ユーザをプラットフォームにロックするために使用されることが多い特定の機能(例えば、ソーシャル・ネットワークの連絡先リストの形式)の相互運用性と移植性を向上させるための小規模な取り組みも同様である。

このアプローチに対する一般的な反論は、採用が任意であることである。その使用を義務付けたり、正しい実装を強制したりする「標準化警察」は存在しない。例えば、アクティビティストリーム[ACTIVITYSTREAMS]のような仕様は、商用ソーシャル・ネットワーク・プロバイダによってフェデレーション方式で使用されることなく、しばらくの間利用可能だった。

この反論は、標準は強制ではないが、法的規制は強制であるという事実を無視している。相互運用性に対する法的義務は、競争問題の解決策として政策立案者によって提案されることが多くなっている(例: [DMA]を参照)。このような規制への欲求は、変化する規範とその結果として生じる市場の力を組み合わせた法的義務に裏付けられた、これらの機能を分権化するための新しい仕様の機会を提示する[Lessig]。

法的規制がインターネット・アーキテクチャと対立する場合、その機会はリスクを伴う。法的規制と協調して機能する標準の作成を成功させるには、多くの潜在的な落とし穴があり、新たな改善された機能(特にリエゾン)と多大な努力が必要になる。技術コミュニティがそのような努力をしなければ、規制当局が相互運用性の仕様について、他の情報源に目を向ける可能性が高い。

4.4. 切り替えの有効化

さまざまな働きを持つプロバイダ間を切り替える機能は、集権化をコントロールするための中心的なメカニズムである。ユーザが切り替えることができなければ、選択肢を行使することも、努力の価値を十分に実現することもできない。というのも、例えば、「ベンダーの製品を使いこなすには時間がかかり、標準化が不十分であれば、そのスキルを競合他社に完全には移転できないかもしれない」からである[FarrellJ]。

したがって、標準は、その規格が定義または実現する機能の実装と展開を、ユーザが容易に切り替えられるようにするという明確な目標を持つべきである。

切り替えに必要な条件の1つは、代替手段が利用可能であること、そして実装と展開の幅広さと多様性が必要である。例えば、あるプロトコルの実装が1つしかない場合、そのプロトコルを使用するアプリケーションは、その動作に対するコントロールに対して脆弱になる。オープンソース・プロジェクトであっても、フォークを困難にする要因(例えば、そのフォークを維持するコスト)があれば、この点で問題になる可能性がある。[RFC5218]のセクション2.1では、プロトコルの設計において、実装の多様性を促進するいくつかの要素を説明している。

ユーザが別の実装や展開に置き換えるコストも、考慮すべきもう1つの重要な要素である。これには、別のプロバイダや実装を使用するために必要な時間、リソース、専門知識、調整、機能の損失、労力を最小限に抑えることが含まれる。これは、標準が機能的に完全であり、代替を可能にするのに十分正確に規定されている必要があることを意味する。

完全性と多様性という目標は、時には対立する。標準が非常に複雑になると、完全な実装のコストが高すぎるため、実装の多様性が損なわれる可能性がある(ウェブブラウザを考えてみてほしい)。一方、仕様が単純すぎると、特に仕様を完成させるためにプロプライエタリな拡張機能が必要になった場合、簡単に切り替えられなくなる可能性がある(セクション4.7を参照).

容易な切り替えを可能にするプロトコルに対する反論の1つは、商用ベンダーによる実装のインセンティブを低下させるというものである。完全にコモディティ化されたプロトコルは、実装が差別化できないかもしれないが、バリューチェーンの他の部分で専門化と改善の機会が得られる[Christensen]。適切なタイミングで標準化に取り組むことで、こうした力を活用して、プロプライエタリな利益をオープンテクノロジーに置き換えるのではなく、オープンテクノロジーの上に集中させることができる。

4.5. 権限委譲のコントロール

一部の機能のユーザは、コミュニケーションにおいて第3者がその機能を提供することで、大きなメリットを享受できるかもしれない。コミュニケーションに新たな当事者を加えることで、以下の点が改善される:

  • 効率: インターネット上の多くの機能は、より大きな規模で実行した方が効率的である。例えば、コンテンツ配信ネットワークは、コンテンツを自ら配信する事業者がその規模で運営する場合、支払うであろう経済的および環境的コストの数分の1でサービスを提供できる。同様に、両面市場プラットフォームは、買い手と売り手の2者間取引に比べ、大幅な効率をもたらすことができる[Spulber]。
  • シンプルさ: コミュニケーションを完全に仲介しないことで、機能の負担をエンドポイントに移すことができる。これは、ユーザの認知負荷を増大させる可能性がある。例えば、商用ソーシャル・ネットワーク・プラットフォームと自己ホスト型の取り組みを比較してほしい。
  • 専門化: ある機能が少数の手に集約されると、専門化が進み、成果が改善する。例えば、専門の管理者が監督するサービスは、セキュリティ体制が強化され、可用性が向上していることがよく見られる。
  • プライバシー: 機能によっては、個々の行動が互いに識別されないように活動を統合することで、ユーザのプライバシーを向上させることができる[Chaum]。サードパーティの採用は、機能境界を強制することもできる。これは、潜在的に悪意のあるエンドポイントをユーザが信頼する必要性を低減するためである。例えば、いわゆる「oblivious」プロトコル(例えば、[RFC9230])に見られるように、エンドユーザはサービスをアクセスしながら、自分のアイデンティティをサービスから隠すことができる。

しかし、その新しい当事者が、 例えば、仲介者の利用を要求するために、ネットワーク内での地位を活用したり、データへのアクセスを悪用したり、機能を別のプロバイダに切り替えるのが難しいという理由で、その参加を「粘り強く」(sticky)行うことができれば、そこには集権化のリスクがある。

ほとんどの場合、サードパーティは「仲介者」(intermediaries)として、あるいは指定された「エージェント」(agent)の役割として機能に追加される。このような役割に慎重な制約を設けて機能を設計することで、少なくともそのような権限のとんでもない乱用を防ぐことができる。

ある機能に新たな当事者を加える場合、2つのガイドラインが役立つことが分かっている。まず、サードパーティをコミュニケーションに介入させるのは、少なくとも主要当事者の1人が積極的な行動をとった場合に限るべきである。第2に、サードパーティがコミュニケーションを監視したり、コントロールしたりする能力は、その意図する機能を実行するために必要なものに限定すべきである。

例えば、HTTPの初期の展開では、エンドポイントの正確な知識を持たない状態で、ネットワークが仲介することが許され、これらの仲介者は、キャッシュのような基本的な機能しか意図していない場合でも、デフォルトでトラフィックの全内容を見ることができ、さらに変更することができた。HTTPS とCONNECTメソッドの導入と([HTTP]のセクション9.3.6を参照)、その採用を促進する努力の結果、これらの仲介者は今や、あるエンドポイントによって明示的に介在を要求され、基本的なルーティング情報にしかアクセスできない。

プロトコルの仲介に関する詳しいガイダンスについては、[THOMSON-TMI]を参照。

また、「仲介者」(intermediary)という用語は、(しばしば、法律や規制の文脈で)プロトコル設計で使われてきたときよりも、広く使われている。例えば、買い手と売り手の間を仲介するオークションサイトは、HTTPの正式な仲介者ではないが、仲介者とみなされる([HTTP]のセクション3.7を参照)。プロトコル設計者は、基礎となるプロトコルの機能を制限するのではなく、機能を標準化することで、この種の仲介に関連する集権化に対処することができる。セクション4.3を参照。

4.6. 境界の強制

ほとんどのインターネット・プロトコルやアプリケーションは、他の「低レイヤ」の機能やその実装に依存している。これらの依存関係の機能、展開、運用は、その「上に」構築された機能やアプリケーションの集権化のリスクとなる可能性がある。

例えば、アプリケーション・プロトコルが機能するためにはネットワークが必要である。したがって、通信に対するある程度の力は、ネットワーク・プロバイダにある。ネットワーク・プロバイダは、財務的、政治的、運営上、あるいは犯罪的な理由から、特定のサービスへのアクセスを遮断したり、速度を低下させたり、コンテンツを変更したりする可能性があり、特定の機能プロバイダを利用する意欲を失わせる(または利用できなくすることさえある)かもしれない。一部のサービスの利用を選択的に妨げ、他のサービスの利用を阻害しないようにすることで、ネットワークの介入が意図的か否かにかかわらず、他のサービスを利用するよう圧力を生み出すように構成することができる。

暗号化のような技術は、そのような境界を強制することで、集権化を阻止することができる。通信内容にアクセスできる当事者の数が制限されれば、通信内容を扱う当事者ではない他の当事者が通信を妨害したり監視したりすることを防ぐことができる。それでも、この当事者が通信を妨げる可能性は依然としてあるが、暗号化によってターゲットと他のユーザのトラフィックを区別することがより難しくなる。

4.7. 拡張性を慎重に検討する

インターネットが進化する能力は非常に重要であり、実装をアップグレードする「フラグデイ」を必要とせずに、新しい要件を満たし、新しい状況に適応できるようになる。通常、機能は拡張インタフェースを定義することで進化に対応し、相互運用可能な形でオプション機能を追加したり、時間の経過とともに変更できるようになる。

しかし、これらのインタフェースは、標準に独自の拡張機能を追加することで、意味のある相互運用性を実現するためにターゲットを変更することができれば、強力な存在によって活用されることもある。これは特に、核となる標準がそれ自体で十分な実用性を提供しない場合に当てはまる。

例えば、SOAP[SOAP]は極めて柔軟性が高く、とはいえ単体では大きな価値を提供できないため、ベンダーは自分たちが好む拡張機能の使用を要求することができ、より市場支配力を持つベンダーが有利となった。

したがって、標準化への取り組みは、相互運用性がすぐに利用できない「フレームワーク」ではなく、公開された時点で大多数のユーザに具体的なユーティリティを提供することに重点を置くべきである。インターネット機能は、その動作のあらゆる側面を拡張可能にすべきではない。モジュール間の境界は、意味のある機能を提供しながらも、進化を可能にするように設計すべきである。

よく考えられたインタフェースは進化を可能にするだけでなく、分権化の取り組みも助けることができる。機能のサブモジュール間に生じる構造的な境界は(隣接する機能を持つもの同士も同様)、相互運用性のタッチポイントとなり、プロバイダの代替の機会を提供する。

特に、ある機能のインタフェースが明確に定義され、安定していれば、その機能に対して別のプロバイダを利用する機会が生まれる。これらのインタフェースがオープン・スタンダードである場合、変更管理はプロプライエタリな手に委ねられるのでなく、技術コミュニティに委ねられるため、安定性がさらに向上し、分権化が可能になる(ただし、保証はされないが)。

4.8. 機能するものを再利用する

インターネット機能において、集権化が意図的に許容される場合、プロトコル設計者は多くの場合、フェデレーション(セクション3.1.1参照)や運用上のガバナンス構造(セクション3.1.3を参照)のような技術的手段を用いて、関連するリスクを軽減しようとする。

それに成功したプロトコルは、その緩和策を再実装するための多大なコストとリスクを避けるため、再利用されることがよくある。例えば、プロトコルで調整されたグローバルなネーミング機能を必要とする場合、新しいシステムを確立するよりもドメインネームシステムを組み込む方が望ましいと考えられる。

5. 今後の取り組み

この文書では、標準化団体がプロトコル設計を通じてインターネットの集権化を効果的にコントロールしたり、防止する手段はほとんどないものの、インターネットを改善するためにとることのできる具体的で有用な手順がまだあると論じてきた。

これらの手順は、今後の作業でより詳しく説明され、拡張されるかもしれない。しかし、それ以上にできることがあるのは間違いない。新しい分権化手法を特定し、検討することができるかもしれない。この分野でより効果的な他の規制当局との関係から学んだことを文書化することもできる。

集権化に対処するためのハウツーガイドやチェックリストの作成を提案する人もいる。集権化は非常に状況に左右され、その現れ方も非常に多様であるため、非常に限定された分野、例えば特定のタイプの機能や特定のレイヤの機能で試みるのが最善と考えられる。

集権化の性質についても、さらなる研究が必要である。特にその原因である。ネットワーク効果やスイッチング・コストのような要素については多くの解説があるが、行動、認知、社会、経済的要素など、他の側面については、変化しつつあるとはいえ、比較的ほとんど注目されてこなかった(例: [Fletcher])。

6. セキュリティに関する考慮事項

本文書は、インターネット・プロトコルに直接セキュリティ上の影響を与えない。とはいえ、集権化を考慮しなければ、無数のセキュリティ問題を引き起こす可能性がある。予備的な議論については、セクション 2.1 を参照。

7. IANAに関する考慮事項

本文書にはIANAのアクションはない。

8. 参考規格

[Abrahamson] Abrahamson, Z., "Essential Data", Yale Law Journal, Vol. 124, No. 3, December 2014, <https://www.yalelawjournal.org/comment/essential-data>.

[ACTIVITYSTREAMS] Prodromou, E., Ed. and J. Snell, Ed., "Activity Streams 2.0", W3C Recommendation, 23 May 2017, <https://www.w3.org/TR/2017/REC-activitystreams-core-20170523/>. Latest version available at <https://www.w3.org/TR/activitystreams-core/>.

[Aligia] Aligia, P. and V. Tarko, "Polycentricity: From Polanyi to Ostrom, and Beyond", Governance: An International Journal of Policy, Administration, and Institutions, Vol. 25, No. 2, p. 237, DOI 10.1111/j.1468-0491.2011.01550.x, April 2012, <https://onlinelibrary.wiley.com/doi/abs/10.1111/j.1468-0491.2011.01550.x>.

[Bacchi] Bacchi, C., "Introducing the 'What's the Problem Represented to be?' approach", Chapter 2, Engaging with Carol Bacchi, 2012, <https://library.oapen.org/bitstream/handle/20.500.12657/33181/560097.pdf?sequence=1#page=34>.

[Baran] Baran, P., "On Distributed Communications: Introduction to Distributed Communications Networks", DOI 10.7249/RM3420, 1964, <https://www.rand.org/pubs/research_memoranda/RM3420.html>.

[BCP95] Alvestrand, H., "A Mission Statement for the IETF", BCP 95, RFC 3935, October 2004. <https://www.rfc-editor.org/info/bcp95>

[Bodo] Bodó, B., Brekke, J. K., and J.-H. Hoepman, "Decentralization: a multidisciplinary perspective", Internet Policy Review, Vol. 10, No. 2, DOI 10.14763/2021.2.1563, June 2021, <https://policyreview.info/concepts/decentralisation>.

[Chaum] Chaum, D., "Untraceable electronic mail, return addresses, and digital pseudonyms", Communications of the ACM, Vol. 24, No. 2, DOI 10.1145/358549.358563, February 1981, <https://dl.acm.org/doi/10.1145/358549.358563>.

[Christensen] Christensen, C., "The Law of Conservation of Attractive Profits", Harvard Business Review, "Breakthrough Ideas for 2004", February 2004.

[Demsetz] Demsetz, H., "Industry Structure, Market Rivalry, and Public Policy", Journal of Law and Economics, Vol. 16, No. 1, April 1973, <https://www.jstor.org/stable/724822>.

[DMA] The European Parliament and the Council of the European Union, "Regulation (EU) 2022/1925 of the European Parliament and of the Council of 14 September 2022 on contestable and fair markets in the digital sector and amending Directives (EU) 2019/1937 and (EU) 2020/1828 (Digital Markets Act)", OJ L 265/1, 12.10.2022, September 2022, <https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R1925>.

[Doctorow] Doctorow, C., "Adversarial Interoperability", October 2019, <https://www.eff.org/deeplinks/2019/10/adversarial-interoperability>.

[ETHEREUM] Ethereum, "The Merge", February 2023, <https://ethereum.org/en/roadmap/merge/>.

[FarrellH] Farrell, H. and A. Newman, "Weaponized Interdependence: How Global Economic Networks Shape State Coercion", International Security, Vol. 44, No. 1, p. 42, DOI 10.1162/ISEC_a_00351, July 2019, <https://doi.org/10.1162/ISEC_a_00351>.

[FarrellJ] Farrell, J. and C. Shapiro, "Dynamic Competition with Switching Costs", UC Berkeley Department of Economics Working Paper 8865, DOI 10.2307/2555402, January 1988, https://www.jstor.org/stable/2555402

[Fletcher] Fletcher, A., "The Role of Behavioural Economics in Competition Policy", DOI 10.2139/ssrn.4389681, March 2023, <https://doi.org/10.2139/ssrn.4389681>.

[Freeman] Freeman, J., "The Tyranny of Structurelessness", Berkeley Journal of Sociology, Vol. 17, 1972, <https://www.jstor.org/stable/41035187>.

[Holzbauer] Holzbauer, F., Ullrich, J., Lindorfer, M., and T. Fiebig, "Not that Simple: Email Delivery in the 21st Century", July 2022, <https://www.usenix.org/system/files/atc22-holzbauer.pdf>.

[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/info/rfc9110>.

[Kashaf] Kashaf, A., Sekar, V., and Y. Agarwal, "Analyzing Third Party Service Dependencies in Modern Web Services: Have We Learned from the Mirai-Dyn Incident?", DOI 10.1145/3419394.3423664, October 2020, <https://dl.acm.org/doi/pdf/10.1145/3419394.3423664>.

[Komaitis] Komaitis, K., "Regulators Seem to Think That Facebook Is the Internet", August 2021, <https://slate.com/technology/2021/08/facebook-internet-regulation.html>.

[Lessig] Lessig, L., "The New Chicago School", Journal of Legal Studies, Vol. 27, DOI 10.1086/468039, June 1998, <https://www.journals.uchicago.edu/doi/10.1086/468039>.

[Madison] Madison, J., "The Structure of the Government Must Furnish the Proper Checks and Balances Between the Different Departments", The Federalist Papers, No. 51, February 1788.

[Makarov] Makarov, I. and A. Schoar, "Blockchain Analysis of the Bitcoin Market", National Bureau of Economic Research, Working Paper 29396, DOI 10.3386/w29396, October 2021, <https://www.nber.org/papers/w29396>.

[Marlinspike] Marlinspike, M., "Reflections: The ecosystem is moving", May 2016, <https://signal.org/blog/the-ecosystem-is-moving/>.

[Moura] Moura, G., Castro, S., Hardaker, W., Wullink, M., and C. Hesselman, "Clouding up the Internet: how centralized is DNS traffic becoming?", DOI 10.1145/3419394.3423625, October 2020, <https://dl.acm.org/doi/abs/10.1145/3419394.3423625>.

[Musiani] Musiani, F., "Alternative Technologies as Alternative Institutions: The Case of the Domain Name System", The Turn to Infrastructure in Internet Governance, DOI 10.1057/9781137483591_4, 2016, <https://link.springer.com/chapter/10.1057/9781137483591_4>.

[Palladino] Palladino, N. and M. Santaniello, "Legitimacy, Power, and Inequalities in the Multistakeholder Internet Governance", DOI 10.1007/978-3-030-56131-4, November 2020, <https://link.springer.com/book/10.1007/978-3-030-56131-4>.

[PHONE] Skrzycki, C. and J. Burgess, "Computer Failure Paralyzes Region's Phone Service", June 1991, <https://www.washingtonpost.com/archive/politics/1991/06/27/computer-failure-paralyzes-regions-phone-service/0db94ac7-89f0-446e-ba33-c126c751b251/>.

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, <https://www.rfc-editor.org/info/rfc2026>.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.

[RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, <https://www.rfc-editor.org/info/rfc5218>.

[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <https://www.rfc-editor.org/info/rfc5321>.

[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, <https://www.rfc-editor.org/info/rfc6120>.

[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.

[RFC8890] Nottingham, M., "The Internet is for End Users", RFC 8890, DOI 10.17487/RFC8890, August 2020, <https://www.rfc-editor.org/info/rfc8890>.

[RFC9230] Kinnear, E., McManus, P., Pauly, T., Verma, T., and C.A. Wood, "Oblivious DNS over HTTPS", RFC 9230, DOI 10.17487/RFC9230, June 2022, <https://www.rfc-editor.org/info/rfc9230>.

[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, <https://www.rfc-editor.org/info/rfc9293>.

[Schneider1] Schneider, N., "What to do once you admit that decentralizing everything never seems to work", Hacker Noon, September 2019, <https://hackernoon.com/decentralizing-everything-never-seems-to-work-2bb0461bd168>.

[Schneider2] Schneider, N., "Decentralization: An Incomplete Ambition", Journal of Cultural Economy, Vol. 12, No. 4, DOI 10.31219/osf.io/m7wyj, April 2019, <https://osf.io/m7wyj/>.

[SOAP] Mitra, N., Ed. and Y. Lafon, Ed., "SOAP Version 1.2 Part 0: Primer (Second Edition)", W3C Recommendation, 27 April 2007, <https://www.w3.org/TR/2007/REC-soap12-part0-20070427/>. Latest version available at <https://www.w3.org/TR/soap12-part0/>.

[Spulber] Spulber, D., "Solving The Circular Conundrum: Communication and Coordination in Two-Sided Markets", Northwestern University Law Review, Vol. 104, No. 2, October 2009, <https://wwws.law.northwestern.edu/research-faculty/clbe/workingpapers/documents/spulber_circularconundrum.pdf>.

[THOMSON-TMI] Thomson, M., "Principles for the Involvement of Intermediaries in Internet Protocols", Work in Progress, Internet-Draft, draft-thomson-tmi-04, 8 September 2022, <https://datatracker.ietf.org/doc/html/draft-thomson-tmi-04>.

謝辞

この文書は、インターネット・アーキテクチャ委員会で共に過ごしたブライアン・トラメルとの以前の議論から生まれたものである。

ジェフ・ヒューストンとミルトン・ミューラーの、よく検討され、思慮深く、有益なレビューに感謝する。

ジャリ・アルッコ、クリスティン・ベルダン、リチャード・クレイトン、コーリー・ドクトロウ、クリスチャン・ウイテマ、エリオット・リア、ジョン・レヴィン、トミー・ポーリー、マーティン・トンプソンのコメントと提案に感謝する。同様に、arch-discuss@ietf.orgメーリング リストと分権型インターネット・インフラストラクチャ研究グループからも貴重な議論とフィードバックを提供してくれた。

この文書の作成には、大規模言語モデルは使用されていない。

著書のアドレス

マーク・ノッティンガム
プラーン
オーストラリア
メール: mnot@mnot.net
URI: https://www.mnot.net/

変更履歴

GitHubで編集を提案

Discussion