< draft-nottingham-avoiding-internet-centralization-00.txt		draft-nottingham-avoiding-internet-centralization-01.txt >
	Network Working Group M. Nottingham		Network Working Group M. Nottingham
	Internet-Draft 8 December 2021		Internet-Draft 9 January 2022
	Intended status: Informational		Intended status: Informational
	Expires: 11 June 2022		Expires: 13 July 2022
	Avoiding Internet Centralization		Centralization and Internet Standards
	draft-nottingham-avoiding-internet-centralization-00		draft-nottingham-avoiding-internet-centralization-01
	Abstract		Abstract
	Avoiding centralization is an important goal for Internet protocols.		Despite being designed and operated as a decentralized network-of-
	This document offers a definition of centralization, discusses why it		networks, the Internet is continuously subjected to forces that
	is necessary for Internet protocol designers to consider its risks,		encourage centralization.
	identifies different kinds of centralization, catalogues some
	limitations of current approaches to controlling it, and recommends		This document offers a definition of centralization, explains why it
	best practices for protocol designers.		is undesirable, identifies different types of centralization,
			catalogues limitations of common approaches to controlling it, and
			explores what Internet standards efforts can do to address it.
	About This Document		About This Document
	This note is to be removed before publishing as an RFC.		This note is to be removed before publishing as an RFC.
	Status information for this document may be found at		Status information for this document may be found at
	https://datatracker.ietf.org/doc/draft-nottingham-avoiding-internet-		https://datatracker.ietf.org/doc/draft-nottingham-avoiding-internet-
	centralization/.		centralization/.
	Source for this draft and an issue tracker can be found at		Source for this draft and an issue tracker can be found at
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 48 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 11 June 2022.		This Internet-Draft will expire on 13 July 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4		2. What is Centralization . . . . . . . . . . . . . . . . . . . 3
	2. Why Avoid Centralization . . . . . . . . . . . . . . . . . . 4		3. Why Avoid Centralization . . . . . . . . . . . . . . . . . . 4
	3. Kinds of Centralization . . . . . . . . . . . . . . . . . . . 6		4. Kinds of Centralization . . . . . . . . . . . . . . . . . . . 6
	3.1. Direct Centralization . . . . . . . . . . . . . . . . . . 6		4.1. Direct Centralization . . . . . . . . . . . . . . . . . . 6
	3.2. Necessary Centralization . . . . . . . . . . . . . . . . 6		4.2. Necessary Centralization . . . . . . . . . . . . . . . . 6
	3.3. Indirect Centralization . . . . . . . . . . . . . . . . . 7		4.3. Indirect Centralization . . . . . . . . . . . . . . . . . 7
	3.4. Inherited Centralization . . . . . . . . . . . . . . . . 8		4.4. Inherited Centralization . . . . . . . . . . . . . . . . 8
	3.5. Platform Centralization . . . . . . . . . . . . . . . . . 8		4.5. Platform Centralization . . . . . . . . . . . . . . . . . 9
	4. The Limits of Decentralization . . . . . . . . . . . . . . . 9		5. The Limits of Decentralization . . . . . . . . . . . . . . . 9
	4.1. Federation isn't Enough . . . . . . . . . . . . . . . . . 9		5.1. Federation isn't Enough . . . . . . . . . . . . . . . . . 10
	4.2. Multi-Stakeholder Administration is Hard . . . . . . . . 10		5.2. Multi-Stakeholder Administration is Hard . . . . . . . . 11
	4.3. Blockchains Are Not Magical . . . . . . . . . . . . . . . 11		5.3. Blockchains Are Not Magical . . . . . . . . . . . . . . . 12
	5. Guidelines for Protocol Designers . . . . . . . . . . . . . . 13		6. What Should Internet Standards Do? . . . . . . . . . . . . . 13
	5.1. Allow Intermediation Sparingly . . . . . . . . . . . . . 13		6.1. Manage Centralization Risk Where Effective . . . . . . . 14
	5.2. Encrypt, Always . . . . . . . . . . . . . . . . . . . . . 14		6.2. Create Standards to Decentralize Proprietary Functions . 15
	5.3. Reuse Existing Tools . . . . . . . . . . . . . . . . . . 14		6.3. Limit Intermediary Power . . . . . . . . . . . . . . . . 15
	5.4. Accomodate Limited Domains Warily . . . . . . . . . . . . 15		6.4. Avoid Over-Extensibility . . . . . . . . . . . . . . . . 16
	5.5. Target Extensibility . . . . . . . . . . . . . . . . . . 15		7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	5.6. Acknowledge the Limits of Protocol Design . . . . . . . . 16		8. Informative References . . . . . . . . . . . . . . . . . . . 17
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 16		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
	7.1. Normative References . . . . . . . . . . . . . . . . . . 16
	7.2. Informative References . . . . . . . . . . . . . . . . . 16
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	The Internet is successful in no small part because of its purposeful		The Internet has succeeded in no small part because of its purposeful
	avoidance of any single controlling entity. While originally this		avoidance of any single controlling entity. While this approach may
	may have been due to a desire to prevent a single technical failure		reflect a desire to prevent a single technical failure from having
	from having wide impact, it has also enabled the rapid adoption and		wide impact,[RAND] it has also enabled the Internet's rapid adoption
	broad spread of the Internet, because internetworking does not		and broad spread, because internetworking did not require obtaining
	require obtaining permission from or ceding control to another entity		permission from or ceding control to another entity -- thereby
	-- thereby accommodating a spectrum of requirements and positioning		accommodating a spectrum of requirements and positioning the Internet
	the Internet as a public good.		as a public good.
	As a result, Internet protocols share a common design goal: avoiding
	centralization, which we define as the ability of a single person,
	company, or government -- or a small group of them -- to observe,
	control, or extract rent from the protocol's operation or use.
	At the same time, the utility of many Internet protocols is enabled		While avoiding centralization is a widely shared goal for the
	or significantly enhanced by ceding some aspect of communication		Internet, meeting that goal has proven difficult. Many successful
	between two parties to a third party -- often, in a manner that has		protocols and applications on the Internet today are designed or
	centralization risk. For example, there might be a need for a		operated in a centralized fashion -- to the point where some
	'single source of truth' or a rendezvous facility to allow endpoints		proprietary, centralized services have become so well-known that they
	to find each other. How should such protocols be designed?		are commonly mistaken for the Internet itself. Even when protocols
			incorporate techniques intended to prevent centralization, economic
			and social factors can drive users to prefer centralized solutions
			built with or on top of supposedly decentralized technology.
	Furthermore, many successful proprietary protocols and applications		These difficulties call into question what role architectural
	on the Internet are de facto centralized. Some have become so well-		regulation -- in particular, open standards bodies such as at the
	known that they are commonly mistaken for the Internet itself. In		IETF -- should be play in preventing, mitigating, and controlling
	other cases, Internet protocols seem to favour centralized		centralization of the Internet.
	deployments due to economic and social factors. Should standards
	efforts attempt to mitigate centralization in these cases, and if so,
	how?
	Finally, some autonomous networks have requirements to control the		This document discusses aspects of centralization that relate to
	operation of Internet protocols internally, and some users or groups		Internet standards efforts. Section 2 provides a definition of
	of users might cede control of some aspect of how they use the		centralization. Section 3 explains why centralization of Internet's
	Internet to a central authority, either voluntarily or under legal		functions is undesirable. Section 4 surveys the different kinds of
	compulsion. In both of these cases, should Internet protocols		centralization that might surface on the Internet. Section 5 then
	accommodate such requirements, and if so, how?		catalogues high-level approaches to mitigating centralization and
	This document discusses aspects of centralization with regard to		discusses their limitations. Finally, Section 6 considers the role
	Internet protocol design (note that 'protocol' is used somewhat		that Internet standards play in avoiding centralization and
	loosely here, to also encompass what could be considered an		mitigating its effects.
	application). Section 2 explains why it is necessary for Internet
	protocols to avoid centralization when possible. Section 3 surveys
	the different kinds of centralization that Internet protocols might
	be involved in. Section 4 then catalogues current high-level
	approaches to mitigating centralization and discusses their
	limitations. Finally, Section 5 discusses cross-cutting interactions
	between centralization and protocol design, recommending best
	practices where appropriate.
	Engineers who design and standardize Internet protocols are the		Engineers who design and standardize Internet protocols are the
	primary audience for this document. However, designers of		primary audience for this document. However, designers of
	proprietary protocols can benefit from considering aspects of		proprietary protocols can benefit from considering aspects of
	centralization, especially if they intend their protocol to be		centralization, especially if they intend their protocol to be
	considered for standardisation. Likewise, policymakers can use this		considered for eventual standardisation. Likewise, policymakers can
	document to help identify and remedy inappropriately centralized		use this document to help identify and remedy inappropriately
	protocols and applications.		centralized protocols and applications.
	1.1. Notational Conventions		2. What is Centralization
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		This document defines "centralization" as the ability of a single
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		entity (e.g., a person, company, or government) -- or a small group
	"OPTIONAL" in this document are to be interpreted as described in BCP		of them -- to observe, control, or extract rent from the operation or
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		use of a given function on the Internet.
	capitals, as shown here.
	2. Why Avoid Centralization		Here, "function" is defined broadly. It might be an enabling
			protocol already defined by standards, such as IP [RFC791], BGP
			[RFC4271], TCP [RFC793], or HTTP [HTTP]. It might also be a proposal
			for a new enabling protocol, or an extension to an existing one.
	Centralization is undesirable in the design of Internet protocols for		However, centralization is not limited to standards-defined
	many reasons -- in particular, because it is counter to the nature of		protocols. User-visible applications built on top of the functions
	the Internet, because it violates the purpose of the Internet from		provided by standards are also vulnerable to centralization -- for
	the perspective of its end users, and because of the many negative		example, social networking, file sharing, financial services, and
	effects it can have on the networks operation and evolution.		news dissemination. Likewise, the supply of hardware, operating
			systems, and software can exhibit centralization.
	By its very nature, the Internet must avoid centralization. As a		Centralization risk is strongest when it necessarily affects the
	'large, heterogeneous collection of interconnected systems' [BCP95]		entire Internet. However, it can also be present when a substantial
	the Internet is often characterised as a 'network of networks'. As		portion of the Internet's users lack options for a given function.
	such, these networks relate as peers who agree to facilitate		For example, if there is only one provider a function in a given
	communication, rather than having a relationship of subservience to		region or legal jurisdiction, that function is effectively
	others' requirements or coercion by them.		centralized for those users.
	However, many Internet protocols allow a third party to be interposed		"Decentralization" is the process of identifying centralization risk
	into communication between two other parties. In some cases, this is		in the functions of a protocol or application, followed by
	not intended by the protocol's designers; for example, intervening		application of appropriate techniques to prevent or mitigate
	networks have taken advantage of unencrypted deployment of HTTP		centralization.
	[HTTP] to interpose 'interception proxies' (also known as
	'transparent proxies') to cache, filter, track, or change traffic.
	In cases where interposition of a third party is a designed feature
	of the protocol, it is often characterised as _intermediation_, and
	is typically used to help provide the protocol's functions --
	sometimes including those that are necessary for it to operate.
	Whether or not interposition of a third party into communication is		Decentralization does not require that a given function need be so
	intentional, the 'informational and positional advantages'		widely distributed that other important factors, such as efficiency,
	[INTERMEDIARY-INFLUENCE] gained can be used to observe behavior (the		resiliency, latency, or availability are sacrificed. In some cases,
	'panopticon effect') and shape or even deny behaviour (the		a function that is only available through a relatively small number
	'chokepoint effect') -- which can be used those parties (or the		of providers can be effectively decentralized, given the appropriate
	states that have authority over them) for coercive ends.		circumstances (see, for example, the DNS).
	[WEAPONIZED-INTERDEPENDENCE]
	As Internet protocols' first duty is to the end user [RFC8890],		Therefore, discussions of centralization and architectural efforts at
			decentralization need to be made on a case-by-base basis, depending
			on the function in question, surrounding circumstances, and other
			regulatory mechanisms.
			Note that it is important to distinguish centralization from anti-
			competitive concerns (also known as "anti-trust"). While there are
			many interactions between them and making the Internet more
			competitive may be a motivation for avoiding centralization, only
			courts are authoritative in determining what is and is not anti-
			competitive in a given market, not standards bodies and other
			technical fora.
			3. Why Avoid Centralization
			Centralization is undesirable because it is counter to the nature of
			the Internet, because it violates the end users' expectations, and
			because of the many negative effects it can have on the networks
			operation and evolution.
			Firstly, the Internet's very nature is incompatible with
			centralization of its functions. As a 'large, heterogeneous
			collection of interconnected systems' [BCP95] the Internet is often
			characterised as a 'network of networks'. As such, these networks
			relate as peers who agree to facilitate communication, rather than
			having a relationship of subservience to others' requirements or
			coercion by them.
			Secondly, as the Internet's first duty is to the end user [RFC8890],
	allowing such power to be concentrated into few hands is counter to		allowing such power to be concentrated into few hands is counter to
	the IETF's mission of creating an Internet that 'will help us to		the IETF's mission of creating an Internet that 'will help us to
	build a better human society.' [BCP95]		build a better human society.' [BCP95] When a third party has
			unavoidable access to communications, the 'informational and
			positional advantages' [INTERMEDIARY-INFLUENCE] gained can be used to
			observe behavior (the 'panopticon effect') and shape or even deny
			behaviour (the 'chokepoint effect') -- which can be used by those
			parties (or the states that have authority over them) for coercive
			ends. [WEAPONIZED-INTERDEPENDENCE]
	Additionally, concentration of power has deleterious effects on the		Finally, concentration of power has deleterious effects on the
	Internet itself, including:		Internet itself, including:
	* _Limiting Innovation_: Centralization can preclude the possibility		* _Limiting Innovation_: Centralization can preclude the possibility
	of 'permissionless innovation' -- the ability to deploy new,		of 'permissionless innovation' -- the ability to deploy new,
	unforeseen applications without requiring coordination with		unforeseen applications without requiring coordination with
	parties other than those you are communicating with.		parties other than those you are communicating with.
	* _Constraining Competition_: The Internet and its users benefit		* _Constraining Competition_: The Internet and its users benefit
	from robust competition when applications and services are		from robust competition when applications and services are
	available from many different providers -- especially when those		available from many different providers -- especially when those
	skipping to change at page 5, line 49 ¶		skipping to change at page 5, line 50 ¶
	* _Reducing Availability_: The Internet's availability (as well as		* _Reducing Availability_: The Internet's availability (as well as
	applications and services built upon it) improves when there are		applications and services built upon it) improves when there are
	many ways to obtain access to it. While centralized services		many ways to obtain access to it. While centralized services
	typically benefit from the focused attention that their elevated		typically benefit from the focused attention that their elevated
	role requires, when they do fail the resulting loss of		role requires, when they do fail the resulting loss of
	availability can have disproportionate impact.		availability can have disproportionate impact.
	* _Creating Monoculture_: At the scale available to a centralized		* _Creating Monoculture_: At the scale available to a centralized
	service or application, minor flaws in features such as		service or application, minor flaws in features such as
	recommendation algorithms can be magnified to a degree that can		recommendation algorithms can be magnified to a degree that can
	have broad (even societal) consequences. Diversity in these		have broad (even societal) consequences. Diversity in the
	functions is significantly more robust, when viewed systemically.		implementation of these functions is significantly more robust,
	[POLYCENTRIC]		when viewed systemically. [POLYCENTRIC]
	* _Self-Reinforcement_: As widely noted (see, eg., [ACCESS]), a		* _Self-Reinforcement_: As widely noted (see, eg., [ACCESS]), a
	centralized service benefits from access to data which can be used		centralized service benefits from access to data which can be used
	to further improve its offerings, while denying such access to		to further improve its offerings, while denying such access to
	others.		others.
	To summarize, we avoid centralization because it would allow the		See also [TECH-SUCCESS-FACTORS].
	Internet (or some part of it) to be captured, effectively turning it
	into a 'walled garden' that fails to meet both architectural design
	goals and users' expectations, while endangering the viability of the
	Internet at the same time.
	3. Kinds of Centralization		To summarize, centralization would allow the Internet (or some part
			of it) to be captured, effectively turning it into a 'walled garden'
			that fails to meet both architectural design goals and users'
			expectations, and endangering its ongoing viability at the same time.
	Not all centralization of Internet protocols is equal; there are		4. Kinds of Centralization
	several different types, each with its own properties. The
	subsections below list some.
	3.1. Direct Centralization		Centralization of the Internet is not uniform; it presents in a
			variety of ways, depending on its relationship to the function in
			question and underlying causes. The subsections below offer the
			start of a classification system for Internet centralization.
	The most straightforward kind of centralized protocol creates a fixed		4.1. Direct Centralization
	role for a specific party.
	For example, most proprietary messaging, videoconferencing, chat, and		The most straightforward kind of centralization creates a fixed role
	simliar protocols operate in this fashion.		for a specific party. For example, most proprietary messaging,
			videoconferencing, chat, and similar protocols operate in this
			fashion.
	While it has been argued that such protocols are simpler to design,		While it has been argued that such protocols are simpler to design,
	more amenable to evolution, and more likely to meet user		more amenable to evolution, and more likely to meet user needs
	needs,[MOXIE] this approach most often reflects commercial goals --		[MOXIE], this approach most often reflects commercial goals -- in
	in particular, a strong desire to capture the financial benefits of		particular, a strong desire to capture the financial benefits of the
	the protocol by 'locking in' users to a proprietary service.		protocol by 'locking in' users to a proprietary service.
	Directly centralised protocols and applications are not considered to		Directly centralised protocols and applications are not considered to
	be part of the Internet per se; instead, they are more properly		be part of the Internet per se; instead, they are more properly
	characterized as proprietary protocols that are built on top of the		characterized as proprietary protocols that are built on top of the
	Internet. As such, they are not regulated by the Internet		Internet. As such, they are not regulated by the Internet
	architecture or standards, beyond the constraints that the underlying		architecture or standards, beyond the constraints that the underlying
	protocols (e.g., TCP, IP, HTTP) impose.		protocols (e.g., TCP, IP, HTTP) impose.
	3.2. Necessary Centralization		4.2. Necessary Centralization
	Some protocols require the introduction of centralization risk that		Some protocols require the introduction of centralization risk that
	is unavoidable by nature.		is unavoidable by nature.
	For example, when there is a need a single, globally coordinated		For example, when there is a need a single, globally coordinated
	'source of truth', that facility is by nature centralized. The most		'source of truth', that function is by nature centralized. The most
	obvious instance is seen in the Domain Name System (DNS), which		obvious instance is seen in the Domain Name System (DNS), which
	allows human-friendly naming to be converted into network addresses		allows human-friendly naming to be converted into network addresses
	in a globally consistent fashion.		in a globally consistent fashion.
	Allocation of IP addresses is another example of a necessary facility		Allocation of IP addresses is another example of a necessary function
	being a centralization risk. Internet routing requires addresses to		being a centralization risk. Internet routing requires addresses to
	be allocated uniquely, but if the addressing function were captured		be allocated uniquely, but if the addressing function were captured
	by a single government or company, the entire Internet would be at		by a single government or company, the entire Internet would be at
	risk of abuse by that entity.		risk of abuse by that entity.
	Similarly, the need for coordination in the Web's trust model brings		Similarly, the need for coordination in the Web's trust model brings
	centralization risk, because a Certificate Authority (CA) can control		centralization risk, because a Certificate Authority (CA) can control
	communication between the Web sites that they sign certificates for		communication between the Web sites that they sign certificates for
	and users whose browsers trust the CA's root certificates.		and users whose browsers trust the CA's root certificates.
	Protocols that need to solve the 'rendezvous problem' to coordinate		Protocols that need to solve the "rendezvous problem" to coordinate
	communication between two parties that are not in direct contact also		communication between two parties that are not in direct contact also
	suffer from this kind of centralization risk. For example, chat		suffer from this kind of centralization risk. For example, chat
	protocols need a way to coordinate communication between two parties		protocols need a way to coordinate communication between two parties
	that wish to talk; while the actual communication can be direct		that wish to talk; while the actual communication can be direct
	between them (so long as the protocol facilitates that), the		between them (so long as the protocol facilitates that), the
	endpoints' mutual discovery typically requires a third party.		endpoints' mutual discovery typically requires a third party.
	Internet protocols currently tend to mitigate necessary		Internet protocols often attempt to mitigate necessary centralization
	centralization using measures such as mandated federation Section 4.1		risk using measures such as mandated federation Section 5.1 and
	and multi-stakeholder administration Section 4.2.		multi-stakeholder administration Section 5.2.
	3.3. Indirect Centralization		Because of the inherent risks and costs of these approaches,
			functions that successfully use these techniques are often reused by
			others with similar requirements. For example, if a protocol
			requires a coordinated, global naming function, reusing the Domain
			Name System is usually preferable to establishing a new system,
			because its centralization risk is known and understood, and the
			risks inherent in establishing new mitigations are avoided.
			4.3. Indirect Centralization
	Even when a protocol avoids direct centralization and does not		Even when a protocol avoids direct centralization and does not
	exhibit any necessary centralization, it might become centralized in		exhibit any necessary centralization, it might become centralized in
	practice when external factors influence its deployment.		practice when external factors influence its deployment. Indirect
			centralization can be caused by factors that encourage use of a
	Indirect centralization can be caused by factors that encourage use		central function despite the absence of such a requirement in the
	of a central facility despite the absence of such a requirement in		protocol itself. Such factors might be economic, social, or legal.
	the protocol itself. Such factors might be economic, social, or
	legal.
	For example, cloud computing is used to deploy many Internet
	protocols. Although the base concepts and control protocols for it
	avoid centralization in the sense that there is no need for a single,
	central cloud provider, the economics of providing compute at scale
	as well as some social factors regarding developer familiarity and
	comfort encourage convergence on a small number of cloud providers.
	Often, the factors driving indirect centralization are related to the		Often, the factors driving indirect centralization are related to the
	network effects that are so often seen on the Internet. While in		network effects that are so often seen on the Internet. While in
	theory every node on the Internet is equal, in practice some nodes		theory every node on the Internet is equal, in practice some nodes
	are much more connected than others: for example, just a few sites		are much more connected than others: for example, just a few sites
	drive much of the traffic on the Web. While expected and observed in		drive much of the traffic on the Web. While expected and observed in
	many kinds of networks [SCALE-FREE], network effects award asymmetric		many kinds of networks [SCALE-FREE], network effects award asymmetric
	power to nodes that act as intermediaries to communication.		power to nodes that act as intermediaries to communication.
	Left unchecked, these factors can cause a potentially decentralized		Left unchecked, these factors can cause a potentially decentralized
	application to become directly centralised, because the central		application to become directly centralised, because the central
	facility has leverage to 'lock in' users. For example, social		function has leverage to "lock in" users. For example, social
	networking is an application that is currently supplied by a small		networking is an application that is currently supplied by a small
	number of directly centralized, proprietary platforms despite		number of directly centralized, proprietary platforms despite
	standardization efforts (see, e.g.,		standardization efforts (see, e.g.,
	[W3C.CR-activitystreams-core-20161215]), due to the powerful network		[W3C.CR-activitystreams-core-20161215]), due to the powerful network
	effects associated.		effects associated.
	By its nature, indirect centralization is difficult to avoid in		By its nature, indirect centralization is difficult to avoid in
	protocol design, and federated protocols are particularly vulnerable		protocol design, and federated protocols are particularly vulnerable
	to it (see Section 4.1).		to it (see Section 5.1).
	3.4. Inherited Centralization		4.4. Inherited Centralization
	Most Internet protocols depend on other, 'lower-layer' protocols.		Most Internet protocols depend on other, "lower-layer" protocols.
	The features, deployment, and operation of these dependencies can		The features, deployment, and operation of these dependencies can
	surface centralization risk into protocols operating 'on top' of		surface centralization risk into functions and applications build "on
	them.		top" of them.
	For example, the network between endpoints can introduce		For example, the network between endpoints can introduce
	centralization risk to application-layer protocols, because it is		centralization risk to application-layer protocols, because it is
	necessary for communication and therefore has power over it. A given		necessary for communication and therefore has power over it. A given
	network might block access to, slow down, or modify the content of		network might block access to, slow down, or modify the content of
	various application protocols or specific services for financial,		various application protocols or specific services for financial,
	political, operational, or criminal reasons, thereby creating		political, operational, or criminal reasons, thereby creating
	pressure to use other services, which can in turn result in		pressure to use other services, which can in turn result in
	centralization.		centralization of them.
	Inherited centralization risk is only present when users cannot use		Inherited centralization risk is only present when users cannot use
	an alternative means of accessing the desired service. For example,		an alternative means of accessing the desired service. For example,
	users often have flexibility in choice of Internet access, so they		users often have flexibility in choice of Internet access, so they
	could just 'route around' a network that impacts their chosen		could just "route around" a network that impacts their chosen
	service. However, such choices are often not available in the		service. However, such choices are often not available in the
	moment, and the Internet's topology means that a 'choke point'		moment, and the Internet's topology means that a choke point upstream
	upstream could still affect their Internet access.		could still affect their Internet access.
	Usually, inherited centralization -- both existing and anticipated --		When deployed at scale, encryption can be an effective technique to
	is a factor to work around in protocol design, just as any other		control many inherited centralization risks. By reducing the number
	constraint would be. One effective tool for doing so is encryption,		of parties who have access to content of communication, the ability
	discussed further in Section 5.2.		of lower-layer protocols and intermediaries at those layers to
			interfere with or observe is precluded. Even when they can still
			prevent communication, the use of encryption makes it more difficult
			to discriminate the target from other traffic.
	3.5. Platform Centralization		Note that the prohibitive effect on inherited centralization is most
			pronounced when most (if not all) traffic is encrypted -- providing
			yet more motivation for that goal (see also [RFC7258]).
			4.5. Platform Centralization
	The complement to inherited centralization is platform centralization		The complement to inherited centralization is platform centralization
	-- where a protocol does not directly define a central role, but		-- where a function does not directly define a central role, but
	could facilitate centralization in the applications it supports.		could facilitate centralization in the applications it supports.
	For example, HTTP [HTTP] in itself is not considered a centralized		For example, HTTP [HTTP] in itself is not considered a centralized
	protocol; interoperable servers are relatively easy to instantiate,		protocol; interoperable servers are relatively easy to instantiate,
	and multiple clients are available. It can be used without central		and multiple clients are available. It can be used without central
	coordination beyond that provided by DNS, as discussed above.		coordination beyond that provided by DNS, as discussed above.
	However, applications built on top of HTTP (as well as the rest of		However, applications built on top of HTTP (as well as the rest of
	the 'Web Platform') often exhibit centralization. As such, HTTP is		the 'Web Platform') often exhibit centralization. As such, HTTP is
	an example of a platform for centralization -- while the protocol		an example of a platform for centralization -- while the protocol
	skipping to change at page 9, line 24 ¶		skipping to change at page 9, line 38 ¶
	centralized services and applications.		centralized services and applications.
	Like indirect centralization, platform centralization is difficult to		Like indirect centralization, platform centralization is difficult to
	completely avoid in protocol design. Because of the layered nature		completely avoid in protocol design. Because of the layered nature
	of the Internet, most protocols are designed to allow considerable		of the Internet, most protocols are designed to allow considerable
	flexibility in how they are used, often in a way that it becomes		flexibility in how they are used, often in a way that it becomes
	attractive to form a dependency on one party's operation. Notably,		attractive to form a dependency on one party's operation. Notably,
	this can happen even if the protocol does not accommodate		this can happen even if the protocol does not accommodate
	intermediation explicitly.		intermediation explicitly.
	4. The Limits of Decentralization		5. The Limits of Decentralization
	4.1. Federation isn't Enough		Over time, various techniques have been developed to decentralize
			protocols and applications. While these approaches can be used to
			create a function which is less centralized or less amenable to some
			kinds of centralization, they are not adequate to completely avoid
			centralization on their own. As such, while the use of these
			techniques is often appropriate and sometimes effective, they are not
			indicators of whether a protocol is centralized without further
			analysis.
	A widely known technique for avoiding centralization in Internet		5.1. Federation isn't Enough
	protocols is federation - that is, designing them in such a way that
			A widely known technique for managing centralization in Internet
			protocols is federation -- that is, designing them in such a way that
	new instances of any intermediary or otherwise centralized function		new instances of any intermediary or otherwise centralized function
	are relatively easy to create, and they are able to maintain		are relatively easy to create, and they are able to maintain
	interoperability and connectivity with other instances.		interoperability and connectivity with other instances.
	For example, SMTP [RFC5321] is the basis of the e-mail suite of		For example, SMTP [RFC5321] is the basis of the e-mail suite of
	protocols, which has two functions that are necessarily centralized:		protocols, which has two functions that are necessarily centralized:
	1. Giving each user a globally unique address, and		1. Giving each user a globally unique address, and
	2. Routing messages to the user, even when they change network		2. Routing messages to the user, even when they change network
	locations or are disconnected for long periods of time.		locations or are disconnected for long periods of time.
	E-mail reuses DNS to mitigating first risk (see Section 5.3). To		E-mail reuses DNS to help mitigate the first risk. To mitigate the
	mitigate the second, it defines an intermediary role for routing		second, it defines an intermediary role for routing users' messages,
	users' messages, the Message Transfer Agent (MTA). By allowing		the Message Transfer Agent (MTA). By allowing anyone to deploy a MTA
	anyone to deploy a MTA and defining rules for interconnecting them,		and defining rules for interconnecting them, the protocol's users
	the protocol's users avoid the need for a single, central router.		avoid a requirement for a single, central router.
	Users can (and often do) choose to delegate that role to someone		Users can (and often do) choose to delegate that role to someone
	else, or run their own MTA. However, running your own mail server		else, or run their own MTA. However, running your own mail server
	has become difficult, due to the likelihood of a small MTA being		has become difficult, due to the likelihood of a small MTA being
	classified as a spam source. Because large MTA operaters are widely		classified as a spam source. Because large MTA operaters are widely
	known and have greater impact if their operation is affected, they		known and have greater impact if their operation is affected, they
	are less likely to be classified as such, thereby indirectly		are less likely to be classified as such, thereby indirectly
	centralizing the protocol's operation (see Section 3.3).		centralizing the protocol's operation (see Section 4.3).
	This illustrates that while federation can be effective at avoiding
	direct centralization and managing necessary centralization,
	federated protocols are still vulnerable to indirect centralization,
	and may exhibit platform centralization.
	Another example of a federated Internet protocol is XMPP [RFC6120],		Another example of a federated Internet protocol is XMPP [RFC6120],
	supporting 'instant messaging' and similar functionality. Like		supporting "instant messaging" and similar functionality. Like
	e-mail, it reuses DNS for naming and requires federation to		e-mail, it reuses DNS for naming and requires federation to
	facilitate rendezvous of users from different systems.		facilitate rendezvous of users from different systems.
	While some deployments of XMPP do support truly federated messaging		While some deployments of XMPP do support truly federated messaging
	(i.e., a person using service A can interoperably chat with someone		(i.e., a person using service A can interoperably chat with someone
	using service B), many of the largest do not. Because federation is		using service B), many of the largest do not. Because federation is
	voluntary, some operators made a decision to capture their users into		voluntary, some operators made a decision to capture their users into
	a single service, rather than provide the benefits of global		a single service, rather than provide the benefits of global
	interoperability.		interoperability.
	The examples above show that federation can be a useful technique to		The examples above illustrate that federation can be a useful
	avoid direct centralization, but on its own is not sufficient to		technique to avoid direct centralization and manage necessary
	avoid indirect centralization. If the value provided by a protocol		centralization, but on its own is not sufficient to avoid indirect
	can be captured by a single entity, they may use the protocol as a		and platform centralization. If the value provided by a protocol can
			be captured by a single entity, they may use the protocol as a
	platform to obtain a 'winner take all' outcome -- a significant risk		platform to obtain a 'winner take all' outcome -- a significant risk
	with many Internet protocols, since network effects often promote		with many Internet protocols, since network effects often promote
	such outcomes. Likewise, external factors (such as spam control)		such outcomes. Likewise, external factors (such as spam control)
	might naturally 'tilt the table' towards a few operators of these		might naturally 'tilt the table' towards a few operators of these
	protocols.		protocols.
	4.2. Multi-Stakeholder Administration is Hard		5.2. Multi-Stakeholder Administration is Hard
	Delegating the administration of a necessarily centralized function		Delegating the administration of a necessarily centralized function
	(see Section 3.2) to a multi-stakeholder body is an onerous but		(see Section 4.2) to a multi-stakeholder body is occasionally used to
	sometimes necessary way to mitigate the undesirable effects.		mitigate its effects.
	A multi-stakeholder body is an institution that includes		A multi-stakeholder body is an institution that includes
	representatives of the different kinds of parties that are affected		representatives of the different kinds of parties that are affected
	by the system's operation ('stakeholders') in an attempt to make		by the system's operation ("stakeholders") in an attempt to make
	well-reasoned, broadly agreed-to, and authoritative decisions.		well-reasoned, broadly agreed-to, and authoritative decisions.
	The most relevant example of this technique is the administration of		The most relevant example of this technique is the administration of
	the Domain Name System [RFC1035], which as a 'single source of truth'		the Domain Name System [RFC1035], which as a "single source of truth"
	requires centralization of the naming function. To mitigate		exhibits necessary centralization of the naming function, as well as
	centralization, this task is carried out by multiple root servers		the operation of the system. To mitigate operational centralization,
	that are administered by separate operators -- themselves diverse in		this task is carried out by multiple root servers that are
	geography and a selection of corporate entities, non-profits and		administered by separate operators -- themselves diverse in geography
	government bodies from many jurisdictions and affiliations.		and a selection of corporate entities, non-profits and government
	Furthermore, those operators are regulated by ICANN		bodies from many jurisdictions and affiliations. Furthermore, the
			name space itself is regulated by ICANN
	(https://www.icann.org/resources/pages/governance/governance-en),		(https://www.icann.org/resources/pages/governance/governance-en),
	which is defined as a globally multi-stakeholder body with		which is defined as a globally multi-stakeholder body with
	representation from a end users, governments, operators, and others.		representation from end users, governments, operators, and others.
	Another example of multi-stakeholderism is the standardization of		Another example of multi-stakeholderism is the standardization of
	Internet protocols themselves. Because a specification effectively		Internet protocols themselves. Because a specification effectively
	controls the behavior of implementations that are conformant with it,		controls the behavior of implementations that are conformant with it,
	the standardization process can be seen as a single point of control.		the standardization process can be seen as a single point of control.
	As a result, Internet standards bodies like the IETF allow open		As a result, Internet standards bodies like the IETF allow open
	participation and contribution, make decisions in an open and		participation and contribution, make decisions in an open and
	accountable way, have a well-defined process for making (and when		accountable way, have a well-defined process for making (and when
	necessary, appealing) decisions, and take into account the views of		necessary, appealing) decisions, taking into account the views of
	different stakeholder groups [RFC8890].		different stakeholder groups [RFC8890].
	Yet another example is the administration of the Web's trust model,		Yet another example is the administration of the Web's trust model,
	implemented by Web browsers as relying parties and Certificate		implemented by Web browsers as relying parties and Certificate
	Authorities as trust anchors. To assure that all parties meet the		Authorities as trust anchors. To assure that all parties meet the
	operational and security requirements necessary to provide the		operational and security requirements necessary to provide the
	desired properties, the CA/Browser Forum (https://cabforum.org) was		desired properties, the CA/Browser Forum (https://cabforum.org) was
	established as an oversight body that involves both of those parties		established as an oversight body that involves both of those parties
	as stakeholders.		as stakeholders.
	In each of these examples, setup and ongoing operation of a multi-		In each of these examples, setup and ongoing operation of a multi-
	stakeholder organization is not trivial. This is the major downside		stakeholder organization is not trivial. This is a major downside of
	of such an approach. Additionally, the legitimacy of such an		this approach. Additionally, the legitimacy of such an organization
	organization cannot be assumed, and may be difficult to establish and		cannot be assumed, and may be difficult to establish and maintain
	maintain (see, eg, [LEGITIMACY-MULTI]). This concern is especially		(see, eg, [LEGITIMACY-MULTI]). This concern is especially relevant
	relevant if the function being coordinated is broad, complex, and/or		if the function being coordinated is broad, complex, and/or
	contentious.		contentious.
	4.3. Blockchains Are Not Magical		5.3. Blockchains Are Not Magical
	Increasingly, distributed consensus technologies such as the		Increasingly, distributed consensus technologies such as the
	blockchain are touted as a solution to centralization issues. A		blockchain are touted as a solution to centralization issues. A
	complete survey of this rapidly-changing area is beyond the scope of		complete survey of this rapidly-changing area is beyond the scope of
	this document, but at a high level, we can generalise about their		this document, but at a high level, we can generalise about their
	properties.		properties.
	These techniques avoid centralization risk by distributing		These techniques attempt to avoid centralization risk by distributing
	intermediary or otherwise potentially centralized functions to		intermediary or otherwise potentially centralized functions to
	members of a large pool of protocol participants. Verification of		members of a large pool of protocol participants. Verification of
	proper performance of a function is typically guaranteed using		proper performance of a function is typically guaranteed using
	cryptographic techniques (often, an append-only transaction ledger).		cryptographic techniques (often, an append-only transaction ledger).
	The assignment of a particular task to a node for handling usually		The assignment of a particular task to a node for handling usually
	cannot be predicted or controlled. To assure diversity in the pool		cannot be predicted or controlled.
	of participants (thereby preventing Sybil attacks), techniques such
	as proof-of-work (where each participant has to demonstrate
	significant consumption of resources) or proof-of-stake (where each
	participant has some other incentive to execute correctly) are used.
	As such, these techniques purposefully disallow direct centralization		Sybil attacks (where enough participants coordinate their activity to
	and are robust against inherited centralization. Depending upon the		affect the protocol's operation) are a major concern for these
	application in question, indirect and platform centralization may		protocols. Diversity in the pool of participants is encouraged using
	still be possible, but in general these techniques do not lend		indirect techniques such as proof-of-work (where each participant has
	themselves to these ends as readily as federated systems do.		to demonstrate significant consumption of resources) or proof-of-
			stake (where each participant has some other incentive to execute
			correctly).
	However, distributed consensus technologies have several potential		Appropriate use of these techniques can create barriers to direct and
	shortcomings that may make them inappropriate -- or at least		inherited centralization. However, depending upon the application in
	difficult to use -- for many Internet applications, because their use		question, indirect and platform centralization can still be possible.
	conflicts with other important goals:
			Furthermore, distributed consensus technologies have several
			potential shortcomings that may make them inappropriate -- or at
			least difficult to use -- for many Internet applications, because
			their use conflicts with other important goals:
	1. Distributed consensus protocols can have significant implications		1. Distributed consensus protocols can have significant implications
	for privacy. Because activity (such as queries or transactions)		for privacy. Because activity (such as queries or transactions)
	are shared with many unknown parties, they have very different		are shared with many unknown parties, they have very different
	privacy properties than traditional client/server protocols.		privacy properties than traditional client/server protocols.
	Mitigations (e.g., Private Information Retrieval; see, eg, [PIR])		Mitigations (e.g., Private Information Retrieval; see, eg, [PIR])
	are still not suitable for broad deployment.		are still not suitable for broad deployment.
	2. Their complexity and 'chattiness' typically results in		2. Their complexity and "chattiness" typically result in
	significantly less efficient use of the network. When		significantly less efficient use of the network (often, to
	distributed consensus protocols use proof-of-work, energy		several orders of magnitude). When distributed consensus
	consumption can become significant (to the point where some		protocols use proof-of-work, energy consumption can become
	jurisdictions have banned its use).		significant (to the point where some jurisdictions have banned
			its use).
	3. Distributed consensus protocols are still not proven to scale to		3. Distributed consensus protocols are still not proven to scale to
	the degree expected of successful Internet protocols. In		the degree expected of successful Internet protocols. In
	particular, relying on unknown third parties to deliver		particular, relying on unknown third parties to deliver
	functionality can introduce variability in latency, availability,		functionality can introduce variability in latency, availability,
	and throughput. This is a marked change for applications with		and throughput. This is a marked change for applications with
	high expectations for these properties (e.g., commercial Web		high expectations for these properties (e.g., commercial Web
	services).		services).
	4. By design, distributed consensus protocols diffuse responsibility		4. By design, distributed consensus protocols diffuse responsibility
	for a function among several, difficult-to-identify parties.		for a function among several, difficult-to-identify parties.
	While this may be an effective way to prevent many kinds of		While this may be an effective way to prevent some kinds of
	centralization, it also means that making someone accountable for		centralization, it also means that making someone accountable for
	how the function is performed is impossible, beyond the bounds of		how the function is performed is impossible, beyond the bounds of
	the protocol's design.		the protocol's design.
	It is also important to recognise that a protocol can use distributed		It is also important to recognise that a protocol or an application
	consensus for some functions, but still have centralization risk		can use distributed consensus for some functions, but still have
	elsewhere. Even when distributed consensus is used exclusively		centralization risk elsewhere. Even when distributed consensus is
	(which is uncommon, due to the associated costs), some degree of		used exclusively (which is uncommon, due to the associated costs),
	coordination is still necessary -- whether that be through governance		some degree of coordination is still necessary -- whether that be
	of the function itself, creation of shared implementations, or		through governance of the function itself, creation of shared
	documentation of shared wire protocols. That represents		implementations, or documentation of shared wire protocols. That
	centralization risk, just at a different layer (inherited or		represents centralization risk, just at a different layer (inherited
	platform, depending on the circumstances).		or platform, depending on the circumstances).
	These potential shortcomings do not rule out the use of distributed		These potential shortcomings do not rule out the use of distributed
	consensus technologies for every use case. They do, however, caution		consensus technologies for every use case. They do, however, caution
	against relying upon these technologies uncritically.		against relying upon these technologies to avoid centralization
			uncritically.
	5. Guidelines for Protocol Designers		6. What Should Internet Standards Do?
	While the following recommendations are not a complete guide, they		Centralization is driven by powerful forces -- both economic and
	can be a starting point for avoiding or mitigating centralization in		social -- as well as the network effects that come with Internet
	Internet protocols.		scale. Moreover, because permissionless innovation is a core value
			for the Internet, and yet much of the centralization seen on the
			Internet is performed by proprietary platforms that take advantage of
			this nature, the controls available to standards efforts on their own
			are very limited.
	5.1. Allow Intermediation Sparingly		Nevertheless, while standards bodies on their own cannot prevent
			centralization, there are meaningful steps that can be taken to
			prevent some functions from exhibiting some forms of centralization.
			There are also valuable contributions that standards efforts can make
			to other relevant forms of regulation.
	The introduction of an intermediary role -- i.e., one that performs a		6.1. Manage Centralization Risk Where Effective
	function but is not a first party to communication -- adds
	centralization risk to Internet protocols, because it brings
	opportunities for control and observation. Even when the protocol is
	federated (see Section 4.1) to avoid direct centralization,
	significant indirect centralization risks exist when intermediation
	is allowed.
	However, intermediation can sometimes add significant value to a		Some types of centralization risk are relatively easy to manage in
	protocol, or enable what is considered a necessary function. In such		standards efforts. A directly centralized protocol, were it to be
	cases, the centralized function SHOULD be as minimal as possible, and		proposed, would be rejected out of hand by the IETF. There is a
	expose only the information and pontential for control necessary for		growning body of knowledge and experience with necessary
	that function to be performed. Protocol designers SHOULD consider		centralization, and a strong inclination to reuse existing
	the likely deployment patterns for those intermediaries and how		infrastructure where possible. As discussed above, encryption is
	network effects and other factors will influence them.		often a way to manage inherited centralization. All of these
			responses are appropriate ways for Internet standards to manage
			centralization risk.
	Such predictions can be difficult. For example, an intermediary		However, precluding indirect and platform centralization are much
	interposed by the end user of a protocol might allow them to delegate		more difficult in standards efforts. Because we have no "protocol
	functions to a party they trust, thereby empowering them. However,		police", it's not possible to demand that someone stop building a
	if an intervening network is able to force users to delegate to a		proprietary service using a purportedly federated protocol. We also
	particular intermediary, inherited centralization could result.		cannot stop someone from building centralized services "on top" of
			standard protocols without violating architectural goals like
			permissionless innovation.
	When carefully considered, intermediation can be a powerful way to		Therefore, committing significant resources to scrutinizing protocols
	enforce functional boundaries -- for example, to reduce the need for		for hidden or latent centralization risk -- especially for indirect
	users to trust potentially malicious endpoints, as seen in the so-		and platform risks -- is unlikely to actually prevent Internet
	called 'oblivious' protocols currently in development (e.g.,		centralization. Almost all existing Internet protocols -- including
	[I-D.pauly-dprive-oblivious-doh]) that allow end users to hide their		IP, TCP, HTTP, and DNS -- suffer some form of indirect or platform
	identity from services, while still accessing them.		centralization. Refusing to standardize a newer protocol because it
			faces similar risks would not be equitable, proportionate, or
			effective.
	The same advice applies in these cases; the observation and control		Centralization risk is sometimes perceived to be in tension with
	potential SHOULD be as minimal as possible, while still meeting the		other goals, such as privacy. While there is rarely a pure tradeoff
	design goals of the protocol.		between two abstract goals such as these, when it does occur
			attention should be paid to how effective architectural regulation
			(such as a standards effort) is in achieving each goal. In this
			example, a technical mechanism might be much more effective at
			improving privacy, whereas centralization might be better controlled
			by other regulators -- leading to the conclusion that the standards
			effort should focus on privacy.
	See [I-D.thomson-tmi] for more guidance.		6.2. Create Standards to Decentralize Proprietary Functions
	5.2. Encrypt, Always		Standards efforts should focus on creating new specifications for
			functions that are currently only satisfied by proprietary,
			centralized protocols. For example, if social networking is thought
			to be a centralized function, this might mean creating specifications
			that enable decentralized social networking, perhaps using some or
			all of the techniques described in Section 5.
	When deployed at scale, encryption can be an effective technique to		Keen readers will point out that social networking is effectively
	reduce many inherited centralization risks. By reducing the number		centralized despite the existence of such standards (see, e.g.,
	of parties who have access to content of communication, the ability		[W3C.CR-activitystreams-core-20161215]), because the IETF and W3C
	of lower-layer protocols and intermediaries at those layers to		create voluntary standards, not mandatory regulations.
	interfere with or observe is precluded. Even when they can still
	prevent communication, the use of encryption makes it more difficult
	to discriminate the target from other traffic.
	Note that the benefits are most pronounced when the majority (if not		However, architecture is not the only form of regulation; legal
	all) traffic is encrypted. As a result, protocols SHOULD be		mechanisms combined with changing norms and the resulting market
	encrypted by default.		forces have their own regulatory effects [NEW-CHICAGO]. While for
			much of its lifetime the Internet has only been subject to limited
			legal regulation, that period appears to be ending.
	See also [RFC7258].		It is far from certain that a legal mandate for interoperability
			based upon Internet standards will eventuate, but it is increasingly
			discussed as a remedy for competition issues (see, e.g., [OECD]). It
			is also not certain that legally-mandated standards will fully
			address centralization risks. However, if such specifications are
			not available from the Internet community, they may be created
			elsewhere without reference to the Internet's architectural goals.
	5.3. Reuse Existing Tools		Even absent a legal mandate, changes in norms and the market -- due
			to increasing knowledge and distrust of centralized functions -- can
			create demand for such specifications and the corresponding
			implementations.
	When a protocol function has necessary centralization risk and there		6.3. Limit Intermediary Power
	exists an already-deployed solution with appropriate mitigations,
	that solution should be reused in favour of inventing a new one.
	For example, if a protocol requires a coordinated, global naming		The introduction of an intermediary role -- i.e., one that performs a
	function, reusing the Domain Name System is preferable to		function but is not a first party to communication -- adds indirect
	establishing a new system, because its centralization risk is known		and platform centralization risk to Internet protocols, because it
	and understood (see Section 4.2).		brings opportunities for control and observation. At the same time,
			intermediation often adds significant value to a protocol, or enables
			what is considered a necessary function.
	5.4. Accomodate Limited Domains Warily		While (as discussed above) standards efforts have a very limited
			capability to prevent or control indirect and platform
			centralization, constraints on intermediary functions -- when
			designed explicitly into a protocol -- and prevent at least the most
			egregious outcomes. In general, this can be achieved by limiting the
			nature of the intermediary role to the most minimal function
			possible.
	[RFC8799] explores a class of protocols that operate in 'limited		For example, HTTP allows intermediaries to see the full content of
	domains' -- that is, they are not intended to be 'full' Internet		traffic by default, even when they are only performing basic
	protocols with broad applicability, but instead operation within a		functions such as routing. However, with the introduction of HTTPS
	particular network or other constrained environment.		and the CONNECT method (see Section 9.3.6 of [HTTP]), combined with
			market forces to adopt HTTPS, those intermediaries now only have
			access to the appropriate routing information.
	Often, limited-domain protocols address network requirements -- for		When carefully considered, intermediation can be a powerful way to
	example, imposing security policy, integrating services or		enforce functional boundaries -- for example, to reduce the need for
	application functions into the network, or differentiating different		users to trust potentially malicious endpoints, as seen in the so-
	classes of network services.		called 'oblivious' protocols currently in development (e.g.,
			[I-D.pauly-dprive-oblivious-doh]) that allow end users to hide their
			identity from services, while still accessing them.
	Such network-centric requirements can introduce the risk of inherited		The same advice applies in these cases; the observation and control
	centralization when they allow the network to interpose itself and		potential SHOULD be as minimal as possible, while still meeting the
	its requirements between the endpoints of a given communication.		design goals of the protocol.
	These risks can be partially mitigated by requiring such functions to		See [I-D.thomson-tmi] for more guidance.
	be opted into by one or both endpoints (once both the network and the
	endpoint are authenticated to each other), so that the network is
	acting on their behalf. However, this approach is still vulnerable
	to indirect centralization, because the endpoints may be pressured to
	acquiesce to a network's demands.
	5.5. Target Extensibility		Another kind of intermediation is created when a new feature or
			service is built using a standard as a substrate. For example, many
			Web sites offer new functions like social networking and aggregated
			news updates that can be viewed as a proprietary intermediary
			function on the Internet. These intermediaries may not be a format
			part of the underlying protocol (in the case of Web sites, HTTP), but
			they can still interpose a third party into communication. This kind
			of intermediation is more effectively dealt with by standardising the
			function, rather than restricting the capability of the protocol; see
			Section 6.2.
			6.4. Avoid Over-Extensibility
	An important feature of Internet protocols is their ability to evolve		An important feature of Internet protocols is their ability to evolve
	over time, so that they can meet new requirements and adapt to new		over time, so that they can meet new requirements and adapt to new
	conditions without requiring a 'flag day' to convert users.		conditions without requiring a "flag day" to upgrade implementations.
	Typically, protocol evolution is accommodated through extension		Typically, protocol evolution is accommodated through extension
	mechanisms, where optional features can be added over time in an		mechanisms, where optional features can be added over time in an
	interoperable fashion.		interoperable fashion.
	Protocol extensions can bring risk of platform centralization if a		However, protocol extensions can also increase the risk of platform
	powerful entity can change the target for meaningful interoperability		centralization if a powerful entity can change the target for
	by adding proprietary extensions to a standard protocol. This is		meaningful interoperability by adding proprietary extensions to a
	especially true when the core standard does not itself provide		standard protocol. This is especially true when the core standard
	sufficient utility to be appealing on its own.		does not itself provide sufficient utility on its own.
	For example, the SOAP protocol [SOAP] was an extremely flexible		For example, the SOAP protocol [SOAP] was an extremely flexible
	framework, allowing vendors to attempt to capture the market by		framework, allowing vendors to attempt to capture the market by
	requiring use of their preferred extensions to interoperate.		requiring use of their preferred extensions to interoperate.
	This kind of centralization risk can be mitigated in a few ways.		Therefore, standards efforts should be focused on providing concrete
	First and foremost, Internet protocols SHOULD provide concrete		utility to the majority of their users as published, rather than
	utility to the majority of their users as published; 'framework'		being a "framework" where interoperability is not immediately
	standards facilitate this kind of risk.		available. Furthermore, Internet protocols should not make every
			aspect of their operation extensible; extension points should be
	Furthermore, Internet protocols SHOULD NOT make every aspect of their		reasoned, appropriate boundaries for flexibility and control. When
	operation extensible; extension points SHOULD be reasoned,		extension points are defined, they should not allow an extension to
	appropriate boundaries for flexibility and control. When extension		declare itself to be mandatory-to-interoperate, as that pattern
	points are defined, they SHOULD NOT allow an extension to declare		invites abuse.
	itself to be mandatory-to-interoperate, as that pattern invites
	abuse.
	5.6. Acknowledge the Limits of Protocol Design
	Centralization cannot be prevented through protocol design and
	standardization efforts alone. While the guidelines above may
	forestall some types of centralization, indirect and platform
	centralization are often outside the control of a protocol's
	architecture.
	Thankfully, architecture is not the only form of regulation; legal
	mechanisms combined with changing norms and the resulting market
	forces have their own regulatory effects. [NEW-CHICAGO]
	In this view, the job of a protocol designer is to avoid
	centralization with architecture where possible, but where it is not,
	to create affordances for these other regulating forces.
	6. Security Considerations		7. Security Considerations
	This document does not have direct security impact on Internet		This document does not have direct security impact on Internet
	protocols. However, failure to consider centralization risks might		protocols. However, failure to consider centralization risks might
	result in a myriad of security issues.		result in a myriad of security issues.
	7. References		8. Informative References
	7.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/rfc/rfc2119>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
	7.2. Informative References
	[ACCESS] Vestager, M., "Defending Competition in a Digitised World,		[ACCESS] Vestager, M., "Defending Competition in a Digitised World,
	Address at the European Consumer and Competition Day",		Address at the European Consumer and Competition Day",
	April 2019, <https://wayback.archive-		April 2019, <https://wayback.archive-
	it.org/12090/20191129202059/https://ec.europa.eu/		it.org/12090/20191129202059/https://ec.europa.eu/
	commission/commissioners/2014-2019/vestager/announcements/		commission/commissioners/2014-2019/vestager/announcements/
	defending-competition-digitised-world_en>.		defending-competition-digitised-world_en>.
	[BCP95] Alvestrand, H., "A Mission Statement for the IETF",		[BCP95] Alvestrand, H., "A Mission Statement for the IETF",
	BCP 95, RFC 3935, October 2004.		BCP 95, RFC 3935, October 2004.
	skipping to change at page 17, line 26 ¶		skipping to change at page 18, line 8 ¶
	[HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP		[HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
	Semantics", Work in Progress, Internet-Draft, draft-ietf-		Semantics", Work in Progress, Internet-Draft, draft-ietf-
	httpbis-semantics-19, 12 September 2021,		httpbis-semantics-19, 12 September 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-		<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
	semantics-19>.		semantics-19>.
	[I-D.pauly-dprive-oblivious-doh]		[I-D.pauly-dprive-oblivious-doh]
	Kinnear, E., McManus, P., Pauly, T., Verma, T., and C. A.		Kinnear, E., McManus, P., Pauly, T., Verma, T., and C. A.
	Wood, "Oblivious DNS Over HTTPS", Work in Progress,		Wood, "Oblivious DNS Over HTTPS", Work in Progress,
	Internet-Draft, draft-pauly-dprive-oblivious-doh-08, 3		Internet-Draft, draft-pauly-dprive-oblivious-doh-09, 5
	December 2021, <https://datatracker.ietf.org/doc/html/		January 2022, <https://datatracker.ietf.org/doc/html/
	draft-pauly-dprive-oblivious-doh-08>.		draft-pauly-dprive-oblivious-doh-09>.
	[I-D.thomson-tmi]		[I-D.thomson-tmi]
	Thomson, M., "Principles for the Involvement of		Thomson, M., "Principles for the Involvement of
	Intermediaries in Internet Protocols", Work in Progress,		Intermediaries in Internet Protocols", Work in Progress,
	Internet-Draft, draft-thomson-tmi-02, 6 July 2021,		Internet-Draft, draft-thomson-tmi-02, 6 July 2021,
	<https://datatracker.ietf.org/doc/html/draft-thomson-tmi-		<https://datatracker.ietf.org/doc/html/draft-thomson-tmi-
	02>.		02>.
	[INTERMEDIARY-INFLUENCE]		[INTERMEDIARY-INFLUENCE]
	Judge, K., "Intermediary Influence", 2014,		Judge, K., "Intermediary Influence", 2014,
	skipping to change at page 18, line 5 ¶		skipping to change at page 18, line 36 ¶
	Inequalities in the Multistakeholder Internet Governance",		Inequalities in the Multistakeholder Internet Governance",
	2020.		2020.
	[MOXIE] Marlinspike, M., "Reflections: The ecosystem is moving",		[MOXIE] Marlinspike, M., "Reflections: The ecosystem is moving",
	May 2016,		May 2016,
	<https://signal.org/blog/the-ecosystem-is-moving/>.		<https://signal.org/blog/the-ecosystem-is-moving/>.
	[NEW-CHICAGO]		[NEW-CHICAGO]
	Lessig, L., "The New Chicago School", June 1998.		Lessig, L., "The New Chicago School", June 1998.
			[OECD] OECD, "Data portability, interoperability and digital
			platform competition", June 2021,
			<https://www.oecd.org/daf/competition/data-portability-
			interoperability-and-digital-platform-competition-
			2021.pdf>.
	[PIR] Olumofin, F. and I. Goldberg, "Revisiting the		[PIR] Olumofin, F. and I. Goldberg, "Revisiting the
	Computational Practicality of Private Information		Computational Practicality of Private Information
	Retrieval", 2010.		Retrieval", 2010.
	[POLYCENTRIC]		[POLYCENTRIC]
	Aligia, P.D. and V. Tarko, "Polycentricity: From Polanyi		Aligia, P.D. and V. Tarko, "Polycentricity: From Polanyi
	to Ostrom, and Beyond", April 2012.		to Ostrom, and Beyond", April 2012.
			[RAND] Baran, P., "On Distributed Communications: Introduction to
			Distributed Communications Networks", 1964,
			<https://www.rand.org/pubs/research_memoranda/
			RM3420.html>.
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,		specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
	November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.		November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.
			[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/rfc/rfc4271>.
	[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,		[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
	DOI 10.17487/RFC5321, October 2008,		DOI 10.17487/RFC5321, October 2008,
	<https://www.rfc-editor.org/rfc/rfc5321>.		<https://www.rfc-editor.org/rfc/rfc5321>.
	[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence		[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
	Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,		Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
	March 2011, <https://www.rfc-editor.org/rfc/rfc6120>.		March 2011, <https://www.rfc-editor.org/rfc/rfc6120>.
	[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an		[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
	Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May		Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
	2014, <https://www.rfc-editor.org/rfc/rfc7258>.		2014, <https://www.rfc-editor.org/rfc/rfc7258>.
	[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet		[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
	Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,		DOI 10.17487/RFC0791, September 1981,
	<https://www.rfc-editor.org/rfc/rfc8799>.		<https://www.rfc-editor.org/rfc/rfc791>.
			[RFC793] Postel, J., "Transmission Control Protocol", STD 7,
			RFC 793, DOI 10.17487/RFC0793, September 1981,
			<https://www.rfc-editor.org/rfc/rfc793>.
	[RFC8890] Nottingham, M., "The Internet is for End Users", RFC 8890,		[RFC8890] Nottingham, M., "The Internet is for End Users", RFC 8890,
	DOI 10.17487/RFC8890, August 2020,		DOI 10.17487/RFC8890, August 2020,
	<https://www.rfc-editor.org/rfc/rfc8890>.		<https://www.rfc-editor.org/rfc/rfc8890>.
	[SCALE-FREE]		[SCALE-FREE]
	Albert, R., "Emergence of Scaling in Random Networks",		Albert, R., "Emergence of Scaling in Random Networks",
	October 1999, <https://barabasi.com/f/67.pdf>.		October 1999, <https://barabasi.com/f/67.pdf>.
	[SOAP] Mitra, N. and Y. Lafon, "SOAP Version 1.2 Part 0: Primer		[SOAP] Mitra, N. and Y. Lafon, "SOAP Version 1.2 Part 0: Primer
	(Second Edition)", World Wide Web Consortium		(Second Edition)", World Wide Web Consortium
	Recommendation REC-soap12-part0-20070427, 27 April 2007,		Recommendation REC-soap12-part0-20070427, 27 April 2007,
	<https://www.w3.org/TR/2007/REC-soap12-part0-20070427>.		<https://www.w3.org/TR/2007/REC-soap12-part0-20070427>.
			[TECH-SUCCESS-FACTORS]
			Kende, M., Kvalbein, A., Allford, J., and D. Abecassis,
			"Study on the Internet's Technical Success Factors",
			December 2021, <https://blog.apnic.net/wp-
			content/uploads/2021/12/MKGRA669-Report-for-APNIC-LACNIC-
			V3.pdf>.
	[W3C.CR-activitystreams-core-20161215]		[W3C.CR-activitystreams-core-20161215]
	Snell, J. and E. Prodromou, "Activity Streams 2.0", World		Snell, J. and E. Prodromou, "Activity Streams 2.0", World
	Wide Web Consortium CR CR-activitystreams-core-20161215,		Wide Web Consortium CR CR-activitystreams-core-20161215,
	15 December 2016, <https://www.w3.org/TR/2016/CR-		15 December 2016, <https://www.w3.org/TR/2016/CR-
	activitystreams-core-20161215>.		activitystreams-core-20161215>.
	[WEAPONIZED-INTERDEPENDENCE]		[WEAPONIZED-INTERDEPENDENCE]
	Farrell, H. and A.L. Newman, "Weaponized Interdependence:		Farrell, H. and A.L. Newman, "Weaponized Interdependence:
	How Global Economic Networks Shape State Coercion", 2019,		How Global Economic Networks Shape State Coercion", 2019,
	<https://doi.org/10.1162/ISEC_a_00351>.		<https://doi.org/10.1162/ISEC_a_00351>.
End of changes. 104 change blocks.
	377 lines changed or deleted		448 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/