<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.39 1.7.4 (Ruby 3.2.2) 3.0.2) -->
<?rfc tocindent="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?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" number="9518" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.18.0 3.18.2 -->
<front>
<title abbrev="Internet Centralization and Standards">Centralization, Standards & Centralization">Centralization, Decentralization, and Internet Standards</title>
<seriesInfo name="Internet-Draft" value="draft-nottingham-avoiding-internet-centralization-14"/> name="RFC" value="9518"/>
<author initials="M." surname="Nottingham" fullname="Mark Nottingham">
<organization/>
<address>
<postal>
<postalLine>Prahran</postalLine>
<postalLine>Australia</postalLine>
</postal>
<email>mnot@mnot.net</email>
<uri>https://www.mnot.net/</uri>
</address>
</author>
<date/>
<area>General</area>
<date month="December" year="2023"/>
<keyword>governance</keyword>
<abstract>
<?line 325?> 321?>
<t>This document discusses aspects of centralization that relate to Internet standards efforts. It argues that that, while standards bodies have a limited ability to prevent many forms of centralization, they can still make contributions that assist in the decentralization of the Internet.</t>
</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>
<middle>
<?line 330?> 326?>
<section anchor="introduction">
<name>Introduction</name>
<t>One of the Internet's defining features is its lack of any single point of technical, political, or economic control. Arguably, that property characteristic assisted the Internet's early adoption and broad reach: because permission is not required to connect to, deploy an application on, or use the Internet for a particular purpose, so it can meet diverse needs and be deployed in many different environments.</t>
<t>Although maintaining that state of affairs remains a widely espoused goal, consistently preserving it across the range of services and applications that people see as "the Internet" has proven elusive. Whereas early services like NNTP the Network News Transfer Protocol (NNTP) and e-mail email had multiple, multiple interoperable providers, many contemporary platforms for content and services are operated by single, single commercial entities without any interoperable alternative -- to the point where some have become so well-known and important to people's experiences that they are commonly mistaken for the Internet itself. itself <xref target="FB-INTERNET"/></t> target="FB-INTERNET"/>.</t>
<t>These difficulties call into question what role architectural design -- in particular, that overseen by open standards bodies such as the IETF -- can and should play in controlling centralization on of the Internet.</t>
<t>This document argues that that, while decentralized technical standards may be necessary to avoid centralization of Internet functions, they are not sufficient to achieve that goal because centralization is often caused by non-technical factors outside the control of standards bodies. As a result, standards bodies should not fixate on preventing all forms of centralization; instead, they should take steps to ensure that the specifications they produce enable decentralized operation.</t>
<t>Although this document has been discussed widely in the IETF community (see <xref target="acks"/>), it represents the views of the author, not community consensus. Its primary audience is the engineers who design and standardize Internet protocols. Designers of proprietary protocols and applications can benefit from considering these issues, especially if they intend their work to be considered for eventual standardization. Policymakers can use this document to help characterise characterize abuses that involve centralized protocols and applications and evaluate proposed remedies for them.</t>
<t><xref target="centralization"/> defines centralization, explains why it is often undesirable but sometimes beneficial, and surveys how it occurs on the Internet. <xref target="decentralization"/> explores decentralization and highlights some relevant strategies, along with their limitations. Then, <xref target="considerations"/> makes recommendations about the role that Internet standards can play in controlling centralization. <xref target="conclude"/> concludes by identifying areas for future work.</t>
</section>
<section anchor="centralization">
<name>Centralization</name>
<t>In this document, "centralization" is the state of affairs where a single entity or a small group of them can observe, capture, control, or extract rent from the operation or use of an Internet function exclusively.</t>
<t>Here, "entity" could be a person, group, or corporation. An organization might be subject to governance that mitigates centralization risk (see <xref target="multi"/>), but that organisation organization is still a centralizing entity.</t>
<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 target="RFC791"/>, BGP <xref target="RFC4271"/>, TCP <xref target="RFC793"/>, target="RFC9293"/>, or HTTP <xref target="HTTP"/>. target="RFC9110"/>. It might also be a proposal for a new enabling protocol, protocol or an extension to an existing one.</t>
<t>Because people's experience of the Internet are not limited to standards-defined protocols and applications, this document also considers centralization in functions built on top of standards -- for example, social networking, file sharing, financial services, and news dissemination. Likewise, the networking equipment, hardware, operating systems, and software that act as enabling technologies for the Internet can also impact centralization. The supply of Internet connectivity to end users in a particular area or situation can exhibit centralization, as can the supply of transit between networks (so called "Tier 1" networks).</t>
<t>This definition of centralization does not capture all types of centralization. Notably, technical centralization (where, for (for example, where a machine or network link is a single point of failure) is relatively well-understood well understood by engineers, and engineers; it can be mitigated, typically by distributing a function across multiple components. As we will see, such techniques might address that type of centralization while failing to prevent control of the function falling into few hands. A failure because of a cut cable, power outage, or failed server is well-understood well understood by the technical community, community but is qualitatively different from the issues encountered when a core Internet function has a gatekeeper.</t>
<t>Likewise, political centralization (where, for (for example, where a country is able to control how a function is supplied across the whole Internet) is equally concerning, concerning but is not considered in depth here.</t>
<t>Even when centralization is not currently present in a function, some conditions make it more likely that centralization will emerge in the future. This document uses "centralization risk" to characterise characterize that possibility.</t>
<section anchor="why">
<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 Internet's history and architecture as incompatible with it. As a "large, heterogeneous collection of interconnected systems" <xref target="BCP95"/> the Internet is often characterised characterized as a "network of networks" whose operators relate as peers that agree to facilitate communication, communication rather than experiencing coercion or requiring subservience to others' requirements. This focus on independence of action is prevalent in the Internet's design -- for example, in the concept of an "autonomous system".</t>
<t>Reluctance to countenance centralization is also rooted in the many potentially damaging effects that have been associated with it, including:</t>
<ul spacing="normal">
<li>
<em>Power
<t><em>Power Imbalance</em>: When a third party has unavoidable access to communications, they gain informational and positional advantages that allow observation of behavior (the "panopticon effect") and shaping or even denial of behavior (the "chokepoint effect") <xref target="INTERMEDIARY-INFLUENCE"/> -- effect"): capabilities that those parties (or the states that have authority over them) can use for coercive ends <xref target="INTERDEPENDENCE"/> or even to disrupt society itself. Just as <xref target="FEDERALIST-51"/> describes good governance of states requires separation of powers <xref target="FEDERALIST-51"/>, so too does the US states, good governance of the Internet require requires that power over any function not be consolidated in one place without appropriate checks and balances.</li> balances.</t>
</li>
<li>
<em>Limits
<t><em>Limits on Innovation</em>: A party with the ability to control communication can preclude the possibility of "permissionless innovation" -- innovation", i.e., the ability to deploy new, unforeseen applications without requiring coordination with parties other than those you are communicating with.</li> with.</t>
</li>
<li>
<em>Constraints
<t><em>Constraints on Competition</em>: The Internet and its users benefit from robust competition when applications and services are available from many providers -- providers, especially when those users can build their own applications and services based upon interoperable standards. When a centralized service or platform must be used because no substitutes are suitable, it effectively becomes an essential facility, which facilitates opens the door to abuse of power.</li> power.</t>
</li>
<li>
<em>Reduced
<t><em>Reduced Availability</em>: Availability of the Internet (and applications and services built upon it) improves when there are many ways to obtain access. While service availability can benefit from the focused attention of a large centralized provider, that provider's failure can have a disproportionate impact on availability.</li> availability.</t>
</li>
<li>
<em>Monoculture</em>:
<t><em>Monoculture</em>: The scale available to a centralized provider can magnify minor flaws in features to a degree that can have broad consequences. For example, a single codebase for routers elevates the impact of a bug or vulnerability; a single recommendation algorithm for content can have severe social impact. Diversity in functions’ implementation implementations leads to a more robust outcome when viewed systemically, systemically because "progress is the outcome of a trial-and-error evolutionary process of many agents interacting freely." freely" <xref target="POLYCENTRIC"/></li> target="POLYCENTRIC"/>.</t>
</li>
<li>
<em>Self-Reinforcement</em>:
<t><em>Self-Reinforcement</em>: As widely noted (see, e.g., (e.g., see <xref target="ACCESS"/>), a centralized provider's access to data allows it the opportunity to make improvements to its offerings, offerings while denying such access to others.</li> others.</t>
</li>
</ul>
<t>The relationship between these harms and centralization is often complex; it complex. It is not always the case that centralization will lead to them, and them; when it does, there is not always a direct and simple tradeoff.</t> trade-off.</t>
<t>For example, consider the relationship between centralization and availability. A centrally operated system might be more available because of the resources available to a larger operator, but their size creates greater impact when a fault is encountered. Decentralized systems can be more resilient in the face of some forms of failure, failure but less so in other ways; for example, they may be less able to react to systemic issues, issues and might be exposed to a larger collection of security vulnerabilities in total. As such, it cannot be said that centralization reduces availability in all cases; cases: nor does it improve it in all cases.</t>
<t>This tension can be seen in areas like the cloud and mobile Internet access. If a popular cloud hosting cloud-hosting provider were to become unavailable (whether for technical or other reasons), many people's experience of the Internet experiences might be disrupted (especially due to the multiple dependencies that a modern Web site website often has; see <xref target="DEPENDENCIES"/>). Likewise, a large mobile Internet access provider might have an outage that affects hundreds of thousands of its users, users or more -- just as previous issues at large telephone companies precipitated widespread outages. outages <xref target="PHONE"/></t> target="PHONE"/>.</t>
<t>In both cases, the services are not technically centralized; these operators have strong incentives to have multiple redundancies in place and use various techniques to mitigate the risk of any one component failing. However, they generally do rely upon a single codebase, a limited selection of hardware, a unified control plane, and a uniform administrative practice -- practice: each of which might precipitate a widespread failure.</t>
<t>If there were only one provider for these services (like the telephone networks of old), they would easily be considered as to be centralized in a way that has significant impact upon availiability. availability. However, many cloud providers offer similar services, and in services. In most places places, there are multiple mobile operators available. That weakens the argument that there is a link between centralization and their availability, availability because the function's users can switch to other providers, providers or use 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 barriers are there to switching to other providers (thereby making any disruptions temporary and manageable) or to using multiple providers simultaneously (to mask the failure of a single operator)?</t>
<t>Another example of the need for nuance can be seen when evaluating competitive constraints. While making provision of various Internet functions more competitive may be a motivation for many engineers, only courts (and sometimes, sometimes regulators) have the authority to define a relevant market and determine that a behavior is anti-competitive. anticompetitive. In particular, market concentration does not always indicate competition issues, so issues; therefore, what might be considered undesirable centralization by the technical community might not attract competition regulation.</t>
</section>
<section anchor="necessary">
<name>Centralization Can Be Helpful</name>
<t>The potential harms damaging effects of centralization listed above are widely appreciated. Less widely explored is the reliance on centralization by some protocols and applications to deliver their functionality.</t>
<t>Often, centralization
<t>Centralization is often present due to technical necessity. For example, a single, single globally coordinated “source of truth” is by nature centralized -- such as in the root zone of the Domain Name System (DNS), which allows human-friendly naming to be converted into network addresses in a globally consistent fashion.</t>
<t>Or, consider IP address allocation. Internet routing requires addresses to be allocated uniquely, but if a single government or company were to capture the addressing function, the entire Internet would be at risk of abuse by that entity. Similarly, the Web's trust model requires a Certificate Authority (CA) to serve as the root of trust for communication between browsers and servers, bringing the centralization risk that risk, which needs to be considered in the design of that system.</t>
<t>Protocols that need to solve the "rendezvous problem" to coordinate communication between two parties who are not in direct contact also require centralization. For example, chat protocols need to coordinate communication between two parties that wish to talk; while the actual communication can be direct between them (so long as the protocol facilitates that), the endpoints' mutual discovery typically requires a third party at some point. From the perspective of those two users, the rendezvous function has a centralization risk.</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 recognized that the efficiencies that come with economies of scale can lead to concentration. concentration <xref target="SCALE"/> target="SCALE"/>. Those efficiences efficiencies can be passed on to users as higher quality products and lower costs, and they might even enable provision of a function that was not viable at smaller scale.</t>
<t>Complex and risky functions like financial services (e.g., credit card processing) are often concentrated into a few specialized organizations, organizations where they can receive the focused attention and expertise that they require.</t>
<t>Centralization can also provide an opportunity for beneficial controls to be imposed. <xref target="AMBITION"/> notes that "centralized structures can have virtues, such as enabling publics to focus their limited attention for oversight, or forming a power bloc capable of challenging less-accountable blocs that might emerge. Centralized structures that have earned widespread respect in recent centuries – including governments, corporations, and nonprofit organizations – have done so in no small part because of the intentional design that went into those structures."</t> structures".</t>
<t>This can be seen when a function requires governance to realize common goals and protect minority interests. For example, content moderation functions impose community values that many see as a benefit. Of course, they can also be viewed as a choke point where inappropriate controls are able to be imposed, imposed if that governance mechanism has inadequate oversight, transparency, or accountability.</t>
<t>Ultimately, deciding when centralization is beneficial is a judgment call. Some protocols cannot function operate without a centralized function; others might be significantly enhanced for certain use cases if a function is centralized, centralized or might merely be more efficient. In Although, in general, though, centralization is most concerning when it is not broadly held to be necessary or beneficial, beneficial; when it has no checks, balances, or other mechanisms of accountability, accountability; when it selects "favorites" which that are difficult (or impossible) to displace, displace; and when it threatens the architectural features that make the Internet successful.</t>
</section>
</section>
<section anchor="decentralization">
<name>Decentralization</name>
<t>While the term "decentralization" has a long history of use in economics, politics, religion, and international development, <xref target="RAND"/> gave one of the first definitions relevant to computer networking, networking as a condition when "complete reliance upon a single point is not always required."</t> required".</t>
<t>Such technical centralization (while not a trivial topic) is relatively well understood. Avoiding all forms of centralization -- including non-technical ones -- using only technical tools (like protocol design) is considerably more difficult. Several issues are encountered.</t>
<t>First
<t>First, and most critically, technical decentralization measures have have, at best best, limited effects on non-technical forms of centralization. Or, per <xref target="SCHNEIDER"/>, "decentralized technology alone does not guarantee decentralized outcomes." outcomes". As explored below in <xref target="techniques"/>, technical measures are better characterised characterized as necessary but insufficient to achieve full decentralization of a function.</t>
<t>Second, decentralizing a function requires overcoming challenges that centralized ones do not face. A decentralized function can be more difficult to adapt to user needs (for example, introducing new features, features or experimenting with user interface) interfaces) because doing so often requires coordination between many different actors. actors <xref target="MOXIE"/> target="MOXIE"/>. Economies of scale are more available to centralized functions, as is data that can be used to refine a function's design. All of these factors make centralized solutions more attractive to service providers, and providers and, in some cases cases, can make a decentralized solution uneconomic.</t>
<t>Third, identifying which aspects of a function to decentralize can be difficult, both because there are often many interactions between different types and sources of centralization, centralization and because centralization sometimes only becomes clear after the function is deployed at scale. Efforts to decentralize often have the effect of merely shifting centralization to a different place -- for example, in its governance, implementation, deployment, or in ancillary functions.</t>
<t>For example, the Web was envisioned and widely held to be a decentralizing force in its early life. Its potential as an enabler of centralization only became apparent when large Web sites websites successfully leveraged network effects (and secured legal prohibitions against interoperability, thus increasing switching costs; see <xref target="ADVERSARIAL"/>) to achieve dominance of social networking, marketplaces, and similar functions.</t>
<t>Fourth, different parties might have good-faith differences on what "sufficiently decentralized" means based upon their beliefs, perceptions perceptions, and goals. Just as centralization is a continuum, so is decentralization, and not everyone agrees what the "right" level or type is, how to weigh different forms of centralization against each other, or how to weigh potential centralization against other architectural goals (such as security or privacy).</t>
<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 function to local servers that users have the option to override -- an essentially centralized aspect of the DNS is its operation as a name space: a single, single global "source of truth" with inherent (if beneficial) centralization in its management. ICANN mitigates the associated risk through multi-stakeholder governance (see <xref target="multi"/>). While many believe that this arrangement is sufficient and might even have desirable qualities (such as the ability to impose community standards over the operation of the name space), others reject ICANN's oversight of the DNS as illegitimate, favoring decentralization based upon distributed consensus protocols rather than human governance. governance <xref target="MUSIANI"/></t> target="MUSIANI"/>.</t>
<t>Fifth, decentralization unavoidably involves adjustments to the power relationships between protocol participants, especially when it opens up the possibility of centralization elsewhere. As Schneider notes in <xref target="AMBITION"/>, target="AMBITION"/> notes, decentralization "appears to operate as a rhetorical strategy that directs attention toward some aspects of a proposed social order and away from others", so "we cannot accept technology as a substitute for taking social, cultural, and political considerations seriously." seriously". Or, more bluntly, "without governance mechanisms in place, nodes may collude, people may lie to each other, markets can be rigged, and there can be significant cost to people entering and exiting markets." markets" <xref target="PERSPECTIVE"/></t> target="PERSPECTIVE"/>.</t>
<t>For example, while blockchain-based cryptocurrencies purport to address the centralization inherent in traditional existing currencies through technical means, many exhibit considerable concentration of power due to voting/mining power, distribution of funds, and diversity of codebase. the codebase <xref target="BITCOIN"/> Over-reliance target="BITCOIN"/>. Overreliance on technical measures also brings an opportunity for latent, informal power structures that have their own risks -- including centralization. centralization <xref target="STRUCTURELESS"/></t> target="STRUCTURELESS"/>.</t>
<t>Overall, decentralizing a function requires considerable work, is inherently political, and involves a large degree of uncertainty about the outcome. If one considers decentralization as a larger social goal (in the spirit of how the term is used in other, non-computing contexts), merely rearranging technical functions may lead to frustration. "A distributed network does not automatically yield an egalitarian, equitable or just social, economic, political landscape." landscape" <xref target="PERSPECTIVE"/></t> target="PERSPECTIVE"/>.</t>
<section anchor="techniques">
<name>Decentralization Strategies</name>
<t>This section examines some common strategies that are employed to decentralize Internet functions, along with functions and discusses their limitations.</t>
<section anchor="federation">
<name>Federation</name>
<t>Protocol designers often attempt to address centralization through federation: federation, i.e., designing a function in a way that uses independent instances who that maintain connectivity and interoperability to provide a single, single cohesive service. Federation promises to allow users to choose the instance they associate with and accommodates substitution of one instance for another, lowering switching costs.</t>
<t>However, federation alone is insufficient to prevent or mitigate centralization of a function, function because non-technical factors can create pressure to use a central solution.</t>
<t>For example, the e-mail email suite of protocols needs to route messages to a user even when that user changes network locations or becomes disconnected for a long period. To facilitate this, SMTP <xref target="RFC5321"/> defines a specific role for routing users' messages, the Message Transfer Agent (MTA). By allowing anyone to deploy an MTA and defining rules for interconnecting them, the protocol avoids a requirement for a single, single central server in that role; users can (and often do) choose to delegate it to someone else, else or they can run their own MTA.</t>
<t>Running one's own MTA has become considerably more onerous over the years, due years due, in part part, to the increasingly complex mechanisms introduced to fight unwanted commercial e-mail. emails. These costs create an incentive to delegate one's MTA to a third party who has the appropriate expertise and resources, contributing to market concentration. concentration <xref target="DELIVERABILITY"/></t> target="DELIVERABILITY"/>.</t>
<t>Additionally, the measures that MTAs use to identify unwanted commercial e-mail emails are often site-specific. site specific. Because large MTAs handle so many more addresses, there is a power imbalance with smaller ones; if a large MTA decides that e-mail email from a small one is unwanted, there is significant impact on its ability to function, function and little recourse.</t>
<t>XMPP
<t>The Extensible Messaging and Presence Protocol (XMPP) <xref target="RFC6120"/> is a chat protocol that demonstrates another issue with federation: the voluntary nature of technical standards.</t>
<t>Like e-mail, email, XMPP is federated to facilitate the rendezvous of users from different systems - if they allow it. While some XMPP deployments do support truly federated messaging (i.e., a person using service A can interoperably chat with someone using service B), many of the largest do not. Because federation is voluntary, some operators captured their users into a single service, deliberately denying them the benefits of global interoperability.</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 anchor="distributed">
<name>Distributed Consensus</name>
<t>Increasingly, distributed consensus technologies (such as the a blockchain) are touted as a solution to centralization. A complete survey of this rapidly changing area is beyond the scope of this document, but we can generalize about its properties.</t>
<t>These techniques typically guarantee proper performance of a function using cryptographic techniques (often, an append-only transaction ledger). They attempt to avoid centralization by distributing the operation of a function to members of a sometimes large pool of protocol participants. Usually, the participants are unknown and untrusted, and a particular task's assignment to a node for handling cannot be predicted or controlled. They typically guarantee proper performance of a function using cryptographic techniques (often, an append-only transaction ledger).</t> controlled.</t>
<t>Sybil attacks (where a party or coordinated parties cheaply create enough protocol participants to affect how consensus is judged) are a major concern for these protocols, protocols because it they would have the effect of concentrating power into the hands of the attacker. Therefore, they encourage diversity in the pool of participants using indirect techniques, such as proof-of-work (where each participant has to show a significant consumption of resources) or proof-of-stake (where each participant has some other incentive to execute correctly).</t>
<t>While these measures can be effective in decentralizing a function's operation, other aspects of its provision can still be centralized; centralized: for example, governance of its design, creation of shared implementations, and documentation of wire protocols. That need for coordination is an avenue for centralization even when the function's operation remains decentralized. For example, the Ethereum "merge" demonstrated that the blockchain could address environmental concerns, concerns but only through coordinated community effort and governance -- governance: coordination that was benign in most eyes, but nevertheless centralized. eyes but, nevertheless, centralized <xref target="ETHEREUM"/></t> target="ETHEREUM"/>.</t>
<t>Furthermore, a protocol or an application composed of many functions can use distributed consensus for some, some but still be centralized elsewhere -- either because those other functions cannot be decentralized (most commonly, rendezvous and global naming; see <xref target="necessary"/>) or because the designer 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 consensus technologies in every instance, but they do merit caution against uncritically relying upon these technologies to avoid or mitigate centralization. Too often, the use of distributed consensus is perceived as imbuing all parts of a project with "decentralization."</t> "decentralization".</t>
</section>
<section anchor="multi">
<name>Operational Governance</name>
<t>Federation and distributed consensus can both create the conditions for the provision of a function by multiple providers, but they cannot guarantee it. However, when providers require access to a resource or cooperation of others to provide that service, that choke point can itself be used to influence provider behaviour behavior -- including in ways that can counteract centralization.</t>
<t>In these circumstances, some form of governance over that choke point is necessary to assure the desired outcome. Often, this is through the establishment of a multi-stakeholder body: body, which is an institution that includes representatives of the different kinds of parties that are affected by the system's operation ("stakeholders") in an attempt to make well-reasoned, legitimate, and authoritative decisions.</t>
<t>The most
<t>A widely studied example of this technique is the governance of the DNS name space, which exhibits centralization as a “single source of truth” exhibits centralization. <xref target="CENTRALIZATION"/>. That source of truth is overseen by <eref target="https://www.icann.org/resources/pages/governance/governance-en">the the Internet Corporation for Assigned Names and Numbers (ICANN)</eref>, (ICANN) <eref target="https://www.icann.org/resources/pages/governance/governance-en" brackets="angle"></eref>, a global multi-stakeholder body with representation from end users, governments, operators, and others.</t>
<t>Another example is the governance of the Web's trust model, implemented by Web web browsers as relying parties that have strong incentives to protect user privacy and security, security and Certificate Authorities (CAs) CAs as trust anchors that have a strong incentive to be included in browser trust stores. To promote the operational and security requirements necessary to provide the desired properties, the CA/Browser Forum <eref target="https://cabforum.org">CA/Browser Forum</eref> 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 operationally, but in a manner that takes advantage of protocol features that enable the imposition of governance.</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 mechanism is not trivial, and their legitimacy may be difficult to establish and maintain (see, e.g., (e.g., see <xref target="MULTISTAKEHOLDER"/>); by their nature, they are vulnerable to capture by the interests that are being governed.</t>
</section>
</section>
</section>
<section anchor="considerations">
<name>What Can Internet Standards Do?</name>
<t>Given the limits of decentralization techniques like federation and distributed consensus, the voluntary nature of standards compliance, and the powerful forces that can drive centralization, it is reasonable to ask what standards efforts like those at the IETF can do to accommodate helpful centralization while avoiding the associated harms -- while and acknowledging that the distinction itself is a judgment call, and call and, therefore, inherently political.</t>
<t>The subsections below suggest a few concrete, meaningful steps that standards bodies can take.</t>
<section anchor="legitimate">
<name>Bolster Legitimacy</name>
<t>Where technical standards have only limited ability to control centralization of the Internet, legal standards (whether regulation, legislation, or case law) show more promise, 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, architecture informed by a technical viewpoint.</t>
<t>That viewpoint can and should be provided by the Internet standards community. To effectively do so, its institutions must be seen as legitimate by the relevant parties -- for example, competition regulators. If the IETF is perceived as representing or being controlled by "big tech" concerns or only US-based companies, its ability to guide decisions that affect the Internet will be diminished considerably.</t>
<t>The IETF already has features that arguably provide considerable legitimacy; for example, legitimacy. Examples of these features include open participation and representation by individuals rather than companies by companies, both of which enhance input legitimacy; legitimacy); a well-defined process with multiple layers of appeals and transparency transparency, which contributes to throughput legitimacy, legitimacy; and a long history of successful Internet standards standards, which provides perhaps the strongest source of legitimacy for the IETF -- its output.</t>
<t>However, it is also widely recognized that the considerable costs (not just financial) involved in successfully participating in the IETF have a tendency to favour favor larger companies over smaller concerns. Additionally, the specialised specialized and highly technical nature of the work creates barriers to entry for non-technical stakeholders. These factors have the potential to reduce the legitimacy of the IETF's decisions, at least in some eyes.</t>
<t>Efforts to address these shortcomings are ongoing; see, for example, see <xref target="RFC8890"/>. Overall, bolstering the legitimacy of the organization should be seen as a continuous effort.</t>
<t>When engaging in external efforts, the IETF community (especially, (especially its leadership) should keep firmly in mind that its voice is most authoritative when focused on technical and architectural impact.</t>
</section>
<section anchor="target">
<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 evaluated. As discussed in <xref target="centralization"/>, not all centralization is automatically harmful, and per harmful. Per <xref target="decentralization"/>, decentralization techniques do not automatically address all centralization harms -- and they may bring their own risks.</t>
<t>However, standards participants rarely have the expertise or information available to completely evaluate those claims, because the analysis involves not only technical factors, but also economic, social, commercial, and legal aspects. For example, economies of scale can cause concentration due to the associated efficiencies <xref target="SCALE"/>, and so determining whether that concentration is appropriate requires a detailed economic analysis that is not in scope for a technical standards body. Furthermore, claims of centralization may have other motivations; in particular, they can be proxies for power struggles between actors with competing interests, and a claim of centralization might be used to deny market participants and (perhaps more importantly) users the benefits of standardization.</t>
<t>Therefore, approaches like requiring a "Centralization Considerations" section in drafts, documents, gatekeeping publication on a centralization review, or committing significant resources to searching for centralization in protocols are unlikely to improve the Internet.</t>
<t>Similarly, refusing to standardize a protocol because it does not actively prevent all forms of centralization ignores the very limited power that standards efforts have to do so. Almost all existing Internet protocols -- including IP, TCP, HTTP, and DNS -- fail to prevent centralized applications from using them. While the imprimatur of an Internet Standard the standards track <xref target="RFC2026"/> is not without value, merely withholding it cannot prevent centralization.</t>
<t>Discussions
<t>Thus, discussions should thus be very focused and limited, and any proposals for decentralization should be detailed, detailed so their full effects can be evaluated. <xref target="SCHNEIDER"/> implores that proposals those who propose decentralization to decentralize be "really, really clear about what particular features of a system a given design seeks to decentralize" and promotes borrowing remedies from more traditional governance systems, such as considered use of tools like separation of powers and accountability.</t> accountability from "old, institutional liberal political theory".</t>
<t>When evaluating claims that a given proposal is centralized, the context of those statements should be examined for presuppositions, assumptions, and omissions. One <xref target="BACCHI"/> offers one framework for critical interrogations is offered by <xref target="BACCHI"/>, interrogations, which can be adapted for centralization-related discussions:</t>
<ol spacing="normal" type="1"><li>What type="1"><li>
<t>What is the nature of the centralization that is represented as being problematic?</li>
<li>What problematic?</t>
</li>
<li>
<t>What deep-seated presuppositions or assumptions (conceptual logics) underlie this representation of the "problem"?</li>
<li>How "problem"?</t>
</li>
<li>
<t>How has this representation of the problem come about?</li>
<li>What about?</t>
</li>
<li>
<t>What is left unproblematic in this problem representation? Where are the silences? Can the "problem" be conceptualized differently?</li>
<li>What differently?</t>
</li>
<li>
<t>What effects are produced by this representation of the “problem”?</li>
<li>How “problem”?</t>
</li>
<li>
<t>How and where has this representation of the “problem” been produced, disseminated, and defended? How has it been and/or how can it be disrupted and replaced?</li> replaced?</t>
</li>
</ol>
</section>
<section anchor="up">
<name>Target Proprietary Functions</name>
<t>Functions that are widely used but lacking in interoperability are ripe for standardisation standardization efforts. Targeting prominent and proprietary functions (e.g., chat) is appropriate, but so are smaller efforts to improve interoperability and portability of specific features that are often used to lock users into a platform; 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; there are no "standards police" to mandate their use or enforce correct implementation. For example, specifications like <xref target="ACTIVITYSTREAMS"/>) target="ACTIVITYSTREAMS"/> were available for some time without being used in a federated manner by commercial social networking social-networking providers.</t>
<t>That objection ignores the fact that while standards aren't mandatory, legal regulation is. Legal mandates for interoperability are increasingly proposed by policymakers as a remedy for competition issues (see, e.g., (e.g., see <xref target="DMA"/>). This appetite for regulation presents an opportunity for new specifications to decentralize these functions, backed by a legal mandate in combination with changing norms and the resulting market forces <xref target="NEW-CHICAGO"/>.</t>
<t>That opportunity also presents a risk, if the resulting legal regulation is at odds with the Internet architecture. Successfully creating standards that work in concert with legal regulation presents many potential pitfalls, pitfalls and will require improved and new and improved capabilities (especially liaison), liaison) and considerable effort. If the Internet technical community does not make that effort, it is likely that regulators will turn to other sources for interoperability specifications.</t>
</section>
<section anchor="switch">
<name>Enable Switching</name>
<t>The ability to switch between different function providers is a core mechanism to control centralization. If users are unable to switch switch, they cannot exercise choice or fully realize the value of their efforts, efforts because, for example, "learning to use a vendor's product takes time, and the skill may not be fully transferrable transferable to a competitor's product if there is inadequate standardization." standardization" <xref target="SWITCHING"/></t> target="SWITCHING"/>.</t>
<t>Therefore, standards should have an explicit goal of facilitating users' users switching between implementations and deployments of the functions they define or enable.</t>
<t>One necessary condition for switching is the availability of alternatives; breadth and diversity of implementation and deployment are required. For example, if there is only a single implementation of a protocol, applications that use it are vulnerable to the control it has over their operation. Even Open Source open source projects can be an issue in this regard if there are factors that make forking difficult (for example, the cost of maintaining that fork). <xref section="2.1" sectionFormat="of" target="RFC5218"/> explores some factors in protocol design 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 amount of time, resources, expertise, coordination, loss of functionality, and effort required to use a different provider or implementation -- with the implication that the standard needs to be functionally complete and specified precisely enough to allow substitution.</t>
<t>These goals of completeness and diversity are sometimes in tension. at odds. If a standard becomes extremely complex, it may discourage implementation diversity because the cost of a complete implementation is too high (consider: Web (consider web browsers). On the other hand, if the specification is too simple, it may not enable easy switching, especially if proprietary extensions are necessary to complete it (see <xref target="evolution"/>).</t>
<t>One objection to protocols that enable easy switching is that they reduce the incentives for implementation by commercial vendors. While a completely commoditized protocol might not allow implementations to differentiate themselves, they provide opportunities for specialization and improvement elsewhere in the value chain <xref target="ATTRACTIVE-PROFITS"/>. Well-timed standards efforts leverage these forces to focus proprietary interests on top of open technology, technology rather than as a replacement for it.</t>
</section>
<section anchor="intermediation">
<name>Control Delegation of Power</name>
<t>The users of some functions might realize substantial benefits if they are provided by a third party in communication. Adding a new party to communication can improve:</t> improve the following:</t>
<ul spacing="normal">
<li>
<em>Efficiency</em>:
<t><em>Efficiency</em>: Many functions on the Internet are more efficient when performed at a higher scale. For example, a content delivery network can offer services at a fraction of the financial and environmental cost that someone serving content themselves would otherwise pay, pay because of the scale they operate at. Likewise, a two-sided market platform can introduce sizeable sizable efficiencies over pair-wise buyer/seller trading <xref target="CIRCULAR-CONUNDRUM"/>.</li> target="CIRCULAR-CONUNDRUM"/>.</t>
</li>
<li>
<em>Simplicity</em>:
<t><em>Simplicity</em>: Completely disintermediating communication can shift the burden of functions onto endpoints. This can cause increased cognitive load for users; for example, compare commercial social networking social-networking platforms with self-hosted efforts.</li> efforts.</t>
</li>
<li>
<em>Specialization</em>:
<t><em>Specialization</em>: Having a function consolidated into a few hands can improve outcomes because of the resulting specialization. For example, services overseen by professional administrators are often seen to have a better security posture and improved availability.</li> availability.</t>
</li>
<li>
<em>Privacy</em>:
<t><em>Privacy</em>: For some functions, user privacy can be improved by consolidating their activity to prevent individual behaviors from being discriminated from each other.<xref target="MIX"/> other <xref target="MIX"/>. Introduction of a third party can also enforce functional boundaries -- for example, to reduce the need for users to trust potentially malicious endpoints, as seen in the so-called “oblivious” protocols (e.g., <xref target="RFC9230"/>) that allow end users to hide their identity from services, services while still accessing them.</li> them.</t>
</li>
</ul>
<t>However, if that new party is able to make their participation "sticky" -- for example, by leveraging their position in the network to require use of an intermediary, by exploiting their access to data, or because it is difficult to switch to another provider of the function -- there is a risk of centralization.</t>
<t>Most often, third parties are added to functions as "intermediaries" or in designated "agent" roles. Designing such functions with thoughtful constraints on these roles can prevent at least the most egregious abuses of such power.</t>
<t>When adding new parties to a function, two guidelines have proven useful: first, useful. First, third parties should only be interposed into communication when at least one of the primary parties takes a positive action to do so. Second, third parties should have their ability to observe or control communication limited to what is necessary to perform their intended function.</t>
<t>For example, early deployments of HTTP allowed intermediaries to be interposed by the network without knowledge of the endpoints, and those intermediaries could see and change the full content of traffic by default -- even when they are were only intended to perform basic functions such as caching. Because of the introduction of HTTPS and the CONNECT method (see <xref section="9.3.6" sectionFormat="of" target="HTTP"/>), target="RFC9110"/>), combined with efforts to encourage its adoption, those intermediaries are now required to be explicitly interposed by one endpoint, and they only have access to basic routing information.</t>
<t>See <xref target="I-D.thomson-tmi"/> for more guidance on protocol intermediation.</t>
<t>The term "intermediary" is also used (often in legal and regulatory contexts) more broadly than it has been in protocol design; for example, an auction Web site website that intermediates between buyers and sellers is considered an intermediary, even though it is not formally an intermediary in HTTP (see <xref section="3.7" sectionFormat="of" target="HTTP"/>). target="RFC9110"/>). Protocol designers can address the centralization associated with this kind of intermediation by standardising standardizing the function, function rather than restricting the capabilities of the underlying protocols; see <xref target="up"/>.</t>
</section>
<section anchor="network">
<name>Enforce Boundaries</name>
<t>Most Internet protocols and applications depend on other, "lower-layer" functions and their implementations. The features, deployment, and operation of these dependencies can surface become centralization into risks for the functions and applications built "on top" of them.</t>
<t>For example, application protocols require a network to function, and therefore function; therefore, a degree of power over communication is available to the network provider. They might block access to, slow down, or change the content of a specific service for financial, political, operational, or criminal reasons, creating a disincentive (or even removing the ability) to use a specific provider of a function. By selectively hindering the use of some services but not others, network interventions can be composed to create pressure to use those other services -- intentionally or not.</t>
<t>Techniques like encryption can discourage such centralization by enforcing such boundaries. When the number of parties who have access to the content of communication is limited, other parties who handle it but are not party to it can be prevented from interfering with and observing it. Although those parties might still prevent communication, encryption also makes it more difficult to discriminate a target from other users' traffic.</t>
</section>
<section anchor="evolution">
<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 upgrade implementations. Typically, functions accommodate evolution by defining extension interfaces, which allow optional features to be added or change over time in an interoperable fashion.</t>
<t>However, these interfaces can also be leveraged by a powerful entity if they can change the target for meaningful interoperability by adding proprietary extensions to a standard. This is especially true when the core standard does not itself provide sufficient utility on its own.</t>
<t>For example, the extreme flexibility of SOAP protocol's <xref target="SOAP"/> extreme flexibility and 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 utility to the majority of their users as published, rather than being a “framework” where interoperability is not immediately available. Internet functions should not make every aspect of their operation extensible; boundaries between modules should be designed in a way that allows evolution, while still offering meaningful functionality.</t>
<t>Beyond allowing evolution, well-considered interfaces can also aid decentralization efforts. The structural boundaries that emerge between the sub-modules of the function -- as well as those with adjacent functions -- provide touchpoints for interoperability and an opportunity for substitution of providers.</t>
<t>In particular, if the interfaces of a function are well-defined and stable, there is an opportunity to use different providers for that function. When those interfaces are open standards, change control resides with the Internet technical community instead of remaining in proprietary hands, further enhancing stability and enabling (but not ensuring) decentralization.</t>
</section>
<section anchor="reuse">
<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 technical 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 considerable cost and risk of re-implementing reimplementing those mitigations. For example, if a protocol requires a coordinated, coordinated global naming function, incorporating the Domain Name System is usually preferable to establishing a new system.</t>
</section>
</section>
<section anchor="conclude">
<name>Future Work</name>
<t>This document has argued that that, while standards bodies have little means of effectively controlling or preventing centralization on of the Internet through protocol design, there are still concrete and useful steps they can take to improve the Internet.</t>
<t>Those steps might be elaborated upon and extended in future work; however, it is doubtless there is more that can be done. New decentralization techniques might be identified and examined; what we learn from relationships with other, more effective regulators in this space can be documented.</t>
<t>Some have suggested creating a how-to guide or checklist for dealing with centralization. Because centralization is so contextual and so varied in how it manifests, this might best be attempted within very limited areas; areas -- for example, for a particular type of function, function or a function at a particular layer.</t>
<t>The nature of centralization also deserves further study; in particular, its causes. While there is much commentary on factors like network effects and switching costs, other aspects -- such as behavioural, behavioral, cognitive, and social social, and economic factors have received comparatively little attention, although that is changing (e.g., <xref target="BEHAVIOUR"/>).</t>
</section>
<section anchor="security-considerations">
<name>Security Considerations</name>
<t>This document does not have a direct security impact on Internet protocols. That said, failure to consider centralization might cause a myriad of security issues; see <xref target="why"/> for a preliminary discussion.</t>
</section>
<section anchor="iana-considerations">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
</middle>
<back>
<displayreference target="RAND" to="Baran"/>
<displayreference target="INTERMEDIARY-INFLUENCE" to="Judge"/>
<displayreference target="INTERDEPENDENCE" to="FarrellH"/>
<displayreference target="MOXIE" to="Marlinspike"/>
<displayreference target="MULTISTAKEHOLDER" to="Palladino"/>
<displayreference target="NEW-CHICAGO" to="Lessig"/>
<displayreference target="POLYCENTRIC" to="Aligia"/>
<displayreference target="ACCESS" to="Abrahamson"/>
<displayreference target="MIX" to="Chaum"/>
<displayreference target="FEDERALIST-51" to="Madison"/>
<displayreference target="ATTRACTIVE-PROFITS" to="Christensen"/>
<displayreference target="CIRCULAR-CONUNDRUM" to="Spulber"/>
<displayreference target="AMBITION" to="Schneider2"/>
<displayreference target="BITCOIN" to="Makarov"/>
<displayreference target="PERSPECTIVE" to="Bodo"/>
<displayreference target="MUSIANI" to="Musiani"/>
<displayreference target="STRUCTURELESS" to="Freeman"/>
<displayreference target="SCHNEIDER" to="Schneider1"/>
<displayreference target="BACCHI" to="Bacchi"/>
<displayreference target="FB-INTERNET" to="Komaitis"/>
<displayreference target="DEPENDENCIES" to="Kashaf"/>
<displayreference target="BEHAVIOUR" to="Fletcher"/>
<displayreference target="DELIVERABILITY" to="Holzbauer"/>
<displayreference target="SWITCHING" to="FarrellJ"/>
<displayreference target="SCALE" to="Demsetz"/>
<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>
<reference anchor="RAND" target="https://www.rand.org/pubs/research_memoranda/RM3420.html">
<front>
<title>On Distributed Communications: Introduction to Distributed Communications Networks</title>
<author initials="P." surname="Baran" fullname="Paul Baran">
<organization>RAND Corporation</organization>
</author>
<date year="1964"/>
</front>
</reference>
<reference anchor="HTTP">
<front>
<title>HTTP Semantics</title>
<author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
<author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
<author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, 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, 7232, 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"/> value="10.7249/RM3420"/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/>
<reference anchor="SOAP" target="https://www.w3.org/TR/2007/REC-soap12-part0-20070427/">
<front>
<title>SOAP Version 1.2 Part 0: Primer (Second Edition)</title>
<author fullname="Nilo Mitra" role="editor"/>
<author fullname="Yves Lafon" role="editor"/>
<date day="27" month="April" year="2007"/>
</front>
<seriesInfo name="W3C REC" value="REC-soap12-part0-20070427"/>
<seriesInfo name="W3C" value="REC-soap12-part0-20070427"/>
</reference>
<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</refcontent>
<refcontent>W3C Recommendation</refcontent>
<annotation>Latest version available at <eref target="https://www.w3.org/TR/soap12-part0/" brackets="angle"/>.</annotation>
</reference>
<reference anchor="INTERDEPENDENCE" target="https://doi.org/10.1162/ISEC_a_00351"> anchor="INTERDEPENDENCE">
<front>
<title>Weaponized Interdependence: How Global Economic Networks Shape State Coercion</title>
<author initials="H." surname="Farrell" fullname="Henry Farrell">
<organization>George Washington University</organization>
</author>
<author initials="A. L." initials="A." surname="Newman" fullname="Abraham L. Newman">
<organization>Georgetown University</organization>
</author>
<date year="2019"/> year="2019" month="July"/>
</front>
<refcontent>International Security, Vol. 44, No. 1, p. 42</refcontent>
<seriesInfo name="DOI" value="10.1162/ISEC_a_00351"/>
</reference>
<reference anchor="MOXIE" target="https://signal.org/blog/the-ecosystem-is-moving/">
<front>
<title>Reflections: The ecosystem is moving</title>
<author initials="M." surname="Marlinspike" fullname="Moxie Marlinspike">
<organization>Signal</organization>
</author>
<date year="2016" month="May"/>
</front>
</reference>
<reference anchor="MULTISTAKEHOLDER" target="https://link.springer.com/book/10.1007/978-3-030-56131-4">
<front>
<title>Legitimacy, Power, and Inequalities in the Multistakeholder Internet Governance</title>
<author initials="N." surname="Palladino" fullname="Nicola Palladino">
<organization/>
</author>
<author initials="N." initials="M." surname="Santaniello" fullname="Nauro fullname="Mauro Santaniello">
<organization/>
</author>
<date year="2020"/> year="2020" month="November"/>
</front>
<seriesInfo name="DOI" value="10.1007/978-3-030-56131-4"/>
</reference>
<reference anchor="NEW-CHICAGO" target="https://www.journals.uchicago.edu/doi/10.1086/468039">
<front>
<title>The New Chicago School</title>
<author initials="L." surname="Lessig" fullname="Laurence Lessig">
<organization/>
</author>
<date year="1998" month="June"/>
</front>
<refcontent>Journal of Legal Studies, Vol. 27</refcontent>
<seriesInfo name="DOI" value="10.1086/468039"/>
</reference>
<reference anchor="POLYCENTRIC" target="https://onlinelibrary.wiley.com/doi/abs/10.1111/j.1468-0491.2011.01550.x">
<front>
<title>Polycentricity: From Polanyi to Ostrom, and Beyond</title>
<author initials="P. D." initials="P." surname="Aligia" fullname="Paul D. Aligia">
<organization/>
</author>
<author initials="V." surname="Tarko" fullname="Vlad Tarko">
<organization/>
</author>
<date year="2012" month="April"/>
</front>
<refcontent>Governance: An International Journal of Policy, Administration, and Institutions, Vol. 25, No. 2, p. 237</refcontent>
<seriesInfo name="DOI" value="10.1111/j.1468-0491.2011.01550.x"/>
</reference>
<reference anchor="ACCESS" target="https://www.yalelawjournal.org/comment/essential-data">
<front>
<title>Essential Data</title>
<author initials="Z." surname="Abrahamson" fullname="Zachary Abrahamson">
<organization/>
</author>
<date year="2014"/> year="2014" month="December"/>
</front>
<refcontent>Yale Law Journal, Vol. 124, No. 3</refcontent>
</reference>
<reference anchor="DMA" target="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R1925">
<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 sector and amending Directives (EU) 2019/1937 and (EU) 2020/1828 (Digital Markets Act)</title>
<author>
<organization>The European Parliament and the Council of the European Union</organization>
</author>
<date year="2022" month="September"/>
</front>
<refcontent>OJ L 265/1, 12.10.2022</refcontent>
</reference>
<reference anchor="MIX" target="https://dl.acm.org/doi/10.1145/358549.358563">
<front>
<title>Untraceable Electronic Mail, Return Addresses, electronic mail, return addresses, and Digital Pseudonyms</title> digital pseudonyms</title>
<author initials="D. L." initials="D." surname="Chaum" fullname="David L. Chaum">
<organization/>
</author>
<date year="1981" month="February"/>
</front>
<refcontent>Communications of the ACM, Vol. 24, No. 2</refcontent>
<seriesInfo name="DOI" value="10.1145/358549.358563"/>
</reference>
<reference anchor="FEDERALIST-51">
<front>
<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">
<organization/>
</author>
<date year="1788" month="February"/>
</front>
<refcontent>The Federalist Papers, No. 51</refcontent>
</reference>
<reference anchor="ATTRACTIVE-PROFITS">
<front>
<title>The Law of Conservation of Attractive Profits</title>
<author initials="C." surname="Christensen" fullname="Clayton Christensen">
<organization/>
</author>
<date year="2004" month="February"/>
</front>
<refcontent>Harvard Business Review, "Breakthrough Ideas for 2004"</refcontent>
</reference>
<reference anchor="ACTIVITYSTREAMS" target="https://www.w3.org/TR/2016/CR-activitystreams-core-20161215/"> target="https://www.w3.org/TR/2017/REC-activitystreams-core-20170523/">
<front>
<title>Activity Streams 2.0</title>
<author initials="E." surname="Prodromou" fullname="Evan Prodromou" role="editor"/>
<author initials="J." surname="Snell" fullname="James Snell" role="editor"/>
<date day="15" month="December" year="2016"/>
</front>
<seriesInfo name="W3C CR" value="CR-activitystreams-core-20161215"/>
<seriesInfo name="W3C" value="CR-activitystreams-core-20161215"/> day="23" month="May" year="2017"/>
</front>
<refcontent>W3C Recommendation</refcontent>
<annotation>Latest version available at <eref target="https://www.w3.org/TR/activitystreams-core/" brackets="angle"/>.</annotation>
</reference>
<reference anchor="CIRCULAR-CONUNDRUM" target="https://wwws.law.northwestern.edu/research-faculty/clbe/workingpapers/documents/spulber_circularconundrum.pdf">
<front>
<title>Solving The Circular Conundrum: Communication And and Coordination In Internet in Two-Sided Markets</title>
<author initials="D. F." initials="D." surname="Spulber" fullname="Daniel F. Spulber">
<organization/>
</author>
<date year="2010"/> month="October" year="2009"/>
</front>
<refcontent>Northwestern University Law Review, Vol. 104, No. 2</refcontent>
</reference>
<reference anchor="AMBITION" target="https://osf.io/m7wyj/">
<front>
<title>Decentralization: an incomplete ambition</title> An Incomplete Ambition</title>
<author initials="N." surname="Schneider" fullname="Nathan Schneider">
<organization/>
</author>
<date year="2019"/> year="2019" month="April"/>
</front>
<refcontent>Journal of Cultural Economy, Vol. 12, No. 4</refcontent>
<seriesInfo name="DOI" value="10.31219/osf.io/m7wyj
"/>
</reference>
<reference anchor="BITCOIN" target="https://www.nber.org/papers/w29396">
<front>
<title>Blockchain Analysis of the Bitcoin Market</title>
<author initials="I." surname="Makarov" fullname="Igor Makarov">
<organization>London School of Economics</organization>
</author>
<author initials="A." surname="Schoar" fullname="Antoinette Schoar">
<organization>MIT Sloan School of Management</organization>
</author>
<date year="2021" month="October"/>
</front>
<refcontent>National Bureau of Economic Research, Working Paper 29396</refcontent>
<seriesInfo name="DOI" value="10.3386/w29396"/>
</reference>
<reference anchor="PERSPECTIVE" target="https://doi.org/10.14763/2021.2.1563"> target="https://policyreview.info/concepts/decentralisation">
<front>
<title>Decentralization: a multidisciplinary perspective</title>
<author initials="B." surname="Bodó" fullname="Balázs Bodó">
<organization>University of Amsterdam</organization>
</author>
<author initials="J. K." surname="Brekke" fullname="Jaya Klara Brekke">
<organization>Durham University</organization>
</author>
<author initials="J.-H." surname="Hoepman" fullname="Jaap-Henk Hoepman">
<organization>Radboud University</organization>
</author>
<date year="2021" month="June"/>
</front>
<refcontent>Internet Policy Review, Vol. 10, No. 2</refcontent>
<seriesInfo name="DOI" value="10.14763/2021.2.1563"/>
</reference>
<reference anchor="MUSIANI" target="https://link.springer.com/chapter/10.1057/9781137483591_4">
<front>
<title>Alternative Technologies as Alternative Institutions: The Case of the Domain Name System</title>
<author initials="F." surname="Musiani" fullname="Francesca Musiani">
<organization/>
</author>
<date year="2016"/>
</front>
<refcontent>The Turn to Infrastructure in Internet Governance</refcontent>
<seriesInfo name="DOI" value="10.1057/9781137483591_4"/>
</reference>
<reference anchor="STRUCTURELESS" target="https://www.jstor.org/stable/41035187">
<front>
<title>The Tyranny of Structurelessness</title>
<author initials="J." surname="Freeman" fullname="Jo Freeman">
<organization/>
</author>
<date year="1972"/>
</front>
<refcontent>Berkeley Journal of Sociology, Vol. 17</refcontent>
</reference>
<reference anchor="SCHNEIDER" target="https://nathanschneider.info/articles/DecentralHacker.html"> target="https://hackernoon.com/decentralizing-everything-never-seems-to-work-2bb0461bd168">
<front>
<title>What to do once you admit that decentralizing everything never seems to work</title>
<author initials="N." surname="Schneider" fullname="Nathan Schneider">
<organization/>
</author>
<date year="2022" month="October"/> year="2019" month="September"/>
</front>
<refcontent>Hacker Noon</refcontent>
</reference>
<reference anchor="BACCHI" target="https://library.oapen.org/bitstream/handle/20.500.12657/33181/560097.pdf?sequence=1#page=34">
<front>
<title>Introducing the ‘What’s the Problem Represented to be?’ approach</title>
<author initials="C." surname="Bacchi" fullname="Carol Bacchi">
<organization/>
</author>
<date year="2012"/>
</front>
<refcontent>Chapter 2, Engaging with Carol Bacchi</refcontent>
</reference>
<reference anchor="ETHEREUM" target="https://ethereum.org/en/upgrades/merge/"> target="https://ethereum.org/en/roadmap/merge/">
<front>
<title>The Merge</title>
<author>
<organization>Ethereum</organization>
</author>
<date year="2023" month="February"/>
</front>
</reference>
<reference anchor="FB-INTERNET" target="https://slate.com/technology/2021/08/facebook-internet-regulation.html">
<front>
<title>Regulators Seem to Think That Facebook Is the Internet</title>
<author initials="K." surname="Komaitis" fullname="Konstantinos Komaitis">
<organization/>
</author>
<date year="2021" month="August"/>
</front>
</reference>
<reference anchor="DEPENDENCIES" target="https://dl.acm.org/doi/pdf/10.1145/3419394.3423664">
<front>
<title>Analyzing Third Party Service Dependencies in Modern Web Services: Have We Learned from the Mirai-Dyn Incident?</title>
<author initials="A." surname="Kashaf" fullname="Aqsa Kashaf">
<organization>Carnegie Mellon University</organization>
</author>
<author initials="V." surname="Sekar" fullname="Vyas Sekar">
<organization>Carnegie Mellon University</organization>
</author>
<author initials="Y." surname="Agarwal" fullname="Yuvraj Agarwal">
<organization>Carnegie Mellon University</organization>
</author>
<date year="2020" month="October"/>
</front>
<seriesInfo name="DOI" value="10.1145/3419394.3423664"/>
</reference>
<reference anchor="PHONE" target="https://www.washingtonpost.com/archive/politics/1991/06/27/computer-failure-paralyzes-regions-phone-service/0db94ac7-89f0-446e-ba33-c126c751b251/">
<front>
<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/>
</author>
<date year="1991" month="June"/>
</front>
</reference>
<reference anchor="BEHAVIOUR" target="http://dx.doi.org/10.2139/ssrn.4389681"> anchor="BEHAVIOUR">
<front>
<title>The Role of Behavioural Economics in Competition Policy</title>
<author initials="A." surname="Fletcher" fullname="Amelia Fletcher">
<organization/>
</author>
<date year="2023" month="March"/>
</front>
<seriesInfo name="DOI" value="10.2139/ssrn.4389681"/>
</reference>
<reference anchor="DELIVERABILITY" target="https://www.usenix.org/system/files/atc22-holzbauer.pdf">
<front>
<title>Not that Simple: Email Delivery in the 21st Century</title>
<author initials="F." surname="Holzbauer" fullname="Florian Holzbauer">
<organization/>
</author>
<author initials="J." surname="Ullrich" fullname="Johanna Ullrich">
<organization/>
</author>
<author initials="M." surname="Lindorfer" fullname="Martina Lindorfer">
<organization/>
</author>
<author initials="T." surname="Fiebig" fullname="Tobias Fiebig">
<organization/>
</author>
<date year="2022" month="July"/>
</front>
</reference>
<reference anchor="SWITCHING" target="http://dx.doi.org/10.2307/2555402"> anchor="SWITCHING">
<front>
<title>Dynamic Competition with Switching Costs</title>
<author initials="J." surname="Farrell" fullname="Joseph Farrell">
<organization/>
</author>
<author initials="C." surname="Shapiro" fullname="Carl Shapiro">
<organization/>
</author>
<date year="1988" month="January"/>
</front>
<refcontent>UC Berkeley Department of Economics Working Paper 8865</refcontent>
<seriesInfo name="DOI" value="10.2307/2555402"/>
</reference>
<reference anchor="SCALE" target="https://www.jstor.org/stable/724822">
<front>
<title>Industry Structure, Market Rivalry, and Public Policy</title>
<author initials="H." surname="Demsetz" fullname="Harold Demsetz">
<organization/>
</author>
<date year="1973" month="April"/>
</front>
<refcontent>Journal of Law and Economics, Vol. 16, No. 1</refcontent>
</reference>
<reference anchor="ADVERSARIAL" target="https://www.eff.org/deeplinks/2019/10/adversarial-interoperability">
<front>
<title>Adversarial Interoperability</title>
<author initials="C." surname="Doctorow" fullname="Cory Doctorow">
<organization>Electronic Frontier Foundation</organization>
</author>
<date year="2019" month="October"/>
</front>
</reference>
<reference anchor="RFC791">
<front>
<title>Internet Protocol</title>
<author fullname="J. Postel" initials="J." surname="Postel"/>
<date month="September" year="1981"/>
</front>
<seriesInfo name="STD" value="5"/>
<seriesInfo name="RFC" value="791"/>
<seriesInfo name="DOI" value="10.17487/RFC0791"/>
</reference>
<reference anchor="RFC4271">
<front>
<title>A Border Gateway Protocol 4 (BGP-4)</title>
<author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"/>
<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 network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing 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 of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including 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>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.791.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9293.xml"/>
<referencegroup anchor="BCP95">
<reference anchor="RFC3935" target="https://www.rfc-editor.org/info/rfc3935">
<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 define the terms used in the statement sufficiently to make the mission statement understandable and useful, argues why the IETF needs a mission statement, and tries 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 discussion 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> anchor="BCP95" target="https://www.rfc-editor.org/info/bcp95"> <xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3935.xml"/>
</referencegroup>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5321.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6120.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8890.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2026.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5218.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9230.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.thomson-tmi.xml"/>
<reference anchor="RFC5321">
<front>
<title>Simple Mail Transfer Protocol</title>
<author fullname="J. Klensin" initials="J." surname="Klensin"/>
<date month="October" year="2008"/>
<abstract>
<t>This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5321"/>
<seriesInfo name="DOI" value="10.17487/RFC5321"/>
</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 application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-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"> anchor="CENTRALIZATION"
target="https://dl.acm.org/doi/abs/10.1145/3419394.3423625">
<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
<title>Clouding up the Internet and other parties, IETF decisions should favor end users. It also explores Internet: how the IETF can more effectively 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 centralized is hoped that these observations can serve as guidance 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"/> traffic becoming?</title>
<author fullname="T. Pauly" initials="T." surname="Pauly"/> initials="G" surname="Moura" fullname="Giovane C. M. Moura">
<organization>SIDN Labs</organization>
</author>
<author fullname="T. Verma" initials="T." surname="Verma"/> initials="S." surname="Castro" fullname="Sebastian Castro">
<organization>InternetNZ</organization>
</author>
<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 their 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 and is published here to guide implementation, ensure interoperability among implementations, 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>
<title>Principles for the Involvement of Intermediaries in Internet Protocols</title> initials="W." surname="Hardaker" fullname="Wes Hardaker">
<organization>USC/ISI</organization>
</author>
<author fullname="Martin Thomson" initials="M." surname="Thomson">
<organization>Mozilla</organization> surname="Wullink" fullname="Maarten Wullink">
<organization>SIDN Labs</organization>
</author>
<author initials="C." surname="Hesselman" fullname="Cristian Hesselman">
<organization/>
</author>
<date day="8" month="September" year="2022"/>
<abstract>
<t> This document proposes a set of principles for designing protocols
with rules for intermediaries. The goal of these principles is to
limit the ways in which intermediaries can produce undesirable
effects and to protect the useful functions that intermediaries
legitimately provide.
</t>
</abstract> year="2020" month="October"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-thomson-tmi-04"/> name="DOI" value="10.1145/3419394.3423625"/>
</reference>
</references>
<?line 640?>
<section anchor="acks">
<name>Acknowledgements</name>
<t>This document was born out of early discussions with Brian Trammell <contact fullname="Brian Trammell"/> during our shared time on the Internet Architecture Board.</t>
<t>Special thanks to Geoff Huston and Milton Mueller <contact fullname="Geoff Huston"/> and <contact fullname="Milton Mueller"/> for their well-considered, thoughtful, and helpful reviews.</t>
<t>Thanks to Jari Arkko, Kristin Berdan, Richard Clayton, Cory Doctorow, Christian Huitema, Mallory Knodel, Eliot Lear, John Levine, Tommy Pauly, <contact fullname="Jari Arkko"/>, <contact fullname="Kristin Berdan"/>, <contact fullname="Richard Clayton"/>, <contact fullname="Cory Doctorow"/>, <contact fullname="Christian Huitema"/>, <contact fullname="Eliot Lear"/>, <contact fullname="John Levine"/>, <contact fullname="Tommy Pauly"/>, and Martin Thomson <contact fullname="Martin Thomson"/> for their comments and suggestions. Likewise, the arch-discuss@ietf.org <eref target="mailto:arch-discuss@ietf.org">arch-discuss@ietf.org</eref> mailing list and Decentralized Internet Infrastructure Research Group provided valuable discussion and feedback.</t>
<t>No large language models were used in the production of this document.</t>
</section>
</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>