<?xmlversion='1.0' encoding='utf-8'?>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.22 (Ruby 3.1.3) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-iab-protocol-maintenance-12" number="9413" submissionType="IAB" category="info" consensus="true"submissionType="IAB"tocInclude="true" sortRefs="true" symRefs="true" updates="" obsoletes="" xml:lang="en" version="3"> <!-- xml2rfc v2v3 conversion 3.16.0 --> <front> <title>Maintaining Robust Protocols</title> <seriesInfoname="Internet-Draft" value="draft-iab-protocol-maintenance-12"/>name="RFC" value="9413"/> <author initials="M." surname="Thomson" fullname="Martin Thomson"> <organization/> <address> <email>mt@lowentropy.net</email> </address> </author> <author initials="D." surname="Schinazi" fullname="David Schinazi"> <organization/> <address> <email>dschinazi.ietf@gmail.com</email> </address> </author> <date year="2023"month="February" day="02"/> <workgroup>EDM</workgroup>month="June"/> <keyword>robustness</keyword> <keyword>postel</keyword> <keyword>principle</keyword> <keyword>law</keyword> <keyword>wrong</keyword> <keyword>tolerance</keyword> <abstract> <t>The main goal of the networking standards process is to enable thelong termlong-term interoperability of protocols. This document describes active protocol maintenance, a means to accomplish that goal. By evolving specifications and implementations, it is possible to reduce ambiguity over time and create a healthy ecosystem.</t> <t>The robustness principle, often phrased as "be conservative in what you send, and liberal in what you accept", has long guided the design and implementation of Internet protocols. However, it has been interpreted in a variety of ways. While some interpretations help ensure the health of the Internet, others can negatively affect interoperability over time. When a protocol is actively maintained, protocol designers and implementers can avoid these pitfalls.</t> </abstract><note removeInRFC="true"> <name>About This Document</name> <t> The latest revision of this draft can be found at <eref target="https://intarchboard.github.io/draft-protocol-maintenance/draft-iab-protocol-maintenance.html"/>. Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-iab-protocol-maintenance/"/>. </t> <t> Discussion of this document takes place on the EDM IAB Program mailing list (<eref target="mailto:edm@iab.org"/>), which is archived at <eref target="https://www.iab.org/mailman/listinfo/edm"/>. Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/edm/"/>. </t> <t>Source for this draft and an issue tracker can be found at <eref target="https://github.com/intarchboard/draft-protocol-maintenance"/>.</t> </note></front> <middle> <section anchor="introduction"> <name>Introduction</name> <t>There is good evidence to suggest that many important protocols are routinely maintained beyond their inception. In particular, asizeablesizable proportion of IETF activity is dedicated to the stewardship of existing protocols. This document first discusses hazards in applying the robustness principle too broadly (see <xreftarget="robustness"/>),target="robustness"/>) and offers an alternative strategy for handling interoperability problems in deployments (see <xref target="active"/>).</t> <t>Ideally, protocol implementations can be actively maintained so that unexpected conditions are proactively identified and resolved. Some deployments might still need to apply short-term mitigations for deployments that cannot be easily updated, but such cases need not be permanent. This is discussed further in <xref target="active"/>.</t> </section> <section anchor="robustness"> <name>Protocol Robustness</name> <t>The robustness principle has been hugely influential in shaping the design of the Internet. As stated in the IAB documenton Architectural"Architectural Principles of theInternetInternet" <xref target="RFC1958"/>, the robustness principle advises to:</t><blockquote> <t>Be<blockquote>Be strict when sending and tolerant when receiving. Implementations must follow specifications precisely when sending to the network, and tolerate faulty input from the network. When in doubt, discard faulty input silently, without returning an error message unless this is required by thespecification.</t>specification. </blockquote> <t>This simple statement captures a significant concept in the design of interoperable systems. Many consider the application of the robustness principle to be instrumental in the success of the Internet as well as the design of interoperable protocols in general.</t> <t>There are three main aspects to the robustness principle:</t> <dl> <dt>Robustness to software defects:</dt> <dd> <t>No software is perfect, and failures can lead to unexpected behavior. Well-designed software strives to be resilient to such issues, whether they occur in the localsoftware,software or in software that it communicates with. In particular, it is critical for software to gracefully recover from these issues without aborting unrelated processing.</t> </dd> <dt>Robustness to attacks:</dt> <dd> <t>Since not all actors on the Internet are benevolent, networking software needs to be resilient to input that is intentionally crafted to cause unexpected consequences. For example, software must ensure that invalid input doesn't allow the sender to access data, change data, or perform actions that it would otherwise not be allowed to.</t> </dd> <dt>Robustness to the unexpected:</dt> <dd> <t>It can be possible for an implementation to receive inputs that the specification did not prepare it for. This scenario excludes those cases where a the specification explicitly defines how a faulty message is handled. Instead, this refers to cases where handling is not defined or where there is some ambiguity in the specification. In this case, some interpretations of the robustness principle advocate that the implementation tolerate the faulty input and silently discard it. Some interpretations even suggest that a faulty or ambiguous message be processed according to the inferred intent of the sender.</t> </dd> </dl> <t>The facets of the robustness principle that protect against defects orattackattacks are understood to be necessary guiding principles for the design and implementation of networked systems. However, an interpretation that advocates for tolerating unexpected inputs is no longer considered best practice in all scenarios.</t> <t>Time and experienceshowsshow that negative consequences to interoperability accumulate over time if implementations silently accept faulty input. This problem originates from an implicit assumption that it is not possible to effect change in a system the size of the Internet. When one assumes that changes to existing implementations are not presently feasible, tolerating flaws feels inevitable.</t> <t>Many problems that this third aspect of the robustness principle was intended to solve can instead be better addressed by active maintenance. Active protocol maintenance is where a community of protocol designers, implementers, and deployers work together to continuously improve and evolve protocol specifications alongside implementations and deployments of those protocols. A community that takes an active role in the maintenance of protocols will no longer need to rely on the robustness principle to avoid interoperability issues.</t> <section anchor="fallibility-of-specifications"> <name>Fallibility of Specifications</name> <t>The context from which the robustness principle was developed provides valuable insights into its intent and purpose. The earliest form of the principle in the RFCseriesSeries (the Internet Protocol specification <xref target="RFC0760"/>) is preceded by a sentence that reveals a motivation for the principle:</t><blockquote> <t>While<blockquote>While the goal of this specification is to be explicit about the protocol there is the possibility of differing interpretations. In general, an implementation should be conservative in its sending behavior, and liberal in its receivingbehavior.</t> </blockquote>behavior.</blockquote> <t>This formulation of the principle expressly recognizes the possibility that the specification could be imperfect. This contextualizes the principle in an important way.</t> <t>Imperfect specifications are unavoidable, largely because it is more important to proceed to implementation and deployment than it is to perfect a specification. A protocol benefits greatly from experience with its use. A deployed protocol is immeasurably more useful than a perfect protocol specification. This is particularly true in early phases of system design, to which the robustness principle is best suited.</t> <t>As demonstrated by the IAB documenton"What Makes for a SuccessfulProtocols <xrefProtocol?" <xref target="RFC5218"/>, success or failure of a protocol depends far more on factors like usefulness than on technical excellence. Timely publication of protocol specifications, even with the potential for flaws, likely contributed significantly to the eventual success of the Internet.</t> <t>This premise that specifications will be imperfect is correct. However, ignoring faulty or ambiguous input is almost always the incorrect solution to the problem.</t> </section> <section anchor="extensibility"> <name>Extensibility</name> <t>Good extensibility <xreftarget="EXT"/>target="RFC6709"/> can make it easier to respond to new use cases or changes in the environment in which the protocol is deployed.</t> <t>The ability to extend a protocol is sometimes mistaken for an application of the robustness principle. After all, if one party wants to start using a new feature before another party is prepared to receive it, it might be assumed that the receiving party is being tolerant of new types of input.</t> <t>A well-designed extensibility mechanism establishes clear rules for the handling of elements like new messages or parameters. This depends on specifying the handling of malformed or illegal inputs so that implementations behave consistently in all cases that might affect interoperation. New messages or parameters thereby become entirely expected. If extension mechanisms and error handling are designed and implemented correctly, new protocol features can be deployed with confidence in the understanding of the effect they have on existing implementations.</t> <t>In contrast, relying on implementations to consistently handle unexpected input is not a good strategy for extensibility. Using undocumented or accidental features of a protocol as the basis of an extensibility mechanism can be extremely difficult, as is demonstrated by the case study in <xref section="A.3" sectionFormat="of"target="EXT"/>.target="RFC6709"/>. It is better and easier to design a protocol for extensibility initially than to retrofit the capability (see also <xreftarget="EDNS0"/>).</t>target="RFC6891"/>).</t> </section> <section anchor="flexibility"> <name>Flexible Protocols</name> <t>A protocol could be designed to permit a narrow set of valid inputs, or it could be designed to treat a wide range of inputs as valid.</t> <t>A more flexible protocol is more complex to specify andimplement: variations -implement; variations, especially those that are not commonlyused -used, can create potential interoperability hazards. In the absence of strong reasons to be flexible, a simpler protocol is more likely to successfully interoperate.</t> <t>Where input is provided by users, allowing flexibility might serve to make the protocol more accessible, especially for non-expert users. HTML authoring <xref target="HTML"/> is an example of this sort of design.</t> <t>In protocols where there are many participants that might generate messages based on data from otherparticipantsparticipants, some flexibility might contribute to resilience of the system. A routing protocol is a good example of where this might be necessary.</t> <t>In BGP <xreftarget="BGP"/>,target="RFC4271"/>, a peer generates UPDATE messages based on messages it receives from other peers. Peers can copy attributes without validation, potentially propagating invalid values. RFC 4271 <xreftarget="BGP"/>target="RFC4271"/> mandated a session reset for invalid UPDATE messages, a requirement that was not widely implemented. In many deployments, peers would treat a malformed UPDATE in less stringent ways, such as by treating the affected route as having been withdrawn. Ultimately, RFC 7606 <xreftarget="BGP-REH"/>target="RFC7606"/> documented this practice and provided precise rules, including mandatory actions for different error conditions.</t> <t>A protocol can explicitly allow for a range of valid expressions of the same semantics, with precise definitions for error handling. This is distinct from a protocol that relies on the application of the robustness principle. With the former, interoperation depends on specifications that capture all relevantdetails;details, whereas- as noted in <xref target="ecosystem"/> -interoperation in the latter depends more extensively on implementations making compatibledecisions.</t>decisions, as noted in <xref target="ecosystem"/>.</t> </section> </section> <section anchor="applicability"> <name>Applicability</name> <t>The guidance in this document is intended for protocols that are deployed to the Internet. There are some situations in which this guidance might not apply to a protocol due to conditions on its implementation or deployment.</t> <t>In particular, this guidance depends on an ability to update and deploy implementations. Being able to rapidly update implementations that are deployed to the Internet helpsmanagingmanage securityriskrisks, but inrealityreality, some software deployments have lifecycles that make software updates either rare or altogether impossible.</t> <t>Where implementations are not updated, there is no opportunity to apply the practices that this document recommends. In particular, some practices--- such as those described in <xref target="intolerance"/>--- only exist to support the development of protocol maintenance and evolution. Employing this guidance is therefore only applicable where there is the possibility of improving deployments through timely updates of their implementations.</t> </section> <section anchor="harmful-consequences-of-tolerating-the-unexpected"> <name>Harmful Consequences of Tolerating the Unexpected</name> <t>Problems in other implementations can create an unavoidable need to temporarily tolerate unexpected inputs. However, this course of action carries risks.</t> <section anchor="decay"> <name>Protocol Decay</name> <t>Tolerating unexpected input might be an expedient tool for systems in early phases of deployment,such aswhich was the case for the early Internet. Being lenient in this way defers the effort of dealing with interoperability problems and prioritizes progress. However, this deferral can amplify the ultimate cost of handling interoperability problems.</t> <t>Divergent implementations of a specification emerge over time. When variations occur in the interpretation or expression of semantic components, implementations cease to be perfectly interoperable.</t> <t>Implementation bugs are often identified as the cause of variation, though it is often a combination of factors. Using a protocol in ways that were not anticipated in the originaldesign,design or ambiguities and errors in the specification are often contributing factors. Disagreements on the interpretation of specifications should be expected over the lifetime of a protocol.</t> <t>Even with the best intentions to maintain protocol correctness, the pressure to interoperate can be significant. No implementation can hope to avoid having to trade correctness for interoperability indefinitely.</t> <t>An implementation that reacts to variations in the manner recommended in the robustness principle enters a pathological feedback cycle. Over time:</t> <ul spacing="normal"> <li>Implementations progressively add logic to constrain how data istransmitted,transmitted or to permit variations in what is received.</li> <li>Errors in implementations or confusion about semantics are permitted or ignored.</li> <li>These errors can become entrenched, forcing other implementations to be tolerant of those errors.</li> </ul> <t>A flaw can become entrenched as a de facto standard. Any implementation of the protocol is required to replicate the aberrant behavior, or it is not interoperable. This is both a consequence of tolerating theunexpected,unexpected and a product of a natural reluctance to avoid fatal error conditions. Ensuring interoperability in this environment is often referred to as aiming to be"bug for bug"bug-for-bug compatible".</t> <t>For example, in TLS <xreftarget="TLS"/>,target="RFC8446"/>, extensions use a tag-length-value format and can be added to messages in any order. However, some server implementations terminated connections if they encountered a TLS ClientHello message that ends with an empty extension. To maintain interoperability with these servers, which were widely deployed, client implementations were required to be aware of this bug and ensure that a ClientHello message ends in a non-empty extension.</t> <t>Overapplication of the robustness principle therefore encourages a chain reaction that can create interoperability problems over time. In particular, tolerating unexpected behavior is particularly deleterious for early implementations of newprotocolsprotocols, as quirks in early implementations can affect all subsequent deployments.</t> </section> <section anchor="ecosystem"> <name>Ecosystem Effects</name> <t>From observing widely deployed protocols, it appears there are two stable points on the spectrum between being strict versus permissive in the presence of protocol errors:</t> <ul spacing="normal"> <li>If implementations predominantly enforce strict compliance with specifications, newer implementations will experience failures if they do not comply with protocol requirements. Newer implementations need to fix compliance issues in order to be successfully deployed. This ensures that most deployments are compliant over time.</li> <li>Conversely, if non-compliance is tolerated by existing implementations, non-compliant implementations can be deployed successfully. Newer implementations then have a strong incentive to tolerate any existing non-compliance in order to be successfully deployed. This ensures that most deployments are tolerant of the same non-compliant behavior.</li> </ul> <t>This happens because interoperability requirements for protocol implementations are set by other deployments. Specifications and test suites--- where they exist--- can guide the initial development of implementations. Ultimately, the need to interoperate with deployed implementations is a de facto conformance test suite that can supersede any formal protocol definition.</t> <t>For widely used protocols, the massive scale of the Internet makes large-scale interoperability testing infeasible for all but a privileged few. The cost of building a new implementation using reverse engineering increases as the number of implementations and bugs increases. Worse, the set of tweaks necessary for wide interoperability can be difficult to discover. In the worst case, a new implementer might have to choose between deployments that have diverged so far as to no longer be interoperable.</t> <t>Consequently, new implementations might be forced into niche uses, where the problems arising from interoperability issues can be more closely managed. However, restricting new implementations into limited deployments risks causing forks in the protocol. If implementations do not interoperate, little prevents those implementations from diverging more over time.</t> <t>This has a negative impact on the ecosystem of a protocol. New implementations are key to the continued viability of a protocol. New protocol implementations are also more likely to be developed for new and diverse use cases and are often the origin of features and capabilities that can be of benefit to existing users.</t> <t>The need to work around interoperability problems also reduces the ability of established implementations to change. An accumulation of mitigations for interoperability issues makes implementations more difficult to maintain and can constrain extensibility (see also the IAB documenton the Long-Term"Long-Term Viability of Protocol ExtensionMechanismsMechanisms" <xref target="RFC9170"/>).</t><t>Sometimes<t>Sometimes, what appear to be interoperability problems are symptomatic of issues in protocol design. A community that is willing to make changes to the protocol, by revising or extending specifications and then deploying those changes, makes the protocol better. Tolerating unexpected input instead conceals problems, making it harder, if not impossible, to fix them later.</t> </section> </section> <section anchor="active"> <name>Active Protocol Maintenance</name> <t>The robustness principle can be highly effective in safeguarding against flaws in the implementation of a protocol by peers. Especially when a specification remains unchanged for an extended period of time, the incentive to be tolerant of errors accumulates over time. Indeed, when faced with divergent interpretations of an immutable specification, the only way for an implementation to remain interoperable is to be tolerant of differences in interpretation and implementation errors. However, when official specifications fail to beupdatedupdated, then deployed implementations--- including their quirks--- often become a substitute standard.</t> <t>Tolerating unexpected inputs from another implementation might seem logical, even necessary.ButHowever, that conclusion relies on an assumption that existing specifications and implementations cannot change. Applying the robustness principle in this way disproportionately values short-term gains over the negative effects on future implementations and the protocol as a whole.</t> <t>For a protocol to have sustained viability, it is necessary for both specifications and implementations to be responsive to changes, in addition to handling new and old problems that might arise over time. For example, when an implementer discovers a scenario where a specification defines some input as faulty but does not define how to handle that input, the implementer can provide significant value to the ecosystem by reporting the issue and helping to evolve the specification.</t> <t>When a discrepancy is found between a specification and its implementation, a maintenance discussion inside the standards process allows reaching consensus on how best to evolve the specification.SubsequentlySubsequently, updating implementations to match evolved specifications ensures that implementations are consistently interoperable and removes needless barriers for new implementations. Maintenance also enables continued improvement of the protocol. New use cases are an indicator that the protocol could be successful <xref target="RFC5218"/>.</t> <t>Protocol designers are strongly encouraged to continue to maintain and evolve protocol specifications beyond their initial inception and definition. This might require the development of revised specifications, extensions, or other supporting material that evolves in concert with implementations. Involvement of those who implement and deploy the protocol is a critical part of this process, as they provide input on their experience with how the protocol is used.</t> <t>Most interoperability problems do not require revision of protocols or protocol specifications, as software defects can happen even when the specification is unambiguous. For instance, the most effective means of dealing with a defective implementation in a peer could be to contact the developer responsible. It is far more efficient in the long term to fix one isolated bug than it is to deal with the consequences of workarounds.</t> <t>Early implementations of protocols have a stronger obligation to closely followspecificationsspecifications, as their behavior will affect all subsequent implementations. In addition to specifications, later implementations will be guided by what existing deployments accept. Tolerance of errors in early deployments is most likely to result in problems. Protocol specifications might need more frequent revision during early deployments to capture feedback from early rounds of deployment.</t> <t>Neglect can quickly produce the negative consequences this document describes. Restoring the protocol to a state where it can be maintained involves first discovering the properties of the protocol as it isdeployed,deployed rather than the protocol as it was originally documented. This can be difficult and time-consuming, particularly if the protocol has a diverse set of implementations. Such a process was undertaken for HTTP <xreftarget="HTTP"/>target="RFC9110"/> after a period of minimal maintenance. Restoring HTTP specifications to relevance took significant effort.</t> <t>Maintenance is most effective if it is responsive, which is greatly affected by how rapidly protocol changes can be deployed. For protocol deployments that operate on longer time scales, temporary workarounds following the spirit of the robustness principle might be necessary. For this, improvements in software update mechanisms ensure that the cost of reacting to changes is much lower than it was in the past. Alternatively, if specifications can be updated more readily than deployments, details of the workaround can be documented, including the desired form of the protocols once the need for workarounds no longer exists and plans for removing the workaround.</t> <section anchor="intolerance"> <name>Virtuous Intolerance</name> <t>A well-specified protocol includes rules for consistent handling of aberrant conditions. This increases the chances that implementations will have consistent and interoperable handling of unusual conditions.</t> <t>Choosing to generate fatal errors for unspecified conditions instead of attempting error recovery can ensure that faults receive attention. This intolerance can be harnessed to reduce occurrences of aberrant implementations.</t> <t>Intolerance toward violations of specification improves feedback for new implementations in particular. When a new implementation encounters a peer that is intolerant of an error, it receives strong feedback that allows the problem to be discovered quickly.</t> <t>To be effective, intolerant implementations need to be sufficiently widely deployed so that they are encountered by new implementations with high probability. This could depend on multiple implementations deploying strict checks.</t> <t>Interoperability problems also need to be made known to those in a position to address them. In particular, systems with human operators, such as user-facing clients, are ideally suited to surfacing errors. Other systems might need to use less direct means of making errors known.</t> <t>This does not mean that intolerance of errors in early deployments of protocols has the effect of preventing interoperability. On the contrary, when existing implementations followclearly-specifiedclearly specified error handling, new implementations or features can be introduced morereadilyreadily, as the effect on existing implementations can be easily predicted; see also <xref target="extensibility"/>.</t> <t>Any intolerance also needs to be strongly supported byspecifications, otherwisespecifications; otherwise, they encourage fracturing of the protocol community or proliferation ofworkarounds; seeworkarounds. See <xref target="exclusion"/>.</t> <t>Intolerance can be used to motivate compliance with any protocol requirement. For instance, the INADEQUATE_SECURITY error code and associated requirements in HTTP/2 <xreftarget="H2"/>target="RFC9113"/> resulted in improvements in the security of the deployed base.</t> <t>A notification for a fatal error is best sent as explicit error messages to the entity that made the error. Error messages benefit from being able to carry arbitrary information that might help the implementer of the sender of the faulty input understand and fix the issue in their software. QUIC error frames <xreftarget="QUIC"/>target="RFC9000"/> are an example of a fatal error mechanism that helped implementers improve software quality throughout the protocol lifecycle. Similarly, the use of Extended DNS Errors <xreftarget="EDE"/>target="RFC8914"/> hasrecentlybeen effective in providing better descriptions of DNS resolution errors to clients.</t> <t>Stateless protocol endpoints might generate denial-of-service attacks if they send an errormessagesmessage in response to every message that is received from an unauthenticated sender. These implementations might need to silently discard these messages.</t> </section> <section anchor="exclusion"> <name>Exclusion</name> <t>Any protocol participant that is affected by changes arising from maintenance might be excluded if they are unwilling or unable to implement or deploy changes that are made to the protocol.</t> <t>Deliberate exclusion of problematic implementations is an important tool that can ensure that the interoperability of a protocol remains viable. Whilebackward compatiblebackward-compatible changes are always preferable to incompatible ones, it is not always possible to produce a design that protects the ability of all current and future protocol participants to interoperate.</t> <t>Accidentally excluding unexpected participants is not usually a good outcome. When developing and deploying changes, it is best to first understand the extent to which the change affects existing deployments. This ensures that any exclusion that occurs is intentional.</t> <t>In some cases, existing deployments might need to change in order to avoid being excluded. Though it might be preferable to avoid forcing deployments to change, this might be considered necessary. To avoid unnecessarily excluding deployments that might take time to change, developing a migration plan can be prudent.</t> <t>Exclusion is a direct goal when choosing to be intolerant of errors (see <xref target="intolerance"/>). Exclusionary actions are employed with the deliberate intent of protecting future interoperability.</t> <t>Excluding implementations or deployments can lead to a fracturing of the protocol system that could be more harmful than any divergence that might arise from tolerating the unexpected. The IAB documenton Uncoordinated"Uncoordinated Protocol Development ConsideredHarmfulHarmful" <xref target="RFC5704"/> describes how conflict or competition in the maintenance of protocols can lead to similar problems.</t> </section> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <t>Careless implementations, lax interpretations of specifications, and uncoordinated extrapolation of requirements to cover gaps in specification can result in security problems. Hiding the consequences of protocol variations encourages the hiding of issues, which can conceal bugs and make them difficult to discover.</t> <t>The consequences of the problems described in this document are especially acute for any protocol where security depends on agreement about semantics of protocol elements. For instance,use of unsafe security mechanisms, such asweak primitives <xreftarget="MD5"/> ortarget="RFC6151"/> and obsolete mechanisms <xreftarget="SSL3"/>,target="RFC7568"/> are good examples of the use of unsafe security practices where forcing exclusion (<xref target="exclusion"/>) can be desirable.</t> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name> <t>This document has no IANA actions.</t> </section> </middle> <back> <displayreferencetarget="H2"target="RFC9113" to="HTTP/2"/> <displayreference target="RFC6709" to="EXT"/> <displayreference target="RFC6891" to="EDNS0"/> <displayreference target="RFC4271" to="BGP"/> <displayreference target="RFC7606" to="BGP-REH"/> <displayreference target="RFC8446" to="TLS"/> <displayreference target="RFC9110" to="HTTP"/> <displayreference target="RFC9000" to="QUIC"/> <displayreference target="RFC8914" to="EDE"/> <displayreference target="RFC6151" to="MD5"/> <displayreference target="RFC7568" to="SSL3"/> <references> <name>Informative References</name> <reference anchor="HTML" target="https://html.spec.whatwg.org/"> <front><title>HTML</title> <author> <organization/> </author> <date year="2019" month="March" day="08"/> </front> <seriesInfo name="WHATWG" value="Living Standard"/> </reference> <reference anchor="H2"> <front> <title>HTTP/2</title> <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"> <organization/> </author> <author fullname="C. Benfield" initials="C." role="editor" surname="Benfield"> <organization/> </author> <date month="June" year="2022"/> <abstract> <t>This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection.</t> <t>This document obsoletes RFCs 7540 and 8740.</t> </abstract> </front> <seriesInfo name="RFC" value="9113"/> <seriesInfo name="DOI" value="10.17487/RFC9113"/> </reference> <reference anchor="RFC1958"> <front> <title>Architectural Principles of the Internet</title> <author fullname="B. Carpenter" initials="B." role="editor" surname="Carpenter"> <organization/> </author> <date month="June" year="1996"/> <abstract> <t>The Internet and its architecture have grown in evolutionary fashion from modest beginnings, rather than from a Grand Plan. While this process of evolution is one of the main reasons for the technology's success, it nevertheless seems useful to record a snapshot of the current principles of the Internet architecture. This is intended for general guidance and general interest, and is in no way intended to be a formal or invariant reference model. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.</t> </abstract> </front> <seriesInfo name="RFC" value="1958"/> <seriesInfo name="DOI" value="10.17487/RFC1958"/> </reference> <reference anchor="RFC0760"> <front> <title>DoD standard Internet Protocol</title> <author fullname="J. Postel" initials="J." surname="Postel"> <organization/> </author> <date month="January" year="1980"/> </front> <seriesInfo name="RFC" value="760"/> <seriesInfo name="DOI" value="10.17487/RFC0760"/> </reference> <reference anchor="RFC5218"> <front> <title>What Makes for a Successful Protocol?</title> <author fullname="D. Thaler" initials="D." surname="Thaler"> <organization/> </author> <author fullname="B. Aboba" initials="B." surname="Aboba"> <organization/> </author> <date month="July" year="2008"/> <abstract> <t>The Internet community has specified a large number of protocols to date, and these protocols have achieved varying degrees of success. Based on case studies, this document attempts to ascertain factors that contribute to or hinder a protocol's success. It is hoped that these observations can serve as 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="EXT"> <front> <title>Design Considerations for Protocol Extensions</title> <author fullname="B. Carpenter" initials="B." surname="Carpenter"> <organization/> </author> <author fullname="B. Aboba" initials="B." role="editor" surname="Aboba"> <organization/> </author> <author fullname="S. Cheshire" initials="S." surname="Cheshire"> <organization/> </author> <date month="September" year="2012"/> <abstract> <t>This document discusses architectural issues related to the extensibility of Internet protocols, with a focus on design considerations. It is intended to assist designers of both base protocols and extensions. Case studies are included. A companion document, RFC 4775 (BCP 125), discusses procedures relating to the extensibility of IETF protocols. This document is not an Internet Standards Track specification; it is published for informational purposes.</t> </abstract> </front> <seriesInfo name="RFC" value="6709"/> <seriesInfo name="DOI" value="10.17487/RFC6709"/> </reference> <reference anchor="EDNS0"> <front> <title>Extension Mechanisms for DNS (EDNS0)</title> <author fullname="P. Vixie" initials="P." surname="Vixie"> <organization/> </author> <date month="August" year="1999"/> <abstract> <t>The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow clients to advertise their capabilities to servers. This document describes backward compatible mechanisms for allowing the protocol to grow. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="2671"/> <seriesInfo name="DOI" value="10.17487/RFC2671"/> </reference> <reference anchor="BGP"> <front> <title>A Border Gateway Protocol 4 (BGP-4)</title> <author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"> <organization/> </author> <author fullname="T. Li" initials="T." role="editor" surname="Li"> <organization/> </author> <author fullname="S. Hares" initials="S." role="editor" surname="Hares"> <organization/> </author> <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="BGP-REH"> <front> <title>Revised Error Handling for BGP UPDATE Messages</title> <author fullname="E. Chen" initials="E." role="editor" surname="Chen"> <organization/> </author> <author fullname="J. Scudder" initials="J." role="editor" surname="Scudder"> <organization/> </author> <author fullname="P. Mohapatra" initials="P." surname="Mohapatra"> <organization/> </author> <author fullname="K. Patel" initials="K." surname="Patel"> <organization/> </author> <date month="August" year="2015"/> <abstract> <t>According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable because a session reset would impact not only routes with the offending attribute but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes.</t> <t>This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760, 5543, 5701, and 6368.</t> </abstract> </front> <seriesInfo name="RFC" value="7606"/> <seriesInfo name="DOI" value="10.17487/RFC7606"/> </reference> <reference anchor="TLS"> <front> <title>The Transport Layer Security (TLS) Protocol Version 1.3</title> <author fullname="E. Rescorla" initials="E." surname="Rescorla"> <organization/> </author> <date month="August" year="2018"/> <abstract> <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t> <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t> </abstract> </front> <seriesInfo name="RFC" value="8446"/> <seriesInfo name="DOI" value="10.17487/RFC8446"/> </reference> <reference anchor="RFC9170"> <front> <title>Long-Term Viability of Protocol Extension Mechanisms</title> <author fullname="M. Thomson" initials="M." surname="Thomson"> <organization/> </author> <author fullname="T. Pauly" initials="T." surname="Pauly"> <organization/> </author> <date month="December" year="2021"/> <abstract> <t>The ability to change protocols depends on exercising the extension and version-negotiation mechanisms that support change. This document explores how regular use of new protocol features can ensure that it remains possible to deploy changes to a protocol. Examples are given where lack of use caused changes to be more difficult or costly.</t> </abstract> </front> <seriesInfo name="RFC" value="9170"/> <seriesInfo name="DOI" value="10.17487/RFC9170"/> </reference> <reference anchor="HTTP"> <front> <title>HTTP Semantics</title> <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"> <organization/> </author> <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"> <organization/> </author> <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"> <organization/> </author> <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"/> </reference> <reference anchor="QUIC"> <front> <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title> <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"> <organization/> </author> <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"> <organization/> </author> <date month="May" year="2021"/> <abstract> <t>This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t> </abstract> </front> <seriesInfo name="RFC" value="9000"/> <seriesInfo name="DOI" value="10.17487/RFC9000"/> </reference> <reference anchor="EDE"> <front> <title>Extended DNS Errors</title> <author fullname="W. Kumari" initials="W." surname="Kumari"> <organization/> </author> <author fullname="E. Hunt" initials="E." surname="Hunt"> <organization/> </author> <author fullname="R. Arends" initials="R." surname="Arends"> <organization/> </author> <author fullname="W. Hardaker" initials="W." surname="Hardaker"> <organization/> </author> <author fullname="D. Lawrence" initials="D." surname="Lawrence"> <organization/> </author> <date month="October" year="2020"/> <abstract> <t>This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information. Extended DNS Error information does not change the processing of RCODEs.</t> </abstract> </front> <seriesInfo name="RFC" value="8914"/> <seriesInfo name="DOI" value="10.17487/RFC8914"/> </reference> <reference anchor="RFC5704"> <front> <title>Uncoordinated Protocol Development Considered Harmful</title> <author fullname="S. Bryant" initials="S." role="editor" surname="Bryant"> <organization/> </author> <author fullname="M. Morrow" initials="M." role="editor" surname="Morrow"> <organization/> </author> <author> <organization>IAB</organization> </author> <date month="November" year="2009"/> <abstract> <t>This document identifies problems that may result from the absence of formal coordination and joint development on protocols of mutual interest between standards development organizations (SDOs). Some of these problems may cause significant harm to the Internet. The document suggests that a robust procedure is required prevent this from occurring in the future. The IAB has selected a number of case studies, such as Transport MPLS (T-MPLS), as recent examples to describe the hazard to the Internet architecture that results from uncoordinated adaptation of a protocol.</t> <t>This experience has resulted in a considerable improvement in the relationship between the IETF and the ITU-T. In particular, this was achieved via the establishment of the "Joint working team on MPLS-TP". In addition, the leadership of the two organizations agreed to improve inter-organizational working practices so as to avoid conflict in the future between ITU-T Recommendations and IETF RFCs.</t> <t>Whilst we use ITU-T<title>HTML -IETF interactions in these case studies, the scope of the document extends to all SDOs that have an overlapping protocol interest with the IETF. This memo provides information for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="5704"/> <seriesInfo name="DOI" value="10.17487/RFC5704"/> </reference> <reference anchor="MD5"> <front> <title>Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms</title> <author fullname="S. Turner" initials="S." surname="Turner"> <organization/> </author> <author fullname="L. Chen" initials="L." surname="Chen"> <organization/> </author> <date month="March" year="2011"/> <abstract> <t>This document updates the security considerations for the MD5 message digest algorithm. It also updates the security considerations for HMAC-MD5. This document is not an Internet Standards Track specification; it is published for informational purposes.</t> </abstract> </front> <seriesInfo name="RFC" value="6151"/> <seriesInfo name="DOI" value="10.17487/RFC6151"/> </reference> <reference anchor="SSL3"> <front> <title>Deprecating Secure Sockets Layer Version 3.0</title> <author fullname="R. Barnes" initials="R." surname="Barnes"> <organization/> </author> <author fullname="M. Thomson" initials="M." surname="Thomson"> <organization/> </author> <author fullname="A. Pironti" initials="A." surname="Pironti"> <organization/> </author> <author fullname="A. Langley" initials="A." surname="Langley"> <organization/> </author> <date month="June" year="2015"/> <abstract> <t>The Secure Sockets Layer version 3.0 (SSLv3), as specified in RFC 6101, is not sufficiently secure. This document requires that SSLv3 not be used. The replacement versions, in particular, Transport Layer Security (TLS) 1.2 (RFC 5246), are considerably more secure and capable protocols.</t> <t>This document updates the backward compatibility section of RFC 5246 and its predecessors to prohibit fallback to SSLv3.</t> </abstract> </front> <seriesInfo name="RFC" value="7568"/> <seriesInfo name="DOI" value="10.17487/RFC7568"/> </reference> <reference anchor="RFC3117"> <front> <title>On the Design of Application Protocols</title> <author fullname="M. Rose" initials="M." surname="Rose"> <organization/>Living Standard</title> <author> <organization>WHATWG</organization> </author><date month="November" year="2001"/> <abstract> <t>This memo describes the design principles for the Blocks eXtensible eXchange Protocol (BXXP). This memo provides information for the Internet community.</t> </abstract></front><seriesInfo name="RFC" value="3117"/> <seriesInfo name="DOI" value="10.17487/RFC3117"/></reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9113.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1958.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0760.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.6709.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6891.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.7606.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9170.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8914.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5704.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6151.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7568.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3117.xml"/> </references> <section numbered="false" anchor="iab-members-at-the-time-of-approval"> <name>IAB Members at the Time of Approval</name> <t>Internet Architecture Board members at the time this document was approved for publication were:</t> <ulspacing="normal"> <li>Jari Arkko</li> <li>Deborah Brungard</li> <li>Lars Eggert</li> <li>Wes Hardaker</li> <li>Cullen Jennings</li> <li>Mallory Knodel</li> <li>Mirja Kuehlewind</li> <li>Zhenbin Li</li> <li>Tommy Pauly</li> <li>David Schinazi</li> <li>Russ White</li> <li>Qin Wu</li> <li>Jiankang Yao</li>empty="true" spacing="compact" bare="false" indent="3"> <li><t><contact fullname="Jari Arkko"/></t></li> <li><t><contact fullname="Deborah Brungard"/></t></li> <li><t><contact fullname="Lars Eggert"/></t></li> <li><t><contact fullname="Wes Hardaker"/></t></li> <li><t><contact fullname="Cullen Jennings"/></t></li> <li><t><contact fullname="Mallory Knodel"/></t></li> <li><t><contact fullname="Mirja Kühlewind"/></t></li> <li><t><contact fullname="Zhenbin Li"/></t></li> <li><t><contact fullname="Tommy Pauly"/></t></li> <li><t><contact fullname="David Schinazi"/></t></li> <li><t><contact fullname="Russ White"/></t></li> <li><t><contact fullname="Qin Wu"/></t></li> <li><t><contact fullname="Jiankang Yao"/></t></li> </ul> <t>The document had broad but not unanimous approval within the IAB, reflecting that while the guidance is valid, concerns were expressed in the IETF community about how broadly it applies in all situations.</t> </section> <section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t>Constructive feedback on this document has been provided by a surprising number of people including, but not limitedto:to, the following: <contact fullname="Bernard Aboba"/>, <contact fullname="Brian Carpenter"/>, <contact fullname="Stuart Cheshire"/>, <contactfullname="Wes Hardaker"/>, <contactfullname="Joel Halpern"/>, <contact fullname="Wes Hardaker"/>, <contact fullname="Russ Housley"/>, <contact fullname="Cullen Jennings"/>, <contact fullname="Mallory Knodel"/>, <contact fullname="Mirja Kühlewind"/>, <contact fullname="Mark Nottingham"/>, <contact fullname="Eric Rescorla"/>, <contact fullname="Henning Schulzrinne"/>, <contact fullname="Job Snijders"/>, <contact fullname="Robert Sparks"/>, <contact fullname="Dave Thaler"/>, <contact fullname="Brian Trammell"/>, and <contact fullname="Anne van Kesteren"/>. Some of the properties of protocols described in <xref target="decay"/> were observed by <contact fullname="Marshall Rose"/> in <xref section="4.5" sectionFormat="of" target="RFC3117"/>.</t> </section> </back><!-- ##markdown-source: H4sIAAAAAAAAA619W5fbyJHme/4KHOlhbR8WJfXVXXO841Kr2pLdktuq6tHO vuxJEkkSUyBAI4Gi2HXqn+3b/rGNLyLyAoCl9cM+eHrEIhKZkXH54sqLiwvT V33tLotn723V9PS/qtkWH9vV4Pvil67t23Vb+2embNeN3dP3ys5u+ovKri4O +teLPZ50jW3W7uLVV2Zte7dtu9NlUTWb1vhhta+8r9qmPx1ogXdXr826bbxr /OAvi74bnLm/LL42x+1lcf3mvbl3zeAuTVFsu3Y4yGdFER/Grrad3dNn9OL6 snDl/s+0n2Xbbekz2613l8Wu7w/+8sWL4/G41L+9wLf3tnlRV77Hzl7Qg/RA 5w5temBb9bthtVy3+xcgBy22am1XvpBjnzsyLVHTiX2fFsmfXOqKVfuFNV58 marLXb+vjbFDv2s7oswFvbMo5D7e245OU9zu2r1vG/6DE7rs+z/X7dE1fdce TsvG9eMH39j7qixu1ruqsb9V+YOl1w+Xles3f97iU1DEGJCt29u+uucLenv7 /udLfjIwET55xp+URJPL4quXr364ePn1xcs/8ofedZXzWEUeK4pPb69uP/3l svi5ugfj3fS2KYlqsqjtto7I+izQFWRY+oNbL4872x+3fK143duvZL0/XRYf f/rxh1evvpY9VP5QW2LEt7e3v7z4yhhzcXFR2JXvO7vujbndOfBQU2xbWxft pujpAyLUse3usBuvu/EF3craeV9Uvujbgm5lVTv+dt3S93rX7Q1uiyjtOruq 6qo/Yb1wmX5JF0TPkhQNe7qRonR+3VUr5wvaCFEzftNk174obLF3tuF32jXd wIF4d0fvtT1veVm8PhXuvq2ZdiBMtalI/EjWaOGmNBU94fBC+WxRVD2OcGhJ HvkELbF/OaxdYferajvwtu9dR/e5d1ihWHeOLrKwZuds3e/odevWn3zv9kuh X8eqogFxDl3VrCt644LOTmcoDrvOelcW1hfPVq5gqe/umX1INxS4xOLUDsQW TbkweF1NNOnoLvK/0sndoX+2KHa0DtObNlrSsqA/EbLaNrzV8WENkf8droTu M7+HtyQSdEImBRZcOdoo392hcz2tSq+2xb0lRpU7PNqTX5pPu4ro5du9S19W Qu9cfSigzTphCaFUYKewB6IJ/bPzxdo2pnFbpkJ9Kuxm49Z9MeeecA3L4tPO YU/hELhB4Zr6JOxC/3PlIn1BiIKXjeiiby/sfVsx9TzxXdVvbE2EUeHYV2VZ O2OeY+NdS7zBxMRV0/Hozdu2LYnn6AKIQ8FAfthuSfsJV5J+PeGFbUeik9Gd 1DJYZSBVNd410f/UNrybqiMq4KrphUt6fXGAalsPte0gCb76zbHY0aJYn74F Gr+7vv3JMDlANciYKyED4I+Wb4CY9Qgh3lUHPOA+s/7fPimcZlN1dB5SHuvB exLRnf2NlQA443CoT3i4f4L16aVtsepaW9Ld/s47Zx4e0vceH3+/4Dtp6db5 egriFeIPkQnoJbKdp4K0LL21KWu8asoahjZOdNjzhkp3qNsTtu35dcXDg/AG vYru9F1JzFifMt6YqARmCJLNwFBFdjW+lUsdGveZdAuRFIa7rFS/dHwV8UFw RE/6B/JOJ+ycJ73kymVxA6HJ97mvtrueDlvVNUmCXBQTtvBk3/oLqFP6Ul9t dY8gR74A74o23rQ99u6sr4iphgNsDsnBaqDVh/WOvoLr41foV4mKxKK0iN45 rl3vuSw2QwcRJbKaREUIxvOIhBQZ8Z0/PM8u9mllmLTMbtgyoZpNPYBWouf8 zh4CR6k2azcmVx3L4srDFql24j8RDorGhAThiuBG1dMdDdCev4R3e9VCJmrC h4d/Jwv56odv//j4uHiai215X4F2PRlq83D5z6Ht3aP578VrZtKKFNYRSgmK G3vHhfdtTSza6F86t3Zs0pdF8W7Ccnt6H9nnTVsTPpmaLVKsa3o10Wn0BpVl Nc6L7I09ENjGDjXEvznQ3W+6dp9/m7bAKhTi0g4rUsW4cxLp8WPERLRHEhZa 70igjbQVHYMo2sgRC9d1xIh7opTdOpKKGjTrlY0698+h6qDQTkzxYnwwtpb0 Nc/yJ7fJl7e2B3oFgECBu+cH8HHLqjDcd2KMTBtgHTbFpMEIB5LmhYUlOez4 GYiUvj0Yo3TXJtdYkIyqoYtlfhK2ZM05rBn1TEwZ7PnR1TX+i6PGzRXjzSXt D4jlGlj2ZTAllq1l5xSBWVCr9+GezzElcWImfbA8hDKOWKd0sKGevnBZfMg+ B9RxHf4mDLMhIMu0htKrnWXNk7QbkWFHoLjtyNzT8S7UjJZpQfD+PYsFSEYr kULGJbIZJIVDfs7gCGYR67Imof9zMu16PXSBpHW7JvqGBQkU8F/iC1izVbj+ /X5o2I55ZkYYRJMbREFyBCLpE1oRKjKt0pLvZNduM5DuhygymAhi4Z3u0wQu tyvYU2LyoelczXpGAS8EeEp22/d2fSfUvoHFZuVqwQ/rviWr1jYTdqEtrej6 CagSsRYjhB22DCXtzRm6imwKXTwzWAOOhlWj05PXJPZjbQfvJpbKk0gCpZB4 /ETkcZ/tnsFpfCkUUUJueENzb+uq1JeWrfPNf+OjtUfWyNBGuFaG4yAHWRy7 KNZkq0kjyD/oTWA68pPYqEKnhVs9tkNdCg48ko4LRonX52PMaI2XpkMxyd/1 wWZHGI/Lp4/Gpl3APbSwk/PoPiCxI9VE2lDsI6neA4tNjxXVQvo1OSNdRU7P 53U9lGD+XUt7F9t6FFkW4owWpT2T9iG38ATxJDxBOIq0vQ06N6jRygvSAVJ4 RzqIpHJhWKl2jjESX256V4JFnjcti5cgu3yhD0gVYN0kvybotJFWBszkl+EV i/P4Xk3oU3ayhZBG0s4vQWwU/y03N+zuBJMTDVLVK16aboJ8lmYMtSMl205P 2Q4+knXlgggDj5Hv2OVmlCAIGTOGEz0jCFHwwt7q2G1IgfR+bjlyrIt9QMvD g7FbCxsSlDEuRDSFAU8NWNn3cB5EyBuHzdnuxN6c4PGIWsDQY+9u4spiW6pG oJ+DFYzOnW0mFFSa6XV5w2+QuxHFF42AygqzF7ubJPDBrrKN8DgzRHvNXixJ rwlCAjfqNrjOWJG8SChIwrVHFb/g+hW5ghJFN4H5dGvDfoA6znzyajND8JGJ xFEecZkIcfAY6E6qbdWwUWFroEoDckoW2A/7Q6KVGBjWC1m4wLG7alTjsa8s 1BcGIh9tihbUf20bJ69wAb/zEji6iS7Z9GhsGUQzeTnjBmB/BS2e3d6mtkTe jXO1J3xEzmkP/EF3waAouksqoxWDtq5UzPFFDj9atTkcb2gN+zSsfyvRVWDl levpqMRcZSfytjqFsE4exCuung71gNSqS4PtH0eQkk+/GDn0DGyMOEfQlpAI 2uhW8UcLNiMaQTfU7Jl3xEvCnvd8lribafgIrA+mn18KPZx7Y0w/mITMob4y 6RRCdnvnxN8VInR0e0El53TIg2YEfAhUNK1RKQy+YgfvQEHGEz64xjhmURUB PuzTPS9+ItGtUrDuZkQAUYKgnvusLsVxV613X+aVktRPTS9kAIUgiS8IUQxg R+JMD8eXGYrEvQ9ohgl6GDoSMwd5hUPbEf7xbIb3gT/Ti4Rshvw4DagWvxvh reisji2yuH4vv//u5ePj7xkbAx6Uyq8GAiYxHdxXRwexiNsU+5YuTFYIajmH 5JlzKDEyfCHFU2GHR7uoAnoOAAHoc+h1XeXFIllx/pwVULyoskL0JIZGkpWE rxk9DUgGLTSxG6SJgcHORCNxIcHbDI6AuA0pKIn1ep+c28xjEPcOFwaVnflc 6d7oxFAQCsnJ1/vNzc/3BEZbh23TecSlUXymHDoQbo3L5ZxCREjxuKM9ISgU lpiFjNlQs+hY1rE1IvC035UTfC02Yd92LgX5ANoZaohwTug9VhY4XaOr4DHd hjUTVHaV9B4chw2IvkUkGhYAopjZVjgxfCsDxOcq6MJyFC+t9nsyHAP80pPs n75N7pFsyMadnNeGKViUPDBaB6krkNjxvw47Rql062oQRWPDUJn/h+aovMAK T0CVcLAxV9Ak+7aRgGCIKcyiPjfin+McMVWnYv7tV68Q4THRhe+C94sd2tyu HIjpiXNtJ4SBnKsjV1d3gVAcM2BiQfG69a5ht5OcAvKUHZs3AB/QYVjlYYfD WWXkF4YRLV+eiECvITEoGTboC35/zVEN8rtXAyiRxUhwAwxneSlIwFMBiyCd JH57+F0sYxPeZ1uTyxe71y2hZIhayhpsmxaqx0TwXSTwLW4jwvP1vvVwHJE8 UMSta5GPUQ/BP1OlB3iiNun6M9EhKoOH5y7/96Mxf+Hw+/hLD/9+/T9u/0SX /t33L394fGR4sid7C0EDXBIgQKrnwJH2lgzpEddqxK+iIwQspgbZNfdV1zbM ZpyJCdybi1SQM3UXgoUFRsT2yknGAq4VECzCvx5ooAlu6zxOddbXItneMMyq SbUTDAaghDieSKs1EjmidbueTsbxOj4lwUVE18zKbcDbtmHnW58TjoDLW46c 5Z6jKxKlXgXUWibNnNR/XGflxLvSECh7J0fOWXuJiwGLk1xz3CwFlsYXuXe4 h8qTevNAsJXfIVZVk34puiH3i4ITjCSXE3Wr0orXqg/IN0s7tER4goYhy6Hy DlvIEhDSGSZ61rTo3tYwZeJXk2SQ01IHzyikBaa4kG2h48AL3bDAdfGP1IGX DBGTdZb1EjX7Ybx7k3YvgGDFpgj+MZQF48Dgt5Ervwn0pLNFWgpe5dBtOqEE DfUSxjmyMgg9siagZmRi5aWQMkmGhpUYHXujSTGVInV5rUAKVUniP3FgsAC5 6B6edH9gqhvRftYTU+K8vNQ01OMV6Ce6S0hl5tYa9eispPFG+aYRLy6LX734 xcHeMCvAJ+U8j83IMbYnEhMuVqR35E/Nk1yOTCgDwZ70suMoyGYD64pwreRm zhhB8BLtfCiZux4erg5g6OpzcbX8GvJAuvDxEUiwF8EU3ww8EFVhCCtkdzsl AKH1CuaoPglEYP3Qdy1BEd3FIWg8TrsRVm5ZE7/5cPMSuvir775/JTk4djVq umS40Jmdfr7hD4NmzzBPBHuRRwUs7YGWi8YSMx8Jq7KeyQKWXsLJvTxvJs/3 wE/0+BE+Xcfue9BMHuTmhVhHMQzYhB3nSpz/wnUI7jMrXNEgYxG65Oy5MuaF cfwlpWQbrG/w7OEmtg39bYDjfMGypTUHERLMSys0I6vhOxgf79R7JG5BiQAt 4VUwVukwC0BN3mg3P5eiDYnlK65iFRZ1FEIKn8QxCZZe3TzmTjoCO+QI50pY It5vyHmSw8HuKZtnKN24C96CRJVlpxndwJ1N21ww6u3lPUuuvimkJgim4OEB H5D5r7wIHUe7kxdGaJ2dJ2YJUS2Zp52FTjkyzoETBrvVwcacq5xCHCy6oaCq zYrLPBBKtr0VhJ4MbVyCo6tzoiR4B6gcgv/rGEjSchNyCqSAYDu6OlVl2XHD WSpvog2P0UY5+Ou//AJhpf9AVL/5CqK6YDeA9hyO54tff3lzdXudLFI8Zvyk 6hUNhIiaHtvxDf3iQsnFuj2cEA6Vc/qYX2ShY1FZmMjvNcesDnYr0a2QlEAg AbkM+P3YMp2ADkAXvkeVEjSkJQbjSjtQ0XH4ID49OQtOqynL4Jj1HMGAUEJF 1CeTGUWWNGaKLPKzkHNqWiPolwQd9JUVcm3kPSB5RlpH3FB6mDNmyI2f5NmQ BBdsQM/jugG/YCjF2VaPoezskVj415oAJR0clhpE+f67l9/ptV58vH6Lq8VH RKHMiPXiCGj8lkMvKsJGU8+CtRaA7PXAtlsI3HanmNHhigQOQ+A8khhOtRHL sTa3o2wIqwfBvkkNyx1pgCDLOhSe8I/xjnZA+0VmEVgjbJRzH1XakewjoJxR iQNRd61hLJuUjoZ6EGwKAbUvZo1zNP5JXTfDtw3XaATm5kAzulpavsF5b4aH tAN3j1BC6XpyUv2/iQzTzV8UwpJS+fDwEKvP6FIvpm8MKVYLk2/C+1mxqm2/ 18jhFD6ROsY9w7LRJ7B6JSisd2meF1dCFcUG7PAgbWEj3MuL+6osZoxrSWo2 mr6IHdWDTcHylB1ndekrcmxlk5knhjqs8HrRcYzquIYGwc90w+XgFByGup1W Ql3TfEpeYaPWIcs2j1+ZXS38t+T5SQlOFvSZViAui9fsKdlQfWgPFSql9MEZ rJ3Sy6jTHGOdKL7D/TV2y/lktx46bKar/B0XAlWoRbG8QSGoJn9NHsJmJF5X pHdO6zp6KrDRMVcsO/SFq1jDd/gMMlyHYDuH2cR4J5jwRD4jlirFMGfTFu0B ETWNmYeKKMEIoq3yDEZkNoQS93tcx6xmjs+bHr4IGtcIDgs1qCpaiEqz+7p2 LFyMytg1EUjEu9OsHAe5JQq1ySBMFscPGYZBHLvrPYgtGj7npEodu41Ensjo qP4Bf0zyuWciwZLPwLLj8jCyHNud6SUgFW5OtBmqDGduFkn4W9vtEUj7MU/L 0SO3Kc2EDfyaKgzML1kdntj9c8V1oYK2yUOrMZdBqozoSniZjh5zxbNsZBaA kmx1O3ReInlrCQ+TTwAlDrYP6Y2YBnjj1haxpBL/RaXa03nPLOrBRsuVWoeh PpJmWmPU06SoZ7qBZNqP6g2yzxaCFxIuTRpPNELtGrzKBG1KGIFTyeL6w2+O ANayDy9x36lnEJN9SIuRtWpRIIPA+AFdA2TCpqTkdyC6z5WxSIZuxM8cFF0Q sT3z+ZMFmfGlRPg3ZGM6BjlTXmA3eVIjscd3Z6W+yX0a1w5NMtrssgbAwK6P wgS2Y23DEG2qgIu1w12IW6SRzpGTI+prXLJHinQrykvquvNSz3DBg1cgo3sH eSGFEu038iAnN1fIQOuWNdIcwg15yLApNHgKYOpEcRo+H7kTWSmk5rTrGG+P IVm6eZeFf0J4c5JZSceKjgg7b2FnbyoCzJ3TIJugJDO9is0U46Q8UxQwuead GBpO5oMlovokql+PQuKcEogFT17cRinOzUMFHKwCOFtoiJb+Xy5oak3uuoai oSyAvkSx3AQH4Fs7eiTlUBV803J9Z0uXv1EdjGmOtVFcSsoXSHhemCSo02q9 XxYtiAnhpoGNDaYtXvb5IhwtbSfmscRzdbuVijjSsCu7vivYpi+LvwcpuzTm D7Oa1KAetCi/LAteJwTW6OhVwwVM7OHCGpGl9Puqhxk3RcHlJCFGMz7RUWvX 1FFEjOUPxXXkyJmeYE9iM7BUS2404n8puuaXaECukIyErnrL1X3K7XLhIVpK jsp6B8hBd7bmKOJZi8WKAfnXLJQtcEFWZdcG6Znzy0MfWJJEEZ/YQEPOu/QF TEp4RhGQvIiWw23iiDiN8EBLN32WmpVYl0Q0x2WxyfNZ0SlZ60Sjzq8d2/Rk BCXfyzKJzgfR2Y2VqmryUugzq20PIhwbi1DozP8rrlFUiKjMGekQuzPKsXjV QFzypucHJau9Fm2R4D4jJcxlS/TfzFN5Rjcyqm5EM9jPN/CD6T/wgf/4zTff IbwRg+OcKqWD9XZ7QWZ32+8uOLZQSHMXV6aFtoBSCl+yiAcwP/JeqBRLtlSw NcJbM54yqOfnqiPE1kmy1YeuNhIGp1tpB5CJIxjY+49c/fnWkaccC9pYaQDm ctUqw5P9oT+lU9GlZwpyRvegVn3YJpfpkjtl2LhIyCP6GYtiLRWoU/ngL+ds CiIdxYZIzAnXwzYnqyu1Z4/EPhSXUHFwb3IcY6Cx/kV3PEPRTM6O78oisVch GqQwMTROBFD6NHzKMMnYqzDnq+aCWM6S5ERWJHAq5Ec5RsGw8Qw4ynMtHJAG je8S1DwLriVWZBBE8MNKZLzPnYGQVg1xg+J6I+WJD89TLIEkiGN3K3CGYMsR N6R9cWaQ7oR25LNwaX9kXcfh8paISngnVZuirB55iCPCV5Io1B4KcOHgRaGz 6QkGUOrdWFkl/SgKWKzXvAqQHilbiBnnfxwaNdexWUNaB20ol5g2J3jOdJ2x BpwUz2otYgF9kN2yZe1byBtOITylO84CjJ6Te2deERyhTfU5LFOpa4hSLfat Oi26XrlxaD6moEXfi8QF773lJpPcL7QheVGxYYscDoqS24fb4FgiHQ4COdpL LOTlSP9TGTsggfzRuf5QvRo5Kz+PkmhWtMSc1kiQQtMbKLtvuHIJPmTwG6GY w9YmO5E41f9PSo4RgkQqJ4efVkftIDmcKdZyoqn6yRlmFDqb2RQOkLkelyFA Jpf5SSmfNAvFAhtEQmJoIYQ4LgxuhhtL1dfi9N8k1jELHRRFHoQGnAn8PMLe LBbxzqe3W40wE8Af7DBay9Omk+r2wwGMWsp181frvJwnhIQVF6gq4/RapsYE ZovS8QSXZ2W7HP7yUgF2wd+YYxlsTxziUJYrcW1U0qCtBPbpvqrdFoFQd5Ti xuBOr4aqLlOlxgQcShEHqhAR6CCQUhFhteYPxgtBB/U9m2FP4NDMb4fvnV3X +Ax52KRDnZxfM6ikmO2dzwrS6QyGs6SzAwfpDXlqTiZXnvtrYjLy2KJ9VBoK +GxZIqXTAAvLMi571wJbB+swa3Lk75USU+CGzI3tjGWYnqrTV27mv8coVixj mIW8Q6CHDUUpRakN4SGu+JIepi7mKDWm0lV8LZxGeKK2NtBIUsV166WptCFA Qj5KxIukXdg0Yblz2+Pt1IR/oXFzsnCEi+MNXIXVKkTIq5OW5+yjWKqRWKLA rO85xc0VZCEwOn2UjyuXwNkgjlVm1kN1m+fb1up+WsOu+5BUiVBjXCwhBS/n VNudC8VtoYCbyHBfZaMFpqt8UVNydcIkyb2KgVxNU+AaOHJfidANscuHnaIQ JjEp6MIRnFAGIl6DVkVUscpfuIG+qIWcUiCm5lMy2ZJPCYqTK9htRy7Bmfrt xIo4kcwu8OogBtKYVD0117Usc8i6wSUtYouFwutJ0/EZ7014XHTjTKRA4JFu iO6IulQmxRLGRTGphuRcnSc++5lk/eIWndH/kbGBiUHe61j69D6VPkkt6A+v vn8ppSg3sQiPgxICZGMD6JO0hq09kXvSYvTHmu2gNBDmkSgtLCiuiknpfyU4 Uj1Zzqqk3o+R4C7MChjgXrRMKMkpzw+3EFAkqkE8eW5Lk5UXRq5oVLQotUDL L8a/Q1sH99+iAD5QYRGShDw3AjhKgWKfJX4WimTx3j2Phek0fyhdD/G23mep kofn2mv+hR5yFaMdKW2ge/Zh1F/wduO2g5X+rtCExQW0JsSNZ3GXLM5KFNdq hetUcHKUiRMjopMXCXb2RDMhchkKOOWWgC/g55VsU4nJFmOUuhpBRqNBqtTk NPE5SwcvnDeCTjStsitTeH1c+m+k1KwizhM/bLR3sfec0UJe4Qv9kjjipMc6 dizkiDck/9fiokziwWca1jR8liImfLQWygI4c8LfcLQ0Fqe5wpzdz+i1i6xc QbJc6j5faGhJQnXGsp/cVz1KK2J47os5odgrdi5iGAubwO8SedXS7lRyU7wO HbyQqloim6nqAG78pPcsOjFnxP6MR8WFZEGrn5/QYSbtMyHDVPk0ToRRvJbZ 5KMoWKZi+D4Ob1Ex5DNsBi5mOAdARyqIQcJx1zJI+4lrQFIxRqsuHm1ZBnBE gx/avUcYlYOb/wqFYlf1oeUaiGQEucoFQb5KJSAluQIaaOty0kGnFbwdKlAy kR0FIUWBNCPkG4AyjzoIXcWh6W3Skawdw9qPC8VsfSi5X2lrdtb+y5F5ph+X vWovNz22GCtAtHLaJlT8mHzggkRA1SAlvMYG6aDt8bwWLB9TBqUH+FQb6WaZ JakCgB7FyVFo3qy5WHzD2CZg/unZ+QZnBRqoXMzz6zq1RMpefPBa5wOruNrI c7ZlJyUuOnkNhcegGmeZgMniKaYt0jcxsBaS6edaNYl3CB2sd7pQOdVoo5DC ubqIvH55ooFlnsy+vddpLjx4Y8Up785H7DrzzTMjaxhbydwun0FqbYgM7v3Y i/ggbRIBBHP/AO2MxwtxLtuO29ZS3W6KrRAEi904S5PgWjaiqQtRnfqUgrdl 1rvpZlBSaJxCgxNaT2YqVTpqRmcraXlOjBNIi7BItQZgzpR5CC6b3WueVuCU DBsJo+UiUjyH8K/VYjPZOdtMhlhdr4n86eW9a/ibochE0B1pzvTNrMxofA0c T4mTMRCNjlWwKhYLI7GDU1AFqmQEa1fdrL+M9cvkHQipoMe49WfGd0WVqX5n IKyg23FrlDRqnO/D5Ur46aATydJyME0GA7C6nYku8u5DE9uTREUDHspwOQ4B YfMJTsq0uWmRhTXyXvVrc+tfNaFqNvK+8q1dj4qFiCeCAeIEnVTnx6YzxzhI +404Rx7m6gVEjXafyrcynQSpsHErITacUuej3nqUBJNPKS4lvM3rs+mE0YWw IbYql3Q6ukx1DPl8GtaQCUYzE+yViWJOhMPo2vIySVWc4XuT2eOZtLFPcT5O v3JhMN7qxP5daiwZxW55SsBSC5s0I5oKJJxmbdIDXB/ve5NCB3STcHDF+5PK lyeajkOciZ176Svo5OQmSkLJmdIzL+bJH1IlGpP50v3JX5X7hHIYVS5+cNsa hIaMkMyt76Scmqcccrjw/ACG8+MZl+Yj2UcusB/LPxK0MsVJIUwVYx3ZBLWq UXXHI+VMQEDZaijor2Jx2ggoCm+njCTBc5kpZJtx4ly+i1qrUAsDQsaS59Ao PI1dwkkBdLsAIQZkmhfj1F012ZOEuEJ4SKKn8wLPG679igAE2+JOqNTzh2mc CE3gv3+SeZ0vHx8LzPLpjM28SNpThej2aIpCuhBeZ1pb3IZqYk7Tt3cjkCdV ZDwYYjR6YaIGMWRDSzYCZtZkMU9A1EbkWKe+OjGSCrWsCQ5olGOS8xE9nDfg jmK+JiQNSDQ0wMvFQhyDR+ReKwZPuVZTVRQYyx8qMn9fnFxzpjWC9wVBWOS4 yOcDqtQbzdvr8jx3n+L7UuCjQZ/YX4rhb0RFzDsSTjbKuSGEaz3G3aWZiJqP m9yyUjS4xqxY6H0lV1FCPkZdClpVHmQskS3eTJSVxdiN5tFmnUQ69lMZBYSO OkWjIfmVpAA962EtSaytFuszoA0Xlp7ThPV/VF3PPcXvUllu8fA8L9KN7aRK nFHLe6PDmlLfaMLXRd7pGQprTF6+IuUzMdHC17qzzfop/M72h21meguXkYxx fP7eoRk8WrZHXRM/Ih2iPBO7jLIaGznJ0KQTZ4XtIXRHSgkdAIgnwKxwbY7O QJMMTs6x7FPG2iy06Ei5naLijN4xBme7Rsa8pOm5XKbZRbgRi5XONXSmBfsW c0nJy2/rhEEmCE7k0GcGULydWQVFlVdpxJmxZzJrsdzGB+jGWkeaFrIIVxh4 yLGH2OSk+ee4HSlvESezT93sOsktGDwilppiDjVxWWTQtov8vU9VB7BPFTAi 1xlwh1Jqo1Dtc2J3Kq8oIix0Lr8kqJ50IO9YUfvS6EgNQFlpcuBuL5QCc+Ro mlOKwedQZ7Fz6zu95i8lLrJj7VFTede0Rx0IwAkoRtUkCSEqo6OFOKw8L/PX mmw50rDHjAY2IW2XdVkh1XKxsSj9M1LbBN8CwEVGxOrwCan17+SLMWhZ/J2h R3hThuloc3CR2SMvKx5wEJ0IDZir5PIZQ7Ysxm/w5RCv6f9VRJpDdbOzsUJc pzlpOu9cqfay+HsTs2owohqqigHHWe5PhpRyE359ylTtuNfqfI617cykaRwb Eiw6tlrF5BBf2JEuJENvueynAgr5tyJrQx5PjXjkKtzTiMKRDUN4MIYg1HUX 0Zm6H3F2oUmlewhXEC63GD6bdbpnUZE4z4phD8qfu5CKMJnFlCNg9xok5p2/ m6vgQbWvjiZy0/qmQsd+zaqQlmbuAr/7cPXm+h+/Xt1e/6+b6x9//fju9j9j QWcpsSfrfbuuGGqMKlSqxshkedr0268IwopjJOXKUwglFQfanqTILOovdJZy aS3JRNL+0iSY15jGSTEc//BpiNJoNm1IrBlIQUjDsaJhHsNXl1KBnPW2anqW HazVqEkLzSUnY7tVxSJTxF8BCOF6rWnAHPRpuHU0WTAcezR2N41JkBmtkj3T OGsVAjIBgC6Lf/z67kc97gbTIbwhVwIfsivx8iW7Ep2b9ECPyZhmEEiVBe3c lXmw2sdRaTH28s/B6oAm7i6azqxK7WNLc1PtK3ahFpKWhU/+5sNNKPrmMQHX XJr7w6tvaLtQYbCwbNrQ5WpGGT6JUUkHLE8zEPf0EDED1uZ520OWapJARaVF kDdwVWtxAUI9YVNKseK0rbt0TWXri3ZzwfWQaxdGvoayP8wKK2cTkb302rHH JLMCGXGNCnizMviQVUKIakByq9ex7TqFUovZz9etBAM6HaBppMI37CgO1QlZ JwzUCcpFlGIkR9aqHveauXjRhxkVweS/AxI9Kp2UWsYqSZmrFZLgjGCDbKVo ZuzADG8ysftRRHecK0evkZPJZL2+MosrAmtwrv5crVmTTejnzi4GgFNkHDuO Jr9pYXPNKhlh5Km4JRgD4AxwIQPbrJ02Ec+FqUgHLnaPdGiyb7eNC79VYWS2 sDyRzaEMER0bhnnks0inFSEyg4YRurglmq47d/eTWZw88+EqTj3hlsjgIGaJ 0tECOmSF/RuYdplQQAoDGdilJIU0LBqGpyckmRJzfdT2HAJFUVmmK1mTf2ZH C0UzcUSTTua0mps8FwIkPDev8iSTaRIX8Ufs1fjJ2GXpDebEHOdFFmdfMRHT NC40VqBK/wQbGhMEhjcWmsaiOI0ZRfsutIllGi7k9+j84LhANr01C3agXUAW G5rwcZXfr5lV48mKPc/uQEgmvXF0n/ieAhy4+2Fe0KEbSglRJn0kpZ+Cm3lo IqPRdeYGC2bM/DLV7vrbEqOu3d8vk6qz2bQC9on2+bQiicxH9SH3axRXO4nb hJz2FELr/stzWcDJDzXkc9btHCNmCawwQ9b2KZPAAHmnfbkyqA8DKLQEJEyq zNLRRkacP9XdI/Wn0+KqX0nz8HRkNj4hjE3KNWW/fkwMFNqEdcre9y9hv9Ov +SAOiALeGt4gwX8oNddXIVciVbdPTDvNieUFQeSdpeZ5cRPgY9iQ1r6YH20n xn32gz+1/TwtlZl3K8oQ2WFECExlsoc21caNkC8neZD739qDBAjH0yotjyDR JEFEvSlb8LYKIbZZribyRNYGm/W04JFdFUZqpYH7Ff/eRxMKt7RllRRlGLWz T6Fvk5ftxkGvo11ksQw/7pQfZwpYtFLhlF0PPU/EGLsgkiKIdMjnJ4TW0lmr X0YKE2a8TVN42nQ7NCgCS+un6GzWiu3sHYpgUOKIQA4x8Ps33/LUwFffviIm Ru52RRjSjcO79L2bm5+/5mEq337HvxqCM8OkGcXXPk3dCXo5WZLfjfy536dg uK9CsTJ+bOjqw9WMq8c/mbXjSSDyTVVs4UeLgDhkldfFe4dqcLp6QTC32md7 dQCKtrV5uJR6cVf+6dmGvGD37NGkn0fJfkfFFa/x+21Ei9GCovhHO0P82vL6 5ERw10I2AhMNY9yz81diZ1r/7q6lf7xxq7azu+J1NzRb4NY/FD+jpeh6u3Vd T//6RFQlXVMS83ZoTxkwZbP4q2vwYySePnmPoBvp+L815KXW+KDq/ssWf/s/ /3tXu2PVYMn/ScZkRSz7c4XeUHLDT8Uv5HqdsIHxr7/9ofg4kPr4hMPTP/5B D30asGlyqu/IwhX/aVsRlOw+SvmhIy7IYcBDSq3aI2htldpsbNJP1qDse1OL eRF0e0wjg7OREDwNZ6EFAqHpTnvds9/Aub79KQUXjMgPl7Tozy9JqxaXmekc wjRNZSlVmQhK1a7csnSd540fuWR3EG8sxj3bqSKIv/KTTwRDtR1pXnEYUp/C wbVSiKZmdBFJGCre+/aSJO/hNdIgxINXq3ZlHzHPFR+SWmwKUvkHdlXxMb57 Q0fryFaRA7QjPR0+zhkprPDX1tX0ITm9XRO+x/f/FmPC3Sl8NuG68PiY9cKX p/wXP7fdXfGh7XHpO7sPi1x35J18JMXadrUN330rbwJfDvVvhBSaeI6/tqvi pqn+CwA4rPGxXaGA5IbQ950PX3yDNMTtztaJNEKx287u967mDbMXQH+5ojcQ uzXF3whno57zETEn/gWGZASyHG2y1pPpKTJb41FYVRoJSRmsTkoBvwP7fWw9 ziNP3EgfbPHN8lusDDjx9atX3+P9/xeH4pkvl3MAAA== --></rfc>