<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.4 (Ruby 3.2.2) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-pce-pceps-tls13-04" number="9916" category="std" consensus="true" submissionType="IETF" updates="8253" obsoletes="" tocInclude="true" sortRefs="true" symRefs="true"version="3"> <!-- xml2rfc v2v3 conversion 3.19.0 -->version="3" xml:lang="en"> <front> <title abbrev="Updates for PCEPS">Updates for PCEPS: TLS Connection Establishment Restrictions</title> <seriesInfoname="Internet-Draft" value="draft-ietf-pce-pceps-tls13-04"/>name="RFC" value="9916"/> <author initials="D." surname="Dhody" fullname="Dhruv Dhody"> <organization>Huawei</organization> <address> <email>dhruv.ietf@gmail.com</email> </address> </author> <author initials="S." surname="Turner" fullname="Sean Turner"> <organization>sn3rd</organization> <address> <email>sean@sn3rd.com</email> </address> </author> <author initials="R." surname="Housley" fullname="Russ Housley"> <organization abbrev="Vigil Security">Vigil Security, LLC</organization> <address> <postal> <street>516 Dranesville Road</street><city>Herndon, VA</city><city>Herndon</city> <region>VA</region> <code>20170</code><country>US</country><country>United States of America</country> </postal> <email>housley@vigilsec.com</email> </address> </author> <dateyear="2024" month="January" day="09"/> <area>Routing</area> <workgroup>Path Computation Element</workgroup>year="2026" month="January"/> <area>RTG</area> <workgroup>pce</workgroup> <keyword>PCEP</keyword> <keyword>PCEPS</keyword> <keyword>TLS 1.3</keyword> <keyword>TLS 1.2</keyword> <keyword>Early Data</keyword> <keyword>0-RTT</keyword> <abstract><?line 48?><t>Section 3.4 of RFC 8253 specifies TLS connection establishment restrictions for PCEPS; PCEPS refers to usage of TLS to provide a secure transport forPCEP (Paththe Path Computation Element CommunicationProtocol).Protocol (PCEP). This document adds restrictions to specify what PCEPS implementations do if they support more than one version of the TLS protocol and to restrict the use of TLS 1.3's early data.</t> </abstract><note removeInRFC="true"> <name>About This Document</name> <t> Status information for this document may be found</front> <middle> <!--[rfced] Regarding the title, even though "PCEPS" is explained in the abstract, please consider updating the title so that at<eref target="https://datatracker.ietf.org/doc/draft-ietf-pce-pceps-tls13/"/>. </t> <t> Discussionleast "PCEP" is expanded. Original: Updates for PCEPS: TLS Connection Establishment Restrictions Perhaps: Updates to the Usage ofthis document takes place onTLS to Provide a Secure Transport for the Path Computation ElementWorking Group mailing list (<eref target="mailto:pce@ietf.org"/>), which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/pce/"/>. Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/pce/"/>. </t> <t>SourceCommunication Protocol (PCEP) Or: TLS Connection Establishment Restrictions forthis draft and an issue tracker can be found at <eref target="https://github.com/ietf-wg-pce/draft-ietf-pce-pceps-tls13"/>.</t> </note> </front> <middle> <?line 58?>the Secure Transport of the Path Computation Element Communication Protocol (PCEP) For comparison, here's the title of RFC 8253: PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP) --> <section anchor="introduction"> <name>Introduction</name> <t><xref section="3.4" sectionFormat="of" target="RFC8253"/> specifies TLS connection establishment restrictions for PCEPS; PCEPS refers to usage of TLS to provide a secure transport forPCEP (Paththe Path Computation Element CommunicationProtocol)Protocol (PCEP) <xref target="RFC5440"/>. This document adds restrictions to specify what PCEPS implementations do if they support more than one version of the TLS protocol, e.g., TLS 1.2 <xref target="RFC5246"/> and TLS 1.3 <xreftarget="I-D.ietf-tls-rfc8446bis"/>,target="RFC9846"/>, and to restrict the use of TLS 1.3's early data, which is also known as 0-RTT data. All other provisions set forth in <xref target="RFC8253"/> are unchanged, including connection initiation, message framing, connection closure, certificate validation, peer identity, and failure handling.</t> </section> <section anchor="conventions-and-definitions"><name>Conventions and Definitions</name> <t>The<name>Conventions</name> <t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t> <?line -18?>here. </t> </section> <section anchor="tls-connection-establishment-restrictions"> <name>TLS Connection Establishment Restrictions</name><t><xref<t>Step 1 in <xref section="3.4" sectionFormat="of" target="RFC8253"/>Step 1includes restrictions on PCEPS TLS connection establishment. This document adds the following restrictions:</t> <ul spacing="normal"> <li> <t>Implementations that support multiple versions of the TLS protocol <bcp14>MUST</bcp14> prefer to negotiate the latest version of the TLS protocol; see <xref section="4.2.1" sectionFormat="of"target="I-D.ietf-tls-rfc8446bis"/>.</t>target="RFC9846"/>.</t> </li> <li> <t>PCEPS implementations that support TLS 1.3 or later <bcp14>MUST NOT</bcp14> use early data.</t> </li> </ul><dl> <dt>NOTE:</dt> <dd> <t>Early<aside><t>NOTE: Early data (aka 0-RTT data) is a mechanism defined in TLS 1.3 <xreftarget="I-D.ietf-tls-rfc8446bis"/>target="RFC9846"/> that allows a client to send data ("early data") as part of the first flight of messages to a server. Note that TLS 1.3 can be used without early data as perAppendix F.5 of<xreftarget="I-D.ietf-tls-rfc8446bis"/>.section="F.5" target="RFC9846"/>. In fact, early data is permitted by TLS 1.3 only when the client and server share a Pre-Shared Key (PSK), either obtained externally or via a previous handshake. The client uses the PSK to authenticate the server and to encrypt the earlydata.</t> </dd> <dt>NOTE:</dt> <dd> <t>Asdata.</t></aside> <aside><t>NOTE: As noted in <xref section="2.3" sectionFormat="of"target="I-D.ietf-tls-rfc8446bis"/>,target="RFC9846"/>, the security properties for early data are weaker than those for subsequentTLS- protectedTLS-protected data. In particular, early data is not forward secret, and there is no protection against the replay of early data between connections. <xref section="E.5" sectionFormat="of"target="I-D.ietf-tls-rfc8446bis"/>target="RFC9846"/> requires applications not use early data without a profile that defines itsuse.</t> </dd> </dl>use.</t></aside> </section> <section anchor="security-considerations"> <name>Security Considerations</name><t>The<!--[rfced] May we clarify the citation to RFC 9325 by adding "TLS/DTLS recommendations" to the sentence below? Original: The Security Considerations of PCEP [RFC5440], [RFC8231], [RFC8253], [RFC8281], and [RFC8283]; TLS 1.2 [RFC5246]; TLS 1.3 [I-D.ietf-tls-rfc8446bis], and; [RFC9325] apply here as well. Perhaps: The security considerations of PCEP [RFC5440] [RFC8231] [RFC8253] [RFC8281] [RFC8283], TLS 1.2 [RFC5246], TLS 1.3 [RFC9846], and TLS/DTLS recommendations [RFC9325] apply here as well. --> <t>The security considerations of PCEP <xref target="RFC5440"/>, <xref target="RFC8231"/>, <xref target="RFC8253"/>, <xref target="RFC8281"/>, and <xref target="RFC8283"/>; TLS 1.2 <xref target="RFC5246"/>; TLS 1.3 <xreftarget="I-D.ietf-tls-rfc8446bis"/>,target="RFC9846"/>, and; <xref target="RFC9325"/> apply here as well.</t> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name><t>There are no IANA considerations.</t> </section> <section anchor="implementation-status"> <name>Implementation Status</name> <aside> <t>Note to the RFC Editor - remove this section before publication, as well as remove the reference to RFC 7942.</t> </aside><t>Thissection records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in <xref target="RFC7942"/>. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effortdocument hasbeen spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalogue of available implementations or their features. Readers are advised to note that other implementations may exist.</t> <t>According to <xref target="RFC7942"/>, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".</t> <t>At the time of posting the -04 version of this document, there arenoknown implementations of this mechanism. It is believed that one vendor has implementation, but these plans are too vague to make any further assertions.</t>IANA actions.</t> </section> </middle> <back> <references> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><reference anchor="RFC8253"> <front> <title>PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)</title> <author fullname="D. Lopez" initials="D." surname="Lopez"/> <author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzalez de Dios"/> <author fullname="Q. Wu" initials="Q." surname="Wu"/> <author fullname="D. Dhody" initials="D." surname="Dhody"/> <date month="October" year="2017"/> <abstract> <t>The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or among PCEs. This document describes PCEPS -- the usage of Transport Layer Security (TLS) to provide a secure transport for PCEP. The additional security mechanisms are provided by the transport protocol supporting PCEP; therefore, they do not affect the flexibility and extensibility of PCEP.</t> <t>This document updates<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8253.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/> <!-- [I-D.ietf-tls-rfc8446bis] -> [RFC9846] draft-ietf-tls-rfc8446bis-14 companion doc RFC5440 in regards to the PCEP initialization phase procedures.</t> </abstract> </front> <seriesInfo name="RFC" value="8253"/> <seriesInfo name="DOI" value="10.17487/RFC8253"/> </reference> <reference anchor="RFC5440"> <front> <title>Path Computation Element (PCE) Communication Protocol (PCEP)</title> <author fullname="JP. Vasseur" initials="JP." role="editor" surname="Vasseur"/> <author fullname="JL. Le Roux" initials="JL." role="editor" surname="Le Roux"/> <date month="March" year="2009"/> <abstract> <t>This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE9846 inthe context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible soAUTH48 asto easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5440"/> <seriesInfo name="DOI" value="10.17487/RFC5440"/> </reference> <reference anchor="RFC5246"> <front> <title>The Transport Layer Security (TLS) Protocol Version 1.2</title> <author fullname="T. Dierks" initials="T." surname="Dierks"/> <author fullname="E. Rescorla" initials="E." surname="Rescorla"/> <date month="August" year="2008"/> <abstract> <t>This document specifies Version 1.2ofthe 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>1/16/26 --> <referenceanchor="I-D.ietf-tls-rfc8446bis">anchor="RFC9846" target="https://www.rfc-editor.org/info/rfc9846"> <front> <title>The Transport Layer Security (TLS) Protocol Version 1.3</title> <authorfullname="Eric Rescorla"initials="E."surname="Rescorla"> <organization>Windy Hill Systems, LLC</organization>surname="Rescorla" fullname="Eric Rescorla"> <organization>Independent</organization> </author> <dateday="7" month="July" year="2023"/> <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. This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, and 8446. This document also specifies new requirements for TLS 1.2 implementations. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-tls-rfc8446bis-09"/> </reference> <reference anchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <date month="May" year="2017"/> <abstract> <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference> <reference anchor="RFC9325"> <front> <title>Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title> <author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/> <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/> <author fullname="T. Fossati" initials="T." surname="Fossati"/> <date month="November" year="2022"/> <abstract> <t>Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases.</t> <t>RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks.</t> </abstract>month="January" year="2026"/> </front> <seriesInfoname="BCP" value="195"/> <seriesInfoname="RFC"value="9325"/>value="9846"/> <seriesInfo name="DOI"value="10.17487/RFC9325"/>value="10.17487/RFC9846"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9325.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name><reference anchor="RFC8231"> <front> <title>Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE</title> <author fullname="E. Crabbe" initials="E." surname="Crabbe"/> <author fullname="I. Minei" initials="I." surname="Minei"/> <author fullname="J. Medved" initials="J." surname="Medved"/> <author fullname="R. Varga" initials="R." surname="Varga"/> <date month="September" year="2017"/> <abstract> <t>The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.</t> <t>Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP.</t> </abstract> </front> <seriesInfo name="RFC" value="8231"/> <seriesInfo name="DOI" value="10.17487/RFC8231"/> </reference> <reference anchor="RFC8281"> <front> <title>Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model</title> <author fullname="E. Crabbe" initials="E." surname="Crabbe"/> <author fullname="I. Minei" initials="I." surname="Minei"/> <author fullname="S. Sivabalan" initials="S." surname="Sivabalan"/> <author fullname="R. Varga" initials="R." surname="Varga"/> <date month="December" year="2017"/> <abstract> <t>The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.</t> <t>The extensions for stateful PCE provide active control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model.</t> </abstract> </front> <seriesInfo name="RFC" value="8281"/> <seriesInfo name="DOI" value="10.17487/RFC8281"/> </reference> <reference anchor="RFC8283"> <front> <title>An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control</title> <author fullname="A. Farrel" initials="A." role="editor" surname="Farrel"/> <author fullname="Q. Zhao" initials="Q." role="editor" surname="Zhao"/> <author fullname="Z. Li" initials="Z." surname="Li"/> <author fullname="C. Zhou" initials="C." surname="Zhou"/> <date month="December" year="2017"/> <abstract> <t>The Path Computation Element (PCE) is a core component of Software- Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands.</t> <t>PCE was developed to derive paths for MPLS Label Switched Paths (LSPs), which are supplied to the head end of the LSP using the Path Computation Element Communication Protocol (PCEP).</t> <t>SDN has a broader applicability than signaled MPLS traffic-engineered (TE) networks, and the PCE may be used to determine paths in a range of use cases including static LSPs, segment routing, Service Function Chaining (SFC), and most forms of a routed or switched network. It is, therefore, reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller.</t> <t>This document briefly introduces the architecture for PCE as a central controller, examines the motivations and applicability for PCEP as a control protocol in this environment, and introduces the implications for the protocol. A PCE-based central controller can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it.</t> <t>This document does not describe use cases in detail and does not define protocol extensions: that work is left for other documents.</t> </abstract> </front> <seriesInfo name="RFC" value="8283"/> <seriesInfo name="DOI" value="10.17487/RFC8283"/> </reference> <reference anchor="RFC7942"> <front> <title>Improving Awareness of Running Code: The Implementation Status Section</title> <author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/> <author fullname="A. Farrel" initials="A." surname="Farrel"/> <date month="July" year="2016"/> <abstract> <t>This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature.</t> <t>This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.</t> </abstract> </front> <seriesInfo name="BCP" value="205"/> <seriesInfo name="RFC" value="7942"/> <seriesInfo name="DOI" value="10.17487/RFC7942"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8231.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8281.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8283.xml"/> </references> </references><?line 172?><section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t>We would like to thankAdrian Farrel, Stephane Litkowski, Cheng Li, and Andrew Stone<contact fullname="Adrian Farrel"/>, <contact fullname="Stephane Litkowski"/>, <contact fullname="Cheng Li"/>, and <contact fullname="Andrew Stone"/> for their review.</t> </section> </back> <!--##markdown-source: H4sIAAAAAAAAA5VY23IbNxJ9x1dgmYeNt0jKlGjHoR3bjCSvVZFtrSgnldra B8xMk0RpCEwADGmuS/+y37JftqeBGWooS17nQSVOD9Doy+nTjRkMBiLoUNJE 9j5WhQrk5dw6eXF8ejGbyKvzmTy2xlAetDXy1AeVldovV2SCvCQfnI5vfE+o LHO0nsgvtIgczwvrthPpQyHq9H4inx0+ORKisLlRKxxfODUPA01hPqhy4r/K D0LpR0eDx2Ph62ylvcdRYVth9dnp1RuR42Ayvoay4GoSOP1IKEcKzlzaOmiz 6ImNddcLZ+sKwgsVlvBnVdVBJYdKYld64pq2WFhMhBxEq9v/M/7BURgNj25/ HvLPU+XKrTxRQfHT48Hl1ZVYk6kJSuT/P1HK5EnvNxgIS+XfeQvLV0qXkCMC rzkcQ+sWLFYuX0K8DKHyk4MDXsUivaZhu+yABQeZsxtPB9h/wPsWOizrDDtj bDcLDu3Bw9HuCaHqsLSOY4HtUmqDAJ8M5cnSFtsoSRk7Wbp63ZHCAGX0v6Of E/m2VhvS8QUljwpeH219vWDJMLervTNmQ3lVO0Ouc8iMlOlK9w/x5sgV3TM8 lr+O0q72pOqy9l6+tbUvaWfwRP6qF7rEMXntdNj25fn5cXzZ4nn/fXwF2BOF iXwyeipPnDLk17osSV5alYzJsRIRIGcKa/ry12mS2gJWHD4e/fC4ea5N4LL4 OOu6sEwWvl7zwZ7y6IgYDAYwCSerPAgxawryaDiWdi4v3xzHcpK+olzPNcqP gZrfVi7tVa7rVK7YFerz9A9v5+S8DFbWXi2ID2BteK6cXeuCpEKcEQ9C2Snj K+sCl7vg7fL7hyDPslVtdJ6kF84Gm9vy0VDKq6X2EkxQx3WqKLzomshHJ8+2 crNUobFTr6qkWaVVhZV6LsOSttLXFVslVpaNXAJC1pBcwy0+2sZV0amqsUIq U/Ax7bFxQe3ZedGU/1+9pFjy4C81FCklK10UJQnxnTxDLm1RR4uF+Pz5Tor+ ghxxim5uvjFJ+xH49iSJrydJfj1J4oEkyc+f2YMn4/Hjm5t7MyYfyJj4UxmT D2VM3M1YX9JwMey3jNwaeDh+ihAjm23a+MXZ4CTyDjPcwM3zZ+Px00z7m5v+ n817HwDU+VLCe1V6K6+N3RipfOL/BA05LUtpocilXPjoq6cYf4RdG9h0Cwc0 LFmbHC4vqOjjbV7WBTeEW2QIbXTQMWh9uSIfMz53aoVl/S6C8tJ6pBwycgEY 49Yr16rURdosKiIngQ4TItmx93OwDsMEBhQlFDK0v+Ouv+ZVbDqvOqF5NIIZ Q1whSOiYkluml713H2dXvX76L99/iL8vT//x8ezy9IR/z95Oz893P0SzYvb2 w8fzk9tftzuPP7x7d/r+JG2GVO6JRO/d9Pdesr334eLq7MP76XmPoxr2QclA sjIjvArkKkeBCqRKFORzpzM8YM/Pxxf//c9o3MDncDT6ESlJD89GP4zxsFmS SadZU26bR8asUFUFZLAWhYznqtIBoOgzHPyScQEIEML5t39yZP41kS+yvBqN XzYCdnhP2MZsTxhj9qXki80piPeI7jlmF809+Z1I79s7/X3vuY17R/jiFdBD cjB69uqliBj65unxHr68rY9ZoEqOmrqgOzzDHBWpZZ9KxR6VDu+jKy70uS1L u+Fa6yqdIGPy7A5VBWaxHUnVZdB43/KTv7elcI7BAEzUDESDIZiLmOLKkofg 8LWW9ByUQZ3AjIeHwxEvfJDNGGoPMO2e+S0zohuwGU62aIzMt9fkIDydiEkz 7LJQfq+uVYfuHkUuBCsxg2m/kgUzRSqu3eCMinrQ6mSb4kyworzUnCNuIISa S0f2olHQw4+9R1xhlYInTdjm2iGW81IvllHWUGRsQ9wGHcKMpvXeBuK5m89r Y5Cj02SR8gu5waSMa0MnAvEgBGiKSjeF/iTfDJ9wa/iqQzjpzIBW89DvqtJR 1UoHpqFsyxZAT8xDyyvRmSYATDjJcpAJc5lCN6bBjH8X8hew7/cXs18e9aGD NDcbabOgYuTpE5JqENEtp3it4QZQRWuNyTLSPBReU+zi7XHQghCkqoDaGDjc ArgD5C1kG2uajkkmd9sqNcxudjqgmXppbEhQuMXxIXv8FRT3m8N2AzcKouJ2 1lwqu9lBWDYEX1waGZA+T3ER7oue/qg5kIjzIGkJsICKpklzjhhDOq9xj7qb KdjNejbKcRZy9I7YAiJ6QOppSauTvVILxN6ncDiqSrVlJztKMwobIiNkh6b8 kIG0A9dpBNfDkYHiP2oNquLbYFWVzZSWrN0v3R2WOfN2rktKsE/F6aUOPqV8 yETd3m6YrT2mA6c6jf6Bl2xpnCXjLJMGwz4eXkXmPhqlpx2N90X76tmonbt2 Erx/3hnkdnPcc3k7xD2MFwFdz5ue/ePR4ROeqRCdbWy/XMEbKsvo59n0/fQ+ H3kZ/pDRuCLfW5F27vEpepIKNfa+ULwQN3Z3XaDh/9TLSptf916KRDZcJwwI vp+dFjoAmAMkcWXXlIYV36AnoznPvVWdtUnlKQJa2HR2YbeJ0uSP6ovaWfMP P44Ph+LFQbTlJTvU0ewoj0NarKloNScuja13m0RiU7FrYC2Tg6ySteni0twN VAJ70Kt4+6is5w8uSYn24oyHLkNhcMKfGlLCoSNTzLS8Pda19YrP6QxkCRTs Ezc0BmB6XYWmT961uh38Wo+1jwOfKYh5SijvdVOX/NGIlwP8UJrHwZytyNEu KCrCwwL15dmR+ImEW4iAPVypFyXB+EhpqZhiH9c7t5XZQkehcfuq4dW+nSKi rLCUqpVfbsGhhXU+3Y5jkJONOOtN7Zho+DbUZ1zSnO8OYgkoZGARTkVqkmBk vhbzVm2wZpWSA7pH+2S2i+dGczdAFI8AIPyY0xgOYB2DT1YDm7691zX8t4ui 8il9qxqBxBuBhsk1wh/dijRj97lzg3dKu6gjHNSav09l4J0vUMZkTdqJOQGO sBPHXpIq+Dob+1yBK1PSexvqeJ36QtVKbQV9QgZQo9Ocgc6pwMYuiHCHiPjY aC4lHjMk90LaxAPh1qb5ABe/2XnBrQ8IWBhZ1LTPBay6nSKbmWqpmrLMyKBc ePwQrjYmXeAKai+MMDU1UK5m4gs6VzAChdtZHeNEn9Dl9C1g4t2MqMhUft05 a4VIpXS3wUCs2pL16f68ioEdirPAuayrloc66Nx3On1HaEipiyNAJl3Piaes 0ONA31/3LBs8Hu9PtJ2pu990zkS04isMhE27aXIokw8ZAbVrRkVEgyH+1Iri kVwR+1r6Emjmw+AP+rDxzU0QtaIYnHB1hZFBcLnOU5lxwnnCSGwfP+xw1Jn4 pzlbWlKxiEkXnyemXmVwpPipN8dtj3o3QvyGMcTWZQE2uG5IX5lrOS2cxlTy RjlHZT9eZCAnea7DNYbda92XxxixFhCk6WJqCkcbLORvH/O2UBq4DsX/ABDi ZoKtFwAA[rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </rfc>