<?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-rfc2629 version 1.5.6 --> <?rfc toc="yes"?> <?rfc sortrefs="yes"?> <?rfc symrefs="yes"?> <?rfc docmapping="yes"?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-iab-use-it-or-lose-it-04"category="info"number="9170" obsoletes="" updates=""submissionType="IETF"submissionType="IAB" category="info" consensus="true" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3"><!-- xml2rfc v2v3 conversion 3.10.0 --><front> <title abbrev="Use ItOror LoseIt">Long-termIt">Long-Term Viability of Protocol Extension Mechanisms</title> <seriesInfoname="Internet-Draft" value="draft-iab-use-it-or-lose-it-04"/>name="RFC" value="9170"/> <author initials="M." surname="Thomson" fullname="Martin Thomson"><organization>Mozilla</organization><address> <email>mt@lowentropy.net</email> </address> </author> <author initials="T." surname="Pauly" fullname="Tommy Pauly"><organization>Apple</organization><address> <email>tpauly@apple.com</email> </address> </author> <date year="2021"month="October" day="13"/>month="December"/> <keyword>Extensions</keyword> <keyword>versions</keyword> <keyword>grease</keyword> <abstract> <t>The ability to change protocols depends on exercising the extension andversion negotiationversion-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><note removeInRFC="true"> <name>Discussion Venues</name> <t>Discussion of this document takes place on the EDM Program mailing list (edm@iab.org), which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/edm/"/>.</t> <t>Source for this draft and an issue tracker can be found at <eref target="https://github.com/intarchboard/use-it-or-lose-it"/>.</t> </note></front> <middle> <section anchor="introduction" numbered="true" toc="default"> <name>Introduction</name> <t>A successful protocol <xreftarget="SUCCESS"target="RFC5218" format="default"/> needs to change in ways that allow it to continue to fulfill the changing needs of its users. New use cases,conditionsconditions, and constraints on the deployment of a protocol can render a protocol that does not change obsolete.</t> <t>Usage patterns and requirements for a protocol shift over time. In response, implementations might adjust usage patterns within the constraints of the protocol, the protocol could be extended, or a replacement protocol might be developed. Experience with Internet-scale protocol deployment shows that each option comes with different costs. <xreftarget="TRANSITIONS"target="RFC8170" format="default"/> examines the problem of protocol evolution more broadly.</t> <t>An extension point is a mechanism that allows a protocol to be changed or enhanced. This document examines the specific conditions that determine whether protocol maintainers have the ability to design and deploy new or modified protocols via their specified extension points. <xref target="implementations" format="default"/> highlights some historical examples of difficulties in transitions to new protocol features. <xref target="use-it" format="default"/> argues that ossified protocols are more difficult to update and describes how successful protocols make frequent use of new extensions andcode-points.code points. <xref target="other" format="default"/> outlines several additional strategies that might aid in ensuring that protocol changes remain possible over time.</t> <t>The experience that informs this document is predominantly at "higher" layers of the network stack, in protocols with limited numbers of participants. Though similar issues are present in many protocols that operate at scale, thetradeoffstrade-offs involved with applying some of the suggested techniques can be more complex when there are many participants, such as at the network layer or in routing systems.</t> </section> <section anchor="implementations" numbered="true" toc="default"> <name>Imperfect Implementations Limit Protocol Evolution</name> <t>It can be extremely difficult to deploy a change to a protocol if implementations with which the new deployment needs to interoperate do not operate predictably. Variation in how newcodepointscode points or extensions are handled can be the result of bugs in implementation or specifications. Unpredictability can manifest as errors, crashes, timeouts, abrupt termination of sessions,errors, crashes,or disappearances ofendpoints and timeouts.</t>endpoints. </t> <t>The risk of interoperability problems can in turn make it infeasible to deploy certain protocol changes. If deploying a newcodepointcode point or extension makes an implementation less reliable than others, even if only in rare cases, it is far less likely that implementations will adopt the change.</t> <t>Deploying a change to a protocol could require implementations to fix a substantial proportion of the bugs that the change exposes. This can involve a difficult process that includes identifying the cause of these errors, finding the responsible implementation(s), coordinating a bug fix and release plan, contacting users and/or the operator of affected services, and waiting for the fix to be deployed.</t> <t>Given the effort involved in fixing problems, the existence of these sorts of bugs can outright prevent the deployment of some types of protocol changes, especially for protocols involving multiple parties or that are considered critical infrastructure (e.g., IP, BGP, DNS, or TLS). It could even be necessary to come up with a new protocol design that uses a different method to achieve the same result.</t> <t>This document only addresses cases where extensions are not deliberately blocked. Some deployments or implementations apply policies that explicitly prohibit the use of unknown capabilities. This is especially true of functions that seek to make security guarantees, like firewalls.</t> <t>The set of interoperable features in a protocol is often the subset of its features that have some value to those implementing and deploying the protocol. It is not always the case that future extensibility is in that set.</t> <section anchor="not-good-enough" numbered="true" toc="default"> <name>Good Protocol DesignisIs Not Itself Sufficient</name> <t>It is often argued that the careful design of a protocol extension point orversion negotiationversion-negotiation capability is critical to the freedom that it ultimately offers.</t> <t>RFC 6709 <xreftarget="EXTENSIBILITY"target="RFC6709" format="default"/> contains a great deal of well-considered advice on designing forextension.extensions. It includes the following advice:</t><ul empty="true"> <li> <t>This<blockquote> <t> This means that, to be useful, a protocol version-negotiation mechanism should be simple enough that it can reasonably be assumed that all the implementers of the first protocol version at least managed to implement the version-negotiation mechanismcorrectly.</t> </li> </ul>correctly. </t> </blockquote> <t>There are a number of protocols for which this has proven to be insufficient in practice. These protocols have imperfect implementations of these mechanisms. Mechanisms that aren't used are the ones that fail most often. The same paragraph from RFC 6709 acknowledges the existence of thisproblem,problem but does not offer any remedy:</t><ul empty="true"> <li> <t>The<blockquote> <t> The nature of protocol version-negotiation mechanisms is that, by definition, they don't get widespread real-world testing until<em>after</em><strong>after</strong> the base protocol has been deployed for a while, and its deficiencies have becomeevident.</t> </li> </ul>evident. </t> </blockquote> <t>Indeed, basic interoperability is considered critical early in the deployment of a protocol. A desire to deploy can result in early focus on a reduced feature set, which could result in deferring implementation ofversion negotiationversion-negotiation and extension mechanisms. This leads to these mechanisms being particularly affected by this problem.</t> </section> <section anchor="disuse" numbered="true" toc="default"> <name>Disuse Can Hide Problems</name> <t>There are many examples of extension points in protocols that have been either completelyunused,unused or their use was so infrequent that they could no longer be relied upon to function correctly.</t> <t><xref target="examples" format="default"/> includes examples of disuse in a number of widely deployed Internet protocols.</t> <t>Even where extension points have multiple valid values, if the set of permitted values does not change over time, there is still a risk that new values are not tolerated by existing implementations. If the set of values for a particular field of a protocol or the order in which these values appearof a protocolremains fixed over a long period, some implementations might not correctly handle a new value when it is introduced. For example, implementations of TLS broke when new values of the signature_algorithms extension were introduced.</t> </section> <section anchor="middleboxes" numbered="true" toc="default"><name>Multi-Party<name>Multi-party Interactions and Middleboxes</name> <t>One of the key challenges in deploying new features is ensuring compatibility with all actors that could be involved in the protocol. Even the most superficially simple protocols can often involve more actors than is immediately apparent.</t> <t>The design of extension points needs to consider what actions middleboxes might take in response to a protocolchange,change as well as the effect those actions could have on the operation of the protocol.</t> <t>Deployments of protocol extensions also need to consider the impact of the changes on entities beyond protocol participants and middleboxes. Protocol changes can affect the behavior of applications or systems that don't directly interact with the protocol, such as when a protocol change modifies the formatting of data delivered to an application.</t> </section> </section> <section anchor="use-it" numbered="true" toc="default"> <name>Active Use</name> <t>The design of a protocol for extensibility and eventual replacement <xreftarget="EXTENSIBILITY"target="RFC6709" format="default"/> does not guarantee the ability to exercise those options. The set of features that enable future evolution need to be interoperable in the first implementations and deployments of the protocol. Implementation of mechanisms that support evolution is necessary to ensure that they remain available for new uses, and history has shown this occurs almost exclusively through active mechanism use.</t> <t>Only by using the extension capabilities of a protocol is the availability of that capability assured. "Using" here includes specifying, implementing, and deploying capabilities that rely on the extension capability. Protocols that fail to use a mechanism, or a protocol that only rarely uses a mechanism, could lead to that mechanism being unreliable.</t> <t>Implementations that routinely see new values are more likely to correctly handle new values. More frequent changes will improve the likelihood that incorrect handling or intolerance is discovered and rectified. The longer an intolerant implementation is deployed, the more difficult it is to correct.</t> <t>Protocols that routinely add new extensions and code points rarely have trouble adding additionalones,ones especially when the handling of new versions or extensions are well defined. The definition of mechanisms alone is insufficient; it is the assured implementation and active use of those mechanisms that determines their availability.</t> <t>What constitutes "active use" can depend greatly on the environment in which a protocol is deployed. The frequency of changes necessary to safeguard some mechanisms might be slow enough to attract ossification in another protocol deployment, while being excessive in others.</t> <section anchor="need-it" numbered="true" toc="default"> <name>DependencyisIs Better</name> <t>The easiest way to guarantee that a protocol mechanism is used is to make the handling of it critical to an endpoint participating in that protocol. This means that implementations must rely on both the existence of extension mechanisms and their continued, repeated expansion over time.</t> <t>For example, the message format in SMTP relies on header fields for most of its functions, including the most basic delivery functions. A deployment of SMTP cannot avoid including an implementation of header field handling. In addition to this, the regularity with which new header fields are defined and used ensures that deployments frequently encounter header fields that they do not yet (and may never) understand. An SMTP implementation therefore needs to be able to both process header fields that it understands and ignore those that it does not.</t> <t>In this way, implementing the extensibility mechanism is not merely mandated by the specification, it is crucial to the functioning of a protocol deployment. Should an implementation fail to correctly implement the mechanism, that failure would quickly become apparent.</t> <t>Caution is advised to avoid assuming that building a dependency on an extension mechanism is sufficient to ensure availability of that mechanism in the long term. If the set of possible uses is narrowly constrained and deployments do not change over time, implementations might not see new variations or assume a narrower interpretation of what is possible. Those implementations might still exhibit errors when presented with new variations.</t> </section> <section anchor="version-negotiation" numbered="true" toc="default"> <name>Version Negotiation</name> <t>As noted in <xref target="not-good-enough" format="default"/>, protocols that provideversion negotiationversion-negotiation mechanisms might not be able to test that feature until a new version is deployed. One relatively successful design approach has been to use the protocol selection mechanisms built into a lower-layer protocol to select the protocol. This could allow aversion negotiationversion-negotiation mechanism to benefit from active use of the extension point by other protocols.</t> <t>For instance, all published versions of IP contain a version number as the four high bits of the first header byte. However, version selection using this field proved to be unsuccessful. Ultimately, successful deployment of IPv6 over Ethernet <xref target="RFC2464" format="default"/> required a different EtherType from IPv4. This change took advantage of thealready-diversealready diverse usage of EtherType.</t> <t>Other examples of this style of design include Application-Layer Protocol Negotiation (<xreftarget="ALPN"target="RFC7301" format="default"/>) and HTTP content negotiation (<xref section="12" sectionFormat="of"target="HTTP"target="I-D.ietf-httpbis-semantics" format="default"/>).</t> <t>This technique relies on thecodepointcode point being usable. For instance, the IP protocol number is known to be unreliable and therefore not suitable <xref target="NEW-PROTOCOLS" format="default"/>.</t> </section> <section anchor="grease" numbered="true" toc="default"> <name>Falsifying Active Use</name> <t>"Grease" was originally defined for TLS <xreftarget="GREASE" format="default"/>,target="RFC8701" format="default"/> but has been adopted by otherprotocols,protocols such as QUIC <xreftarget="QUIC"target="RFC9000" format="default"/>. Grease identifies lack of use as an issue (protocol mechanisms "rusting" shut) and proposes reserving values for extensions that have no semantic value attached.</t> <t>The design in <xreftarget="GREASE"target="RFC8701" format="default"/> is aimed at the style of negotiation most used in TLS, where one endpoint offers a set of options and the other chooses the one that it most prefers from those that it supports. An endpoint that uses grease randomly offersoptions -options, usually justone -one, from a set of reserved values. These values are guaranteed to never be assigned real meaning, so its peer will never have cause to genuinely select one of these values.</t> <t>More generally, greasing is used to refer to any attempt to exercise extension points without changing endpointbehavior,behavior other than to encourage participants to tolerate new or varying values of protocol elements.</t> <t>The principle that grease operates on is that an implementation that is regularly exposed to unknown values is less likely to be intolerant of new values when they appear. This depends largely on the assumption that the difficulty of implementing the extension mechanism correctly is as easy or easier than implementing code to identify and filter out reserved values. Reserving random or unevenly distributed values for this purpose is thought to further discourage special treatment.</t> <t>Without reserved greasingcodepoints,code points, an implementation can use code points from spaces used for private or experimental use if such a range exists. In addition to the risk of triggering participation in an unwanted experiment, this can be less effective. Incorrect implementations might still be able to identify these code points and ignore them.</t> <t>In addition to advertising bogus capabilities, an endpoint might also selectively disablenon-criticalnoncritical protocol elements to test the ability of peers to handle the absence of certain capabilities.</t> <t>This style of defensive design is limited because it is only superficial. As greasing only mimics active use of an extension point, it only exercises a small part of the mechanisms that support extensibility. More critically, it does not easily translate to all forms of extension points. For instance,HMSVhighest mutually supported version (HMSV) negotiation cannot be greased in this fashion. Other techniques might be necessary for protocols that don't rely on the particular style of exchange that is predominant in TLS.</t> <t>Grease is deployed with the intent of quickly revealing errors in implementing the mechanisms it safeguards. Though it has been effective at revealing problems in some cases with TLS, the efficacy of greasing isn't proven more generally. Where implementations are able to tolerate a non-zero error rate in their operation, greasing offers a potential option for safeguarding future extensibility. However, this relies on there being a sufficient proportion of participants that are willing to invest the effort and tolerate the risk of interoperability failures.</t> </section> <section anchor="ex-active" numbered="true" toc="default"> <name>Examples of Active Use</name> <t>Header fields in email <xreftarget="SMTP"target="RFC5321" format="default"/>, HTTP <xreftarget="HTTP" format="default"/>target="I-D.ietf-httpbis-semantics" format="default"/>, and SIP <xreftarget="SIP"target="RFC3261" format="default"/> all derive from the same basic design, which amounts to a list of name/value pairs. There is no evidence of significant barriers to deploying header fields with new names and semantics in email and HTTP as clients and servers generally ignore headers they do not understand or need. The widespread deployment of SIPB2BUAs,back-to-back user agents (B2BUAs), which generally do not ignore unknown fields, means that new SIP header fields do not reliably reach peers. This does not necessarily cause interoperability issues in SIP but rather causes features to remain unavailable until the B2BUA is updated. All three protocols are still able to deploy new features reliably, but SIP features are deployed more slowly due to the larger number of active participants that need to support new features.</t> <t>As another example, the attribute-value pairs (AVPs) in Diameter <xreftarget="DIAMETER"target="RFC6733" format="default"/> are fundamental to the design of the protocol. Any use of Diameter requires exercising the ability to add new AVPs. This is routinely done without fear that the new feature might not be successfully deployed.</t> <t>These examples show extension points that are heavily used are also being relatively unaffected by deployment issues preventing addition of new values for new use cases.</t> <t>These examples show that a good design is not required for success. On the contrary, success is often despite shortcomings in the design. For instance, the shortcomings of HTTP header fields are significant enough that there are ongoing efforts to improve the syntax <xreftarget="HTTP-HEADERS"target="RFC8941" format="default"/>.</t> </section> <section anchor="restoring-active-use" numbered="true" toc="default"> <name>Restoring Active Use</name> <t>With enough effort, active use can be used to restorecapabililities.</t> <t>EDNS <xref target="EDNS" format="default"/>capabilities.</t> <t>Extension Mechanisms for DNS (<xref target="RFC6891" format="default"/>) was defined to provide extensibility in DNS. Intolerance of the extension in DNS servers resulted in a fallback method being widely deployed (see <xref section="6.2.2" sectionFormat="of"target="EDNS"target="RFC6891" format="default"/>). This fallback resulted in EDNS being disabled for affected servers. Over time, greater support for EDNS and increased reliance on it for different features motivated a flag day <xref target="DNSFLAGDAY" format="default"/> where the workaround was removed.</t> <t>The EDNS example shows that effort can be used to restore capabilities. This is in part because EDNS was actively used with most resolvers and servers. It was therefore possible to force a change to ensure that extension capabilities would always be available. However, this required an enormous coordination effort. A small number of incompatible servers and the names they serve also became inaccessible to most clients.</t> </section> </section> <section anchor="other" numbered="true" toc="default"> <name>Complementary Techniques</name> <t>The protections to protocol evolution that come from <xref target="use-it" format="default">active use</xref> can be improved through the use of other defensive techniques. The techniques listed here might not prevent ossification on their own, but they can make active use more effective.</t> <section anchor="fewer-extension-points" numbered="true" toc="default"> <name>Fewer Extension Points</name> <t>A successful protocol will include many potential types ofextension.extensions. Designing multiple types of extensionmechanism,mechanisms, each suited to a specific purpose, might leave some extension points less heavily used than others.</t> <t>Disuse of a specialized extension point might render it unusable. In contrast, having a smaller number of extension points with wide applicability could improve the use of those extension points. Use of a shared extension point for any purpose can protect rarer or more specialized uses.</t> <t>Both extensions and core protocol elements use the same extension points in protocols like HTTP <xreftarget="HTTP"target="I-D.ietf-httpbis-semantics" format="default"/> and DIAMETER <xreftarget="DIAMETER"target="RFC6733" format="default"/>; see <xref target="ex-active" format="default"/>.</t> </section> <section anchor="invariants" numbered="true" toc="default"> <name>Invariants</name> <t>Documenting aspects of the protocol that cannot or will not change as extensions or new versions are added can be a useful exercise. <xref section="2.2" sectionFormat="of" target="RFC5704" format="default"/> defines invariants as:</t><ul empty="true"> <li> <t>Invariants<blockquote> <t> Invariants are core properties that are consistent across the network and do not change over extremely longtime-scales.</t> </li> </ul>time-scales. </t> </blockquote> <t>Understanding what aspects of a protocol are invariant can help guide the process of identifying those parts of the protocol that might change. <xreftarget="QUIC-INVARIANTS"target="RFC8999" format="default"/> and <xref section="9.3" sectionFormat="of"target="TLS13"target="RFC8446" format="default"/> are both examples of documented invariants.</t> <t>As a means of protecting extensibility, a declaration of protocol invariants is useful only to the extent that protocol participants are willing to allow new uses for the protocol. A protocol that declares protocol invariants relies on implementations understanding and respecting those invariants. If active use is not possible for all non-invariant parts of the protocol, greasing (<xref target="grease" format="default"/>) might be used to improve the chance that invariants are respected.</t> <t>Protocol invariants need to be clearly and concisely documented. Including examples of aspects of the protocol that are not invariant, such as <xref target="RFC8999" section="A"sectionFormat="of" target="QUIC-INVARIANTS"format="default"/>, can be used to clarify intent.</t> </section> <section anchor="limiting-participation" numbered="true" toc="default"> <name>Limiting Participation</name> <t>Reducing the number of entities that can participate in a protocol or limiting the extent of participation can reduce the number of entities that might affect extensibility. Using TLS or other cryptographic tools can therefore reduce the number of entities that can influence whether new features are usable.</t> <t><xreftarget="PATH-SIGNALS"target="RFC8558" format="default"/> also recommends the use of encryption and integrity protection to limit participation. For example, encryption is used by the QUIC protocol <xreftarget="QUIC"target="RFC9000" format="default"/> to limit the information that is available to middleboxes and integrity protection prevents modification.</t> </section> <section anchor="effective-feedback" numbered="true" toc="default"> <name>Effective Feedback</name> <t>While not a direct means of protecting extensibility mechanisms, feedback systems can be important to discovering problems.</t><t>Visibility<t>The visibility of errors is critical to the success of techniques like grease (see <xref target="grease" format="default"/>). The grease design is most effective if a deployment has a means of detecting and reporting errors. Ignoring errors could allow problems to become entrenched.</t> <t>Feedback on errors is more important during the development and early deployment of a change. It might also be helpful to disable automatic error recovery methods during development.</t> <t>Automated feedback systems are important for automated systems, or where error recovery is also automated. For instance, connection failures with HTTP alternative services <xreftarget="ALT-SVC"target="RFC7838" format="default"/> are not permitted to affect the outcome of transactions. An automated feedback system for capturing failures in alternative services is therefore necessary for failures to be detected.</t> <t>How errors are gathered and reported will depend greatly on the nature of the protocol deployment and the entity that receives the report. For instance, end users, developers, and network operations each have different requirements for how error reports are created, managed, and acted upon.</t> <t>Automated delivery of error reports can be critical for rectifying deployment errors as early as possible,suchas seen in <xreftarget="DMARC"target="RFC7489" format="default"/> and <xreftarget="SMTP-TLS-Reporting"target="RFC8460" format="default"/>.</t> </section> </section> <section anchor="security-considerations" numbered="true" toc="default"> <name>Security Considerations</name> <t>Many of the problems identified in this document are not the result of deliberate actions by anadversary,adversary but more the result of mistakes, decisions made without sufficient context, or simpleneglect. Problemsneglect, i.e., problems therefore not the result of opposition by an adversary. In response, the recommended measures generally assume that other protocol participants will not take deliberate action to prevent protocol evolution.</t> <t>The use of cryptographic techniques to exclude potential participants is the only strong measure that the document recommends. However, authorized protocol peers are most often responsible for the identified problems, which can mean that cryptography is insufficient to exclude them.</t> <t>The ability to design, implement, and deploy new protocol mechanisms can be critical to security. In particular, it is important to be able to replace cryptographic algorithms over time <xreftarget="AGILITY"target="RFC7696" format="default"/>. For example, preparing for the replacement of weak hash algorithms was made more difficult through misuse <xref target="HASH" format="default"/>.</t> </section> <section anchor="iana-considerations" numbered="true" toc="default"> <name>IANA Considerations</name> <t>This documentmakeshas norequest of IANA.</t>IANA actions.</t> </section> </middle> <back> <displayreference target="I-D.ietf-httpbis-semantics" to="HTTP"/> <displayreference target="I-D.ietf-httpbis-messaging" to="HTTP11"/> <displayreference target="RFC5218" to="SUCCESS"/> <displayreference target="RFC8170" to="TRANSITIONS"/> <displayreference target="RFC6709" to="EXTENSIBILITY"/> <displayreference target="RFC7301" to="ALPN"/> <displayreference target="RFC8701" to="GREASE"/> <displayreference target="RFC9000" to="QUIC"/> <displayreference target="RFC5321" to="SMTP"/> <displayreference target="RFC3261" to="SIP"/> <displayreference target="RFC6733" to="DIAMETER"/> <displayreference target="RFC8941" to="HTTP-HEADERS"/> <displayreference target="RFC6891" to="EDNS"/> <displayreference target="RFC8999" to="QUIC-INVARIANTS"/> <displayreference target="RFC8558" to="PATH-SIGNALS"/> <displayreference target="RFC7838" to="ALT-SVC"/> <displayreference target="RFC7489" to="DMARC"/> <displayreference target="RFC8460" to="SMTP-TLS-REPORTING"/> <displayreference target="RFC7696" to="AGILITY"/> <displayreference target="RFC7208" to="SPF"/> <displayreference target="RFC3597" to="RRTYPE"/> <displayreference target="RFC2113" to="RAv4"/> <displayreference target="RFC2711" to="RAv6"/> <displayreference target="RFC1157" to="SNMPv1"/> <displayreference target="RFC0793" to="TCP"/> <displayreference target="RFC8684" to="MPTCP"/> <displayreference target="RFC7413" to="TFO"/> <displayreference target="RFC5246" to="TLS12"/> <displayreference target="RFC8446" to="TLS13"/> <displayreference target="RFC6066" to="TLS-EXT"/> <references> <name>Informative References</name> <reference anchor="HASH" target="https://www.cs.columbia.edu/~smb/papers/new-hash.pdf"> <front> <title>Deploying a New Hash Algorithm</title> <author initials="S." surname="Bellovin" fullname="Steven M. Bellovin"> <organization/> </author> <author initials="E." surname="Rescorla" fullname="Eric M. Rescorla"> <organization/> </author> <date year="2006"/> </front><seriesInfo name="Proceedings<refcontent>Proceedings ofNDSS '06" value=""/>NDSS</refcontent> </reference> <reference anchor="SNI" target="https://mailarchive.ietf.org/arch/msg/tls/1t79gzNItZd71DwwoaqcQQ_4Yxc"> <front><title>Accepting<title>[TLS] Accepting that other SNI name types will neverwork</title>work.</title> <author initials="A." surname="Langley" fullname="Adam Langley"> <organization/> </author> <date year="2016"month="March" day="03"/>month="March"/> </front> </reference> <reference anchor="INTOLERANCE" target="https://mailarchive.ietf.org/arch/msg/tls/bOJ2JQc3HjAHFFWCiNTIb0JuMZc"> <front> <title>Re: [TLS] Thoughts on Version Intolerance</title> <author initials="H." surname="Kario" fullname="Hubert Kario"> <organization/> </author> <date year="2016"month="July" day="20"/>month="July"/> </front> </reference> <reference anchor="DNSFLAGDAY" target="https://dnsflagday.net/2019/"> <front> <title>DNS Flag Day 2019</title> <author> <organization/> </author> <date year="2019" month="May"/> </front> </reference> <reference anchor="MPTCP-HOW-HARD" target="https://www.usenix.org/conference/nsdi12/technical-sessions/presentation/raiciu"> <front> <title>How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP</title> <author initials="C." surname="Raiciu" fullname="Costin Raiciu"> <organization/> </author> <author initials="C." surname="Paasch" fullname="Christoph Paasch"> <organization/> </author> <author initials="S." surname="Barre" fullname="Sebastien Barre"> <organization/> </author> <author initials="A." surname="Ford" fullname="Alan Ford"> <organization/> </author> <author initials="M." surname="Honda" fullname="Michio Honda"> <organization/> </author> <author initials="F." surname="Duchene" fullname="Fabien Duchene"> <organization/> </author> <author initials="O." surname="Bonaventure" fullname="Olivier Bonaventure"> <organization/> </author> <author initials="M." surname="Handley" fullname="Mark Handley"> <organization/> </author> <date year="2012" month="April"/> </front> </reference> <referenceanchor="HTTP">anchor='I-D.ietf-httpbis-semantics'> <front> <title>HTTP Semantics</title> <authorfullname="Roy T. Fielding"> <organization>Adobe</organization>initials='R' surname='Fielding' fullname='Roy Fielding' role="editor"> <organization /> </author> <authorfullname="Mark Nottingham"> <organization>Fastly</organization>initials='M' surname='Nottingham' fullname='Mark Nottingham' role="editor"> <organization /> </author> <authorfullname="Julian Reschke"> <organization>greenbytes GmbH</organization>initials='J' surname='Reschke' fullname='Julian Reschke' role="editor"> <organization /> </author> <dateday="12" month="September" year="2021"/> <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. This document updates RFC 3864 and obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230. </t> </abstract>year='2021' month='September' /> </front> <seriesInfoname="Internet-Draft" value="draft-ietf-httpbis-semantics-19"/>name='Internet-Draft' value='draft-ietf-httpbis-semantics-19'/> </reference> <referenceanchor="HTTP11">anchor='I-D.ietf-httpbis-messaging'> <front> <title>HTTP/1.1</title> <authorfullname="Roy T. Fielding"> <organization>Adobe</organization> </author> <author fullname="Mark Nottingham"> <organization>Fastly</organization> </author> <author fullname="Julian Reschke"> <organization>greenbytes GmbH</organization> </author> <date day="12" month="September" year="2021"/> <abstract> <t> The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns. This document obsoletes portions of RFC 7230. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-messaging-19"/> </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 - 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="SUCCESS"> <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="TRANSITIONS"> <front> <title>Planning for Protocol Adoption and Subsequent Transitions</title> <author fullname="D. Thaler" initials="D." role="editor" surname="Thaler"> <organization/> </author> <date month="May" year="2017"/> <abstract> <t>Over the many years since the introduction of the Internet Protocol, we have seen a number of transitions throughout the protocol stack, such as deploying a new protocol, or updating or replacing an existing protocol. Many protocols and technologies were not designed to enable smooth transition to alternatives or to easily deploy extensions; thus, some transitions, such as the introduction of IPv6, have been difficult. This document attempts to summarize some basic principles to enable future transitions, and it also summarizes what makes for a good transition plan.</t> </abstract> </front> <seriesInfo name="RFC" value="8170"/> <seriesInfo name="DOI" value="10.17487/RFC8170"/> </reference> <reference anchor="EXTENSIBILITY"> <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="RFC2464"> <front> <title>Transmission of IPv6 Packets over Ethernet Networks</title> <author fullname="M. Crawford" initials="M." surname="Crawford"> <organization/> </author> <date month="December" year="1998"/> <abstract> <t>This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an Ethernet. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="2464"/> <seriesInfo name="DOI" value="10.17487/RFC2464"/> </reference> <reference anchor="ALPN"> <front> <title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension</title> <author fullname="S. Friedl" initials="S." surname="Friedl"> <organization/> </author> <author fullname="A. Popov" initials="A." surname="Popov"> <organization/> </author> <author fullname="A. Langley" initials="A." surname="Langley"> <organization/> </author> <author fullname="E. Stephan" initials="E." surname="Stephan"> <organization/> </author> <date month="July" year="2014"/> <abstract> <t>This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.</t> </abstract> </front> <seriesInfo name="RFC" value="7301"/> <seriesInfo name="DOI" value="10.17487/RFC7301"/> </reference>initials='R' surname='Fielding' fullname='Roy Fielding' role="editor"/> <author initials='M' surname='Nottingham' fullname='Mark Nottingham' role="editor"/> <author initials='J' surname='Reschke' fullname='Julian Reschke' role="editor"/> <date year='2021' month='September'/> </front> <seriesInfo name='Internet-Draft' value='draft-ietf-httpbis-messaging-19'/> </reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5704.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5218.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8170.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6709.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2464.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7301.xml"/> <reference anchor="NEW-PROTOCOLS"> <front> <title>On the usability of transport protocols other than TCP: A home gateway and internet path traversal study</title> <author fullname="Runa Barik" initials="R." surname="Barik"> <organization/> </author> <author fullname="Michael Welzl" initials="M." surname="Welzl"> <organization/> </author> <author fullname="Gorry Fairhurst" initials="G." surname="Fairhurst"> <organization/> </author> <author fullname="Ahmed Elmokashfi" initials="A." surname="Elmokashfi"> <organization/> </author> <author fullname="Thomas Dreibholz" initials="T." surname="Dreibholz"> <organization/> </author> <author fullname="Stein Gjessing" initials="S." surname="Gjessing"> <organization/> </author> <date month="May" year="2020"/> </front><seriesInfo name="Computer Networks" value="Vol.<refcontent>Computer Networks, Vol. 173, pp.107211"/>107211</refcontent> <seriesInfo name="DOI" value="10.1016/j.comnet.2020.107211"/> </reference><reference anchor="GREASE"> <front> <title>Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility</title> <author fullname="D. Benjamin" initials="D." surname="Benjamin"> <organization/> </author> <date month="January" year="2020"/> <abstract> <t>This document describes GREASE (Generate Random Extensions And Sustain Extensibility), a mechanism to prevent extensibility failures in the TLS ecosystem. It reserves a set of TLS protocol values that may be advertised to ensure peers correctly handle unknown values.</t> </abstract> </front> <seriesInfo name="RFC" value="8701"/> <seriesInfo name="DOI" value="10.17487/RFC8701"/> </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="SMTP"> <front> <title>Simple Mail Transfer Protocol</title> <author fullname="J. Klensin" initials="J." surname="Klensin"> <organization/> </author> <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="SIP"> <front> <title>SIP: Session Initiation Protocol</title> <author fullname="J. Rosenberg" initials="J." surname="Rosenberg"> <organization/> </author> <author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne"> <organization/> </author> <author fullname="G. Camarillo" initials="G." surname="Camarillo"> <organization/> </author> <author fullname="A. Johnston" initials="A." surname="Johnston"> <organization/> </author> <author fullname="J. Peterson" initials="J." surname="Peterson"> <organization/> </author> <author fullname="R. Sparks" initials="R." surname="Sparks"> <organization/> </author> <author fullname="M. Handley" initials="M." surname="Handley"> <organization/> </author> <author fullname="E. Schooler" initials="E." surname="Schooler"> <organization/> </author> <date month="June" year="2002"/> <abstract> <t>This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="3261"/> <seriesInfo name="DOI" value="10.17487/RFC3261"/> </reference> <reference anchor="DIAMETER"> <front> <title>Diameter Base Protocol</title> <author fullname="V. Fajardo" initials="V." role="editor" surname="Fajardo"> <organization/> </author> <author fullname="J. Arkko" initials="J." surname="Arkko"> <organization/> </author> <author fullname="J. Loughney" initials="J." surname="Loughney"> <organization/> </author> <author fullname="G. Zorn" initials="G." role="editor" surname="Zorn"> <organization/> </author> <date month="October" year="2012"/> <abstract> <t>The Diameter base protocol is intended to provide an Authentication, Authorization, and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting, and security services used by all Diameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and RFC 5719, and it must be supported by all new Diameter implementations. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6733"/> <seriesInfo name="DOI" value="10.17487/RFC6733"/> </reference> <reference anchor="HTTP-HEADERS"> <front> <title>Structured Field Values for HTTP</title> <author fullname="M. Nottingham" initials="M." surname="Nottingham"> <organization/> </author> <author fullname="P-H. Kamp" initials="P-H." surname="Kamp"> <organization/> </author> <date month="February" year="2021"/> <abstract> <t>This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values.</t> </abstract> </front> <seriesInfo name="RFC" value="8941"/> <seriesInfo name="DOI" value="10.17487/RFC8941"/> </reference> <reference anchor="EDNS"> <front> <title>Extension Mechanisms for DNS (EDNS(0))</title> <author fullname="J. Damas" initials="J." surname="Damas"> <organization/> </author> <author fullname="M. Graff" initials="M." surname="Graff"> <organization/> </author> <author fullname="P. Vixie" initials="P." surname="Vixie"> <organization/> </author> <date month="April" year="2013"/> <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 requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow.</t> <t>This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS.</t> </abstract> </front> <seriesInfo name="STD" value="75"/> <seriesInfo name="RFC" value="6891"/> <seriesInfo name="DOI" value="10.17487/RFC6891"/> </reference> <reference anchor="QUIC-INVARIANTS"> <front> <title>Version-Independent Properties of QUIC</title> <author fullname="M. Thomson" initials="M." surname="Thomson"> <organization/> </author> <date month="May" year="2021"/> <abstract> <t>This document defines the properties of the QUIC transport protocol that are common to all versions of the protocol.</t> </abstract> </front> <seriesInfo name="RFC" value="8999"/> <seriesInfo name="DOI" value="10.17487/RFC8999"/> </reference> <reference anchor="PATH-SIGNALS"> <front> <title>Transport Protocol Path Signals</title> <author fullname="T. Hardie" initials="T." role="editor" surname="Hardie"> <organization/> </author> <date month="April" year="2019"/> <abstract> <t>This document discusses the nature of signals seen by on-path elements examining transport protocols, contrasting implicit and explicit signals. For example, TCP's state machine uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. In transports that do not exchange these messages in the clear, on-path network elements lack those signals. Often, the removal of those signals is intended by those moving the messages to confidential channels. Where the endpoints desire that network elements along the path receive these signals, this document recommends explicit signals be used.</t> </abstract> </front> <seriesInfo name="RFC" value="8558"/> <seriesInfo name="DOI" value="10.17487/RFC8558"/> </reference> <reference anchor="ALT-SVC"> <front> <title>HTTP Alternative Services</title> <author fullname="M. Nottingham" initials="M." surname="Nottingham"> <organization/> </author> <author fullname="P. McManus" initials="P." surname="McManus"> <organization/> </author> <author fullname="J. Reschke" initials="J." surname="Reschke"> <organization/> </author> <date month="April" year="2016"/> <abstract> <t>This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.</t> </abstract> </front> <seriesInfo name="RFC" value="7838"/> <seriesInfo name="DOI" value="10.17487/RFC7838"/> </reference> <reference anchor="DMARC"> <front> <title>Domain-based Message Authentication, Reporting, and Conformance (DMARC)</title> <author fullname="M. Kucherawy" initials="M." role="editor" surname="Kucherawy"> <organization/> </author> <author fullname="E. Zwicky" initials="E." role="editor" surname="Zwicky"> <organization/> </author> <date month="March" year="2015"/> <abstract> <t>Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling.</t> <t>Originators of Internet Mail need to be able to associate reliable and authenticated domain identifiers with messages, communicate policies about messages that use those identifiers, and report about mail using those identifiers. These abilities have several benefits: Receivers can provide feedback to Domain Owners about the use of their domains; this feedback can provide valuable insight about the management of internal operations and the presence of external domain name abuse.</t> <t>DMARC does not produce or encourage elevated delivery privilege of authenticated email. DMARC is a mechanism for policy distribution that enables increasingly strict handling of messages that fail authentication checks, ranging from no action, through altered delivery, up to message rejection.</t> </abstract> </front> <seriesInfo name="RFC" value="7489"/> <seriesInfo name="DOI" value="10.17487/RFC7489"/> </reference> <reference anchor="SMTP-TLS-Reporting"> <front> <title>SMTP TLS Reporting</title> <author fullname="D. Margolis" initials="D." surname="Margolis"> <organization/> </author> <author fullname="A. Brotman" initials="A." surname="Brotman"> <organization/> </author> <author fullname="B. Ramakrishnan" initials="B." surname="Ramakrishnan"> <organization/> </author> <author fullname="J. Jones" initials="J." surname="Jones"> <organization/> </author> <author fullname="M. Risher" initials="M." surname="Risher"> <organization/> </author> <date month="September" year="2018"/> <abstract> <t>A number of protocols exist for establishing encrypted channels between SMTP Mail Transfer Agents (MTAs), including STARTTLS, DNS- Based Authentication of Named Entities (DANE) TLSA, and MTA Strict Transport Security (MTA-STS). These protocols can fail due to misconfiguration or active attack, leading to undelivered messages or delivery over unencrypted or unauthenticated channels. This document describes a reporting mechanism and format by which sending systems can share statistics and specific information about potential failures with recipient domains. Recipient domains can then use this information to both detect potential attacks and diagnose unintentional misconfigurations.</t> </abstract> </front> <seriesInfo name="RFC" value="8460"/> <seriesInfo name="DOI" value="10.17487/RFC8460"/> </reference> <reference anchor="AGILITY"> <front> <title>Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms</title> <author fullname="R. Housley" initials="R." surname="Housley"> <organization/> </author> <date month="November" year="2015"/> <abstract> <t>Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature. Communicating peers must support a common set of cryptographic algorithms for these mechanisms to work properly. This memo provides guidelines to ensure that protocols have the ability to migrate from one mandatory-to-implement algorithm suite to another over time.</t> </abstract> </front> <seriesInfo name="BCP" value="201"/> <seriesInfo name="RFC" value="7696"/> <seriesInfo name="DOI" value="10.17487/RFC7696"/> </reference> <reference anchor="SPF"> <front> <title>Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1</title> <author fullname="S. Kitterman" initials="S." surname="Kitterman"> <organization/> </author> <date month="April" year="2014"/> <abstract> <t>Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization.</t> <t>This document obsoletes RFC 4408.</t> </abstract> </front> <seriesInfo name="RFC" value="7208"/> <seriesInfo name="DOI" value="10.17487/RFC7208"/> </reference> <reference anchor="RRTYPE"> <front> <title>Handling of Unknown DNS Resource Record (RR) Types</title> <author fullname="A. Gustafsson" initials="A." surname="Gustafsson"> <organization/> </author> <date month="September" year="2003"/> <abstract> <t>Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="3597"/> <seriesInfo name="DOI" value="10.17487/RFC3597"/> </reference> <reference anchor="RFC0988"> <front> <title>Host extensions for IP multicasting</title> <author fullname="S.E. Deering" initials="S.E." surname="Deering"> <organization/> </author> <date month="July" year="1986"/> <abstract> <t>This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support internetwork multicasting. This specification supersedes that given in RFC-966, and constitutes a proposed protocol standard for IP multicasting in the ARPA-Internet. The reader is directed to RFC-966 for a discussion of the motivation and rationale behind the multicasting extension specified here.</t> </abstract> </front> <seriesInfo name="RFC" value="988"/> <seriesInfo name="DOI" value="10.17487/RFC0988"/> </reference> <reference anchor="RFC0791"> <front> <title>Internet Protocol</title> <author fullname="J. Postel" initials="J." surname="Postel"> <organization/> </author> <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="RAv4"> <front> <title>IP Router Alert Option</title> <author fullname="D. Katz" initials="D." surname="Katz"> <organization/> </author> <date month="February" year="1997"/> <abstract> <t>This memo describes a new IP Option type that alerts transit routers to more closely examine the contents of an IP packet. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="2113"/> <seriesInfo name="DOI" value="10.17487/RFC2113"/> </reference> <reference anchor="RAv6"> <front> <title>IPv6 Router Alert Option</title> <author fullname="C. Partridge" initials="C." surname="Partridge"> <organization/> </author> <author fullname="A. Jackson" initials="A." surname="Jackson"> <organization/> </author> <date month="October" year="1999"/> <abstract> <t>This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="2711"/> <seriesInfo name="DOI" value="10.17487/RFC2711"/> </reference> <reference anchor="SNMPv1"> <front> <title>Simple Network Management Protocol (SNMP)</title> <author fullname="J.D. Case" initials="J.D." surname="Case"> <organization/> </author> <author fullname="M. Fedor" initials="M." surname="Fedor"> <organization/> </author> <author fullname="M.L. Schoffstall" initials="M.L." surname="Schoffstall"> <organization/> </author> <author fullname="J. Davin" initials="J." surname="Davin"> <organization/> </author> <date month="May" year="1990"/> <abstract> <t>This RFC is a re-release of RFC 1098, with a changed "Status of this Memo" section plus a few minor typographical corrections. This memo defines a simple protocol by which management information for a network element may be inspected or altered by logically remote users. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="1157"/> <seriesInfo name="DOI" value="10.17487/RFC1157"/> </reference> <reference anchor="TCP"> <front> <title>Transmission Control Protocol</title> <author fullname="J. Postel" initials="J." surname="Postel"> <organization/> </author> <date month="September" year="1981"/> </front> <seriesInfo name="STD" value="7"/> <seriesInfo name="RFC" value="793"/> <seriesInfo name="DOI" value="10.17487/RFC0793"/> </reference><xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8701.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5321.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6733.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8941.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6891.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8999.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8558.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7838.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7489.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8460.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7696.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7208.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3597.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1112.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2113.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2711.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1157.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0793.xml"/> <reference anchor="EXT-TCP"> <front> <title>Is it still possible to extend TCP?</title> <author fullname="Michio Honda" initials="M." surname="Honda"> <organization/> </author> <author fullname="Yoshifumi Nishida" initials="Y." surname="Nishida"> <organization/> </author> <author fullname="Costin Raiciu" initials="C." surname="Raiciu"> <organization/> </author> <author fullname="Adam Greenhalgh" initials="A." surname="Greenhalgh"> <organization/> </author> <author fullname="Mark Handley" initials="M." surname="Handley"> <organization/> </author> <author fullname="Hideyuki Tokuda" initials="H." surname="Tokuda"> <organization/> </author> <date month="November" year="2011"/> </front><seriesInfo name="Proceedings<refcontent>IMC '11: Proceedings of the 2011 ACM SIGCOMM conference on Internet measurementconference - IMC" value="'11"/>conference</refcontent> <seriesInfo name="DOI" value="10.1145/2068816.2068834"/> </reference><reference anchor="MPTCP"> <front> <title>TCP Extensions for Multipath Operation with Multiple Addresses</title> <author fullname="A. Ford" initials="A." surname="Ford"> <organization/> </author> <author fullname="C. Raiciu" initials="C." surname="Raiciu"> <organization/> </author> <author fullname="M. Handley" initials="M." surname="Handley"> <organization/> </author> <author fullname="O. Bonaventure" initials="O." surname="Bonaventure"> <organization/> </author> <date month="January" year="2013"/> <abstract> <t>TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure.</t> <t>Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document defines an Experimental Protocol for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="6824"/> <seriesInfo name="DOI" value="10.17487/RFC6824"/> </reference> <reference anchor="TFO"> <front> <title>TCP Fast Open</title> <author fullname="Y. Cheng" initials="Y." surname="Cheng"> <organization/> </author> <author fullname="J. Chu" initials="J." surname="Chu"> <organization/> </author> <author fullname="S. Radhakrishnan" initials="S." surname="Radhakrishnan"> <organization/> </author> <author fullname="A. Jain" initials="A." surname="Jain"> <organization/> </author> <date month="December" year="2014"/> <abstract> <t>This document describes an experimental TCP mechanism called TCP Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, and saves up to one full round-trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However, TFO deviates from the standard TCP semantics, since the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue, as detailed in the Applicability section.</t> </abstract> </front> <seriesInfo name="RFC" value="7413"/> <seriesInfo name="DOI" value="10.17487/RFC7413"/> </reference> <reference anchor="TLS12"> <front> <title>The Transport Layer Security (TLS) Protocol Version 1.2</title> <author fullname="T. Dierks" initials="T." surname="Dierks"> <organization/> </author> <author fullname="E. Rescorla" initials="E." surname="Rescorla"> <organization/> </author> <date month="August" year="2008"/> <abstract> <t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5246"/> <seriesInfo name="DOI" value="10.17487/RFC5246"/> </reference> <reference anchor="TLS13"> <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="TLS-EXT"> <front> <title>Transport Layer Security (TLS) Extensions: Extension Definitions</title> <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"> <organization/> </author> <date month="January" year="2011"/> <abstract> <t>This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6066"/> <seriesInfo name="DOI" value="10.17487/RFC6066"/> </reference><xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8684.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7413.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6066.xml"/> </references> <section anchor="examples" numbered="true" toc="default"> <name>Examples</name> <t>This appendix contains a brief study of problems in a range of Internet protocols at different layers of the stack.</t> <section anchor="dns" numbered="true" toc="default"> <name>DNS</name> <t>Ossified DNS code bases and systems resulted in new Resource Record Codes (RRCodes) being unusable. A newcodepointcode point would take years of coordination between implementations and deployments before it could be relied upon. Consequently,overloadinguse of the TXT record wasusedoverloaded in order to avoid the effort and delaysinvolved, a methodinvolved in allocating new code points; this approach was used in the Sender Policy Framework <xreftarget="SPF"target="RFC7208" format="default"/> and otherprotocols.</t>protocols. </t> <t>It was not until after the standard mechanism for dealing with new RRCodes <xreftarget="RRTYPE"target="RFC3597" format="default"/> was considered widely deployed that new RRCodescancould be safely created and used.</t> </section> <sectionanchor="http"anchor="HTTP" numbered="true" toc="default"> <name>HTTP</name> <t>HTTP has a number of very effective extension points in addition to the aforementioned header fields. It also has some examples of extension points that are so rarely used that it is possible that they are not at all usable.</t> <t>Extension points in HTTP that might be unwise to use include the extension point on each chunk in the chunked transfer coding<xref(<xref section="7.1" sectionFormat="of"target="HTTP11" format="default"/>,target="I-D.ietf-httpbis-messaging" format="default"/>), the ability to use transfer codings other than the chunked coding, and the range unit in a range request<xref(<xref section="14" sectionFormat="of"target="HTTP" format="default"/>.</t>target="I-D.ietf-httpbis-semantics" format="default"/>).</t> </section> <section anchor="ip" numbered="true" toc="default"> <name>IP</name> <t>The version field in IP was rendered useless when encapsulated over Ethernet,requringrequiring a newethertypeEtherType with IPv6 <xref target="RFC2464" format="default"/>, due in part tolayerLayer 2 devices making version-independent assumptions about the structure of the IPv4 header.</t> <t>Protocol identifiers orcodepointscode points that are reserved for future use can be especially problematic. Reserving values without attributing semantics to their use can result in diverse or conflicting semantics being attributed without any hope of interoperability. An example of this is the 224/3"class E"address space in IPv4 that <xreftarget="RFC0988" format="default"/>. This space was originallytarget="RFC0791"/> reservedin <xref target="RFC0791" format="default"/>without assigning anysemantics and has since beensemantics. <xref target="RFC1112"/> partially reclaimed that reserved address space for use in multicast (224/4), butotherwisethe remaining address space (240/4) has not been successfully reclaimed for anypurpose (240/4) <xref target="RFC0988" format="default"/>.</t>purpose. </t> <t>For protocols that can use negotiation to attribute semantics to values, it is possible that unusedcodepointscode points can be reclaimed for active use, though this requires that the negotiation include all protocol participants. For something as fundamental as addressing, negotiation is difficult or even impossible, as all nodes on the network path plus potential alternative paths would need to be involved.</t> <t>IP Router Alerts <xreftarget="RAv4"target="RFC2113" format="default"/><xreftarget="RAv6"target="RFC2711" format="default"/> use IP options or extension headers to indicate that data is intended for consumption by thenext hopnext-hop router rather than the addressed destination. In part, the deployment of router alerts was unsuccessful due to the realities of processing IP packets at line rates, combined with bad assumptions in the protocol design about these performance constraints. However, this was not exclusively down to design problems orbugsbugs, as the capability was also deliberately blocked at some routers.</t> </section> <section anchor="snmp" numbered="true" toc="default"> <name>SNMP</name> <t>As a counter example, the first version of the Simple Network Management Protocol (SNMP) <xreftarget="SNMPv1"target="RFC1157" format="default"/>definesstates that unparseable or unauthenticated messages are simply discarded without response:</t><ul empty="true"> <li><blockquote> <t>It then verifies the version number of the SNMP message. If there is a mismatch, it discards the datagram and performs no further actions.</t></li> </ul></blockquote> <t>When SNMP versions 2,2c2c, and 3 came along, older agents did exactly what the protocol specifies. Deployment of new versions was likely successful because the handling of newer versions was both clear and simple.</t> </section> <section anchor="tcp" numbered="true" toc="default"> <name>TCP</name> <t>Extension points in TCP <xreftarget="TCP"target="RFC0793" format="default"/> have been rendered difficult touse,use largely due to middlebox interactions; see <xref target="EXT-TCP" format="default"/>.</t><t>For<t> For instance, multipath TCP<xref target="MPTCP" format="default"/>(<xref target="RFC8684" format="default"/>) can only be deployed opportunistically; see <xref target="MPTCP-HOW-HARD" format="default"/>.As multipath TCP enables progressiveSince MPTCP is a protocol enhancementof the protocol, this largely only causesthat doesn’t impair thefeature to not be availableconnection ifthe pathit isintolerantblocked, network path intolerance of theextension.</t>extension only results in the multipath functionality becoming unavailable. </t> <t>In comparison, the deployment of TCP Fast Open<xref target="TFO" format="default"/>(<xref target="RFC7413" format="default"/>) critically depends on extension capability being widely available. Though very few network paths were intolerant of the extension in absolute terms, TCP Fast Open could not be deployed as a result.</t> </section> <section anchor="tls" numbered="true" toc="default"> <name>TLS</name> <t>Transport Layer Security (TLS) <xreftarget="TLS12"target="RFC5246" format="default"/> provides examples of where a design that is objectively sound fails when incorrectly implemented. TLS provides examples of failures in protocol version negotiation and extensibility.</t> <t>Version negotiation in TLS 1.2 and earlier uses the "Highest mutually supported version (HMSV)" scheme exactly as it is described in <xreftarget="EXTENSIBILITY"target="RFC6709" format="default"/>. However, clients are unable to advertise a new version without causing a non-trivial proportion of sessions to fail due to bugs in server and middlebox implementations.</t> <t>Intolerance to new TLS versions is so severe <xref target="INTOLERANCE" format="default"/> that TLS 1.3 <xreftarget="TLS13"target="RFC8446" format="default"/> abandoned HMSV version negotiation for a new mechanism.</t> <t>The server name indication (SNI) <xreftarget="TLS-EXT"target="RFC6066" format="default"/> in TLS is another excellent example of the failure of a well-designed extensibility point. SNI uses the same technique forextensionextensions that is used successfully in other parts of the TLS protocol. The original design of SNI anticipated the ability to include multiple names of different types.</t> <t>SNI was originally defined with just one type of name: a domain name. No other type has ever been standardized, though several have been proposed. Despite an otherwise exemplary design, SNI is so inconsistently implemented that any hope for using the extension point it defines has been abandoned <xref target="SNI" format="default"/>.</t> </section> </section> <section numbered="false"> <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> <ul empty="true" spacing="compact" bare="false"> <li > <t><contact fullname="Jari Arkko"/></t> </li> <li > <t><contact fullname="Deborah Brungard"/></t> </li> <li> <t><contact fullname="Ben Campbell"/></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="Mirja Kühlewind"/></t> </li> <li > <t><contact fullname="Zhenbin Li"/></t> </li> <li> <t><contact fullname="Jared Mauch"/></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="Jiankang Yao"/></t> </li> </ul> </section> <section numbered="false" anchor="acknowledgments" toc="default"> <name>Acknowledgments</name><t>Toerless Eckert, Wes Hardaker, Mirja Kuehlewind, Eliot Lear, Mark Nottingham,<t><contact fullname="Toerless Eckert"/>, <contact fullname="Wes Hardaker"/>, <contact fullname="Mirja Kühlewind"/>, <contact fullname="Eliot Lear"/>, <contact fullname="Mark Nottingham"/>, andBrian Trammell<contact fullname="Brian Trammell"/> made significant contributions to this document.</t> </section> </back><!-- ##markdown-source: H4sIAO5JZmEAA519W3PcyJHue/0KhPSw0kZ38yINddnweimJGtErUTRJzazX 4XBUA9VsWGigDaBJtRk6v+y8nT928svMugDdGm+sYzxDsoG6ZOXly1v1dDo1 fdlX7nX26GNT3057166yX0o7L6uy32bNIrtsm77Jmyo7+9a7uiubOvvk8qWt y27VPTJ2Pm/d3evsS+ey8z773GYfG/7RFE1e2xWNXLR20U9pzOmmc9Oynzbt tGrkx8PnJre9u23a7eusrBeNKdft66xvN11/fHj46vDYmK63dfFXWzU1DbZ1 nVmXr7M/06ImWde0fesWHf20XckPNO3KrtdlffsXY+ymXzbta5NlU/p/RjN0 r7NPs+xm2ay6pua/ySI/2bYv68EHTXtLf2/+UVaV5T+4lS2r19mq/4+quXd1 3zbr7ax2/XD4m1l2aTfVNhn8plmttslfeeTT9bpy6bj9Gg/8h8XfZ3mzMqZu 2pXtyzv32hgD6oRfs+zD6fWH1/y6P8B3bl01W9p4ZrMLd599sN0yO62ItmW/ XD3iZyNB8L+p/ldXfj3L3riqau7KOnwgG7ju3Z2rQbnRA6MRzmbZlevyplWK xRHO2jLH+4OPCzr61xmd84lsxLa3rqedLPt+3b0+OLi/v5/lHdGi2qzmpZ25 YnPwf7rV/GBt167tDmp3P13SLmfrYiH761xbug6komGIdXPnCqJIB06+eHd9 nf3L4ckjQ49eX5wPqXea527dg3r90vZZ0y9di6d4/Vm/XbsuuydWyGoiRZvd N+3X/wFJT2fZR1vfVm47osdpYVeDjzwtjk6mh8/on/0UAafYNl8SE8xK1y9m xEoH+MPBqrs96Kvu4Kh/8er2Hxfn/X8XL47e3d839u/5H//41+d/+pbzxs8v bj5/PLs6vXh7NiTAFf3rzzcfr/8CIdjcLnsiWp39QnSGzJ/XfVO51ta5+x9s +8Ms+0/bls1o0x82c9f2yUfppl9Mjw//t5uef/7D8R/+mD/78LfTD+/f//q2 vLg5nx/+YfPpv2XT7y6u3388/fnd6Z9GInNxnb2v7G32zm6xjFePhst6NT38 abAmv6Si7hb0XmFZARzg0QNM9Ony5u3l9MPnX6cfTq/eDSf70EAm2yJ7a2vo yjfu99k7YtbbmmW2LrLzFYn+ijSLCLEItJ1XLvu0qfpybftlRuM/+rG0kIat y29MoLypF651dGAHdVeUR8cHPentusxtNe1ch1PtDtatozd60ipNfdDaMi83 IxIcQ0fvOXA90rdNB715xa+OP1u2Zdc36yWpPtvly9HH125u6WXSK29s27rR p6cVUel90xajv38qiRGa7ENTF3b00XsyWzTau02+dPV4vM9VeVeS4L5paku6 rN/szEgm4CsdUF1AJKFhb24uX2fn03fMdFOQeV52RLuVpRPKO33k6GjPQysi sL2lY6SHrt6//enF4XPocDOdTjM77/rW5r0xN0uXeVPbNxms6q3L1mpxu6xw a1cXLIfum2vzshP95OhXb4zBN3cipKYmQ9qXfJjZKhhpUWjdZr0ma6mTzDKS 8rKDtdyA4WhA4jVihmxJXNq62w1JnCFuguIkNRsWlS2cBe26LKfzoTXQzzJB 2dN7JKp1l60bYi+wLW2qYCY2Mm2Hv9gw2IxAhQXPd5mlYW5LGJl7Urwuq2z+ FXNjCbmlfxdZMsTcmRWtNivKxaLMSTbIpGY5sWK1nSmVV2VBB2nMY6iutik2 OchizClRglR91y02VdzVw8Pvr7+8fXt2ff07HNfx0cvv32nfruiSgyE+v7db paclO3hPmzb4vIHIbni/NOwCZgKnxO/hyGQk2k5JWpU203Z0ALDRsj0Sx4mh QYoSa+z4TOlXsElZix7GcEJKPi4aKpKRj4IkvSD2jn81vMyiIYrVjT/3rJl3 pMd7R2T6QhxK3GZ7An06aev+vilbVkFdRnAjnaRblguaGMavL1fgoHPM2q1p oW5iSq+7rOxhVZIJyWzxN0JytM3BVPcESErZ02CbC/zJ+Bkn/EDcZLOpCjp5 4f3CFZOMF9gSVWzOU8eHZXZik4KsddWsXUHrPfu2BjwgjcgrAGPQclw/7Ugn JjMldO5IHPTAnSUN1qxZuAidOdkGsyDUbM/8h3MlXroh+3p9fnP++YL56eXR i0PiJ0fMXtbgYNklScgKmw4TuztCOiK94O5529iCOfq0TiR+3RC1MhJeG4U8 4ckuPTSWFT37guhlXL2EDS/2KIC4uKxbu7wkycoSphR2cvAQ6DmIKSCSiSTH IdL/ibmzJalYHijRbgWbOmYzITDrFTrCVUM0LF1houK7Ky1eL1u/Elr8iABC 6RHXEZGXdPIVTr8zHZ0S/U4mqIXV4y2ysiGaB81BcBGCTTxIg+tOm4HKM17l 8Yziw9BEZH43TskCfceLjFuAQhvpqL4xmzUMqxKhy9tyrip3j1IiGbJfXbaA UOKEojY2gRZeVxRumlCFwSstsdn0FZ9pB8xKFLCFnCb9CKkjx4u2L4pC5bUs QA3W6wELRxFUDSx6Pqr5qBTEprkoaGIa2HUBrVKOo58JfhQNsRMZ1Gqb0ZOP cHyufUT6fwtGahYGbERCCsBNiyazMMEKI5FYCqtyVfZE/5ocBXmPtA15dDmB JqGKgFrT0YNk2mjybqNmRzEQRiXLvk2GlrOlvfCZkTaAnmC1ZIh6hWsWCzAP Se0dzc0LgffGPhgzn2g0OtxbIhvWJxDs7xu1n3PhEdL9YMxvECpWi7Qq5h9e TrKPCfiEJumwmpQwTC4IE3lmLR07r2BLU646GMTHgJauXbi8jyBTFfVHkC5x 84MOeng8li5jCLbquokFYSjo2FIG96Jtvb0Z2PusXOzYCaba/ZJQnW7oPtW/ wQSX0NX+KIoGJs34X8FFZd4TUN7SQf9C3oVAIDpQiBaGhISIgIBIqfgQmZeM +QqjO8MyiCUYVSyy+eaWFcRw3RjFK0nZyCz7UoeFsNLj8egIywWdPZ/ZvN2s iUqsQXWYReax+CRzbdu09N+8JZ+WIAH0dVF2xFLOsufFfE22T3cC0YfU0Xl3 KnkEuBk2RXKpAlZzI2wHfbdpa9EvJcunsx6xGT3CnFw1m0ial34Y/oWekfgp AwIP6GswAxY6Jh9pYaiRqmTvhuSsFo8bVAAILBcEeoi3aP4WR6QYqWStsSD5 5QGq8isYUHTMDl9V0HfNuo9QDPopjZLs5VHBGYqEdoYFwiu/ZdZ0mzkCUwS3 WWMDW+uBYjrmGl5XnBxqselc500vnYRR5UHzRylaI2zRdV515tWmgI0q4Bcu tt4DYFCs+pF+8LyzKOvCP6LgjM91uI8n3VNis4a8K2ZEEMPQkmVrjAMrYgiS LHLCJgxvyV/BY4xd8cgBHTPmEBmkX4BIF1AwJEj00F2Zg4Mx2L0t+d2FvoJJ BJcIExEYMeZnxv7s2iwW8FOCWiUWoDcwgOfhibpAZNnZxgjNabkIB7LNYPKD 00k0WjZsJJrw+vbgaFbUEt9JsZhy+8Q4lnOCVlveQbQOskIsbMXeOSAkdLVj HSOArBWES4fXQsG0RAkgERI4kvG+JacE/tMTN7udTbLzy0n25mf617uLawa3 Nx+vn0LcemVKFg0CtbUDg9hWvEasf7NW8zN01hRz8Vro6DrlM8GrKwJwTQGJ J2RbOkVsHcJdov5Yp6QWm0WSMAR93LEFw7/FXxupVHgcBYn3nDV0tTXzqsm/ Muy8xnrjETCxxlLGVpTwRUWGz2MseKj0KwEFAMVlOS/lNBUWbeqvdXNP0Nyu ReeVUdLon+QUiez8xmJTs0+oAKhz7ivoyUqxczkBINKbtxuo3t6BmaFuiBdb d0/jeI3buX6kcIkPgpNMzJuaP7BYr3wOBaLvElYNb/BaGD8zY97ZSvxKOqsu EWMfMop6OHWWZjDUpTh+tlKnVbSoTLDYMOPpqamNKAUJCzF6xg2Ps58b4pGA DiRehScvaOjzvnPVIrveQHWV4JCHxzTl9JbemboagEswQ9g4g+Yi0YzELMC8 yqhDt3bs8pA51EhHlkY6wonzDoKMMc0YPgNjhhgFRHUlPNlAEnCO5KJlJy8O X8F1O/uvmzPy3d6cfzy/+ROcN3xAWJqVIIIbNrttHbtCNAkt+N5V1TQRcltA 98FnL0Jwb5EaRZHooNh5kQ08Nz5Tfvu1Mf8urLtyVn2viSpN4nei2CQllFJl ujf+YzJ4seo7d8xAmZxNoInED2xHjgFhKDxnCR6v/EFZCWfQQIH9FGOLOm+7 fmctAKiwIT0QkIXzCRDnX9fhfnPdRPG2JXvCDvBNwMRWMX6qrCVW4UFkCf8T vkXDJoWJRgcXmZQw8hoBOCI0awiYjjgUy14Z4PJYNQVjEwNsM/NpFGyjhdb/ wiq34EWzpay9dC9sSe5y0/UiFLIGVryGDIi9be16SXxLTBsYk9we0m4EUm+V Y0bWj30pto4Twh4x7CM8nsGPAFovtspZpKFZ3wxM3m8eB2tR4cM5YX5HQINd yQmdIy2I/tRgy7ek0u5JEjoyuBZAwlZT8lAquD6dQAhSXlX2r5a23v6rgCWb HAANh9ObO1cHfKChKDpguF9Qe4ijYQ04UDYRfGpzx8bQ3TFYIrY5rwuHQBHN UOa7oBjqIghu1ByEtgV67oAFk8Yus1OW8DYJc6okse8AN5oHWpD55BgeYlXF Jsd+RNsTUCJyCt962Onfpd0RpgPBxp7HItunBYkqMSyQMqfaQBJG8aTG3EtU Y3DFbibCvqQZPZLDUafMpTbhXdnB6iKP8YGIB/MgzsXD44I/+p5KLHuxaexl HMkZ+vPRADIPuJLDTOIhQ20TA0GuJgKyECPCWu6JZ7qGgZWGS7yN2Spp6yar GoJ0LRAUXA/a3mbd1BK0FSgw0DkPD37RpP6Duh4GkZgObOSjVgL7wy32zOvD jDG+RYOfxVD3Djl48wFTEgIoC8EBhEFKjSgIcljDlewBueXz3XCvj8xMNKxA Z0liCNdIfEWmEjCjDqDgzUi2T1mAlc0uK6ormKxHB9HIceAosyhdVWTeZWgR qEYw3Xv9nQvTs6/LOCBGFn1agdwABDHvOMyNs8T+y6aYCFTaH4HGZsKpqquv MFmwFcdcxLEsNVPAOPU922w+7N3oNi2QwDkitF91hISGPupDxp/F/K/WJ+G7 RETv+TjijCJanOibXhLptsI4No85gU+c05g33xxEbRV/I3n7XIdw01fw/JKs tuNoXVknKBHLjOi0i5E+CBhtTkMX4kyATXJy7lQoQwQ+9c0GsDPLzrwbB/tG TjLMaKnAW8FHFHX20BgXej+YI6ZxTkaa5YoMVymQjfgDtrVX8B1h444QxeSN ang6Jljm3DNHIJ4RRuk5GBJTGuOwAAvUBHEcID78V71VoARB5zq4EUKxGGvq RtzkJEAQkbpGJNQXWuyBv3T4VdfwjgYbwjhEUqQSdVQfoEXCkMws+6Jzt23q GJkexBOZqxJSzMzlONaLM7J+k9DJtK1S/f01PDIvEa0POPrEE+BAUarglcrL 4qamFIgxTZajJIGlOkzzAx4powaGlREUsO0t+5l3bMFxYnW6LIl9nuYomuES pYfHGr8f809y0glYV5wAKnH4YGOrNN9kxv4CGYqggYPnOE6EaCrXKdNISolI n3iTQ2/Q1eJUqs8WArSeIVgiU/dTxNIIMt/xrYPXGFhuJMPnY8BhfpRMjmuB s5lGJdLMMBthUeLG3qGYg7dDZK4lBaqBIknVbBn/IfFWC/ZocvLFIQMMmd03 MsQdnSdpg37Zsh9j5YCj60BjzqAS4cwQYNiTNk/DBKPzL4XTdKWhEA5bMYmv CRephaV49AXjP8rEvnqcINFh6NzJwGvnrZqokAcLYXK1QA+qN/YsGDHuywFa MuxQENEBRpKkoCZIYzKQ0xkgCmKqQFISEkpeYM1lgBUFKiIxFKgqQHFT+7gt APY4PMob4AQEJuicG4ML1vA+cNtEwGXUNMfHaZ+f8HBAdF4lcWiXaAoHj6nE w5VLRCqYHnQIMqzYe1YWQByhhAlnTOAtb0RvSMiTmAg5PHXHFCtyjFbfG8sS j6Iob6JGb5DwE1QRd0kEG55cQipbFLz3Pak9b9L01CS5Sm/SERhk9DhsEBJ7 8DMnabzLJ5USYkhNh7oRHeeFh/E7NnHs5AWCRJcP7ycagSszaaMmdbL/zW9+ 6bykjKmH7ankagyPFeKOsgk5507xfiqZRNJfBZvUBFH7DXmZ2aM46iO2X1JH I3GbRLbqu7Jt6pXm/gSNJrAzOV0lgXJizvrAc+NA7XV24aD4C4ak6VZ8RULW oW7EB2DIYPVcDKQp5DxkrmwtJYjBGkadPRFPWOWRFCIySHes9iWJ4t003jav l/byxqH6AhE6MhvRBCLxg/zUveUNpFYLcCkpqQh6oOwksiG8zfFSmJuUvRBU SgJxXCokaauIP8SjqIc5ZnVXTYx77eJ6VJR4JTlvFE4MAiJJAirhU6TLmIF8 vQ5JLVlzx26O+7a2omnTbHbqBIiEc2GXxyFY/vWnm0tOZQnuWpLupPfZ4xFP SCM9Eub1MeeJWgpvmfghCVMontnGALXGGtKsBWZFgpEjvHcNp+39eLvpNnoh XVfQBFLE45WHYZVfan5Fi8Bg6pIcLfTGcItQF6opmMRgDSPmPwhwRBtemdPp 0WE1G+CW0YARM0ieN9uS7/yEkardSvntU7JC9AZXhoM4egqjXbPHu4BKDs4A QptQm/gRnONzbXtWgFhxmES4h7Bi03rc5h8C4DO0TA43CWIhWRoa/dSWK3wY iBN2uXLM0yuaSP1uk5bi8JYmqlXzdgPlHmLcyigqfDZNAHnSz8y1RIF3ucPD h+gmDwK1KT4I8UtEr+55vL9vyvwrR405+JZ4aG9twIYIa3eK0JlbOcAcKkzm m7IS1lVdLUq2ZsWxK8scxYjx3Ag392G2lNKi+GHaDWzKTvwiVLQwMsLB2LZt 7qttrFNTLk95umjM/pDLDyMSCTDSYgV2oCTqTjZIpuUoCa1z3boox+zFlrHG Ukpbuh+FPzjYQ9Zd8mWSJRZEoGUvvnBluBq1IL76+yIGGo05ZX4V7//hYZzv +T4Zx/KA0xAl3BO13DWQII4KKXM3TJMwnbhEGj62KYAB9kgsNSIhJErcKQEM GiurfAnampZkSZmFQLNi57T6kI6ocvk4Bg5G7RlJcgiKjmgqpTdpxZ28ORgt 5PxFBLl21O6N4yYlfVBXNWnWnpMBZoyVdiKH8HWGoKFTE0bIrAfunXBMZ03I seyWrkgQ4CI7v/Q5rnRlEtW03vnetAYVWtm87EcJINWg820PlvxApKExJmGg SE3vjdGhiTFiHO8d2U0dz2uWfQnJusnwHFNTeH55d2JY6s6w+ZpEmfzyq/dv j5+fPCePXEs5ikHymx+92a6dJFpojOceeoSqkOYr9BahIRh83aytkNfYTguY 6M5pZSt9GAaE48mHkEaK2Sx0/bbiZ5UP1VfkTiBV8NOPzE3eSzCJ4GVPaFen Hy8vkJR88ezw6Pv3p6yKUITORycFU4MXrpXoR8dw4/EkveXz+qEYLYEvUpPr a3nU4+usKJohK+HR88soMMorNLBk4v2BhjIfBWDeJkMNbsqe7TFt7eLs1+nl 1eebz28/f7z+3bvP57OjQ/rn6OTgb+iGomOdHR8e408vjo9o86qi3tuq07KY QZwHYJ8TEY9+5p8ecYqgacvbsma3yGOWhRRagGd+vjo7vT7jit0XoK/k0ryW MFxNJBHxkZjFGNYfv5y/xVD4LwZ6dXh4SGvNMlmFL+NB2WVa4m6lSApFidmT XchNPg064jjM0C03vRw8lx2RoTLQ5C1XoiQB+MSjiymVGtpJ+hc0/E3+B6lC jj8nETFW7UoPZD9oeSXywZq2D5w80FxNpylPNNJ9vJ4YyW/AOwzoX3LuJIpq cTX65XlDCZuTL99pxA+vK9YyPAUZLh6DBXeIxTQu1QkmDJPG+hfhCvKk66JZ hRKAsIopPbVh7uCydUw9lXnCgoXWrohBipskgWG4j8H7UIWUEt9xzgnWnUjr JCnKiX0OByFrRcp07RCijg1mOC4jRV5wy1y98SEVNi5NndQ96VKM4XgJPYti X+hM3i67Weqy0VBMPXHKUHLbu9W6H4QlI+DSuAPwQbPpYztDIKyPBk/03Dhk z3CMDF0rNf8x2sz+heaVfPE3QY5twriD+LfAGV9os25JX3JGjI9TT1JrQFl3 lT77voNwhT8gKLeS4dRaPCaIrxzSJXCuNCku9PFVHwPSEmx92gdXtpq6CnX1 2rpToUsrxhwY4a3jmoARQryIIeuP3Ib9pREsmR2c+C1HceDM6zEMBuIwEiow tIqQ5W1BWAYpy02/w9XmKqgUkRWc1QacWXPFL2HhknRjeEGL+4BLN+2a4SgO g/sIUWG22LTMIBx0E87QAFXWIyojHor5VTktLCcwcCzgnew5XwR5uJUmiZYx ZurWFmWzzPtSvVfegftYPyJ7yGNU/HK5UC2OLd9qRKHb5yLHOltUF966NibQ Oa7hIzhEsXtba3RBJ5sImaTW2DCnSQ4J3Y2Yy4cufwPPpwg5nCirApNSYOCy cvI+2QlrgII0TS9dZfPmdtMNotGTQdhG+wOqrjGK5e6k+JvBARmWehoiPjsi nED5mArh/DVpX9BUg7/ycefDOL4EeVDTp+AlAVMLyMddtF1daAcgn5Q1qHjN HPpOUpKwEp0JLMYfr+jNvBvFJe1O+w074vyCV5ts01akdlHD03u4+MPESRoL 8IFuTz9o7jKp4cH6uG7R1l0F7sXRVZyoWu0tqNiBah8+Xf9ihjVztXpaokc1 lcvF1d1SitQExSYdC6GpKoY8hxWxSeIvTWLEQoB4au6bh9kcsB+0gih+QFWw gqYYiY35w1IAL43lIxAo8bUcgVQ/txxqQTM6EQAGH6+NLSL4c3AMg2hmnJjR 8X3zFs/AtQdaCou1Afn41DCdpgSLE0MM6mhtGvd+BHNNK/hVckjjjF2bOMTe floWuX+4tpHdZvzXsjYS4gwJ5wQEBOy1bkA6KF/tZ8MxBlJwwSLnGs2YTYNb x6wy8BpaH4+2aWhmUBlvBqnnUCAN0MPGDuU7d15LaBk440K/50Tzmp1iLo1K +dDFWeJ9DRwD920q0k2+wYdB2A8VW+g1527QTzeX3Ar67JgdAXayHh7Eg+JV XZPvgwfP+blnxydH+IDTJi1mU3iqFdU+tAsN5Uu+7ArxT+2JJY+8N2hEPhBc vrZlq+hSynYIukthm+hGLi0FgwGG2bYtcbShEA1MOoxphiAP5hDbEDqZ486D P0kCkFelUzPCFf2YIDCrNywySTeI18awacY53pA/iYWBZhTNPr/M3hy/+XLa edrEiXRQnc+DNdnVROpjTahiwkDDfevr6oRCSSDyw4Yn9kCqovV6DdpWDcdu ySD3jSHuT1PBPSTOZJfFsoMRM/eN0Ta5TR2T3hK9AlfwdhmXc0sgh7G5zrZ1 aYkMBERieHbQUD0s5PG7E4cVKwsfSXhelSfnJ5GAIten8HXlTkBqm5Swqfnb lVdfcuDtGJBwaI/k0KDPWw2yJkhyMV6cJsydPTn95bJ7Clq+K4kpidIQqHfn p5/Obs6upPb62TNuteQYd2EVremyY/XGqIDhtN6q6TZ+ZB8F6sad9Elhhk/B YllJ60DI0ZoCXpf3hhYoVAuF7MlxDCOZMWyV1ASKS8O+lmop1DvsFjEFHUk8 fVdKxl4qirkiiBWuSWKdxGpJ5WYiY8q22gWTZoxDMlj816QqQ4zaD5aq2UFE fhPcJZKm4TY2KrJ7jsqys4M4VUvIIcTzYm8AdAOhNozf9jmwwG0Xq3AxxRjX SIIkfZw2w+prN0WV6su0/L33daqmqW8bBg9seTotWA9FBt2WeO8bbANmmH44 O313diXt3a+ex3gUOU7oNx6Eo8Sx8dPK+JMUY2rnYXTRMYYLuDcg3zNcWIKi o3fSWH7y8hWsDiJbPpxFr/uA+6i7o0ZfEbsYoQ7C141FxpOnMq/vpR5Z4KEl E1tVc0SttHVIDL7Uu4YIfPYEyY0YejyZHc+OOUJKAyP6qJIVBkvn4A0KW6tn ocXfnq11YWComGfhxL5rg1bCGzwSTFdZ5wpxWUvW0ptRylMxIBwU5opA8h1n 4GjDuBumsFvSS/EKGRCcmQaUQ/etJQ3BfW7cGY1gtoYseA0qN4OrBATb/JNT H3YwGRRJw7PwPg0Pjjmt98V4ILbzHCej8VBT2Xpj7wl3jmQ/bKaPxKbXddAf cjdojUwruX5QP8WJQKONRvOQhqvcHsjoY/FwLcl/aeB0hkbEplbaQIkbdqcS q4SyHilSBTmVQ33gUGANwxD+yGvIHG0VNDgrG79Lpo/iG8iteZy9bQLqJr/m Jno9D4+lnd5HoQg756EXdM/VDVoqu1IE+Oco5n95otWHT7n3c+68fsEOWlVJ wekUMxq92+iIzRhMJY4ZsKMrDDNlND6+5XFQWSJgHQ7CfS1oQbqUv7pUH7Fj EsMSGml3yEjGa+Au2Ub96EYVKdLSDIc0sgevI3Rbpj1R4SokE0rfd59Lc9EM 5JBB0LxyvLVCY1ATIQbK2Xw73Y6FrTT7H61r0oyM4lwp8eesukasyn/s3kah ZNdLWLh0IGRNzutMrF7XTwzipeIkgbkHoGtnbVJ2AU2uJa2qyaVIL7VNaf3U vmjAl7CFpW33rJ5EzvARafAOPKGczlVnrdzT0boBDTYCD96gkGKnbK11e8JA mmQVl2hPG0hyBQg3W+56XR4dZglS/P793zKxOdG38+b4vOakNjPqO+1j5QPA RnarX1V6JTrS+IB8TO4j1hp2ahQrhSwqA7OiQC+RqHar3XohSjRLDKOaRb0e 6vt3IyacG4t1zTQfN2ydJ3/hlmKh7tq1sWw09Bp3HBexedt0nWJTuSSC6xZw 8dq4WiHe5cBdFTCqcicOjvdL8ObY2PNUkXhJrYnl8lddKFNg6ap1drsBB2sy nBEfVPmgmx0sB9v2g+MQ2fId/Jpcm55f/HJ6dX56caMY7NUrZZFI4VezZ9qp ceTdiLkwa4gNGN/czPjDU1ldGe2+1KSEkxb4AaqacMVKTg5UKNCI9YPx0Mh8 KyNwzFD9Fx6pH9a/jcrzh+ERqRuAzyW+pjbUDFrShqSTtTHy311ViN/stLds Bmcu5bF85vG8EmJxFU1iPcQRMAFWMIBjOaqnkUH2HngSrXry8KA53O9PY+jR g6VU++V8pZEmeYaSostmRHa5hwRJCX1eSbueXr4FaeXog2cPCc5LiZ1Jc/u/ qUp8M3yYM6aKHx5O10gSld8I69DLI65G1GmEEHGWCPVL6FM1HN/fAoJdpgkI Y67Qa+i93MTK+L4Qr+mSxIUb9avTuVU6ukkYNr1cJ6RfpLXxNyfTFALDip3Q IhfRcyIezSUSUmm3677hdlgy6n3jW4Yico2Tmt/aYVkvqo3c+yW3Vg2jJzgj tdbo+vv95enNh+n1+c8Xpx9Ft/z000uO7XUA6QTtVpzaSwwvjY21+qpmnM8t KidNhIs4PybmkHajRrN0JJ+z5R5Mx+wRiy12Sgzi+BIc18tiY/IzonLEppKm n+GSE4TrEWSnLThJT83j7CxExt+TDMGRQyV2WQm7W+38+ecaNAnIT+hIdCht JfICQNJOToGVWj9fuJ9eCUKL+qUMQ+JENAOweyGAjztAXFMI/dXnQtiBNYn2 0eilfhqjHdKPEuhQLqR80cdckESIJsSgjD3voz7luHjIVUC7IMKZZC/SWrGQ cGBdBe/C4AJi4hYp3fBnwJ1fYeuM2CLtCn+nFzbB1+LxOrm7iVVfXLxh0x7u ijxP8384EFh2mDM5Dqnu2fQNOC73+QjHp7Q1Eizo/PTJ1DCz8hb3ROsW/Nnb weLZiISH9RnucNEuWkxq/KTM71hreGUnJ0Y6vlY+96kDQdxAm+TMommX42qZ v84m4wKsm+n1Lyx3L14+e6mogt0t34vLljp0zJlm0+f+LjBk8Gys6a6THY22 z/slJ7sXooUVooVq39Kk1SKUO6f5ufCuv3Sn9xYRN9Iqt3DdCkeyQz8MKM8B Bc5p7OugiHcIDConExnw3jnrZL2pic7I0dpFgco0O4dDkxm+a2ji+YV/xnAe zYYMVyeeINc3xXjO+CpLs/Sb1TkVSnPoqJj4ayomvi1Fu8MHLBoq872CCUOp ngq6ZiEC4CFuIlie3p3KnI2lvBEadM75Gqx3n06vhN2ev1SEazQ/NSVrOb3y ioQt1fOTQ3V9smt/hc1b7RcVYhnzCZ5eBCuayPR1aTETHK798Rwu56UXo5l4 vU9oqp1vuf8SVQUdx3gRX1hp/UFyp9qKfBRcDIbDRSgey1rZIsbWkwwiFzZ+ 61nStYG4drcoQJA+OFWLg7JCcGOcrVkTgSXWPVrg6A5TXaUaeKRLSOFDcmKO 1pdoJ3eE70fuwXHktuJIK2MDGvDxmd0YkoYPFVyMYFC0WVy0JQGWGFsZrEK0 gpHCh76Fc6d7ipmLcMwR2qRhO7n2mf390IrE2TPt5vO3mAxuG/OeScJV8fIu ve8CYSeyjZK7S/ao9xCN6vt1n1rHcjNM3Pi0anBjJuNrRveVVGoJTooP/LVP whixbsH3XQxwSFKEoz3BZnhUse0/NgWwDfk5XC704uTVCZeHDm4bIM6guf3F QekFt3zfkP0KbLFMx0ccmCVo2IEYOmRXEsZ6eMDXBngNQW7G6Y52GN74Jff3 1Q2rUyd9THjN37IsuC/JtiO/rpdm6FjWOznJDUrztnQL4shNsVVsGMopfPUV Jtq5OANVGFHFhztCtSaV1uI73y6ujfnsL2VFoJzrouZcpcHRcMUYae4BfHLl umaDCPgVCQOuaqfXOvPk6op/eBpaYH1w73R0+aG0xLDMb0m/8+LS8LaZk/Vi 5f5PurLnos3K5NaF5M6SmcGx+U6qCbNX1dhCr+jzJLn5rxuW6laSE5tBB04s sIAqR+TeX+swYdjKGZ5NKA1yZFA4uHmJW9m22fvWrhwbYlijy/fMzceHhIgM J/53+hAk7aAFAtzDgRuA/NHVBZomY4UjJ2e0mieULugxwP5dXd386ZJLtZ/9 9OqF5sCSy3zGl7CECgEdw0s/ql6Q7RcYEBrYlI8YChrJKDKaj14m44AI/vfd aZOW2kENWxwpByAbZOoGOUoB2QxZuf1dgtU/vjPHhOgCnNLQzl2EUugyvYY9 dNR5U663egWv92zP8nnbiePOxfz3pRQkS3FEUMrj9Rn4IUBl+XJTf/UcxL9g jcDBqEImwcEBx4jdi9mRz+Eecd0N0y1qeg4gD9/uBrXHySzy8SRgUNYrZlPz hadBz3jFlvRKPPdLiFHkS7E5vptFGldolPNLTfvVwnYb1EZ2WhZM3pldk35h zho0qEwMpm3j9akclUC6Q28mv7w7GTSxEFLacHSGU4Bw9blP5BjoGPgfF61y GbVe4VXWvo+uT2qOcQUt4JXInL99UpUFWmCUJwfBMm/C204u2Q8X6QYODNW6 7G3ILRUxq51eoKmKHl4iMfzVuG3Bwz9fLsK3GIciJZGiUr6WYHjRlu/G4QXW C1JQo3e1NK0PZcthqnpLnsHaZc3upbnaRaD5W9/Fo03tx8fPD55lj/KKyJud PfLXYkrFsbAG0VPO8PDVy5ew8lK4yg+MmlECCQX0450XSO2bsM4uflHINtkY 35sBhVEivMU1iwxbdFRaHvdt4GSIbEgic3Ytx818T7CH508FprMQsXQvVUvz YIPyleF4acLoyfHzQxrKDPYrvWej8lBfqp1Wo2obPB/N8MDDtVdcvj9UaHIP WMqR6oWNlhkC09AmmmXlXgAtCEpqeOKSvG7jfrl9CF8xGxQ1vszg1hDV0hol mAthCVZCg7G74RdXyI3Hq+gG2s5IvLyITVne7eUvgVlXmy7B/GlEAJ9rRj6J bvuLhmHYSGddEUuR+jitHJxXHNrp3XMY0+MjZErkDyf8hxfQw3xi9J7vkxnc 8RxKAFG/WSBKqAfEt/PItVriTy1EPkMLhEY2axorIyHkSivXGq2oCwrd3zjL lUa9IqkI0Sca0UoLCmUkIgw2aBj81GkDYax9QzNOuAVGM1QQM9otCepX1zPo xDX6XGHLX9SxmnOpDavquS0GGnZ0JVboOfWKF6ku13J0FgU4yfdf7BRLeLiU XHlDyFw663TYgJyJsrj02Fh/02u4p4ZLRIAr0vt4M72Pl2+1B9YQgvni2euL T5eaAvM9+oN6Pmn59NZQDci1eOcXyqifOKDCMY9gTJ5g4KeMGOmHuyNw2NHR T8BvPvmpok0H2zl2r7jxBF4omB3MVRi9hMEXdq3W0oiQE4RMVLv36yWDysSv seZ4mdSoy9Xvg5bm73mYaYO4lODiC4fIkyL7lS+lRF8mldHA7uT6raQ3T86Y fSff/OIjfwiU01J4npA7Pp5kxzm/+ixDzQpfq0KKo6n4a11updMcuP2b5c6f e98/FDuW9bsyOq6mSMVhkKUGQ2hzUyISWlbEeZ7RRTE0/+BlzqFyukx8KT53 5Zybt5f70SR9wN+M8pbLpcm6ISMbr3kMCGrwbQJQ2sa3UKnQhsxFuFMMC+MK AL2Pa4pJfAPp0fOfDo4PT16+PDqZ8X+fPQ+mKcYbV+n3a2Gd/EVeUmJ3jCZi vqqulstxvVNhGi43I0TZad+Gr0MYfg0YO/innRlOIrd6cWb2ttUbXPTbWfyx DTOjrBNiP1m1NVpzzBKptad9E1roQ7pH74zkmUUdJ71s4KBYhsMtQlxl1ZYd mgd2Vet7QIfPBC75ON9/ltgkJ9hjA4vvf2M/YM8dVoPSwUG9mDZhyAUoKFdP 7B5pcr00cbiBYf2ixVccAUngigfCDiB2XLS/DFS/HUjdQ3buwq3nzMgfrwnz w9XgkkLpyw4x1Se4mp0J8PH66Fi+M+r5CZFAay+H94RKhsKa9Dp2lL3O/xb6 qDouIUSoXp2HcIdVeh2HVNLTyvZOkyQJdu9jHt0VO+pAMuaXPc9JH052NDsO SSK0Fwame/QB39aCO543vbTNagUmLiTV8Z6g9+jpo6zLl058Wt6S7dRJ9V+D 46Hv6D69mQk2MfQjcBuAD735HrZwqafOG5pWrVw4YA3KDwhk3u1+Y4P/Cg4u gEQbhKoa/90fUms4vCxxXDPBohMvGNPvEAL5gu4s+Ypa/i4eKInkmxiRvgVT CLWfGWWsZxLTZ8ayc/RhAnaAoHuPVa5dxbQhjhIuqecN8FdZKkbjs7m+OPdc PCXCs747PDnh+255MWUo6De4ZwpXivZDj8h5tpNqIL4NXfjcjZhMjMGMv3vT BB7iUrB4E8Ggcz1ICgP9gSvi77qSMhJfx4wlD67ccMHJSroF8K2e7GJwzYME B2KMwYSiRV+GKKWlzSIJPXJlIhEXQ/3gXgFGh6GNnH17mFP+qkFLOI57Q/Ar vgqukd0YfgwOmDaNwwPT4BhC8MGD8V/oFA2oXgZQSCUlF9Lb2kSvzn1zdGjI CfpoOdZe6q3JsXBsqG7UySdPD06yETdytzNZv5KsDyguNNBFtn14oAl96Pk0 3GfO4U7z8FowmCt+92hBaNU9Qvi4cS1HU84IqgLn/0oj4xs07Vfog09l+zeb /ef/+7/Lyt0TV0+ys6okvf7RIWDP3+Z40fBVoUu7kmsX36AEJyOtvlrhgjuO mKeNAVynyZEH1QaDRNjM/H8A7ffEMHkAAA== --></rfc>