rfc9518.original.xml | rfc9518.xml | |||
---|---|---|---|---|
<?xml version='1.0' encoding='utf-8'?> | <?xml version='1.0' encoding='utf-8'?> | |||
<!DOCTYPE rfc [ | <!DOCTYPE rfc [ | |||
<!ENTITY nbsp " "> | <!ENTITY nbsp " "> | |||
<!ENTITY zwsp "​"> | <!ENTITY zwsp "​"> | |||
<!ENTITY nbhy "‑"> | <!ENTITY nbhy "‑"> | |||
<!ENTITY wj "⁠"> | <!ENTITY wj "⁠"> | |||
]> | ]> | |||
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> | <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.4 (Ruby 3.0.2 | |||
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.39 (Ruby 3.2. | ) --> | |||
2) --> | <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft | |||
<?rfc tocindent="yes"?> | -nottingham-avoiding-internet-centralization-14" category="info" submissionType= | |||
<?rfc strict="yes"?> | "independent" number="9518" tocInclude="true" sortRefs="true" symRefs="true" ver | |||
<?rfc compact="yes"?> | sion="3"> | |||
<?rfc comments="yes"?> | <!-- xml2rfc v2v3 conversion 3.18.2 --> | |||
<?rfc inline="yes"?> | ||||
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft | ||||
-nottingham-avoiding-internet-centralization-14" category="info" submissionType= | ||||
"independent" tocInclude="true" sortRefs="true" symRefs="true" version="3"> | ||||
<!-- xml2rfc v2v3 conversion 3.18.0 --> | ||||
<front> | <front> | |||
<title abbrev="Internet Centralization and Standards">Centralization, Decent | <title abbrev="Internet Standards & Centralization">Centralization, Dece | |||
ralization, and Internet Standards</title> | ntralization, and Internet Standards</title> | |||
<seriesInfo name="Internet-Draft" value="draft-nottingham-avoiding-internet- | <seriesInfo name="RFC" value="9518"/> | |||
centralization-14"/> | ||||
<author initials="M." surname="Nottingham" fullname="Mark Nottingham"> | <author initials="M." surname="Nottingham" fullname="Mark Nottingham"> | |||
<organization/> | <organization/> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<postalLine>Prahran</postalLine> | <postalLine>Prahran</postalLine> | |||
<postalLine>Australia</postalLine> | <postalLine>Australia</postalLine> | |||
</postal> | </postal> | |||
<email>mnot@mnot.net</email> | <email>mnot@mnot.net</email> | |||
<uri>https://www.mnot.net/</uri> | <uri>https://www.mnot.net/</uri> | |||
</address> | </address> | |||
</author> | </author> | |||
<date/> | <date month="December" year="2023"/> | |||
<area>General</area> | ||||
<keyword>governance</keyword> | <keyword>governance</keyword> | |||
<abstract> | <abstract> | |||
<?line 325?> | <?line 321?> | |||
<t>This document discusses aspects of centralization that relate to Internet sta ndards efforts. It argues that while standards bodies have limited ability to pr event many forms of centralization, they can still make contributions that assis t decentralization of the Internet.</t> | <t>This document discusses aspects of centralization that relate to Internet sta ndards efforts. It argues that, while standards bodies have a limited ability to prevent many forms of centralization, they can still make contributions that as sist in the decentralization of the Internet.</t> | |||
</abstract> | </abstract> | |||
<note removeInRFC="true"> | ||||
<name>About This Document</name> | ||||
<t> | ||||
Status information for this document may be found at <eref target="https | ||||
://datatracker.ietf.org/doc/draft-nottingham-avoiding-internet-centralization/"/ | ||||
>. | ||||
</t> | ||||
<t>Source for this draft and an issue tracker can be found at | ||||
<eref target="https://github.com/mnot/avoiding-internet-centralization"/ | ||||
>.</t> | ||||
</note> | ||||
</front> | </front> | |||
<middle> | <middle> | |||
<?line 330?> | <?line 326?> | |||
<section anchor="introduction"> | <section anchor="introduction"> | |||
<name>Introduction</name> | <name>Introduction</name> | |||
<t>One of the Internet's defining features is its lack of any single point | <t>One of the Internet's defining features is its lack of any single point | |||
of technical, political, or economic control. Arguably, that property assisted | of technical, political, or economic control. Arguably, that characteristic ass | |||
the Internet's early adoption and broad reach: because permission is not require | isted the Internet's early adoption and broad reach: permission is not required | |||
d to connect to, deploy an application on, or use the Internet for a particular | to connect to, deploy an application on, or use the Internet for a particular pu | |||
purpose, it can meet diverse needs and be deployed in many different environment | rpose, so it can meet diverse needs and be deployed in many different environmen | |||
s.</t> | ts.</t> | |||
<t>Although maintaining that state of affairs remains a widely espoused go | <t>Although maintaining that state of affairs remains a widely espoused go | |||
al, consistently preserving it across the range of services and applications tha | al, consistently preserving it across the range of services and applications tha | |||
t people see as "the Internet" has proven elusive. Whereas early services like N | t people see as "the Internet" has proven elusive. Whereas early services like t | |||
NTP and e-mail had multiple, interoperable providers, many contemporary platform | he Network News Transfer Protocol (NNTP) and email had multiple interoperable pr | |||
s for content and services are operated by single, commercial entities without a | oviders, many contemporary platforms for content and services are operated by si | |||
ny interoperable alternative -- to the point where some have become so well-know | ngle commercial entities without any interoperable alternative -- to the point w | |||
n and important to people's experiences that they are commonly mistaken for the | here some have become so well-known and important to people's experiences that t | |||
Internet itself. <xref target="FB-INTERNET"/></t> | hey are commonly mistaken for the Internet itself <xref target="FB-INTERNET"/>.< | |||
<t>These difficulties call into question what role architectural design -- | /t> | |||
in particular, that overseen by open standards bodies such as the IETF -- can a | <t>These difficulties call into question what role architectural design -- | |||
nd should play in controlling centralization on the Internet.</t> | in particular, that overseen by open standards bodies such as the IETF -- can a | |||
<t>This document argues that while decentralized technical standards may b | nd should play in controlling centralization of the Internet.</t> | |||
e necessary to avoid centralization of Internet functions, they are not sufficie | <t>This document argues that, while decentralized technical standards may | |||
nt to achieve that goal because centralization is often caused by non-technical | be necessary to avoid centralization of Internet functions, they are not suffici | |||
factors outside the control of standards bodies. As a result, standards bodies s | ent to achieve that goal because centralization is often caused by non-technical | |||
hould not fixate on preventing all forms of centralization; instead, they should | factors outside the control of standards bodies. As a result, standards bodies | |||
take steps to ensure that the specifications they produce enable decentralized | should not fixate on preventing all forms of centralization; instead, they shoul | |||
operation.</t> | d take steps to ensure that the specifications they produce enable decentralized | |||
<t>Although this document has been discussed widely in the IETF community | operation.</t> | |||
(see <xref target="acks"/>), it represents the views of the author, not communit | <t>Although this document has been discussed widely in the IETF community | |||
y consensus. Its primary audience is the engineers who design and standardize In | (see <xref target="acks"/>), it represents the views of the author, not communit | |||
ternet protocols. Designers of proprietary protocols and applications can benefi | y consensus. Its primary audience is the engineers who design and standardize In | |||
t from considering these issues, especially if they intend their work to be cons | ternet protocols. Designers of proprietary protocols and applications can benefi | |||
idered for eventual standardization. Policymakers can use this document to help | t from considering these issues, especially if they intend their work to be cons | |||
characterise abuses that involve centralized protocols and applications and eval | idered for eventual standardization. Policymakers can use this document to help | |||
uate proposed remedies for them.</t> | characterize abuses that involve centralized protocols and applications and eval | |||
<t><xref target="centralization"/> defines centralization, explains why it | uate proposed remedies for them.</t> | |||
is often undesirable but sometimes beneficial, and surveys how it occurs on the | <t><xref target="centralization"/> defines centralization, explains why it | |||
Internet. <xref target="decentralization"/> explores decentralization and highl | is often undesirable but sometimes beneficial, and surveys how it occurs on the | |||
ights some relevant strategies, along with their limitations. Then, <xref target | Internet. <xref target="decentralization"/> explores decentralization and highl | |||
="considerations"/> makes recommendations about the role that Internet standards | ights some relevant strategies, along with their limitations. <xref target="con | |||
can play in controlling centralization. <xref target="conclude"/> concludes by | siderations"/> makes recommendations about the role that Internet standards can | |||
identifying areas for future work.</t> | play in controlling centralization. <xref target="conclude"/> concludes by ident | |||
ifying areas for future work.</t> | ||||
</section> | </section> | |||
<section anchor="centralization"> | <section anchor="centralization"> | |||
<name>Centralization</name> | <name>Centralization</name> | |||
<t>In this document, "centralization" is the state of affairs where a sing le entity or a small group of them can observe, capture, control, or extract ren t from the operation or use of an Internet function exclusively.</t> | <t>In this document, "centralization" is the state of affairs where a sing le entity or a small group of them can observe, capture, control, or extract ren t from the operation or use of an Internet function exclusively.</t> | |||
<t>Here, "entity" could be a person, group, or corporation. An organizatio | <t>Here, "entity" could be a person, group, or corporation. An organizatio | |||
n might be subject to governance that mitigates centralization risk (see <xref t | n might be subject to governance that mitigates centralization risk (see <xref t | |||
arget="multi"/>), but that organisation is still a centralizing entity.</t> | arget="multi"/>), but that organization is still a centralizing entity.</t> | |||
<t>"Internet function" is used broadly in this document. Most directly, it | <t>"Internet function" is used broadly in this document. Most directly, it | |||
might be an enabling protocol already defined by standards, such as IP <xref ta | might be an enabling protocol already defined by standards, such as IP <xref ta | |||
rget="RFC791"/>, BGP <xref target="RFC4271"/>, TCP <xref target="RFC793"/>, or H | rget="RFC791"/>, BGP <xref target="RFC4271"/>, TCP <xref target="RFC9293"/>, or | |||
TTP <xref target="HTTP"/>. It might also be a proposal for a new enabling protoc | HTTP <xref target="RFC9110"/>. It might also be a proposal for a new enabling pr | |||
ol, or an extension to an existing one.</t> | otocol or an extension to an existing one.</t> | |||
<t>Because people's experience of the Internet are not limited to standard s-defined protocols and applications, this document also considers centralizatio n in functions built on top of standards -- for example, social networking, file sharing, financial services, and news dissemination. Likewise, the networking e quipment, hardware, operating systems, and software that act as enabling technol ogies for the Internet can also impact centralization. The supply of Internet co nnectivity to end users in a particular area or situation can exhibit centraliza tion, as can the supply of transit between networks (so called "Tier 1" networks ).</t> | <t>Because people's experience of the Internet are not limited to standard s-defined protocols and applications, this document also considers centralizatio n in functions built on top of standards -- for example, social networking, file sharing, financial services, and news dissemination. Likewise, the networking e quipment, hardware, operating systems, and software that act as enabling technol ogies for the Internet can also impact centralization. The supply of Internet co nnectivity to end users in a particular area or situation can exhibit centraliza tion, as can the supply of transit between networks (so called "Tier 1" networks ).</t> | |||
<t>This definition does not capture all types of centralization. Notably, | <t>This definition of centralization does not capture all types of central | |||
technical centralization (where, for example, a machine or network link is a sin | ization. Notably, technical centralization (for example, where a machine or netw | |||
gle point of failure) is relatively well-understood by engineers, and can be mit | ork link is a single point of failure) is relatively well understood by engineer | |||
igated, typically by distributing a function across multiple components. As we w | s; it can be mitigated, typically by distributing a function across multiple com | |||
ill see, such techniques might address that type of centralization while failing | ponents. As we will see, such techniques might address that type of centralizati | |||
to prevent control of the function falling into few hands. A failure because of | on while failing to prevent control of the function falling into few hands. A fa | |||
a cut cable, power outage, or failed server is well-understood by the technical | ilure because of a cut cable, power outage, or failed server is well understood | |||
community, but qualitatively different from the issues encountered when a core | by the technical community but is qualitatively different from the issues encoun | |||
Internet function has a gatekeeper.</t> | tered when a core Internet function has a gatekeeper.</t> | |||
<t>Likewise, political centralization (where, for example, a country is ab | <t>Likewise, political centralization (for example, where a country is abl | |||
le to control how a function is supplied across the whole Internet) is equally c | e to control how a function is supplied across the whole Internet) is equally co | |||
oncerning, but not considered in depth here.</t> | ncerning but is not considered in depth here.</t> | |||
<t>Even when centralization is not currently present in a function, some c | <t>Even when centralization is not currently present in a function, some c | |||
onditions make it more likely that centralization will emerge in the future. Thi | onditions make it more likely that centralization will emerge in the future. Thi | |||
s document uses "centralization risk" to characterise that possibility.</t> | s document uses "centralization risk" to characterize that possibility.</t> | |||
<section anchor="why"> | <section anchor="why"> | |||
<name>Centralization Can Be Harmful</name> | <name>Centralization Can Be Harmful</name> | |||
<t>Many engineers who participate in Internet standards efforts have an inclination to prevent and counteract centralization because they see the Intern et's history and architecture as incompatible with it. As a "large, heterogeneou s collection of interconnected systems" <xref target="BCP95"/> the Internet is o ften characterised as a "network of networks" whose operators relate as peers th at agree to facilitate communication, rather than experiencing coercion or requi ring subservience to others' requirements. This focus on independence of action is prevalent in the Internet's design -- for example, in the concept of an "auto nomous system".</t> | <t>Many engineers who participate in Internet standards efforts have an inclination to prevent and counteract centralization because they see the Intern et's history and architecture as incompatible with it. As a "large, heterogeneou s collection of interconnected systems" <xref target="BCP95"/> the Internet is o ften characterized as a "network of networks" whose operators relate as peers th at agree to facilitate communication rather than experiencing coercion or requir ing subservience to others' requirements. This focus on independence of action i s prevalent in the Internet's design -- for example, in the concept of an "auton omous system".</t> | |||
<t>Reluctance to countenance centralization is also rooted in the many p otentially damaging effects that have been associated with it, including:</t> | <t>Reluctance to countenance centralization is also rooted in the many p otentially damaging effects that have been associated with it, including:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
<em>Power Imbalance</em>: When a third party has unavoidable access | <t><em>Power Imbalance</em>: When a third party has unavoidable acce | |||
to communications, they gain informational and positional advantages that allow | ss to communications, they gain informational and positional advantages that all | |||
observation of behavior (the "panopticon effect") and shaping or even denial of | ow observation of behavior (the "panopticon effect") and shaping or even denial | |||
behavior (the "chokepoint effect") <xref target="INTERMEDIARY-INFLUENCE"/> -- ca | of behavior (the "chokepoint effect"): capabilities that those parties (or the s | |||
pabilities that those parties (or the states that have authority over them) can | tates that have authority over them) can use for coercive ends <xref target="INT | |||
use for coercive ends <xref target="INTERDEPENDENCE"/> or even to disrupt societ | ERDEPENDENCE"/> or even to disrupt society itself. Just as <xref target="FEDERAL | |||
y itself. Just as good governance of states requires separation of powers <xref | IST-51"/> describes good governance of the US states, good governance of the Int | |||
target="FEDERALIST-51"/>, so too does good governance of the Internet require th | ernet requires that power over any function not be consolidated in one place wit | |||
at power not be consolidated in one place without appropriate checks and balance | hout appropriate checks and balances.</t> | |||
s.</li> | </li> | |||
<li> | <li> | |||
<em>Limits on Innovation</em>: A party with the ability to control c | <t><em>Limits on Innovation</em>: A party with the ability to contro | |||
ommunication can preclude the possibility of "permissionless innovation" -- the | l communication can preclude the possibility of "permissionless innovation", i.e | |||
ability to deploy new, unforeseen applications without requiring coordination wi | ., the ability to deploy new, unforeseen applications without requiring coordina | |||
th parties other than those you are communicating with.</li> | tion with parties other than those you are communicating with.</t> | |||
</li> | ||||
<li> | <li> | |||
<em>Constraints on Competition</em>: The Internet and its users bene | <t><em>Constraints on Competition</em>: The Internet and its users b | |||
fit from robust competition when applications and services are available from ma | enefit from robust competition when applications and services are available from | |||
ny providers -- especially when those users can build their own applications and | many providers, especially when those users can build their own applications an | |||
services based upon interoperable standards. When a centralized service or plat | d services based upon interoperable standards. When a centralized service or pla | |||
form must be used because no substitutes are suitable, it effectively becomes an | tform must be used because no substitutes are suitable, it effectively becomes a | |||
essential facility, which facilitates abuse of power.</li> | n essential facility, which opens the door to abuse of power.</t> | |||
</li> | ||||
<li> | <li> | |||
<em>Reduced Availability</em>: Availability of the Internet (and app | <t><em>Reduced Availability</em>: Availability of the Internet (and | |||
lications and services built upon it) improves when there are many ways to obtai | applications and services built upon it) improves when there are many ways to ob | |||
n access. While service availability can benefit from the focused attention of a | tain access. While service availability can benefit from the focused attention o | |||
large centralized provider, that provider's failure can have a disproportionate | f a large centralized provider, that provider's failure can have a disproportion | |||
impact on availability.</li> | ate impact on availability.</t> | |||
</li> | ||||
<li> | <li> | |||
<em>Monoculture</em>: The scale available to a centralized provider | <t><em>Monoculture</em>: The scale available to a centralized provid | |||
can magnify minor flaws in features to a degree that can have broad consequences | er can magnify minor flaws in features to a degree that can have broad consequen | |||
. For example, a single codebase for routers elevates the impact of a bug or vul | ces. For example, a single codebase for routers elevates the impact of a bug or | |||
nerability; a single recommendation algorithm for content can have severe social | vulnerability; a single recommendation algorithm for content can have severe soc | |||
impact. Diversity in functions’ implementation leads to a more robust outcome w | ial impact. Diversity in functions’ implementations leads to a more robust outco | |||
hen viewed systemically, because "progress is the outcome of a trial-and-error e | me when viewed systemically because "progress is the outcome of a trial-and-erro | |||
volutionary process of many agents interacting freely." <xref target="POLYCENTRI | r evolutionary process of many agents interacting freely" <xref target="POLYCENT | |||
C"/></li> | RIC"/>.</t> | |||
</li> | ||||
<li> | <li> | |||
<em>Self-Reinforcement</em>: As widely noted (see, e.g., <xref targe | <t><em>Self-Reinforcement</em>: As widely noted (e.g., see <xref tar | |||
t="ACCESS"/>), a centralized provider's access to data allows it the opportunity | get="ACCESS"/>), a centralized provider's access to data allows it the opportuni | |||
to make improvements to its offerings, while denying such access to others.</li | ty to make improvements to its offerings while denying such access to others.</t | |||
> | > | |||
</li> | ||||
</ul> | </ul> | |||
<t>The relationship between these harms and centralization is often comp | <t>The relationship between these harms and centralization is often comp | |||
lex; it is not always the case that centralization will lead to them, and when i | lex. It is not always the case that centralization will lead to them; when it do | |||
t does, there is not always a direct and simple tradeoff.</t> | es, there is not always a direct and simple trade-off.</t> | |||
<t>For example, consider the relationship between centralization and ava | <t>For example, consider the relationship between centralization and ava | |||
ilability. A centrally operated system might be more available because of the re | ilability. A centrally operated system might be more available because of the re | |||
sources available to a larger operator, but their size creates greater impact wh | sources available to a larger operator, but their size creates greater impact wh | |||
en a fault is encountered. Decentralized systems can be more resilient in the fa | en a fault is encountered. Decentralized systems can be more resilient in the fa | |||
ce of some forms of failure, but less so in other ways; for example, they may be | ce 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 collect | less able to react to systemic issues and might be exposed to a larger collectio | |||
ion of security vulnerabilities in total. As such, it cannot be said that centra | n of security vulnerabilities in total. As such, it cannot be said that centrali | |||
lization reduces availability in all cases; nor does it improve it in all cases. | zation reduces availability in all cases: nor does it improve it in all cases.</ | |||
</t> | t> | |||
<t>This tension can be seen in areas like the cloud and mobile Internet | <t>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 | access. If a popular cloud-hosting provider were to become unavailable (whether | |||
for technical or other reasons), many people's experience of the Internet might | for technical or other reasons), many Internet experiences might be disrupted (e | |||
be disrupted (especially due to the multiple dependencies that a modern Web site | specially due to the multiple dependencies that a modern website often has; see | |||
often has; see <xref target="DEPENDENCIES"/>). Likewise, a large mobile Interne | <xref target="DEPENDENCIES"/>). Likewise, a large mobile Internet access provide | |||
t access provider might have an outage that affects hundreds of thousands of its | r might have an outage that affects hundreds of thousands of its users or more - | |||
users, or more -- just as previous issues at large telephone companies precipit | - just as previous issues at large telephone companies precipitated widespread o | |||
ated widespread outages. <xref target="PHONE"/></t> | utages <xref target="PHONE"/>.</t> | |||
<t>In both cases, the services are not technically centralized; these op | <t>In both cases, the services are not technically centralized; these op | |||
erators have strong incentives to have multiple redundancies in place and use va | erators have strong incentives to have multiple redundancies in place and use va | |||
rious techniques to mitigate the risk of any one component failing. However, the | rious techniques to mitigate the risk of any one component failing. However, the | |||
y generally do rely upon a single codebase, a limited selection of hardware, a u | y generally do rely upon a single codebase, a limited selection of hardware, a u | |||
nified control plane, and a uniform administrative practice -- each of which mig | nified control plane, and a uniform administrative practice: each of which might | |||
ht precipitate a widespread failure.</t> | precipitate a widespread failure.</t> | |||
<t>If there were only one provider for these services (like the telephon | <t>If there were only one provider for these services (like the telephon | |||
e networks of old), they would easily be considered as centralized in a way that | e networks of old), they would easily be considered to be centralized in a way t | |||
has significant impact upon availiability. However, many cloud providers offer | hat has significant impact upon availability. However, many cloud providers offe | |||
similar services, and in most places there are multiple mobile operators availab | r similar services. In most places, there are multiple mobile operators availabl | |||
le. That weakens the argument that there is a link between centralization and th | e. That weakens the argument that there is a link between centralization and the | |||
eir availability, because the function's users can switch to other providers, or | ir availability because the function's users can switch to other providers or us | |||
use more than one provider simultaneously; see <xref target="switch"/>.</t> | e more than one provider simultaneously; see <xref target="switch"/>.</t> | |||
<t>These circumstances suggest one area of inquiry when considering the relationship between centralization and availability of a given function: what b arriers are there to switching to other providers (thereby making any disruption s temporary and manageable) or to using multiple providers simultaneously (to ma sk the failure of a single operator)?</t> | <t>These circumstances suggest one area of inquiry when considering the relationship between centralization and availability of a given function: what b arriers are there to switching to other providers (thereby making any disruption s temporary and manageable) or to using multiple providers simultaneously (to ma sk the failure of a single operator)?</t> | |||
<t>Another example of the need for nuance can be seen when evaluating co mpetitive 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 anti-competitive. In particular, market concentration does not alwa ys indicate competition issues, so what might be considered undesirable centrali zation by the technical community might not attract competition regulation.</t> | <t>Another example of the need for nuance can be seen when evaluating co mpetitive 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 ce ntralization by the technical community might not attract competition regulation .</t> | |||
</section> | </section> | |||
<section anchor="necessary"> | <section anchor="necessary"> | |||
<name>Centralization Can Be Helpful</name> | <name>Centralization Can Be Helpful</name> | |||
<t>The potential harms of centralization listed above are widely appreci | <t>The potential damaging effects of centralization listed above are wid | |||
ated. Less widely explored is the reliance on centralization by some protocols a | ely appreciated. Less widely explored is the reliance on centralization by some | |||
nd applications to deliver their functionality.</t> | protocols and applications to deliver their functionality.</t> | |||
<t>Often, centralization is present due to technical necessity. For exam | <t>Centralization is often present due to technical necessity. For examp | |||
ple, a single, globally coordinated “source of truth” is by nature centralized - | le, 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-f | such as in the root zone of the Domain Name System (DNS), which allows human-fri | |||
riendly naming to be converted into network addresses in a globally consistent f | endly naming to be converted into network addresses in a globally consistent fas | |||
ashion.</t> | hion.</t> | |||
<t>Or, consider IP address allocation. Internet routing requires address | <t>Or, consider IP address allocation. Internet routing requires address | |||
es to be allocated uniquely, but if a single government or company were to captu | es to be allocated uniquely, but if a single government or company were to captu | |||
re the addressing function, the entire Internet would be at risk of abuse by tha | re the addressing function, the entire Internet would be at risk of abuse by tha | |||
t entity. Similarly, the Web's trust model requires a Certificate Authority to s | t entity. Similarly, the Web's trust model requires a Certificate Authority (CA) | |||
erve as the root of trust for communication between browsers and servers, bringi | to serve as the root of trust for communication between browsers and servers, b | |||
ng centralization risk that needs to be considered in the design of that system. | ringing the centralization risk, which needs to be considered in the design of t | |||
</t> | hat system.</t> | |||
<t>Protocols that need to solve the "rendezvous problem" to coordinate c | <t>Protocols that need to solve the "rendezvous problem" to coordinate c | |||
ommunication between two parties who are not in direct contact also require cent | ommunication between two parties who are not in direct contact also require cent | |||
ralization. For example, chat protocols need to coordinate communication between | ralization. For example, chat protocols need to coordinate communication between | |||
two parties that wish to talk; while the actual communication can be direct bet | two parties that wish to talk; while the actual communication can be direct bet | |||
ween them (so long as the protocol facilitates that), the endpoints' mutual disc | ween them (so long as the protocol facilitates that), the endpoints' mutual disc | |||
overy typically requires a third party at some point. From the perspective of th | overy typically requires a third party at some point. From the perspective of th | |||
ose two users, the rendezvous function has centralization risk.</t> | ose two users, the rendezvous function has a centralization risk.</t> | |||
<t>Even when not strictly necessary, centralization can create benefits for a function's users and for society.</t> | <t>Even when not strictly necessary, centralization can create benefits for a function's users and for society.</t> | |||
<t>For example, it has long been recognised that the efficiencies that c | <t>For example, it has long been recognized that the efficiencies that c | |||
ome with economies of scale can lead to concentration. <xref target="SCALE"/> Th | ome with economies of scale can lead to concentration <xref target="SCALE"/>. Th | |||
ose efficiences can be passed on to users as higher quality products and lower c | ose efficiencies can be passed on to users as higher quality products and lower | |||
osts, and might even enable provision of a function that was not viable at small | costs, and they might even enable provision of a function that was not viable at | |||
er scale.</t> | smaller scale.</t> | |||
<t>Complex and risky functions like financial services (e.g., credit car | <t>Complex and risky functions like financial services (e.g., credit car | |||
d processing) are often concentrated into a few specialized organizations, where | d processing) are often concentrated into a few specialized organizations where | |||
they can receive the focused attention and expertise that they require.</t> | they can receive the focused attention and expertise that they require.</t> | |||
<t>Centralization can also provide an opportunity for beneficial control | <t>Centralization can also provide an opportunity for beneficial control | |||
s to be imposed. <xref target="AMBITION"/> notes that "centralized structures ca | s to be imposed. <xref target="AMBITION"/> notes that "centralized structures ca | |||
n have virtues, such as enabling publics to focus their limited attention for ov | n have virtues, such as enabling publics to focus their limited attention for ov | |||
ersight, or forming a power bloc capable of challenging less-accountable blocs t | ersight, or forming a power bloc capable of challenging less-accountable blocs t | |||
hat might emerge. Centralized structures that have earned widespread respect in | hat might emerge. Centralized structures that have earned widespread respect in | |||
recent centuries – including governments, corporations, and nonprofit organizati | recent centuries – including governments, corporations, and nonprofit organizati | |||
ons – have done so in no small part because of the intentional design that went | ons – have done so in no small part because of the intentional design that went | |||
into those structures."</t> | into those structures".</t> | |||
<t>This can be seen when a function requires governance to realize commo | <t>This can be seen when a function requires governance to realize commo | |||
n goals and protect minority interests. For example, content moderation function | n goals and protect minority interests. For example, content moderation function | |||
s impose community values that many see as a benefit. Of course, they can also b | s impose community values that many see as a benefit. Of course, they can also b | |||
e viewed as a choke point where inappropriate controls are able to be imposed, i | e viewed as a choke point where inappropriate controls are able to be imposed if | |||
f that governance mechanism has inadequate oversight, transparency, or accountab | that governance mechanism has inadequate oversight, transparency, or accountabi | |||
ility.</t> | lity.</t> | |||
<t>Ultimately, deciding when centralization is beneficial is a judgment | <t>Ultimately, deciding when centralization is beneficial is a judgment | |||
call. Some protocols cannot function without a centralized function; others migh | call. Some protocols cannot operate without a centralized function; others might | |||
t be significantly enhanced for certain use cases if a function is centralized, | be significantly enhanced for certain use cases if a function is centralized or | |||
or might merely be more efficient. In general, though, centralization is most co | might merely be more efficient. Although, in general, centralization is most co | |||
ncerning when it is not broadly held to be necessary or beneficial, when it has | ncerning 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 "fav | no checks, balances, or other mechanisms of accountability; when it selects "fav | |||
orites" which are difficult (or impossible) to displace, and when it threatens t | orites" that are difficult (or impossible) to displace; and when it threatens th | |||
he architectural features that make the Internet successful.</t> | e architectural features that make the Internet successful.</t> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="decentralization"> | <section anchor="decentralization"> | |||
<name>Decentralization</name> | <name>Decentralization</name> | |||
<t>While the term "decentralization" has a long history of use in economic s, politics, religion, and international development, <xref target="RAND"/> gave one of the first definitions relevant to computer networking, as a condition wh en "complete reliance upon a single point is not always required."</t> | <t>While the term "decentralization" has a long history of use in economic s, politics, religion, and international development, <xref target="RAND"/> gave one of the first definitions relevant to computer networking as a condition whe n "complete reliance upon a single point is not always required".</t> | |||
<t>Such technical centralization (while not a trivial topic) is relatively well understood. Avoiding all forms of centralization -- including non-technica l ones -- using only technical tools (like protocol design) is considerably more difficult. Several issues are encountered.</t> | <t>Such technical centralization (while not a trivial topic) is relatively well understood. Avoiding all forms of centralization -- including non-technica l ones -- using only technical tools (like protocol design) is considerably more difficult. Several issues are encountered.</t> | |||
<t>First and most critically, technical decentralization measures have at | <t>First, and most critically, technical decentralization measures have, a | |||
best limited effects on non-technical forms of centralization. Or, per <xref tar | t best, limited effects on non-technical forms of centralization. Or, per <xref | |||
get="SCHNEIDER"/>, "decentralized technology alone does not guarantee decentrali | target="SCHNEIDER"/>, "decentralized technology alone does not guarantee decentr | |||
zed outcomes." As explored below in <xref target="techniques"/>, technical measu | alized outcomes". As explored below in <xref target="techniques"/>, technical me | |||
res are better characterised as necessary but insufficient to achieve full decen | asures are better characterized as necessary but insufficient to achieve full de | |||
tralization of a function.</t> | centralization of a function.</t> | |||
<t>Second, decentralizing a function requires overcoming challenges that c | <t>Second, decentralizing a function requires overcoming challenges that c | |||
entralized ones do not face. A decentralized function can be more difficult to a | entralized ones do not face. A decentralized function can be more difficult to a | |||
dapt to user needs (for example, introducing new features, or experimenting with | dapt to user needs (for example, introducing new features or experimenting with | |||
user interface) because doing so often requires coordination between many diffe | user interfaces) because doing so often requires coordination between many diffe | |||
rent actors. <xref target="MOXIE"/> Economies of scale are more available to cen | rent actors <xref target="MOXIE"/>. Economies of scale are more available to cen | |||
tralized functions, as is data that can be used to refine a function's design. A | tralized functions, as is data that can be used to refine a function's design. A | |||
ll of these factors make centralized solutions more attractive to service provid | ll of these factors make centralized solutions more attractive to service provid | |||
ers, and in some cases can make a decentralized solution uneconomic.</t> | ers and, in some cases, can make a decentralized solution uneconomic.</t> | |||
<t>Third, identifying which aspects of a function to decentralize can be d | <t>Third, identifying which aspects of a function to decentralize can be d | |||
ifficult, both because there are often many interactions between different types | ifficult, both because there are often many interactions between different types | |||
and sources of centralization, and because centralization sometimes only become | and sources of centralization and because centralization sometimes only becomes | |||
s clear after the function is deployed at scale. Efforts to decentralize often h | clear after the function is deployed at scale. Efforts to decentralize often ha | |||
ave the effect of merely shifting centralization to a different place -- for exa | ve the effect of merely shifting centralization to a different place -- for exam | |||
mple, in its governance, implementation, deployment, or in ancillary functions.< | ple, in its governance, implementation, deployment, or ancillary functions.</t> | |||
/t> | <t>For example, the Web was envisioned and widely held to be a decentraliz | |||
<t>For example, the Web was envisioned and widely held to be a decentraliz | ing force in its early life. Its potential as an enabler of centralization only | |||
ing force in its early life. Its potential as an enabler of centralization only | became apparent when large websites successfully leveraged network effects (and | |||
became apparent when large Web sites successfully leveraged network effects (and | secured legal prohibitions against interoperability, thus increasing switching c | |||
secured legal prohibitions against interoperability, thus increasing switching | osts; see <xref target="ADVERSARIAL"/>) to achieve dominance of social networkin | |||
costs; see <xref target="ADVERSARIAL"/>) to achieve dominance of social networki | g, marketplaces, and similar functions.</t> | |||
ng, marketplaces, and similar functions.</t> | <t>Fourth, different parties might have good-faith differences on what "su | |||
<t>Fourth, different parties might have good-faith differences on what "su | fficiently decentralized" means based upon their beliefs, perceptions, and goals | |||
fficiently decentralized" means based upon their beliefs, perceptions and goals. | . Just as centralization is a continuum, so is decentralization, and not everyon | |||
Just as centralization is a continuum, so is decentralization, and not everyone | e agrees what the "right" level or type is, how to weigh different forms of cent | |||
agrees what the "right" level or type is, how to weigh different forms of centr | ralization against each other, or how to weigh potential centralization against | |||
alization against each other, or how to weigh potential centralization against o | other architectural goals (such as security or privacy).</t> | |||
ther architectural goals (such as security or privacy).</t> | <t>These tensions can be seen, for example, in the DNS. While some aspects | |||
<t>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 | |||
of the system are decentralized -- for example, the distribution of the lookup | function to local servers that users have the option to override -- an essential | |||
function to local servers that users have the option to override -- an essential | ly centralized aspect of the DNS is its operation as a name space: a single glob | |||
ly centralized aspect of the DNS is its operation as a name space: a single, glo | al "source of truth" with inherent (if beneficial) centralization in its managem | |||
bal "source of truth" with inherent (if beneficial) centralization in its manage | ent. ICANN mitigates the associated risk through multi-stakeholder governance (s | |||
ment. ICANN mitigates the associated risk through multi-stakeholder governance ( | ee <xref target="multi"/>). While many believe that this arrangement is sufficie | |||
see <xref target="multi"/>). While many believe that this arrangement is suffici | nt and might even have desirable qualities (such as the ability to impose commun | |||
ent and might even have desirable qualities (such as the ability to impose commu | ity standards over the operation of the name space), others reject ICANN's overs | |||
nity standards over the operation of the name space), others reject ICANN's over | ight of the DNS as illegitimate, favoring decentralization based upon distribute | |||
sight of the DNS as illegitimate, favoring decentralization based upon distribut | d consensus protocols rather than human governance <xref target="MUSIANI"/>.</t> | |||
ed consensus protocols rather than human governance. <xref target="MUSIANI"/></t | <t>Fifth, decentralization unavoidably involves adjustments to the power r | |||
> | elationships between protocol participants, especially when it opens up the poss | |||
<t>Fifth, decentralization unavoidably involves adjustments to the power r | ibility of centralization elsewhere. As <xref target="AMBITION"/> notes, decentr | |||
elationships between protocol participants, especially when it opens up the poss | alization "appears to operate as a rhetorical strategy that directs attention to | |||
ibility of centralization elsewhere. As Schneider notes in <xref target="AMBITIO | ward some aspects of a proposed social order and away from others", so "we canno | |||
N"/>, decentralization "appears to operate as a rhetorical strategy that directs | t accept technology as a substitute for taking social, cultural, and political c | |||
attention toward some aspects of a proposed social order and away from others", | onsiderations seriously". Or, more bluntly, "without governance mechanisms in pl | |||
so "we cannot accept technology as a substitute for taking social, cultural, an | ace, nodes may collude, people may lie to each other, markets can be rigged, and | |||
d political considerations seriously." Or, more bluntly, "without governance mec | there can be significant cost to people entering and exiting markets" <xref tar | |||
hanisms in place, nodes may collude, people may lie to each other, markets can b | get="PERSPECTIVE"/>.</t> | |||
e rigged, and there can be significant cost to people entering and exiting marke | <t>For example, while blockchain-based cryptocurrencies purport to address | |||
ts." <xref target="PERSPECTIVE"/></t> | the centralization inherent in existing currencies through technical means, man | |||
<t>For example, while blockchain-based cryptocurrencies purport to address | y exhibit considerable concentration of power due to voting/mining power, distri | |||
the centralization inherent in traditional currencies through technical means, | bution of funds, and diversity of the codebase <xref target="BITCOIN"/>. Overrel | |||
many exhibit considerable concentration of power due to voting/mining power, dis | iance on technical measures also brings an opportunity for latent, informal powe | |||
tribution of funds, and diversity of codebase. <xref target="BITCOIN"/> Over-rel | r structures that have their own risks -- including centralization <xref target= | |||
iance on technical measures also brings an opportunity for latent, informal powe | "STRUCTURELESS"/>.</t> | |||
r structures that have their own risks -- including centralization. <xref target | <t>Overall, decentralizing a function requires considerable work, is inher | |||
="STRUCTURELESS"/></t> | ently political, and involves a large degree of uncertainty about the outcome. I | |||
<t>Overall, decentralizing a function requires considerable work, is inher | f one considers decentralization as a larger social goal (in the spirit of how t | |||
ently political, and involves a large degree of uncertainty about the outcome. I | he term is used in other, non-computing contexts), merely rearranging technical | |||
f one considers decentralization as a larger social goal (in the spirit of how t | functions may lead to frustration. "A distributed network does not automatically | |||
he term is used in other, non-computing contexts), merely rearranging technical | yield an egalitarian, equitable or just social, economic, political landscape" | |||
functions may lead to frustration. "A distributed network does not automatically | <xref target="PERSPECTIVE"/>.</t> | |||
yield an egalitarian, equitable or just social, economic, political landscape." | ||||
<xref target="PERSPECTIVE"/></t> | ||||
<section anchor="techniques"> | <section anchor="techniques"> | |||
<name>Decentralization Strategies</name> | <name>Decentralization Strategies</name> | |||
<t>This section examines some common strategies that are employed to dec entralize Internet functions, along with their limitations.</t> | <t>This section examines some common strategies that are employed to dec entralize Internet functions and discusses their limitations.</t> | |||
<section anchor="federation"> | <section anchor="federation"> | |||
<name>Federation</name> | <name>Federation</name> | |||
<t>Protocol designers often attempt to address centralization through | <t>Protocol designers often attempt to address centralization through | |||
federation: designing a function in a way that uses independent instances who ma | federation, i.e., designing a function in a way that uses independent instances | |||
intain connectivity and interoperability to provide a single, cohesive service. | that maintain connectivity and interoperability to provide a single cohesive ser | |||
Federation promises to allow users to choose the instance they associate with an | vice. Federation promises to allow users to choose the instance they associate w | |||
d accommodates substitution of one instance for another, lowering switching cost | ith and accommodates substitution of one instance for another, lowering switchin | |||
s.</t> | g costs.</t> | |||
<t>However, federation alone is insufficient to prevent or mitigate ce | <t>However, federation alone is insufficient to prevent or mitigate ce | |||
ntralization of a function, because non-technical factors can create pressure to | ntralization of a function because non-technical factors can create pressure to | |||
use a central solution.</t> | use a central solution.</t> | |||
<t>For example, the e-mail suite of protocols needs to route messages | <t>For example, the email suite of protocols needs to route messages t | |||
to a user even when that user changes network locations or becomes disconnected | o a user even when that user changes network locations or becomes disconnected f | |||
for a long period. To facilitate this, SMTP <xref target="RFC5321"/> defines a s | or a long period. To facilitate this, SMTP <xref target="RFC5321"/> defines a sp | |||
pecific role for routing users' messages, the Message Transfer Agent (MTA). By a | ecific role for routing users' messages, the Message Transfer Agent (MTA). By al | |||
llowing anyone to deploy an MTA and defining rules for interconnecting them, the | lowing 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 | protocol avoids a requirement for a single central server in that role; users ca | |||
can (and often do) choose to delegate it to someone else, or can run their own M | n (and often do) choose to delegate it to someone else or they can run their own | |||
TA.</t> | MTA.</t> | |||
<t>Running one's own MTA has become considerably more onerous over the | <t>Running one's own MTA has become considerably more onerous over the | |||
years, due in part to the increasingly complex mechanisms introduced to fight u | years due, in part, to the increasingly complex mechanisms introduced to fight | |||
nwanted commercial e-mail. These costs create an incentive to delegate one's MT | unwanted commercial emails. These costs create an incentive to delegate one's M | |||
A to a third party who has the appropriate expertise and resources, contributing | TA to a third party who has the appropriate expertise and resources, contributin | |||
to market concentration. <xref target="DELIVERABILITY"/></t> | g to market concentration <xref target="DELIVERABILITY"/>.</t> | |||
<t>Additionally, the measures that MTAs use to identify unwanted comme | <t>Additionally, the measures that MTAs use to identify unwanted comme | |||
rcial e-mail are often site-specific. Because large MTAs handle so many more add | rcial emails are often site specific. Because large MTAs handle so many more add | |||
resses, there is a power imbalance with smaller ones; if a large MTA decides tha | resses, there is a power imbalance with smaller ones; if a large MTA decides tha | |||
t e-mail from a small one is unwanted, there is significant impact on its abilit | t email from a small one is unwanted, there is significant impact on its ability | |||
y to function, and little recourse.</t> | to function and little recourse.</t> | |||
<t>XMPP <xref target="RFC6120"/> is a chat protocol that demonstrates | <t>The Extensible Messaging and Presence Protocol (XMPP) <xref target= | |||
another issue with federation: the voluntary nature of technical standards.</t> | "RFC6120"/> is a chat protocol that demonstrates another issue with federation: | |||
<t>Like e-mail, XMPP is federated to facilitate rendezvous of users fr | the voluntary nature of technical standards.</t> | |||
om different systems - if they allow it. While some XMPP deployments do support | <t>Like email, XMPP is federated to facilitate the rendezvous of users | |||
truly federated messaging (i.e., a person using service A can interoperably chat | from different systems - if they allow it. While some XMPP deployments do suppo | |||
with someone using service B), many of the largest do not. Because federation i | rt truly federated messaging (i.e., a person using service A can interoperably c | |||
s voluntary, some operators captured their users into a single service, delibera | hat with someone using service B), many of the largest do not. Because federatio | |||
tely denying them the benefits of global interoperability.</t> | n is voluntary, some operators captured their users into a single service, delib | |||
erately denying them the benefits of global interoperability.</t> | ||||
<t>The examples above illustrate that, while federation can create the conditions necessary for a function to be decentralized, it does not guarantee that outcome.</t> | <t>The examples above illustrate that, while federation can create the conditions necessary for a function to be decentralized, it does not guarantee that outcome.</t> | |||
</section> | </section> | |||
<section anchor="distributed"> | <section anchor="distributed"> | |||
<name>Distributed Consensus</name> | <name>Distributed Consensus</name> | |||
<t>Increasingly, distributed consensus technologies (such as the block | <t>Increasingly, distributed consensus technologies (such as a blockch | |||
chain) are touted as a solution to centralization. A complete survey of this rap | ain) are touted as a solution to centralization. A complete survey of this rapid | |||
idly changing area is beyond the scope of this document, but we can generalize a | ly changing area is beyond the scope of this document, but we can generalize abo | |||
bout its properties.</t> | ut its properties.</t> | |||
<t>These techniques attempt to avoid centralization by distributing th | <t>These techniques typically guarantee proper performance of a functi | |||
e operation of a function to members of a sometimes large pool of protocol parti | on using cryptographic techniques (often, an append-only transaction ledger). Th | |||
cipants. Usually, the participants are unknown and untrusted, and a particular t | ey attempt to avoid centralization by distributing the operation of a function t | |||
ask's assignment to a node for handling cannot be predicted or controlled. They | o members of a sometimes large pool of protocol participants. Usually, the parti | |||
typically guarantee proper performance of a function using cryptographic techniq | cipants are unknown and untrusted, and a particular task's assignment to a node | |||
ues (often, an append-only transaction ledger).</t> | for handling cannot be predicted or controlled.</t> | |||
<t>Sybil attacks (where a party or coordinated parties cheaply create | <t>Sybil attacks (where a party or coordinated parties cheaply create | |||
enough protocol participants to affect how consensus is judged) are a major conc | enough protocol participants to affect how consensus is judged) are a major conc | |||
ern for these protocols, because it would have the effect of concentrating power | ern for these protocols because they would have the effect of concentrating powe | |||
into the hands of the attacker. Therefore, they encourage diversity in the pool | r into the hands of the attacker. Therefore, they encourage diversity in the poo | |||
of participants using indirect techniques, such as proof-of-work (where each pa | l of participants using indirect techniques, such as proof-of-work (where each p | |||
rticipant has to show a significant consumption of resources) or proof-of-stake | articipant has to show a significant consumption of resources) or proof-of-stake | |||
(where each participant has some other incentive to execute correctly).</t> | (where each participant has some other incentive to execute correctly).</t> | |||
<t>While these measures can be effective in decentralizing a function' | <t>While these measures can be effective in decentralizing a function' | |||
s operation, other aspects of its provision can still be centralized; for exampl | s operation, other aspects of its provision can still be centralized: for exampl | |||
e, governance of its design, creation of shared implementations, and documentati | e, governance of its design, creation of shared implementations, and documentati | |||
on of wire protocols. That need for coordination is an avenue for centralization | on of wire protocols. That need for coordination is an avenue for centralization | |||
even when the function's operation remains decentralized. For example, the Ethe | even when the function's operation remains decentralized. For example, the Ethe | |||
reum "merge" demonstrated that the blockchain could address environmental concer | reum "merge" demonstrated that the blockchain could address environmental concer | |||
ns, but only through coordinated community effort and governance -- coordination | ns but only through coordinated community effort and governance: coordination th | |||
that was benign in most eyes, but nevertheless centralized. <xref target="ETHER | at was benign in most eyes but, nevertheless, centralized <xref target="ETHEREUM | |||
EUM"/></t> | "/>.</t> | |||
<t>Furthermore, a protocol or an application composed of many function | <t>Furthermore, a protocol or an application composed of many function | |||
s can use distributed consensus for some, but still be centralized elsewhere -- | s can use distributed consensus for some but still be centralized elsewhere -- e | |||
either because those other functions cannot be decentralized (most commonly, ren | ither because those other functions cannot be decentralized (most commonly, rend | |||
dezvous and global naming; see <xref target="necessary"/>) or because the design | ezvous and global naming; see <xref target="necessary"/>) or because the designe | |||
er has chosen not to because of the associated costs and lost opportunities.</t> | r has chosen not to because of the associated costs and lost opportunities.</t> | |||
<t>These potential shortcomings do not rule out the use of distributed | <t>These potential shortcomings do not rule out the use of distributed | |||
consensus technologies in every instance, but they do merit caution against unc | consensus technologies in every instance, but they do merit caution against unc | |||
ritically relying upon these technologies to avoid or mitigate centralization. T | ritically relying upon these technologies to avoid or mitigate centralization. T | |||
oo often, the use of distributed consensus is perceived as imbuing all parts of | oo often, the use of distributed consensus is perceived as imbuing all parts of | |||
a project with "decentralization."</t> | a project with "decentralization".</t> | |||
</section> | </section> | |||
<section anchor="multi"> | <section anchor="multi"> | |||
<name>Operational Governance</name> | <name>Operational Governance</name> | |||
<t>Federation and distributed consensus can both create the conditions | <t>Federation and distributed consensus can both create the conditions | |||
for the provision of a function by multiple providers, but cannot guarantee it. | for the provision of a function by multiple providers, but they cannot guarante | |||
However, when providers require access to a resource or cooperation of others t | e it. However, when providers require access to a resource or cooperation of oth | |||
o provide that service, that choke point can itself be used to influence provide | ers to provide that service, that choke point can itself be used to influence pr | |||
r behaviour -- including in ways that can counteract centralization.</t> | ovider behavior -- including in ways that can counteract centralization.</t> | |||
<t>In these circumstances, some form of governance over that choke poi | <t>In these circumstances, some form of governance over that choke poi | |||
nt is necessary to assure the desired outcome. Often, this is through the establ | nt is necessary to assure the desired outcome. Often, this is through the establ | |||
ishment of a multi-stakeholder body: an institution that includes representative | ishment of a multi-stakeholder body, which is an institution that includes repre | |||
s of the different kinds of parties that are affected by the system's operation | sentatives of the different kinds of parties that are affected by the system's o | |||
("stakeholders") in an attempt to make well-reasoned, legitimate, and authoritat | peration ("stakeholders") in an attempt to make well-reasoned, legitimate, and a | |||
ive decisions.</t> | uthoritative decisions.</t> | |||
<t>The most widely studied example of this technique is the governance | <t>A widely studied example of this technique is the governance of the | |||
of the DNS name space, which as a “single source of truth” exhibits centralizat | DNS name space, which exhibits centralization as a “single source of truth” <xr | |||
ion. That source of truth is overseen by <eref target="https://www.icann.org/res | ef target="CENTRALIZATION"/>. That source of truth is overseen by the Internet C | |||
ources/pages/governance/governance-en">the Internet Corporation for Assigned Nam | orporation for Assigned Names and Numbers (ICANN) <eref target="https://www.ican | |||
es and Numbers (ICANN)</eref>, a global multi-stakeholder body with representati | n.org/resources/pages/governance/governance-en" brackets="angle"></eref>, a glob | |||
on from end users, governments, operators, and others.</t> | al multi-stakeholder body with representation from end users, governments, opera | |||
<t>Another example is the governance of the Web's trust model, impleme | tors, and others.</t> | |||
nted by Web browsers as relying parties that have strong incentives to protect u | <t>Another example is the governance of the Web's trust model, impleme | |||
ser privacy and security, and Certificate Authorities (CAs) as trust anchors tha | nted by web browsers as relying parties that have strong incentives to protect u | |||
t have a strong incentive to be included in browser trust stores. To promote the | ser privacy and security and CAs as trust anchors that have a strong incentive t | |||
operational and security requirements necessary to provide the desired properti | o be included in browser trust stores. To promote the operational and security r | |||
es, the <eref target="https://cabforum.org">CA/Browser Forum</eref> was establis | equirements necessary to provide the desired properties, the CA/Browser Forum <e | |||
hed as an oversight body that involves both parties as stakeholders.</t> | ref target="https://cabforum.org" brackets="angle"></eref> was established as an | |||
oversight body that involves both parties as stakeholders.</t> | ||||
<t>These examples are notable in that the governance mechanism is not specified in the protocol documents directly; rather, they are layered on operat ionally, but in a manner that takes advantage of protocol features that enable t he imposition of governance.</t> | <t>These examples are notable in that the governance mechanism is not specified in the protocol documents directly; rather, they are layered on operat ionally, but in a manner that takes advantage of protocol features that enable t he imposition of governance.</t> | |||
<t>Governance in this manner is suited to very limited functions like the examples above. Even then, setup and ongoing operation of a governance mecha nism is not trivial, and their legitimacy may be difficult to establish and main tain (see, e.g., <xref target="MULTISTAKEHOLDER"/>); by their nature, they are v ulnerable to capture by the interests that are being governed.</t> | <t>Governance in this manner is suited to very limited functions like the examples above. Even then, the setup and ongoing operation of a governance m echanism is not trivial, and their legitimacy may be difficult to establish and maintain (e.g., see <xref target="MULTISTAKEHOLDER"/>); by their nature, they ar e vulnerable to capture by the interests that are being governed.</t> | |||
</section> | </section> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="considerations"> | <section anchor="considerations"> | |||
<name>What Can Internet Standards Do?</name> | <name>What Can Internet Standards Do?</name> | |||
<t>Given the limits of decentralization techniques like federation and dis tributed consensus, the voluntary nature of standards compliance, and the powerf ul forces that can drive centralization, it is reasonable to ask what standards efforts like those at the IETF can do to accommodate helpful centralization whil e avoiding the associated harms -- while acknowledging that the distinction itse lf is a judgment call, and inherently political.</t> | <t>Given the limits of decentralization techniques like federation and dis tributed consensus, the voluntary nature of standards compliance, and the powerf ul forces that can drive centralization, it is reasonable to ask what standards efforts like those at the IETF can do to accommodate helpful centralization whil e avoiding the associated harms and acknowledging that the distinction itself is a judgment call and, therefore, inherently political.</t> | |||
<t>The subsections below suggest a few concrete, meaningful steps that sta ndards bodies can take.</t> | <t>The subsections below suggest a few concrete, meaningful steps that sta ndards bodies can take.</t> | |||
<section anchor="legitimate"> | <section anchor="legitimate"> | |||
<name>Bolster Legitimacy</name> | <name>Bolster Legitimacy</name> | |||
<t>Where technical standards have only limited ability to control centra lization of the Internet, legal standards (whether regulation, legislation, or c ase 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 .</t> | <t>Where technical standards have only limited ability to control centra lization of the Internet, legal standards (whether regulation, legislation, or c ase 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.< /t> | |||
<t>That viewpoint can and should be provided by the Internet standards c ommunity. To effectively do so, its institutions must be seen as legitimate by t he relevant parties -- for example, competition regulators. If the IETF is perce ived 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 dimi nished considerably.</t> | <t>That viewpoint can and should be provided by the Internet standards c ommunity. To effectively do so, its institutions must be seen as legitimate by t he relevant parties -- for example, competition regulators. If the IETF is perce ived 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 dimi nished considerably.</t> | |||
<t>The IETF already has features that arguably provide considerable legi | <t>The IETF already has features that arguably provide considerable legi | |||
timacy; for example, open participation and representation by individuals rather | timacy. Examples of these features include open participation and representatio | |||
than companies both enhance input legitimacy; a well-defined process with multi | n by individuals rather than by companies, both of which enhance input legitimac | |||
ple layers of appeals and transparency contributes to throughput legitimacy, and | y); a well-defined process with multiple layers of appeals and transparency, whi | |||
a long history of successful Internet standards provides perhaps the strongest | ch contributes to throughput legitimacy; and a long history of successful Intern | |||
source of legitimacy for the IETF -- its output.</t> | et standards, which provides perhaps the strongest source of legitimacy for the | |||
<t>However, it is also widely recognized the considerable costs (not jus | IETF -- its output.</t> | |||
t financial) involved in successfully participating in the IETF have a tendency | <t>However, it is also widely recognized that the considerable costs (no | |||
to favour larger companies over smaller concerns. Additionally, the specialised | t just financial) involved in successfully participating in the IETF have a tend | |||
and highly technical nature of the work creates barriers to entry for non-techni | ency to favor larger companies over smaller concerns. Additionally, the speciali | |||
cal stakeholders. These factors have the potential to reduce the legitimacy of t | zed and highly technical nature of the work creates barriers to entry for non-te | |||
he IETF's decisions, at least in some eyes.</t> | chnical stakeholders. These factors have the potential to reduce the legitimacy | |||
<t>Efforts to address these shortcomings are ongoing; see, for example, | of the IETF's decisions, at least in some eyes.</t> | |||
<xref target="RFC8890"/>. Overall, bolstering the legitimacy of the organization | <t>Efforts to address these shortcomings are ongoing; for example, see < | |||
should be seen as a continuous effort.</t> | xref target="RFC8890"/>. Overall, bolstering the legitimacy of the organization | |||
<t>When engaging in external efforts, the IETF community (especially, it | should be seen as a continuous effort.</t> | |||
s leadership) should keep firmly in mind that its voice is most authoritative wh | <t>When engaging in external efforts, the IETF community (especially its | |||
en focused on technical and architectural impact.</t> | leadership) should keep firmly in mind that its voice is most authoritative whe | |||
n focused on technical and architectural impact.</t> | ||||
</section> | </section> | |||
<section anchor="target"> | <section anchor="target"> | |||
<name>Focus Discussion of Centralization</name> | <name>Focus Discussion of Centralization</name> | |||
<t>Centralization and decentralization are increasingly being raised in technical standards discussions. Any claim needs to be critically evaluated: as discussed in <xref target="centralization"/>, not all centralization is automati cally harmful, and per <xref target="decentralization"/>, decentralization techn iques do not automatically address all centralization harms -- and they may brin g their own risks.</t> | <t>Centralization and decentralization are increasingly being raised in technical standards discussions. Any claim needs to be critically evaluated. As discussed in <xref target="centralization"/>, not all centralization is automat ically harmful. Per <xref target="decentralization"/>, decentralization techniqu es do not automatically address all centralization harms and may bring their own risks.</t> | |||
<t>However, standards participants rarely have the expertise or informat ion available to completely evaluate those claims, because the analysis involves not only technical factors, but also economic, social, commercial, and legal as pects. For example, economies of scale can cause concentration due to the associ ated efficiencies <xref target="SCALE"/>, and so determining whether that concen tration is appropriate requires a detailed economic analysis that is not in scop e for a technical standards body. Furthermore, claims of centralization may have other motivations; in particular, they can be proxies for power struggles betwe en 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.</t> | <t>However, standards participants rarely have the expertise or informat ion available to completely evaluate those claims, because the analysis involves not only technical factors, but also economic, social, commercial, and legal as pects. For example, economies of scale can cause concentration due to the associ ated efficiencies <xref target="SCALE"/>, and so determining whether that concen tration is appropriate requires a detailed economic analysis that is not in scop e for a technical standards body. Furthermore, claims of centralization may have other motivations; in particular, they can be proxies for power struggles betwe en 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.</t> | |||
<t>Therefore, approaches like requiring a "Centralization Considerations | <t>Therefore, approaches like requiring a "Centralization Considerations | |||
" section in drafts, gatekeeping publication on a centralization review, or comm | " section in documents, gatekeeping publication on a centralization review, or c | |||
itting significant resources to searching for centralization in protocols are un | ommitting significant resources to searching for centralization in protocols are | |||
likely to improve the Internet.</t> | unlikely to improve the Internet.</t> | |||
<t>Similarly, refusing to standardize a protocol because it does not act | <t>Similarly, refusing to standardize a protocol because it does not act | |||
ively prevent all forms of centralization ignores the very limited power that st | ively prevent all forms of centralization ignores the very limited power that st | |||
andards efforts have to do so. Almost all existing Internet protocols -- includi | andards efforts have to do so. Almost all existing Internet protocols -- includi | |||
ng IP, TCP, HTTP, and DNS -- fail to prevent centralized applications from using | ng IP, TCP, HTTP, and DNS -- fail to prevent centralized applications from using | |||
them. While the imprimatur of an Internet Standard is not without value, merely | them. While the imprimatur of the standards track <xref target="RFC2026"/> is n | |||
withholding it cannot prevent centralization.</t> | ot without value, merely withholding it cannot prevent centralization.</t> | |||
<t>Discussions should thus be very focused and limited, and any proposal | <t>Thus, discussions should be very focused and limited, and any proposa | |||
s for decentralization should be detailed, so their full effects can be evaluate | ls for decentralization should be detailed so their full effects can be evaluate | |||
d. <xref target="SCHNEIDER"/> implores that proposals to decentralize be "really | d. <xref target="SCHNEIDER"/> implores those who propose decentralization to be | |||
, really clear about what particular features of a system a given design seeks t | "really, really clear about what particular features of a system a given design | |||
o decentralize" and promotes borrowing remedies from more traditional governance | seeks to decentralize" and promotes considered use of tools like separation of p | |||
systems, such as separation of powers and accountability.</t> | owers and accountability from "old, institutional liberal political theory".</t> | |||
<t>When evaluating claims that a given proposal is centralized, the cont | <t>When evaluating claims that a given proposal is centralized, the cont | |||
ext of those statements should be examined for presuppositions, assumptions, and | ext of those statements should be examined for presuppositions, assumptions, and | |||
omissions. One framework for critical interrogations is offered by <xref target | omissions. <xref target="BACCHI"/> offers one framework for critical interrogat | |||
="BACCHI"/>, which can be adapted for centralization-related discussions:</t> | ions, which can be adapted for centralization-related discussions:</t> | |||
<ol spacing="normal" type="1"><li>What is the nature of the centralizati | <ol spacing="normal" type="1"><li> | |||
on that is represented as being problematic?</li> | <t>What is the nature of the centralization that is represented as b | |||
<li>What deep-seated presuppositions or assumptions (conceptual logics | eing problematic?</t> | |||
) underlie this representation of the "problem"?</li> | </li> | |||
<li>How has this representation of the problem come about?</li> | <li> | |||
<li>What is left unproblematic in this problem representation? Where a | <t>What deep-seated presuppositions or assumptions (conceptual logic | |||
re the silences? Can the "problem" be conceptualized differently?</li> | s) underlie this representation of the "problem"?</t> | |||
<li>What effects are produced by this representation of the “problem”? | </li> | |||
</li> | <li> | |||
<li>How and where has this representation of the “problem” been produc | <t>How has this representation of the problem come about?</t> | |||
ed, disseminated, and defended? How has it been and/or how can it be disrupted a | </li> | |||
nd replaced?</li> | <li> | |||
<t>What is left unproblematic in this problem representation? Where | ||||
are the silences? Can the "problem" be conceptualized differently?</t> | ||||
</li> | ||||
<li> | ||||
<t>What effects are produced by this representation of the “problem” | ||||
?</t> | ||||
</li> | ||||
<li> | ||||
<t>How and where has this representation of the “problem” been produ | ||||
ced, disseminated, and defended? How has it been and/or how can it be disrupted | ||||
and replaced?</t> | ||||
</li> | ||||
</ol> | </ol> | |||
</section> | </section> | |||
<section anchor="up"> | <section anchor="up"> | |||
<name>Target Proprietary Functions</name> | <name>Target Proprietary Functions</name> | |||
<t>Functions that are widely used but lacking in interoperability are ri | <t>Functions that are widely used but lacking in interoperability are ri | |||
pe for standardisation efforts. Targeting prominent and proprietary functions (e | pe for standardization efforts. Targeting prominent and proprietary functions (e | |||
.g., chat) is appropriate, but so are smaller efforts to improve interoperabilit | .g., chat) is appropriate, but so are smaller efforts to improve interoperabilit | |||
y and portability of specific features that are often used to lock users into a | y 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.</t> | platform, for example, a format for lists of contacts in a social network.</t> | |||
<t>A common objection to this approach is that adoption is voluntary; th | <t>A common objection to this approach is that adoption is voluntary; th | |||
ere are no "standards police" to mandate their use or enforce correct implementa | ere are no "standards police" to mandate their use or enforce correct implementa | |||
tion. For example, specifications like <xref target="ACTIVITYSTREAMS"/>) were av | tion. For example, specifications like <xref target="ACTIVITYSTREAMS"/> were ava | |||
ailable for some time without being used in a federated manner by commercial soc | ilable for some time without being used in a federated manner by commercial soci | |||
ial networking providers.</t> | al-networking providers.</t> | |||
<t>That objection ignores that while standards aren't mandatory, legal r | <t>That objection ignores the fact that while standards aren't mandatory | |||
egulation is. Legal mandates for interoperability are increasingly proposed by p | , legal regulation is. Legal mandates for interoperability are increasingly prop | |||
olicymakers as a remedy for competition issues (see, e.g., <xref target="DMA"/>) | osed by policymakers as a remedy for competition issues (e.g., see <xref target= | |||
. This appetite for regulation presents an opportunity for new specifications to | "DMA"/>). This appetite for regulation presents an opportunity for new specifica | |||
decentralize these functions, backed by a legal mandate in combination with cha | tions to decentralize these functions, backed by a legal mandate in combination | |||
nging norms and the resulting market forces <xref target="NEW-CHICAGO"/>.</t> | with changing norms and the resulting market forces <xref target="NEW-CHICAGO"/> | |||
<t>That opportunity also presents a risk, if the resulting legal regulat | .</t> | |||
ion is at odds with the Internet architecture. Successfully creating standards t | <t>That opportunity also presents a risk, if the resulting legal regulat | |||
hat work in concert with legal regulation presents many potential pitfalls, and | ion is at odds with the Internet architecture. Successfully creating standards t | |||
will require improved and new capabilities (especially liaison), and considerabl | hat work in concert with legal regulation presents many potential pitfalls and w | |||
e effort. If the Internet community does not make that effort, it is likely that | ill require new and improved capabilities (especially liaison) and considerable | |||
regulators will turn to other sources for interoperability specifications.</t> | effort. If the technical community does not make that effort, it is likely that | |||
regulators will turn to other sources for interoperability specifications.</t> | ||||
</section> | </section> | |||
<section anchor="switch"> | <section anchor="switch"> | |||
<name>Enable Switching</name> | <name>Enable Switching</name> | |||
<t>The ability to switch between different function providers is a core | <t>The ability to switch between different function providers is a core | |||
mechanism to control centralization. If users are unable to switch they cannot e | mechanism to control centralization. If users are unable to switch, they cannot | |||
xercise choice or fully realize the value of their efforts, because, for example | 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 | , "learning to use a vendor's product takes time, and the skill may not be fully | |||
transferrable to a competitor's product if there is inadequate standardization. | transferable to a competitor's product if there is inadequate standardization" | |||
" <xref target="SWITCHING"/></t> | <xref target="SWITCHING"/>.</t> | |||
<t>Therefore, standards should have an explicit goal of facilitating use | <t>Therefore, standards should have an explicit goal of facilitating use | |||
rs' switching between implementations and deployments of the functions they defi | rs switching between implementations and deployments of the functions they defin | |||
ne or enable.</t> | e or enable.</t> | |||
<t>One necessary condition for switching is the availability of alternat | <t>One necessary condition for switching is the availability of alternat | |||
ives; breadth and diversity of implementation and deployment are required. For e | ives; breadth and diversity of implementation and deployment are required. For e | |||
xample, if there is only a single implementation of a protocol, applications tha | xample, if there is only a single implementation of a protocol, applications tha | |||
t use it are vulnerable to the control it has over their operation. Even Open So | t use it are vulnerable to the control it has over their operation. Even open so | |||
urce projects can be an issue in this regard if there are factors that make fork | urce projects can be an issue in this regard if there are factors that make fork | |||
ing difficult (for example, the cost of maintaining that fork). <xref section="2 | ing difficult (for example, the cost of maintaining that fork). <xref section="2 | |||
.1" sectionFormat="of" target="RFC5218"/> explores some factors in protocol desi | .1" sectionFormat="of" target="RFC5218"/> explores some factors in protocol desi | |||
gn that encourage diversity of implementation.</t> | gn that encourage diversity of implementation.</t> | |||
<t>The cost of substituting an alternative implementation or deployment by users is another important factor to consider. This includes minimizing the a mount of time, resources, expertise, coordination, loss of functionality, and ef fort required to use a different provider or implementation -- with the implicat ion that the standard needs to be functionally complete and specified precisely enough to allow substitution.</t> | <t>The cost of substituting an alternative implementation or deployment by users is another important factor to consider. This includes minimizing the a mount of time, resources, expertise, coordination, loss of functionality, and ef fort required to use a different provider or implementation -- with the implicat ion that the standard needs to be functionally complete and specified precisely enough to allow substitution.</t> | |||
<t>These goals of completeness and diversity are sometimes in tension. I | <t>These goals of completeness and diversity are sometimes at odds. If a | |||
f a standard becomes extremely complex, it may discourage implementation diversi | standard becomes extremely complex, it may discourage implementation diversity | |||
ty because the cost of a complete implementation is too high (consider: Web brow | because the cost of a complete implementation is too high (consider web browsers | |||
sers). On the other hand, if the specification is too simple, it may not enable | ). On the other hand, if the specification is too simple, it may not enable easy | |||
easy switching, especially if proprietary extensions are necessary to complete i | switching, especially if proprietary extensions are necessary to complete it (s | |||
t (see <xref target="evolution"/>).</t> | ee <xref target="evolution"/>).</t> | |||
<t>One objection to protocols that enable easy switching is that they re | <t>One objection to protocols that enable easy switching is that they re | |||
duce the incentives for implementation by commercial vendors. While a completely | duce the incentives for implementation by commercial vendors. While a completely | |||
commoditized protocol might not allow implementations to differentiate themselv | commoditized protocol might not allow implementations to differentiate themselv | |||
es, they provide opportunities for specialization and improvement elsewhere in t | es, they provide opportunities for specialization and improvement elsewhere in t | |||
he value chain <xref target="ATTRACTIVE-PROFITS"/>. Well-timed standards efforts | he value chain <xref target="ATTRACTIVE-PROFITS"/>. Well-timed standards efforts | |||
leverage these forces to focus proprietary interests on top of open technology, | leverage these forces to focus proprietary interests on top of open technology | |||
rather than as a replacement for it.</t> | rather than as a replacement for it.</t> | |||
</section> | </section> | |||
<section anchor="intermediation"> | <section anchor="intermediation"> | |||
<name>Control Delegation of Power</name> | <name>Control Delegation of Power</name> | |||
<t>The users of some functions might realize substantial benefits if the y are provided by a third party in communication. Adding a new party to communic ation can improve:</t> | <t>The users of some functions might realize substantial benefits if the y are provided by a third party in communication. Adding a new party to communic ation can improve the following:</t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
<em>Efficiency</em>: Many functions on the Internet are more efficie | <t><em>Efficiency</em>: Many functions on the Internet are more effi | |||
nt when performed at a higher scale. For example, a content delivery network can | cient when performed at a higher scale. For example, a content delivery network | |||
offer services at a fraction of the financial and environmental cost that someo | can offer services at a fraction of the financial and environmental cost that so | |||
ne serving content themselves would otherwise pay, because of the scale they ope | meone serving content themselves would otherwise pay because of the scale they o | |||
rate at. Likewise, a two-sided market platform can introduce sizeable efficienci | perate at. Likewise, a two-sided market platform can introduce sizable efficienc | |||
es over pair-wise buyer/seller trading <xref target="CIRCULAR-CONUNDRUM"/>.</li> | ies over pair-wise buyer/seller trading <xref target="CIRCULAR-CONUNDRUM"/>.</t> | |||
</li> | ||||
<li> | <li> | |||
<em>Simplicity</em>: Completely disintermediating communication can | <t><em>Simplicity</em>: Completely disintermediating communication c | |||
shift the burden of functions onto endpoints. This can cause increased cognitive | an shift the burden of functions onto endpoints. This can cause increased cognit | |||
load for users; for example, compare commercial social networking platforms wit | ive load for users; for example, compare commercial social-networking platforms | |||
h self-hosted efforts.</li> | with self-hosted efforts.</t> | |||
</li> | ||||
<li> | <li> | |||
<em>Specialization</em>: Having a function consolidated into a few h | <t><em>Specialization</em>: Having a function consolidated into a fe | |||
ands can improve outcomes because of the resulting specialization. For example, | w hands can improve outcomes because of the resulting specialization. For exampl | |||
services overseen by professional administrators are often seen to have a better | e, services overseen by professional administrators are often seen to have a bet | |||
security posture and improved availability.</li> | ter security posture and improved availability.</t> | |||
</li> | ||||
<li> | <li> | |||
<em>Privacy</em>: For some functions, user privacy can be improved b | <t><em>Privacy</em>: For some functions, user privacy can be improve | |||
y consolidating their activity to prevent individual behaviors from being discri | d by consolidating their activity to prevent individual behaviors from being dis | |||
minated from each other.<xref target="MIX"/> Introduction of a third party can a | criminated from each other <xref target="MIX"/>. Introduction of a third party c | |||
lso enforce functional boundaries -- for example, to reduce the need for users t | an also enforce functional boundaries -- for example, to reduce the need for use | |||
o trust potentially malicious endpoints, as seen in the so-called “oblivious” pr | rs to trust potentially malicious endpoints, as seen in the so-called “oblivious | |||
otocols (e.g., <xref target="RFC9230"/>) that allow end users to hide their iden | ” protocols (e.g., <xref target="RFC9230"/>) that allow end users to hide their | |||
tity from services, while still accessing them.</li> | identity from services while still accessing them.</t> | |||
</li> | ||||
</ul> | </ul> | |||
<t>However, if that new party is able to make their participation "stick y" -- 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 centralizat ion.</t> | <t>However, if that new party is able to make their participation "stick y" -- 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 centralizat ion.</t> | |||
<t>Most often, third parties are added to functions as "intermediaries" or in designated "agent" roles. Designing such functions with thoughtful constra ints on these roles can prevent at least the most egregious abuses of such power .</t> | <t>Most often, third parties are added to functions as "intermediaries" or in designated "agent" roles. Designing such functions with thoughtful constra ints on these roles can prevent at least the most egregious abuses of such power .</t> | |||
<t>When adding new parties to a function, two guidelines have proven use | <t>When adding new parties to a function, two guidelines have proven use | |||
ful: first, third parties should only be interposed into communication when at l | ful. First, third parties should only be interposed into communication when at | |||
east one of the primary parties takes a positive action to do so. Second, third | 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 | parties should have their ability to observe or control communication limited t | |||
what is necessary to perform their intended function.</t> | o what is necessary to perform their intended function.</t> | |||
<t>For example, early deployments of HTTP allowed intermediaries to be i | <t>For example, early deployments of HTTP allowed intermediaries to be i | |||
nterposed by the network without knowledge of the endpoints, and those intermedi | nterposed by the network without knowledge of the endpoints, and those intermedi | |||
aries could see and change the full content of traffic by default -- even when t | aries could see and change the full content of traffic by default -- even when t | |||
hey are only intended to perform basic functions such as caching. Because of the | hey were only intended to perform basic functions such as caching. Because of th | |||
introduction of HTTPS and the CONNECT method (see <xref section="9.3.6" section | e introduction of HTTPS and the CONNECT method (see <xref section="9.3.6" sectio | |||
Format="of" target="HTTP"/>), combined with efforts to encourage its adoption, t | nFormat="of" target="RFC9110"/>), combined with efforts to encourage its adoptio | |||
hose intermediaries are now required to be explicitly interposed by one endpoint | n, those intermediaries are now required to be explicitly interposed by one endp | |||
, and they only have access to basic routing information.</t> | oint, and they only have access to basic routing information.</t> | |||
<t>See <xref target="I-D.thomson-tmi"/> for more guidance on protocol in termediation.</t> | <t>See <xref target="I-D.thomson-tmi"/> for more guidance on protocol in termediation.</t> | |||
<t>The term "intermediary" is also used (often in legal and regulatory c ontexts) more broadly than it has been in protocol design; for example, an aucti on Web site intermediates between buyers and sellers is considered an intermedia ry, even though it is not formally an intermediary in HTTP (see <xref section="3 .7" sectionFormat="of" target="HTTP"/>). Protocol designers can address the cent ralization associated with this kind of intermediation by standardising the func tion, rather than restricting the capabilities of the underlying protocols; see <xref target="up"/>.</t> | <t>The term "intermediary" is also used (often in legal and regulatory c ontexts) more broadly than it has been in protocol design; for example, an aucti on website that intermediates between buyers and sellers is considered an interm ediary, even though it is not formally an intermediary in HTTP (see <xref sectio n="3.7" sectionFormat="of" target="RFC9110"/>). Protocol designers can address t he centralization associated with this kind of intermediation by standardizing t he function rather than restricting the capabilities of the underlying protocols ; see <xref target="up"/>.</t> | |||
</section> | </section> | |||
<section anchor="network"> | <section anchor="network"> | |||
<name>Enforce Boundaries</name> | <name>Enforce Boundaries</name> | |||
<t>Most Internet protocols and applications depend on other, "lower-laye | <t>Most Internet protocols and applications depend on other, "lower-laye | |||
r" functions and their implementations. The features, deployment, and operation | r" functions and their implementations. The features, deployment, and operation | |||
of these dependencies can surface centralization into functions and applications | of these dependencies can become centralization risks for the functions and appl | |||
built "on top" of them.</t> | ications built "on top" of them.</t> | |||
<t>For example, application protocols require a network to function, and | <t>For example, application protocols require a network to function; the | |||
therefore a degree of power over communication is available to the network prov | refore, a degree of power over communication is available to the network provide | |||
ider. They might block access to, slow down, or change the content of a specific | r. They might block access to, slow down, or change the content of a specific se | |||
service for financial, political, operational, or criminal reasons, creating a | rvice for financial, political, operational, or criminal reasons, creating a dis | |||
disincentive (or even removing the ability) to use a specific provider of a func | incentive (or even removing the ability) to use a specific provider of a functio | |||
tion. By selectively hindering the use of some services but not others, network | n. By selectively hindering the use of some services but not others, network int | |||
interventions can be composed to create pressure to use those other services -- | erventions can be composed to create pressure to use those other services -- int | |||
intentionally or not.</t> | entionally or not.</t> | |||
<t>Techniques like encryption can discourage such centralization by enfo rcing 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 i t can be prevented from interfering with and observing it. Although those partie s might still prevent communication, encryption also makes it more difficult to discriminate a target from other users' traffic.</t> | <t>Techniques like encryption can discourage such centralization by enfo rcing 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 i t can be prevented from interfering with and observing it. Although those partie s might still prevent communication, encryption also makes it more difficult to discriminate a target from other users' traffic.</t> | |||
</section> | </section> | |||
<section anchor="evolution"> | <section anchor="evolution"> | |||
<name>Consider Extensibility Carefully</name> | <name>Consider Extensibility Carefully</name> | |||
<t>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 upgr ade implementations. Typically, functions accommodate evolution by defining exte nsion interfaces, which allow optional features to be added or change over time in an interoperable fashion.</t> | <t>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 upgr ade implementations. Typically, functions accommodate evolution by defining exte nsion interfaces, which allow optional features to be added or change over time in an interoperable fashion.</t> | |||
<t>However, these interfaces can also be leveraged by a powerful entity if they can change the target for meaningful interoperability by adding propriet ary extensions to a standard. This is especially true when the core standard doe s not itself provide sufficient utility on its own.</t> | <t>However, these interfaces can also be leveraged by a powerful entity if they can change the target for meaningful interoperability by adding propriet ary extensions to a standard. This is especially true when the core standard doe s not itself provide sufficient utility on its own.</t> | |||
<t>For example, the SOAP protocol's <xref target="SOAP"/> extreme flexib ility and failure to provide significant standalone value allowed vendors to req uire use of their preferred extensions, favoring those who had more market power .</t> | <t>For example, the extreme flexibility of SOAP <xref target="SOAP"/> an d its failure to provide significant standalone value allowed vendors to require use of their preferred extensions, favoring those who had more market power.</t > | |||
<t>Therefore, standards efforts should focus on providing concrete utili ty to the majority of their users as published, rather than being a “framework” where interoperability is not immediately available. Internet functions should n ot make every aspect of their operation extensible; boundaries between modules s hould be designed in a way that allows evolution, while still offering meaningfu l functionality.</t> | <t>Therefore, standards efforts should focus on providing concrete utili ty to the majority of their users as published, rather than being a “framework” where interoperability is not immediately available. Internet functions should n ot make every aspect of their operation extensible; boundaries between modules s hould be designed in a way that allows evolution, while still offering meaningfu l functionality.</t> | |||
<t>Beyond allowing evolution, well-considered interfaces can also aid de centralization efforts. The structural boundaries that emerge between the sub-mo dules of the function -- as well as those with adjacent functions -- provide tou chpoints for interoperability and an opportunity for substitution of providers.< /t> | <t>Beyond allowing evolution, well-considered interfaces can also aid de centralization efforts. The structural boundaries that emerge between the sub-mo dules of the function -- as well as those with adjacent functions -- provide tou chpoints for interoperability and an opportunity for substitution of providers.< /t> | |||
<t>In particular, if the interfaces of a function are well-defined and s table, there is an opportunity to use different providers for that function. Whe n those interfaces are open standards, change control resides with the Internet community instead of remaining in proprietary hands, further enhancing stability and enabling (but not ensuring) decentralization.</t> | <t>In particular, if the interfaces of a function are well-defined and s table, there is an opportunity to use different providers for that function. Whe n those interfaces are open standards, change control resides with the technical community instead of remaining in proprietary hands, further enhancing stabilit y and enabling (but not ensuring) decentralization.</t> | |||
</section> | </section> | |||
<section anchor="reuse"> | <section anchor="reuse"> | |||
<name>Reuse What Works</name> | <name>Reuse What Works</name> | |||
<t>When centralization is purposefully allowed in an Internet function, protocol designers often attempt to mitigate the associated risks using technica l measures such as federation (see <xref target="federation"/>) and operational governance structures (see <xref target="multi"/>).</t> | <t>When centralization is purposefully allowed in an Internet function, protocol designers often attempt to mitigate the associated risks using technica l measures such as federation (see <xref target="federation"/>) and operational governance structures (see <xref target="multi"/>).</t> | |||
<t>Protocols that successfully do so are often reused to avoid the consi derable cost and risk of re-implementing those mitigations. For example, if a pr otocol requires a coordinated, global naming function, incorporating the Domain Name System is usually preferable to establishing a new system.</t> | <t>Protocols that successfully do so are often reused to avoid the consi derable cost and risk of reimplementing those mitigations. For example, if a pro tocol requires a coordinated global naming function, incorporating the Domain Na me System is usually preferable to establishing a new system.</t> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="conclude"> | <section anchor="conclude"> | |||
<name>Future Work</name> | <name>Future Work</name> | |||
<t>This document has argued that while standards bodies have little means | <t>This document has argued that, while standards bodies have little means | |||
of effectively controlling or preventing centralization on the Internet through | of effectively controlling or preventing centralization of the Internet through | |||
protocol design, there are still concrete and useful steps they can take to impr | protocol design, there are still concrete and useful steps they can take to imp | |||
ove the Internet.</t> | rove the Internet.</t> | |||
<t>Those steps might be elaborated upon and extended in future work; doubt | <t>Those steps might be elaborated upon and extended in future work; howev | |||
less there is more that can be done. New decentralization techniques might be id | er, it is doubtless there is more that can be done. New decentralization techniq | |||
entified and examined; what we learn from relationships with other, more effecti | ues might be identified and examined; what we learn from relationships with othe | |||
ve regulators in this space can be documented.</t> | r, more effective regulators in this space can be documented.</t> | |||
<t>Some have suggested creating a how-to guide or checklist for dealing wi | <t>Some have suggested creating a how-to guide or checklist for dealing wi | |||
th centralization. Because centralization is so contextual and so varied in how | th centralization. Because centralization is so contextual and so varied in how | |||
it manifests, this might best be attempted within very limited areas; for exampl | it manifests, this might best be attempted within very limited areas -- for exam | |||
e, for a particular type of function, or a function at a particular layer.</t> | ple, for a particular type of function or a function at a particular layer.</t> | |||
<t>The nature of centralization also deserves further study; in particular | <t>The nature of centralization also deserves further study; in particular | |||
, its causes. While there is much commentary on factors like network effects and | , its causes. While there is much commentary on factors like network effects and | |||
switching costs, other aspects such as behavioural, cognitive, and social and e | switching costs, other aspects -- such as behavioral, cognitive, social, and ec | |||
conomic factors have received comparatively little attention, although that is c | onomic factors have received comparatively little attention, although that is ch | |||
hanging (e.g., <xref target="BEHAVIOUR"/>).</t> | anging (e.g., <xref target="BEHAVIOUR"/>).</t> | |||
</section> | </section> | |||
<section anchor="security-considerations"> | <section anchor="security-considerations"> | |||
<name>Security Considerations</name> | <name>Security Considerations</name> | |||
<t>This document does not have a direct security impact on Internet protoc ols. That said, failure to consider centralization might cause a myriad of secur ity issues; see <xref target="why"/> for a preliminary discussion.</t> | <t>This document does not have a direct security impact on Internet protoc ols. That said, failure to consider centralization might cause a myriad of secur ity issues; see <xref target="why"/> for a preliminary discussion.</t> | |||
</section> | </section> | |||
<section anchor="iana-considerations"> | ||||
<name>IANA Considerations</name> | ||||
<t>This document has no IANA actions.</t> | ||||
</section> | ||||
</middle> | </middle> | |||
<back> | <back> | |||
<displayreference target="RAND" to="Baran"/> | <displayreference target="RAND" to="Baran"/> | |||
<displayreference target="INTERMEDIARY-INFLUENCE" to="Judge"/> | ||||
<displayreference target="INTERDEPENDENCE" to="FarrellH"/> | <displayreference target="INTERDEPENDENCE" to="FarrellH"/> | |||
<displayreference target="MOXIE" to="Marlinspike"/> | <displayreference target="MOXIE" to="Marlinspike"/> | |||
<displayreference target="MULTISTAKEHOLDER" to="Palladino"/> | <displayreference target="MULTISTAKEHOLDER" to="Palladino"/> | |||
<displayreference target="NEW-CHICAGO" to="Lessig"/> | <displayreference target="NEW-CHICAGO" to="Lessig"/> | |||
<displayreference target="POLYCENTRIC" to="Aligia"/> | <displayreference target="POLYCENTRIC" to="Aligia"/> | |||
<displayreference target="ACCESS" to="Abrahamson"/> | <displayreference target="ACCESS" to="Abrahamson"/> | |||
<displayreference target="MIX" to="Chaum"/> | <displayreference target="MIX" to="Chaum"/> | |||
<displayreference target="FEDERALIST-51" to="Madison"/> | <displayreference target="FEDERALIST-51" to="Madison"/> | |||
<displayreference target="ATTRACTIVE-PROFITS" to="Christensen"/> | <displayreference target="ATTRACTIVE-PROFITS" to="Christensen"/> | |||
<displayreference target="CIRCULAR-CONUNDRUM" to="Spulber"/> | <displayreference target="CIRCULAR-CONUNDRUM" to="Spulber"/> | |||
skipping to change at line 281 ¶ | skipping to change at line 291 ¶ | |||
<displayreference target="STRUCTURELESS" to="Freeman"/> | <displayreference target="STRUCTURELESS" to="Freeman"/> | |||
<displayreference target="SCHNEIDER" to="Schneider1"/> | <displayreference target="SCHNEIDER" to="Schneider1"/> | |||
<displayreference target="BACCHI" to="Bacchi"/> | <displayreference target="BACCHI" to="Bacchi"/> | |||
<displayreference target="FB-INTERNET" to="Komaitis"/> | <displayreference target="FB-INTERNET" to="Komaitis"/> | |||
<displayreference target="DEPENDENCIES" to="Kashaf"/> | <displayreference target="DEPENDENCIES" to="Kashaf"/> | |||
<displayreference target="BEHAVIOUR" to="Fletcher"/> | <displayreference target="BEHAVIOUR" to="Fletcher"/> | |||
<displayreference target="DELIVERABILITY" to="Holzbauer"/> | <displayreference target="DELIVERABILITY" to="Holzbauer"/> | |||
<displayreference target="SWITCHING" to="FarrellJ"/> | <displayreference target="SWITCHING" to="FarrellJ"/> | |||
<displayreference target="SCALE" to="Demsetz"/> | <displayreference target="SCALE" to="Demsetz"/> | |||
<displayreference target="ADVERSARIAL" to="Doctorow"/> | <displayreference target="ADVERSARIAL" to="Doctorow"/> | |||
<references> | <displayreference target="RFC9110" to="HTTP"/> | |||
<displayreference target="I-D.thomson-tmi" to="THOMSON-TMI"/> | ||||
<displayreference target="CENTRALIZATION" to="Moura"/> | ||||
<references anchor="sec-informative-references"> | ||||
<name>Informative References</name> | <name>Informative References</name> | |||
<reference anchor="RAND" target="https://www.rand.org/pubs/research_memora nda/RM3420.html"> | <reference anchor="RAND" target="https://www.rand.org/pubs/research_memora nda/RM3420.html"> | |||
<front> | <front> | |||
<title>On Distributed Communications: Introduction to Distributed Comm unications Networks</title> | <title>On Distributed Communications: Introduction to Distributed Comm unications Networks</title> | |||
<author initials="P." surname="Baran" fullname="Paul Baran"> | <author initials="P." surname="Baran" fullname="Paul Baran"> | |||
<organization>RAND Corporation</organization> | <organization>RAND Corporation</organization> | |||
</author> | </author> | |||
<date year="1964"/> | <date year="1964"/> | |||
</front> | </front> | |||
<seriesInfo name="DOI" value="10.7249/RM3420"/> | ||||
</reference> | </reference> | |||
<reference anchor="HTTP"> | ||||
<front> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.911 | |||
<title>HTTP Semantics</title> | 0.xml"/> | |||
<author fullname="R. Fielding" initials="R." role="editor" surname="Fi | ||||
elding"/> | ||||
<author fullname="M. Nottingham" initials="M." role="editor" surname=" | ||||
Nottingham"/> | ||||
<author fullname="J. Reschke" initials="J." role="editor" surname="Res | ||||
chke"/> | ||||
<date month="June" year="2022"/> | ||||
<abstract> | ||||
<t>The Hypertext Transfer Protocol (HTTP) is a stateless application | ||||
-level protocol for distributed, collaborative, hypertext information systems. T | ||||
his document describes the overall architecture of HTTP, establishes common term | ||||
inology, and defines aspects of the protocol that are shared by all versions. In | ||||
this definition are core protocol elements, extensibility mechanisms, and the " | ||||
http" and "https" Uniform Resource Identifier (URI) schemes.</t> | ||||
<t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 723 | ||||
2, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="STD" value="97"/> | ||||
<seriesInfo name="RFC" value="9110"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC9110"/> | ||||
</reference> | ||||
<reference anchor="SOAP" target="https://www.w3.org/TR/2007/REC-soap12-par t0-20070427/"> | <reference anchor="SOAP" target="https://www.w3.org/TR/2007/REC-soap12-par t0-20070427/"> | |||
<front> | <front> | |||
<title>SOAP Version 1.2 Part 0: Primer (Second Edition)</title> | <title>SOAP Version 1.2 Part 0: Primer (Second Edition)</title> | |||
<author fullname="Nilo Mitra" role="editor"/> | <author fullname="Nilo Mitra" role="editor"/> | |||
<author fullname="Yves Lafon" role="editor"/> | <author fullname="Yves Lafon" role="editor"/> | |||
<date day="27" month="April" year="2007"/> | <date day="27" month="April" year="2007"/> | |||
</front> | </front> | |||
<seriesInfo name="W3C REC" value="REC-soap12-part0-20070427"/> | <refcontent>W3C Recommendation</refcontent> | |||
<seriesInfo name="W3C" value="REC-soap12-part0-20070427"/> | <annotation>Latest version available at <eref target="https://www.w3.org/ | |||
</reference> | TR/soap12-part0/" brackets="angle"/>.</annotation> | |||
<reference anchor="INTERMEDIARY-INFLUENCE" target="https://scholarship.law | ||||
.columbia.edu/faculty_scholarship/1856"> | ||||
<front> | ||||
<title>Intermediary Influence</title> | ||||
<author initials="K." surname="Judge" fullname="Kathryn Judge"> | ||||
<organization>Columbia Law School</organization> | ||||
</author> | ||||
<date year="2014"/> | ||||
</front> | ||||
<refcontent>University of Chicago Law Review, Vol. 82, p. 573</refconten | ||||
t> | ||||
</reference> | </reference> | |||
<reference anchor="INTERDEPENDENCE" target="https://doi.org/10.1162/ISEC_a | ||||
_00351"> | <reference anchor="INTERDEPENDENCE"> | |||
<front> | <front> | |||
<title>Weaponized Interdependence: How Global Economic Networks Shape State Coercion</title> | <title>Weaponized Interdependence: How Global Economic Networks Shape State Coercion</title> | |||
<author initials="H." surname="Farrell" fullname="Henry Farrell"> | <author initials="H." surname="Farrell" fullname="Henry Farrell"> | |||
<organization>George Washington University</organization> | <organization>George Washington University</organization> | |||
</author> | </author> | |||
<author initials="A. L." surname="Newman" fullname="Abraham L. Newman" > | <author initials="A." surname="Newman" fullname="Abraham L. Newman"> | |||
<organization>Georgetown University</organization> | <organization>Georgetown University</organization> | |||
</author> | </author> | |||
<date year="2019"/> | <date year="2019" month="July"/> | |||
</front> | </front> | |||
<refcontent>International Security, Vol. 44, No. 1, p. 42</refcontent> | <refcontent>International Security, Vol. 44, No. 1, p. 42</refcontent> | |||
<seriesInfo name="DOI" value="10.1162/ISEC_a_00351"/> | ||||
</reference> | </reference> | |||
<reference anchor="MOXIE" target="https://signal.org/blog/the-ecosystem-is -moving/"> | <reference anchor="MOXIE" target="https://signal.org/blog/the-ecosystem-is -moving/"> | |||
<front> | <front> | |||
<title>Reflections: The ecosystem is moving</title> | <title>Reflections: The ecosystem is moving</title> | |||
<author initials="M." surname="Marlinspike" fullname="Moxie Marlinspik e"> | <author initials="M." surname="Marlinspike" fullname="Moxie Marlinspik e"> | |||
<organization>Signal</organization> | <organization>Signal</organization> | |||
</author> | </author> | |||
<date year="2016" month="May"/> | <date year="2016" month="May"/> | |||
</front> | </front> | |||
</reference> | </reference> | |||
<reference anchor="MULTISTAKEHOLDER" target="https://link.springer.com/boo k/10.1007/978-3-030-56131-4"> | <reference anchor="MULTISTAKEHOLDER" target="https://link.springer.com/boo k/10.1007/978-3-030-56131-4"> | |||
<front> | <front> | |||
<title>Legitimacy, Power, and Inequalities in the Multistakeholder Int ernet Governance</title> | <title>Legitimacy, Power, and Inequalities in the Multistakeholder Int ernet Governance</title> | |||
<author initials="N." surname="Palladino" fullname="Nicola Palladino"> | <author initials="N." surname="Palladino" fullname="Nicola Palladino"> | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<author initials="N." surname="Santaniello" fullname="Nauro Santaniell o"> | <author initials="M." surname="Santaniello" fullname="Mauro Santaniell o"> | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<date year="2020"/> | <date year="2020" month="November"/> | |||
</front> | </front> | |||
<seriesInfo name="DOI" value="10.1007/978-3-030-56131-4"/> | ||||
</reference> | </reference> | |||
<reference anchor="NEW-CHICAGO" target="https://www.journals.uchicago.edu/ doi/10.1086/468039"> | <reference anchor="NEW-CHICAGO" target="https://www.journals.uchicago.edu/ doi/10.1086/468039"> | |||
<front> | <front> | |||
<title>The New Chicago School</title> | <title>The New Chicago School</title> | |||
<author initials="L." surname="Lessig" fullname="Laurence Lessig"> | <author initials="L." surname="Lessig" fullname="Laurence Lessig"> | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<date year="1998" month="June"/> | <date year="1998" month="June"/> | |||
</front> | </front> | |||
<refcontent>Journal of Legal Studies, Vol. 27</refcontent> | <refcontent>Journal of Legal Studies, Vol. 27</refcontent> | |||
<seriesInfo name="DOI" value="10.1086/468039"/> | ||||
</reference> | </reference> | |||
<reference anchor="POLYCENTRIC" target="https://onlinelibrary.wiley.com/do i/abs/10.1111/j.1468-0491.2011.01550.x"> | <reference anchor="POLYCENTRIC" target="https://onlinelibrary.wiley.com/do i/abs/10.1111/j.1468-0491.2011.01550.x"> | |||
<front> | <front> | |||
<title>Polycentricity: From Polanyi to Ostrom, and Beyond</title> | <title>Polycentricity: From Polanyi to Ostrom, and Beyond</title> | |||
<author initials="P. D." surname="Aligia" fullname="Paul D. Aligia"> | <author initials="P." surname="Aligia" fullname="Paul D. Aligia"> | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<author initials="V." surname="Tarko" fullname="Vlad Tarko"> | <author initials="V." surname="Tarko" fullname="Vlad Tarko"> | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<date year="2012" month="April"/> | <date year="2012" month="April"/> | |||
</front> | </front> | |||
<refcontent>Governance: An International Journal of Policy, Administrati on, and Institutions, Vol. 25, No. 2, p. 237</refcontent> | <refcontent>Governance: An International Journal of Policy, Administrati on, and Institutions, Vol. 25, No. 2, p. 237</refcontent> | |||
<seriesInfo name="DOI" value="10.1111/j.1468-0491.2011.01550.x"/> | ||||
</reference> | </reference> | |||
<reference anchor="ACCESS" target="https://www.yalelawjournal.org/comment/ essential-data"> | <reference anchor="ACCESS" target="https://www.yalelawjournal.org/comment/ essential-data"> | |||
<front> | <front> | |||
<title>Essential Data</title> | <title>Essential Data</title> | |||
<author initials="Z." surname="Abrahamson" fullname="Zachary Abrahamso n"> | <author initials="Z." surname="Abrahamson" fullname="Zachary Abrahamso n"> | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<date year="2014"/> | <date year="2014" month="December"/> | |||
</front> | </front> | |||
<refcontent>Yale Law Journal, Vol. 124, No. 3</refcontent> | <refcontent>Yale Law Journal, Vol. 124, No. 3</refcontent> | |||
</reference> | </reference> | |||
<reference anchor="DMA" target="https://eur-lex.europa.eu/legal-content/EN /TXT/?uri=CELEX%3A32022R1925"> | <reference anchor="DMA" target="https://eur-lex.europa.eu/legal-content/EN /TXT/?uri=CELEX%3A32022R1925"> | |||
<front> | <front> | |||
<title>Regulation (EU) 2022/1925 of the European Parliament and of the Council of 14 September 2022 on contestable and fair markets in the digital sec tor and amending Directives (EU) 2019/1937 and (EU) 2020/1828 (Digital Markets A ct)</title> | <title>Regulation (EU) 2022/1925 of the European Parliament and of the Council of 14 September 2022 on contestable and fair markets in the digital sec tor and amending Directives (EU) 2019/1937 and (EU) 2020/1828 (Digital Markets A ct)</title> | |||
<author> | <author> | |||
<organization>The European Parliament and the Council of the Europea n Union</organization> | <organization>The European Parliament and the Council of the Europea n Union</organization> | |||
</author> | </author> | |||
<date year="2022" month="September"/> | <date year="2022" month="September"/> | |||
</front> | </front> | |||
<refcontent>OJ L 265/1, 12.10.2022</refcontent> | <refcontent>OJ L 265/1, 12.10.2022</refcontent> | |||
</reference> | </reference> | |||
skipping to change at line 405 ¶ | skipping to change at line 408 ¶ | |||
<reference anchor="DMA" target="https://eur-lex.europa.eu/legal-content/EN /TXT/?uri=CELEX%3A32022R1925"> | <reference anchor="DMA" target="https://eur-lex.europa.eu/legal-content/EN /TXT/?uri=CELEX%3A32022R1925"> | |||
<front> | <front> | |||
<title>Regulation (EU) 2022/1925 of the European Parliament and of the Council of 14 September 2022 on contestable and fair markets in the digital sec tor and amending Directives (EU) 2019/1937 and (EU) 2020/1828 (Digital Markets A ct)</title> | <title>Regulation (EU) 2022/1925 of the European Parliament and of the Council of 14 September 2022 on contestable and fair markets in the digital sec tor and amending Directives (EU) 2019/1937 and (EU) 2020/1828 (Digital Markets A ct)</title> | |||
<author> | <author> | |||
<organization>The European Parliament and the Council of the Europea n Union</organization> | <organization>The European Parliament and the Council of the Europea n Union</organization> | |||
</author> | </author> | |||
<date year="2022" month="September"/> | <date year="2022" month="September"/> | |||
</front> | </front> | |||
<refcontent>OJ L 265/1, 12.10.2022</refcontent> | <refcontent>OJ L 265/1, 12.10.2022</refcontent> | |||
</reference> | </reference> | |||
<reference anchor="MIX" target="https://dl.acm.org/doi/10.1145/358549.3585 63"> | <reference anchor="MIX" target="https://dl.acm.org/doi/10.1145/358549.3585 63"> | |||
<front> | <front> | |||
<title>Untraceable Electronic Mail, Return Addresses, and Digital Pseu | <title>Untraceable electronic mail, return addresses, and digital pseu | |||
donyms</title> | donyms</title> | |||
<author initials="D. L." surname="Chaum" fullname="David L. Chaum"> | <author initials="D." surname="Chaum" fullname="David L. Chaum"> | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<date year="1981" month="February"/> | <date year="1981" month="February"/> | |||
</front> | </front> | |||
<refcontent>Communications of the ACM, Vol. 24, No. 2</refcontent> | <refcontent>Communications of the ACM, Vol. 24, No. 2</refcontent> | |||
<seriesInfo name="DOI" value="10.1145/358549.358563"/> | ||||
</reference> | </reference> | |||
<reference anchor="FEDERALIST-51"> | <reference anchor="FEDERALIST-51"> | |||
<front> | <front> | |||
<title>The Structure of the Government Must Furnish the Proper Checks and Balances Between the Different Departments</title> | <title>The Structure of the Government Must Furnish the Proper Checks and Balances Between the Different Departments</title> | |||
<author initials="J." surname="Madison" fullname="James Madison"> | <author initials="J." surname="Madison" fullname="James Madison"> | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<date year="1788" month="February"/> | <date year="1788" month="February"/> | |||
</front> | </front> | |||
<refcontent>The Federalist Papers, No. 51</refcontent> | <refcontent>The Federalist Papers, No. 51</refcontent> | |||
</reference> | </reference> | |||
skipping to change at line 425 ¶ | skipping to change at line 431 ¶ | |||
<reference anchor="FEDERALIST-51"> | <reference anchor="FEDERALIST-51"> | |||
<front> | <front> | |||
<title>The Structure of the Government Must Furnish the Proper Checks and Balances Between the Different Departments</title> | <title>The Structure of the Government Must Furnish the Proper Checks and Balances Between the Different Departments</title> | |||
<author initials="J." surname="Madison" fullname="James Madison"> | <author initials="J." surname="Madison" fullname="James Madison"> | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<date year="1788" month="February"/> | <date year="1788" month="February"/> | |||
</front> | </front> | |||
<refcontent>The Federalist Papers, No. 51</refcontent> | <refcontent>The Federalist Papers, No. 51</refcontent> | |||
</reference> | </reference> | |||
<reference anchor="ATTRACTIVE-PROFITS"> | <reference anchor="ATTRACTIVE-PROFITS"> | |||
<front> | <front> | |||
<title>The Law of Conservation of Attractive Profits</title> | <title>The Law of Conservation of Attractive Profits</title> | |||
<author initials="C." surname="Christensen" fullname="Clayton Christen sen"> | <author initials="C." surname="Christensen" fullname="Clayton Christen sen"> | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<date year="2004" month="February"/> | <date year="2004" month="February"/> | |||
</front> | </front> | |||
<refcontent>Harvard Business Review, "Breakthrough Ideas for 2004"</refc ontent> | <refcontent>Harvard Business Review, "Breakthrough Ideas for 2004"</refc ontent> | |||
</reference> | </reference> | |||
<reference anchor="ACTIVITYSTREAMS" target="https://www.w3.org/TR/2016/CR- | ||||
activitystreams-core-20161215/"> | <reference anchor="ACTIVITYSTREAMS" target="https://www.w3.org/TR/2017/REC | |||
-activitystreams-core-20170523/"> | ||||
<front> | <front> | |||
<title>Activity Streams 2.0</title> | <title>Activity Streams 2.0</title> | |||
<author fullname="Evan Prodromou" role="editor"/> | <author initials="E." surname="Prodromou" fullname="Evan Prodromou" ro | |||
<author fullname="James Snell" role="editor"/> | le="editor"/> | |||
<date day="15" month="December" year="2016"/> | <author initials="J." surname="Snell" fullname="James Snell" role="edi | |||
tor"/> | ||||
<date day="23" month="May" year="2017"/> | ||||
</front> | </front> | |||
<seriesInfo name="W3C CR" value="CR-activitystreams-core-20161215"/> | <refcontent>W3C Recommendation</refcontent> | |||
<seriesInfo name="W3C" value="CR-activitystreams-core-20161215"/> | <annotation>Latest version available at <eref target="https://www.w3.org/ | |||
TR/activitystreams-core/" brackets="angle"/>.</annotation> | ||||
</reference> | </reference> | |||
<reference anchor="CIRCULAR-CONUNDRUM" target="https://wwws.law.northweste rn.edu/research-faculty/clbe/workingpapers/documents/spulber_circularconundrum.p df"> | <reference anchor="CIRCULAR-CONUNDRUM" target="https://wwws.law.northweste rn.edu/research-faculty/clbe/workingpapers/documents/spulber_circularconundrum.p df"> | |||
<front> | <front> | |||
<title>Solving The Circular Conundrum: Communication And Coordination | <title>Solving The Circular Conundrum: Communication and Coordination | |||
In Internet Markets</title> | in Two-Sided Markets</title> | |||
<author initials="D. F." surname="Spulber" fullname="Daniel F. Spulber | <author initials="D." surname="Spulber" fullname="Daniel F. Spulber"> | |||
"> | ||||
<organization/> | <organization/> | |||
</author> | </author> | |||
<date year="2010"/> | <date month="October" year="2009"/> | |||
</front> | </front> | |||
<refcontent>Northwestern University Law Review, Vol. 104, No. 2</refcont ent> | <refcontent>Northwestern University Law Review, Vol. 104, No. 2</refcont ent> | |||
</reference> | </reference> | |||
<reference anchor="AMBITION" target="https://osf.io/m7wyj/"> | <reference anchor="AMBITION" target="https://osf.io/m7wyj/"> | |||
<front> | <front> | |||
<title>Decentralization: an incomplete ambition</title> | <title>Decentralization: An Incomplete Ambition</title> | |||
<author initials="N." surname="Schneider" fullname="Nathan Schneider"> | <author initials="N." surname="Schneider" fullname="Nathan Schneider"> | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<date year="2019"/> | <date year="2019" month="April"/> | |||
</front> | </front> | |||
<refcontent>Journal of Cultural Economy, Vol. 12, No. 4</refcontent> | <refcontent>Journal of Cultural Economy, Vol. 12, No. 4</refcontent> | |||
<seriesInfo name="DOI" value="10.31219/osf.io/m7wyj | ||||
"/> | ||||
</reference> | </reference> | |||
<reference anchor="BITCOIN" target="https://www.nber.org/papers/w29396"> | <reference anchor="BITCOIN" target="https://www.nber.org/papers/w29396"> | |||
<front> | <front> | |||
<title>Blockchain Analysis of the Bitcoin Market</title> | <title>Blockchain Analysis of the Bitcoin Market</title> | |||
<author initials="I." surname="Makarov" fullname="Igor Makarov"> | <author initials="I." surname="Makarov" fullname="Igor Makarov"> | |||
<organization>London School of Economics</organization> | <organization>London School of Economics</organization> | |||
</author> | </author> | |||
<author initials="A." surname="Schoar" fullname="Antoinette Schoar"> | <author initials="A." surname="Schoar" fullname="Antoinette Schoar"> | |||
<organization>MIT Sloan School of Management</organization> | <organization>MIT Sloan School of Management</organization> | |||
</author> | </author> | |||
<date year="2021" month="October"/> | <date year="2021" month="October"/> | |||
</front> | </front> | |||
<refcontent>National Bureau of Economic Research, Working Paper 29396</r efcontent> | <refcontent>National Bureau of Economic Research, Working Paper 29396</r efcontent> | |||
<seriesInfo name="DOI" value="10.3386/w29396"/> | ||||
</reference> | </reference> | |||
<reference anchor="PERSPECTIVE" target="https://doi.org/10.14763/2021.2.15 | ||||
63"> | <reference anchor="PERSPECTIVE" target="https://policyreview.info/concepts | |||
/decentralisation"> | ||||
<front> | <front> | |||
<title>Decentralization: a multidisciplinary perspective</title> | <title>Decentralization: a multidisciplinary perspective</title> | |||
<author initials="B." surname="Bodó" fullname="Balázs Bodó"> | <author initials="B." surname="Bodó" fullname="Balázs Bodó"> | |||
<organization>University of Amsterdam</organization> | <organization>University of Amsterdam</organization> | |||
</author> | </author> | |||
<author initials="J. K." surname="Brekke" fullname="Jaya Klara Brekke" > | <author initials="J. K." surname="Brekke" fullname="Jaya Klara Brekke" > | |||
<organization>Durham University</organization> | <organization>Durham University</organization> | |||
</author> | </author> | |||
<author initials="J.-H." surname="Hoepman" fullname="Jaap-Henk Hoepman "> | <author initials="J.-H." surname="Hoepman" fullname="Jaap-Henk Hoepman "> | |||
<organization>Radboud University</organization> | <organization>Radboud University</organization> | |||
</author> | </author> | |||
<date year="2021" month="June"/> | <date year="2021" month="June"/> | |||
</front> | </front> | |||
<refcontent>Internet Policy Review, Vol. 10, No. 2</refcontent> | <refcontent>Internet Policy Review, Vol. 10, No. 2</refcontent> | |||
<seriesInfo name="DOI" value="10.14763/2021.2.1563"/> | ||||
</reference> | </reference> | |||
<reference anchor="MUSIANI" target="https://link.springer.com/chapter/10.1 057/9781137483591_4"> | <reference anchor="MUSIANI" target="https://link.springer.com/chapter/10.1 057/9781137483591_4"> | |||
<front> | <front> | |||
<title>Alternative Technologies as Alternative Institutions: The Case of the Domain Name System</title> | <title>Alternative Technologies as Alternative Institutions: The Case of the Domain Name System</title> | |||
<author initials="F." surname="Musiani" fullname="Francesca Musiani"> | <author initials="F." surname="Musiani" fullname="Francesca Musiani"> | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<date year="2016"/> | <date year="2016"/> | |||
</front> | </front> | |||
<refcontent>The Turn to Infrastructure in Internet Governance</refconten t> | <refcontent>The Turn to Infrastructure in Internet Governance</refconten t> | |||
<seriesInfo name="DOI" value="10.1057/9781137483591_4"/> | ||||
</reference> | </reference> | |||
<reference anchor="STRUCTURELESS" target="https://www.jstor.org/stable/410 35187"> | <reference anchor="STRUCTURELESS" target="https://www.jstor.org/stable/410 35187"> | |||
<front> | <front> | |||
<title>The Tyranny of Structurelessness</title> | <title>The Tyranny of Structurelessness</title> | |||
<author initials="J." surname="Freeman" fullname="Jo Freeman"> | <author initials="J." surname="Freeman" fullname="Jo Freeman"> | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<date year="1972"/> | <date year="1972"/> | |||
</front> | </front> | |||
<refcontent>Berkeley Journal of Sociology, Vol. 17</refcontent> | <refcontent>Berkeley Journal of Sociology, Vol. 17</refcontent> | |||
</reference> | </reference> | |||
<reference anchor="SCHNEIDER" target="https://nathanschneider.info/article | ||||
s/DecentralHacker.html"> | <reference anchor="SCHNEIDER" target="https://hackernoon.com/decentralizin | |||
g-everything-never-seems-to-work-2bb0461bd168"> | ||||
<front> | <front> | |||
<title>What to do once you admit that decentralizing everything never seems to work</title> | <title>What to do once you admit that decentralizing everything never seems to work</title> | |||
<author initials="N." surname="Schneider" fullname="Nathan Schneider"> | <author initials="N." surname="Schneider" fullname="Nathan Schneider"> | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<date year="2022" month="October"/> | <date year="2019" month="September"/> | |||
</front> | </front> | |||
<refcontent>Hacker Noon</refcontent> | <refcontent>Hacker Noon</refcontent> | |||
</reference> | </reference> | |||
<reference anchor="BACCHI" target="https://library.oapen.org/bitstream/han dle/20.500.12657/33181/560097.pdf?sequence=1#page=34"> | <reference anchor="BACCHI" target="https://library.oapen.org/bitstream/han dle/20.500.12657/33181/560097.pdf?sequence=1#page=34"> | |||
<front> | <front> | |||
<title>Introducing the ‘What’s the Problem Represented to be?’ approac h</title> | <title>Introducing the ‘What’s the Problem Represented to be?’ approac h</title> | |||
<author initials="C." surname="Bacchi" fullname="Carol Bacchi"> | <author initials="C." surname="Bacchi" fullname="Carol Bacchi"> | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<date year="2012"/> | <date year="2012"/> | |||
</front> | </front> | |||
<refcontent>Chapter 2, Engaging with Carol Bacchi</refcontent> | <refcontent>Chapter 2, Engaging with Carol Bacchi</refcontent> | |||
</reference> | </reference> | |||
<reference anchor="ETHEREUM" target="https://ethereum.org/en/upgrades/merg | ||||
e/"> | <reference anchor="ETHEREUM" target="https://ethereum.org/en/roadmap/merge | |||
/"> | ||||
<front> | <front> | |||
<title>The Merge</title> | <title>The Merge</title> | |||
<author> | <author> | |||
<organization>Ethereum</organization> | <organization>Ethereum</organization> | |||
</author> | </author> | |||
<date year="2023" month="February"/> | <date year="2023" month="February"/> | |||
</front> | </front> | |||
</reference> | </reference> | |||
<reference anchor="FB-INTERNET" target="https://slate.com/technology/2021/ 08/facebook-internet-regulation.html"> | <reference anchor="FB-INTERNET" target="https://slate.com/technology/2021/ 08/facebook-internet-regulation.html"> | |||
<front> | <front> | |||
<title>Regulators Seem to Think That Facebook Is the Internet</title> | <title>Regulators Seem to Think That Facebook Is the Internet</title> | |||
<author initials="K." surname="Komaitis" fullname="Konstantinos Komait is"> | <author initials="K." surname="Komaitis" fullname="Konstantinos Komait is"> | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<date year="2021" month="August"/> | <date year="2021" month="August"/> | |||
</front> | </front> | |||
</reference> | </reference> | |||
<reference anchor="DEPENDENCIES" target="https://dl.acm.org/doi/pdf/10.114 5/3419394.3423664"> | <reference anchor="DEPENDENCIES" target="https://dl.acm.org/doi/pdf/10.114 5/3419394.3423664"> | |||
<front> | <front> | |||
<title>Analyzing Third Party Service Dependencies in Modern Web Servic es: Have We Learned from the Mirai-Dyn Incident?</title> | <title>Analyzing Third Party Service Dependencies in Modern Web Servic es: Have We Learned from the Mirai-Dyn Incident?</title> | |||
<author initials="A." surname="Kashaf" fullname="Aqsa Kashaf"> | <author initials="A." surname="Kashaf" fullname="Aqsa Kashaf"> | |||
<organization>Carnegie Mellon University</organization> | <organization>Carnegie Mellon University</organization> | |||
</author> | </author> | |||
<author initials="V." surname="Sekar" fullname="Vyas Sekar"> | <author initials="V." surname="Sekar" fullname="Vyas Sekar"> | |||
<organization>Carnegie Mellon University</organization> | <organization>Carnegie Mellon University</organization> | |||
</author> | </author> | |||
<author initials="Y." surname="Agarwal" fullname="Yuvraj Agarwal"> | <author initials="Y." surname="Agarwal" fullname="Yuvraj Agarwal"> | |||
<organization>Carnegie Mellon University</organization> | <organization>Carnegie Mellon University</organization> | |||
</author> | </author> | |||
<date year="2020" month="October"/> | <date year="2020" month="October"/> | |||
</front> | </front> | |||
<seriesInfo name="DOI" value="10.1145/3419394.3423664"/> | ||||
</reference> | </reference> | |||
<reference anchor="PHONE" target="https://www.washingtonpost.com/archive/p olitics/1991/06/27/computer-failure-paralyzes-regions-phone-service/0db94ac7-89f 0-446e-ba33-c126c751b251/"> | <reference anchor="PHONE" target="https://www.washingtonpost.com/archive/p olitics/1991/06/27/computer-failure-paralyzes-regions-phone-service/0db94ac7-89f 0-446e-ba33-c126c751b251/"> | |||
<front> | <front> | |||
<title>Computer Failure Paralyzes Region's Phone Service</title> | <title>Computer Failure Paralyzes Region's Phone Service</title> | |||
<author> | <author initials="C." surname="Skrzycki" fullname="Cindy Skrzycki"> | |||
<organization/> | ||||
</author> | ||||
<author initials="J." surname="Burgess" fullname=" | ||||
John Burgess"> | ||||
<organization/> | <organization/> | |||
</author> | </author> | |||
<date year="1991" month="June"/> | <date year="1991" month="June"/> | |||
</front> | </front> | |||
</reference> | </reference> | |||
<reference anchor="BEHAVIOUR" target="http://dx.doi.org/10.2139/ssrn.43896 | ||||
81"> | <reference anchor="BEHAVIOUR"> | |||
<front> | <front> | |||
<title>The Role of Behavioural Economics in Competition Policy</title> | <title>The Role of Behavioural Economics in Competition Policy</title> | |||
<author initials="A." surname="Fletcher" fullname="Amelia Fletcher"> | <author initials="A." surname="Fletcher" fullname="Amelia Fletcher"> | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<date year="2023" month="March"/> | <date year="2023" month="March"/> | |||
</front> | </front> | |||
<seriesInfo name="DOI" value="10.2139/ssrn.4389681"/> | ||||
</reference> | </reference> | |||
<reference anchor="DELIVERABILITY" target="https://www.usenix.org/system/f iles/atc22-holzbauer.pdf"> | <reference anchor="DELIVERABILITY" target="https://www.usenix.org/system/f iles/atc22-holzbauer.pdf"> | |||
<front> | <front> | |||
<title>Not that Simple: Email Delivery in the 21st Century</title> | <title>Not that Simple: Email Delivery in the 21st Century</title> | |||
<author initials="F." surname="Holzbauer" fullname="Florian Holzbauer" > | <author initials="F." surname="Holzbauer" fullname="Florian Holzbauer" > | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<author initials="J." surname="Ullrich" fullname="Johanna Ullrich"> | <author initials="J." surname="Ullrich" fullname="Johanna Ullrich"> | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<author initials="M." surname="Lindorfer" fullname="Martina Lindorfer" > | <author initials="M." surname="Lindorfer" fullname="Martina Lindorfer" > | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<author initials="T." surname="Fiebig" fullname="Tobias Fiebig"> | <author initials="T." surname="Fiebig" fullname="Tobias Fiebig"> | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<date year="2022" month="July"/> | <date year="2022" month="July"/> | |||
</front> | </front> | |||
</reference> | </reference> | |||
<reference anchor="SWITCHING" target="http://dx.doi.org/10.2307/2555402"> | ||||
<reference anchor="SWITCHING"> | ||||
<front> | <front> | |||
<title>Dynamic Competition with Switching Costs</title> | <title>Dynamic Competition with Switching Costs</title> | |||
<author initials="J." surname="Farrell" fullname="Joseph Farrell"> | <author initials="J." surname="Farrell" fullname="Joseph Farrell"> | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<author initials="C." surname="Shapiro" fullname="Carl Shapiro"> | <author initials="C." surname="Shapiro" fullname="Carl Shapiro"> | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<date year="1988" month="January"/> | <date year="1988" month="January"/> | |||
</front> | </front> | |||
<refcontent>UC Berkeley Department of Economics Working Paper 8865</refc ontent> | <refcontent>UC Berkeley Department of Economics Working Paper 8865</refc ontent> | |||
<seriesInfo name="DOI" value="10.2307/2555402"/> | ||||
</reference> | </reference> | |||
<reference anchor="SCALE" target="https://www.jstor.org/stable/724822"> | <reference anchor="SCALE" target="https://www.jstor.org/stable/724822"> | |||
<front> | <front> | |||
<title>Industry Structure, Market Rivalry, and Public Policy</title> | <title>Industry Structure, Market Rivalry, and Public Policy</title> | |||
<author initials="H." surname="Demsetz" fullname="Harold Demsetz"> | <author initials="H." surname="Demsetz" fullname="Harold Demsetz"> | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<date year="1973" month="April"/> | <date year="1973" month="April"/> | |||
</front> | </front> | |||
<refcontent>Journal of Law and Economics, Vol. 16, No. 1</refcontent> | <refcontent>Journal of Law and Economics, Vol. 16, No. 1</refcontent> | |||
</reference> | </reference> | |||
skipping to change at line 626 ¶ | skipping to change at line 662 ¶ | |||
<reference anchor="SCALE" target="https://www.jstor.org/stable/724822"> | <reference anchor="SCALE" target="https://www.jstor.org/stable/724822"> | |||
<front> | <front> | |||
<title>Industry Structure, Market Rivalry, and Public Policy</title> | <title>Industry Structure, Market Rivalry, and Public Policy</title> | |||
<author initials="H." surname="Demsetz" fullname="Harold Demsetz"> | <author initials="H." surname="Demsetz" fullname="Harold Demsetz"> | |||
<organization/> | <organization/> | |||
</author> | </author> | |||
<date year="1973" month="April"/> | <date year="1973" month="April"/> | |||
</front> | </front> | |||
<refcontent>Journal of Law and Economics, Vol. 16, No. 1</refcontent> | <refcontent>Journal of Law and Economics, Vol. 16, No. 1</refcontent> | |||
</reference> | </reference> | |||
<reference anchor="ADVERSARIAL" target="https://www.eff.org/deeplinks/2019 /10/adversarial-interoperability"> | <reference anchor="ADVERSARIAL" target="https://www.eff.org/deeplinks/2019 /10/adversarial-interoperability"> | |||
<front> | <front> | |||
<title>Adversarial Interoperability</title> | <title>Adversarial Interoperability</title> | |||
<author initials="C." surname="Doctorow" fullname="Cory Doctorow"> | <author initials="C." surname="Doctorow" fullname="Cory Doctorow"> | |||
<organization>Electronic Frontier Foundation</organization> | <organization>Electronic Frontier Foundation</organization> | |||
</author> | </author> | |||
<date year="2019" month="October"/> | <date year="2019" month="October"/> | |||
</front> | </front> | |||
</reference> | </reference> | |||
<reference anchor="RFC791"> | ||||
<front> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.791 | |||
<title>Internet Protocol</title> | .xml"/> | |||
<author fullname="J. Postel" initials="J." surname="Postel"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.427 | |||
<date month="September" year="1981"/> | 1.xml"/> | |||
</front> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.929 | |||
<seriesInfo name="STD" value="5"/> | 3.xml"/> | |||
<seriesInfo name="RFC" value="791"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC0791"/> | <referencegroup anchor="BCP95" target="https://www.rfc-editor.org/info/bcp | |||
</reference> | 95"> <xi:include | |||
<reference anchor="RFC4271"> | href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3935.xml"/> | |||
<front> | ||||
<title>A Border Gateway Protocol 4 (BGP-4)</title> | ||||
<author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rek | ||||
hter"/> | ||||
<author fullname="T. Li" initials="T." role="editor" surname="Li"/> | ||||
<author fullname="S. Hares" initials="S." role="editor" surname="Hares | ||||
"/> | ||||
<date month="January" year="2006"/> | ||||
<abstract> | ||||
<t>This document discusses the Border Gateway Protocol (BGP), which | ||||
is an inter-Autonomous System routing protocol.</t> | ||||
<t>The primary function of a BGP speaking system is to exchange netw | ||||
ork reachability information with other BGP systems. This network reachability i | ||||
nformation includes information on the list of Autonomous Systems (ASes) that re | ||||
achability information traverses. This information is sufficient for constructin | ||||
g a graph of AS connectivity for this reachability from which routing loops may | ||||
be pruned, and, at the AS level, some policy decisions may be enforced.</t> | ||||
<t>BGP-4 provides a set of mechanisms for supporting Classless Inter | ||||
-Domain Routing (CIDR). These mechanisms include support for advertising a set o | ||||
f destinations as an IP prefix, and eliminating the concept of network "class" w | ||||
ithin BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, in | ||||
cluding aggregation of AS paths.</t> | ||||
<t>This document obsoletes RFC 1771. [STANDARDS-TRACK]</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="4271"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC4271"/> | ||||
</reference> | ||||
<reference anchor="RFC793"> | ||||
<front> | ||||
<title>Transmission Control Protocol</title> | ||||
<author fullname="J. Postel" initials="J." surname="Postel"/> | ||||
<date month="September" year="1981"/> | ||||
</front> | ||||
<seriesInfo name="RFC" value="793"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC0793"/> | ||||
</reference> | ||||
<referencegroup anchor="BCP95"> | ||||
<reference anchor="RFC3935" target="https://www.rfc-editor.org/info/rfc3 | ||||
935"> | ||||
<front> | ||||
<title>A Mission Statement for the IETF</title> | ||||
<author fullname="H. Alvestrand" initials="H." surname="Alvestrand"/ | ||||
> | ||||
<date month="October" year="2004"/> | ||||
<abstract> | ||||
<t>This memo gives a mission statement for the IETF, tries to defi | ||||
ne the terms used in the statement sufficiently to make the mission statement un | ||||
derstandable and useful, argues why the IETF needs a mission statement, and trie | ||||
s to capture some of the debate that led to this point. This document specifies | ||||
an Internet Best Current Practices for the Internet Community, and requests disc | ||||
ussion and suggestions for improvements.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="BCP" value="95"/> | ||||
<seriesInfo name="RFC" value="3935"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC3935"/> | ||||
</reference> | ||||
</referencegroup> | </referencegroup> | |||
<reference anchor="RFC5321"> | ||||
<front> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.532 | |||
<title>Simple Mail Transfer Protocol</title> | 1.xml"/> | |||
<author fullname="J. Klensin" initials="J." surname="Klensin"/> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.612 | |||
<date month="October" year="2008"/> | 0.xml"/> | |||
<abstract> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.889 | |||
<t>This document is a specification of the basic protocol for Intern | 0.xml"/> | |||
et electronic mail transport. It consolidates, updates, and clarifies several pr | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.202 | |||
evious documents, making all or parts of most of them obsolete. It covers the SM | 6.xml"/> | |||
TP extension mechanisms and best practices for the contemporary Internet, but do | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.521 | |||
es not provide details about particular extensions. Although SMTP was designed a | 8.xml"/> | |||
s a mail transport and delivery protocol, this specification also contains infor | <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.923 | |||
mation that is important to its use as a "mail submission" protocol for "split-U | 0.xml"/> | |||
A" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK]< | ||||
/t> | <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.th | |||
</abstract> | omson-tmi.xml"/> | |||
</front> | ||||
<seriesInfo name="RFC" value="5321"/> | <reference anchor="CENTRALIZATION" | |||
<seriesInfo name="DOI" value="10.17487/RFC5321"/> | target="https://dl.acm.org/doi/abs/10.1145/3419394.3423625"> | |||
</reference> | ||||
<reference anchor="RFC6120"> | ||||
<front> | ||||
<title>Extensible Messaging and Presence Protocol (XMPP): Core</title> | ||||
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/ | ||||
> | ||||
<date month="March" year="2011"/> | ||||
<abstract> | ||||
<t>The Extensible Messaging and Presence Protocol (XMPP) is an appli | ||||
cation profile of the Extensible Markup Language (XML) that enables the near-rea | ||||
l-time exchange of structured yet extensible data between any two or more networ | ||||
k entities. This document defines XMPP's core protocol methods: setup and teardo | ||||
wn of XML streams, channel encryption, authentication, error handling, and commu | ||||
nication primitives for messaging, network availability ("presence"), and reques | ||||
t-response interactions. This document obsoletes RFC 3920. [STANDARDS-TRACK]</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="6120"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC6120"/> | ||||
</reference> | ||||
<reference anchor="RFC8890"> | ||||
<front> | ||||
<title>The Internet is for End Users</title> | ||||
<author fullname="M. Nottingham" initials="M." surname="Nottingham"/> | ||||
<date month="August" year="2020"/> | ||||
<abstract> | ||||
<t>This document explains why the IAB believes that, when there is a | ||||
conflict between the interests of end users of the Internet and other parties, | ||||
IETF decisions should favor end users. It also explores how the IETF can more ef | ||||
fectively achieve this.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="8890"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC8890"/> | ||||
</reference> | ||||
<reference anchor="RFC5218"> | ||||
<front> | ||||
<title>What Makes for a Successful Protocol?</title> | ||||
<author fullname="D. Thaler" initials="D." surname="Thaler"/> | ||||
<author fullname="B. Aboba" initials="B." surname="Aboba"/> | ||||
<date month="July" year="2008"/> | ||||
<abstract> | ||||
<t>The Internet community has specified a large number of protocols | ||||
to date, and these protocols have achieved varying degrees of success. Based on | ||||
case studies, this document attempts to ascertain factors that contribute to or | ||||
hinder a protocol's success. It is hoped that these observations can serve as gu | ||||
idance for future protocol work. This memo provides information for the Internet | ||||
community.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="5218"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC5218"/> | ||||
</reference> | ||||
<reference anchor="RFC9230"> | ||||
<front> | ||||
<title>Oblivious DNS over HTTPS</title> | ||||
<author fullname="E. Kinnear" initials="E." surname="Kinnear"/> | ||||
<author fullname="P. McManus" initials="P." surname="McManus"/> | ||||
<author fullname="T. Pauly" initials="T." surname="Pauly"/> | ||||
<author fullname="T. Verma" initials="T." surname="Verma"/> | ||||
<author fullname="C.A. Wood" initials="C.A." surname="Wood"/> | ||||
<date month="June" year="2022"/> | ||||
<abstract> | ||||
<t>This document describes a protocol that allows clients to hide th | ||||
eir IP addresses from DNS resolvers via proxying encrypted DNS over HTTPS (DoH) | ||||
messages. This improves privacy of DNS operations by not allowing any one server | ||||
entity to be aware of both the client IP address and the content of DNS queries | ||||
and answers.</t> | ||||
<t>This experimental protocol has been developed outside the IETF an | ||||
d is published here to guide implementation, ensure interoperability among imple | ||||
mentations, and enable wide-scale experimentation.</t> | ||||
</abstract> | ||||
</front> | ||||
<seriesInfo name="RFC" value="9230"/> | ||||
<seriesInfo name="DOI" value="10.17487/RFC9230"/> | ||||
</reference> | ||||
<reference anchor="I-D.thomson-tmi"> | ||||
<front> | <front> | |||
<title>Principles for the Involvement of Intermediaries in Internet Pr | <title>Clouding up the Internet: how centralized is DNS traffic becomi | |||
otocols</title> | ng?</title> | |||
<author fullname="Martin Thomson" initials="M." surname="Thomson"> | <author initials="G" surname="Moura" fullname="Giovane C. M. Moura"> | |||
<organization>Mozilla</organization> | <organization>SIDN Labs</organization> | |||
</author> | </author> | |||
<date day="8" month="September" year="2022"/> | <author initials="S." surname="Castro" fullname="Sebastian Castro"> | |||
<abstract> | <organization>InternetNZ</organization> | |||
<t> This document proposes a set of principles for designing proto | </author> | |||
cols | <author initials="W." surname="Hardaker" fullname="Wes Hardaker"> | |||
with rules for intermediaries. The goal of these principles is to | <organization>USC/ISI</organization> | |||
limit the ways in which intermediaries can produce undesirable | </author> | |||
effects and to protect the useful functions that intermediaries | <author initials="M." surname="Wullink" fullname="Maarten Wullink"> | |||
legitimately provide. | <organization>SIDN Labs</organization> | |||
</author> | ||||
</t> | <author initials="C." surname="Hesselman" fullname="Cristian Hesselman" | |||
</abstract> | > | |||
<organization/> | ||||
</author> | ||||
<date year="2020" month="October"/> | ||||
</front> | </front> | |||
<seriesInfo name="Internet-Draft" value="draft-thomson-tmi-04"/> | <seriesInfo name="DOI" value="10.1145/3419394.3423625"/> | |||
</reference> | </reference> | |||
</references> | </references> | |||
<?line 640?> | <?line 640?> | |||
<section anchor="acks"> | <section anchor="acks"> | |||
<name>Acknowledgements</name> | <name>Acknowledgements</name> | |||
<t>This document was born out of early discussions with Brian Trammell dur | <t>This document was born out of early discussions with <contact fullname= | |||
ing our shared time on the Internet Architecture Board.</t> | "Brian Trammell"/> during our shared time on the Internet Architecture Board.</t | |||
<t>Special thanks to Geoff Huston and Milton Mueller for their well-consid | > | |||
ered, thoughtful, and helpful reviews.</t> | <t>Special thanks to <contact fullname="Geoff Huston"/> and <contact fulln | |||
<t>Thanks to Jari Arkko, Kristin Berdan, Richard Clayton, Cory Doctorow, C | ame="Milton Mueller"/> for their well-considered, thoughtful, and helpful review | |||
hristian Huitema, Mallory Knodel, Eliot Lear, John Levine, Tommy Pauly, and Mart | s.</t> | |||
in Thomson for their comments and suggestions. Likewise, the arch-discuss@ietf.o | <t>Thanks to <contact fullname="Jari Arkko"/>, <contact fullname="Kristin | |||
rg mailing list and Decentralized Internet Infrastructure Research Group provide | Berdan"/>, <contact fullname="Richard Clayton"/>, <contact fullname="Cory Doctor | |||
d valuable discussion and feedback.</t> | ow"/>, <contact fullname="Christian Huitema"/>, <contact fullname="Eliot Lear"/> | |||
, <contact fullname="John Levine"/>, <contact fullname="Tommy Pauly"/>, and <con | ||||
tact fullname="Martin Thomson"/> for their comments and suggestions. Likewise, t | ||||
he <eref target="mailto:arch-discuss@ietf.org">arch-discuss@ietf.org</eref> mail | ||||
ing list and Decentralized Internet Infrastructure Research Group provided valua | ||||
ble discussion and feedback.</t> | ||||
<t>No large language models were used in the production of this document.< /t> | <t>No large language models were used in the production of this document.< /t> | |||
</section> | </section> | |||
</back> | </back> | |||
<!-- ##markdown-source: | ||||
H4sIAAAAAAAAA6W9624jSbIm+F9PEVBhUakFSd3yXjioUUrKSlWnlAlJ2dW9 | ||||
B4NCkHSKUQpGsCOCUrETCfQ8w/7ZBWbeaJ6in2Tts4tfgsysmlngnK6UREa4 | ||||
m5vb9TOz4XC40xVd6V5nu6eu6pq8LP6Zd0VdDbIzN+n9Jq+m2UXVuaZyXXbT | ||||
0Y95M213d/LxuHEPr8Pf0kfx9/zHd6b1pMoX9MZpk8+6YVV3XVHdzfPFMH+o | ||||
iyn9e1jog4bpCoaHT3emeUdf/Xx2cnv+ZWdCP9zVzfp1VlSzemenWDavs65Z | ||||
td3RwcGrg6OdvHH56+wnVzl6ys5j3dzfNfVq+Xqn7egvC3xv6paO/qfqdu7d | ||||
mj4xfZ2lbw2/n7qv/WVSV21dFtPerxt3typ7v7urH2hveTVxO7QKIsqveVlX | ||||
tKe1a3faRd50v/5jVXeufZ1V9c6yeJ39Z1dPBhn9T8HrHGRt3dDyZy39a73Q | ||||
f3RNMaE/TerFMtd/LOjD9KeiKovK/dednQdXrdzrnSy7K7r5avw6WxDt9/+I | ||||
6Ds7+aqb1w19cUjfzeh5tLTLUXblD45/LWd6mTf3/b/UzV1e6dNe82+WNe28 | ||||
lH9n2TD72OTzJq/450m9otfTkZ7QMWIZOf/aLfKilCX/F/zPiFbKf1g1RKJ5 | ||||
1y3b1/v7j4+PI/vr/s5OVTcLeu0D7XoHHOJ/yrLrk6szWcC0aJdlTi98k9sa | ||||
ury5c136WPrbdERb2V+uxu1+41qXN5P5rwu3qPGnfP/68vjp0cFo3i1KeYje | ||||
qw9VdlbgfMarzk2zUzqYVVVMmBwtX5qmnq4mfFO6+hufza5cBxamG8fr5ptw | ||||
+Or5U/7RnxKTVEmrp/IxX5XR9vpnwsSglzVL2gqfeZa9u739SH94e/rq8PCA | ||||
fr75cEI//3J8Oro+Px22db48PBouiVsPhnTXXhw8PXpBn7q4uj2/vjw/uzi5 | ||||
/vvw4urt+0/nV6fnPTr/vJreua10bifzusybdl4sR2X+OJrU5WoxLvKRm672 | ||||
Z/lkVXbrX6MP7R++fPY8JjZLoIWbFnmzph9m5crhogVyHR0cfotcwtx/GUVr | ||||
DFT8S97Nm3XV+1tKyVNdcfY+f8xuaKW1MAPdUpIRHd2s19mniniwaYtundWz | ||||
7HRO53tX8xeu3UPhHgfZX+tylL08GmTLUfbsxbER9uz84/nV2RaKvs2bxpXl | ||||
u61EndYF8+3hwejw8PnR/sXN+emv+a8HB8fPDhNG/cXly5q24lTKm2Sc0B/f | ||||
1Y/ZT2U9zsvsnDZSL4qJZ8fsZp4vHSR854gArpkQKXZTor/6Q6K/G9k2emR/ | ||||
5yo6zP7fUrL/5Ohnl/2SE1dUdx3dpEDkrW87GWXvSYS5x0W4E/q+kzFJo3yx | ||||
5e/b3tnVjxsviw9bdCJ/hWh34yYkr7q1HvHTpwMSlqPskE/66RF9+/LD3y70 | ||||
eDduR3FHz+CzHJf13X43d0M3qdt127nFsGiHi/qBdr+fHOq1m5VuorLmdu4y | ||||
/42saDP5xm7KTSTDSWO0y+I+vjmHB/SHNc7y+TfO0pRD/xmeupf174Xb9ueU | ||||
uDe8V9Dj0/vbi5vbk7+cv/vw/uz8usf5H/OyzEl91cmm3ztSccUinxChP9aP | ||||
rjHbxf1jRRqlK1xLK82IgNklyRSSuPm9I6kydU0wYn7yijrl5aODP5S3VwVJ | ||||
rry3uI0P5aumzm7yioyAgli73nroRKb7Ubts6JhcQwJxsT+u63u+zCR291+9 | ||||
eDk8Hh4cHwyfPT88PhxCuF2d/zI8fXdxevLThx613ruWmCghFViC2NyLIZFZ | ||||
8Y5/XlWO1Myrl3+47fe0I4iL+D3xXdj9uV41uAYk9uiIcB+61ZQOQ6/D0Yvd | ||||
r6rf3+Sr7Wg1kZWyTiDZJqR4+Xz/6fOXB8eQMx8/vP/76fnV7fXFaW//J2Vx | ||||
p/aE7f9jXa7Z4CkmdC9JlDb1gnimzKt1AXX8gbRxvRD+eePWdTWNaXNCB1Pi | ||||
Thz9OR18NorX0P/IX4lbsluyoLazQs2GXFmQfGrWo8eidGtmCBAhJ5uEBfzh | ||||
4f5vo0OixfDg6avDES3tcHRw+OzZwej3zfMILE5bqXqyKjosokeBu3QyXRQV | ||||
7JPEIWiJliuWMHaOz0SsiQI7OuZjPTk9Pb+56R+IyNq2ruJDOW9bWl9B7z7L | ||||
u3yb9t7GIeu8dGQ0KKOwmFQjeN/ZA4dTe+DWo5Jj+L/yyRz2Q29xMeX+Tu9i | ||||
ja1E0o0fHqlAh8o+uzx5He/q2jsD2ZPzT3uQJEf7h6+OnoHCEEXnJA+WLq+I | ||||
VUg65lg5U1j/fEqG8aTg8zh8SppkSTJ8TAILz8noobw4kmRjWhq+NsuLJiN/ | ||||
4t51XtpNiffI8s5aUgl1wx/De2D/k+HZQFE8kGzU9R2+ovUdv+CP2ZIPyOY6 | ||||
epk9OdMnXeoLTibdXqwt+ivcemxu1QxL9/vIYedk5a32S4iFodJ5//xq//Zv | ||||
t/s/ks78j9Pz9+d/+z+OT47xtGvQbeNUPvycvc+Onj/bJ316eERSYeTfvPW4 | ||||
U5Vz+40j6NE/OS1S/swhlxd/63H36TxfLWIW+ATHauL4iM6hlhuytyZEw4I4 | ||||
6Np1xEt0x6YN+LWV62V0/ti61bSu1os2pnL21o2bFZj18NXLw+3mXznKJwu+ | ||||
DiYtD58+2z9+9vLZ01cj/Of58R/diLP8oZjCIAo7iunec1OUQCenlyYP9Fbg | ||||
KN6ekxI/eU8qffjssEevS1KWPVGAQ7khj35CtHH2ZBFbfDiX5CRmb4luRTvn | ||||
v33EqTS0UDchy5Sldl5CwrUkvrtH5+QinBWzmWvwhDMHL4Z95YiyLyPKvnj5 | ||||
x6rvZ/rfNtlATCDs4q2bIghB0pOYi5bYCk3YBj+5vb0+Ob29+Ov58OP1h7cX | ||||
t305eTpv6IuuIjHWpw6kENwIorxrHkS+0M8nHVgN1xkkmRXJ7vzeyHX7Y+/x | ||||
lJYAk7q/iHiH73J6d0PEXrWko9rWuzK7bxqX35PjVK/u5tnF1OVtRo44v1nU | ||||
Am374vbvN7fX5yeXN+Jinl4Pee2kkSVQ05JIaNwQxufh0SFu/unF9emn9yfX | ||||
w9MPV5+uzq4/XfZIdrNclSR8EmV/U5ewd5lup0VD/mTegHKratqsFj1GJo0I | ||||
D7xuSDrKLy6qYB2q3Ou5Od8wDe0mwdbL3o6S9SVK+apuuvkjSXJ6UewrbjiI | ||||
hwd2r75qNrXsRlfRE9lssujFUH3q/QktZR/OHFFnydxJwmKy4lux38pKf50o | ||||
xSZGsNFyOsMRXr65uL34cNU/gMm8cgUx/VFyBv2w4mu6pKSeELgqHTmQObnP | ||||
3f+SA2nmdDenJ/m3bjeh2tmoqPcXLx7Xv+1/0z49JbqsGu/urr2GF5Iz79K2 | ||||
Tz9cXCVafvdNWU/uyYAowEB5uW4LLxHfFN2kpt8L72x4Xfd5Uz9Eu/5AOlrV | ||||
5+Hm7vu39OKOblX8kA0F956M17pSCx9rMk++3f7Ek6qj1bqODgXfyZvtj728 | ||||
uM1uyjqPn3yZV/mdA/t81VyraGsSTxN+ezx6dfzq+ZbrYPboG9IA+SpeN10H | ||||
4eNB9ovwrojWjB8F+n48v775eM6StR/sq6f1H/FltoBzSF+ZFEsyvUlg7mCp | ||||
SzGTkijcc3GTth9VyqjQR//zv/2z5SX8z/+21RZJQ0QnC1zdqYZTe4/7OV/n | ||||
2V/oWuYZidp771CnDzxbNYhpfC0qYo/Kl8N3rrrP3tVuGSIfvWBhPh3Xq2n/ | ||||
Wd8KOz198fx4H7QZkVVm9kZyyl6uiqvRF3SRnLv8dHNxcnWRXrqTUj0XUne3 | ||||
jkRAXdZ38PJJ28R/i50VUZ+neevtirN6gWt7RcTIbjhG0r+jpN2IEqlk2hIO | ||||
yYZK0bcNmx6TPPnqH/v4JD/IeG7Et33Gbv7h4fGLpy+Pn706/PXpJv2wlVuY | ||||
j+SyXlSzJm+90VRUX4tpkM79dHr76Zos6w3P7G3jnHFAZG3crmlHFXOlN8tK | ||||
0vfQ+fF9ePXiG3a3cludvmSb09+Sl8JcJH7N/tNDRC1fvtggwBtHIpUc4thr | ||||
vaknBfjAy2587eb03dX5xWYgyeuNJCb6yzzvQNJpTR7WxGXrepXl5ATTL/GX | ||||
KCEE4eOIuOsOEciswr/JzXKLFt+Hao3J8yIW7lso5RnoT2m1ij/U2mdGSHXs | ||||
k1FbTOho9r1ge5dP7umvPkGR2m/4G90ytl7fkLP+rnfFLE+B3eGy/Ptf/w+o | ||||
8+9//b+tGd50Qgu6uUuYFxXyF7TzsfuRPpLly2VTk1/du1Bv8slk3rtP3yLH | ||||
KWm3Mv7W5lWS6EhNeqCSUCmZvmxD7hONpsRDRwejZwd0r8hRfLF/fHz48nD/ | ||||
2fODg1cvYM782Lp/cM7gPw6/W5IK+4/jzct2KpcT4Y3z6i6/A0Uei27eX935 | ||||
7bvz63MzTOOA26WjVe9+S6enIvecCNw49byEUE9jI/7oeLt7rV9jOrhqf7W8 | ||||
a/IpscQC74f98/bNkDMLV+e36So1WFE3LfnxdKp0krfE2Pf0v8T3b8mJRRgy | ||||
u5CzN/nSO92/QJ52RSwYnmcnqzv4bF/RlJZqIfnc5VVXVHWbPmYjKE6rdCwz | ||||
O5P7a1Y1+wcvkTLidYbcZsjI2j3wSZWL85ueUoH59k/xFwrybT7SlVoTOZqH | ||||
gkTBmWVHNJh8WU9hsP/ixvYRJDVyUjq/ICCa0+un2QzRRQ47F01eDM/WkM2T | ||||
AmndH/vEy9t5PvsjIXryjzaPP7qRj8J77xBxR4T562kRDUCuc5z3vTf1/v88 | ||||
7O+rhyb/LTu5y5vHvPzfeeCGGXyw3dJIIxx0i0OU4+khmYJPR8dPj46fc6L0 | ||||
47sPV+fpOZPXt1zhQr/NixIakw4aJ+/gxd7RQr9vs4/zmsw7PdjENXnhA+Tb | ||||
4y/QY48+L4XMN3MrzFba7P6yRj5i0u7jAfsHz/ePXiBsyQsi94wXhDyrLAj8 | ||||
C9tluMR6hq2sZ/9gOn71NJ+8GL58NTsYPn363A3H+fHxcEJCbvLi2eH46Nkh | ||||
rvub83cnf7348Ok6IQAk0nVdshn0xs3zh6KOPB9aG9gbRHIde2Zqo0VEuMRu | ||||
ghz6Fr8uXFnk2Vty9SbzLeoMx/n7KLIdjw6PX+23LTmuT49fvnquQa5gpoQH | ||||
nZ2/JzP/+uTNxfuL27+nR3xVq8a+KeBmkkQFnIDucAmGW1t49OiwFfDKqlmn | ||||
KZBy/RVNnW7vbVk3ZOaR/Vz+c5yvdIMbhg9poirPPpVlU0zm2z5yCe1NH3lf | ||||
kMvWzLY/57YeF3Rf3xZubEmdLby3Il1c/C5GFNu0+7MCZkHeTY6OhnNbqPry | ||||
EWnjPdz8Qq7uu4urnxKykvjK4YbFvMGK8Ib+d8J20Cnxe9s7Msnk/hzTN68k | ||||
1IbA7atvhduMgq1bztOccPoJkiwl56WLZjOZsslkxwcv9o+ePXv29OBoQ91/ | ||||
Og3WZQgWJv5zz/18+fL5MzY1T96nouaimgLUsg6280CDAdl18ZCXzVqCvh9X | ||||
Y7phyT0z6p2RRem6f0bEkxwUWdx/ePnewT6ZJo/4U1b3i6OnL482CRNn8/JH | ||||
XriniJnczzXBTV8+OaPbeXNyfXHyPiHKyRQyP2+Q72FDAgHcfFyUXg34vdfI | ||||
WtSPsfiN1MMfx4hOa6J98pQNSytE5d/Sf7oCaqFeVVPDxWwnmZvNRP84h0jB | ||||
fbsv2ZOD/TzsTqyQeHc7w+Ewy8cth2p3dsjMaDOLu2HbkxUSAeTEIuTAYaQ0 | ||||
RiEyje4AkBfs+amf1xraLqOV1U3XjrKLLqOFr1wrX3qckxSIPjeukYjN5jBY | ||||
yoI8HLJWdJl4Mtn0D1gUeWtrxG8XW1YzgAxdZxOSf+RllyV9+N5xWorxTJwb | ||||
4HfnbYsweB9OZ2647WK0IwRaFFOy23d2vkuwUjs7HyrX/wpp6qmbFRXu4szl | ||||
uGEtcA7kA2QluTj4PHbQ0gdo+8u6kJvMtmMxQSJPFTL+WTdAS0ioibcBlj4h | ||||
ItKtWA9kL0s+UCKSbMpN++shy4+URz6tlx4LOSZXaErHRv7Qa3KQJjnJ6Iye | ||||
sijoGfQZWnBV41z/sSoacaPo9RXxAP1zQDtclvUaYVPyqkqLVoP+tGA8Kl4B | ||||
B9vzbMnuIMe7l6uGrBCSPOTF4qwWzoHZwKaO/FY3lbTJ2OmLaAGkHvngpz5r | ||||
4qoHkqycg2npnE5KunMI8COA0uVyAEyfllFBIPsMCcmWdoXP0DtIVUwdkca1 | ||||
y5pWPc3uahAdUEpOM3T0N3YlG47Z02rzSVO34nE0eXXHj1UTSNYc0UNZbenq | ||||
JfjcOYSCdhNnhZi9xfkRY2euXLVEghF5/LTB3I7NP70siJWvrm4/8nvckM2H | ||||
OZ0ihwjpFcBZ+tsN1qLnwhknScikY6m5AMCORBCJs04uEU5HBSo/OWwH6S48 | ||||
DCw1No5VXGczgbBESpuhLNC59apjzk5XkUexL7pJxEiggLD9I3aatfXCya0n | ||||
RsS/2zp7JKU6vK+AbMKaCiwb3hgLAiYo+Pp3eknhOLPGpObLj2VjiXVF1FsI | ||||
sKbiXSZMSffRlbNR9vlz5IF++QIRSAfOfAZu5d3RVSyxrTojz7wVI4PFHkxW | ||||
NqPp9kqsnnzb4q7CToljA8vrVa2ZxWk5RE6iULUp/doVmbG5+rTnt2/xJFwR | ||||
PhkiMSlPaCI8XeVBCdbsi7GqL8ZSwb4phiNJiOtuwiha4ILeOsb1JHK3YCEi | ||||
ByN3N14+i67+qpooLsMfDgRLuwJ5CycnSlKoIOEu68Ed9CKp92hOZBCnZvxX | ||||
5sqqroZhueRuc8SAeLEl3mcqKJ34qvbITbIUYoCuOJ30YMtpCMWx4lnxO4uR | ||||
yhQRyA6++Ioq+gFAtM7lU925PgrcSO9xSw7KuaqFt2fMm0HLFrNIfjgIIOgb | ||||
R5/l+5QelNxPxBIiCdglZw0RMwbPmTafmthTl4PZbCJ5R9IiTyCpPn8mVdV+ | ||||
+bLHMrqxgJrwJeLiPqMkts6AaRQeAhGKzbHWh4grFmCZHFgrRDELeZKr7gqS | ||||
93Rgj/Pa7g6zup4EbTIwE1Giqyd1SQ8944/ii7QMKECSAx3LNfvMpjTGNRq7 | ||||
ipRzJ1EQlvMkIDWe2GJZ7QqwB8cHQadLRJrJMUCqCQyjaDiYKqFF/xCEVqCt | ||||
wRqr6OIoO4zUlIZB0shaRE/GR0VPnLtymQH8Q4xMK6OP5ONVa3e1qB7q8iG6 | ||||
FvTWb+yYFQUZ9StwLqhU4/RJ/TnmbpWJC+Kdz59T7v3yRawYCL+ehUVSt2T1 | ||||
+Thfgzn8nSQTlU5FpD4ZWyzXuwKgBKE6CCrOBTH9g1uTqVc/4gn1ZLLCSfaE | ||||
FjFh3z6jZeH1NWyqDdsNT54Xd/OS/p94jtUKUgMP0BuMGEOgB6CWsrZ4qRwn | ||||
W5tCsxFiEbRLIogerPye3oyjg/EgkK6p0XgMvccGAbQBH9MWIxgH/seCeyTv | ||||
nZSrqaM32j9bCDoO0RWzNcudxkAMsxVnWMCQMFbJQu1Vvnz+rkfCnZ2LKuW7 | ||||
QbabfmbX7ueG6SQaOzfrlfX/OmP7rl1AGnJxi8qGBe+6HsOigN2QL8Xf1P2L | ||||
dfs7ex4Zm3Q+NunFmtmTbDRvqhX6+kTMpnJN23/n8PhdWdUu6jhKtiJzmLYt | ||||
mJeXxy+ehFqDEZCHsRNGZgOxEL7Zrsa/idEbVc3IIRPLFHdEnv4NyejW3psU | ||||
ZduMxeh4pfEfeVHrFZo4KnmW5nF4C7Sl3Y098+GI9oMRb3I8Os9RdlnDuWE0 | ||||
HdyEogs7IjKyJsFbTHTQjSCGmq71zou1Z6w78DbJxUfa0Y/Xb09fvDr88mWQ | ||||
vfnJfvH06AX/5vY0fOQYvyBCo4yDfon/fPnCTqCsJS/bWg+HJVNeqqNQucfN | ||||
JfKjsPbfAf/RQhX+mSw8fLCuHJHrjXdlNmzEvqPmbRHzNemBftNDo8TXpeug | ||||
J7x5PyY0NpiCzsjbQsQLRdmxvKuXqVlC1h5rkd/zBVv0bc12diV1DrTPQTZj | ||||
r5k0hP4EliwYUCl2u4jYCiqaNH7rFoodGmXvyYN4LOB3gQ7hmRm8vKVIAnru | ||||
9DHHNdI7SH+WoJ0+uCVhjw+oHz2BLx2Oq4sz3xs2NxuyIFPBJWIbwg9h4HZF | ||||
NF4nRqR6ngzGEqtpigvQcFQ4cSwhF8EobUE6mOk+YR6ZF+Oi/7oBFo4/d8lb | ||||
6RN0hLgqAtWrrMTkCY6XRBwxxe4tgjKHu/6Pe97CZtef3zytnTjRKvfYWOzW | ||||
S7fFWORSNnXpvS3b46AnLHsHKX/kpJUQ5nTYta4mQ/gHQiLfCDJoNH8Pf+WY | ||||
DUtO8bagvpu2q2u+/t4yk1MX28nLPBi16yVWSd8ewyvXijFWTkE8q7tsHirX | ||||
BtJFhccOy/uRFBeEH8lKlTKye3hZJiUEi6omMlFvSwhKPBjsjVkwhIoiyx+H | ||||
7Jc1y0X5sks3I3GDvCyWZATy/gf0TjZZ4RDHoPcSpRzwLvI7xyIJX3DiNNMf | ||||
inYbLfHu6FjNSBadIOUgdhIhvOF1odikdCBclsiGJnECGB+AxC06EQZ/nuGY | ||||
7p2jS0y8GW6+jy39SfbSWkhmJxh2EghiqsJ6i84aqgy3qEDYLoRJyLAvwyqZ | ||||
87gEpmQnYUK/ZTkGUogL4c1putxTtyQjDQujTZwjSsJb3/QK+aurpoliNlUn | ||||
4sEWOBCLkF4wLUQMc3AQuhF0RHilXAuf9fkLPOo4Y20+k5hdkFixCmBDfXeL | ||||
ObDLdIutegkNEZEKiXDCePtuw3g7pWv3xiFqvpitSrLlyOYmA+4SYZbUdxIh | ||||
WCxhr8Vwm40wrERaBPBYGqw0ujN824XTNkW0vxfi0ro00EfqlsjRIcLNyjIE | ||||
Rjj0JQhLeg74iK3volMHfLdERJu0j0Po6I7chXpFwplsZCkcwz3ksJKqAtw4 | ||||
UUq7sDfenH589Yzs5TTA42MFEd2nGV+OXROV9FyT4bugY2u2Z920FtVGiI7p | ||||
LBrvrnF8DWb5pOCb6+xKT1Sv0NeJZTOGzXj7g419rUyE4JDQKqvXFVvIYqTQ | ||||
g2t8u/3egq8S4BROmxGnsaMUisbFsMn9HcQ55qVy/0Zg2oJTyS3XD/J1XHZq | ||||
a++SY4/AMw5CaL1LPHrtytWky3WlwidiE2/eSdb0TV13cpfxCo5DLutOSmEg | ||||
7/KFoFeIOznBwDTWYCCEXMsWUMdBC+aYATPuCvUir3d2/s/sV66uyy4WYwHZ | ||||
/wrIFIvHjiETS4ZMQCauKg5XSVRyMmGtUqdnZ2GqO4DwfLk2Yz/B0XRfC/tx | ||||
CreStICxRVmSOBRfx4fBxpLKbrIn2PzuMq8Qgp/Ab+Ht7u5pXC9fsgkr4QM6 | ||||
pqqQpFbvAZN5fe9EmfsHfP68veKZrgOHDpeSQilCjBRMzuICZTZqorGjF1Nf | ||||
wjrs3D04CRPs+aiFhIzByw/wAUm46CpCeTC93rYD8FrRNqtlx+as69Y++Poz | ||||
cDh0NHfQlJGDJTZxx+42XwLiQeQ9PWVZD+O1STEHPA7iOdK7Yn1teWwiIvTh | ||||
JozBR1AkGtWRbgrCvIBekPs+cSHSvZSwE9//UOqhXIiMBPHme7gWfGEvqqoW | ||||
xiAGPVGutBBEnOYy7ZrwpYQPyJ1DNEAD6F51YFu7IXcDLCQt2V63y1H39B2a | ||||
vqkAb12Byx0HpZPYke0zyKlJXIjASzcuqoO8E/ZikGKTCEaNuAhdUCpC0qKo | ||||
hDhR9v5XAYMEJw3R/65Vez8J3zX1GOwziVP/8/42NjIa+QNZbCwD+CEikSxT | ||||
AlpFsT9+nOxI3s9mMDlvFgfk/MRXXzfOoXBWS5bXcU7EK+WRyao4oKffx/2x | ||||
LA1Z0C3zpfj9qoSrmnUHw4l1d+2q6MRSLUxGiGEpqZWWXWZf26gqjCxRMqHJ | ||||
+g4qrZWwo79qcmzXDpHoaXYiNOTvgp2jHzfu2JOtUclAI3aFhUawDhecDWuN | ||||
9BxtalRxPOZrFtn1GPk9leEgIXvESrU8XsxGyJdtNyhRWAId6yERKHnGJkg/ | ||||
sspsEfKs/CMpUnMT8HwRlwwRQByjYQUBK0x8XHhB0ZKEkJekWSdc3uGU4dsJ | ||||
6jkDcyK6sXUxkjDN76pihvRWBR+kzB/ZF/b5Zv721ImpwhatLVQSvxyeF5Qp | ||||
EfBtavKr0zippw4czNK+qYEGIyMS4VTRFGGHoN54xfrrYVVWHlzwQ3hYGjUl | ||||
bXkH5TJfJNlHv8gW0GVnwQ95zSg78wUJcTAF0F5GVMFOkqeXLp8qDdi0V0FB | ||||
W+D0IrMWchjeihRHduAv1i4R+47dTo2D2ld5qx0jKYiLh65pWMnVJWMLNP/A | ||||
lgV9knmWLISKi1/FnmZUAJ1KuR7Bco3qxJF6JM64Ib04vHZse0x4T7hgraVs | ||||
KramnrDD7EZ3IwSqpayZg4zbWYYYNtg7KD8WawWYBI22gm0lcUOfELdILuJC | ||||
kj41y+AavintoB34pGG1FgsWAUL/CjFgOSTiNMxABzUvlj6oItkWsssXIg6+ | ||||
mubjkqzff9A8A5RzXooYgMGamyO1zWEDF2i6WYvn+eDpSbANBipc0qfmGjQV | ||||
GcVshYDQ1NHWaT/JRTFPVWL/23a5JT+RiAKyA/Qj5Tpk2rU1hg/YMgsHwRBF | ||||
JuTFbb1qWLmlsoPFWeO9GQtAQ2u1yKpNGscX+Y7/29hl1tDCLCfpxL56CDuM | ||||
4n5cwQPzsSG+auRhlEXkfQD/zOYcro9Plar8lEWxwYKgYKWGBI7ih9RFYatc | ||||
M9D8edsoICwcnreb7HN4ILcnIrlhnPuKSZO6l632RUlEmHXpqLu8ZFcVnG6w | ||||
FTUV27yYbuXChrVlm2ok6C1iTrAu7RHSmy1V8LfcOP5n9CGLLFrYW6nNBhs+ | ||||
x5kgxobwlShRF8Vbr8dFGRtSqi0vIMKW9ZLjpfJxMnA6jbWLinnEzeD0Jks9 | ||||
OE7GWwgT8SFxcNcHtegHOTssh67BnmJO/kwc3h+SegkQcJERNl05Q434OOI0 | ||||
Rr6L/0Ub9uh3UhJOJQg5fj9kkouJYfYkLeN4uGn/7UQLhJGlWgRFwoD6fvVf | ||||
56hLBYCJd0nOMyKLHL4wI5bDhnxZyNj8TR0geO0FXG2N9tETZUUdaVxGWktf | ||||
tQobhiNQLNlOk1w+WR4QdrKeFklExph/kVzfmE5GeEkC/4k5DCb2x4iYXLjg | ||||
P6iYDgERUc4AJyJ2io9yrwakrfEXfzzgfFL1vjBBPKdcwvbZQ97wVqNYL7SO | ||||
hpZFqiGFpkA52zvHjS3KO0I7KFgJ5rBLfz2wC2QC/ZdNyg1jho9a8z3kgobr | ||||
H/IeOfF7MUMU01wxWn7lRKDIH2GR51Ejkgdk16HdJ3yoQNXhmWJUC89EZ6a4 | ||||
Mz00FYV0zS9mqpP4+jF8id1OYz5Np7TRCT7xFz/wiU9Y0ArqcrqnFHrkZCjd | ||||
zoK9gTjQmreJ2cBRU5LBFg0gqVfA3CQOqTrTE0JeiIXCqzN/JAI3Y9kSXCu2 | ||||
HqBUC0ieNFsFdB9SlswobWz3G0vpzQy86EXSSAqCHh1wXmIYAN4kgAoF1oii | ||||
zyUz8g31LPoxFtiDOOTprc7v28ghbBlq7g2fGHen2Wu+7eweJwdKtKDt5Rzs | ||||
LNcmpuRxX76MDIrGRe+LtpMWEu3qju54x0+SdBdCo/DR1V/toVr+t0wTMXTv | ||||
CoRvbM+vBfM2zhuS441IDyEttK+H22+SgYNXjRtDgXO6UXCcLOsF5uRRiay4 | ||||
uHAbJ7sH+tHz0NDhLrBCeHBKQHoPjFeSHGJ4iIvGO1EpYNyz9+POzkkly1QT | ||||
w7QS0Kd806qVhDUjdcvkVTyNBEQ08vAg10kjGuaR6m55ua2KGZN9mwA5YZL4 | ||||
kWruQLPRz3JQWNkiif4PRFKQlYbg/hNJ0SrwZmDtP+nC7ImMDpAtHwtCoptB | ||||
cAqVkYY9fBZTxOMX+LsqWR+QxHUi8T+MFjxCd4oY8qgP4rhypR2bQlpUTe6i | ||||
miIy4JI4jtlwQIIK1kJNhEhqxXCjfpbiqzk3fRK/X9qTJO+NavO+lY5x5VLS | ||||
MR4MKbjRENpW32YzV1kKQjsfw9TDFVLHDuFEJ5HuETcv89hkwTtNzRVtUL3E | ||||
ZtTGLQZqA/baNxBhfOBccaSyzvgv1+DEB1hNgy0OmeXUzBzztBUasALYGkgY | ||||
ZHfctZGZVCOItJ1//+u/i+ciSXdiyX//63/gRcB0chgjUUqkVg2Gop4FMgvZ | ||||
P+uAwN+snc+enF3d7Fl0S53e+You0HAGYxTgGdQPidgS9iLSSMyXfmNZotwa | ||||
IolujPZjQHESNyRfmW0+NJFvePHRZ7Dx+olm+0MEupacuQ9zh1fJivRbzO+w | ||||
lUpNGxeRWLsLzYg4mgI7ce2NeIMf8M2Xp3MUwqdFBYjZFXEy+dFDp7pgjHFE | ||||
cKx2gSKUUM4GhS7VCKg0HZNy5AbIbJGX0dboOpFwmMl1P4mFEKfPDfbMBytM | ||||
0XYaIIpj4abDxg0dJ2uiyhLwJDLGUHxbING8C165FBhsoDetP5nkyJinUDzA | ||||
jETH+tFfKv8QXjnjMTk708Al+ecDxPtSKtEl7euZ/iv7IB7zkXSkcs0sR/5b | ||||
ohEwRBlpwxk1TVr0ESRpcEIDlrpkW+3/0loEHc5drei+5+X9Dxr2YU6aMMp1 | ||||
M0vBfhyvOgr2LBg9w7BLPWQPPYtjznjjnjHklBNd7fek+PlVgC/XXCoZoCcR | ||||
b8XZvrxTQYgnjKShIr80tE5R/wx23WNtjpnIV3+KCaJiCzslmARGtXMLbAgV | ||||
0wsbkhQkktCLBaZbhb1t2JbcQQ9gJkma9eNPhdjmTFTOlSLGSnY6hzkMUO4U | ||||
Zh8cZQmBInujhUWCR5L4M1ZncbNEbcOn5GLCL1/I3AbZ/JOdjwAtc0aXC55A | ||||
99AyJJckoeBcDM7eyfZKzrlNUKEZB2w4bah498R8iuAmwp252BIPhWR1O0Gh | ||||
wrbGfohkpxJB5IfjzNaRxcXO0yaALnsikVU6pilHepqphXVJruxJXYyGJ41E | ||||
pjFyhhNp8EIQ+hGulAOnrlH4BKhGZ+YKFSCbeQnGbyNw0nnICH9T2R7b2+Qu | ||||
FhJqI3OUIorugp0CGNscXBOGqLJpYX98/mwNtei4EXJW3tlNwn9WQNqGwP1D | ||||
QW9yEWQ04Di5npTfJCCGCHmd7BlL5DIZcIJArOpmIbgySdGOSSNKYlvMdpJ1 | ||||
dOQi9BEbHOYTjllKuJQ+3Bpgl3mLcTyjYNqlWwkZcO2XELnqDUelWDA3HAnl | ||||
y71qcIX+/a//OwATIo3cDmKksYEz62rJHfFS7uCH8LunMGskJIokHyOrIdr6 | ||||
0V8uSlBEgiouuRcSgeWwGS5r2OBoV+OJG45NdLe8WI0xzxxrLTl0zNVVXKgj | ||||
1xjCHIThdJREORExbrt+cskyPRyrU4/GX0dhv8hWh6dlR8JOj9bQ5SY6R9mH | ||||
GXs+rYsqPw1YrCke/gIjJ5KqM7r2cQbfbgKniDW2HK7EQMpAuDrJU2RBJjCQ | ||||
3AuWw/S8KYBtiDwG9mU0KZ0cycm1QJiNNy0b+KlEm+iODbspiQ3mn6+g3KKr | ||||
y+GM31bTu4VkzsqSTLHU+NcQtT9Vj1xIDGv78w+atomw7yHqAz+kmmPXopIm | ||||
JJJga3OJVs6GcSKciySiJBFPfixdPslGi7trSqRj31GDeINM6pi2eSEcJQq4 | ||||
QZ/S0TSOIeLnrtTWP1G9WiL7Bv6rc9YhiuEYeADHIMS0/UG3ArWKTzA8R8KJ | ||||
bbY7yx9wCxwjytjxaKJ6QobcMFu1Bcc4BB7Dka80TdXN2U7wMa24zDBkeuVy | ||||
3PdKbkn+YtvkpTKwcGOSCvmuG7U1Ozu/ePMObn+22//IrmJL2eYwqB+RBGxA | ||||
3GCVyq2HmXIEAt2mrVVzkfR3npKiL2tFnn/+jBkQpHDuIAEjv25WNFyqbcjq | ||||
NoQqBL8lrVNijLzceUN6CkV3fX9H70KnMWKRDmlC0AqgITZvAkB5O34WxOPv | ||||
IkX8gFva1WSpbkNbZwEhPMpOdP7Jt8oJpaLU9Eta9FijTIv+LnEyDgeFP9Ir | ||||
SgsUe6NbdAUvzJc5jVEuW8esShIF8VyWNpKVwJWNEoJkkfLZSL4JN7MRcHEK | ||||
ZN+o1Fq4vGXulUwKpE0b6jAMClhX/eLO7aQhLUAuN7pewEbV3mqAgu1uKWrl | ||||
7kxcAeZCKOpuhcEknduorpS0PylN5P58JGbsgPUjhv/8OeQw8MKwVL/DnMHk | ||||
HRh0A4caRBN79NX2oli6w1tImBjDdBA3uHzTQb8f3DalDvVE22IfWU0n7xzE | ||||
mwdXTWspfiXhhHR1Sh7/6DgDHAQd9jDNl515A+p4P+lhT0NPNxT+mGDT4jAk | ||||
DRdabMtOCz+IpQjWtOcNomnNQIRaLXO/2QS0Zh5pr5OA1AzD7OXRFySCzjdd | ||||
I85GpKl4SJ8t5GhZ/gAXDqiFh98YeosNKY25Rj6fXEk057d6hdb5cmZpYxFb | ||||
rAo50bBxHlotazQFqagoEaFJFkHAs8IWGNE9Q5fctkeTiDKBLjnoBmZQVISo | ||||
yi10Bom9szp5aogMKHMMJCsZ5VY04SPHt/B9BHIrmdKjC6cmpTQS7xYExJZ2 | ||||
INJGYmsteShPZYlpALkJ+b9kps06RXbENo3vRgFHkx3M7FxR9f0NW/ZZfTuR | ||||
aYwKEguonRezbkuYSpBbfpOSOd0C2EbcINiigx4Eyjp0iGaFwQFnclKUJaSN | ||||
Z9R+SEEDeOxWo70G3G4ncAKNRkeGVd6XNYxYsrVJ84qymDmtAPeR8bz1NYjA | ||||
p2woOjsNhHHJRM+ZDqzBJSNuCf42MnLwKlZVd27qo7amRyQnAngH/ZG7++Nm | ||||
cEmY4BGB9m67GKOppl03X3HZAkANLF58lotDFpaxi9oKffmyF8vuKcSsRzRv | ||||
1vJJhkSyngMDHXF+ND2jVdORORyxhYboIjwCsM7o1ka3yj7Hd0JbVewG5YIk | ||||
eXzjd6GtqgSuKs456bmCR7sRTVAZ4NGb7PkF9PYW6D87VEW1Wi04iVNslmub | ||||
J9xJz1JOZwKv2Mp6JaKK7e3y0TLEhOu/CloQSo/Q09TRB+Kaqa/YTnbCkpiH | ||||
sOFLkTwlMOhXviy+QGqGiwv8xKIdHkME6C6ZgPlkvefTuArgSTzvwdZCjLOr | ||||
G49qhcCORCzjNyS3wV5FIrn7YoLD2b4yL3Q3Kuv6frVMhDWSDKUF0UVnSQDP | ||||
SzBtHoT0Ln2mQXAJnaMiOHGKHtFV++TM1Y11QQrF3Wymoy9WRj4yJsD0c0bE | ||||
tmmOaFfLQKq5nPiTYhY5dXtbqm7xxoXvBU7C6PTk6ioq3mbfKlSZaJpAZgVw | ||||
ynkYj2aK3P9ehXfI+lZruTkPPmSHG9FwvyD21rlSzpt6vbCnxH98ZjNMi3oS | ||||
t4aJwPwbYZNQ8mWlG3E9vaa5PdH3Bub4N45L3ZlA37chihEfIQwbshhltlWH | ||||
ckF2dkkibliokTiZRgMFfWeQKFIRF0xxei6iM5tl0nAbeKa3pDbng823heKe | ||||
tXXJQDIN+CqPYZW6iUdGqQVMRLAtvHvki+k4ftcvCEDYbgm3nO7QllKM3sJc | ||||
2TqOODF+0HdR1rAqOxEh2LplY7ukA0mZCrBWMKJyb5q5I9tQm/RwcwvNzEn6 | ||||
pY1iql39iCB2X5hY5T0bfaybyFZ2OpMHACCGzAt37LIc3310FlYCNG7ZJU4V | ||||
Vxz7ggTBKwkGQh4/yCY60mCg5VS+FjXptQE5VDCkgxwv+HZs447LVcXdDHYt | ||||
kLUtFhfwZmhJg9YZgFEA6rmaovxVmnHhd3RDuZg80gk2qkglNKmfO0SvFBnU | ||||
BDRIhIeCJRC6UiEtKtAbid0XbOPpcwXyHeYBMD/HAltCCGM/vmEod2jSrJfE | ||||
mFzeyokc7p/WqIdl9dGbJXgmJKFWmnxqpWvRg0zQJY5rZQ3DfN18CBG4HprD | ||||
6kMMFvBQY8P7C2m/tpTBd30dRIpnqubONB4yYCA9XHkdbEG+2Af6xDBGPWzz | ||||
sjnky9j0bSkPlHFWXDnIFX2lrnlr2D8U9kAVtGncZbNbS9LAHgf6gSMm5Z/y | ||||
xBPCwigcsI7Uc0Mhc+gEKB6cCTa1hbXEAyG4SmOySH/6ljQawGDUr+AorT3F | ||||
Zvcc/9TGpAF34nqiRkm7LJqCdQGbTRYjtF4kBt4ecMxGgnJiKNOF+L1jQLB4 | ||||
PmRMsy707SIkthNwULibmoOcNSsb9TbKdk8SRWJmfgAUrboa5ZqSGl4XcFVg | ||||
n9xxgT2a4g6404UkhogtGHxrosl83bhEvgR4d5Iv3babC3zQRlj1xrcZyj5/ | ||||
FwWHNOnSOmtbA9SJa60knfMpoUWRoq0QbVuox9n3L7d1WPtmXyOs9zsdAaUR | ||||
4Jn/4UvAN2ggQhCb8GGhRhbLRNhstAAVKRKe91qf0mP8FFm6EkCNn37NDdME | ||||
5AgYhPVxTNt/+CBy5KhJ+bomPKM2hWR2Fw8eLTuKN08fXxSKspHSXTF3uUy/ | ||||
rhXuaQuS3JK3EoXErCUnfHbTXNzRsR/tweDbKnoC5/grvSKc9t7iUKKFkWFo | ||||
AzE1WsmSIQ0RWs0+p1cUPv2tOGEAs27vmheBEwD3kt50HLwLSSMfH9oWPNCu | ||||
lKhCdNqZLUKgMHm5koxkQdtK8TTiHRzUcx5K4d0PxCc5OOk7m9R+wlvjIzYM | ||||
DLG2AIKl4IuA2CHC67dJrT6s8UF2c3lrnYqeHR8dRu3Oct+ETxp6WfUbDol5 | ||||
5Hu/eNnzpfyU3SLVB4jzyR17Jpe3J+QUvFkLfynuFQcZCnCJ3PQpRVpqz9hm | ||||
VWrrnLjhgYJ5F4MUPMM2r3Qw9L0ClAT+GtixaYcS69hLe/shAjE/kTGPuPDT | ||||
es9fAoYLOmasQspsiOTYBMxa6aMFFMOqivQmbQmdAlZVpX2Z4EzI77UZ4UQb | ||||
cfQSD/TRBrgb77asYfgO2LbQbppmxoegDMPwBOORGIESVhbJOWM3ZlU95pW4 | ||||
IKGBKTPsKMsUao1baFdAemRIkUNCCdkStsPcGyOPILjm5qNF+eWA4mAgihVt | ||||
DaLexAJC3IaZHXHxStxaHvrnZGoWnWHvvDnEJ0zra6XHYO3Dtt+gQRR9RXRt | ||||
aLeAWFhlhpgc/FiZYwKPgA1FiUGHqZER4l4srcK6M4joNJAOUgw/SOrYP1yS | ||||
4LYJXRs7ItZiToWhbSV63ZY6hVoiAJGmCMKQEUhF12l9KmAExLh/u/xoouH5 | ||||
4dEBiQYJaMWIOnW03EJQ31wvrXhyTpXJNmN9iPNBnWjFXSoV4Bq3fY6KwqVf | ||||
j+59kPGC0PxDHqcsHSRahFiTXCxdaSZYCIxZqd7Qt7MUpQcIRRRo4jeFyDGn | ||||
f9DTh32NBhMIwhpECIJrnxQjNxr4JnuahrQkxAlLiLj+fS20FE5QcZJ+542V | ||||
j1nACsyBHDBnowJHRjqS6OPJq51+Qq2IQmCtvsN6h/Ht1eSvvnrA8Ogx75Hj | ||||
pFLgyhBGrMRj9mhlGqLqWyNa96p6sVWod0EOqLAK8475etEOIuXbzZM+RSFP | ||||
mCIFNRCfBAEHVuDaS2xK60F1B3bEGDyLrOlTH5b5/F1kZXMFWRC1g6+EcpK2 | ||||
b0mgKjizApzrav6qxAos0xQn0qwjY+bT9dItVHgBmfR8WUyFicSJ4CoYRsdg | ||||
NrY4K5N66fw3Qp9L5FklhGFgE9jS4i8V3KeWW6kXWnYpYVtfpRZbwtsaH/cb | ||||
oW1E3tKjW/BoYo3EhGyUSMKljjHcGpMaZZ/aVZD78Z+YyKsqtM5G+65V21kc | ||||
I2mX1+XtPYrDMSq9sg60OcdNmNVYzLN16qtdlwBFsqWlhftoZArM4C2kSkDm | ||||
Bs4TmkI4sPNtDYsCKeTuS5Djjk53TqZXRPUntZQkSLN5knVDQTjA3NK2R7QA | ||||
clsRar9Zj6HKug7ti7Wnme55LSsOFQiWRJnMXY7mf3r5XMXOzFbCM30klQcv | ||||
OFwA4jKAsdxUuBxt+X4TAgGpFJXueYs42OKFwe23ZAsjO8DiKYbrc9K1zvdh | ||||
5j27hk+icWjqopg4RmwgNRZFW9Sp91wW71HOA3U5DOMORxFgnbSLejak/2Or | ||||
XMnMkbToSWII1eh8/ciCNg6aEdUWS7sX3h7ak8yJPpwD7998ush50buxqeZ+ | ||||
d5MVw/oa6YEK3vDopjYylTSi51ulSNe5r0Ruvo+SFwNLCIV4qkoQhSuHIRTj | ||||
JHffq2xP2xPhEeI6D4QflULo9+mmvSyvxdBUvPkPP6I8IGqWfesLFmbxFbBc | ||||
Heo4XbXStk696HXklLmtdPDTFBI11MN94ss2QS7bZQTubmw+RYj1oDC0f68F | ||||
HaJ5DxIxxs1qRaaLRNAwRHzHQ1ZE2t9p+tKTHC2yYnp4VDkpeqBprTDVrZ2+ | ||||
iscq0kLLJBAiqGkbt8eBXeRsXbOopabYixNpYxuPzeDiZgbOa8+QEAuzhlvb | ||||
ta4UByy0jcI2XgvZB65LLphjA+iC293x75JXqqhPk4tPFHopgxUGsdXJNBVj | ||||
SKqpLDEeyuO+7KnH7ktpLcwkxRVYitRQSNuBGOQcZefEP5PKAaRkfZw31tgh | ||||
k0uSp+kE6uShTPCvM4uP6lv+hFFTVJKn9hEd31CDS86JpblUYJWkjImoHhDH | ||||
VekcRNAEu9kW9gZvVXw9moNYhiKcBn+8fhTtIXFPUo0NLnLCVoYyhCANOSDO | ||||
+7E9vgH5BPCRjcUPduGJrmGGK1mLkgAlho8CVhzZ37YmFrfcj2CrpWsdg79W | ||||
9IEa4o0yYDkJ5dtgd8C38dE0FmGhcNhqqELPmtwrITUTYrtNE6RRmFFqw8xn | ||||
EIxXBDFnl4d73MWwr6KaldxzKZSAj23YXZpnIG7TLjcKHvtqR86RtnPfKBQf | ||||
hJYr7KxEakbCK70lF21vtIeG//SqNgEOCdS9cmChHZI0iwTThQd2Fe3cJpTl | ||||
W7Lo43q61qHrIWKqAw604b0fOZFLjwmVBcGlvS/U+EnK1dj4Yl3ufOtdcX4T | ||||
nfVkN1pOu7sn+KjYwGdoHPfylY4msJ/jvDfb0lrCKB0gELdoNdQOB5DlpcKm | ||||
2g6DL6ZpsXkRtcCw6t7NZoXIuodsva9lhf+EElr1XjcraTV51w/WqzXQ+wJ3 | ||||
XIpm0/xnAiY/DQUsfENP2F+g7aDUVsTx1Up8mSeMHtj7r0/i0WSw+WQSrjf0 | ||||
9jHZtt0P243+OXQVt7JSlbKdfURcxVyCxSHq4buDD9IyHB8OkMPzTar6jQC+ | ||||
ehIbpa0R6k64DdC0UJXaepGfsOjXm6hYGQ2HvhU/lHnwGiPS8NO2Klr2u09P | ||||
yIDObYm09HndxC/NN15rVS5y6ziLp+vXhwDij44yt7y6Rd0ZGCgog3iBSc/a | ||||
VJ4EyRkESnC3RZ395+nJ/ht9P9mPq0Xgo0k+nuE3YKM9ASiapNFwQhUhVphD | ||||
4okprWgdOwi4DpEA8KZDCNpIDS5nCi1k3uOKUP6jJQMaMQ2lxAFurxZ662cy | ||||
/KCYl2gsUpmvuQ4ZKieQ19d7V+xUVpXJ7o6nkfg2tEmsIK0O0ULKbq7lTIWp | ||||
tQhks7MT6XSbJ6GvY7iSTUhgG8iQ+r1Sym4j7DXKuEC245EqretWS7l71R3D | ||||
tXvBkW8RVysqPBgD2U0VxxPfGSzBnnv+0K4imk1Me+ddfnp/e3Fze/KX83cf | ||||
3nPZwN4PqjfoDRKmjc7IeoOVSWW96hlf9BZU0diFakCul9j5Tga6n8bTTG48 | ||||
YOus/hEDW9LJM3Q2hVJRKM9qbyOBH4VMpLD1T9hjg6/GpaPJNYjDFWLyKvEl | ||||
EIEWGIz5jeyUaVM89K3WgRZoiSL1Herae0F6bnYoV2aCd6LXTkZU4fm1wGt9 | ||||
2pUHJmElW2cC5FZZ0/MjpDsHmVz6sQniZYgi+aGBhp0sLHUt1txm2Z0hMzYx | ||||
G2oHcHtvj2JH1N1a+EixMDzZxsGmAPaGFoDd6ISwlD46lIxnVtDt15bxb8jH | ||||
B1j9fbgOn78LpgqXdXHN8ZaZbnMptSrX2wZu+k7EGxnl2DoYKKQ6PNS3iAvd | ||||
VMR2au0HThtyRulxT8JDnEHSpLwaV2ye++61iiXxLauqaaJ86WJba53fSBO1 | ||||
iFGyLRZcAFuNckPcJ14Kw0N95KwgoxmjgiqzxkNUzs+pitvbG7RIzIA8ojWK | ||||
UKUNAbgh78Iv+mP9xt4t8JbrtjlSFtBgnRx3+EWuph5wBCkyq1vfOlhaPLeR | ||||
FWuv8eV0ph77QOItLXK4YOZiFm5n39v0ppl2NvdHqBFjvHx3XAgGaNfHc7jq | ||||
Egz56cbQb9b3btDP5N2tYFB4uzuLGvGl5HvUyMi04J5tcxWBln3Wi8rbsElI | ||||
iEqkajTXqavekknQW0EZ9eJ7POYxTGcwcdyzXDHfi5iNnrvKe4DY0PePTRit | ||||
w6WPL7l3ZnhtLv5KNLloIn2EunnwmtnKEM8fuFIt4I7LlENK2ilqlr279G2W | ||||
TOhXgoaSjG3Mq5RjTpnnS5sxBpvUtbFTEql2P0RIh2Gy+lt1tJwYLSMahmGA | ||||
6nJpN4x/Stavj2GEln4Cu4IxYL4HxJ7Zi1ItFdeXREcYRAIvSm3rTjpSSo6Z | ||||
FM+qCY1G7QTZ9bbst7H8KNtM5VsHiVZlHc+1i8s6owzyXLCDvqOr79AGI4iH | ||||
t3A/swTxk1i/Cn4wFJBPQ4RAGtes8RRKNkLC6dRBAnANm17FATewJH3f+aoz | ||||
RFDRMCXUS0XQVbQoiGN1jEUQI/EHmQ6U3CnJzr98+eoAE8U84nIsmtAk/OYy | ||||
kxlvQeyaZPRVK1AjYoxw2oCbkdxJsruQEWQ8dVztlUFkooQpmgE1LnILkEYi | ||||
9rxY7tmrMZ6HdY3McKOtaxwcnyfLReZkchwhDTVwNMvahSSI2N7cldA9W2yF | ||||
t9x640wGgaoy35gXKNPFv2w0FxGYUh822vTAOCLnm7xQVOg2s2PqFwDm516R | ||||
ebFIGzOFwKlNsJy+xiGFKaaMne/VsH8ZaPX2htkC8ZAAROcyVEeh6Fw9vDlu | ||||
cgsgP7KzNaScPjfq99Vfgzc71Y5Wx8U4NsYdx8ItEqBxnq7JGU8bsoYeY8Tg | ||||
MT+8pFexqmn1iLBqa/MhtGnDy5z4fN0y9FD9aGy4V2KugkMcVZbBAUzrkf8e | ||||
b6S4GzYaNXnWyxZ9pTGRVnGm3QRDc+DIvE+6HvnGRTa/znc11AYSpmr7nQrB | ||||
MRGEK+o1RQ+QsV9+Nrunk9zf1hp4CRBBYBvbbgICFbT7OFckx7ClkgS8IgY7 | ||||
rzh0hQSGqj9s2tnwAyjd320aX8C9393BSbfKF5X8bCqosSfj0cShNW0v13TL | ||||
yqxliEW6gZsxKFuKTqDnPDHtz0a/H+1drvcMhNsD2vRH6bK5ZiluPqJ8Mje3 | ||||
N8wrybPdfv/GxLHe9XBs5HybfIaN2ti00LPIqlLjvimW+YQxr9NEF+Q/ybTE | ||||
KM8durNzWTZLZqmU3VKpFrVtZAyHTSSrfWvw2KgF2CG03iNqSNq+qyNyuTjx | ||||
GMENAmTenAc//esbHShoX3WjFXNJGEi4qtvuzIt4qsU9QXm76DNMVLPRnZsD | ||||
ntNsyMVHniw64FGiwouIisNLATgwAkIn9Ydx30uODCuFMPE4C61OQFy4Q6tG | ||||
Ok5vxmXsPpuDyH2JfD0DfgtLim+Mz0NtrMhYNyhfP16cy4zHSlTfBYzBiUxg | ||||
vX4yqIYnpcpt3lBNwaQxCSXzkLTTZ1l6H9ZgD6ZaR2nvDPata+/6hNf2yxDG | ||||
3PdQrBz5rxXQM6aKAzwR4Mh7VIJ50kJWbTSsDazIGrvfeNGu9ZlacNncuG4a | ||||
wVSHYdY8zYcbLUe1TlFI0U8xDdW6WyZKGao/6dH0S7/xr4ho7Ykrq/dDbPu9 | ||||
j9T7QBVMaDrI060kJBwOTatCBKYB9xDQSwnXck8Jg8xYBkMHPpH6/FBhnFG+ | ||||
cOwIsHhR+0mEeFPf6UUotBG3OOCfP785OT19dwHlKIklZQxu3OGbPcVMNpSp | ||||
eNPYiHu9s3M4ksCmZk9S92SjXiTXgKD6wBIxEMtRW2fCnPpx50ifOiWJPGyd | ||||
wLZSwjCgIpAme6Jj7NAyEpn1SbsnzXa43m9etH3XW9e4az07f9w55qiR4ri/ | ||||
+gX9vDRUZHb/cedpoELpZgAARNvxcXX7ZvrcH7NffBcMdgHp/iKR+yMHi5Ml | ||||
audS3SZLO58YLdc/7jzTZdhtzyW4Jnh4Dvp8dVf//td/17f8+1//48ed50IK | ||||
bUvVuD8iSvJ1aUtpLx5E44hNpk3dDF7z9EdPcJ6869jZ2NcSfUmmpwMiNISC | ||||
Os/pj+Lb3LLbkn1kg81xOPutz098/m61ZFCO/cKH6DVcIIO1EOPIJ/fq6G3U | ||||
GeHzTaEGnVezOspbFd5IF6K8jAutRd7LaGUhc2LNJtH6tGdyKq5HOsJa1MAF | ||||
B9pPDNlYJxfXNl3Uzd0XtfSDWgb6N9MN8KsUIW1DyHqBrTwTD0MqLItWbDVt | ||||
VaudktOWF0i2WrFbzXPVFQkrFfJqyGVmRedT7TkQY7t5KIXekqrOdiPfqCZ1 | ||||
73YleV9NFV1S6Px4WriMVDJMYA9L13NBjFx5lN7CpKXbi79e3P795vb6/OQS | ||||
Q0Sky3I0U04hWRmwvN5gEMlmdZJ5jKKXFNt4HRdkbDQKCcgViyIH8gWrDMg1 | ||||
wfJ7miCi932n9KiBjBe/K0TmibjoN45fKtWi4qM+7yeOvq8dH0vOY7IGZkIS | ||||
37no5bV1b+41du8l4c4uT7iBwq2yAT6shVdhnSptttb3VtZzNZxY31CRIFNU | ||||
LDkGWlbD9WW8/4yRh4txMunQg82r2mZWSeS8RWDVl3hbPuzz56vzX4akWE9P | ||||
fvqgoxzyLlm3tmm1TbHXr20m4+duOS/E1urptA3jI6OR9iEnMcpu4viloEnh | ||||
n3juEJaBxVBoL9tGYWAbb/ULTSe4ZsuiwzBttUg4zm7YKpVOIqtxQsks0njC | ||||
T1nkRVsz6KOappFajcL5TEMYCW+BNu/LaBNEUXv0JQsKx4OdQ/JC1kp0qsLE | ||||
CvPVtvJ/yl8aTzuXdOaNL+P8/J2O75CUQpSs0Ckhm32sPLgtwNO0g04T58G/ | ||||
mpBj4mi3ZfYbLdJjc0k0FsCtdn6HiEEUZV7riEnhDmvtyr4d3BtV6EUTopzq | ||||
QPZisbsw9yt1PaVSlMzhaY2pc9rrWbEKEIkhhdze4wAQ01C4qSyk0ypKn2TP | ||||
vfxIHlnYsJwiab3aDxWgbvvml4tbuopXP335kkQOwkVQE9zmOqHRXzEpOimA | ||||
53FlWmwVFYGG0l070h44Ww2cUExl7SwjGwTgUekFxwqKx9ns7Hyo4raloY0l | ||||
Kxf/WrW0N8a2lNph8wG1dWNks7RYOem10BuZmK5VDB1rfZlqxpjwHAf0JVS9 | ||||
Rxq4lD36QW8MhVb44opu4irMYwKva4NWKwktmgAaUXDJByTYbiR1pFhW79/m | ||||
qnG86U0CgB36WWRGWN4jtFKdqdqNmrZuNFbivh+M2BZgiUcO4Mt77E+rhj4a | ||||
HeKDXGt8dPiSvGvtJKn1C/b+KASUNHPeVr+xcYKaw7RVhVp0rjuOuWLjnJr4 | ||||
5MdrM/6ikkYL0elSVRaxlFat7XGbCKsupG6CuXMBT5pZn29/VPnqw9WDBIKP | ||||
6niZn5mMJhHBoSB+Y80gcqLWaAatlTa78U6B9zCViT9ZbM8DPkwiJJmIsAxf | ||||
atxJGW8AfPHslpZj6lI95NsKxE0BPMxM2oaxtSyPqzhhkNxRtvl9URgnUrh/ | ||||
mE7w80u1Knj3ewebK5RDs/6DfOX6eGGgHkHC2+KYv/FQHnbb+x5ET11zUpL9 | ||||
beaE1wn8cQ9BCUm6MQ+hVsmbN4kutafJuE2/alZXosvI5FwHwZc0ZCpmiVuF | ||||
1Jx2WWMHIQYghs101rvLT26F+SlyN/FLlunMj63L8e5KJ535fZY0wnbONnkx | ||||
tfhFY/rJUYHycpyLGhpAR7qKgIjmGEklb0/5cFdpvROF+kIL4tAHZzPuDcaQ | ||||
FFGIjrHxBUE3RONgo5oSzYKLwSA1O+Qk3d5es6N0Pvx4/eHtxe0NkrS/AJoA | ||||
Xp5uA3xp70az0msLmcuogPiEA8iOj2jJ8HxogNCIapDAJ9Qb4VCBb49QWEL0 | ||||
VNXMmdT2q976yAHtz9/xyxBftCYpt3ObBF7bSNPQt4ZPxAwpvve5GMk+l+GL | ||||
r5sU65P2EBD/I4xVEXwAJzRgRsuHhKF7s1f0lF7zJOFzS4JhRPdlWlekEKbI | ||||
b+g3ZNeKCSnalI6nuY3y0NanvWlP1ttf50utfdMOrEyH//nJk4yy0uauoc+3 | ||||
TeJgUd8r92p1mp9VjPOzrMEQj/oz/tZqSpY7GO9JFIvG+FkTRU4r8mn4rmpd | ||||
OhKUVj9s+Ygsk2XT2LWiXQJbPE7XnJWQdmSLZZkXzZDXMF6tXbNPCywZW53z | ||||
gX7+fHpxffrp/cn18PTD1aers2vUjsmI8BvRUDJh/TSIA5LmMVvKGLoeH3Bz | ||||
WUmjrZqpq2JtisNnYIjO11EFHhKs6uQzRuquklF0JYaGz2otne8FghjeIrPr | ||||
vhHBUNqp1wow5RBzZ93UB85k24nsoa2/yx96XYSgcOqymPanrkg5bHQPfP/u | ||||
LUOT1b1ORV0/CGTsGpdGYHCH47A3GDUMAa3V/9IWGjz4qDZskHYA9zD5Je0c | ||||
8fFItE63jIn/KDUARIW3FleKIhhJmYAavP5h43VEp4AvyK2PUpQ0C8AzP95P | ||||
0ykSt4L90BQat9UaC980b/T58+XF38imvdD7EGz/WKb5uRwWhQtWVTYGzjJv | ||||
tgEPU9yRL2H1vZqkSMGHI9BIJselYQCPcfhAkj0yL5nvfj0EVMPxELp6TOIK | ||||
X0DAOij8Jxacgtn+6uj4gDv7cliS9a2vMuFT1sIGIrB0Wum0d2KYcmqROTi9 | ||||
UnXmc5ExjE2njAQ5X4RR1zbloWh6eMJdeuzkfr27Qb6xb4scOMAXACgxTEp3 | ||||
YbKY3hRr28GSBrHDsU4jLBKGigfLD+IqTwm/JJj8MCrVfItgrqfeMfbi/czc | ||||
z6DbSKdeirFq9WhNKOvPpSeNtkvx0o94YTfaVoExHdIgW3wuZvLdHD2cdrlL | ||||
Uou559bMjHOH4WHqTsDk7xiEHqaAZr7Kkx/CN8Bn2Q0c11mdGPr43THb8pS9 | ||||
VrGUc0lLWgoyFzvAuMOqRuNZfo8Kiy25mRWLH5YIHOCnJb6WcRp9YmkERHtv | ||||
y7lLdJcFbKpiZFyQ7SGa1MGJ9GYdFic1KspzDwLoFtNa4QA2tmDraqJ+jFEg | ||||
rR7LtMDQf6K3PIMldDo8tF/ZqEaNXdiKgZuhmKXf10w6mfcCOUAiiCRw0yxl | ||||
J19T5UmoMGu7aZYVsJoDT75YYnGUrG5d/+FSE8+DkBAr5f5oenHK0htDXNeX | ||||
4+JxUxI3y3EBUQIe1/OvFWdZrgMVIvqM8xb5Is/sljef5Oz4hDY8YRhVogFA | ||||
oxsf7yMD5+r89DYjj3ZeT80DsxjJq9Hx6Ll9iUTtQEPwbqqz6kLWK4RDGA6u | ||||
SaLBdnJJmugxiRhwpl1sK915OCdubabH4GOVa6GR6HIv74Q81houwtvxNA5s | ||||
7seL4dmIlrVogb1dFKQlZzb7HZfUGpp6py71NzSkI6N4Ykm867HOnFKSBimQ | ||||
YAqq49yoBrrXoQOnttHVEUnsHGl0bazKsRd+6if86NLr6VoP/njFEZyMjV2b | ||||
ywmLt40nzXBKoKdanBQ4cewkjHOSbq3luv95rJVvYI+LjkcvIh4aZVt6WrIh | ||||
8vWeuRGIUGU7LQWlxhxxS46Hx+36HLAFvIIojp1QeKwYDWmfSlIhen0EpLDW | ||||
dJ+YIdZIYbVkt0BSDmJAvQlWE+YQs2j5ovpwC6Aq708ClrabXG3YcSHiLnel | ||||
HHKBwG6sMH3BXS/GwLjxaGBLPHKC8Sm9puPoY6G9PidWx9SueI7LJhou1dn9 | ||||
xY9XBcmzXQkB7OrzF33JHTfZiJqNW+1/bPqkTeE6SxIw1tNa7ArMjf26VOEU | ||||
bQqxjYW92TfaIEmRkpxk96KEPA2YlNP6UWujglSPBHrUmNL6pOF6eq95EHcL | ||||
jipI5ZFiwJdahNcOQj4wF5fSKoIxnoxvY+MW9YOP44r+3QsRV7+Y2IKLRhKh | ||||
86WMRBOE4RydXj02X9UGuzTezeL2KrVOWqAlGg353sFwKqLxCb5rCsyT7T1L | ||||
4wYn/iWMLPRTE0vuCoWmciRsewWUxKboSWVOdRRGZU242fxLfBtvJga/BnE9 | ||||
LeCsuFA+7lsgLSMT1dI7+Q1u87hAtaGTJ3FnRuBlVp0fJexjRkUXYMFsi5pH | ||||
JyOV5IB8e1sxtQTYCOimCmihazqDRDwbj3qMVzyIKclqa8F2IQK9GxOjYmcT | ||||
PqSAekIjeku/qXkTwngyb/tcAsBqLZ7mwMXikD9/F2K9Wu2lMvL7pKTMMcqd | ||||
tVXjO29b/1bpgLpwThy0pNadRZRNu6qkrNO6mpjBF0OTyfOclTk51/kajic4 | ||||
dnnX5NN+rB1S1pqqDWKRGJXA+q2psSfJKB8Lz/y4rDYZha4jPZJpgjLZh72m | ||||
IIgk+QZAi7TJiJs5umjyuXdjRdiH1yZjOcOgHo58+lJi9ZstRsoBqSAIjRFg | ||||
P4Uy2Y0s/XhtTtJX0gLS81HVtiWv2jil0DUrF1pecRbeJ1s82EDLgS2GHrVl | ||||
poOQVKw0HiWZvq1R8s2Hk49eJ33PRQr0G04Nchonm5Xu9yKCcwHprKLNvzQC | ||||
mssKuU+0ROPNN9HMwhb3XsMBdENc03BvEiNSNNVDrroIlqlcVwuGqmO6NaFu | ||||
5ro6chLG9xAHDdty1bOnl4o97punGc4u6taJpnMrbfeQ2lYSpJIbZRBYXClL | ||||
UfQ4xGozFmq1wro05T3a0lbd9uAhJtIGKpluE2eljY5j9FeOQlt+9hy5SKVr | ||||
E6y2tlNJ26PzCbbhcqcxJA6oM/Ao3IYkYUpH80YaYnr5FT8K6ZjIIN92V/Ni | ||||
S71XQDnOw1jhNIgnuTJu8hbPgEdKZGi73xLtoRPmyZgMMGWuYzU0/S2fxDAZ | ||||
1uC+mUhNilZ85q+g1hg4vwEY67dqj/F1F2kpTREmLSuB0pZUjCGN627Z6+HO | ||||
IXEj5HQNaqBsZq2tBVbeRZaUGg91KlPZd0fmy1+7gQlMi4uQSOdy202gWMBP | ||||
oVYc0xa4DeNCgQziC3r5yZF1aB8uU9ISZMWSRYT2w76fmCWHJhPg0r0NRlLF | ||||
fe1ABwYr/0L3Fr5Mg1990YjXZhEfzz5pVa2HCExSuBGs+eWfmGrgm611aRWZ | ||||
zP/QopHNmSMWDon6bKg7Gs1V+LKXukK9koQwgKQ/TSoMZLA2EDGYj6NnUbqB | ||||
aTYNLeS6bRXPEhjQQGrjht7QCIJeSSF2Rx/2E9USRbVwUbfFQdoFMDoGci+s | ||||
h5Q6AGc1eI07SGU3UgfCo0S4ra1qJfOnfCeXkASVYg5pqPJ2xbkU8I80T2Eo | ||||
io3csN47Mrq4uVtZs8k+Vla7a7Aprl3BZS4eUSvus2AtDLSvgZq8xcZ0mI0k | ||||
q7VJ6/GkSQkGfLBs97oxlyRD3BBELSPujPr1yrBbLTLBd3xxniMdVwvsWAYf | ||||
V6r0tfPTTOgI/fkDkW017kqNkjRaiNwowNKmeZK5Mcqu6Di+VSTr369N6AuV | ||||
kVbt8oNEaR9hGeaNNvFKB3Sx/LIZTZqm1natEaLTMF7cKC2sUY6fu+/wgHTp | ||||
vyUtWHi4kveD5/Xj0LeVYPPXTe6BbNdqq7z03lEfgvlm+4xRrKa2CNzKmmXV | ||||
3KtEiD7nLuyA1RYzKbWU1ktKNGndocJKg1LodRKX36H/dT8nKxWncavntTTE | ||||
DncybSXOGfno8xwG0ghkKObpR8tKrqbleHzr1QOa3a03SlK5FR1o1EbFd8pY | ||||
7E4jeyxdiAB1VEwcO+L9gZ5MxHRySr8brwln319RapA1n22VwAFsYHW8SQ+E | ||||
xmk7E8lw5yoAVDj48WrwEL1nLPkGDxf3acQ35+9O/nrx4dO1CHcSWzeWDE6r | ||||
Uvtiy7scmkrWrsw+lRzmHGxG/azZH1lyg9iDMNWwvY5XODnPFuumEMMgvIzh | ||||
+xaVfJyvNaQN1eBKdtubdVQZhp0OyV4D2J43feI7Lanf/Pk7dOreENbcgrcm | ||||
aQC/GQJYkjBR7SRfwzeY6oTJK8Q7mJLNxkaG1hvaMJm91r4gPolQ8tmbGo4g | ||||
yQZxANmnkPrDnxwZ2dm7VdupsLwsSvzzciUoDu1MQsZ/z5oeRClBYTVrUiUV | ||||
w1rFoa/5mWQBLen+vh5kf2m4JJbESTPFuKrrAkPDp9kpXccOnHaKiP5ZDSat | ||||
H+nHOX+BaPAOHdoW+SC7hE1EH/pLJS0Kz8uCmOe9wx38uZ5X9M8HEruD7JYu | ||||
3Dr7mK9KBVde4rYSNSVhEW1Pr6ZePJGcYiIEuEynHZGGekb/hUzHGZr1ASDL | ||||
cpMFKdfuJn2F/alcVOS+eYuILEOpl85+Iq25DHAprsKEYRCYQRxk56ZgM6Lt | ||||
Va1N9Eu6hSsE7LhdYyvFOlaGIwnLOGGVDAsY7fx/riCJtprmAAA= | ||||
</rfc> | </rfc> | |||
End of changes. 117 change blocks. | ||||
1297 lines changed or deleted | 726 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |