<?xml version='1.0' encoding='utf-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version1.7.291.7.30 (Ruby3.4.4)2.5.9) --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-core-coap-dtls-alpn-05" category="info" consensus="true" submissionType="IETF" number="9952" tocInclude="true" sortRefs="true" symRefs="true" version="3"> <!-- xml2rfc v2v3 conversion3.30.03.32.0 --> <link href="https://datatracker.ietf.org/doc/draft-ietf-core-coap-dtls-alpn-05" rel="prev"/> <front> <title abbrev="CoREALPN">ALPNALPN">The Application-Layer Protocol Negotiation (ALPN) ID Specification forCoAPthe Constrained Application Protocol (CoAP) over DTLS</title> <seriesInfoname="Internet-Draft" value="draft-ietf-core-coap-dtls-alpn-05"/>name="RFC" value="9952"/> <author fullname="Martine Sophie Lenders"> <organization abbrev="TU Dresden">TUD Dresden University of Technology</organization> <address> <postal> <street>Helmholtzstr. 10</street> <city>Dresden</city> <code>D-01069</code> <country>Germany</country> </postal> <email>martine.lenders@tu-dresden.de</email> </address> </author> <author initials="C." surname="Amsüss" fullname="Christian Amsüss"> <organization/> <address> <email>christian@amsuess.com</email> </address> </author> <author fullname="Thomas C. Schmidt"> <organization>HAW Hamburg</organization> <address> <postal> <street>Berliner Tor 7</street> <city>Hamburg</city> <code>D-20099</code> <country>Germany</country> </postal> <email>t.schmidt@haw-hamburg.de</email> </address> </author> <author initials="M." surname="Wählisch" fullname="Matthias Wählisch"> <organization abbrev="TU Dresden & Barkhausen Institut">TUD Dresden University of Technology & Barkhausen Institut</organization> <address> <postal> <street>Helmholtzstr. 10</street> <city>Dresden</city> <code>D-01069</code> <country>Germany</country> </postal> <email>m.waehlisch@tu-dresden.de</email> </address> </author> <dateyear="2025" month="August" day="11"/> <area>Web and Internet Transport</area> <workgroup>Constrained RESTful Environments</workgroup>year="2026" month="March"/> <area>WIT</area> <workgroup>core</workgroup> <keyword>CoRE</keyword> <keyword>CoAP</keyword> <keyword>SVCB</keyword> <keyword>DTLS</keyword> <keyword>ALPN</keyword> <abstract> <?line68?> <t>This87?> <!-- [rfced] FYI - We updated [I-D.ietf-core-dns-over-coap] to [PRE-RFC9953] for now. We will make the final updates in RFCXML (i.e., remove "PRE-"). --> <!--[rfced] Author Names a) Thomas, we note "T. C. Schmidt" in the document header; however, the majority of past RFCs have used "T. Schmidt". Which form do you prefer? b) Martine, please confirm if you prefer "M. S. Lenders" or "M. Lenders" in the document header. --> <!-- [I-D.ietf-core-dns-over-coap] - RFC 9953 draft-ietf-core-dns-over-coap-20 Companion document (C554) --> <!--[rfced] Document Title a) Please note that the document title has been updated as follows. Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC Style Guide"). In addition, is "Specification" essential to the title or may it be removed for conciseness? Original (document title): ALPN ID Specification for CoAP over DTLS Current: The Application-Layer Protocol Negotiation (ALPN) ID Specification for the Constrained Application Protocol (CoAP) over DTLS Perhaps: Application-Layer Protocol Negotiation (ALPN) ID for the Constrained Application Protocol (CoAP) over DTLS b) For the short title that spans the header of the PDF file, should "CoRE ALPN" be updated to "ALPN ID for CoAP over DTLS" to more closely match the document title? Original (short title): CoRE ALPN Perhaps: ALPN ID for CoAP over DTLS --> <!-- [rfced] Abstract: Should the abstract mention DTLS? Original: This document specifies an Application-Layer Protocol Negotiation (ALPN) ID for transport-layer-secured Constrained Application Protocol (CoAP)services.</t> </abstract> <note removeInRFC="true"> <name>Aboutservices. Perhaps (similar to text in the Introduction): ThisDocument</name> <t> The latest revision of this draft can be found at <eref target="https://core-wg.github.io/coap-dtls-alpn/draft-ietf-core-coap-dtls-alpn.html"/>. Status informationdocument specifies an Application-Layer Protocol Negotiation (ALPN) ID for Constrained Application Protocol (CoAP) services that are secured by DTLS. --> <!-- [rfced] Introduction: We updated "by transport layer security using DTLS" to "by TLS using DTLS" here. Would further updating as shown below improve this sentence? Original: This documentmay be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-core-coap-dtls-alpn/"/>. </t> <t> Discussion of thisspecifies an ALPN ID for CoAP services that are secured by transport layer security using DTLS. Current: This documenttakes place on the Constrained RESTful Environments Working Group mailing list (<eref target="mailto:core@ietf.org"/>), which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/core/"/>. Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/core/"/>. </t> <t>Sourcespecifies an ALPN ID forthis draft andCoAP services that are secured by TLS using DTLS. Perhaps: This document specifies anissue tracker can be found at <eref target="https://github.com/core-wg/coap-dtls-alpn"/>.</t> </note>ALPN ID for CoAP services that are secured by DTLS. --> <t>This document specifies an Application-Layer Protocol Negotiation (ALPN) ID for transport-layer-secured Constrained Application Protocol (CoAP) services.</t> </abstract> </front> <middle> <?line73?>175?> <section anchor="introduction"> <name>Introduction</name> <t>Application-Layer Protocol Negotiation (ALPN) enables communicating parties to agree on an application-layer protocol during a Transport Layer Security (TLS) handshake using an ALPN ID <xref target="RFC7301"/>. This ALPN ID can be discovered for services as part of Service Bindings(SVCB)(SVCBs) via the DNS, using SVCB resource records with the "alpn" Service Parameter Keys <xref target="RFC9460"/>. As an example, applications that use the Constrained Application Protocol (CoAP) <xref target="RFC7252"/> can obtain this information as part of the discovery of DNS over CoAP (DoC) servers (see <xref section="3.2" sectionFormat="of"target="I-D.ietf-core-dns-over-coap"/>)target="PRE-RFC9953"/>) that deploy TLS 1.3 <xref target="RFC8446"/> as well as Datagram Transport Layer Security (DTLS) 1.2 or 1.3 <xref target="RFC6347"/> <xref target="RFC9147"/> to secure their messages. This document specifies an ALPN ID for CoAP services that are secured bytransport layer securityTLS using DTLS. An ALPN ID for CoAP services secured by TLS has already been specified in <xref target="RFC8323"/>.</t> </section> <section anchor="application-layer-protocol-negotiation-alpn-ids"> <name>Application-Layer Protocol Negotiation (ALPN) IDs</name> <t>For CoAP over TLS, an ALPN IDwasis defined as "coap" in <xref target="RFC8323"/>. As it is not advisable tore-usereuse the same ALPN ID for a different transport layer, an ALPN for CoAP over DTLS is registered in <xreftarget="iana-coap-alpn"/>.</t>target="iana"/>.</t> <t>ALPN ID values have variable length. For CoAP over DTLS, a short value ("co") is allocated, as this can avoid fragmentation of Client Hello and Server Hello messages in constrained networks with link-layer fragmentation, such as 6LoWPAN <xref target="RFC4944"/>.</t> <t>To discover CoAP services that secure their messages with TLS or DTLS, the ALPN IDs "coap" and "co" can be used, respectively, in the same manner as for any other service secured withtransport layer security,TLS, as described in <xref target="RFC9460"/>. The discovery of CoAP services that rely on other security mechanisms is out of the scope of this document.</t> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <t>Any security considerationsonfor ALPN (see <xref target="RFC7301"/>) and SVCB resource records (see <xref target="RFC9460"/>) also apply to this document.</t> </section> <section anchor="iana"> <name>IANA Considerations</name><t><cref anchor="replace-xxxx">RFC Ed.: throughout this section, please replace RFC-XXXX with the RFC number of this specification and remove this note.</cref></t> <t>This document<t>IANA has added the followingactions for IANA.</t> <section anchor="iana-coap-alpn"> <name>TLS ALPN for CoAP</name> <t>The followingentryhas been addedto the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs"registry, which is part ofregistry in the "Transport Layer Security (TLS) Extensions" registry group.</t><ul spacing="normal"> <li> <t>Protocol: CoAP<table anchor="table1"> <name>TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs Registry</name> <thead> <tr> <th align="left">Protocol</th> <th align="left">Identification Sequence</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">CoAP (overDTLS)</t> </li> <li> <t>Identification sequence: 0x63DTLS)</td> <td align="left">0x63 0x6f("co")</t> </li> <li> <t>Reference:("co")</td> <td align="left"> <xreftarget="RFC7252"/> and [RFC-XXXX]</t> </li> </ul>target="RFC7252"/>, RFC 9952</td> </tr> </tbody> </table> <t>Note that <xref target="RFC7252"/> does not define the use of the ALPN TLS extension during the DTLS connection handshake. This document does not change thisbehavior,behavior and thus does not establish any rules like those in <xref section="8.2" sectionFormat="of" target="RFC8323"/>.</t> </section></section></middle> <back> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><reference anchor="RFC6347"> <front> <title>Datagram Transport Layer Security Version 1.2</title> <author fullname="E. Rescorla" initials="E." surname="Rescorla"/> <author fullname="N. Modadugu" initials="N." surname="Modadugu"/> <date month="January" year="2012"/> <abstract> <t>This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6347"/> <seriesInfo name="DOI" value="10.17487/RFC6347"/> </reference> <reference anchor="RFC7252"> <front> <title>The Constrained Application Protocol (CoAP)</title> <author fullname="Z. Shelby" initials="Z." surname="Shelby"/> <author fullname="K. Hartke" initials="K." surname="Hartke"/> <author fullname="C. Bormann" initials="C." surname="Bormann"/> <date month="June" year="2014"/> <abstract> <t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t> <t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t> </abstract> </front> <seriesInfo name="RFC" value="7252"/> <seriesInfo name="DOI" value="10.17487/RFC7252"/> </reference> <reference anchor="RFC7301"> <front> <title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension</title> <author fullname="S. Friedl" initials="S." surname="Friedl"/> <author fullname="A. Popov" initials="A." surname="Popov"/> <author fullname="A. Langley" initials="A." surname="Langley"/> <author fullname="E. Stephan" initials="E." surname="Stephan"/> <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> <reference anchor="RFC9147"> <front> <title>The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title> <author fullname="E. Rescorla" initials="E." surname="Rescorla"/> <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/> <author fullname="N. Modadugu" initials="N." surname="Modadugu"/> <date month="April" year="2022"/> <abstract> <t>This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t> <t>The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol.</t> <t>This document obsoletes RFC 6347.</t> </abstract> </front> <seriesInfo name="RFC" value="9147"/> <seriesInfo name="DOI" value="10.17487/RFC9147"/> </reference> <reference anchor="RFC9460"> <front> <title>Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)</title> <author fullname="B. Schwartz" initials="B." surname="Schwartz"/> <author fullname="M. Bishop" initials="M." surname="Bishop"/> <author fullname="E. Nygren" initials="E." surname="Nygren"/> <date month="November" year="2023"/> <abstract> <t>This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy.</t> </abstract> </front> <seriesInfo name="RFC" value="9460"/> <seriesInfo name="DOI" value="10.17487/RFC9460"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7301.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9147.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9460.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8323.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <referenceanchor="RFC8323">anchor="PRE-RFC9953" target="https://www.rfc-editor.org/info/rfc9953"> <front><title>CoAP (Constrained Application Protocol)<title>DNS overTCP, TLS, and WebSockets</title> <author fullname="C. Bormann" initials="C." surname="Bormann"/> <author fullname="S. Lemay" initials="S." surname="Lemay"/> <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/> <author fullname="K. Hartke" initials="K." surname="Hartke"/> <author fullname="B. Silverajan" initials="B." surname="Silverajan"/> <author fullname="B. Raymor" initials="B." role="editor" surname="Raymor"/> <date month="February" year="2018"/> <abstract> <t>Thethe Constrained Application Protocol(CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control.</t> <t>Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport.</t> </abstract> </front> <seriesInfo name="RFC" value="8323"/> <seriesInfo name="DOI" value="10.17487/RFC8323"/> </reference> <reference anchor="RFC8446"> <front> <title>The Transport Layer Security (TLS) Protocol Version 1.3</title> <author fullname="E. Rescorla" initials="E." surname="Rescorla"/> <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="I-D.ietf-core-dns-over-coap"> <front> <title>DNS over CoAP(DoC)</title> <author fullname="Martine SophieLenders" initials="M. S." surname="Lenders"> <organization>TUD Dresden University of Technology</organization>Lenders"> <organization/> </author> <author fullname="ChristianAmsüss" initials="C." surname="Amsüss">Amsüss"> <organization/> </author> <author fullname="CenkGündoğan" initials="C." surname="Gündoğan"> <organization>NeuralAgent GmbH</organization>Gündoğan"> <organization/> </author> <author fullname="Thomas C.Schmidt" initials="T. C." surname="Schmidt"> <organization>HAW Hamburg</organization>Schmidt"> <organization/> </author> <author fullname="MatthiasWählisch" initials="M." surname="Wählisch"> <organization>TUD Dresden University of Technology & Barkhausen Institut</organization>Wählisch"> <organization/> </author> <dateday="24" month="July" year="2025"/> <abstract> <t> This document defines a protocol for exchanging DNS messages over the Constrained Application Protocol (CoAP). These CoAP messages can be protected by (D)TLS-Secured CoAP (CoAPS) or Object Security for Constrained RESTful Environments (OSCORE) to provide encrypted DNS message exchange for constrained devices in the Internet of Things (IoT). </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-core-dns-over-coap-17"/> </reference> <reference anchor="RFC4944"> <front> <title>Transmission of IPv6 Packets over IEEE 802.15.4 Networks</title> <author fullname="G. Montenegro" initials="G." surname="Montenegro"/> <author fullname="N. Kushalnagar" initials="N." surname="Kushalnagar"/> <author fullname="J. Hui" initials="J." surname="Hui"/> <author fullname="D. Culler" initials="D." surname="Culler"/> <date month="September" year="2007"/> <abstract> <t>This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes. [STANDARDS-TRACK]</t> </abstract>year="2026" month="March"/> </front> <seriesInfo name="RFC"value="4944"/>value="PRE-9953"/> <seriesInfo name="DOI"value="10.17487/RFC4944"/>value="10.17487/PRE-RFC9953"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4944.xml"/> </references> </references> <?line123?> <section anchor="change-log"> <name>Change Log</name> <section anchor="since-draft-ietf-core-coap-dtls-alpn-04"> <name>Since <eref target="https://datatracker.ietf.org/doc/draft-ietf-core-coap-dtls-alpn/04/">draft-ietf-core-coap-dtls-alpn-04</eref></name> <ul spacing="normal"> <li> <t>Address Deb Cooley's IESG ballot COMMENT</t> </li> </ul> </section> <section anchor="since-draft-ietf-core-coap-dtls-alpn-03"> <name>Since <eref target="https://datatracker.ietf.org/doc/draft-ietf-core-coap-dtls-alpn/03/">draft-ietf-core-coap-dtls-alpn-03</eref></name> <ul spacing="normal"> <li> <t>Make DTLS references normative</t> </li> </ul> </section> <section anchor="since-draft-ietf-core-coap-dtls-alpn-02"> <name>Since <eref target="https://datatracker.ietf.org/doc/draft-ietf-core-coap-dtls-alpn/02/">draft-ietf-core-coap-dtls-alpn-02</eref></name> <ul spacing="normal"> <li> <t>Address shepherd review</t> </li> </ul> </section> <section anchor="since-draft-ietf-core-coap-dtls-alpn-01"> <name>Since <eref target="https://datatracker.ietf.org/doc/draft-ietf-core-coap-dtls-alpn/01/">draft-ietf-core-coap-dtls-alpn-01</eref></name> <ul spacing="normal"> <li> <t>Address review by Esko Dijk</t> </li> <li> <t>Address review by Marco Tiloca</t> </li> </ul> </section> <section anchor="since-draft-ietf-core-coap-dtls-alpn-00"> <name>Since <eref target="https://datatracker.ietf.org/doc/draft-ietf-core-coap-dtls-alpn/00/">draft-ietf-core-coap-dtls-alpn-00</eref></name> <ul spacing="normal"> <li> <t>Fix ALPN ID for CoAP over TLS</t> </li> <li> <t>Change intended status to Informational</t> </li> </ul> </section> </section>215?> <section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t>We would like to thankRich Salz<contact fullname="Rich Salz"/> for the expert review on the "co" ALPN ID allocation. We would also like to thankMohamed Boucadair and Ben Schwartz<contact fullname="Mohamed Boucadair"/> and <contact fullname="Ben Schwartz"/> for their earlyreviewreviews before WG adoption of thisdraftspecification andEsko Dijk, Thomas Fossati,<contact fullname="Esko Dijk"/>, <contact fullname="Thomas Fossati"/>, andMarco Tiloca<contact fullname="Marco Tiloca"/> for their feedback and comments.</t> <!--[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. --> </section> </back> <!-- ##markdown-source:H4sIAAAAAAAAA7VY3W7juBW+11MQHqBNFpHsxNnMjK/GiZPZoEkaxJ6mwGwL 0BJtsZZEL0nZ8QR5m32M3u2L9TukJNuZbH6AqS/8I5Ln9zvfOXQYhoGVNhM9 1upfXF+x8wEbzkUsJzLmVqqCTZRmJ6p/zdRCaDYYXQxZK+DjsRYLnDlRN6eM DrYC7BdTpVc9JouJCoJExQXPITjRfGJDKewkjJUWeOPzMLGZCXk2L8LOz4Ep x7k0Bursao4T56ejM8beMZ4ZBSWySMRc4K2wrT3WEom0Skue0Y/z/jE+YGPr /GZ01gqKMh8L3QsSWNMLYlUYUZjS9JjVpQhgcjfgWnBIvRVjxouEnRdW6EJY NtK8MHOlbStYKj2balXOnYuFsZrLQiTs5nQ4mpQZOy0WUqsih0WmFczECgeS XsBCRgHxn/1r+hz+4+SYPilw9EmxChaiKGEdw+v1Wmi3D0/rFubJYso+02G/ knOZYYUC/IlCHSk99StcxylWUmvnptdu00Z6JBciqje26UF7rNXSiDaJaPuj U2nTclyJDZfT9nbq/KYMkTZ2Q0O1OfKnI6keHWs/D4gotXnWCgJe2lRpF1SG aGQeTJdcWwSJDdU8lYJdECy0cYbAkR4bfRmwgRYGYGFfCjipjbQrpiZsJOK0 UJmarnxYKgiPvtT73WMkQQh484vI8lRl9hseRGy/4xZjiOptbY9VAqMGYWe/ c/SxelIWlqrgs9A5L7wy4dOTe+OjzFv9yZZh4oVFiXCOeidPUi2Nlbxg/dz8 8V9jNoXE9eInnptSGBPFKn8UpVGqcm7YScSGcZrLxNYB4oX85uoaHvZv2S88 H5d6uuX5sdAZjNRshKp6v+H35uba74NO5+PLftvIeDM+pXwZpl7OtsuX3NpU wubbP35PM4n9b8sp+ws75nqW8hIFj5pGhGxp/yTTz2z+/+Y/WnLhvXuU+6BQ 2G3hG9HCzdnJUffwPagTRbF/4J+8P/j5ANlHrVS/u539HqOK8b8/7jcnutWT w6NOj5lFPA4C4uRtDR+6B10vL7RxJfPD4eER0lWJOA8H0bpKk8KE1ANcuUKR iv2Zw4+Hhz12lIHywzBEtInHYhsEo1Qa2lYSgTHju4owjGA9n2dVgwkv+Apg u9bKqlhl7ApNBOh2vWeH2HKXehKMD2zNz2FGR0Ij4lKDLjepc0PwWuQOkfEu M0IvZCxM5A0FHpMMkX9HHUCrpIzpVBC8zTZR8HEGp1CDeVm4cyDmORU6nlrF +BSAYjgAt/mGaOcDm9eik1LTQb7uQswrH5KXBPcddJBdlqJlmZTPBCuNO1Cw um/f3zv+fHiIfOjr5zH2jAVLADvKH6JEPb2OBkPNkblUTkP/jB2j40K4YTvU vnbZQnJmU8EGV8O9Si8tMOBXlRoHtABEEsOWoHy3s+X6QyPwmmtUOfos+5tY GbKUUEmW9h0exB3P55nY24wQopdyC3XCSXxtliGbAPrw4PxWY4sjEIB4NCVA yVg7TcLr2DhSgZd+2HFjz85AnXjsgHbYjkEy7++RFCemGx3QiRAof3jY9QZj VsnUitGgtB91yR5XTzAISpciy+hzwC2AwfNn0j1w+d4nDbqW5PkAourvJBYg 86VArkjNcvQEPiWcP1eBFTia8a7Bg3MCMxKr62u8Yk3pMQ9bU1vpwUCmIpXP Sd0QRpFJEQOeYRBLVsAmSLg2LkGa6hwSLxFGUKJvJQwTBGdbgyuU7m36vYQB iZg4OOFri/S1ntANfErLEMZCISrJQhqqd4o5KLHGpgG4t3znQNRkglpD2B/F bm0FcdqjyRp6tJiivbsyddag0XNvUV3cQa1pwTP0f8RyIfAdEzFZhtliatPo kfsD7z8zKRniDrIdON3aJZ08yxSN78kexcIVCxUPXygJstB8SvjxEQbaTzJJ fqFDZspN0ENXHNWDGn1kfbxRs5iwaaquOAITxqyiwC35e8yUcUpWHF2o2+v+ FeUDvcX5PVJNoT6F2SeLwKuj2Ko6CpSxKoRN4skNCkdNlsgsggF+m1OlL0S2 2oNDQZNsdHYakWCnS3cB4sBaw6oN3D0h/kn1ULSDRJhYy3ED/JoYR49p6QmP Neyi1lLrrooyx1SEQc/khpKryobmIG0u/I8NYnAF1vAO8azEdOo5GGCDb43k eGuRVLtAVqxYIXTXg+LJBlHv9F7uuhueI/0VldT3Zp33r/qPTGL376gmHoLg 6781uJbHIrzD61/fPejReMJOkwgjTYqr0jSlWDglxhP4HkPX4Ybsc+fcsIZD 4T/xWnczEuMvlk3wzNYlmRzWIkeu3KoTA8IQ0eMpKHX1JYAa1MrSNfDYe0U4 Im/J7XcOsDVJ+Mx7rzeYIHAQWQsSNHY6BY5QeZIAUy6oaMdO3ps4tFlDlbQq VtKA7DKVKFC53T9bL0wtp3cW13Dycy3KX33h7k+Nrl7VchvK2sXiOd3716E2 4rdSFDGm7s7dUZfeJhWTYe+NcKRLq+s5gJLz69c6q78CJ1dIja+g9a5ECU/y vis4t4jfKw9dMiiKonalHtncYEQrKI6imguaKe1xD260UIVOPVqQL1C4VK41 IGVpadb7cLUGrUuTOpLRJc2amZzRSQXrHGfU08iHahrZ6p1u1h3zeEbldOK1 XqipQ9lQIlTs60t/0BwiZCHrJ3RfwegixkiTysTqr4adnw4/QzowaNnJ3y8v T69Gb5HcdZIvaZx1IdR1/sj56rryFnkHW5aaVMxBjFSaCymWbxG0vyXIn6fZ 5dTMFBvI/8yeXL3kOlZsJKmbvkVbx2k7k3ffD1D18IL1KnmysPT3QYKrKrel u2OcrydbnoEGX05oj9X/1iSYROnCNhN6/X8Q8PrCvzTtzmH7ZUXdH6Go+wpF Bz9C0cErFO3/CEX7r1DU+RGKOm03PMezQi0zkbg5ywT3vbLw7UwkaCO3omIU 6hW8mLEbYvghz745GBK/ibu50LZGuio86dO8VAO2GiGBwIgEur6+LfVSpZic EnasypgnXGrHdsdoVcM4XaKZNOqwJLjGSFBXlsCCYLef0dTU3N3SmxmGAuAE NZW5V//7daYwAlrpWXWzNDf0TIRIiBzdHrrDU4Ci4H9GVYqFFxcAAA==H4sIAFhAqmkAA7VZ3XLbuBW+51OgykzHmjFpW3acWN1u17HixFPH64mUpp1M pgORkIg1SXAB0IrW62fpTR9j77YP1u8AJCVqFe96f3IRSSRwcH6+851z4DAM AyttJoasN0kFOy3LTMbcSlWEl3wpNLvWyqpYZexKzJWV7hXbOb28vuqzixEb lyKWs3oLmynNLMScqcJYzWUhknWRK2E7Z+r0us/ULU4YTS7HvYBPp1rcQo0z 9fYlI/m9ALtwqF4OmSxmKggSFRc8h66J5jMbSmFnYay0wH+8DBObmZBnZRHu Pw1MNc2lMTjULkvsuHg5OQ+KKp8KPWQnJ08HQVUmEG+GgZoalQn3NYbeojCV GTKrKxHIUrtvxg7290/2B0Eph+wDTNhlZplrMTP4orSlbx8Dkjdkg/3Bcbh/ GMCWw4BrwYfs/cUkWCh9M9eqKoeMVA5uxBKPkmHAQkYm+8/Ta/oc/+PsBX2S Z+iTvBEEAa9sqrTbwWZVlnlfvOHawtFsrMpUCnYpikRoEzD8U3o+ZJN3IzbS wiSiYO8KCY8baZdMzdhExGmhMjVfutVNBCbvmvXuMQIphB2y1yLLU5XZ7/Ag Ygf77mUMUcPO8lglUGoU7h/sH5/UT6rCUhBfCZ3zwh8mci6zIcu98lHmtf7K VmHihUWJcIZ6I89SLQ3QV7DT3Pz4gzHrQuLm5Vc8N5UwJopVvuGlSapybthZ xMZxmsvENg7ihfzOgRMWnr5nr3k+rfS8Y/kLoTMoqdkE8H62Zvf64sZuAsrP 220j49X4KuWLMPVyuia/4damEjq///G/aSax/nExZX9mL7i+SXkFSLMLJKS0 lf1MpB9Y/MfGP1pw4a3biH1QKKy2sA2AZ2/Pz44Pj54h85HkBwP/5Nng6YCy iZf178P9gyEjBvC/Tw7aHYf1k6Pj/SEzt/E0CIhSuic8PxwcenmhjWuZz4+O jhEuJ+IJYxfhKFrRTlKYkCjM8Q9OUjE2Xb99GdJRJ08Ph87UsHnDWE21X7of 9G90NfYk+MtYc6TO+l4Q13MKSmptaYZ7e4vFItKzOBSJtEpHAMke2beHZ6SI D6TQUhh6PGzPh6JDp3G7ymn19cUQEY4Onh09f7a3ZpBb4WkOtBOnjuw8pBpu IoNbQb+IpbYt357vW1eK4oa9+vGHIlH/+w8vPrtuOwFsV3VL4sEBRydHR0N2 nKEQBWEYIosoWrENgi/+hJ8f4GuRfGTn/7pAEr8XzBeYhH14ADQfmVXsw5qH PwZUQwu1iEjEQmYZOPJGOHzMZMGzWqxBSSSl/vnmku3ISES7TIscclmPpPX6 EXT80qvWaHbqYsSuYKVBNenXPtllC4ETLbZOojUH9egIOhforXJRWJYKjqj9 haVqIWDBLr0Ncv6N0jX7lNxY0sqwlEMVkEnihDYSYVQqARvKPIhlS1WxEsVT 6L8FwbTfoGSXlZngRiAXi5nEUjlbW8p6byAxajDUAyW6R83vYLvaaw75mZCE ZAJzeN9sNDorwfXBmcpLlBBkaXvcztnTp0f9n7p/1CyYEAu4AFx7M53zbcpt V2/HFvCkYVMBVm7whN8zlWVqYaLg1DG578pqp7u14hO0SrC4hL/GInY8chgd U5DIuGeHgwHb6dHXsV1Cm1eVTAShJrgoGE9AI9ixy6RhvU6L12Oor1BOAomA Lunr1UQQcr5k0kKBGoqJwzJiGEtswT4E+Wst5w7GO10z+446qNHZ3lVSa7Rq F4PgrNIam92u36dxJUm/qncNgmuhUw4ediY8VpHfdjSS5rxuug2SuwGNA5MB Box75TOAgk+/rkfn4JIMaYYtVZb4njtwPTdFrwEa4ttrIvLTGPTofY6kYHGm jMiWiL9FbhMndGPbCfualj7mbb+/4cfPHryexw2z1VQ8ZGNvEZnZ8DMjTciN tHlNlxo7gHirrvGgALtS5flFkSQhnWBiXoDbS1gZZrQrNCKuNNz5meiSgM0A o1TfylggwRufwHEylxnXLuvEJ9uQ8wV6K5VULsP7f5RJv0J1D0HMP6yxf7p0 EYi2xG/diOF67exhU+tP5vzp5VHBqdDMzOvxkbCKtfi+/hjA1wJFx2FiVmk4 THvZtARECjQuCmAebMpkXmqALLDkP+I4UcTiQbzQg65/N0H7oDdaw0jOZ22L Nsnu91PAjZese9Z6Dv5eZ9HWbvSD3wzSDQZ9ZNI9lHHU26FbSahGP+lAMwge p5so+DSDURhH86pw++Dokpoc8pJifI7ZimEDzOZroj0YykZ0AkwQXtmkTQV/ +LiByw5c20f9LxKTUrvoQ7oWpLs7dzVyfx951zfPY07wZwnaXCJYeInC2UYS KULqUuUY+2fshSwSCAcj0TWF6TO0H46JMMvs1gfTGzQBRlU6pm4AvVNi0M1a Vx5Yj1TptRKvuUZLamHP38XSkKo0oZGqpw4Q4hPPSypXay6qQYYO81GVE7Kp c7u/d4arqeWORqVh7ThI0VhZ7Rqy2jmuxW0nNgd5N5E5d6HzBEcjmnd3q35r QDtCwPz+vu8VTkSZKc9TB9Eh6eNmSyiEQxcC7T4+R9wCGTx/IN4jF/ADOkE3 kvxsDFHNdxILlPlcIFMkmjT0YXxOQH8oBR9LIx0OOX1IwMY+6m55ptGfLH3n 2uiRUIGrw0XjOMEB6fhYcsCgc97pIHDo7rqJ5AMxc8CBKj06rrflaCARrS0W o1dHf3wrDaU2eVeLBoQGKO5YzgGdGSYW1wl1q9hKB2KvboNDx2gxxwDsEtIp g1GYOxc08m95Vom65b/lWjp1MlHMbRptmDzyNtcNotuI3j9WvT6dxDFK0EVr sksOcLlAucFvlQQZaD4neHivAsxnmSRrXgOpoK8icUmMM/yDBlykc7yWkoWw dP9ZU0Ami5ua4jry0Y9WaCChxfGlen99ekVBwLzt7J6oNg+3QXIrxv1x5FHV eIHiVLuwjTaZQe5oyJDGVhqnCYp0PZQtMQgVQRvinBd0G+jmMHwU4AXXWNQa tRBvTifHBokwsZbTFtcNxU02CWaLcZq6a/J/fUxNArmIwfjS5IbiqKqWsCCt FP7HWoq7/GkZhBgTI5/2bApcwYxWctx56cx0TqsJri4lfQ+ArVzfrPRmYmVm lOPvpR8bN/W6OL063dCJ3T1xqMdISi8dUyQ007q7EDcBE+cIulxsZtEeBftx HNG+AyJ6dd5BYN1e936m5L78hDaR/sywvtfd88Os71fCv2cXCY0h7cQ5Ft9W 1GDizVvhOIK+Y4uvK23i9rFg/9PxIf03a9L2+1Uh220uKwbYfTf0k9Vff6Mf oJI3pceeWGKWA0Thqr2lWFXRRAlPiZ5DncuIDmsgOtCQKqJxU9PLuIaB3gBq RV0v2/Zlsza1pxDe58LDZyrAfdIlIEGiMqtlwpDS0qQuOXVFPVgm3S0aJlWf gE2Rfl4X6U6dcT3glMc3ruTEN4VaZCJxTGXg5Krwf0kSCdxC13RuvvAnEA55 cYMT7t7SVdeYZ9/dw1PNn8bEp1JoSulbKRaU1A5lxD4Ns9eEDOWilXCXPz85 4Y1KQUgJe6GqmCdcajqJ/IF3L1BMx3G6QCOzrgDoUXCNNPQakB9nNMS/f4Xs UqVrcxvmMJ07klruS3Oj2Eh+c3NP4MOD+mb1XIF0rXRP66V0R6zYRJI9XRVm QiTkX7eS2mPybNS9L6svx2pPOTddFHGGTgMl7xJAqMDxPUa5WRcnWqOKzN0z r2612BcP3JIbWjenZXvU8g32nsjmjH9n9RlfkpZBJqjdZIQFuo8kZHk4GtcP FbBIJBFj7+r72caJBbeuMi1LODLLlgG4ssrc/O5uT0pQpoSdzWm7bOHuSLE1 FVk5qzLnN+2ucMhHqzwE5TKqKiVSBMWaoD/L+NzptnA0jEPcuBFXGUfPMa1s HVl3TRIYSxfM08bJvgfieGAs9OLIkFj4ie3/xo8wnykeAAA= --> </rfc>