Independent Submission M. Nottingham
Request for Comments: 9518 December 2023
Category: Informational
ISSN: 2070-1721
This document discusses aspects of centralization that relate to Internet standards efforts. It argues that, while standards bodies have a limited ability to prevent many forms of centralization, they can still make contributions that assist in the decentralization of the Internet.
このドキュメントでは、インターネット標準の取り組みに関連する集中化の側面について説明します。標準団体は多くの形態の集中化を防ぐ能力が限られているが、インターネットの地方分権化を支援する貢献を依然として行うことができると主張している。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開されることが承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9518.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9518で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
1. Introduction
2. Centralization
2.1. Centralization Can Be Harmful
2.2. Centralization Can Be Helpful
3. Decentralization
3.1. Decentralization Strategies
3.1.1. Federation
3.1.2. Distributed Consensus
3.1.3. Operational Governance
4. What Can Internet Standards Do?
4.1. Bolster Legitimacy
4.2. Focus Discussion of Centralization
4.3. Target Proprietary Functions
4.4. Enable Switching
4.5. Control Delegation of Power
4.6. Enforce Boundaries
4.7. Consider Extensibility Carefully
4.8. Reuse What Works
5. Future Work
6. Security Considerations
7. IANA Considerations
8. Informative References
Acknowledgements
Author's Address
One of the Internet's defining features is its lack of any single point of technical, political, or economic control. Arguably, that characteristic assisted the Internet's early adoption and broad reach: permission is not required to connect to, deploy an application on, or use the Internet for a particular purpose, so it can meet diverse needs and be deployed in many different environments.
インターネットの決定的な機能の1つは、技術的、政治的、または経済的管理の単一のポイントがないことです。おそらく、その特徴は、インターネットの早期採用と広範な範囲を支援しました。特定の目的でインターネットに接続、アプリケーションの展開、または使用する許可は必要ありません。
Although maintaining that state of affairs remains a widely espoused goal, consistently preserving it across the range of services and applications that people see as "the Internet" has proven elusive. Whereas early services like the Network News Transfer Protocol (NNTP) and email had multiple interoperable providers, many contemporary platforms for content and services are operated by single commercial entities without any interoperable alternative -- to the point where some have become so well-known and important to people's experiences that they are commonly mistaken for the Internet itself [Komaitis].
その状況を維持することは、広く支持されている目標のままですが、人々が「インターネット」と見なすサービスやアプリケーションの範囲全体で一貫して保存されていることはとらえどころのないことが証明されています。ネットワークニュース転送プロトコル（NNTP）や電子メールなどの初期のサービスには複数の相互運用可能なプロバイダーがありましたが、コンテンツとサービスのための多くの現代的なプラットフォームは、相互運用可能な代替手段なしで単一の商業エンティティによって運営されています - 一部は非常に有名になり、人々の経験にとって重要であり、彼らは一般的にインターネット自体と間違われている[Komaitis]。
These difficulties call into question what role architectural design -- in particular, that overseen by open standards bodies such as the IETF -- can and should play in controlling centralization of the Internet.
これらの困難は、IETFなどのオープン標準団体によって監督される役割のアーキテクチャデザインが、インターネットの集中化の制御においてプレイすることができる、そして再生できる役割のアーキテクチャデザインに疑問を投げかけます。
This document argues that, while decentralized technical standards may be necessary to avoid centralization of Internet functions, they are not sufficient to achieve that goal because centralization is often caused by non-technical factors outside the control of standards bodies. As a result, standards bodies should not fixate on preventing all forms of centralization; instead, they should take steps to ensure that the specifications they produce enable decentralized operation.
この文書は、インターネット機能の集中化を避けるために分散型の技術基準が必要であるかもしれないが、集中化はしばしば標準団体の制御以外の非技術的要因によって引き起こされるため、その目標を達成するのに十分ではないと主張している。その結果、標準団体は、あらゆる形態の集中化を防ぐことに固執すべきではありません。代わりに、彼らが生成する仕様が分散操作を可能にするために措置を講じる必要があります。
Although this document has been discussed widely in the IETF community (see the Acknowledgements section), it represents the views of the author, not community consensus. Its primary audience is the engineers who design and standardize Internet protocols. Designers of proprietary protocols and applications can benefit from considering these issues, especially if they intend their work to be considered for eventual standardization. Policymakers can use this document to help characterize abuses that involve centralized protocols and applications and evaluate proposed remedies for them.
このドキュメントはIETFコミュニティで広く議論されていますが（謝辞セクションを参照）、コミュニティのコンセンサスではなく、著者の見解を表しています。その主な視聴者は、インターネットプロトコルを設計および標準化するエンジニアです。独自のプロトコルとアプリケーションの設計者は、特に最終的な標準化を検討することを意図している場合、これらの問題を考慮することで利益を得ることができます。政策立案者は、このドキュメントを使用して、集中化されたプロトコルとアプリケーションを含む虐待を特徴付け、提案された救済策を評価することができます。
Section 2 defines centralization, explains why it is often undesirable but sometimes beneficial, and surveys how it occurs on the Internet. Section 3 explores decentralization and highlights some relevant strategies, along with their limitations. Section 4 makes recommendations about the role that Internet standards can play in controlling centralization. Section 5 concludes by identifying areas for future work.
セクション2では、集中化を定義し、なぜそれがしばしば望ましくないが有益である理由を説明し、インターネット上でどのように発生するかを調査します。セクション3では、地方分権化を調査し、関連するいくつかの戦略とその制限を強調します。セクション4は、インターネット標準が集中化の制御において果たすことができる役割について推奨しています。セクション5は、将来の作業の領域を特定することで締めくくります。
In this document, "centralization" is the state of affairs where a single entity or a small group of them can observe, capture, control, or extract rent from the operation or use of an Internet function exclusively.
この文書では、「集中化」とは、単一のエンティティまたはそれらの小さなグループが、インターネット機能の操作または使用から賃貸を観察、キャプチャ、制御、または抽出できる状況です。
Here, "entity" could be a person, group, or corporation. An organization might be subject to governance that mitigates centralization risk (see Section 3.1.3), but that organization is still a centralizing entity.
ここで、「エンティティ」は、人、グループ、または企業である可能性があります。組織は、集中リスクを軽減するガバナンスの対象となる可能性があります（セクション3.1.3を参照）が、その組織は依然として集中化されています。
"Internet function" is used broadly in this document. Most directly, it might be an enabling protocol already defined by standards, such as IP [RFC791], BGP [RFC4271], TCP [RFC9293], or HTTP [HTTP]. It might also be a proposal for a new enabling protocol or an extension to an existing one.
「インターネット機能」は、このドキュメントで広く使用されています。最も直接的に、IP [RFC791]、BGP [RFC4271]、TCP [RFC9293]、またはHTTP [HTTP]など、標準によって既に定義されている有効化プロトコルである可能性があります。また、新しい有効化プロトコルまたは既存のプロトコルの拡張機能の提案でもあります。
Because people's experience of the Internet are not limited to standards-defined protocols and applications, this document also considers centralization in functions built on top of standards -- for example, social networking, file sharing, financial services, and news dissemination. Likewise, the networking equipment, hardware, operating systems, and software that act as enabling technologies for the Internet can also impact centralization. The supply of Internet connectivity to end users in a particular area or situation can exhibit centralization, as can the supply of transit between networks (so called "Tier 1" networks).
インターネットの人々の経験は標準定義のプロトコルとアプリケーションに限定されないため、このドキュメントは、ソーシャルネットワーキング、ファイル共有、金融サービス、ニュース普及など、基準の上に構築された機能の集中化も考慮しています。同様に、インターネットのテクノロジーを可能にするネットワーキング機器、ハードウェア、オペレーティングシステム、およびソフトウェアも集中化に影響を与える可能性があります。特定の分野または状況のエンドユーザーへのインターネット接続の供給は、ネットワーク間の通過の供給（いわゆる「Tier 1」ネットワーク）と同様に、集中化を示すことができます。
This definition of centralization does not capture all types of centralization. Notably, technical centralization (for example, where a machine or network link is a single point of failure) is relatively well understood by engineers; it can be mitigated, typically by distributing a function across multiple components. As we will see, such techniques might address that type of centralization while failing to prevent control of the function falling into few hands. A failure because of a cut cable, power outage, or failed server is well understood by the technical community but is qualitatively different from the issues encountered when a core Internet function has a gatekeeper.
この集中化の定義は、すべてのタイプの集中化をキャプチャするものではありません。特に、技術的な集中化（たとえば、マシンまたはネットワークリンクが単一の障害ポイントである場合）は、エンジニアが比較的よく理解しています。通常、複数のコンポーネントに関数を分散することにより、軽減できます。私たちが見るように、そのような手法は、関数の制御が少数の手に落ちるのを防ぎながら、そのタイプの集中化に対処するかもしれません。カットケーブル、停電、または故障したサーバーのための障害は、技術コミュニティによってよく理解されていますが、コアインターネット関数にゲートキーパーがある場合に発生した問題と定性的に異なります。
Likewise, political centralization (for example, where a country is able to control how a function is supplied across the whole Internet) is equally concerning but is not considered in depth here.
同様に、政治的集中化（たとえば、国がインターネット全体で機能がどのように供給されるかを制御できる）は等しく懸念されますが、ここでは深く考慮されていません。
Even when centralization is not currently present in a function, some conditions make it more likely that centralization will emerge in the future. This document uses "centralization risk" to characterize that possibility.
現在、集中化が機能に存在していない場合でも、一部の条件により、将来中央集中化が出現する可能性が高くなります。このドキュメントでは、「集中リスク」を使用して、その可能性を特徴付けます。
Many engineers who participate in Internet standards efforts have an inclination to prevent and counteract centralization because they see the Internet's history and architecture as incompatible with it. As a "large, heterogeneous collection of interconnected systems" [BCP95] the Internet is often characterized as a "network of networks" whose operators relate as peers that agree to facilitate communication rather than experiencing coercion or requiring subservience to others' requirements. This focus on independence of action is prevalent in the Internet's design -- for example, in the concept of an "autonomous system".
インターネット標準の取り組みに参加する多くのエンジニアは、インターネットの歴史とアーキテクチャを互換性がないと考えているため、集中化を防止および対抗する傾向があります。「相互接続されたシステムの大規模で不均一なコレクション」[BCP95]として、インターネットは、多くの場合、「ネットワークのネットワーク」として特徴付けられます。アクションの独立にこの焦点は、たとえば「自律システム」の概念において、インターネットの設計で一般的です。
Reluctance to countenance centralization is also rooted in the many potentially damaging effects that have been associated with it, including:
表情の集中化への不本意は、以下を含む、それに関連付けられている多くの潜在的に損害を与える効果にも根ざしています。
* _Power Imbalance_: When a third party has unavoidable access to communications, they gain informational and positional advantages that allow observation of behavior (the "panopticon effect") and shaping or even denial of behavior (the "chokepoint effect"): capabilities that those parties (or the states that have authority over them) can use for coercive ends [FarrellH] or even to disrupt society itself. Just as [Madison] describes good governance of the US states, good governance of the Internet requires that power over any function not be consolidated in one place without appropriate checks and balances.
* _Power Imbalance _：第三者がコミュニケーションへの避けられないアクセスを持っている場合、行動の観察（「パノプティコン効果」）および形成または行動の拒否（「Chokepoint Effect」）を可能にする情報および位置的な利点を得る：それらの当事者の能力があります（またはそれらに対する権限を持っている州）は、強制的な終わり[ファレル]に使用することも、社会自体を混乱させることもできます。[マディソン]が米国国家の優れたガバナンスを説明しているように、インターネットの優れたガバナンスは、適切なチェックとバランスなしに、あらゆる機能に対する電力を1つの場所で統合しないことを必要とします。
* _Limits on Innovation_: A party with the ability to control communication can preclude the possibility of "permissionless innovation", i.e., the ability to deploy new, unforeseen applications without requiring coordination with parties other than those you are communicating with.
* _limits on Innovation _：コミュニケーションを制御する能力を備えた当事者は、「許可のないイノベーション」の可能性、つまり、通信している当事者以外の当事者との調整を必要とせずに、新しい、予期しないアプリケーションを展開する能力を排除することができます。
* _Constraints on Competition_: The Internet and its users benefit from robust competition when applications and services are available from many providers, especially when those users can build their own applications and services based upon interoperable standards. When a centralized service or platform must be used because no substitutes are suitable, it effectively becomes an essential facility, which opens the door to abuse of power.
* _ Constraints on Competition _：インターネットとそのユーザーは、多くのプロバイダーからアプリケーションとサービスが利用できる場合、特にそれらのユーザーが相互運用可能な基準に基づいて独自のアプリケーションとサービスを構築できる場合、堅牢な競争から利益を得ます。代替品が適切ではないため、集中サービスまたはプラットフォームを使用する必要がある場合、それは事実上、権力の乱用への扉を開く重要な施設になります。
* _Reduced Availability_: Availability of the Internet (and applications and services built upon it) improves when there are many ways to obtain access. While service availability can benefit from the focused attention of a large centralized provider, that provider's failure can have a disproportionate impact on availability.
* _ Reduced Availableability _：インターネットの可用性（およびその上に構築されたアプリケーションとサービス）は、アクセスを取得する多くの方法があると改善します。サービスの可用性は、大規模な集中プロバイダーの集中的な注意の恩恵を受けることができますが、そのプロバイダーの失敗は可用性に不均衡な影響を与える可能性があります。
* _Monoculture_: The scale available to a centralized provider can magnify minor flaws in features to a degree that can have broad consequences. For example, a single codebase for routers elevates the impact of a bug or vulnerability; a single recommendation algorithm for content can have severe social impact. Diversity in functions' implementations leads to a more robust outcome when viewed systemically because "progress is the outcome of a trial-and-error evolutionary process of many agents interacting freely" [Aligia].
* _monoculture _：集中プロバイダーが利用できるスケールは、幅広い結果をもたらすことができる程度まで、機能のマイナーな欠陥を拡大することができます。たとえば、ルーター用の単一のコードベースは、バグまたは脆弱性の影響を高めます。コンテンツの単一の推奨アルゴリズムは、深刻な社会的影響を与える可能性があります。「進歩は自由に相互作用する多くのエージェントの試行錯誤の進化プロセスの結果である」[Aligia]のため、機能の実装の多様性は、体系的に見られると、より堅牢な結果につながります。
* _Self-Reinforcement_: As widely noted (e.g., see [Abrahamson]), a centralized provider's access to data allows it the opportunity to make improvements to its offerings while denying such access to others.
* _Self-Reinforcement _：広く指摘されているように（たとえば、[Abrahamson]を参照）、集中型プロバイダーのデータへのアクセスにより、他の人へのアクセスを拒否しながら、提供を改善する機会が得られます。
The relationship between these harms and centralization is often complex. It is not always the case that centralization will lead to them; when it does, there is not always a direct and simple trade-off.
これらの害と集中化の関係は、しばしば複雑です。集中化がそれらにつながることは常にそうではありません。そうすると、直接的で単純なトレードオフは常にあるとは限りません。
For example, consider the relationship between centralization and availability. A centrally operated system might be more available because of the resources available to a larger operator, but their size creates greater impact when a fault is encountered. Decentralized systems can be more resilient in the face of some forms of failure but less so in other ways; for example, they may be less able to react to systemic issues and might be exposed to a larger collection of security vulnerabilities in total. As such, it cannot be said that centralization reduces availability in all cases: nor does it improve it in all cases.
たとえば、集中化と可用性の関係を考慮してください。大規模なオペレーターが利用できるリソースのため、中央で動作したシステムがより利用できる場合がありますが、障害に遭遇するとサイズがより大きな影響を与えます。分散型システムは、いくつかの形態の障害に直面してより回復力がありますが、他の方法ではそうではありません。たとえば、それらは体系的な問題に反応することができず、合計でセキュリティの脆弱性のより大きなコレクションにさらされる可能性があります。そのため、集中化がすべての場合に可用性を低下させるとは言えません。また、すべての場合にそれを改善することもありません。
This tension can be seen in areas like the cloud and mobile Internet access. If a popular cloud-hosting provider were to become unavailable (whether for technical or other reasons), many Internet experiences might be disrupted (especially due to the multiple dependencies that a modern website often has; see [Kashaf]). Likewise, a large mobile Internet access provider might have an outage that affects hundreds of thousands of its users or more -- just as previous issues at large telephone companies precipitated widespread outages [PHONE].
この緊張は、クラウドやモバイルインターネットアクセスなどの領域で見ることができます。人気のあるクラウドホスティングプロバイダーが利用できなくなった場合（技術的または他の理由で）、多くのインターネットエクスペリエンスが中断される可能性があります（特に、現代のWebサイトがしばしば持っている複数の依存関係により、[Kashaf]を参照）。同様に、大規模なモバイルインターネットアクセスプロバイダーは、数十万人以上のユーザーに影響を与える停止がある可能性があります。
In both cases, the services are not technically centralized; these operators have strong incentives to have multiple redundancies in place and use various techniques to mitigate the risk of any one component failing. However, they generally do rely upon a single codebase, a limited selection of hardware, a unified control plane, and a uniform administrative practice: each of which might precipitate a widespread failure.
どちらの場合も、サービスは技術的に集中化されていません。これらのオペレーターには、複数の冗長性を導入し、さまざまな手法を使用して、いずれかのコンポーネントが失敗するリスクを軽減する強力なインセンティブがあります。ただし、通常、それらは単一のコードベース、限られた選択のハードウェア、統一された制御プレーン、および均一な管理慣行に依存しています。
If there were only one provider for these services (like the telephone networks of old), they would easily be considered to be centralized in a way that has significant impact upon availability. However, many cloud providers offer similar services. In most places, there are multiple mobile operators available. That weakens the argument that there is a link between centralization and their availability because the function's users can switch to other providers or use more than one provider simultaneously; see Section 4.4.
これらのサービスには1つのプロバイダー（古い電話ネットワークなど）が1つしかなかった場合、可用性に大きな影響を与える方法で集中化されると簡単に考慮されます。ただし、多くのクラウドプロバイダーは同様のサービスを提供しています。ほとんどの場所で、複数のモバイルオペレーターが利用可能です。これは、関数のユーザーが他のプロバイダーに切り替えるか、複数のプロバイダーを同時に使用できるため、集中化とその可用性の間にリンクがあるという議論を弱めます。セクション4.4を参照してください。
These circumstances suggest one area of inquiry when considering the relationship between centralization and availability of a given function: what barriers are there to switching to other providers (thereby making any disruptions temporary and manageable) or to using multiple providers simultaneously (to mask the failure of a single operator)?
これらの状況は、特定の機能の集中化と可用性との関係を考慮する際の調査領域を示唆しています。他のプロバイダーへの切り替え（一時的かつ管理可能な混乱を引き起こす）または複数のプロバイダーを同時に使用すること（障害をマスクするための障壁がありますか？単一のオペレーター）？
Another example of the need for nuance can be seen when evaluating competitive constraints. While making provision of various Internet functions more competitive may be a motivation for many engineers, only courts (and sometimes regulators) have the authority to define a relevant market and determine that a behavior is anticompetitive. In particular, market concentration does not always indicate competition issues; therefore, what might be considered undesirable centralization by the technical community might not attract competition regulation.
競争上の制約を評価する際に、ニュアンスの必要性の別の例を見ることができます。さまざまなインターネット機能をより競争力のあるものにすることは、多くのエンジニアにとって動機となる可能性がありますが、関連する市場を定義し、行動が反競争的であると判断する権限を持っている裁判所のみがあります。特に、市場の集中は常に競争の問題を示すとは限りません。したがって、技術コミュニティによって望ましくない集中化と見なされる可能性があるものは、競争規制を引き付けることはないかもしれません。
The potential damaging effects of centralization listed above are widely appreciated. Less widely explored is the reliance on centralization by some protocols and applications to deliver their functionality.
上記の集中化の潜在的な損傷効果は、広く評価されています。あまり調査されていないのは、機能を提供するための一部のプロトコルとアプリケーションによる集中化への依存です。
Centralization is often present due to technical necessity. For example, a single globally coordinated "source of truth" is by nature centralized -- such as in the root zone of the Domain Name System (DNS), which allows human-friendly naming to be converted into network addresses in a globally consistent fashion.
技術的な必要性のために、集中化がしばしば存在します。たとえば、グローバルに調整された単一の「真実の源」は、ドメイン名システム（DNS）のルートゾーンなど、自然団によって集中化されています。。
Or, consider IP address allocation. Internet routing requires addresses to be allocated uniquely, but if a single government or company were to capture the addressing function, the entire Internet would be at risk of abuse by that entity. Similarly, the Web's trust model requires a Certificate Authority (CA) to serve as the root of trust for communication between browsers and servers, bringing the centralization risk, which needs to be considered in the design of that system.
または、IPアドレスの割り当てを検討してください。インターネットルーティングでは、住所を一意に割り当てる必要がありますが、単一の政府または会社がアドレス指定機能を把握した場合、インターネット全体がそのエンティティによる虐待のリスクがあります。同様に、Webの信頼モデルでは、証明書当局（CA）がブラウザーとサーバー間のコミュニケーションのための信頼のルートとして機能し、そのシステムの設計で考慮する必要がある集中リスクをもたらす必要があります。
Protocols that need to solve the "rendezvous problem" to coordinate communication between two parties who are not in direct contact also require centralization. For example, chat protocols need to coordinate communication between two parties that wish to talk; while the actual communication can be direct between them (so long as the protocol facilitates that), the endpoints' mutual discovery typically requires a third party at some point. From the perspective of those two users, the rendezvous function has a centralization risk.
直接接触していない2つの当事者間のコミュニケーションを調整するために「ランデブー問題」を解決する必要があるプロトコルも集中化が必要です。たとえば、チャットプロトコルは、話をしたい2つの関係者間のコミュニケーションを調整する必要があります。実際のコミュニケーションはそれらの間で直接的になりますが（プロトコルがそれを促進する限り）、エンドポイントの相互発見は通常、ある時点で第三者を必要とします。これら2人のユーザーの観点から見ると、ランデブー関数には集中リスクがあります。
Even when not strictly necessary, centralization can create benefits for a function's users and for society.
厳密に必要ではない場合でも、集中化は関数のユーザーと社会に利益をもたらすことができます。
For example, it has long been recognized that the efficiencies that come with economies of scale can lead to concentration [Demsetz]. Those efficiencies can be passed on to users as higher quality products and lower costs, and they might even enable provision of a function that was not viable at smaller scale.
たとえば、規模の経済に伴う効率が集中につながる可能性があることは長い間認識されてきました[Demsetz]。これらの効率は、高品質の製品と低コストとしてユーザーに渡すことができ、小規模で実行可能でない機能の提供を可能にすることさえあります。
Complex and risky functions like financial services (e.g., credit card processing) are often concentrated into a few specialized organizations where they can receive the focused attention and expertise that they require.
金融サービス（クレジットカード処理など）のような複雑で危険な機能は、多くの場合、必要な集中的な注意と専門知識を受け取ることができるいくつかの専門組織に集中しています。
Centralization can also provide an opportunity for beneficial controls to be imposed. [Schneider2] notes that "centralized structures can have virtues, such as enabling publics to focus their limited attention for oversight, or forming a power bloc capable of challenging less-accountable blocs that might emerge. Centralized structures that have earned widespread respect in recent centuries -- including governments, corporations, and nonprofit organizations -- have done so in no small part because of the intentional design that went into those structures".
集中化は、有益な制御が課される機会を提供することもできます。[Schneider2]は、「集中構造が監視に限られた注意を集中させることができるようにするなどの美徳を持つことができること、または出現する可能性のあるあまり重要でないブロックに挑戦できる力のブロックを形成できるようにするなど。 - 政府、企業、および非営利団体を含む - は、それらの構造に入った意図的な設計のために、それをほんの一部ではありません。」
This can be seen when a function requires governance to realize common goals and protect minority interests. For example, content moderation functions impose community values that many see as a benefit. Of course, they can also be viewed as a choke point where inappropriate controls are able to be imposed if that governance mechanism has inadequate oversight, transparency, or accountability.
これは、関数がガバナンスが共通の目標を実現し、少数派の利益を保護するためにガバナンスを必要とするときに見ることができます。たとえば、コンテンツモデレート機能は、多くの人が利益と見なすコミュニティの価値を課します。もちろん、そのガバナンスメカニズムに不十分な監視、透明性、説明責任がある場合、不適切なコントロールが課せられるチョークポイントとも見なすことができます。
Ultimately, deciding when centralization is beneficial is a judgment call. Some protocols cannot operate without a centralized function; others might be significantly enhanced for certain use cases if a function is centralized or might merely be more efficient. Although, in general, centralization is most concerning when it is not broadly held to be necessary or beneficial; when it has no checks, balances, or other mechanisms of accountability; when it selects "favorites" that are difficult (or impossible) to displace; and when it threatens the architectural features that make the Internet successful.
最終的に、集中化がいつ有益であるかを決定することは判断コールです。一部のプロトコルは、集中機能なしでは動作できません。他のものは、関数が集中化されている場合、または単に効率的である場合、特定のユースケースで大幅に強化される可能性があります。一般的に、集中化は、それが必要または有益であると広く保持されていない場合に最も懸念されます。チェック、バランス、または説明責任のその他のメカニズムがない場合。それが置き換えるのが難しい（または不可能な）「お気に入り」を選択するとき。そして、それがインターネットを成功させる建築的特徴を脅かすとき。
While the term "decentralization" has a long history of use in economics, politics, religion, and international development, [Baran] gave one of the first definitions relevant to computer networking as a condition when "complete reliance upon a single point is not always required".
「分散化」という用語には、経済学、政治、宗教、国際的な発展における長い使用史がありますが、[バラン]は、「単一のポイントへの完全な依存が常にではない場合、コンピューターネットワーキングに関連する最初の定義の1つを条件として与えました。必須"。
Such technical centralization (while not a trivial topic) is relatively well understood. Avoiding all forms of centralization -- including non-technical ones -- using only technical tools (like protocol design) is considerably more difficult. Several issues are encountered.
このような技術的集中化（些細なトピックではありませんが）は比較的よく理解されています。技術的なツール（プロトコル設計など）のみを使用して、技術的なツールのみを使用して、あらゆる形態の集中化を避けることはかなり困難です。いくつかの問題が発生します。
First, and most critically, technical decentralization measures have, at best, limited effects on non-technical forms of centralization. Or, per [Schneider1], "decentralized technology alone does not guarantee decentralized outcomes". As explored below in Section 3.1, technical measures are better characterized as necessary but insufficient to achieve full decentralization of a function.
第一に、そして最も重要なことに、技術的な分散化措置は、せいぜい技術的な形態の集中形態に限られた影響を及ぼします。または、[Schneider1]によると、「分散化された技術だけでは分散型の結果が保証されません」。セクション3.1で以下で説明するように、技術的な測定値は必要に応じてよりよく特徴付けられますが、関数の完全な分散化を実現するには不十分です。
Second, decentralizing a function requires overcoming challenges that centralized ones do not face. A decentralized function can be more difficult to adapt to user needs (for example, introducing new features or experimenting with user interfaces) because doing so often requires coordination between many different actors [Marlinspike]. Economies of scale are more available to centralized functions, as is data that can be used to refine a function's design. All of these factors make centralized solutions more attractive to service providers and, in some cases, can make a decentralized solution uneconomic.
第二に、関数を分散化するには、集中化されたものが直面しない課題を克服する必要があります。分散型関数は、ユーザーのニーズに適応するのがより困難になる可能性があります（たとえば、新しい機能の導入やユーザーインターフェイスの実験）。関数の設計を改良するために使用できるデータと同様に、スケールの経済は集中機能により利用可能です。これらの要因はすべて、集中化されたソリューションをサービスプロバイダーにとってより魅力的にし、場合によっては分散型ソリューションを非経済的にすることができます。
Third, identifying which aspects of a function to decentralize can be difficult, both because there are often many interactions between different types and sources of centralization and because centralization sometimes only becomes clear after the function is deployed at scale. Efforts to decentralize often have the effect of merely shifting centralization to a different place -- for example, in its governance, implementation, deployment, or ancillary functions.
第三に、異なるタイプと集中化のソースの間に多くの相互作用があることが多いため、また集中化が大規模に展開された後にのみ中央化が明確になることがあるため、分散化する関数のどの側面を特定することは困難です。分散化する努力は、多くの場合、単に集中化を別の場所に移行する効果があります。たとえば、そのガバナンス、実装、展開、または補助的な機能において。
For example, the Web was envisioned and widely held to be a decentralizing force in its early life. Its potential as an enabler of centralization only became apparent when large websites successfully leveraged network effects (and secured legal prohibitions against interoperability, thus increasing switching costs; see [Doctorow]) to achieve dominance of social networking, marketplaces, and similar functions.
たとえば、このWebは想像され、その幼少期の分散型の力であると広く保持されていました。集中化の可能性としての可能性は、大規模なWebサイトがネットワーク効果を成功裏に活用した場合にのみ明らかになりました（そして、相互運用性に対する法的禁止を確保し、スイッチングコストを増加させます。[Doctow]を参照）ソーシャルネットワーキング、市場、および同様の機能の優位性を達成しました。
Fourth, different parties might have good-faith differences on what "sufficiently decentralized" means based upon their beliefs, perceptions, and goals. Just as centralization is a continuum, so is decentralization, and not everyone agrees what the "right" level or type is, how to weigh different forms of centralization against each other, or how to weigh potential centralization against other architectural goals (such as security or privacy).
第4に、異なる政党は、信念、認識、目標に基づいて「十分に分散化された」が意味するものに善意の違いを持つ可能性があります。集中化が連続体であるように、地方分権も同様に、そして誰もが「正しい」レベルまたはタイプが何であるか、互いにさまざまな形態の集中化を比較検討する方法、または他の建築目標に対する潜在的な集中化（セキュリティなど）を比較検討する方法に同意するわけではありませんまたはプライバシー）。
These tensions can be seen, for example, in the DNS. While some aspects of the system are decentralized -- for example, the distribution of the lookup function to local servers that users have the option to override -- an essentially centralized aspect of the DNS is its operation as a name space: a single global "source of truth" with inherent (if beneficial) centralization in its management. ICANN mitigates the associated risk through multi-stakeholder governance (see Section 3.1.3). While many believe that this arrangement is sufficient and might even have desirable qualities (such as the ability to impose community standards over the operation of the name space), others reject ICANN's oversight of the DNS as illegitimate, favoring decentralization based upon distributed consensus protocols rather than human governance [Musiani].
これらの緊張は、たとえばDNSで見ることができます。システムのいくつかの側面は分散化されていますが、たとえば、ユーザーがオーバーライドするオプションを持っているローカルサーバーへのルックアップ関数の分布は、DNSの本質的に集中化された側面は、名前空間としての操作です。真実の源「その管理に固有の（有益な）集中化を伴う。ICANNは、マルチステークホルダーガバナンスを通じて関連するリスクを軽減します（セクション3.1.3を参照）。多くの人は、この取り決めは十分であり、望ましい品質（名前空間の運用にコミュニティの基準を課す能力など）を持っているかもしれないと信じていますが、他の人はICANNのDNSの違法であることを拒否し、分散コンセンサスプロトコルに基づいて分散化を支持しています。人間のガバナンスよりも[Musiani]。
Fifth, decentralization unavoidably involves adjustments to the power relationships between protocol participants, especially when it opens up the possibility of centralization elsewhere. As [Schneider2] notes, decentralization "appears to operate as a rhetorical strategy that directs attention toward some aspects of a proposed social order and away from others", so "we cannot accept technology as a substitute for taking social, cultural, and political considerations seriously". Or, more bluntly, "without governance mechanisms in place, nodes may collude, people may lie to each other, markets can be rigged, and there can be significant cost to people entering and exiting markets" [Bodo].
第5に、地方分権化には、特に他の場所で集中化の可能性を開く場合、プロトコル参加者間のパワー関係の調整が避けられません。[Schneider2]が指摘するように、地方分権化は「提案された社会秩序のいくつかの側面に注意を向ける修辞的戦略として機能しているように見えます」。真剣に"。または、より率直に言って、「ガバナンスメカニズムが整っていないと、ノードは共謀し、人々は互いに嘘をつく可能性があり、市場が装備される可能性があり、市場に出入りする人々にかなりのコストがかかる可能性があります」[Bodo]。
For example, while blockchain-based cryptocurrencies purport to address the centralization inherent in existing currencies through technical means, many exhibit considerable concentration of power due to voting/mining power, distribution of funds, and diversity of the codebase [Makarov]. Overreliance on technical measures also brings an opportunity for latent, informal power structures that have their own risks -- including centralization [Freeman].
たとえば、ブロックチェーンベースの暗号通貨は、技術的な手段を通じて既存の通貨に固有の集中化に対処することを目的としていますが、多くは投票/採掘力、資金の分布、およびコードベースの多様性により、かなりの集中力を示しています[Makarov]。技術的措置に依存することは、集中化を含む独自のリスクを持つ潜在的で非公式の電力構造の機会ももたらします[フリーマン]。
Overall, decentralizing a function requires considerable work, is inherently political, and involves a large degree of uncertainty about the outcome. If one considers decentralization as a larger social goal (in the spirit of how the term is used in other, non-computing contexts), merely rearranging technical functions may lead to frustration. "A distributed network does not automatically yield an egalitarian, equitable or just social, economic, political landscape" [Bodo].
全体として、関数を分散化するにはかなりの仕事が必要であり、本質的に政治的であり、結果についての大きな不確実性が含まれます。地方分権化をより大きな社会的目標と見なしている場合（その用語が他の非計算の文脈でどのように使用されるかという精神で）、単に技術的な機能を再配置するだけではフラストレーションにつながる可能性があります。「分散ネットワークは、平等主義、公平、または単なる社会的、経済的、政治的景観を自動的に生成しません」[ボドー]。
This section examines some common strategies that are employed to decentralize Internet functions and discusses their limitations.
このセクションでは、インターネット機能を分散させるために採用されているいくつかの一般的な戦略を検討し、それらの制限について説明します。
Protocol designers often attempt to address centralization through federation, i.e., designing a function in a way that uses independent instances that maintain connectivity and interoperability to provide a single cohesive service. Federation promises to allow users to choose the instance they associate with and accommodates substitution of one instance for another, lowering switching costs.
プロトコル設計者は、多くの場合、連邦を通じて集中化に対処しようとします。つまり、接続性と相互運用性を維持して単一の凝集サービスを提供する独立したインスタンスを使用する方法で機能を設計します。連邦は、ユーザーが関連付けられたインスタンスを選択し、あるインスタンスの代替を別のインスタンスに選択できるようにすることを約束し、スイッチングコストを削減します。
However, federation alone is insufficient to prevent or mitigate centralization of a function because non-technical factors can create pressure to use a central solution.
ただし、非技術的要因が中心ソリューションを使用するよう圧力をかける可能性があるため、連邦のみが関数の集中化を防止または軽減するには不十分です。
For example, the email suite of protocols needs to route messages to a user even when that user changes network locations or becomes disconnected for a long period. To facilitate this, SMTP [RFC5321] defines a specific role for routing users' messages, the Message Transfer Agent (MTA). By allowing anyone to deploy an MTA and defining rules for interconnecting them, the protocol avoids a requirement for a single central server in that role; users can (and often do) choose to delegate it to someone else or they can run their own MTA.
たとえば、電子メールスイートのプロトコルは、ユーザーがネットワークの場所を変更したり、長期間切断されたりしても、メッセージをユーザーにルーティングする必要があります。これを容易にするために、SMTP [RFC5321]は、ユーザーのメッセージをルーティングするための特定の役割であるメッセージ転送エージェント（MTA）を定義します。誰でもMTAを展開し、それらを相互接続するためのルールを定義できるようにすることにより、プロトコルはその役割における単一の中央サーバーの要件を回避します。ユーザーは、それを他の誰かに委任することを選択することができます（そして頻繁に行う）、または自分のMTAを実行することができます。
Running one's own MTA has become considerably more onerous over the years due, in part, to the increasingly complex mechanisms introduced to fight unwanted commercial emails. These costs create an incentive to delegate one's MTA to a third party who has the appropriate expertise and resources, contributing to market concentration [Holzbauer].
自分のMTAを運営することは、不要な商業電子メールと戦うために導入されたますます複雑なメカニズムに一部起因して、長年にわたってかなり面倒になっています。これらのコストは、適切な専門知識とリソースを持つ第三者にMTAを委任するインセンティブを生み出し、市場集中に貢献しています[Holzbauer]。
Additionally, the measures that MTAs use to identify unwanted commercial emails are often site specific. Because large MTAs handle so many more addresses, there is a power imbalance with smaller ones; if a large MTA decides that email from a small one is unwanted, there is significant impact on its ability to function and little recourse.
さらに、MTAが不要な商用電子メールを識別するために使用する測定値は、多くの場合サイト固有です。大規模なMTAは非常に多くのアドレスを処理するため、より小さなアドレスとのパワーの不均衡があります。大規模なMTAが小さなものからその電子メールが望ましくないと判断した場合、機能する能力とほとんど頼みの能力に大きな影響があります。
The Extensible Messaging and Presence Protocol (XMPP) [RFC6120] is a chat protocol that demonstrates another issue with federation: the voluntary nature of technical standards.
拡張可能なメッセージングおよびプレゼンスプロトコル（XMPP）[RFC6120]は、連邦に関する別の問題を示すチャットプロトコルです。技術標準の自発的な性質です。
Like email, XMPP is federated to facilitate the rendezvous of users from different systems - if they allow it. While some XMPP deployments do support truly federated messaging (i.e., a person using service A can interoperably chat with someone using service B), many of the largest do not. Because federation is voluntary, some operators captured their users into a single service, deliberately denying them the benefits of global interoperability.
メールと同様に、XMPPは、異なるシステムのユーザーのランデブーを促進するためにフェデレーションされています。一部のXMPPの展開は、真にフェデレーションされたメッセージング（つまり、サービスAを使用する人はサービスBを使用している人と相互作用可能にチャットできます）をサポートしていますが、最大の多くはそうではありません。フェデレーションは自発的であるため、一部のオペレーターはユーザーを単一のサービスに獲得し、グローバルな相互運用性の利点を意図的に否定しました。
The examples above illustrate that, while federation can create the conditions necessary for a function to be decentralized, it does not guarantee that outcome.
上記の例は、連邦が関数を分散化するために必要な条件を作成できるが、その結果を保証しないことを示しています。
Increasingly, distributed consensus technologies (such as a blockchain) are touted as a solution to centralization. A complete survey of this rapidly changing area is beyond the scope of this document, but we can generalize about its properties.
ますます、分散コンセンサステクノロジー（ブロックチェーンなど）は、集中化の解決策として宣伝されています。この急速に変化するエリアの完全な調査は、このドキュメントの範囲を超えていますが、そのプロパティについて一般化することができます。
These techniques typically guarantee proper performance of a function using cryptographic techniques (often, an append-only transaction ledger). They attempt to avoid centralization by distributing the operation of a function to members of a sometimes large pool of protocol participants. Usually, the participants are unknown and untrusted, and a particular task's assignment to a node for handling cannot be predicted or controlled.
これらの手法は、通常、暗号化技術（多くの場合、付録のみのトランザクション元帳）を使用して、関数の適切なパフォーマンスを保証します。彼らは、プロトコル参加者の大規模なプールのメンバーに関数の操作を配布することにより、集中化を避けようとします。通常、参加者は不明で信頼されておらず、処理用のノードへの特定のタスクの割り当てを予測または制御することはできません。
Sybil attacks (where a party or coordinated parties cheaply create enough protocol participants to affect how consensus is judged) are a major concern for these protocols because they would have the effect of concentrating power into the hands of the attacker. Therefore, they encourage diversity in the pool of participants using indirect techniques, such as proof-of-work (where each participant has to show a significant consumption of resources) or proof-of-stake (where each participant has some other incentive to execute correctly).
シビル攻撃（当事者または調整された当事者がコンセンサスの判断に影響を与えるのに十分なプロトコル参加者を安く作成する）は、攻撃者の手に力を集中させる効果があるため、これらのプロトコルにとって大きな関心事です。したがって、彼らは、仕事の証明（各参加者がリソースの大幅な消費を示さなければならない場合）やステークの証明（各参加者が他のインセンティブを実行するインセンティブがある場合など、間接的な手法を使用して参加者のプールの多様性を奨励します。正しく）。
While these measures can be effective in decentralizing a function's operation, other aspects of its provision can still be centralized: for example, governance of its design, creation of shared implementations, and documentation of wire protocols. That need for coordination is an avenue for centralization even when the function's operation remains decentralized. For example, the Ethereum "merge" demonstrated that the blockchain could address environmental concerns but only through coordinated community effort and governance: coordination that was benign in most eyes but, nevertheless, centralized [ETHEREUM].
これらの手段は関数の操作の分散化に効果的ですが、その規定の他の側面は依然として集中化できます。たとえば、その設計のガバナンス、共有実装の作成、ワイヤープロトコルの文書化。調整の必要性は、関数の操作が分散化されたままであっても、集中化の道です。たとえば、イーサリアムの「マージ」は、ブロックチェーンが環境への懸念に対処できることを実証しましたが、それは協調的なコミュニティの努力とガバナンス、つまりほとんどの目で良性であったが、それにもかかわらず、集中化された[イーサリアム]であることを実証しました。
Furthermore, a protocol or an application composed of many functions can use distributed consensus for some but still be centralized elsewhere -- either because those other functions cannot be decentralized (most commonly, rendezvous and global naming; see Section 2.2) or because the designer has chosen not to because of the associated costs and lost opportunities.
さらに、多くの関数で構成されるプロトコルまたはアプリケーションは、分散コンセンサスを一部の人に使用できますが、他の場所では集中化できます。これらの機能は分散化できないため（最も一般的には、ランデブーとグローバルの命名を参照してください。セクション2.2を参照）、デザイナーが持っているためです。関連するコストと失われた機会のために選択されません。
These potential shortcomings do not rule out the use of distributed consensus technologies in every instance, but they do merit caution against uncritically relying upon these technologies to avoid or mitigate centralization. Too often, the use of distributed consensus is perceived as imbuing all parts of a project with "decentralization".
これらの潜在的な欠点は、あらゆるインスタンスで分散コンセンサステクノロジーの使用を排除するものではありませんが、集中化を回避または軽減するために、これらの技術に批判的に依存していることに対して注意を払っています。多くの場合、分散コンセンサスの使用は、プロジェクトのすべての部分に「分散化」を吹き込んでいると認識されます。
Federation and distributed consensus can both create the conditions for the provision of a function by multiple providers, but they cannot guarantee it. However, when providers require access to a resource or cooperation of others to provide that service, that choke point can itself be used to influence provider behavior -- including in ways that can counteract centralization.
連盟と分散コンセンサスは、両方とも複数のプロバイダーによる関数の提供の条件を作成できますが、それを保証することはできません。ただし、プロバイダーがそのサービスを提供するために他者のリソースまたは協力へのアクセスを必要とする場合、そのチョークポイント自体を使用してプロバイダーの行動に影響を与えることができます。
In these circumstances, some form of governance over that choke point is necessary to assure the desired outcome. Often, this is through the establishment of a multi-stakeholder body, which is an institution that includes representatives of the different kinds of parties that are affected by the system's operation ("stakeholders") in an attempt to make well-reasoned, legitimate, and authoritative decisions.
これらの状況では、そのチョークポイントをめぐる何らかの形のガバナンスが、望ましい結果を保証するために必要です。多くの場合、これはマルチステークホルダー団体の設立を通じてです。これは、システムの操作（「利害関係者」）の影響を受けるさまざまな種類の当事者の代表者を含む機関であり、十分に合理的で正当な、および権威ある決定。
A widely studied example of this technique is the governance of the DNS name space, which exhibits centralization as a "single source of truth" [Moura]. That source of truth is overseen by the Internet Corporation for Assigned Names and Numbers (ICANN) <https://www.icann.org/resources/pages/governance/governance-en>, a global multi-stakeholder body with representation from end users, governments, operators, and others.
この手法の広く研究されている例は、「真実の単一源」[Moura]として集中化を示すDNS名空間のガバナンスです。その真実の源泉は、割り当てられた名前と数字についてインターネット企業によって監督されています（ICANN）<https://www.icann.org/resources/pages/governance/governance-en>、エンドから表現を持つグローバルなマルチステークホルダーボディボディユーザー、政府、オペレーター、その他。
Another example is the governance of the Web's trust model, implemented by web browsers as relying parties that have strong incentives to protect user privacy and security and CAs as trust anchors that have a strong incentive to be included in browser trust stores. To promote the operational and security requirements necessary to provide the desired properties, the CA/Browser Forum <https://cabforum.org> was established as an oversight body that involves both parties as stakeholders.
もう1つの例は、ユーザーのプライバシーとセキュリティを保護するための強力なインセンティブを持つ依存関係者としてWebブラウザーによって実装されたWebの信頼モデルのガバナンスです。目的のプロパティを提供するために必要な運用およびセキュリティの要件を促進するために、CA/ブラウザフォーラム<https://cabforum.org>は、両方の当事者を利害関係者として関与させる監視機関として確立されました。
These examples are notable in that the governance mechanism is not specified in the protocol documents directly; rather, they are layered on operationally, but in a manner that takes advantage of protocol features that enable the imposition of governance.
これらの例は、プロトコルドキュメントではガバナンスメカニズムが直接指定されていないという点で注目に値します。むしろ、それらは操作的に階層化されていますが、ガバナンスの賦課を可能にするプロトコル機能を利用する方法で階層化されています。
Governance in this manner is suited to very limited functions like the examples above. Even then, the setup and ongoing operation of a governance mechanism is not trivial, and their legitimacy may be difficult to establish and maintain (e.g., see [Palladino]); by their nature, they are vulnerable to capture by the interests that are being governed.
この方法でのガバナンスは、上記の例のように非常に限られた関数に適しています。それでも、ガバナンスメカニズムのセットアップと継続的な操作は些細なものではなく、それらの正当性を確立して維持することは困難かもしれません（たとえば、[Palladino]を参照）。彼らの性質上、彼らは統治されている利益によって捕らえることを脆弱です。
Given the limits of decentralization techniques like federation and distributed consensus, the voluntary nature of standards compliance, and the powerful forces that can drive centralization, it is reasonable to ask what standards efforts like those at the IETF can do to accommodate helpful centralization while avoiding the associated harms and acknowledging that the distinction itself is a judgment call and, therefore, inherently political.
連盟や分散コンセンサス、標準コンプライアンスの自発的な性質、および集中化を促進できる強力な力などの地方分権化手法の限界を考えると、IETFのような基準の努力が役立つ集中化に対応するためにできる基準の取り組みを尋ねることは合理的です。関連することは、区別自体が判断の呼びかけであり、したがって、本質的に政治的であることを害と認めます。
The subsections below suggest a few concrete, meaningful steps that standards bodies can take.
以下のサブセクションは、基準機関がとることができるいくつかの具体的で意味のある手順を示唆しています。
Where technical standards have only limited ability to control centralization of the Internet, legal standards (whether regulation, legislation, or case law) show more promise and are actively being considered and implemented in various jurisdictions. However, regulating the Internet is risky without a firm grounding in the effects on the architecture informed by a technical viewpoint.
技術基準がインターネットの集中化を制御する能力しか限られていない場合、法的基準（規制、法律、または判例法）がより多くの有望であるかどうかにかかわらず、さまざまな管轄区域で積極的に検討および実施されています。ただし、技術的な視点によって通知されるアーキテクチャへの影響をしっかりと根付かせることなく、インターネットを規制することは危険です。
That viewpoint can and should be provided by the Internet standards community. To effectively do so, its institutions must be seen as legitimate by the relevant parties -- for example, competition regulators. If the IETF is perceived as representing or being controlled by "big tech" concerns or only US-based companies, its ability to guide decisions that affect the Internet will be diminished considerably.
その視点は、インターネット標準コミュニティによって提供されることができます。そのためには、その機関は、関連当事者、たとえば競争規制当局によって合法的であると見なされなければなりません。IETFが「ビッグテクノロジー」の懸念または米国ベースの企業のみを表す、または管理されていると認識されている場合、インターネットに影響を与える決定を導く能力はかなり減少します。
The IETF already has features that arguably provide considerable legitimacy. Examples of these features include open participation and representation by individuals rather than by companies, both of which enhance input legitimacy); a well-defined process with multiple layers of appeals and transparency, which contributes to throughput legitimacy; and a long history of successful Internet standards, which provides perhaps the strongest source of legitimacy for the IETF -- its output.
IETFには、間違いなくかなりの正当性を提供する機能が既にあります。これらの機能の例には、企業ではなく個人によるオープンな参加と表現が含まれます。どちらも、入力の正当性を高めます）。スループットの正当性に貢献する複数の魅力と透明性を備えた明確に定義されたプロセス。インターネット標準の成功の長い歴史は、おそらくIETFの正当性の最も強力なソースであるその出力を提供します。
However, it is also widely recognized that the considerable costs (not just financial) involved in successfully participating in the IETF have a tendency to favor larger companies over smaller concerns. Additionally, the specialized and highly technical nature of the work creates barriers to entry for non-technical stakeholders. These factors have the potential to reduce the legitimacy of the IETF's decisions, at least in some eyes.
ただし、IETFへの首尾よく参加することに伴うかなりのコスト（財政的だけでなく）が、より小さな懸念よりも大企業を支持する傾向があることも広く認識されています。さらに、この作業の専門的で高度に技術的な性質は、非技術的な利害関係者の参入の障壁を作り出します。これらの要因は、少なくともいくつかの目では、IETFの決定の正当性を減らす可能性があります。
Efforts to address these shortcomings are ongoing; for example, see [RFC8890]. Overall, bolstering the legitimacy of the organization should be seen as a continuous effort.
これらの欠点に対処する努力は進行中です。たとえば、[RFC8890]を参照してください。全体として、組織の正当性を強化することは、継続的な努力と見なされるべきです。
When engaging in external efforts, the IETF community (especially its leadership) should keep firmly in mind that its voice is most authoritative when focused on technical and architectural impact.
外部の努力に従事する場合、IETFコミュニティ（特にそのリーダーシップ）は、技術的および建築的影響に焦点を当てた場合、その声は最も権威があることをしっかりと留意する必要があります。
Centralization and decentralization are increasingly being raised in technical standards discussions. Any claim needs to be critically evaluated. As discussed in Section 2, not all centralization is automatically harmful. Per Section 3, decentralization techniques do not automatically address all centralization harms and may bring their own risks.
中央集権化と分散化は、技術基準の議論でますます提起されています。請求を批判的に評価する必要があります。セクション2で説明したように、すべての集中化が自動的に有害であるわけではありません。セクション3に従って、地方分権化手法は、すべての集中化の危害に自動的に対処せず、独自のリスクをもたらす可能性があります。
However, standards participants rarely have the expertise or information available to completely evaluate those claims, because the analysis involves not only technical factors, but also economic, social, commercial, and legal aspects. For example, economies of scale can cause concentration due to the associated efficiencies [Demsetz], and so determining whether that concentration is appropriate requires a detailed economic analysis that is not in scope for a technical standards body. Furthermore, claims of centralization may have other motivations; in particular, they can be proxies for power struggles between actors with competing interests, and a claim of centralization might be used to deny market participants and (perhaps more importantly) users the benefits of standardization.
ただし、分析には技術的要因だけでなく、経済的、社会的、商業的、および法的側面も含まれるため、標準参加者がこれらの主張を完全に評価するために利用できる専門知識や情報を持つことはめったにありません。たとえば、規模の経済は、関連する効率[Demsetz]のために集中を引き起こす可能性があり、その濃度が適切であるかどうかを判断するには、技術基準体の範囲ではない詳細な経済分析が必要です。さらに、集中化の主張には他の動機があるかもしれません。特に、彼らは競合する関心のある俳優間の権力闘争の代理であり、中央集権化の主張を使用して、市場参加者と（おそらくより重要なことに）標準化の利点をユーザーに拒否することができます。
Therefore, approaches like requiring a "Centralization Considerations" section in documents, gatekeeping publication on a centralization review, or committing significant resources to searching for centralization in protocols are unlikely to improve the Internet.
したがって、ドキュメントに「集中考慮事項」セクションを要求する、集中レビューでのゲートキーピングの出版物、またはプロトコルの集中化を検索するための重要なリソースをコミットするなどのアプローチは、インターネットを改善する可能性は低いです。
Similarly, refusing to standardize a protocol because it does not actively prevent all forms of centralization ignores the very limited power that standards efforts have to do so. Almost all existing Internet protocols -- including IP, TCP, HTTP, and DNS -- fail to prevent centralized applications from using them. While the imprimatur of the standards track [RFC2026] is not without value, merely withholding it cannot prevent centralization.
同様に、あらゆる形態の集中化を積極的に防止しないため、プロトコルの標準化を拒否すると、標準の努力がそうしなければならない非常に限られた力が無視されます。IP、TCP、HTTP、DNSを含むほとんどすべての既存のインターネットプロトコルは、集中化されたアプリケーションがそれらの使用を防ぐことができません。標準トラック[RFC2026]の不正行為には価値がないわけではありませんが、単に集中化を防ぐことはできません。
Thus, discussions should be very focused and limited, and any proposals for decentralization should be detailed so their full effects can be evaluated. [Schneider1] implores those who propose decentralization to be "really, really clear about what particular features of a system a given design seeks to decentralize" and promotes considered use of tools like separation of powers and accountability from "old, institutional liberal political theory".
したがって、議論は非常に集中し、限られている必要があり、地方分権化の提案を詳細に説明して、その完全な効果を評価できるようにする必要があります。[Schneider1]は、地方分権化を提案する人々に「特定の設計が分散化しようとするシステムの特定の特徴を本当に、本当に明確にする」ことを懇願し、「古い、制度的リベラルな政治理論」からのパワーの分離や説明責任などのツールの使用と見なされる使用を促進することを促進します。。
When evaluating claims that a given proposal is centralized, the context of those statements should be examined for presuppositions, assumptions, and omissions. [Bacchi] offers one framework for critical interrogations, which can be adapted for centralization-related discussions:
特定の提案が集中化されているという主張を評価する場合、これらの声明のコンテキストは、前提、仮定、および不作為について検討する必要があります。[Bacchi]は、重大な尋問のための1つのフレームワークを提供します。これは、集中関連の議論に適合させることができます。
1. What is the nature of the centralization that is represented as being problematic?
1. 問題があると表される集中化の性質は何ですか？
1. What deep-seated presuppositions or assumptions (conceptual logics) underlie this representation of the "problem"?
1. この「問題」のこの表現の根底にある、根深い前提または仮定（概念論理）は何ですか？
1. How has this representation of the problem come about?
1. この問題のこの表現はどのように生まれましたか？
1. What is left unproblematic in this problem representation? Where are the silences? Can the "problem" be conceptualized differently?
1. この問題の表現では、何が問題ではありませんか？沈黙はどこにありますか？「問題」を概念化することは異なりますか？
1. What effects are produced by this representation of the "problem"?
1. この「問題」のこの表現によってどのような効果が生じますか？
1. How and where has this representation of the "problem" been produced, disseminated, and defended? How has it been and/or how can it be disrupted and replaced?
1. この「問題」のこの表現は、どのように、どこで生産され、普及し、擁護されていますか？それはどのように、そして/またはどのようにそれを混乱させて置き換えることができましたか？
Functions that are widely used but lacking in interoperability are ripe for standardization efforts. Targeting prominent and proprietary functions (e.g., chat) is appropriate, but so are smaller efforts to improve interoperability and portability of specific features that are often used to lock users into a platform, for example, a format for lists of contacts in a social network.
広く使用されているが、相互運用性に欠けている機能は、標準化の取り組みに熟している。顕著で独自の機能をターゲットにすること（チャットなど）が適切ですが、ユーザーをプラットフォームにロックするためによく使用される特定の機能の相互運用性と移植性を改善するためのより小さな努力も適しています。。
A common objection to this approach is that adoption is voluntary; there are no "standards police" to mandate their use or enforce correct implementation. For example, specifications like [ACTIVITYSTREAMS] were available for some time without being used in a federated manner by commercial social-networking providers.
このアプローチに対する一般的な異議は、採用が自発的であるということです。彼らの使用を義務付けたり、正しい実装を施行する「標準警察」はありません。たとえば、[ActivityStreams]のような仕様は、商業的なソーシャルネットワーキングプロバイダーによって連邦政府の方法で使用されることなく、しばらくの間利用可能でした。
That objection ignores the fact that while standards aren't mandatory, legal regulation is. Legal mandates for interoperability are increasingly proposed by policymakers as a remedy for competition issues (e.g., see [DMA]). This appetite for regulation presents an opportunity for new specifications to decentralize these functions, backed by a legal mandate in combination with changing norms and the resulting market forces [Lessig].
その異議は、標準が必須ではないが、法的規制がそうであるという事実を無視している。相互運用性の法的委任は、競争問題の救済策として政策立案者によってますます提案されています（例：[DMA]を参照）。規制に対するこの食欲は、規範の変化と結果として生じる市場の力と組み合わせた法的任務に裏付けられた、これらの機能を分散させる新しい仕様の機会を提示します[Lessig]。
That opportunity also presents a risk, if the resulting legal regulation is at odds with the Internet architecture. Successfully creating standards that work in concert with legal regulation presents many potential pitfalls and will require new and improved capabilities (especially liaison) and considerable effort. If the technical community does not make that effort, it is likely that regulators will turn to other sources for interoperability specifications.
結果として生じる法的規制がインターネットアーキテクチャと対立している場合、その機会もリスクをもたらします。法的規制と協力して機能する標準の作成には、多くの潜在的な落とし穴が提示され、新しい改善された能力（特にリエゾン）とかなりの努力が必要になります。技術コミュニティがその努力をしない場合、規制当局は相互運用性の仕様のために他のソースに頼る可能性があります。
The ability to switch between different function providers is a core mechanism to control centralization. If users are unable to switch, they cannot exercise choice or fully realize the value of their efforts because, for example, "learning to use a vendor's product takes time, and the skill may not be fully transferable to a competitor's product if there is inadequate standardization" [FarrellJ].
異なる機能プロバイダーを切り替える機能は、集中化を制御するためのコアメカニズムです。ユーザーが切り替えられない場合、たとえば「ベンダーの製品を使用することを学ぶことは時間がかかり、スキルが不十分な場合は競合他社の製品に完全に譲渡できない可能性があるため、選択を行使したり、努力の価値を完全に実現できません。標準化 "[farrellj]。
Therefore, standards should have an explicit goal of facilitating users switching between implementations and deployments of the functions they define or enable.
したがって、標準には、実装と有効化の機能の実装と展開を切り替えるユーザーを促進するという明確な目標が必要です。
One necessary condition for switching is the availability of alternatives; breadth and diversity of implementation and deployment are required. For example, if there is only a single implementation of a protocol, applications that use it are vulnerable to the control it has over their operation. Even open source projects can be an issue in this regard if there are factors that make forking difficult (for example, the cost of maintaining that fork). Section 2.1 of [RFC5218] explores some factors in protocol design that encourage diversity of implementation.
切り替えに必要な条件の1つは、代替案の可用性です。実装と展開の幅と多様性が必要です。たとえば、プロトコルの単一の実装のみがある場合、それを使用するアプリケーションは、操作に対して持っている制御に対して脆弱です。オープンソースプロジェクトでさえ、この点に関して、フォークを困難にする要因がある場合（たとえば、そのフォークを維持するコスト）。[RFC5218]のセクション2.1では、実装の多様性を促進するプロトコル設計のいくつかの要因を調査します。
The cost of substituting an alternative implementation or deployment by users is another important factor to consider. This includes minimizing the amount of time, resources, expertise, coordination, loss of functionality, and effort required to use a different provider or implementation -- with the implication that the standard needs to be functionally complete and specified precisely enough to allow substitution.
ユーザーによる代替の実装または展開を置き換えるコストは、考慮すべきもう1つの重要な要素です。これには、時間、リソース、専門知識、調整、機能の喪失、異なるプロバイダーまたは実装を使用するために必要な労力を最小限に抑えることが含まれます。
These goals of completeness and diversity are sometimes at odds. If a standard becomes extremely complex, it may discourage implementation diversity because the cost of a complete implementation is too high (consider web browsers). On the other hand, if the specification is too simple, it may not enable easy switching, especially if proprietary extensions are necessary to complete it (see Section 4.7).
完全性と多様性のこれらの目標は、時々対立しています。標準が非常に複雑になった場合、完全な実装のコストが高すぎるため、実装の多様性を阻止する可能性があります（Webブラウザーを考慮してください）。一方、仕様が単純すぎる場合、特にそれを完了するために独自の拡張機能が必要な場合は、簡単な切り替えを可能にしない場合があります（セクション4.7を参照）。
One objection to protocols that enable easy switching is that they reduce the incentives for implementation by commercial vendors. While a completely commoditized protocol might not allow implementations to differentiate themselves, they provide opportunities for specialization and improvement elsewhere in the value chain [Christensen]. Well-timed standards efforts leverage these forces to focus proprietary interests on top of open technology rather than as a replacement for it.
簡単な切り替えを可能にするプロトコルに対する異議の1つは、商業ベンダーによる実装のインセンティブを減らすことです。完全にコモディティ化されたプロトコルは、実装が自分自身を区別することを許可しないかもしれませんが、バリューチェーンの他の場所で専門化と改善の機会を提供します[Christensen]。適切な標準の努力は、これらの力を活用して、独自の関心を、それに代わるものとしてではなく、オープンテクノロジーに加えて集中します。
The users of some functions might realize substantial benefits if they are provided by a third party in communication. Adding a new party to communication can improve the following:
一部の機能のユーザーは、コミュニケーションの第三者から提供されている場合、大きな利点を実現する可能性があります。コミュニケーションに新しいパーティーを追加すると、以下を改善できます。
* _Efficiency_: Many functions on the Internet are more efficient when performed at a higher scale. For example, a content delivery network can offer services at a fraction of the financial and environmental cost that someone serving content themselves would otherwise pay because of the scale they operate at. Likewise, a two-sided market platform can introduce sizable efficiencies over pair-wise buyer/seller trading [Spulber].
* _EFFICITY _：インターネット上の多くの機能は、高スケールで実行されるとより効率的です。たとえば、コンテンツ配信ネットワークは、コンテンツにサービスを提供している人が運営しているため、コンテンツにサービスを提供する財務および環境コストの一部でサービスを提供できます。同様に、両面市場プラットフォームは、ペアワイズの買い手/売り手取引[Spulber]にかなりの効率を導入できます。
* _Simplicity_: Completely disintermediating communication can shift the burden of functions onto endpoints. This can cause increased cognitive load for users; for example, compare commercial social-networking platforms with self-hosted efforts.
* _SIMPLICITY _：完全に介入する通信は、関数の負担をエンドポイントにシフトする可能性があります。これにより、ユーザーの認知負荷が増加する可能性があります。たとえば、商業的なソーシャルネットワーキングプラットフォームを自己ホストの努力と比較してください。
* _Specialization_: Having a function consolidated into a few hands can improve outcomes because of the resulting specialization. For example, services overseen by professional administrators are often seen to have a better security posture and improved availability.
* _SPECIALIZATION _：関数を数ハンドに統合することで、結果として生じる専門化のために結果を改善できます。たとえば、プロの管理者が監督するサービスは、セキュリティ姿勢が改善され、可用性が向上していることがよくあります。
* _Privacy_: For some functions, user privacy can be improved by consolidating their activity to prevent individual behaviors from being discriminated from each other [Chaum]. Introduction of a third party can also enforce functional boundaries -- for example, to reduce the need for users to trust potentially malicious endpoints, as seen in the so-called "oblivious" protocols (e.g., [RFC9230]) that allow end users to hide their identity from services while still accessing them.
* _Privacy_：一部の機能については、個々の行動が互いに差別されないようにアクティビティを統合することにより、ユーザーのプライバシーを改善できます[Chaum]。サードパーティの導入は、機能的境界を実施することもできます。たとえば、ユーザーがエンドユーザーを可能にするいわゆる「忘れられない」プロトコル（例えば[RFC9230]）に見られるように、ユーザーが潜在的に悪意のあるエンドポイントを信頼する必要性を減らすこともできます。サービスにアクセスしながら、サービスからアイデンティティを隠します。
However, if that new party is able to make their participation "sticky" -- for example, by leveraging their position in the network to require use of an intermediary, by exploiting their access to data, or because it is difficult to switch to another provider of the function -- there is a risk of centralization.
ただし、その新しい当事者が参加を「スティッキー」にすることができる場合 - たとえば、ネットワークでのポジションを活用して仲介者の使用を要求すること、データへのアクセスを活用することによって、または他の人に切り替えることが困難であるため関数のプロバイダー - 集中化のリスクがあります。
Most often, third parties are added to functions as "intermediaries" or in designated "agent" roles. Designing such functions with thoughtful constraints on these roles can prevent at least the most egregious abuses of such power.
ほとんどの場合、第三者は「仲介者」または指定された「エージェント」の役割として機能に追加されます。これらの役割に思慮深い制約でそのような機能を設計すると、少なくともそのような力の最もひどい虐待を防ぐことができます。
When adding new parties to a function, two guidelines have proven useful. First, third parties should only be interposed into communication when at least one of the primary parties takes a positive action to do so. Second, third parties should have their ability to observe or control communication limited to what is necessary to perform their intended function.
関数に新しいパーティーを追加すると、2つのガイドラインが有用であることが証明されています。第一に、第三者は、少なくとも1つの主要な当事者がそうするために前向きな行動をとる場合にのみ、コミュニケーションに介入する必要があります。第二に、第三者は、意図した機能を実行するために必要なものに制限されているコミュニケーションを観察または制御する能力を持つ必要があります。
For example, early deployments of HTTP allowed intermediaries to be interposed by the network without knowledge of the endpoints, and those intermediaries could see and change the full content of traffic by default -- even when they were only intended to perform basic functions such as caching. Because of the introduction of HTTPS and the CONNECT method (see Section 9.3.6 of [HTTP]), combined with efforts to encourage its adoption, those intermediaries are now required to be explicitly interposed by one endpoint, and they only have access to basic routing information.
たとえば、HTTPの早期展開により、仲介者はエンドポイントの知識なしにネットワークに介入することができ、それらの仲介者は、キャッシュなどの基本的な機能を実行することを意図している場合でも、デフォルトでトラフィックの完全なコンテンツを見て変更できます。。HTTPSとConnectメソッドの導入（[HTTP]のセクション9.3.6を参照）と採用を促進する努力と組み合わせて、これらの仲介者は1つのエンドポイントによって明示的に介入される必要があり、基本的なアクセスのみがあります。ルーティング情報。
See [THOMSON-TMI] for more guidance on protocol intermediation.
プロトコル仲介に関する詳細については、[Thomson-TMI]を参照してください。
The term "intermediary" is also used (often in legal and regulatory contexts) more broadly than it has been in protocol design; for example, an auction website that intermediates between buyers and sellers is considered an intermediary, even though it is not formally an intermediary in HTTP (see Section 3.7 of [HTTP]). Protocol designers can address the centralization associated with this kind of intermediation by standardizing the function rather than restricting the capabilities of the underlying protocols; see Section 4.3.
「仲介者」という用語は、プロトコル設計よりも広く（法的および規制の文脈で）使用されます。たとえば、HTTPの中間ではないにもかかわらず、買い手と売り手の間の中間体が仲介者と見なされるオークションウェブサイト（[HTTP]のセクション3.7を参照）。プロトコル設計者は、基礎となるプロトコルの機能を制限するのではなく、関数を標準化することにより、この種の仲介に関連する集中化に対処できます。セクション4.3を参照してください。
Most Internet protocols and applications depend on other, "lower-layer" functions and their implementations. The features, deployment, and operation of these dependencies can become centralization risks for the functions and applications built "on top" of them.
ほとんどのインターネットプロトコルとアプリケーションは、他の「低層」関数とその実装に依存します。これらの依存関係の機能、展開、および操作は、それらの「上に」構築された機能とアプリケーションの集中リスクになる可能性があります。
For example, application protocols require a network to function; therefore, a degree of power over communication is available to the network provider. They might block access to, slow down, or change the content of a specific service for financial, political, operational, or criminal reasons, creating a disincentive (or even removing the ability) to use a specific provider of a function. By selectively hindering the use of some services but not others, network interventions can be composed to create pressure to use those other services -- intentionally or not.
たとえば、アプリケーションプロトコルは機能するためのネットワークを必要とします。したがって、ネットワークプロバイダーは、通信をめぐる程度の電力を利用できます。彼らは、財政的、政治的、運用上、または犯罪的理由に対する特定のサービスのコンテンツへのアクセスをブロックしたり、減速させたり、変更したりして、機能の特定のプロバイダーを使用する（または能力を削除）する（または能力を削除する）ことがあります。一部のサービスの使用を選択的に妨害するが、他のサービスではなく使用することにより、ネットワーク介入を構成することができます。
Techniques like encryption can discourage such centralization by enforcing such boundaries. When the number of parties who have access to the content of communication is limited, other parties who handle it but are not party to it can be prevented from interfering with and observing it. Although those parties might still prevent communication, encryption also makes it more difficult to discriminate a target from other users' traffic.
暗号化のような手法は、そのような境界を施行することにより、そのような集中化を阻止できます。コミュニケーションの内容にアクセスできる当事者の数が限られている場合、それを処理していないが、当事者ではない他の当事者は、それを妨害して観察することを防ぐことができます。これらの当事者は依然としてコミュニケーションを防ぐかもしれませんが、暗号化により、ターゲットを他のユーザーのトラフィックから区別することも困難になります。
The Internet's ability to evolve is critical, allowing it to meet new requirements and adapt to new conditions without requiring a "flag day" to upgrade implementations. Typically, functions accommodate evolution by defining extension interfaces, which allow optional features to be added or change over time in an interoperable fashion.
インターネットの進化能力は重要であり、実装をアップグレードするために「フラグデイ」を必要とせずに、新しい要件を満たし、新しい条件に適応することができます。通常、関数は、拡張インターフェイスを定義することにより進化に対応します。これにより、オプションの機能を相互運用可能な方法で時間の経過とともに変更または変更できます。
However, these interfaces can also be leveraged by a powerful entity if they can change the target for meaningful interoperability by adding proprietary extensions to a standard. This is especially true when the core standard does not itself provide sufficient utility on its own.
ただし、これらのインターフェイスは、独自の拡張機能を標準に追加することで意味のある相互運用性のターゲットを変更できる場合、強力なエンティティによって活用される可能性もあります。これは、Core標準自体が十分なユーティリティを自然に提供しない場合に特に当てはまります。
For example, the extreme flexibility of SOAP [SOAP] and its failure to provide significant standalone value allowed vendors to require use of their preferred extensions, favoring those who had more market power.
たとえば、SOAP [SOAP]の極端な柔軟性と、重要なスタンドアロン価値を提供できなかったため、ベンダーは優先拡張機能の使用を要求し、より多くの市場力を持っている人を支持することができました。
Therefore, standards efforts should focus on providing concrete utility to the majority of their users as published, rather than being a "framework" where interoperability is not immediately available. Internet functions should not make every aspect of their operation extensible; boundaries between modules should be designed in a way that allows evolution, while still offering meaningful functionality.
したがって、標準の取り組みは、相互運用性がすぐに利用できない「フレームワーク」ではなく、公開されたユーザーの大多数に具体的なユーティリティを提供することに焦点を当てる必要があります。インターネット機能は、操作のあらゆる側面を拡張可能にするべきではありません。モジュール間の境界は、意味のある機能を提供しながら、進化を可能にする方法で設計する必要があります。
Beyond allowing evolution, well-considered interfaces can also aid decentralization efforts. The structural boundaries that emerge between the sub-modules of the function -- as well as those with adjacent functions -- provide touchpoints for interoperability and an opportunity for substitution of providers.
進化を可能にするだけでなく、よく考慮されたインターフェイスは、地方分権化の取り組みを支援することもできます。関数のサブモジュールと隣接する関数を持つものとの間に現れる構造境界は、相互運用性とプロバイダーの代替機会のタッチポイントを提供します。
In particular, if the interfaces of a function are well-defined and stable, there is an opportunity to use different providers for that function. When those interfaces are open standards, change control resides with the technical community instead of remaining in proprietary hands, further enhancing stability and enabling (but not ensuring) decentralization.
特に、関数のインターフェイスが明確に定義され、安定している場合、その関数に異なるプロバイダーを使用する機会があります。これらのインターフェイスがオープンな基準である場合、変更制御は独自の手にとどまるのではなく、技術コミュニティに存在し、安定性をさらに強化し、分散化を可能にします（ただします）。
When centralization is purposefully allowed in an Internet function, protocol designers often attempt to mitigate the associated risks using technical measures such as federation (see Section 3.1.1) and operational governance structures (see Section 3.1.3).
インターネット機能で集中化が意図的に許可されている場合、プロトコル設計者は、連邦（セクション3.1.1を参照）や運用ガバナンス構造（セクション3.1.3を参照）などの技術的手段を使用して、関連するリスクを軽減しようとします。
Protocols that successfully do so are often reused to avoid the considerable cost and risk of reimplementing those mitigations. For example, if a protocol requires a coordinated global naming function, incorporating the Domain Name System is usually preferable to establishing a new system.
正常に行うプロトコルは、多くの場合、これらの緩和を再実装するかなりのコストとリスクを回避するために再利用されます。たとえば、プロトコルが調整されたグローバルネーミング関数を必要とする場合、通常、新しいシステムを確立するにはドメイン名システムを組み込むことが望ましいです。
This document has argued that, while standards bodies have little means of effectively controlling or preventing centralization of the Internet through protocol design, there are still concrete and useful steps they can take to improve the Internet.
この文書は、標準団体にはプロトコル設計を通じてインターネットの集中化を効果的に制御または防止する手段がほとんどないが、インターネットを改善するために取ることができる具体的で有用なステップがまだあると主張しています。
Those steps might be elaborated upon and extended in future work; however, it is doubtless there is more that can be done. New decentralization techniques might be identified and examined; what we learn from relationships with other, more effective regulators in this space can be documented.
これらの手順は、将来の仕事で詳述され、拡張される可能性があります。ただし、できることは間違いありません。新しい分散化手法が特定され、調査される場合があります。この分野の他のより効果的な規制当局との関係から学ぶことは、文書化できます。
Some have suggested creating a how-to guide or checklist for dealing with centralization. Because centralization is so contextual and so varied in how it manifests, this might best be attempted within very limited areas -- for example, for a particular type of function or a function at a particular layer.
集中化を扱うためのハウツーガイドまたはチェックリストを作成することを提案する人もいます。集中化は非常に文脈的であり、それがどのように現れるかは非常に多様であるため、これは非常に限られた領域で最もよく試みられるかもしれません。たとえば、特定のタイプの関数や特定のレイヤーの関数についてです。
The nature of centralization also deserves further study; in particular, its causes. While there is much commentary on factors like network effects and switching costs, other aspects -- such as behavioral, cognitive, social, and economic factors have received comparatively little attention, although that is changing (e.g., [Fletcher]).
集中化の性質もさらなる研究に値します。特に、その原因。ネットワーク効果や切り替えコストなどの要因については多くの解説がありますが、行動、認知、社会、経済の要因などの他の側面は比較的ほとんど注目されていませんが、それは変化していません（例：[フレッチャー]）。
This document does not have a direct security impact on Internet protocols. That said, failure to consider centralization might cause a myriad of security issues; see Section 2.1 for a preliminary discussion.
このドキュメントには、インターネットプロトコルに直接的なセキュリティの影響がありません。とはいえ、集中化を検討できないと、無数のセキュリティの問題が発生する可能性があります。予備的な議論については、セクション2.1を参照してください。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[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] Best Current Practice 95,
<https://www.rfc-editor.org/info/bcp95>.
At the time of writing, this BCP comprises the following:
Alvestrand, H., "A Mission Statement for the IETF",
BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004,
<https://www.rfc-editor.org/info/rfc3935>.
[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://doi.org/10.2307/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>.
This document was born out of early discussions with Brian Trammell during our shared time on the Internet Architecture Board.
この文書は、インターネットアーキテクチャボードでの共有時間中に、ブライアントラメルとの初期の議論から生まれました。
Special thanks to Geoff Huston and Milton Mueller for their well-considered, thoughtful, and helpful reviews.
Geoff HustonとMilton Muellerに、よく考えられていて、思慮深く、役立つレビューに感謝します。
Thanks to Jari Arkko, Kristin Berdan, Richard Clayton, Cory Doctorow, Christian Huitema, Eliot Lear, John Levine, Tommy Pauly, and Martin Thomson for their comments and suggestions. Likewise, the arch-discuss@ietf.org (mailto:arch-discuss@ietf.org) mailing list and Decentralized Internet Infrastructure Research Group provided valuable discussion and feedback.
Jari Arkko、Kristin Berdan、Richard Clayton、Cory Doctorow、Christian Huitema、Eliot Lear、John Levine、Tommy Pauly、Martin Thomsonのコメントと提案に感謝します。同様に、arch-discuss@ietf.org（mailto：arch-discuss@ietf.org）メーリングリストと分散型インターネットインフラストラクチャリサーチグループは、貴重な議論とフィードバックを提供しました。
No large language models were used in the production of this document.
このドキュメントの作成には、大きな言語モデルは使用されていません。
Mark Nottingham
Prahran
Australia
Email: mnot@mnot.net
URI: https://www.mnot.net/