<?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.6.35 (Ruby 3.0.2) -->
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-toutain-schc-sid-allocation-01" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.17.4 -->
  <front>
    <title abbrev="SCHC Sid Allocation">SCHC Sid Allocation</title>
    <seriesInfo name="Internet-Draft" value="draft-toutain-schc-sid-allocation-01"/>
    <author initials="A." surname="Minaburo" fullname="Ana Minaburo">
      <organization>Consultant</organization>
      <address>
        <postal>
          <street>Rue de Rennes</street>
          <city>35510 Cesson-Sevigne</city>
          <country>France</country>
        </postal>
        <email>anaminaburo@gmail.com</email>
      </address>
    </author>
    <author initials="L." surname="Toutain" fullname="Laurent Toutain">
      <organization>Institut MINES TELECOM; IMT Atlantique</organization>
      <address>
        <postal>
          <street>2 rue de la Chataigneraie</street>
          <street>CS 17607</street>
          <city>35576 Cesson-Sevigne Cedex</city>
          <country>France</country>
        </postal>
        <email>Laurent.Toutain@imt-atlantique.fr</email>
      </address>
    </author>
    <date year="2023" month="July" day="07"/>
    <workgroup>schc Working Group</workgroup>
    <abstract>
      <?line 46?>

<t>YANG SID (Schema Item iDentifier) is a method to identify YANG items in constrained environments. The YANG Data Model for SCHC needs to use smaller values and reduce the distance between two sections to minimize deltas' size and assure header compression performance. Keeping compact values for SCHC can be done when data and identity are differentiated.</t>
    </abstract>
  </front>
  <middle>
    <?line 50?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>RFC9363 defines a YANG Data Model for SCHC rules. <xref target="I-D.ietf-core-sid"/> specifies the process for SID allocation and management. This document discuss of the SID allocation for RFC9363 to minimize the rule representation.</t>
    </section>
    <section anchor="schc-yang-data-model">
      <name>SCHC YANG Data Model</name>
      <t>The version @2023-01-18 of the SCHC YANG Data Model published in the RFC 9363 contains 136 SIDs (92 for identities, 2 for features and 42 for data). <xref target="I-D.ietf-core-sid"/> indicates that the SID range for the YANG Data Model specified in RFC is between 1000 and 59 000 and that the maximum request pool SHOULD NOT exceed 1000. The draft also gives some pre allocated values.</t>
      <t>Since SIDs will be used either to represent unique identity contained
in the data model and also leaves (data) forming this data model, it could
be wise to distinguish between identifiers and data.</t>
      <t>Data structures are delta encoded and included as a CBOR element, 
the size depends on the value. Deltas between -24 and +23 are encoded 
on a single byte. Deltas between -256 and +255 use 2 bytes and larger 
values corresponding to the RFC SID range will be encoded into 3 bytes. 
To optimize the CORECONF representation delta should be smaller as possible
for the more frequent leaves.</t>
      <t>On the other hand identities are included in the CORECONF
representation and for the RFC SID range the size is constant and equal 
to 3 bytes.</t>
      <section anchor="example">
        <name>Example</name>
        <figure anchor="Fig-sid">
          <artwork><![CDATA[
CORECONF 

{5095: {1: [{4: 
        [{1: 5015, 
          5: 5018, 
          6: 5068, 
          7: 4, 
          8: 1, 
          9: 5083, 
          13: [{1: 0, 2: h'06'}]}, 
         {1: 5015, 
          5: 5018, 
          6: 2000003, 
          7: 8, 
          8: 1, 
          9: 5083, 
          13: [{1: 0, 2: h'00'}]}]
    }]}
}


RESTCONF

{"ietf-schc:schc": {"rule": [{"entry": 
             [{"comp-decomp-action": "ietf-schc:cda-not-sent",
               "direction-indicator": "ietf-schc:di-bidirectional",
               "field-id": "ietf-schc:fid-ipv6-version",
               "field-length": 4,
               "field-position": 1,
               "matching-operator": "ietf-schc:mo-equal",
               "target-value": [{"index": 0, "value": "Bg=="}]},
              {"comp-decomp-action": "ietf-schc:cda-not-sent",
               "direction-indicator": "ietf-schc:di-bidirectional",
               "field-id": "ietf-schc-oam:fid-icmpv6-type",
               "field-length": 8,
               "field-position": 1,
               "matching-operator": "ietf-schc:mo-equal",
               "target-value": [{"index": 0, "value": "gA=="}]} ]
         }]}
    }

]]></artwork>
        </figure>
        <t>The example in <xref target="Fig-sid"/> gives a CORECONF structure transposed the CBOR diagnostic notation and its equivalent in RESTCONF with JSON. For readability and compactness, this example is edited and do not encode a full rule as defined in RFC9363.</t>
        <t>The default SID numbering produced by pyang is used, starting from 5000 for SCHC Data Model defined in RFC9363 and 2000000 for an experimental module for OAM.</t>
        <t>We can see the delta encoding. The first SID 5095 represents "ietf-schc:schc". "/ietf-schc:schc/rule" which is coded with a +1 since SID 5096 has been assigned. "/ietf-schc:schc/rule/entry" is coded with a delta of 4. Then 
a list of Field Description follows. +1 represents the leaf "ietf-schc:schc/rule/entry/comp-decomp-action" and the
value assigned to that key contains the SID of "ietf-schc:cda-not-sent" identity.</t>
        <t>Note that the second element contains a "field-id" belonging to the "ietf-schc-oam" module and the associate SID is 2000003.</t>
      </section>
    </section>
    <section anchor="recommendation-for-sid-values">
      <name>Recommendation for SID values</name>
      <t>The SCHC YANG Data Model defined in RFC 9363 will probably be augmented, to include for instance access control
data. To keep a compact representation, delta values must be kept as small as possible. The LPWAN working group should not use the automatic SID numbering and provide a more optimal allocation scheme for augmentation of the SCHC YANG Data Model.</t>
      <t>A first recommendation is to avoid merging data and identity in order to limit the delta encoding. The distance between these two sections can be 255 SID to allow deltas on 2 bytes.</t>
      <t>The second recommendation is to leave some unused SID around SCHC rules to allow augmentation.</t>
    </section>
    <section anchor="sid-value-impact">
      <name>SID value impact</name>
      <t>To study the impact of SIDs size and delta size, we will take three scenarii, which cover the original Data Model defined in <xref target="RFC9363"/> and some augmentations, rules regarding these scenarii are listed in the annex:</t>
      <ul spacing="normal">
        <li>sor-9363 contains only parameters defined in <xref target="RFC9363"/> with IPv6, UDP and CoAP fields. This is a set of 7 rules: 2 for compression and 5 for fragmentation.</li>
        <li>sor-oam adds to the previous set of rules, a compression rule for ICMP messages. This add new identities for ICMPv6 fields, but the rule structure is not modified.</li>
        <li>sor-oam+ac augments to the previous set of rule with access control nodes. This requires an augmentation with Access Control DM and includes new nodes in the rule Data Model.</li>
      </ul>
      <t>For this three group of Set of Rule, we applied four different allocation methods for the SIDs:</t>
      <ul spacing="normal">
        <li>SIDs are located in the million range for the 3 YANG modules (1000 000 for basic model based on RFC9363, 2 000 000 for OAM and 3 000 000 for Access Control),</li>
        <li>SIDs are located in the IETF range (5000:500, 5500:50, 6000:50) and in the alphabetical order,</li>
        <li>SIDs are manually allocated regarding their frequency occurrences in the rule,</li>
        <li>tens of the main used SID for RFC9363 are allocated in the IESG range (CDA: compute, LSB, Match Mapping, not sent, value-send, MO: equal, ignore, match, MSB, and bidirectional).</li>
      </ul>
      <t>The following table shows the results:</t>
      <figure anchor="Fig-meas">
        <name>Size in Bytes SID allocations strategies</name>
        <artwork><![CDATA[
  +------------+------------+------------+------------+------------+--------+
  |            |   million  |  IETF      |  IETF      |  IESG      |  JSON  |
  |            |            |  separate  |  grouped   |  (dream)   |        |
  +------------+------------+------------+------------+------------+--------+
  | sor-9363   | 2194       | 1740 (-454)| 1721 (-19) | 1586 (-135)| 15388  |
  +------------+------------+------------+------------+------------+--------+
  | sor-oam    | 2841       | 2265 (-576)| 2243 (-22) | 2064 (-179)| 19871  |
  +------------+------------+------------+------------+------------+--------+
  | sor-oam+ac | 2925       | 2321 (-604)| 2271 (-50) | 2092 (-179)| 20686  |’
  +------------+------------+------------+------------+------------+--------+ 

]]></artwork>
      </figure>
      <t>The most important result, is the factor 10 between CBOR and JSON (without indentation) size which proves the efficiency of encoding. 2 kilo-byte of information to represent 8 rules (3 compression and 5 fragmentation rules).</t>
      <t>The IETF-grouped has a impact on the rule size, even when no augmentation is perform. This is the case for rfc9363 compatible rules and OAM addition. Figure <xref target="Fig-sid-alloc"/> shows the alphabetical order allocation with pyang.</t>
      <figure anchor="Fig-sid-alloc">
        <name>Alphabetical order of SIDs</name>
        <artwork><![CDATA[
5095       data /ietf-schc:schc
5096       data /ietf-schc:schc/rule
5097       data /ietf-schc:schc/rule/ack-behavior
5098       data /ietf-schc:schc/rule/direction
5099       data /ietf-schc:schc/rule/dtag-size
5100       data /ietf-schc:schc/rule/entry
5101       data /ietf-schc:schc/rule/entry/comp-decomp-action
5102       data /ietf-schc:schc/rule/entry/comp-decomp-action-value
5103       data /ietf-schc:schc/rule/entry/comp-decomp-action-value/index
5104       data /ietf-schc:schc/rule/entry/comp-decomp-action-value/value
5105       data /ietf-schc:schc/rule/entry/direction-indicator
5106       data /ietf-schc:schc/rule/entry/field-id
5107       data /ietf-schc:schc/rule/entry/field-length
5108       data /ietf-schc:schc/rule/entry/field-position
5109       data /ietf-schc:schc/rule/entry/matching-operator
5110       data /ietf-schc:schc/rule/entry/matching-operator-value
5111       data /ietf-schc:schc/rule/entry/matching-operator-value/index
5112       data /ietf-schc:schc/rule/entry/matching-operator-value/value
5113       data /ietf-schc:schc/rule/entry/target-value
5114       data /ietf-schc:schc/rule/entry/target-value/index
5115       data /ietf-schc:schc/rule/entry/target-value/value
5116       data /ietf-schc:schc/rule/fcn-size
5117       data /ietf-schc:schc/rule/fragmentation-mode
5118       data /ietf-schc:schc/rule/inactivity-timer
------ 23 delta limit
5119       data /ietf-schc:schc/rule/inactivity-timer/ticks-duration
5120       data /ietf-schc:schc/rule/inactivity-timer/ticks-numbers
5121       data /ietf-schc:schc/rule/l2-word-size
5122       data /ietf-schc:schc/rule/max-ack-requests
5123       data /ietf-schc:schc/rule/max-interleaved-frames
5124       data /ietf-schc:schc/rule/maximum-packet-size
5125       data /ietf-schc:schc/rule/rcs-algorithm
5126       data /ietf-schc:schc/rule/retransmission-timer
5127       data /ietf-schc:schc/rule/retransmission-timer/ticks-duration
5128       data /ietf-schc:schc/rule/retransmission-timer/ticks-numbers
5129       data /ietf-schc:schc/rule/rule-id-length
5130       data /ietf-schc:schc/rule/rule-id-value
5131       data /ietf-schc:schc/rule/rule-nature
5132       data /ietf-schc:schc/rule/tile-in-all-1
5133       data /ietf-schc:schc/rule/tile-size
5134       data /ietf-schc:schc/rule/w-size
5135       data /ietf-schc:schc/rule/window-size
]]></artwork>
      </figure>
      <t>"Rule-id-value", "rule-id-length", "rule-nature" present in all rules have a delta higher than 23. On the other hand, other elements such are matching-operator-value or comp-decomp-action-value which are not present in all rules have a smaller delta. Figure {#Allocation} gives the manual SID allocation used in this document. This lead to a reduction of about 20 bytes (a mean of 5 bytes for the 8 rules in the example) when no augmentation is perform. In case of augmentation with the last example including access control, this leads to 50 bytes.</t>
      <t>Manual allocation allows also to use some other space, the last scenario takes 10 values (1%) from the IESG space for the most frequent identity.</t>
      <section anchor="administrative-process">
        <name>Administrative process</name>
        <t>The allocation process proposed in <xref target="I-D.ietf-core-sid"/> is slightly enhanced:</t>
        <ul spacing="normal">
          <li>the SCHC WG requests IANA for a larger pool of SIDs than originally needed for a single Data Model (for instance 500 SIDs)</li>
          <li>the SCHC WG MAY request IESG review for a small amount of SIDs</li>
          <li>the WG manages the space as presented in <xref target="Allocation"/>.</li>
          <li>If a module is validated by the WG and request a WG allocation, the SID are allocated in the space and a sid file is issue for this module.</li>
        </ul>
        <t>The result is a better allocation of the space, <xref target="I-D.ietf-core-sid"/> proposes a minimum of 50 SIDs per module, but looking at the existing models, the effective number is smaller. Using a common pool, allows a better utilization.</t>
      </section>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <reference anchor="RFC8824">
        <front>
          <title>Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)</title>
          <author fullname="A. Minaburo" initials="A." surname="Minaburo"/>
          <author fullname="L. Toutain" initials="L." surname="Toutain"/>
          <author fullname="R. Andreasen" initials="R." surname="Andreasen"/>
          <date month="June" year="2021"/>
          <abstract>
            <t>This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for Constrained Devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from IPv6 and UDP, since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP message format is asymmetric: the request messages have a header format different from the format in the response messages. This specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8824"/>
        <seriesInfo name="DOI" value="10.17487/RFC8824"/>
      </reference>
      <reference anchor="RFC8341">
        <front>
          <title>Network Configuration Access Control Model</title>
          <author fullname="A. Bierman" initials="A." surname="Bierman"/>
          <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
          <date month="March" year="2018"/>
          <abstract>
            <t>The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.</t>
            <t>This document obsoletes RFC 6536.</t>
          </abstract>
        </front>
        <seriesInfo name="STD" value="91"/>
        <seriesInfo name="RFC" value="8341"/>
        <seriesInfo name="DOI" value="10.17487/RFC8341"/>
      </reference>
      <reference anchor="RFC9363">
        <front>
          <title>A YANG Data Model for Static Context Header Compression (SCHC)</title>
          <author fullname="A. Minaburo" initials="A." surname="Minaburo"/>
          <author fullname="L. Toutain" initials="L." surname="Toutain"/>
          <date month="March" year="2023"/>
          <abstract>
            <t>This document describes a YANG data model for the Static Context Header Compression (SCHC) compression and fragmentation Rules.</t>
            <t>This document formalizes the description of the Rules for better interoperability between SCHC instances either to exchange a set of Rules or to modify the parameters of some Rules.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9363"/>
        <seriesInfo name="DOI" value="10.17487/RFC9363"/>
      </reference>
      <reference anchor="I-D.ietf-lpwan-schc-yang-data-model">
        <front>
          <title>A YANG Data Model for Static Context Header Compression (SCHC)</title>
          <author fullname="Ana Minaburo" initials="A." surname="Minaburo">
            <organization>Acklio</organization>
          </author>
          <author fullname="Laurent Toutain" initials="L." surname="Toutain">
            <organization>Institut MINES TELECOM; IMT Atlantique</organization>
          </author>
          <date day="9" month="October" year="2022"/>
          <abstract>
            <t>This document describes a YANG data model for the Static Context Header Compression (SCHC) compression and fragmentation Rules.

 This document formalizes the description of the Rules for better interoperability between SCHC instances either to exchange a set of Rules or to modify the parameters of some Rules.
            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-lpwan-schc-yang-data-model-21"/>
      </reference>
      <reference anchor="I-D.ietf-core-sid">
        <front>
          <title>YANG Schema Item iDentifier (YANG SID)</title>
          <author fullname="Michel Veillette" initials="M." surname="Veillette">
            <organization>Trilliant Networks Inc.</organization>
          </author>
          <author fullname="Alexander Pelov" initials="A." surname="Pelov">
            <organization>Acklio</organization>
          </author>
          <author fullname="Ivaylo Petrov" initials="I." surname="Petrov">
            <organization>Google Switzerland GmbH</organization>
          </author>
          <author fullname="Carsten Bormann" initials="C." surname="Bormann">
            <organization>Universität Bremen TZI</organization>
          </author>
          <author fullname="Michael Richardson" initials="M." surname="Richardson">
            <organization>Sandelman Software Works</organization>
          </author>
          <date day="1" month="March" year="2023"/>
          <abstract>
            <t>   YANG Schema Item iDentifiers (YANG SID) are globally unique 63-bit
   unsigned integers used to identify YANG items, as a more compact
   method to identify YANG items that can be used for efficiency and in
   constrained environments (RFC 7228).  This document defines the
   semantics, the registration, and assignment processes of YANG SIDs
   for IETF managed YANG modules.  To enable the implementation of these
   processes, this document also defines a file format used to persist
   and publish assigned YANG SIDs.


   // The present version (-20) is intended to address all IESG
   // feedback.  It has significantly progressed from -16, which was the
   // original submission to the IESG.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-core-sid-20"/>
      </reference>
      <reference anchor="I-D.toutain-lpwan-access-control">
        <front>
          <title>SCHC Rule Access Control</title>
          <author fullname="Ana Minaburo" initials="A." surname="Minaburo">
            <organization>Acklio</organization>
          </author>
          <author fullname="Laurent Toutain" initials="L." surname="Toutain">
            <organization>Institut MINES TELECOM; IMT Atlantique</organization>
          </author>
          <author fullname="Ivan Martinez" initials="I." surname="Martinez">
            <organization>Institut MINES TELECOM; IMT Atlantique</organization>
          </author>
          <date day="20" month="February" year="2023"/>
          <abstract>
            <t>   The framework for SCHC defines an abstract view of the rules,
   formalized with through a YANG Data Model.  In its original
   description rules are static and share by 2 entities.  The use of
   YANG authorizes rules to be uploaded or modified in a SCHC instance
   and leads to some possible attacks, if the changes are not
   controlled.  This document summarizes some possible attacks and
   define augmentation to the existing Data Mode, to restrict the
   changes in the rule.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-toutain-lpwan-access-control-01"/>
      </reference>
      <reference anchor="I-D.ietf-lpwan-schc-compound-ack">
        <front>
          <title>SCHC Compound ACK</title>
          <author fullname="Juan-Carlos Zúñiga" initials="J. C." surname="Zúñiga">
            <organization>Cisco</organization>
          </author>
          <author fullname="Carles Gomez" initials="C." surname="Gomez">
            <organization>Universitat Politecnica de Catalunya</organization>
          </author>
          <author fullname="Sergio Aguilar" initials="S." surname="Aguilar">
            <organization>Universitat Politecnica de Catalunya</organization>
          </author>
          <author fullname="Laurent Toutain" initials="L." surname="Toutain">
            <organization>IMT-Atlantique</organization>
          </author>
          <author fullname="Sandra Cespedes" initials="S." surname="Cespedes">
            <organization>Concordia University</organization>
          </author>
          <author fullname="Diego S. Wistuba La Torre" initials="D. S. W. L." surname="Torre">
            <organization>NIC Labs, Universidad de Chile</organization>
          </author>
          <date day="4" month="April" year="2023"/>
          <abstract>
            <t>   The present document updates the SCHC (Static Context Header
   Compression and fragmentation) protocol RFC8724 and the corresponding
   Yang Module RFC9363.  It defines a SCHC Compound ACK message format
   and procedure, which are intended to reduce the number of response
   transmissions (i.e., SCHC ACKs) in the ACK-on-Error mode, by
   accumulating bitmaps of several windows in a single SCHC message
   (i.e., the SCHC Compound ACK).

   Both message format and procedure are generic, so they can be used,
   for instance, by any of the four Low Power Wide Area Networks
   (LPWANs) technologies defined in RFC8376, being Sigfox, LoRaWAN, NB-
   IoT and IEEE 802.15.4w.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-lpwan-schc-compound-ack-17"/>
      </reference>
    </references>
    <?line 244?>

<section anchor="set-of-rules">
      <name>Set of Rules</name>
      <figure anchor="Fig-sor-9363">
        <name>SoR only referenced by RFC9363</name>
        <artwork><![CDATA[
{::include sor-9363.json}
]]></artwork>
      </figure>
      <figure anchor="Fig-sor-oam">
        <name>SoR including OAM compression</name>
        <artwork><![CDATA[
{::include sor-oam.json}
]]></artwork>
      </figure>
      <figure>
        <name>SoR including Access Control</name>
        <artwork><![CDATA[
{::include sor-oam+ac.json}
]]></artwork>
      </figure>
    </section>
    <section anchor="Allocation">
      <name>SID Allocation</name>
      <figure anchor="Fig-csv">
        <name>Manual SID allocation</name>
        <artwork><![CDATA[
{::include Classeur2.csv}
]]></artwork>
      </figure>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>TBD</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>TBD</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA81a624buRX+P09BKChiNxpFF0u2VSywjp1s3cZxYGexKIpF
Qc1QEuu5qHOR7fW66Gv09fok/c4hORdZttJuF6gQOJoReXh4rt85pO/7Xl7I
JPyLjNJETUWRlcrTq4y/5cWw3z/uD70wDRIZ4+cwk/PCL9KykDrx82AZ+LkO
fRlFaSALnSZ+f+Dh21TkReit9NQTIr+PMzXPp+L1vcpf04s0KzbeFJkOivo5
SOOVbL4o0sA9eIUuIrByffr7U3GtQ3FSLe7J2SxT6+2/3S7AFBgWP6TZjU4W
4rssLVeeLItlmk09X+gEHJ30xIVO5KzMUixrNn2SyObLNAOl0zTJywiSKwz7
SoHbq1KJUIkrlSQqp23o4n4qRuPxoC9OVZ5DPNdqrReJErzJMikyDPiQySRQ
eKNiqaOpkFjWLvftgl71IA/H4Mee+GLEX/H3UZaZSorGe2bxPMkhqrIQF+ef
3l+LL+8/vj+9vPidOL/4Ik6KCKzrv5WqZh/ffDEUmdlEJMXpUoIeuM2kVvzr
6bUYHE76h829HU4293aqQnX30gYtwz3L8Lc6LnxZcdSbZ56XpFkMva0VsXX1
4fToaHjgvo4OBvbr8Wgyoq/n/llPq2LuR6tbae3yXiYLP8QO/DgNVdQaFqSZ
IsN1L51Bm+kyCLAhDAL3afQcfbJRbBDGH9w8Q1wn8+Y28A9/fN8XcgaZw8A9
708nn74T1+dnYu86WEI84rxQsdBnEI+ea5XtC50LKWIFKw3hBkKH/NO94Jka
o3MYBmSdEEmdqFCoZK2zNIkxMIe1LJUZewZZiAuShQBbxkcSpcKcyJa5EnkM
P1aZWMuoVFg1CUWmwjJQogCNUFOgwMNMFbdKJaK4TUWuAnIuJgGb1bH+iawH
jpG/Fjk9EBWZ51C4WCoZgjwJLoOAMU+sVMYiAt2e+KNSK3JM6/2Oj4rZQCZY
XIQIVOJ2CQ5Iu7yAEUpxL2RGjM7niuxLy0KFPY8lHuswjJTnvYJbQKvYFQcF
zxoReJ5DdiTqZ2WVlZGCPB8enmj68VHkKxWQwnKW1SpLyYTMXCi3jo/MLvYr
F4r0Q+qBghFfS3okIQclJqZzprMxl8g5hpsCp6HEHdRFkgUhHt+j7TLrG3vy
PDKKtcpYB98O+8MR4rY/OKrW3TJJrMpZpPMlDAz2RqPAimBeyFNgerkYjCbE
cy72jofMrVUM5NIV5s1cyQLGYMzrwLwjPe4/J1mdhBr7Z8nKohILQspC8exi
i4E7dTCvxCeE7Ox20O/3efXxsXBfK9KxvNNxGUOSiER5IVZpGonr319+//FM
fLr8ItRdAJdhGsa1OCNCSXkqFvDzHNktJgNQTnEYbQy5JzzvWpMHsYhudRSR
OcPz4LIai2ek1EqFokwoGta2baWsQs/Kn82fg5vxMuIhUpKY2GORknhi8qiC
jawa3kXcoOgchR4YuNXwfaxMDo7BJXRcycpGGwQiozCi0TORzGNxI+jAlYxC
M+v6CEABlgmNayZBVPIDOdfpu8sroSK2/a7waBe5CRkrlSASpWZnLLCeOONA
UjHjDw+Y5JvhiBdzy3jkVqCTLOACs/ti28zxxE4djznWDXmg2VQkswWE79l4
A9vDdlYp7I5El1a2Xpud053jQCcYNjIkoeYvqUhXRe2bp5dXSL2fPmz4p5VW
viRNEDkXgMH5KkWAnCFiOQuP4RFizmYJ2zBqJou6NBJL2X6WjWCorUoqBVir
ccx4G8zQVLdYe7eVlnRu8gwSNQ8HMzKCFpt79169Eu/vZLwC73+nj1ft3vMe
xv3j8VQ8DKbizw8HU5MR6fNnejXuD8bd+p0QY3531Ho3oXeT9rvDqThovTia
ikHrxTHNOhq13g1GU7NuH7FpKpav+5PXjz8+Nsf8J1wBKuMz2mTs6H/BWJ8Y
+5GH4Iv36CFxvb/+wmr0HjocMgmUTOlPBwLuUDroEJmOIgzWmTYXYIF3KM36
oeL/JKdDjGrQCkLpJ2nhk4l0uu3pQnRCnZnk79sInWbt+aH2Z7oaJaMtNBBY
otDXYXviHBWFXq0nvs1Qz06MVLIolh3S/jMj4Eba7mzwdAygWbCEk/spcMjT
DcSpzxa+Zf2CQkbhc8QwYoYQ1F2HddZxrzvvFt980yGb2iDw/yt8P5WxUUAQ
kwqK+5XaLf+j/1P5L06M/MWPNQVyIP7fs/HpYSpefdALghuCa8tvOlXIWufC
OdqjQU3KxDaKpg8PdhpQisn9sg71VWJEIS0TpBNK8xx/KQWGWi6SFPk2ENBy
HYB1kVNU1dgBhXkCL3Z55JxiKf5wffmpJz4gTGcA03KmI0a9mGlBMzAsoBbn
+4pTfA11YfNxmNKKNnOB4XmJVMbgEVnHoGAHmgjb9cyu8YNEuctJISnjmcoo
N64YSGP87F6sqN6itQjPdLF9mRGaQMpKY4Q44KwKSDdw2tMFmUkTS80UgH51
B/vQhBmQboBgiFv66fLkgjLOD4pLg1zZQqXGIGDAoLS5znLDPWWgOg/nYjN4
9kTnbfvVW46lqDh0sDQpkLIpq0OKNwMCHgbTEe0JcjDhDoAOVD1UDofPUHxr
AvMTioZ9APEDZj0RnhTA3QW9+kBOBXCTB5le2ZIAKPMWiReMNHZFcgBGmG9u
r7Hy2y0hyGJhZaBQtQMDgoCQb9R9DfYdEk/nzwauCrzCjD6lhapxNgrHlBCE
gYI1UdmISxBjlCaLBgprx6mOswXLNfGbBlT1MV8QrM3JXAhd0U6xWFjXUjTK
gj5j5lvrnraNmoqHASDMfyZn0T1BN1kuaCNk+lSkG8xlSqDE1s2mrSBsW8Ez
UBpQ8QZlL/btqt42LOtae7BsxiUMAcvdqFVBDsuIsYkXjbl//PzDySdxaxtd
C2p0OZhJzk8AmOVVFim1J4INvyZ5YnNrzRGCkSfjWXhfoxrNqWFh9mh3b96/
UEOSt55YZ8za+tDcQ5DrFFE4Vhlr/Wl9Dx2kWWgqpQgAu3jW45+2K5aKtt1s
WtiGAtUEJABan7zJNjCoGLFlgo2C1mi3cs6I3BR/ZcI1HRfvGbWIGv2DepGm
zBg31+YoNJuCR4VEXpThPe/SvCTxcv1YdVdsFYHHrri1tUkhb0jFGUJiHqhE
Zlp3bQQL0rUyKD/NNMQMpW439ocHG5KR3mgd3luTayQas6dMLWRmqiUWsluS
6w+KXXX1IZNE3QGM4vNbagT77QZCmsCdVjKTsSqo5nyGHQ6V55/Xk674/uwz
c3eannwWHDpy21ThxlmuWGKHhtOpbUI0W1DcCTCtiUw2VGL5Q5wRMjRNMtPa
UWudlrmjzHS71n8dzcxlqPPTi88w5zyXC+X4AjWRqNtmneaGrid2C10xK4u6
r1ODCcwnD0bg4/ZGg8s3MnDaeZFZm2dawQg0w4o/qjG16dC0HZsnnpiJp3bi
2UWzys95Y0zMKZyXbEeAD1xlktuwgZrwRGZtmLzCDLZkuVpF1MKZp2VWd/Wa
Ici0RfOqbiXHmJJlsYew9dkWjOUmhnOwglrdo5GJUyab5GKPO0QOf8xkjgBp
2iz4DlppBVaoqdUcC0DC4hi13rZFtt99gb/z918+WOb2CDRN8acrxmP+1hUT
82rfytx4VLRaSgQ5VAGRCY6tBWKZAELDq+p2VMtddea6CsG9SIOgzCDkoK0/
IliopGpLxvBVUcW4ZldStvpe1aauv3ObOj07mbKrlAWU/PH6XVdcUBWAvytq
/nbZvHNuD3EsJCCBpHpxOTXthq4AJEFG6gquHvAL0SB5tOqdfYRsjtkGIPFm
kasVpcFbg11g4oC0ZC9/Nx8PdcEbv/H5RQ9vQO3nZtFCD87+6IF17X7ZeIDA
3ANBfnzZRq35kCsKm4A+9MAuBQXww16IWiHeb875+VfYaRXM6WE4OD6oeBsc
HvTFnn8wPtinh+EAD4PjffplfDShh9GYfhmPjo5+Pd4okBvejg4GFW/D4WQM
DsaHk316OBjhYTgk3ob9yQHxdnhMvB0fHQ5+Vd4ofGPR4+G45m3Eopr0D5i3
Q3og5yfejocVb2AUUhQ//+sf//zfsidqz3A1cqyAi2yRfM0twUS840Zq+6gi
p5QFa1wgu3UerSvGKHgJxaQZdxCN/3UZP5GjAtwgkgz6FWLjSpk8m11gj9JP
WlJRHLqUtG9QkAE2hFjt+Yuaz3WgTUibN4DhUNzoKPUJ09EP1fkctZ2brfcj
C2z2RtugQhMmmIH7FiCSF/vO+Zbc8XaorZENDVRTa2yRj7GStJ1nIRB7LlYj
GZocIPtwtM3mgYVNIF4Q7Lf8EoOcg8JQG1wJpRFsqFoV5qieDqyqOPg0gTRT
LCd9Lu57tTlwEW0+jNE36luPC+Hnf+cqlAYd7hr0VgY3/kwtJWBMRjOOds6o
kgANP949vJAkmJ/AD9L+zuFcOtPQwdcN3VJl0+zhfz3b9LyIxugX0njLLTOi
dPBLKVU8vWQVTUpb+pc0fafR2OmuRUBzdttQc45pWdK83ZbUnOcamTRzt1GZ
mU/am5g8+EoTezq5Uvzga03vGRKV3gdfa4XPEao4+lpTbLZtad7XGl5zXs3+
1xpba3a19m5bmweJiwyD3VbWSgt854Tm7bYyVODwhLUu7v1CxyrzTPZF9reV
Pfc5iNZuu9uk9RZB/Sb3wzKT1niHu+3vGSKmPZQTjd0GGA39W6QSJ77hbkuL
5R3dpPHtwTuvs9usaJZOCpVx+yX059Q54Lm7Tcse9fvIzzcwD8fqbqvKghxp
dJFmSI0xTdltSpniU4BYM5CwisbM3Wa1beYWte62sxcINVS728boD0JvHUlH
u03KzXHON9ptQTwl4bsiNGG3ARWa1kgI4PgDmrLbeniK1ftot8HcVmN32wgq
zjC1EzZBdAXDHJI+eYrAbJePsHPnqim9Tld02iqo3hhpdYRDscDm0h7u5ECj
a1WdLiz1gq+bLGWCONMTTy4RdO13258HnC+BsE0/YWsuELartg0eWHxOs6m4
f4k9dwOC2azR66v6Hqc7ajN9COptbN6S4sYEtx4aN6sskkaY4NMMaW62uX61
nFFhgdhoLoXs0YU7yb+M7SvXKnKVgW1t2DO2/d1A/jwx+J1We9JU4+Maieqo
Pl2kfhr34luNOnu0R9vgJt+4X1+8uDDSaN4147MhczHI3fGjJq7RbY7Ap7r1
2rZrm3LzOKdCzB467A1+s2/O8apuDs8V9d0UTK/uplRnPtzlffVKnIR0U40L
QqjOXY4zFVODW3dpDv+b01Ju+m69EgZ7jGDCRXSP4m5Jbf5w6nl+fe7ww3fu
Blcuzk8+nZhTCnfThy91uT46O4FrhYMgXYlUoZ1gLxU1GuR7rTOdMUoGorK/
sfjFyZ+qK2Sm/aXWWt06qubUJqb7sRUflgImm+uBxsSNoOmAx3iNE0vDIR57
mHo+55MaPg6DeKA5HXIPbnbvyJr7nIYnyS8qGt36tuG2Bp5lgu6YCToln2uz
ClJJ6awAj2Z5Wwqb6t404RHainZVaRuJ1gS3a9naAV9/pZuOZcwOaQROjmUX
NL3yKE35sMueL6o7c5vNNG7zrmsLUNUBGzQZjw3JRJye+D7n6RTFYrLGlLzN
eZDbQomUoX9ytysJps2AHvjwpm5e56ZQRryfuoNA1xzr/TWHxvhnUecD1zlz
jZX0yhyEZIpb3vaE3fZYO4/byacyfpY69b4axOvoQs2CRofjBdpvZPASeWpf
bV2h3fymBcxBV23A7fD+lIFTRKdcldmwF+TrzeXxyq17sS0bcPOJ1ROUGZ0g
0sV9RCiDnCgIvTvjW8EUJLb99m9lfT6EIjEAAA==

-->

</rfc>
