<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4.4) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-chittapragada-netconf-https-notif-cbor-01" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.29.0 -->
  <front>
    <title abbrev="https-notif-cbor">CBOR Encoding for HTTPS-based Transport for YANG Notifications</title>
    <seriesInfo name="Internet-Draft" value="draft-chittapragada-netconf-https-notif-cbor-01"/>
    <author initials="B. M." surname="Chittapragada" fullname="Bharadwaja Meherrushi Chittapragada">
      <organization>National Institute of Technology Karnataka</organization>
      <address>
        <email>meherrushi2@gmail.com</email>
      </address>
    </author>
    <author initials="S." surname="Bhat" fullname="Siddharth Bhat">
      <organization>National Institute of Technology Karnataka</organization>
      <address>
        <email>siddharth.bhat10@gmail.com</email>
      </address>
    </author>
    <author initials="V. T." surname="Rao" fullname="Vartika T Rao">
      <organization>National Institute of Technology Karnataka</organization>
      <address>
        <email>vartikatrao@gmail.com</email>
      </address>
    </author>
    <author initials="H." surname="Arshad" fullname="Hayyan Arshad">
      <organization>National Institute of Technology Karnataka</organization>
      <address>
        <email>hayyanhamnah@gmail.com</email>
      </address>
    </author>
    <author initials="M. P." surname="Tahiliani" fullname="Mohit P. Tahiliani">
      <organization>National Institute of Technology Karnataka, Surathkal</organization>
      <address>
        <email>tahiliani@nitk.edu.in</email>
      </address>
    </author>
    <date year="2025" month="July" day="07"/>
    <area/>
    <workgroup>Network Configuration</workgroup>
    <keyword>cbor</keyword>
    <keyword>https</keyword>
    <keyword>yang</keyword>
    <abstract>
      <?line 62?>

<t>This document extends <xref target="I-D.draft-ietf-netconf-https-notif-15"/> by introducing CBOR encoding for YANG notifications over HTTPS in addition to the existing JSON and XML encoding schemes.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://MeherRushi.github.io/draft-chittapragada-netconf-https-notif-cbor/draft-chittapragada-netconf-https-notif-cbor.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-chittapragada-netconf-https-notif-cbor/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        Network Configuration  mailing list (<eref target="mailto:netconf@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/netconf/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/netconf/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/MeherRushi/draft-chittapragada-netconf-https-notif-cbor"/>.</t>
    </note>
  </front>
  <middle>
    <?line 67?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>This document introduces a CBOR encoding scheme for event notifications over HTTPS by using the framework proposed in <xref target="I-D.draft-ietf-netconf-https-notif-15"/> which supports transfer of YANG notifications over HTTPS using JSON and XML encoding schemes.</t>
      <t>In <xref target="I-D.draft-ietf-netconf-https-notif-15"/>, the capabilities HTTP-target resource allows a publisher to retrieve supported encoding formats via a GET request, while the relay-notification resource enables the publisher to send YANG notifications via POST requests. These requests and responses use different content types based on the selected encoding scheme. This document defines support for using CBOR encoding as mentioned in section 1 of <xref target="I-D.draft-ietf-netconf-https-notif-15"/></t>
      <t>CBOR offers an efficient and compact representation of YANG notifications.</t>
      <t>Examples of the GET and POST request and reply encoded in CBOR are also provided.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</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 in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <?line -18?>

</section>
    <section anchor="terminology">
      <name>Terminology</name>
      <t>This document uses the following terms defined in Section 2,3 and 4 of <xref target="I-D.draft-ietf-netconf-https-notif-15"/>:</t>
      <ul spacing="normal">
        <li>
          <t>Capabilities Resource</t>
        </li>
        <li>
          <t>Relay-Notification</t>
        </li>
        <li>
          <t>Event Notification</t>
        </li>
      </ul>
      <t>The following term(s) are defined in Subscription to YANG Notifications <xref target="RFC8639"/>:</t>
      <ul spacing="normal">
        <li>
          <t>Publisher</t>
        </li>
        <li>
          <t>Receiver</t>
        </li>
        <li>
          <t>Subscribed Notifications</t>
        </li>
      </ul>
      <t>The following term(s) are defined in Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR) <xref target="RFC9254"/>:</t>
      <ul spacing="normal">
        <li>
          <t>Diagnostic Notifications</t>
        </li>
        <li>
          <t>YANG Schema Item iDentifier (or "YANG SID" or simply "SID"): 63-bit unsigned integer used to identify different YANG items.</t>
        </li>
      </ul>
    </section>
    <section anchor="cbor-encoding-of-the-notifications">
      <name>CBOR Encoding of the notification(s)</name>
      <t>YANG notifications can be encoded in CBOR using Names or SIDs in keys. Notifications encoded using names is similar to JSON encoding as defined in Section 3.4 and 4.3 of <xref target="I-D.draft-ietf-netconf-https-notif-15"/>. Notification encoded using YANG-SIDs replaces the names of the keys of the CBOR encoded message with a 63 bit unsigned integer.  In this case, the term 'SID' is defined in Section 3.2 of <xref target="RFC9254"/>, and the keys of the encoded data use SID value as mentioned in 4.3.2 of this document.</t>
      <section anchor="capabilities-request">
        <name>Capabilities Request</name>
        <t>The publisher sends a request to the receiver to learn its capabilities. In the below example, the “Accept” states that the publisher wants to receive the capabilities response in CBOR but if not supported then in XML or JSON in that order.</t>
        <sourcecode type="http-request"><![CDATA[
GET /some/path/capabilities HTTP/1.1
   Host: example.com
   Accept: application/cbor, application/xml;0.9, application/json;q=0.5
]]></sourcecode>
      </section>
      <section anchor="capabilities-response">
        <name>Capabilities Response</name>
        <t>If the receiver is able to reply using “application/cbor” and assuming it is capable of receiving JSON, XML and CBOR encoded messages the response would look like this</t>
        <section anchor="cbor-using-names-as-keys">
          <name>CBOR using names as keys</name>
          <t>Diagnostic Notation:</t>
          <sourcecode type="http-message"><![CDATA[
   HTTP/1.1 200 OK
   Date: Tue, 4 March 2025 20:33:30 GMT
   Server: example-server
   Cache-Control: no-cache
   Content-Type: application/json
   {
   "receiver-capabilities": {
     "receiver-capability": [
       "urn:ietf:capability:https-notif-receiver:encoding:json",
       "urn:ietf:capability:https-notif-receiver:encoding:xml",
       "urn:ietf:capability:https-notif-receiver:encoding:cbor"
        ]
      }
   }
]]></sourcecode>
          <t>CBOR Encoding:</t>
          <artwork><![CDATA[
A1                                      # map(1)
   75                                   # text(21)
      72656365697665722D6361706162696C6974696573 # "receiver-capabilities"
   A1                                   # map(1)
      73                                # text(19)
         72656365697665722D6361706162696C697479 # "receiver-capability"
      83                                # array(3)
         78 36                          # text(54)
            75726E3A696574663A6361706162696C6974793A68747470732D6E6F7469662D72656365697665723A656E636F64696E673A6A736F6E # "urn:ietf:capability:https-notif-receiver:encoding:json"
         78 35                          # text(53)
            75726E3A696574663A6361706162696C6974793A68747470732D6E6F7469662D72656365697665723A656E636F64696E673A786D6C # "urn:ietf:capability:https-notif-receiver:encoding:xml"
         78 36                          # text(54)
            75726E3A696574663A6361706162696C6974793A68747470732D6E6F7469662D72656365697665723A656E636F64696E673A63626F72 # "urn:ietf:capability:https-notif-receiver:encoding:cbor"
]]></artwork>
        </section>
      </section>
      <section anchor="relay-notification-request">
        <name>Relay Notification request</name>
        <t>The publisher sends an HTTP POST request to the "relay-notification" resource on the receiver with the "Content-Type" header set to either "application/cbor" in case the receiver is CBOR capable and a body containing the notification encoded in CBOR.</t>
        <section anchor="cbor-encoding-using-names-as-keys">
          <name>CBOR encoding using names as keys</name>
          <sourcecode type="http-request"><![CDATA[
POST /some/path/relay-notification HTTP/1.1
   Host: example.com
   Content-Type: application/cbor
]]></sourcecode>
          <t>Diagnostic notation:</t>
          <sourcecode type="http-response"><![CDATA[
   {
     "ietf-https-notif:notification": {
       "eventTime": "2013-12-21T00:01:00Z",
       "example-mod:event" : {
         "event-class" : "fault",
         "reporting-entity" : { "card" : "Ethernet0" },
         "severity" : "major"
       }
     }
   }
]]></sourcecode>
          <t>Cbor Encoding:</t>
          <artwork><![CDATA[
A1                                      # map(1)
   78 1D                                # text(29)
      696574662D68747470732D6E6F7469663A6E6F74696669636174696F6E # "ietf-https-notif:notification"
   A2                                   # map(2)
      69                                # text(9)
         6576656E7454696D65             # "eventTime"
      74                                # text(20)
         323031332D31322D32315430303A30313A30305A # "2013-12-21T00:01:00Z"
      71                                # text(17)
         6578616D706C652D6D6F643A6576656E74 # "example-mod:event"
      A3                                # map(3)
         68                             # text(8)
            7365766572697479            # "severity"
         65                             # text(5)
            6D616A6F72                  # "major"
         6B                             # text(11)
            6576656E742D636C617373      # "event-class"
         65                             # text(5)
            6661756C74                  # "fault"
         70                             # text(16)
            7265706F7274696E672D656E74697479 # "reporting-entity"
         A1                             # map(1)
            64                          # text(4)
               63617264                 # "card"
            69                          # text(9)
               45746865726E657430       # "Ethernet0"
]]></artwork>
        </section>
        <section anchor="cbor-encoding-using-sids-as-keys">
          <name>CBOR encoding using SIDs as keys</name>
          <t>Diagnostic Notation:</t>
          <sourcecode type="http-response"><![CDATA[
   {
    2601: {
       1: "2013-12-21T00:01:00Z",
       "example-mod:event" : {
         "event-class" : "fault",
         "reporting-entity" : { "card" : "Ethernet0" },
         "severity" : "major"
       }
     }
   }
]]></sourcecode>
          <t>The above is assuming the YANG module for event notifications has a corresponding .sid file with these entries</t>
          <artwork><![CDATA[
"item": [
      {
        "namespace": "module",
        "identifier": "ietf-notification",
        "sid": "2600"
      },
      {
        "namespace": "data",
        "identifier": "/ietf-notification:notification",
        "sid": "2601"
      },
      {
        "namespace": "data",
        "identifier": "/ietf-notification:notification/eventTime",
        "sid": "2602"
      }
    ]
]]></artwork>
          <t>CBOR Encoding:</t>
          <artwork><![CDATA[
A1                                      # map(1)
   19 0A28                              # unsigned(2600)
   A2                                   # map(2)
      01                                # unsigned(1)
      74                                # text(20)
         323031332D31322D32315430303A30313A30305A # "2013-12-21T00:01:00Z"
      71                                # text(17)
         6578616D706C652D6D6F643A6576656E74 # "example-mod:event"
      A3                                # map(3)
         68                             # text(8)
            7365766572697479            # "severity"
         65                             # text(5)
            6D616A6F72                  # "major"
         6B                             # text(11)
            6576656E742D636C617373      # "event-class"
         65                             # text(5)
            6661756C74                  # "fault"
         70                             # text(16)
            7265706F7274696E672D656E74697479 # "reporting-entity"
         A1                             # map(1)
            64                          # text(4)
               63617264                 # "card"
            69                          # text(9)
               45746865726E657430       # "Ethernet0"
]]></artwork>
        </section>
      </section>
      <section anchor="relay-notification-response">
        <name>Relay Notification Response</name>
        <t>The response on success is  "204 (No Content)". In case of corrupted or malformed event, the response is an appropriate HTTP error response.</t>
      </section>
    </section>
    <section anchor="scope-of-experimentation">
      <name>Scope of Experimentation</name>
      <t>CBOR encoding may be tested against JSON and XML to evaluate requests per second, data transfer rate, and overall network efficiency.</t>
      <t>Bandwidth constraints can be applied using traffic control to analyze CBOR encoding efficiency under different network conditions.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>Addition of the CBOR encoding introduces no specific security exposures or risks other that the ones mentioned in <xref target="RFC9254"/> and <xref target="I-D.draft-ietf-netconf-https-notif-15"/> (An HTTPS-based Transport for YANG Notifications)</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document requests the the IANA registry to include an additional entry to the proposed initial assignments in the “Capabilities for HTTPS Notification Receivers” registry within the YANG Notifications registry group(defined in <xref target="RFC3553"/>) as requested in the draft <xref target="I-D.ietf-netconf-http-client-server"/>. The following entry is added :</t>
      <artwork><![CDATA[
Record:
   URN:         urn:ietf:params:yang-notif:https-capability:encoding:cbor
   Reference:   RFC XXXX:An HTTPS-based Transport for YANG Notifications
   Description: Identifies support for CBOR-encoded notifications.
]]></artwork>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="I-D.draft-ietf-netconf-https-notif-15">
          <front>
            <title>An HTTPS-based Transport for YANG Notifications</title>
            <author fullname="Mahesh Jethanandani" initials="M." surname="Jethanandani">
              <organization>Kloud Services</organization>
            </author>
            <author fullname="Kent Watsen" initials="K." surname="Watsen">
              <organization>Watsen Networks</organization>
            </author>
            <date day="1" month="February" year="2024"/>
            <abstract>
              <t>   This document defines a protocol for sending asynchronous event
   notifications similar to notifications defined in RFC 5277, but over
   HTTPS.  YANG modules for configuring publishers are also defined.
   Examples are provided illustrating how to configure various
   publishers.

   This document requires that the publisher is a "server" (e.g., a
   NETCONF or RESTCONF server), but does not assume that the receiver is
   a server.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-netconf-https-notif-15"/>
        </reference>
        <reference anchor="RFC8949">
          <front>
            <title>Concise Binary Object Representation (CBOR)</title>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <date month="December" year="2020"/>
            <abstract>
              <t>The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t>
              <t>This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="94"/>
          <seriesInfo name="RFC" value="8949"/>
          <seriesInfo name="DOI" value="10.17487/RFC8949"/>
        </reference>
        <reference anchor="RFC9254">
          <front>
            <title>Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR)</title>
            <author fullname="M. Veillette" initials="M." role="editor" surname="Veillette"/>
            <author fullname="I. Petrov" initials="I." role="editor" surname="Petrov"/>
            <author fullname="A. Pelov" initials="A." surname="Pelov"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <author fullname="M. Richardson" initials="M." surname="Richardson"/>
            <date month="July" year="2022"/>
            <abstract>
              <t>YANG (RFC 7950) is a data modeling language used to model configuration data, state data, parameters and results of Remote Procedure Call (RPC) operations or actions, and notifications.</t>
              <t>This document defines encoding rules for YANG in the Concise Binary Object Representation (CBOR) (RFC 8949).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9254"/>
          <seriesInfo name="DOI" value="10.17487/RFC9254"/>
        </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="RFC8639">
          <front>
            <title>Subscription to YANG Notifications</title>
            <author fullname="E. Voit" initials="E." surname="Voit"/>
            <author fullname="A. Clemm" initials="A." surname="Clemm"/>
            <author fullname="A. Gonzalez Prieto" initials="A." surname="Gonzalez Prieto"/>
            <author fullname="E. Nilsen-Nygaard" initials="E." surname="Nilsen-Nygaard"/>
            <author fullname="A. Tripathy" initials="A." surname="Tripathy"/>
            <date month="September" year="2019"/>
            <abstract>
              <t>This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request and receive a continuous, customized feed of publisher-generated information.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8639"/>
          <seriesInfo name="DOI" value="10.17487/RFC8639"/>
        </reference>
        <reference anchor="I-D.ietf-netconf-http-client-server">
          <front>
            <title>YANG Groupings for HTTP Clients and HTTP Servers</title>
            <author fullname="Kent Watsen" initials="K." surname="Watsen">
              <organization>Watsen Networks</organization>
            </author>
            <date day="6" month="June" year="2025"/>
            <abstract>
              <t>   This document primarily presents two YANG modules: the first defines
   a minimal grouping for configuring an HTTP client, and the second
   defines a minimal grouping for configuring an HTTP server.  It is
   intended that these groupings will be used to help define the
   configuration for simple HTTP-based protocols (not for complete web
   servers or browsers).  This document additionally presents a third
   YANG module, to define a grouping for URIs.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-netconf-http-client-server-28"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC3553">
          <front>
            <title>An IETF URN Sub-namespace for Registered Protocol Parameters</title>
            <author fullname="M. Mealling" initials="M." surname="Mealling"/>
            <author fullname="L. Masinter" initials="L." surname="Masinter"/>
            <author fullname="T. Hardie" initials="T." surname="Hardie"/>
            <author fullname="G. Klyne" initials="G." surname="Klyne"/>
            <date month="June" year="2003"/>
            <abstract>
              <t>This document describes a new sub-delegation for the 'ietf' URN namespace for registered protocol items. The 'ietf' URN namespace is defined in RFC 2648 as a root for persistent URIs that refer to IETF- defined resources. 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="73"/>
          <seriesInfo name="RFC" value="3553"/>
          <seriesInfo name="DOI" value="10.17487/RFC3553"/>
        </reference>
      </references>
    </references>
    <?line 340?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>The authors acknowlegde the support of Kent Watsen and Mahesh Jethanandani, the authors of <xref target="I-D.draft-ietf-netconf-https-notif-15"/> for their guidance and support provided to draft this document.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+1a63LbNhb+z6fA0j9q71iy7rbZq2w5jdvYztpKt91Of0Ak
JCGmSJYg7Wgz7vRBujP7LPsofZL9DkBSpMQkctLpzO7EMxZJAAfngnPDARqN
hpXIxBcOs09Prq7ZWeCGngxmbBrG7Ol4/PymMeFKeGwc80BFYZzonh+Gl1+z
yzCRU+nyRIaBsi0+mcTiDhPNkyRSjYB6G+4kjG0LY8QsjJcOU4lnWV7oBnwB
nF7Mp0nDncsk4VHMZ9zjjUAkbhhMG+uzNFptS6WThVQK+JJlBPjzs/ETxnYY
91UIxDLwRCTwEyT2PrOFJ5Mwltynj/PhCR4g3T6/Hj+xrSBdTETsWB5Icyxg
VCJQqXJYEqfCAhtdi8eCY1bbug/j21kcphG+LkVCn+wUNMpZGmvubetWLNHs
ORZrMKKWnpoDelnyYGZZdyJIgYqxd0zFmGHOptcFlz5eM6F8JUUybYbxjLp4
7M5zaTsHBzSSmuSdaObDDqjhYBKH90ocZHMcEOxMJvN0AugLMRfxdarm8uAx
i0Fz+JCcSkoUrOZqmvmbMnzUrI8a3JwnC9+2LJ4m8zAmuTaY0aqTOY+5d89f
cqZJiokkdlqeFaMZE0a4i2JM56sZNTXdcKEHyAD6cNJkF80aaIjXYZd6zbjP
zgMFO0oTwcIpGwt3HoR+OFuyb3kc8ITfcqtE4I30PNCYzInUpEyLynuaE/S0
W3UE3TRXYB9AxHdAI285G7NrHpZpuDMdSczDOvTfNdm4WcB8AAFP+RKGwYax
mnOvTMBcd8z5IuDzOgqeNstAH0DBRYhVZc/BEJ9LX/JAlslI8savApncNoWX
NmWwogJKsQH5SFr22Q1Z/fyW+5YVhPECkHfkIs4bo6axBbLkWhNo9zHu+snp
0XHv2Lwdd/o9x7JkMC3NhPZuv99Fu9VoNBifKKyrm1jWeC4VgyNOF/CWTLxK
4DcVe/36L1vhfnhgkyXkkMShl7oUL3T0EOXooWNEUI4RLLwTWVQBLOMeHDTa
WRKyZC5AhITAAP3NzdUl44HHvr94tppTuXOxEKqZsbKAqfjCsnYgZ0MGzbXO
WE6iUIyv0Wjm06SKOxr7RlrBaqoIhKicxtAd7bejOIxCio3g5RGCu59Ld85U
GlE0VYg3CKxT4IKSvF1khoZ3Cuf8MdTsa55cHvEJ9DiRkBMhayQ8nomExUKF
aewKRFgfQQQyjNKJLxU8Jq1aLJJYQng5N5BFWQWghYrdSQ6wr8/GGP1zioix
TxLwhUYcC58vG2WOVyhFwCc+6KFxFayI1F6dqAjT86ubApGCec6FEsW3Fhvm
jyjaK8hTME9OIXtafYgnoScFX8VM0kO6CexK+MKtMGfETfOXlc0TUxkAOJOG
Vi2zaFXN44rReBBtlEcJrbusTTqw/dpZlp42JA6INyamEIYkSohR+MwIpg6G
I/CMViPfWjWD3py94ouI5I0BxDStGE1TlmgmwMhfGmYM+ZoKJEs6DSOruJPo
IVXcodzmzrBqpD8iEWmrV2SqgiFxYpQ5KeQiL27GlKrRk11e6ffrs7+9OL8+
G9H7zdPhs2fFi5WNuHl69eLZaPW2gjy9urg4uxwZYLSySpNlXwx/QA9RZV89
H59fXQ6f2cRPUllUYgxKNxHkS0QMWZImcGV5QrmxnBgZnJw+/8+/2z1aPbjc
Trt9DEs3H0ftw542exEYbGEA+ZlPCHpp8SgSPNYe0ffJFmUCSe6Tmqh5eB8w
6L2AOP/6I0nmJ4d9NnGjdu+LrIEYrjTmMqs0aplttmwAGyHWNNWgKaRZaV+T
dJXe4Q+V71zupcbPvvRhRKzRPvryC61CYxEvpAmd6949VZl/mIbkn7SLxmiV
WaJemZvMuDr7XS393uOMzKGEARnDadlFXmc+Kuu71l6svB3KOs50XKl2jDfI
3VV7WsvKRKcTUq4oD4+b+61cuQbd4xWRz3M3WRDmCuQB+Wc2K6lsZa4tiSr2
hhDgCAkM8icPntFj98j2DYnSOExYvSvhXU9kwOMlu5q8xCKAmooj2iW/sZfx
QcnLio+R5LMgRDLgrhOquzWqG3LBnJ0nYsHkiHzMVCI+7NIWzww4H9m04VNy
QQ7Lpu89hw26jQmyvjRQcmYYw95UkKPGB0QtPT3XshQaDGtApOMrebXKVjlz
mGWHCulZVk2IcuGlJ2LDeZogcYnEQhHFoFRRH3wjYlh12XNQAxJoEJgEmKTt
HzGgE4RyrKkxhm6zZ4yh2X2cOVTJWaOGGG5o4ilGcDczTkNkJiXiKX9fRUVM
gTGKz4RRJo5lYnXL1GRI94yHdhGiTfpC+so+AeJPSBS17HYyNgtVM654naKc
GI/Um/IDTIoNkZ+KjaAN0ZlZK+ECCrKzs+4sdOw0RrZKZJROuHkRWrMkOM5M
lr59hIUAiqcqCVrTSEBAkWCvyJp13DaS+P3X34auK6Lk91//xVRCO3S082Qt
ibrnAWWeYY5tMwnMs6RCRScpkukpqXMp2QNYQCMoFYXeas3TLgAYEdOxXJb1
yy+/6EpII2PUosTiQIULcRBh73OwkXsetJttsvOnIVUXMvbyHaDhzmGImX6m
hAdUDdivtLxa+J+2msfVxpcqDD79+fNWs0801a2TYRlO5nxaXQssMOWiRmLk
TIy+Q9rrdJDcSbG4UumCxkCHZbZ+vt4ImknzTH5fy44g6oxBZWRka3Efpr7H
/DC8Zb68FVrziI+dshcx1gZtJb22rKor1YQ6pUXJEGl5Z7JnnVaLXX1LTSMq
jrFxCu3qsQsqJqGz08eP0+063Rb7+mJM425EDDEVi9VQ+pt6TjncdAPxANsw
7KmDsOFSi+4yCXdjrKtd6ytFI17Tj52vQqOsKbZjemv7l+j90fSiP40Dh3ya
s+p3ym4th3dyn+kQfiSI7z8B9O+D4PMSm/n7KXt7sPSPVt5KBDILag3bbKu/
Hbbg0W57j6Y77G8FkIhXyW7HgBBUZ9AfdPF/fDgY9A87nRG+2oetQXvQGRwP
TtHew7N/2AXsGxZQW/M2FJfJJdzdLcltH+8VItyK4sPjemqX+VIcbYGaxzFf
7nbLqI9Yd/BOavu9EghBgcjBWXeoxdgbDPBWQzBaj/DsHbYOu2DpbPBEC37Q
Ga0zjJF99HcHTwY04mxwiJbhIX2fEdvvaSVVNt+iTDmb3T+fzcOjwWhw+n5M
kiX/TyxlF3M9Oey8H5fG32jHQmHRbGiqmV781iwm0NGjWivIEhp7s8Zjr4o8
WYWliLQ6+9Ng5fBgYwvMPY1OzyswCl/2evTV23fKCzfCt/aXeRTWAZpNQm+p
qz5cBnlxL6hLbrMUqFkKtUV6XRtzN1IeLZdSzlNT9npn5vPmcKnPm/TilYJ9
UBPs80SiiK0ITjrbL2mHU1moIspipC6SjuVCoNXutNrdRrvT6LTHrZbTajut
1j9KIS9PBBah52g4m5WmyidruD7yJOqypzz1k9UEOqxTkgnpNijrhhOmGZjt
8tjTEGekAtimtGz2UIZTmDrOxtsL/rIUSR+s1SOPo5DdHxJHj1h79G4AE0eL
wJR7BNh7re3Drot3/JPXoPfMZb996XR87WzNRmdF05ZslMMr2BiQUzrs9YnA
0aC/BlHSnjyO97YVV6uEqNvptrrtLqSEX0RxfLf7PbS1ukPdQ7+t/pBQ1upo
jv2da5xnEYdVNo/gtUfw3aeDPlZqRD6Y/HHOvmZ1Q/mzGYZb5A+0FuUYOTja
hsqjtYjTNRQhcpi8pgKxMpEyZ9ug6VfRgP32YKjDTg3EmvFh+Mk2ONrtNSSF
bHXOdgob6OY54E7VkXwoOwPM3R+c1mnmTu6iSslAayt2BmtLg2AO9YHMDrPg
DbY0e+UUdM31rWZ4h29ay5Uzvt5iaRmVaxkLAZGz6dSA7mQ+uIriLU6jxl2Y
vx75viOtpWfkB7utAqLk3fPNen3k1dWmbTe7m/GvM4BbWAWm9v9RZKM8jU/C
O6GrF3k5gpIcXZcE/an/5tPPOafalBvGRmZa4k0lPTalo7s8S1NUMaMjQJP0
WDYVSUub75VcbJ0iRdzV2YNBXhKKnVVdpYip35Qgy9GsNBRU6Axk0Grl/Bdi
ehNCque9Gd3BBj7n3cjbfw7yg1XgrCWjU5Chnz/9seWB9jFrDTtvD0EAyKu0
u7Qoe++bebS2iMkFplU94GMeUYf0Yx7xMY/4mEfU5BF1xY1V6X9crrejR6Wu
K5Q+YiNH0GO7l2G+Fd+z9VGMrjeEUx0s04iORRBTF9ynCzB0Z4QUa79ayJe6
ZII9fBxGseSJMOUTEccAzUeZCxQ3bhjp6c9eRTC2RX58mvn4Ih1agKcJHYUp
fT1hxmWgkuplISqc0FkW4SuuxES6quIixO+bU6/iPlKMcdmFBZg5XU0Isgur
+T0TdwkaTzDiXnpICOgSLaBlkBQHnbpMUZwPopMgddElDn0iiAfcX/5TrOV2
KwRw+FT3WZ3F5jQQxTK/u0JyEm5KvogWB9FRxPmJ8TC/ZbZx6KiPZ1b3w4KQ
qUi4pBUkETObeBWFKo3NuWws1S1edO2pOFUL6cZP5WSwfMyo5feIy2G7w+BR
16739AW44eVwg+/qTYlivfV5Kf41TCxmEku21OfegeunntCKmYmM+zq9W+al
vNKFN/SjF84S0ZgQqPzo//dff6ucqhX3yNctztTmFB2YFWRQXpnNU3PjoRim
L1Dvls55X7/O7jk+POzRbiDj1nTSbFr0+TpsrADcPt2ayo6t6JC7eh/CCIGM
1qN6YJZPgQVz45uxF9eXTuGOivJrxGO+UA7d/s4KNGa5S2XZSgWWZroWWs9d
QfOBKfY9/pxHKoU+uhPFBRKHnecZZ/VuGplCI69yrt0H096S7llOuHtLSjZ0
b4Pw3hfeTK+39doxV+iF9zlCmq+E/ZBtOvSFbAgrA5h5RuNyzLDDb0kl/84T
JQJtIBcce4k5+0bAqgI08EAaj5nP9ag7Cpo3QMuYzVKJyVxT8s0JyG+okVob
xVg7wv8vGeK/ohYxAAA=

-->

</rfc>
