<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.13 --> version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc consensus="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
ipr="trust200902"
docName="draft-ietf-6tisch-enrollment-enhanced-beacon-14" category="std"
number="9032"
obsoletes=""
updates=""
submissionType="IETF"
category="std"
consensus="true"
xml:lang="en"
tocInclude="true"
tocDepth="2"
sortRefs="true"
symRefs="true"
version="3">

  <!-- xml2rfc v2v3 conversion 2.39.0 -->
  <front>
    <title abbrev="IE for ICMPv6">IEEE 802.15.4 Information Element encapsulation abbrev="Enroll Beacon">Encapsulation of 6TiSCH Join and Enrollment Information</title> Information Elements</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-6tisch-enrollment-enhanced-beacon-14"/> name="RFC" value="9032"/>

        <author initials="D." initials="D" surname="Dujovne" fullname="Diego Dujovne (editor)"> Dujovne" role="editor">
            <organization>Universidad Diego Portales</organization>
            <address>
                <postal>
                    <street>Escuela de Informatica Informática y Telecomunicaciones, Av. Ejercito Telecomunicaciones</street>
                    <street>Av. Ejército 441</street>
          <city>Santiago, Region Metropolitana</city>
                    <city>Santiago</city>
                    <region>Región Metropolitana</region>
                    <country>Chile</country>
                </postal>
                <phone>+56 (2) 676-8121</phone>
                <email>diego.dujovne@mail.udp.cl</email>
            </address>
        </author>
    <author initials="M." surname="Richardson" fullname="Michael Richardson">
      <organization>Sandelman Software Works</organization>
      <address>
        <email>mcr+ietf@sandelman.ca</email>
      </address>
    </author>
    <date year="2020" month="February" day="21"/> year="2021" month="May"/>
    <area>Internet</area>
    <workgroup>6tisch Working Group</workgroup>
    <keyword>Internet-Draft</keyword>
    <workgroup>6TiSCH</workgroup>

<keyword>BRSKI</keyword>
<keyword>enroll</keyword>
<keyword>zero-touch</keyword>
<keyword>DODAG balancing</keyword>
<keyword>LLN balancing</keyword>

    <abstract>
      <t>In TSCH the Time-Slotted Channel Hopping (TSCH) mode of IEEE STD Std 802.15.4,
opportunities for broadcasts are limited to
specific times and specific channels.  Routers in a Time-Slotted Channel
Hopping (TSCH)
TSCH network
transmit Enhanced Beacon (EB) frames to announce the presence of the
network.  This document provides a mechanism by which additional information critical
for new nodes (pledges) and long sleeping long-sleeping nodes may be carried within the
Enhanced Beacon
EB in order to conserve use of broadcast opportunities.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="problems" numbered="true" toc="default">
      <name>Introduction</name>
      <t><xref target="RFC7554" format="default"/> describes the use of the Time-Slotted Channel Hopping (TSCH) mode of <xref target="ieee802154" target="IEEE.802.15.4" format="default"/>.</t>
      <t>In TSCH mode of IEEE STD Std 802.15.4, opportunities for broadcasts are limited to
specific times and specific channels.
Routers in a Time-Slotted Channel Hopping (TSCH) TSCH network
transmit Enhanced Beacon (EB) frames during broadcast slots in order to
announce the time and channel schedule.</t>
      <t>This document defines a new IETF Information Element (IE) subtype to place
into the Enhanced Beacon (EB) EB to provide join and enrollment information to prospective
pledges in a more efficient way.</t>
      <t>The following sub-sections subsections explain the problem being solved, which
justify
justifies carrying the join and enrollement enrollment information in the EB.</t>
      <section anchor="Terminology" numbered="true" toc="default">
        <name>Use of BCP 14 Terminology</name>
        <t>The
        <name>Terminology</name>

        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", "<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 "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP&nbsp;14 <xref target="RFC2119" format="default"/> target="RFC2119"/> <xref target="RFC8174" format="default"/> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>

        <t>Other terminology can be found in <xref target="I-D.ietf-6tisch-architecture" format="default"/> in section
2.1.</t> target="RFC9030"
	sectionFormat="of" section="2.1"/>.</t>
      </section>
      <section anchor="layer-2-synchronization" numbered="true" toc="default">
        <name>Layer-2
        <name>Layer 2 Synchronization</name>
        <t>As explained in section 6 of <xref target="RFC8180" format="default"/>,
	sectionFormat="of" section="4.5.2"/>, the Enhanced Beacon (EB) EB
has a number of purposes: it carries synchronization of information such as the
   Absolute Slot Number (ASN) and Join Metric, carrying Metric and identifiers for
   the timeslot template identifier, carrying and the channel hopping sequence identifier, sequence, and indicating it
   indicates the TSCH SlotFrame.</t> slotframe.</t>
        <t>An EB announces the existence of a TSCH network, network and of the nodes
already joined to that network.  Receiving an EB allows a Joining Node
(pledge) to learn about the network and synchronize to synchronize with it.</t>
        <t>The EB may also be used as a means for a node already part of the network to
re-synchronize
resynchronize <xref target="RFC7554" format="default"/>.</t>
        <t>There are a limited number of timeslots designated as broadcast slots by each
router in the network.
Considering 10ms 10 ms slots and a slot-frame slotframe length of 100, these slots are rare
and could result in only 1 slot per second for broadcasts, which needs to be
used for the beacon.
Additional broadcasts for Router Advertisements (RA), (RA) or Neighbor Discovery
(ND) could be even more scarce.</t>
      </section>
      <section anchor="layer-3-synchronization-ipv6-router-solicitations-and-advertisements" numbered="true" toc="default">
        <name>Layer-3 synchronization:
        <name>Layer 3 Synchronization: IPv6 Router Solicitations and Advertisements</name>
        <t>At layer Layer 3, <xref target="RFC4861" format="default"/> defines a mechanism by which nodes learn about
routers by receiving multicast Router Advertisements (RA). RAs.
If no RA is received within a set time, then a Router Solicitation (RS) may be
transmitted as a multicast, to which an RA will be received, usually unicast.</t>
        <t>Although <xref target="RFC6775" format="default"/> reduces the amount of multicast necessary to do for address
resolution via Neighbor Solicitation (NS) messages, it still requires multicast
of either RAs or RSes.
This is an expensive operation for two reasons: there
are few multicast timeslots for unsolicited RAs; and if a pledge node does not
receive an RA, and decides to transmit an RS,
a broadcast aloha Aloha slot (see <xref target="RFC7554" format="default"/> section A.5) sectionFormat="of" section="A.5"/>) is consumed with
unencrypted traffic.
<xref target="RFC6775" format="default"/> already allows for a unicast reply to such an RS.</t>
        <t>This is a particularly acute issue for the join process for the following
reasons:</t>
        <ol spacing="normal" type="1">
          <li>Use of a multicast slot by even a non-malicious unauthenticated node for
a Router Solicitation (RS) may overwhelm that time slot.</li> timeslot.</li>
          <li>It may require many seconds of on-time before a new pledge receives a
Router Advertisement (RA) that it can use.</li>
          <li>A new pledge may have to receive many Enhanced Beacons (EB) EBs before it can pick an
appropriate network and/or closest Join Assistant Proxy to attach to.
If it must remain in the receive state for an RA as well as find the
Enhanced Beacon (EB),
EB, then the process may take dozens of seconds, even minutes for each
enrollment attempt that it needs to make.</li>
        </ol>
      </section>
      <section anchor="layer-2-selection" numbered="true" toc="default">
        <name>Layer-2
        <name>Layer 2 Selection</name>
        <t>In a complex Low-power and Lossy Networks Network (LLN), multiple LLNs may
be connected together by backbone routers ( technology Backbone Routers (technology such as
<xref target="I-D.ietf-6lo-backbone-router" target="RFC8929" format="default"/>), resulting in an area that is
serviced by multiple multiple, distinct Layer-2 Layer 2 instances.
These are called Personal Area Networks (PAN). (PANs).
Each instance will have a separate Layer-2 Layer 2 security profile, profile and will be distinguished by a different PANID.

The PANID is part of the Layer 2 header as defined in <xref target="ieee802154" format="default"/> layer-2 header: target="IEEE.802.15.4" format="default"/>:
it is a 16-bit value which that is chosen to be unique, and
it contributes context to the layer-2 Layer 2 security mechanisms.
The PANID provides a context similar to the ESSID does Extended Service Set ID (ESSID)
in 802.11 networking, networking and can be conceived of in a considered similar fashion as to
the 802.3 ethernet Ethernet VLAN tag in that it provides context for all layer-2 Layer 2 addresses.</t>
        <t>A device which that is already enrolled in a network may find after
a long sleep that it needs to resynchronize to with the Layer 2 network.
The device's enrollment keys that it has will be specific to a PANID, but it the device may have more than one set of keys.
Such a device may wish to connect to a PAN that is experiencing less congestion, congestion or which that has a shalower
(<xref target="RFC6550" format="default"/>) shallower
Routing Protocol for LLNs (RPL) tree. tree <xref target="RFC6550" format="default"/>.
It may even observe PANs for which it does not have keys, but for which is
it believes it may have credentials that would allow it to join.</t>

        <t>In order to identify which PANs are part of the same backbone network, the network ID is introduced in this extension.
PANs that are part of the same backbone will be configured to use the same network ID.
For RPL networks <xref target="RFC6550" format="default"/> RPL networks, format="default"/>, configuration of the network ID can be done with an a configuration option, which is the subject of future work.</t>
        <t>In order to provide some input to the choice of which PAN to use, the PAN priority field has been added.
This lists the relative priority for the PAN among different PANs.
Every Enhanced Beacon EB from a given PAN will likely have the same PAN priority.
Determination of the the PAN priority is the subject of future work;
but it is expected that it will be calculated by an algorithm in the 6LBR,
6LoWPAN Border Router (6LBR), possibly involving communication between 6LBRs over the backbone network.</t>
        <t>The <xref target="RFC6550" format="default"/> parent selection process <xref target="RFC6550" format="default"/>
can only operate within a single PAN, PAN because it depends upon receiving RPL DIO messages from all available parents.
As part of the PAN selection process, the device may wish to know how deep
in the LLN mesh it will be if it joins a particular PAN, and the rank
priority field provides an estimation of what the rank of each announcer is. announcer's rank.
Once the device synchronizes to with a particular PAN's TSCH schedule then schedule,
it may receive DIOs that are richer in their diversity than this value.
How
The use of this value will be used in practice is the subject of future research, and the interpretation of this
value of the structure is considered experimental.</t>
      </section>
    </section>
    <section anchor="protocol-definition" numbered="true" toc="default">
      <name>Protocol Definition</name>
      <t><xref target="RFC8137" format="default"/> creates a registry for new IETF IE subtypes.
This document allocates a new subtype.</t>
      <t>The new IE subtype structure is as follows.  As explained in
<xref target="RFC8137" format="default"/> format="default"/>, the length of the Sub-Type Content subtype content can be calculated from the
container, so no length information is necessary.</t>

      <figure anchor="iesubtype">
        <name>IE subtype structure</name> Subtype Structure</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   TBD-XXX       2       |R|P| res |  proxy prio |    rank priority      |
+-+-+-+-+-+-+-+-+-+-------------+-------------+-----------------+
| pan PAN priority  |                                               |
+---------------+                                               +
|                     Join Proxy Interface-ID Interface ID                   |
+                        (present if P=1)                       +
|                                                               |
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |                                               |
+-+-+-+-+-+-+-+-+                                               +
|                           network ID                          |
+                   variable length, up to 16 bytes             +
~                                                               ~
+                                                               +
|                                                               |
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |
+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
      <dl newline="false" spacing="normal">
        <dt>res:</dt>
        <dd>
  reserved
  Reserved bits MUST <bcp14>MUST</bcp14> be ignored upon receipt, receipt and SHOULD <bcp14>SHOULD</bcp14> be set to 0 when sending.</dd>
        <dt>R:</dt>
        <dd>
  The Router Advertisement RA R-flag is set if the sending node will act as a Router router for host-only nodes relying on stateless address auto-configuration (SLAAC) to get their global IPv6 address.
Those hosts MUST <bcp14>MUST</bcp14> send a unicast Router Solicitation RS message in order to receive a an RA with the Prefix Information Option.</dd>
        <dt/>
        <dd>In most cases, every node sending a beacon will set this flag, and in a
typical mesh, this will be every single node.  When this bit is not set, it
might indicate that this node may be under provisioned, provisioned or that it may have no additional
slots for additional nodes.  This could make this node more interesting to an
attacker.</dd>
        <dt>P:</dt>
        <dd>
  If the Proxy Address P-flag is set, then the Join Proxy Interface ID bit field
is present.  Otherwise, it is not provided.</dd>
        <dt/>
        <dd>This bit only indicates if another part of the structure is present, and
it has little security or privacy impact.</dd>
        <dt>proxy priority prio (proxy prio):</dt> priority):</dt>
        <dd>
  This field indicates the willingness of the sender to act as join proxy. a Join Proxy.
Lower value indicates greater willingness to act as a Join Proxy as described in
<xref target="I-D.ietf-6tisch-minimal-security" target="RFC9031" format="default"/>.
Values range from 0x00 (most willing) to 0x7e (least willing).
A priority of 0x7f indicates that the announcer should never be considered as a viable enrollment proxy. Join Proxy.
Only unenrolled pledges look at this value.</dd>
        <dt/>
        <dd>Lower values in this field indicate that the transmitter may have more
capacity to handle unencrypted traffic.
A higher value may indicate that the transmitter is low on neighbor cache entries, entries or other resources.
Ongoing work such as <xref target="I-D.ietf-roll-enrollment-priority" format="default"/> documents one way to set this field.</dd>
        <dt>rank priority:</dt>
        <dd>
  The rank "priority" priority is set by the IPv6 LLN Router (6LR) which that sent the beacon and is an
indication of how willing this 6LR is to serve as an a RPL parent <xref target="RFC6550" format="default"/> parent within a
particular network ID.
Lower values indicate more willingness, and higher values indicate less willingness.
This value is calculated by each 6LR according to algorithms specific to the
routing metrics used by the RPL (<xref <xref target="RFC6550" format="default"/>). format="default"/>.
The exact process is a subject of significant research work.
It will typically be calculated from the RPL rank, and it may include some modifications
based upon current number of children, children or the number of neighbor cache entries
available.
Pledges MUST <bcp14>MUST</bcp14> ignore this value.
It helps enrolled devices only to compare connection points.</dd>
        <dt/>
        <dd>An attacker can use this value to determine which nodes are potentially
more interesting.
Nodes which that are less willingness willing to be parents likely have more traffic, and an
attacker could use this information to determine which nodes would be more
interesting to attack or disrupt.</dd>
        <dt>pan
        <dt>PAN priority:</dt>
        <dd>
  The pan PAN priority is a value set by the Destination-Oriented Directed
Acyclic Graph (DODAG) root (see <xref target="RFC6550" format="default"/>, typically, typically the 6LBR) to indicate the relative
priority of this LLN compared to those with different PANIDs that the
operator might control.
This value may be used as part of the enrollment priority, but typically it is used by devices
which
that have already enrolled, enrolled and need to determine which PAN to pick when
resuming from a long sleep.
Unenrolled pledges MAY <bcp14>MAY</bcp14> consider this value when selecting a PAN to join.
Enrolled devices MAY <bcp14>MAY</bcp14> consider this value when looking for an eligible parent
device.
Lower values indicate a higher more willingness to accept new nodes.</dd>
        <dt/>
        <dd>An attacker can use this value, along with the observed PANID in the Beacon EB
to determine which PANIDs have more network resources, and may have more
interesting traffic.</dd>
        <dt>Join Proxy Interface ID:</dt>
        <dd>
  If the P bit is set, then 64 bits (8 bytes) of address are present.
This field provides the Interface ID (IID) of the Link-Local link-local address of the Join Proxy.
The associated prefix is well-known as fe80::/64.  If this field is not
present, then IID is derived from the layer-2 Layer 2 address of the sender as per
SLAAC (<xref target="RFC4662" format="default"/>).</dd> <xref target="RFC4862" format="default"/>.</dd>
        <dt/>
        <dd>This field communicates the Interface ID IID bits that should be used for this node's
layer-3
Layer 3 address, if it should not be derived from the layer-2 Layer 2 address.
Communication with the Join Proxy occurs in the clear.
This field avoids the need for an additional service-discovery process for the case where the L3 Layer 3
address is not derived from the L2 Layer 2 address.
An attacker will see both L2 Layer 2 and L3 Layer 3 addresses, so this field provides no new information.</dd>
        <dt>network ID:</dt>
        <dd>
  This is a variable length field, up to 16-bytes in size that uniquely identifies
this network, potentially among many networks that are operating in the same
frequencies in overlapping physical space.  The length of this field can be
calculated as being whatever is left in the Information Element.</dd> IE.</dd>
        <dt/>
        <dd>In a 6tisch 6TiSCH network, where RPL <xref target="RFC6550" format="default"/> is used as the mesh routing protocol, the
network ID can be constructed from a truncated SHA256 SHA-256 hash of the prefix (/64) of the
network.  This will be done by the RPL DODAG root and communicated by the RPL
Configuration Option payloads, so it is not calculated more than once.
This is just a suggestion for a default algorithm: it may be set in any
convenience
convenient way that results in a non-identifing non-identifying value.
In some LLNs where multiple PANIDs may lead to the same management device
(the Join Registrar/Coordinator - JRC), (JRC)), then a common value that is the same across all the PANs MUST <bcp14>MUST</bcp14> be
configured.
Pledges that see the same networkID network ID will not waste time
attempting to enroll multiple times with the same network that when the network has multiple attachment points.</dd>
        <dt/>
        <dd>If the network ID is derived as suggested, then it will be an opaque,
seemingly random value, value and will not directly reveal any information about the network.
An attacker can match this value across many transmissions to map the extent
of a network beyond what the PANID might already provide.</dd>
      </dl>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>All of the contents of this Information Element IE are transmitted in the clear.
The content of the Enhanced Beacon EB is not encrypted.
This is a restriction in the cryptographic architecture of the 802.15.4 mechanism.
In order to decrypt or do integrity checking of layer-2 Layer 2 frames in TSCH, the
TSCH Absolute Slot Number (ASN) ASN is needed.
The Enhanced Beacon EB provides the ASN to new (and long-sleeping) nodes.</t>
      <t>The sensitivity of each field is described within the description of each field.</t>
      <t>The Enhanced Beacon EB is authenticated at the layer-2 Layer 2 level using 802.15.4
mechanisms using the network-wide keying material.  Nodes which that are enrolled
will have the network-wide keying material and can validate the beacon.</t>
      <t>Pledges which that have not yet enrolled are unable to authenticate the beacons, beacons
and will be forced to temporarily take the contents on faith.
After enrollment, a newly enrolled node will be able to return to the beacon and
validate it.</t>
      <t>In addition to the enrollment and join information described in this
document, the Enhanced Beacon EB contains a description of the TSCH schedule to
be used by the transmitter of this packet.
The schedule can provide an attacker with a list of channels and frequencies
on which communication will occur.
Knowledge of this can help an attacker to more efficiently jam
communications, although there is future work being considered to make some
of the schedule less visible.
Encrypting the schedule does not prevent an attacker from jamming, but rather
increases the energy cost of doing that jamming.</t>
    </section>
    <section anchor="privacy-considerations" numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>The use of a network ID may reveal information about the network.
The use of a SHA256 SHA-256 hash of the DODAGID (see <xref target="RFC6550" format="default"/>), rather than using the DODAGID itself
directly provides some privacy for the the addresses used within the network,
as the DODAGID is usually the IPv6 address of the root of the RPL mesh.</t>
      <t>An interloper with a radio sniffer would be able to use the network ID to map
out the extent of the mesh network.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA is asked to assign a new number TBD-XXX from Registry has assigned the following value in the
"IEEE Std 802.15.4 IETF IE Subtype IDs" registry, as defined by <xref target="RFC8137" format="default"/>.</t>
      <t>This entry should be called 6tisch-Join-Info, and should refer to this
document.</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
       Value   Subtype-ID          Reference
       ----    ----------          -----------
       TBD-XXX 6tisch-Join-Inbfo   [this document]
]]></artwork>
    </section>
    <section anchor="acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>Thomas Watteyne provided extensive editorial comments on the document.
Carles Gomez Montenegro generated a detailed review of the document at WGLC.
Tim Evens provided a number of useful editorial suggestions.</t>

<table anchor="iana">

  <thead>
    <tr>
      <th>Value</th>
      <th>Subtype ID</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>2</td>
      <td>6tisch-Join-Info</td>
      <td>RFC 9032</td>
    </tr>

  </tbody>
</table>
    </section>

  </middle>
  <back>

<displayreference target="I-D.ietf-roll-enrollment-priority" to="NETWORK-ENROLLMENT"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8137.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6775.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"/>

<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119"> anchor="RFC9031" target="https://www.rfc-editor.org/info/rfc9031">
  <front>
            <title>Key words
    <title>Constrained Join Protocol (CoJP) for use in RFCs to Indicate Requirement Levels</title>
            <seriesInfo name="DOI" value="10.17487/RFC2119"/>
            <seriesInfo name="RFC" value="2119"/>
            <seriesInfo name="BCP" value="14"/> 6TiSCH</title>
    <author initials="M" surname="Vučinić" fullname=" Mališa Vučinić"
role="editor">
      <organization/>
    </author>
    <author initials="J" surname="Simon" fullname="Jonathan Simon">
     <organization/>
    </author>
    <author initials="K" surname="Pister" fullname="Kris Pister">
     <organization/>
    </author>
    <author initials="S." surname="Bradner" fullname="S. Bradner"> initials="M" surname="Richardson" fullname="Michael Richardson">
     <organization/>
    </author>
    <date year="1997" month="March"/>
            <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> month="May" year="2021"/>
  </front>
        </reference>
        <reference anchor="BCP14" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <seriesInfo name="DOI" value="10.17487/RFC8174"/>
  <seriesInfo name="RFC" value="8174"/> value="9031"/>
  <seriesInfo name="BCP" value="14"/>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization/> name="DOI" value="10.17487/RFC9031"/>
</reference>

      <reference
anchor="IEEE.802.15.4"
target="https://ieeexplore.ieee.org/document/7460875">
        <front>
            <title>IEEE Standard for Low-Rate Wireless Networks</title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date year="2017" month="May"/>
            <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> month="April" year="2016"/>
        </front>
        <seriesInfo name="IEEE Standard" value="802.15.4-2015"/>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7460875"/>
      </reference>

      </references>
      <references>

        <name>Informative References</name>

<reference anchor="RFC8137" target="https://www.rfc-editor.org/info/rfc8137"> anchor="RFC9030" target="https://www.rfc-editor.org/info/rfc9030">
<front>
            <title>IEEE 802.15.4 Information Element
<title>An Architecture for IPv6 over the IETF</title>
            <seriesInfo name="DOI" value="10.17487/RFC8137"/>
            <seriesInfo name="RFC" value="8137"/>
            <author initials="T." surname="Kivinen" fullname="T. Kivinen">
              <organization/>
            </author> Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH)</title>

<author initials="P." surname="Kinney" fullname="P. Kinney"> initials="P" surname="Thubert" fullname="Pascal Thubert" role="editor">
    <organization/>
</author>

<date year="2017" month="May"/>
            <abstract>
              <t>IEEE Std 802.15.4 defines Information Elements (IEs) that can be used to extend 802.15.4 in an interoperable manner.  The IEEE 802.15 Assigned Numbers Authority (ANA) manages the registry of the Information Elements.  This document formulates a request for ANA to allocate a number from that registry for the IETF and describes how the IE is formatted to provide subtypes.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC6775" target="https://www.rfc-editor.org/info/rfc6775">
          <front>
            <title>Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)</title>
            <seriesInfo name="DOI" value="10.17487/RFC6775"/>
            <seriesInfo name="RFC" value="6775"/>
            <author initials="Z." surname="Shelby" fullname="Z. Shelby" role="editor">
              <organization/>
            </author>
            <author initials="S." surname="Chakrabarti" fullname="S. Chakrabarti">
              <organization/>
            </author>
            <author initials="E." surname="Nordmark" fullname="E. Nordmark">
              <organization/>
            </author>
            <author initials="C." surname="Bormann" fullname="C. Bormann">
              <organization/>
            </author>
            <date year="2012" month="November"/>
            <abstract>
              <t>The IETF work in IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4.  This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation.  In addition, the wireless network may not strictly follow the traditional concept of IP subnets and IP links.  IPv6 Neighbor Discovery was not designed for non- transitive wireless links, as its reliance on the traditional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network.  This document describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar networks.  The document thus updates RFC 4944 to specify the use of the optimizations defined here.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC4861" target="https://www.rfc-editor.org/info/rfc4861">
          <front>
            <title>Neighbor Discovery for IP version 6 (IPv6)</title>
            <seriesInfo name="DOI" value="10.17487/RFC4861"/>
            <seriesInfo name="RFC" value="4861"/>
            <author initials="T." surname="Narten" fullname="T. Narten">
              <organization/>
            </author>
            <author initials="E." surname="Nordmark" fullname="E. Nordmark">
              <organization/>
            </author>
            <author initials="W." surname="Simpson" fullname="W. Simpson">
              <organization/>
            </author>
            <author initials="H." surname="Soliman" fullname="H. Soliman">
              <organization/>
            </author>
            <date year="2007" month="September"/>
            <abstract>
              <t>This document specifies the Neighbor Discovery protocol for IP Version 6.  IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.ietf-6tisch-minimal-security" target="http://www.ietf.org/internet-drafts/draft-ietf-6tisch-minimal-security-15.txt">
          <front>
            <title>Constrained Join Protocol (CoJP) for 6TiSCH</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-6tisch-minimal-security-15"/>
            <author initials="M" surname="Vucinic" fullname="Malisa Vucinic">
              <organization/>
            </author>
            <author initials="J" surname="Simon" fullname="Jonathan Simon">
              <organization/>
            </author>
            <author initials="K" surname="Pister" fullname="Kris Pister">
              <organization/>
            </author>
            <author initials="M" surname="Richardson" fullname="Michael Richardson">
              <organization/>
            </author>
            <date month="December" day="10" year="2019"/>
            <abstract>
              <t>This document describes the minimal framework required for a new device, called "pledge", to securely join a 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4e) network.  The framework requires that the pledge and the JRC (join registrar/coordinator, a central entity), share a symmetric key.  How this key is provisioned is out of scope of this document.  Through a single CoAP (Constrained Application Protocol) request-response exchange secured by OSCORE (Object Security for Constrained RESTful Environments), the pledge requests admission into the network and the JRC configures it with link-layer keying material and other parameters.  The JRC may at any time update the parameters through another request-response exchange secured by OSCORE.  This specification defines the Constrained Join Protocol and its CBOR (Concise Binary Object Representation) data structures, and describes how to configure the rest of the 6TiSCH communication stack for this join process to occur in a secure manner.  Additional security mechanisms may be added on top of this minimal framework.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="ieee802154" target="http://standards.ieee.org/findstds/standard/802.15.4-2015.html">
          <front>
            <title>IEEE Std. 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks</title>
            <author initials="." surname="IEEE standard for Information Technology">
              <organization/>
            </author>
            <date year="2015"/>
          </front>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <seriesInfo name="DOI" value="10.17487/RFC8174"/>
            <seriesInfo name="RFC" value="8174"/>
            <seriesInfo name="BCP" value="14"/>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization/>
            </author>
            <date year="2017" month="May"/>
            <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>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="I-D.ietf-6tisch-architecture" target="http://www.ietf.org/internet-drafts/draft-ietf-6tisch-architecture-28.txt">
          <front>
            <title>An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-6tisch-architecture-28"/>
            <author initials="P" surname="Thubert" fullname="Pascal Thubert">
              <organization/>
            </author>
            <date month="October" day="29" year="2019"/>
            <abstract>
              <t>This document describes a network architecture that provides low- latency, low-jitter and high-reliability packet delivery.  It combines a high-speed powered backbone and subnetworks using IEEE 802.15.4 time-slotted channel hopping (TSCH) to meet the requirements of LowPower wireless deterministic applications.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8180" target="https://www.rfc-editor.org/info/rfc8180">
          <front>
            <title>Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration</title>
            <seriesInfo name="DOI" value="10.17487/RFC8180"/>
            <seriesInfo name="RFC" value="8180"/>
            <seriesInfo name="BCP" value="210"/>
            <author initials="X." surname="Vilajosana" fullname="X. Vilajosana" role="editor">
              <organization/>
            </author>
            <author initials="K." surname="Pister" fullname="K. Pister">
              <organization/>
            </author>
            <author initials="T." surname="Watteyne" fullname="T. Watteyne">
              <organization/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t>This document describes a minimal mode of operation for an IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) network.  This minimal mode of operation specifies the baseline set of protocols that need to be supported and the recommended configurations and modes of operation sufficient to enable a 6TiSCH functional network.  6TiSCH provides IPv6 connectivity over a Time-Slotted Channel Hopping (TSCH) mesh composed of IEEE Std 802.15.4 TSCH links.  This minimal mode uses a collection of protocols with the respective configurations, including the IPv6 Low-Power Wireless Personal Area Network (6LoWPAN) framework, enabling interoperable IPv6 connectivity over IEEE Std 802.15.4 TSCH.  This minimal configuration provides the necessary bandwidth for network and security bootstrapping and defines the proper link between the IETF protocols that interface to IEEE Std 802.15.4 TSCH.  This minimal mode of operation should be implemented by all 6TiSCH-compliant devices.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC6550" target="https://www.rfc-editor.org/info/rfc6550">
          <front>
            <title>RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks</title>
            <seriesInfo name="DOI" value="10.17487/RFC6550"/>
            <seriesInfo name="RFC" value="6550"/>
            <author initials="T." surname="Winter" fullname="T. Winter" role="editor">
              <organization/>
            </author>
            <author initials="P." surname="Thubert" fullname="P. Thubert" role="editor">
              <organization/>
            </author>
            <author initials="A." surname="Brandt" fullname="A. Brandt">
              <organization/>
            </author>
            <author initials="J." surname="Hui" fullname="J. Hui">
              <organization/>
            </author>
            <author initials="R." surname="Kelsey" fullname="R. Kelsey">
              <organization/>
            </author>
            <author initials="P." surname="Levis" fullname="P. Levis">
              <organization/>
            </author>
            <author initials="K." surname="Pister" fullname="K. Pister">
              <organization/>
            </author>
            <author initials="R." surname="Struik" fullname="R. Struik">
              <organization/>
            </author>
            <author initials="JP." surname="Vasseur" fullname="JP. Vasseur">
              <organization/>
            </author>
            <author initials="R." surname="Alexander" fullname="R. Alexander">
              <organization/>
            </author>
            <date year="2012" month="March"/>
            <abstract>
              <t>Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained.  LLN routers typically operate with constraints on processing power, memory, and energy (battery power).  Their interconnects are characterized by high loss rates, low data rates, and instability.  LLNs are comprised of anything from a few dozen to thousands of routers.  Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point).  This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported.  Support for point-to-point traffic is also available.  [STANDARDS-TRACK]</t>
            </abstract> month="May" year="2021"/>

</front>
        </reference>
        <reference anchor="RFC7554" target="https://www.rfc-editor.org/info/rfc7554">
          <front>
            <title>Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement</title>
            <seriesInfo name="DOI" value="10.17487/RFC7554"/>
<seriesInfo name="RFC" value="7554"/>
            <author initials="T." surname="Watteyne" fullname="T. Watteyne" role="editor">
              <organization/>
            </author>
            <author initials="M." surname="Palattella" fullname="M. Palattella">
              <organization/>
            </author>
            <author initials="L." surname="Grieco" fullname="L. Grieco">
              <organization/>
            </author>
            <date year="2015" month="May"/>
            <abstract>
              <t>This document describes the environment, problem statement, and goals for using the Time-Slotted Channel Hopping (TSCH) Medium Access Control (MAC) protocol of IEEE 802.14.4e in the context of Low-Power and Lossy Networks (LLNs).  The set of goals enumerated in this document form an initial set only.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.ietf-6lo-backbone-router" target="http://www.ietf.org/internet-drafts/draft-ietf-6lo-backbone-router-17.txt">
          <front>
            <title>IPv6 Backbone Router</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-6lo-backbone-router-17"/>
            <author initials="P" surname="Thubert" fullname="Pascal Thubert">
              <organization/>
            </author>
            <author initials="C" surname="Perkins" fullname="Charles Perkins">
              <organization/>
            </author>
            <author initials="E" surname="Levy-Abegnoli" fullname="Eric Levy-Abegnoli">
              <organization/>
            </author>
            <date month="February" day="20" year="2020"/>
            <abstract>
              <t>This document updates RFC 6775 and RFC 8505 in order to enable proxy services for IPv6 Neighbor Discovery by Routing Registrars called Backbone Routers.  Backbone Routers are placed along the wireless edge of a Backbone, and federate multiple wireless links to form a single Multi-Link Subnet.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.ietf-roll-enrollment-priority" target="http://www.ietf.org/internet-drafts/draft-ietf-roll-enrollment-priority-00.txt">
          <front>
            <title>Enabling secure network enrollment in RPL networks</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-roll-enrollment-priority-00"/>
            <author initials="M" surname="Richardson" fullname="Michael Richardson">
              <organization/>
            </author>
            <date month="September" day="16" year="2019"/>
            <abstract>
              <t>[I-D.6tisch-enrollment-enhanced-beacon] defines a method by which a potential [I-D.ietf-6tisch-minimal-security] can announce itself as a available for new Pledges to Join a network.  The announcement includes a priority for join.  This document provides a mechanism by which a RPL DODAG root can disable join announcements, or adjust the base priority for join operation.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC4662" target="https://www.rfc-editor.org/info/rfc4662">
          <front>
            <title>A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists</title> value="9030"/>
<seriesInfo name="DOI" value="10.17487/RFC4662"/>
            <seriesInfo name="RFC" value="4662"/>
            <author initials="A. B." surname="Roach" fullname="A. B. Roach">
              <organization/>
            </author>
            <author initials="B." surname="Campbell" fullname="B. Campbell">
              <organization/>
            </author>
            <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
              <organization/>
            </author>
            <date year="2006" month="August"/>
            <abstract>
              <t>This document presents an extension to value="10.17487/RFC9030"/>
</reference>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8180.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6550.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7554.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8929.xml"/>

<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-roll-enrollment-priority.xml"/>

<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml"/>

      </references>
    </references>

    <section anchor="acknowledgements" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t><contact fullname="Thomas Watteyne"/> provided extensive editorial comments on the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for subscribing to document.
<contact fullname="Carles Gomez Montenegro"/> generated a homogeneous list of resources.  Instead detailed review of sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire list and then receive notifications when the state of any document at Working Group Last Call.
<contact fullname="Tim Evens"/> provided a number of the resources in the list changes.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
      </references>
    </references> useful editorial suggestions.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIACg9UF4AA9VcbXMbyXH+Pr9iQn0wWEdAJEVRMl2uGCJ5JzoUyZA8n12p
VGqwOwDmuNhFdhakYJ38W/Jb8svydPfM7iwIST7nQypMOQIW89LTr0/39N5w
OFSNawp7oi/Oz8/12/3D0cHr0ZG+KKdVvTCNq0p9XtiFLRtty8ws/aqQp9VU
H9+7u9P3+o+VK7Upc31e1lVR8NhkvjKTSW0faQeNh/ri9MPN47HKq6w0C2yc
12baDJ1tpsPjxvlsPrTtOvg4N2Vm8+HEmqwqhwdHSvkGm/2HKaoSs5t6ZZVy
y/pE4w/ffHO4v//b/UNlamvo4UXZ2Lq0jXqa8Rgtu+ifqvrBlTP9Q12tlurh
SX6Mo4dnRJbKTMPPfZMrtXT8+YXOTKlX3mpT12atB26qTVHotfW7GgecGz/X
c1tb9ULroW6qTD74qm5qO/Xh23rBXzQNOKHJ+BiHnPA2uZ2aVdF4jIi/y6Q4
HBzxtvSr8ECZVTOv6hPFJ9HD8K/WrsSIs5E+W/1cPZa2fS4COHN2VsXf9MDm
rqnq3XZQVYNvP5bu0dbe5SYP429AqimYDPnzoNyCW+c+W9nCgPpOCzKj1/re
FjarFqsSXzMohvV7evw40uc/2zrDnvro6KBdDQ/WJ/rOlI0zs2pP39oZad0H
29TVsiocdMB0g6tV2dQYfzp3RXe85ZxV5LvXx3pwuKuP3xwP3x4cdnvYhXEF
FJDOM8rl/H+gZ6NVvhxlxXY+fhjpW5fNTZ17KHeflR/oB1tsG8BsxHlyWyyg
PnfVtHmCirIa+k2SFln9HVnEH3ycMMqMUqoUdj5akvHt96eHBwe/pY/vTm8O
jk7oyduDN0fy29uDV2/CsOM3b16Hj0dvjw/o48XwbJTa3MKVbmGKobfZqibe
Y4yz1sIjHLw+EpVqTD0jCe/Mm2Z58vIlGyIdc0QjRzjhy6krc9iKb397GV3K
8HAf/8ybRbEji4nb2WG/c9fko9b57OkbUzcjTZ9P9E+uht54D9HnbrXQ4yyj
b6cVJF4VevBhfLrL3udmvvbQrEJfmrWt9eDm/V929d3SZm6Kx+SJPPufy+pp
eGsa2618A82uSswcw2XoK9s8kUyEzL5JsQIIyfGA4tMSd3lvs3lZFdVsLSvk
2OtE0+nhp+I4keCmEEydzV1js2ZVRwm/PXi7H6X4+nX8+OY1yUQNh0NtJjA8
kzVKXWBv8seLCqYH9yycvT9LGFstlzBbWGDjrHBjUlcmz4yHlyFtLNwCBOTw
OMoH1kFSCwwmFrePoN1laQs/AjXVCh7Ta4oB+h5Dh3dF1dAapzJIvceu5GgH
RN2uLoW/ClSXHrshbIiP1+/Yx+vB+btdPa0N7QqvgEVg3pnVzdzqZW3h8TI+
H76rsBjouJ87rxFUVhx/lnX16HIiWy8sUev8Qk/W+mkOy9Qmh49zLHKXSC6D
4pMGKWJMaZ90WdESg2Vh8xk5d+IBws5M+8JaPpOMWCAKTCzCQl07nOPJNXOw
g+jbPBseV3UO9cTB2HvXj5ZDCc7TiqIvppHIeeHyHL4NweOCND9fZUxz+Pv0
AieeIFD7z0p9+hRU5PNneGGPY02IlfN2J/q4TVR6Q1RRkz596lzB58+j/xtV
U9/UtE3yf5Wm5XB7mNoJwWNxnwpM9TSRSGVKA4EaBmzzVWHBnr4uIoy7klWR
dOri/P77rfBqcHG+q/1q0qyXltRjWZjMwmPgI+23lXYaJpquf44orENPPeWW
ocRW8j4q6LQwc1FBHnYKdjua9mTWfAgLsRVF9UR8AWEUG8SN2o8gTjRcB72D
/vOwqni0+Z7YmfoZaMxN12wYa/qZJmwQap9RGhY+fwciXrzQP4rOIsTpgyN4
1xqhit2r1p32J48/C+kPFtYO0Xm98+HHu/udPflXX13z59vzf/3x4vb8jD7f
vR9fXrYfVBhx9/76x8uz7lM38/T6w4fzqzOZjKe690jtfBj/Bb/QEXeub+4v
rq/GlztyqlQtyAYgFPgNR5gTno1U2XgVTTanOTj2f/8Xzv3p0z+FeA+jli8U
6vHlaW5L2a0qi3X4CgaulVkuralZxICnAO9ATQVAl/Haz6unkkEqmKyuMRwa
nrCWEO6E5L8qmYxPn74Wq0AFxgT1UPAAIjkOxMNDfbcus3ldle6vkhCocatC
csgwUx+Lswlh7/PnvS9qvgLIJoNaLSagHLOWq3pZeYvw7Pu7RX83nkA34UA0
OQ19JRMH47srceucxBC6dNleX1/FKdGkxi5ANJaAvQGXTp2tN8ZGXzAPjsjb
/1xxuEpnGGZpzqAkzGNnSoR9T84I3BvDL7xrQ584b/vR+SYGPyNzgosL8peT
ckxSpgCYyddsbuxl8ZtpdBcwb21m3SNRYGQzMnViKrGCHl9hHRWCH7uaAtoE
XZrAD8tGspb465brrNWuCR4EC1N0hN6xqiMAkY5zWDYBkBmmWEeClwB/7VHC
DnC+tR2meyQxTnaqLVuUaeNKpxtRgJ6ioZuVRgztma8HPoCGzVXNgSb6ocgx
BciJBMhymDjYX/gwi05v+POQQwnYVM6aOW18sL/PKgwPFsaCwhr/T3HgqFZF
rgFokONxnCHzPeCReon9YRVVmW+EzuBaQZXNvfgPxUylYUSuJMojNe4wThJ4
aZTEUT3OkdHBltkBA+Xcjnf3KH29sm42n+DDGey8wpi1Glyd7QZy7aMtJV54
aH5mU0t/tWl7yPmR6scN75C2Ia0LUJw40CcBWt/ogsH7qz0RMGUrDGJiBN0C
5gSCJboZ5MfyrFslX4DLjoX95fOP1MUU6+nbsYanlrkdnoOQbcPKxEKlB1tO
hoXudgMibJFH02p9pGKPZBfQaEkbPjn4aFhI3HUPtrKCTa41J8yeDGpcIBlZ
zebCHMrqwJwaqCO6CLOgTJhUrztuaSlhMvWadswrAr/QOQ+DYodIJD8604m9
f5grOgzNn1G6DgyFiA5Cazg2pE++20dhU+s4kNzCv5Oe3RF4ZSzkSN7k8y1M
CIi3gn7LBqy2TxUWNMjB4L4brpyQoUyBlrpjdEZMU1alFzLBWGz3O3Gq5BbF
X4lLyStQWFbQCGGqsFqcZQ58mUuG0eJD+vluT5nEM5iimot164G35Hf+uQPX
MW6NR6936YyE6BHcRWPUqoSzrtdLBrm1IXg1UqnkoscLnld8YZA2GLIsWGR+
FXTkLiJL4ia7SZetClNjmMkosjnvV7Z1BIyzgM44XY4PW0CnIsOVOhhFjJXo
pxyZPOIja3pZlcOFIZZXKw8iKS+mkJaxM2VuYw9KeL9hFeRRgFGKhcQjhtG0
Fw53ONIXDQ8K6oXP5Tr4QU8EggieMLHTip09Ieog8SBj3xJAxPSMnG1ctoWw
QxEP+74a6XG6ElEwN48cyKLmMCUbSMQLCA/EhCWXLqOIyJxYgv3L2hFkSGLl
S8giKwisNAI7xt47Kic0nO42DWIQPo1oCfgjrLtYsUIsCHOHqBTpwrxGZC5u
BF7mycJA8S/VYjgJxTrbMFTwYgHEs5rQyRvzQJbzV5gqsTxwfy94fleCtaJP
HCupZtUlHCAeGKlpedxGqQUW3QCFVA0UOHhBCpZVAFf2I5dnltWTrdlKLyvv
121JRg8uL69AN2spRmt87bLvCtArk4xyZtkRQX0nJnuYVCUYFoLCADAuFmiC
bXmy6g7fFtUwzhrKrM+fsakEagolnL9QLDfhoIACSOQd8RdbttTlkKors6Y9
sytJzJm4ResFsWQwf0zcXoTSg5vxFeLSOelEnC6xgjWUYhI8AelA3CRW8Eio
U1dYcXcxvAhNs5Xzc6HW4NF0Cp8L8WGvizOmTT7SyVI41q8DSKzGjnN4MVuf
kMDZNR0cDyf4/GgKuCOJceQc51D5MqQ88HJAxgELNyQ7IO8JqxZ9th8bHfLe
YvNYLQTwKaVJwScu4AEE4R7jQud3dxjHIQEC5ELFQTRLcERoCXkPlgixHyeX
0B8Wmxo/J39mJODSMq80axuW0n+6HF/BgGZipWIDLWWRLjZWSCOeLARkrvSM
EZdIkTq2xSARsuVcyInuhHSf7dxMyeWapDz13AixSx+l0wmkWnrYwVziaWLS
yKN9uxRlXVGTuqINnJZIYU9DhOywogdlpIjZhG4t4ycwlJYcqTu2vXhemvEE
pQyFMbLkduHWyghA1A5RlayQS7cYCmBCboSxq3BNckM/R+yGH1EDibmvXyOj
3OXYQNNv6qqpsqqQmjD5kcHtzSXCQ23hqUIcYp9XTaRMB0rE8QXZNC2+kLPS
sYQDrfAmtnCWYlLKkwyIjUInciI52RMja0YBNBDHptgtZba2WhgyyIh6mRhy
H6l9eko/Wo/X5oZpJiVG7UIJUdSJ6xLQTAJnlDrw2kzZ1zeImgAhTN1sVUua
STXGdmy37Uh9D9YlotBgd/wdfIuL9JL2hOpgmbls3DAk2pizFD1ouc9UrCY/
ky5hwemKahVatLzH21hD89WCqjHLVet94LScJNwt28MZha30HRG+Ys+E9B5y
JO2bWAJNeW7zAIALR9mXBO6C6//JtIDNaC0AeOhmzyPDVM4pC3sWw6d1tYCe
zxwpKU1meRTuwRYRv0QxpGSO1JmVUk+P1c9O81UG/i5aerBKibvBS7R6YQoC
qE0INFSGmtHa80VEMceX72739BJB3k1AtCsfq4KzNaABuShkEidQA+IoDfeM
ICXV3dD0UHJIdQzKS2z0EWy0SCczIeGWVMQmSR72L5gXMGabGdJnsnWL5AV+
dLXEKl1aSUp8dnHd5khBKoTAHg0ixqSwgQjIcdwPp8TuZ5SJXm3xig8l3MMc
/8vJuQcGwnHR1vOU7Y4xI7mQfp4gRzICCjVynodN1e2CKJI1eNVFqyFPjNXj
NEr1DGclUp+qoQYjdR1L44H4JNjIRc4GLb/xUsOKhXOBoy5mAIJvwdvEF9Ww
wbYy42oYCt9K4wAcY9iRMewYqffgVPe9ZQ7XSjgxMmA7Vea+pOZ000RFzo5l
bZ02MRznlWwQPWRTr7gmGvNBqhhhSwldFFFNQUC4iz9nVNxwgoRD7fPVG6gu
woRpGNDUdgb3UYun6O4QzuNtQcyyu9IyQkkWJtP4MC7Yh6zQXjX0KKa0gVNE
utrbKNP2qGNo1ha66NvdajK8pwXpapaoiFiq8wJsG5SREBSiZes9+FyquISl
etcAvitdgHL9pb+DLc8Otzx7JUvsY8KhfqWP9Gt9rN/ot/q3v+YZL/Ld8H/5
f7zKL/jf/buz4Z///Gem7JfbX25+IbWjX2CKH9dsnzxuw1xl/BdpSf++9o2f
BFqWlLu26//yRXZv/4u0bKz9K1fp+PL8jzPlG+YK9+hMTWaHwAVfpOVLmwzk
DrkhP3nz+4Pdf4CWv/9vOy3/uL701v7HaNlc+1eu8m2+JKDtW7Rs+eXR1I6j
priEPQRcCh4Hx8AQ5NGe0/K3X3mCzb+/fV1f/s6//wf6sl3+6tOJfuFse/NM
fTm/39kWIHY+K0Vl4xN1wtGxpgQZmb7XfLNK0GNWVhTtOpC0bCR+hjvUiSSB
EOg+31TiW5kDR8HB39KyFJ+21ef17XBaUF7teb4LwVYmS/mRIzyCuhTawyIU
MeeVb4aM9eSqAAicL+xAIlfPOJEMSTj1+1TDfl4xuLscU5MRiJ7ZJiCPWVFN
TCH3G2EuReEKYJH2CywhApOa7rbCaACOvc6QtlwtFwMIjAwXayCFj73egWtO
ecC8EzxGsu0p6nor1bpaDtxyyYS7IeEUi4FQA/E1XkpqoyBy7qIiVLknIyJ2
kjUDPqalgRF+khIi5bqSDVA6jLXprkAt3GzexLtOGwq+cx6U21i3W5V0aoae
lH7SzQeE1mbLZZW066juBiDp4WGxxhYguaaiemO6FRdoKWxYL5eu1FekuNb6
YGsw8Ia07yLgco4y46ARN6nmJTXTbQGJfB7xgeG0ouqZxBoQx3fswPJ2T3eM
CoA7ZwneRy6yrkaueb7WwGACvr1cPMVtYR+WI9+NF66BHXdVs4pY7B5NhpUX
S5gJtuwwBg8ZdN93TyI9khh0xNDOpA9gYkncqTpLFN0NFhhvHz4Cu11yOVdg
crfSjPFt3Vutm29S/hqv06YI9bwbYbN9kW6F/0QbekJOMC+Gnvsf9/f1gM0k
7MpWvf/xjdWDwprkOZK1jjM4JMZMe2wI+VCXAvk5a15JVhKqIhH883keJawl
pbXAnuuSL/naAl9szSmq6kFHiwlZDcSScNO31Zu+mDryugvIul+UU5mBFnDm
VOFpmRdWb72wGus5rLiVHy3y9W2o2oHcC36mjFeKGZJFOnlTO/JNeCLqTFeQ
q5rr4dflrCLDZOSwrSxPzEk7w6Nw6Ho45D2ei4xPRq7NWv9GrAHnegg6xhp+
uBOf7sT4Mlnzsdi7U4odHPfg+PJ2N1SCGEJ2F+7iQClzVrG3Q1JEytiDUgk9
WIOTzkpLWdFwuk11BLlb7FcuYllCJblzWlTb0IYgGPZ3iWGJf08FmQzm+JcM
DtlksFe/UcbhxJ/OYLIMASs601jZ8b26MOV6dSi4Lri5xksGHhhMpx6kx94N
9eeP5AZirYYvFZIEnXo4uKm3bNosPZT1LkIZJESxYv2FDJR3JuG3VxCi2Fmx
inXARZV3ncNqYnzENfAwLJquwSSbuwLBQmrQ3ePt+q/awtBI3QRTZ7Ag4Kln
7jjO3BZL31X/pbbiJUZwrXyx5FskqZlzIQmGRNUmqPi41DHGtS8tJEURaggI
tUDb66bgum/VSJW6WKvN+DlSVzwuNDDUz5Uo3POE0levKil3AuJfhP1JKA7x
uyV0o4VxO7lSQJ8Ez7YZ53llkkzufL1acuRLkt3oCnoJMKucMCnxB2e8KhMz
vKaLCFKpM1dz+VONs3UGYKd/qM1yrgdn12fjH3Z1XfVbB0TP9zoN3WsroRyM
EufaFYtVGoqYL+SVguxDcxdBT8aKG/d5XbBSUuskdMXALJMe+p69R1AW+rRS
wNGLXEKOXHd0xuY68w6KquKVzKN9dpUlwqfrqW2iDaV2vk+nVIEyj9WChBoK
391V10j9+Dx8fhj/pY3BvUqgpB1cdmVUHDaSO5fzTUP76jIUopkiuX+3hZu5
ruKrZI0vOWkTHfIzBJTZZdM1oP8dlrxHfSoUPWOuEO6s8niPK5BVLg7UdmaT
pnT2GWNMG6JFWH0M0bO0CBjUF4BxCrBjstAh6uMjySQHbyXP3+V+lJiU1bZF
0iqBpW29moN1CsIHFxdnu1FxL135MLysKKuJK4ZfOlIl7hjvq8xxpFhKtuWk
n2JI1Xe+9Z3at/snJy+Pj0ZajtOhL+k1aqE4n+tCLtyobfAxjT8bl78bOJos
z9aKE88YII+Ojw85QPaheXdTso0PzFO2/wBPo23LpVPIj37jVRE6+AI9e+EW
IYJa6gWy3zwF9Uim9zatOiYqUWWInz5qZEZ9ez2ZmsfK5T7c/gVCTZmme6HX
YpjH/sRnXU6UA5OB1uJFL1+pyOaQdz07yGVyhtTUQqoMlAfEyqOoKeVVd2fP
Bexmi0oibyULTuIXJNchtzbBCpGmV/SStbrS11BKX9QpzTf3JE/poCCfG1uL
vRKBxmvfJICHe0VuYopXrt2tSujGK2dRKnRnqKa1NC872Zk4XRhpa17GV608
cgjLmXf/NqDTTr4DUAkC49tRRvrYnnMlShjstImbb3k3IhY4THx3sz2jCFnA
c4edYxgKTRp8QRZh6DLcu7B9qucXzOTrObOO6mHordJS+tzu3o8PXx/LG57B
YoOfGMAjRIez+VZS23tD6UmCfBkhCECQfuDWklOATH3HSTVKSj6IMOuiMrno
X1dQSBidtl5QEIraRi9lMJ6ehc6J0HgY3jbtoPxJhMWhaMdtT2u6u3m0peNG
dM61SI2kOSq8TkK9glErwfGIZUvB1dxrIXJrO6VC+KHN4BDyePvOd9dQWjOz
4U0aMnw1aF3KrdyMmfrlacXJCKObof7j7elu26RLfKUmV4G8oZWkXd5kdUUh
hpKGeWjyCOVM1TU2dFBdnKl93uMAFWJBkxiejG/kFSEVWuICGBWU0h1cXnhq
/WSvZ0J6Q2K5KT6l4k47XZoFBZJ1qP/iWfNEEoHo5Q8RPQGweOUaVZS0ZWmo
NUvhjIS24DyQJ+UwhIg0YjcZO1IGvzQGpkzxtVz3IPuzlwX67pVsDiOp37FD
VkEi7KxCYcF77hnnRsKlgFFqV+Gm464ZamLX1DDf3lUL9hGs275dIP6Z3np5
oe9idSy29odkT41xvGDfmdxm+taxbXt3y9RpDSR/Ft3aZeKqz94LFPNt6y9J
3zTZFmXO6btRPKqaUaKBhCN9FSdu0L7J37bLjXotL7nlNTgtqji1mzEnkKhm
DGmxTozu4Q05Jy/9iePkm/uvvFPDgciGBpjn5+0hN0wgkihcDuIrlsP4iuVu
C4LvBR954IDHkApxMaJFX12NsHsDMzxcxnJMNyO+oPJcEv3e5qBMkRkFFL1A
eCEeRSarricx/JJo/PCJWoseLN85LKjkiZCM0LCZQccERnXdnd9apW1ZhOG4
PCaN8Q2Q1mUlKRgp2do2XT2Bdl6VjD0o9UhOnqzl91TaQwr9z0LWCddWwf26
IvQN9y0GocVAErB57k7sEsg9aUwokrbG7g6H3FCgp7bQ6TKGg67SptoD84tG
Fx0+jGPTpmSQzuXo1DH1XrLjNo5YRdz+0lnoWPAcKHsaRaM3+lgqFWF2CONp
fTT6kSW5wEbMo53KHeShG830cCh1vHEbmRSc5KVYPlsC1BSBbpZ2tgHEyaER
8h6pf0EmI33ukRLalMpMvR3J1/ZeC4WwfjYL1VuYssL4TkrDIZ2QX9cmFqBe
UgoPveAMBVRMeuLpuYhE10BcHDsXZxjNqR3Vdl0uKeiwgDuyGbKBzgW39FJ1
Ak4dlCFXpYYaH9+lK21NrzlWws+8kl1g62GuBIibcGWyGR9IZqv4zkQSZ6Vz
iSPhN6Jgb4UtsJKxISWyUjnqCqR74UAC7TpvEycg4bPFVLWBufW0DL7iHVDM
lPgKI+YyorKJ74wwWwUg3e7h25eT2jL5RiLLqDZ8JqxLGFzea+SiQUE5R9Tq
2uSu0r7kulVXzItOIDaUJnwWIKAiVwUMxO0Y7nctgS/0xfhq/EyE/JA7nh5E
LZH7u1kZOqZCETe257BWBbC5Vu1/syL57+WEjqy7cGcONLsj11ZT7p6CH0i6
p+KLPFQRXieZeXgVINxpEcIdEtoQzBWGId2woac9cVr9Bim++cK/gZpem8yt
5eJgZtMJ1KwT/5W//m/hL50SWdMndjKt8Nu/9d50/nc2pXH2EB1PeNvvfl4t
wKKfCCGvS9tehsZWZIQr+W/RUKQjtxODCof19uCnpobf0D9Avf+qP3DsAZah
u/qSOztzdtlw3sRaGKeDeIOmdA1zjf7ph8tTmKVb6PNHevWlpSZ9yxiqOF0V
CVldFhX/Ow3UlKrU/wD5JxZBWUkAAA==

-->
</rfc>