<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="info" consensus="false" docName="draft-bormann-core-overview-01" indexInclude="true" ipr="trust200902" prepTime="2020-03-30T11:06:40" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <!-- xml2rfc v2v3 conversion 2.39.0 -->
  <front>
    <title abbrev="CoRE Working Group -- Overview">CoRE Working Group -- Overview</title>
    <seriesInfo name="Internet-Draft" value="draft-bormann-core-overview-01" stream="IETF"/>
    <author initials="C." surname="Bormann" fullname="Carsten Bormann">
      <organization ascii="Universitaet Bremen TZI" showOnFrontPage="true">Universität Bremen TZI</organization>
      <address>
        <postal>
          <street>Postfach 330440</street>
          <city>Bremen</city>
          <code>D-28359</code>
          <country>Germany</country>
        </postal>
        <phone>+49-421-218-63921</phone>
        <email>cabo@tzi.org</email>
      </address>
    </author>
    <author initials="J." surname="Jiménez" fullname="Jaime Jiménez">
      <organization showOnFrontPage="true">Ericsson</organization>
      <address>
        <phone>+358-442-992-827</phone>
        <email>jaime@iki.fi</email>
      </address>
    </author>
    <date month="03" year="2020" day="30"/>
    <keyword>Internet-Draft</keyword>
    <abstract pn="section-abstract">
      <t pn="section-abstract-1">The IETF "Constrained RESTful Environments" (CoRE) Working Group standardizes application layer protocols that can be used by resource-constrained devices, as can be found in the Internet of Things (IoT).  It is part of a cluster of about a dozen IETF WGs defining specifications for these environments.</t>
      <t pn="section-abstract-2">This short document provides an overview of the activities of the CoRE WG as of end of March, 2020.</t>
    </abstract>
    <note removeInRFC="false" pn="section-note.1">
      <name slugifiedName="name-about-this-document">About This Document</name>
      <t pn="section-note.1-1">This document is not intended for publication as an RFC.  It provides
a snapshot of the current status of the WG, from the personal view of
the authors.  The intention is to keep it updated, roughly once per
physical IETF meeting (or its digital replacement).</t>
    </note>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t pn="section-boilerplate.1-1">
        This Internet-Draft is submitted in full conformance with the
        provisions of BCP 78 and BCP 79.
        </t>
        <t pn="section-boilerplate.1-2">
        Internet-Drafts are working documents of the Internet Engineering Task
        Force (IETF). Note that other groups may also distribute working
        documents as Internet-Drafts. The list of current Internet-Drafts is
        at <eref target="https://datatracker.ietf.org/drafts/current/" brackets="none"/>.
        </t>
        <t pn="section-boilerplate.1-3">
        Internet-Drafts are draft documents valid for a maximum of six months
        and may be updated, replaced, or obsoleted by other documents at any
        time. It is inappropriate to use Internet-Drafts as reference
        material or to cite them other than as "work in progress."
        </t>
        <t pn="section-boilerplate.1-4">
        This Internet-Draft will expire on 1 October 2020.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t pn="section-boilerplate.2-1">
            Copyright (c) 2020 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-main-specification">Main Specification</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security">Security</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t keepWithNext="true" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-operations-and-management">Operations and Management</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t keepWithNext="true" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-data-formats">Data Formats</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t keepWithNext="true" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-further-information">Further Information</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t keepWithNext="true" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t keepWithNext="true" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t keepWithNext="true" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t pn="section-1-1">The IETF "Constrained RESTful Environments" (CoRE) Working Group standardizes application layer protocols that can be used by resource-constrained devices, as can be found in the Internet of Things (IoT).  It is part of a cluster of about a dozen IETF WGs that define networking (e.g., 6Lo), routing (e.g., ROLL), and security (e.g., ACE, LAKE, SUIT) for these environments.  This cluster has been growing since 2005; ten years ago, on 2010-03-09, CoRE was added to it.</t>
    </section>
    <section anchor="main-specification" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-main-specification">Main Specification</name>
      <t pn="section-2-1">The main specification of CoRE is the Constrained Application Protocol (CoAP) <xref target="RFC7252" format="default" sectionFormat="of" derivedContent="RFC7252"/>.  CoAP is for applications including constrained devices what HTTP is for general purpose applications. By using UDP as the transport protocol as opposed to HTTP's use of TCP, and by removing much of the baggage of of HTTP, CoAP can be run on quite simple platforms and with very little power use.  Both protocols share the Representational State Transfer (REST) architecture, the same set of verbs (GET, PUT, POST, DELETE), and quite similar semantics.</t>
      <t pn="section-2-2">Since CoAP's approval in 2013, further specifications have been added to support the Observe pattern of change notifications from a server (low-complexity server-push) <xref target="RFC7641" format="default" sectionFormat="of" derivedContent="RFC7641"/>, to support larger transfers <xref target="RFC7959" format="default" sectionFormat="of" derivedContent="RFC7959"/>, to add verbs (FETCH, PATCH, and idempotent iPATCH <xref target="RFC8132" format="default" sectionFormat="of" derivedContent="RFC8132"/>), and to enable the use of CoAP over TCP <xref target="RFC8323" format="default" sectionFormat="of" derivedContent="RFC8323"/>.  <xref target="RFC8768" format="default" sectionFormat="of" derivedContent="RFC8768"/> recently added a way to detect and mitigate loops in a proxy configuration, motivated by the requirements of the Distributed Denial-of-Service Open Threat Signaling (DOTS <xref target="I-D.ietf-dots-signal-channel" format="default" sectionFormat="of" derivedContent="I-D.ietf-dots-signal-channel"/>) specification.</t>
      <t pn="section-2-3">Two further extensions are now in completion: reducing the need for per-request state in clients and proxies <xref target="I-D.ietf-core-stateless" format="default" sectionFormat="of" derivedContent="I-D.ietf-core-stateless"/> (in IETF last call) and improving the security between multiple active requests <xref target="I-D.ietf-core-echo-request-tag" format="default" sectionFormat="of" derivedContent="I-D.ietf-core-echo-request-tag"/>, further reducing CoAP's exploitability in denial of service attacks (completed working-group last call).</t>
    </section>
    <section anchor="security" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-security">Security</name>
      <t pn="section-3-1">Security has always been a critical enabler for IoT.  Similar to the way the HTTP web uses TLS, CoAP was kicked off with a security architecture based on Datagram TLS (DTLS), which provides high levels of security, but does not support end-to-end security in a configuration that includes proxies.
Object Security for CoRE (OSCORE) now provides end-to-end security over proxy paths that may include both CoAP and HTTP <xref target="RFC8613" format="default" sectionFormat="of" derivedContent="RFC8613"/>.</t>
      <t pn="section-3-2">One interesting aspect of OSCORE is that it also supports group communication, as it occurs in multicasting requests to collect responses from a group of nodes.  CoAP has supported multicast requests from the outset, and <xref target="RFC7390" format="default" sectionFormat="of" derivedContent="RFC7390"/>,
Group Communication on top of IP multicast, provides additional specification for this.  As DTLS only supports unicast, without a security architecture RFC 7390 was published an experimental RFC.  Work is now underway to revise this  RFC <xref target="I-D.ietf-core-groupcomm-bis" format="default" sectionFormat="of" derivedContent="I-D.ietf-core-groupcomm-bis"/>, which includes making use of the capabilities provided by OSCORE for group communication <xref target="I-D.ietf-core-oscore-groupcomm" format="default" sectionFormat="of" derivedContent="I-D.ietf-core-oscore-groupcomm"/>.  Work is now under way in the CoRE, ACE, and LAKE working groups to complement this basis with additional specifications making use of OSCORE and CoAP group communication.</t>
    </section>
    <section anchor="operations-and-management" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-operations-and-management">Operations and Management</name>
      <t pn="section-4-1">IoT systems need to support a large number of nodes, which need to be configured and integrated into an IoT system.  A discovery and self-description architecture based on web links has been the first product of the WG <xref target="RFC6690" format="default" sectionFormat="of" derivedContent="RFC6690"/>, which is now being complemented by a registration and discovery function (CoRE Resource Directory <xref target="I-D.ietf-core-resource-directory" format="default" sectionFormat="of" derivedContent="I-D.ietf-core-resource-directory"/>, in IESG processing).</t>
      <t pn="section-4-2">Constrained nodes also need management functions.  While many IoT SDOs are integrating these right into their IoT data format specifications, the IETF has its own architecture for describing management information, YANG <xref target="RFC7950" format="default" sectionFormat="of" derivedContent="RFC7950"/>.  The "CORECONF" specifications that are in Working Group Last Call (including YANG-CBOR <xref target="I-D.ietf-core-yang-cbor" format="default" sectionFormat="of" derivedContent="I-D.ietf-core-yang-cbor"/>) make this widely used approach of providing management interfaces available in a highly efficient way that is applicable to constrained environments, as our complement to the established YANG protocols NETCONF and RESTCONF.</t>
    </section>
    <section anchor="data-formats" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-data-formats">Data Formats</name>
      <t pn="section-5-1">While CoAP can be used with many different data formats, a simple CoRE format for sensor and actuator data, Sensor Measurement Lists (SenML), was defined in <xref target="RFC8428" format="default" sectionFormat="of" derivedContent="RFC8428"/>.  Recently, a number of specifications have been readied in support of SenML that are now undergoing final processing by the RFC editor:  Support for the RFC 8132 verbs <xref target="I-D.ietf-core-senml-etch" format="default" sectionFormat="of" derivedContent="I-D.ietf-core-senml-etch"/>, and modifications to the SenML units registry <xref target="I-D.ietf-core-senml-more-units" format="default" sectionFormat="of" derivedContent="I-D.ietf-core-senml-more-units"/> that make it more accessible as a basis for data format standards of other Standards Development Organizations (SDOs).
A foundation for further data format specification that combines the web-linking approach of RFC 6690 with more modern data representation techniques is now being worked on under the name CoRAL <xref target="I-D.ietf-core-coral" format="default" sectionFormat="of" derivedContent="I-D.ietf-core-coral"/> <xref target="I-D.ietf-core-href" format="default" sectionFormat="of" derivedContent="I-D.ietf-core-href"/>; application specifications such as CoAP pubsub <xref target="I-D.ietf-core-coap-pubsub" format="default" sectionFormat="of" derivedContent="I-D.ietf-core-coap-pubsub"/> are expected to pivot to this basis.</t>
    </section>
    <section anchor="further-information" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-further-information">Further Information</name>
      <t pn="section-6-1">To follow and contribute to CoRE's work, please refer to the core status page (<eref target="https://tools.ietf.org/wg/core/" brackets="none">https://tools.ietf.org/wg/core/</eref>) and join the core mailing list: <em>core@ietf.org</em> via <eref target="https://www.ietf.org/mailman/listinfo/core" brackets="none">https://www.ietf.org/mailman/listinfo/core</eref>.</t>
    </section>
  </middle>
  <back>
    <references pn="section-7">
      <name slugifiedName="name-informative-references">Informative References</name>
      <reference anchor="I-D.ietf-core-coap-pubsub" target="http://www.ietf.org/internet-drafts/draft-ietf-core-coap-pubsub-09.txt" quoteTitle="true" derivedAnchor="I-D.ietf-core-coap-pubsub">
        <front>
          <title>Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)</title>
          <seriesInfo name="Internet-Draft" value="draft-ietf-core-coap-pubsub-09"/>
          <author initials="M" surname="Koster" fullname="Michael Koster">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="A" surname="Keranen" fullname="Ari Keranen">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="J" surname="Jimenez" fullname="Jaime Jimenez">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="September" day="30" year="2019"/>
          <abstract>
            <t>The Constrained Application Protocol (CoAP), and related extensions are intended to support machine-to-machine communication in systems where one or more nodes are resource constrained, in particular for low power wireless sensor networks.  This document defines a publish- subscribe Broker for CoAP that extends the capabilities of CoAP for supporting nodes with long breaks in connectivity and/or up-time.  There is work in progress to resolve some of the transfer layer issues by using a more RESTful approach.  Please see https://github.com/core-wg/pubsub/blob/master/proposal.txt</t>
          </abstract>
        </front>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="I-D.ietf-core-coral" target="http://www.ietf.org/internet-drafts/draft-ietf-core-coral-03.txt" quoteTitle="true" derivedAnchor="I-D.ietf-core-coral">
        <front>
          <title>The Constrained RESTful Application Language (CoRAL)</title>
          <seriesInfo name="Internet-Draft" value="draft-ietf-core-coral-03"/>
          <author initials="K" surname="Hartke" fullname="Klaus Hartke">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="March" day="9" year="2020"/>
          <abstract>
            <t>The Constrained RESTful Application Language (CoRAL) defines a data model and interaction model as well as two specialized serialization formats for the description of typed connections between resources on the Web ("links"), possible operations on such resources ("forms"), and simple resource metadata.</t>
          </abstract>
        </front>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="I-D.ietf-core-echo-request-tag" target="http://www.ietf.org/internet-drafts/draft-ietf-core-echo-request-tag-09.txt" quoteTitle="true" derivedAnchor="I-D.ietf-core-echo-request-tag">
        <front>
          <title>CoAP: Echo, Request-Tag, and Token Processing</title>
          <seriesInfo name="Internet-Draft" value="draft-ietf-core-echo-request-tag-09"/>
          <author initials="C" surname="Amsuess" fullname="Christian Amsuess">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="J" surname="Mattsson" fullname="John Mattsson">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="G" surname="Selander" fullname="Goeran Selander">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="March" day="9" year="2020"/>
          <abstract>
            <t>This document specifies enhancements to the Constrained Application Protocol (CoAP) that mitigate security issues in particular use cases.  The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address; it is now the recommeded way to mitigate amplification attacks.  The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. The update to the client Token processing requirements of RFC 7252 forbids non-secure reuse of Tokens to ensure binding of responses to requests when CoAP is used with security.</t>
          </abstract>
        </front>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="I-D.ietf-core-groupcomm-bis" target="https://www.ietf.org/internet-drafts/draft-ietf-core-groupcomm-bis-00.txt" quoteTitle="true" derivedAnchor="I-D.ietf-core-groupcomm-bis">
        <front>
          <title>Group Communication for the Constrained Application Protocol (CoAP)</title>
          <seriesInfo name="Internet-Draft" value="draft-ietf-core-groupcomm-bis-00"/>
          <author fullname="Esko Dijk">
            <organization showOnFrontPage="true">IoTconsultancy.nl</organization>
          </author>
          <author fullname="Chonggang Wang">
            <organization showOnFrontPage="true">InterDigital</organization>
          </author>
          <author fullname="Marco Tiloca">
            <organization showOnFrontPage="true">RISE AB</organization>
          </author>
          <date month="March" day="30" year="2020"/>
          <abstract>
            <t>   This document specifies the use of the Constrained Application
   Protocol (CoAP) for group communication, using UDP/IP multicast as
   the underlying data transport.  Both unsecured and secured CoAP group
   communication are specified.  Security is achieved by use of the
   Group Object Security for Constrained RESTful Environments (Group
   OSCORE) protocol.  The target application area of this specification
   is any group communication use cases that involve resource-
   constrained networks.  The most common of such use cases are also
   discussed.  This document replaces [RFC7390] and updates [RFC7252]
   and [RFC7641].

            </t>
          </abstract>
        </front>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="I-D.ietf-core-href" target="http://www.ietf.org/internet-drafts/draft-ietf-core-href-03.txt" quoteTitle="true" derivedAnchor="I-D.ietf-core-href">
        <front>
          <title>Constrained Resource Identifiers</title>
          <seriesInfo name="Internet-Draft" value="draft-ietf-core-href-03"/>
          <author initials="K" surname="Hartke" fullname="Klaus Hartke">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="March" day="9" year="2020"/>
          <abstract>
            <t>The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that serializes the URI components in Concise Binary Object Representation (CBOR) instead of a sequence of characters.  This simplifies parsing, comparison and reference resolution in environments with severe limitations on processing power, code size, and memory size.</t>
          </abstract>
        </front>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="I-D.ietf-core-oscore-groupcomm" target="http://www.ietf.org/internet-drafts/draft-ietf-core-oscore-groupcomm-07.txt" quoteTitle="true" derivedAnchor="I-D.ietf-core-oscore-groupcomm">
        <front>
          <title>Group OSCORE - Secure Group Communication for CoAP</title>
          <seriesInfo name="Internet-Draft" value="draft-ietf-core-oscore-groupcomm-07"/>
          <author initials="M" surname="Tiloca" fullname="Marco Tiloca">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="G" surname="Selander" fullname="Goeran Selander">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="F" surname="Palombini" fullname="Francesca Palombini">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="J" surname="Park" fullname="Jiye Park">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="March" day="9" year="2020"/>
          <abstract>
            <t>This document defines Group Object Security for Constrained RESTful Environments (Group OSCORE), providing end-to-end security of CoAP messages exchanged between members of a group, e.g. using IP multicast.  In particular, the described approach defines how OSCORE should be used in a group communication setting to provide source authentication for CoAP group requests, sent by a client to multiple servers, and the corresponding CoAP responses.</t>
          </abstract>
        </front>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="I-D.ietf-core-resource-directory" target="http://www.ietf.org/internet-drafts/draft-ietf-core-resource-directory-24.txt" quoteTitle="true" derivedAnchor="I-D.ietf-core-resource-directory">
        <front>
          <title>CoRE Resource Directory</title>
          <seriesInfo name="Internet-Draft" value="draft-ietf-core-resource-directory-24"/>
          <author initials="Z" surname="Shelby" fullname="Zach Shelby">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="M" surname="Koster" fullname="Michael Koster">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="C" surname="Bormann" fullname="Carsten Bormann">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="P" surname="Stok" fullname="Peter van der Stok">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="C" surname="Amsuess" fullname="Christian Amsuess">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="March" day="9" year="2020"/>
          <abstract>
            <t>In many IoT applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient.  These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources.  The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD.  This document specifies the web interfaces that a Resource Directory supports for web servers to discover the RD and to register, maintain, lookup and remove information on resources.  Furthermore, new target attributes useful in conjunction with an RD are defined.</t>
          </abstract>
        </front>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="I-D.ietf-core-senml-etch" target="http://www.ietf.org/internet-drafts/draft-ietf-core-senml-etch-07.txt" quoteTitle="true" derivedAnchor="I-D.ietf-core-senml-etch">
        <front>
          <title>FETCH &amp; PATCH with Sensor Measurement Lists (SenML)</title>
          <seriesInfo name="Internet-Draft" value="draft-ietf-core-senml-etch-07"/>
          <author initials="A" surname="Keranen" fullname="Ari Keranen">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="M" surname="Mohajer" fullname="Mojan Mohajer">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="March" day="9" year="2020"/>
          <abstract>
            <t>The Sensor Measurement Lists (SenML) media type and data model can be used to send collections of resources, such as batches of sensor data or configuration parameters.  The CoAP FETCH, PATCH, and iPATCH methods enable accessing and updating parts of a resource or multiple resources with one request.  This document defines new media types for the CoAP FETCH, PATCH, and iPATCH methods for resources represented with the SenML data model.</t>
          </abstract>
        </front>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="I-D.ietf-core-senml-more-units" target="http://www.ietf.org/internet-drafts/draft-ietf-core-senml-more-units-06.txt" quoteTitle="true" derivedAnchor="I-D.ietf-core-senml-more-units">
        <front>
          <title>Additional Units for SenML</title>
          <seriesInfo name="Internet-Draft" value="draft-ietf-core-senml-more-units-06"/>
          <author initials="C" surname="Bormann" fullname="Carsten Bormann">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="March" day="19" year="2020"/>
          <abstract>
            <t>The Sensor Measurement Lists (SenML) media type supports the indication of units for a quantity represented.  This short document registers a number of additional unit names in the IANA registry for Units in SenML.  It also defines a registry for secondary units that cannot be in SenML's main registry as they are derived by linear transformation from units already in that registry.</t>
          </abstract>
        </front>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="I-D.ietf-core-stateless" target="http://www.ietf.org/internet-drafts/draft-ietf-core-stateless-05.txt" quoteTitle="true" derivedAnchor="I-D.ietf-core-stateless">
        <front>
          <title>Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)</title>
          <seriesInfo name="Internet-Draft" value="draft-ietf-core-stateless-05"/>
          <author initials="K" surname="Hartke" fullname="Klaus Hartke">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="March" day="12" year="2020"/>
          <abstract>
            <t>This document provides considerations for alleviating CoAP clients and intermediaries of keeping per-request state.  To facilitate this, this document additionally introduces a new, optional CoAP protocol extension for extended token lengths.  This document updates RFCs 7252 and 8323.</t>
          </abstract>
        </front>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="I-D.ietf-core-yang-cbor" target="http://www.ietf.org/internet-drafts/draft-ietf-core-yang-cbor-12.txt" quoteTitle="true" derivedAnchor="I-D.ietf-core-yang-cbor">
        <front>
          <title>CBOR Encoding of Data Modeled with YANG</title>
          <seriesInfo name="Internet-Draft" value="draft-ietf-core-yang-cbor-12"/>
          <author initials="M" surname="Veillette" fullname="Michel Veillette">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="I" surname="Petrov" fullname="Ivaylo Petrov">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="A" surname="Pelov" fullname="Alexander Pelov">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="March" day="9" year="2020"/>
          <abstract>
            <t>This document defines encoding rules for serializing configuration data, state data, RPC input and RPC output, Action input, Action output, notifications and yang data template defined within YANG modules using the Concise Binary Object Representation (CBOR) [RFC7049].</t>
          </abstract>
        </front>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="I-D.ietf-dots-signal-channel" target="http://www.ietf.org/internet-drafts/draft-ietf-dots-signal-channel-41.txt" quoteTitle="true" derivedAnchor="I-D.ietf-dots-signal-channel">
        <front>
          <title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification</title>
          <seriesInfo name="Internet-Draft" value="draft-ietf-dots-signal-channel-41"/>
          <author initials="T" surname="Reddy.K" fullname="Tirumaleswar Reddy.K">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="M" surname="Boucadair" fullname="Mohamed Boucadair">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="P" surname="Patil" fullname="Prashanth Patil">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="A" surname="Mortensen" fullname="Andrew Mortensen">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="N" surname="Teague" fullname="Nik Teague">
            <organization showOnFrontPage="true"/>
          </author>
          <date month="January" day="6" year="2020"/>
          <abstract>
            <t>This document specifies the DOTS signal channel, a protocol for signaling the need for protection against Distributed Denial-of- Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client.  A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes.  Editorial Note (To be removed by RFC Editor)  Please update these statements within the document with the RFC number to be assigned to this document:  o  "This version of this YANG module is part of RFC XXXX;"  o  "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification";  o  "| [RFCXXXX] |"  o  reference: RFC XXXX  Please update this statement with the RFC number to be assigned to the following documents:  o  "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification (used to be I-D.ietf-dots-data- channel)  Please update TBD/TBD1/TBD2 statements with the assignments made by IANA to DOTS Signal Channel Protocol.  Also, please update the "revision" date of the YANG modules.</t>
          </abstract>
        </front>
        <refcontent>Work in Progress</refcontent>
      </reference>
      <reference anchor="RFC6690" target="https://www.rfc-editor.org/info/rfc6690" quoteTitle="true" derivedAnchor="RFC6690">
        <front>
          <title>Constrained RESTful Environments (CoRE) Link Format</title>
          <seriesInfo name="RFC" value="6690"/>
          <seriesInfo name="DOI" value="10.17487/RFC6690"/>
          <author initials="Z." surname="Shelby" fullname="Z. Shelby">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2012" month="August"/>
          <abstract>
            <t>This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links.  Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type.  "RESTful" refers to the Representational State Transfer (REST) architecture.  A well-known URI is defined as a default entry point for requesting the links hosted by a server.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7252" quoteTitle="true" derivedAnchor="RFC7252">
        <front>
          <title>The Constrained Application Protocol (CoAP)</title>
          <seriesInfo name="RFC" value="7252"/>
          <seriesInfo name="DOI" value="10.17487/RFC7252"/>
          <author initials="Z." surname="Shelby" fullname="Z. Shelby">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="K." surname="Hartke" fullname="K. Hartke">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="C." surname="Bormann" fullname="C. Bormann">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2014" month="June"/>
          <abstract>
            <t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks.  The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s.  The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t>
            <t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types.  CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC7390" target="https://www.rfc-editor.org/info/rfc7390" quoteTitle="true" derivedAnchor="RFC7390">
        <front>
          <title>Group Communication for the Constrained Application Protocol (CoAP)</title>
          <seriesInfo name="RFC" value="7390"/>
          <seriesInfo name="DOI" value="10.17487/RFC7390"/>
          <author initials="A." surname="Rahman" fullname="A. Rahman" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="E." surname="Dijk" fullname="E. Dijk" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2014" month="October"/>
          <abstract>
            <t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This specification defines how CoAP should be used in a group communication context.  An approach for using CoAP on top of IP multicast is detailed based on existing CoAP functionality as well as new features introduced in this specification.  Also, various use cases and corresponding protocol flows are provided to illustrate important concepts.  Finally, guidance is provided for deployment in various network topologies.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC7641" target="https://www.rfc-editor.org/info/rfc7641" quoteTitle="true" derivedAnchor="RFC7641">
        <front>
          <title>Observing Resources in the Constrained Application Protocol (CoAP)</title>
          <seriesInfo name="RFC" value="7641"/>
          <seriesInfo name="DOI" value="10.17487/RFC7641"/>
          <author initials="K." surname="Hartke" fullname="K. Hartke">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2015" month="September"/>
          <abstract>
            <t>The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks.  The state of a resource on a CoAP server can change over time.  This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time.  The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7950" quoteTitle="true" derivedAnchor="RFC7950">
        <front>
          <title>The YANG 1.1 Data Modeling Language</title>
          <seriesInfo name="RFC" value="7950"/>
          <seriesInfo name="DOI" value="10.17487/RFC7950"/>
          <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2016" month="August"/>
          <abstract>
            <t>YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols.  This document describes the syntax and semantics of version 1.1 of the YANG language.  YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification.  There are a small number of backward incompatibilities from YANG version 1.  This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC7959" target="https://www.rfc-editor.org/info/rfc7959" quoteTitle="true" derivedAnchor="RFC7959">
        <front>
          <title>Block-Wise Transfers in the Constrained Application Protocol (CoAP)</title>
          <seriesInfo name="RFC" value="7959"/>
          <seriesInfo name="DOI" value="10.17487/RFC7959"/>
          <author initials="C." surname="Bormann" fullname="C. Bormann">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="Z." surname="Shelby" fullname="Z. Shelby" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2016" month="August"/>
          <abstract>
            <t>The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks.  Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates.  In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS).  These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred.</t>
            <t>Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs.  In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers.  Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion.</t>
            <t>A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations.  Therefore, this specification updates RFC 7252.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC8132" target="https://www.rfc-editor.org/info/rfc8132" quoteTitle="true" derivedAnchor="RFC8132">
        <front>
          <title>PATCH and FETCH Methods for the Constrained Application Protocol (CoAP)</title>
          <seriesInfo name="RFC" value="8132"/>
          <seriesInfo name="DOI" value="10.17487/RFC8132"/>
          <author initials="P." surname="van der Stok" fullname="P. van der Stok">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="C." surname="Bormann" fullname="C. Bormann">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="A." surname="Sehgal" fullname="A. Sehgal">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2017" month="April"/>
          <abstract>
            <t>The methods defined in RFC 7252 for the Constrained Application Protocol (CoAP) only allow access to a complete resource, not to parts of a resource.  In case of resources with larger or complex data, or in situations where resource continuity is required, replacing or requesting the whole resource is undesirable.  Several applications using CoAP need to access parts of the resources.</t>
            <t>This specification defines the new CoAP methods, FETCH, PATCH, and iPATCH, which are used to access and update parts of a resource.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC8323" target="https://www.rfc-editor.org/info/rfc8323" quoteTitle="true" derivedAnchor="RFC8323">
        <front>
          <title>CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets</title>
          <seriesInfo name="RFC" value="8323"/>
          <seriesInfo name="DOI" value="10.17487/RFC8323"/>
          <author initials="C." surname="Bormann" fullname="C. Bormann">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="S." surname="Lemay" fullname="S. Lemay">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="K." surname="Hartke" fullname="K. Hartke">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="B." surname="Silverajan" fullname="B. Silverajan">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="B." surname="Raymor" fullname="B. Raymor" role="editor">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2018" month="February"/>
          <abstract>
            <t>The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP.  The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control.</t>
            <t>Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports.  It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC8428" target="https://www.rfc-editor.org/info/rfc8428" quoteTitle="true" derivedAnchor="RFC8428">
        <front>
          <title>Sensor Measurement Lists (SenML)</title>
          <seriesInfo name="RFC" value="8428"/>
          <seriesInfo name="DOI" value="10.17487/RFC8428"/>
          <author initials="C." surname="Jennings" fullname="C. Jennings">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="Z." surname="Shelby" fullname="Z. Shelby">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="J." surname="Arkko" fullname="J. Arkko">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="A." surname="Keranen" fullname="A. Keranen">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="C." surname="Bormann" fullname="C. Bormann">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2018" month="August"/>
          <abstract>
            <t>This specification defines a format for representing simple sensor measurements and device parameters in Sensor Measurement Lists (SenML).  Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), Extensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model.  A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or the Constrained Application Protocol (CoAP) to transport the measurements of the sensor or to be configured.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC8613" target="https://www.rfc-editor.org/info/rfc8613" quoteTitle="true" derivedAnchor="RFC8613">
        <front>
          <title>Object Security for Constrained RESTful Environments (OSCORE)</title>
          <seriesInfo name="RFC" value="8613"/>
          <seriesInfo name="DOI" value="10.17487/RFC8613"/>
          <author initials="G." surname="Selander" fullname="G. Selander">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="J." surname="Mattsson" fullname="J. Mattsson">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="F." surname="Palombini" fullname="F. Palombini">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="L." surname="Seitz" fullname="L. Seitz">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2019" month="July"/>
          <abstract>
            <t>This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE).  OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.</t>
            <t>Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration.  Therefore, this document updates RFC 7252.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC8768" target="https://www.rfc-editor.org/info/rfc8768" quoteTitle="true" derivedAnchor="RFC8768">
        <front>
          <title>Constrained Application Protocol (CoAP) Hop-Limit Option</title>
          <seriesInfo name="RFC" value="8768"/>
          <seriesInfo name="DOI" value="10.17487/RFC8768"/>
          <author initials="M." surname="Boucadair" fullname="M. Boucadair">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="T." surname="Reddy.K" fullname="T. Reddy.K">
            <organization showOnFrontPage="true"/>
          </author>
          <author initials="J." surname="Shallow" fullname="J. Shallow">
            <organization showOnFrontPage="true"/>
          </author>
          <date year="2020" month="March"/>
          <abstract>
            <t>The presence of Constrained Application Protocol (CoAP) proxies may lead to infinite forwarding loops, which is undesirable. To prevent and detect such loops, this document specifies the Hop-Limit CoAP option.</t>
          </abstract>
        </front>
      </reference>
    </references>
    <section numbered="false" anchor="acknowledgements" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t pn="section-appendix.a-1">Marco Tiloca provided comments on a draft of this document.</t>
      <!--  LocalWords:  exploitability multicasting OSCORE CORECONF
 -->
<!--  LocalWords:  NETCONF
 -->

</section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="C." surname="Bormann" fullname="Carsten Bormann">
        <organization ascii="Universitaet Bremen TZI" showOnFrontPage="true">Universität Bremen TZI</organization>
        <address>
          <postal>
            <street>Postfach 330440</street>
            <city>Bremen</city>
            <code>D-28359</code>
            <country>Germany</country>
          </postal>
          <phone>+49-421-218-63921</phone>
          <email>cabo@tzi.org</email>
        </address>
      </author>
      <author initials="J." surname="Jiménez" fullname="Jaime Jiménez">
        <organization showOnFrontPage="true">Ericsson</organization>
        <address>
          <phone>+358-442-992-827</phone>
          <email>jaime@iki.fi</email>
        </address>
      </author>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAJi2gV4AA+1ZXXLbyBF+xykm2gdLu4QsUbIscTfOypKs1UZeqkS6XMmL
awAMiVkBGAQzEE27VJVD5Ah5yTn2JjlJvu4ZgKQk3yBVLpoczEz/ff11NxTH
cWSdrLJPsjCVGgnXtCrSdcPfrBvu7Z3sDaPMpJUs8Thr5MzFiWlKWVVxahoV
m3vV3Gu1iAvplHXRnVouTJONxFXlVFMpF5/ToSiVbiR0NTNRrUeREM6kI/Fi
qewL/8OUtUzdxlKmapdj5SD81lWmqrUtdlk2ambXFkzjNldwbYkzayu6KjRZ
2p9xjWa5lQkHNvWwbbJaoz1OuwLnz8zthfhomjtdzcVlY9pa/Pef/xLj4I5I
Jkmj7p/dF8erbRm8NhLDveFevHcQH+xFsnW5aUZRDNne6WeysU5V4q13O9ZN
Mx+JD5XGJVa7P/7txNtGwU4x/fuVfyxtqvXaHqke7YHZSsGkG2PdTKa5ODjY
OzzcIw9otxyFzeyQDDqcx8Pjg1cn/LutXIMdl4rUWWKpzhk7PxyexIfD/Xi4
fxwfHZwM9/FIlVIXI5HKxPzsvuhdqLZm2a9Sl0r8qss//lOpL0HzSn+RTptq
JC4QGWtNtRKx9cPBq+P48HAYn5wM4+Ph662VjN/psp/1nd6d6SiK4WSZwEoE
LoqmuRJXF9N3YuvMVLQICGTi9mIynbWFuKjudWMqBsqW2KaI7TwKGSeJbDL9
RVkh67rQKSspCrlUjagbQxAurHC5dDC3EokSrYWQZCkaZU3bpAoJsxKeqXud
KjsQ0nb7Z3BtBoDiEtWnjzAzMc2hiRXbV2a6syvElRPailo2/FCKtECqQgv6
kZjWYSkzXxBqNvnjpYWwma7IGlurVM+C8hYSGxJmlVBrPtglh0GCBRAdrkpb
WiYj73VG9leiy3qSSdrCy/peO42nYcXj/pLMw4qCYfjvvWzSfMBw3/UxqoxT
n05J608k89N5kBZU6IXjO7bCOciEDO4jzes26eMgWa3bd2feP52ukRS2kjUs
cZ1iads0dCNC6tpe3Y+XAzFrTMk/auSMqWQhgokRm8iJaXE/oYkVYcnQzBlx
p1QttBNtTRmdDQRgM8+LpTBVyhdGdb600LbwUSmRfRSQbdihHQzVc2RpAazU
hUwp99xOcFGps6xQURR9R6BoTNamLPjrd5p+PkT/xzdrxSBXAncugm3bane+
OxBH12aHA+LWFm/H19dYhdnCKmACrNc9Oj27GIjr07/ic/LharrzrTQhJEDR
Tr0cliYKas0bs+Bk0xR71NBXPwoi8KUCkws5NwOgAuv7zPl7JwOfLAvCcEbg
Bp6026WAv4czxWQ9aX2wS1rfSGbyDl9DeOT8W8XidC2gNyGUhIPTmx3x9etf
kDWvh6+GDw+wiBbpCjJ5DQcWYYOdGZn1TJTFggLwy3Tan52rSjXAc902tYHj
1u/aFW+XAA/d9eH8hgBCCuPKytbEOB3amDtqOs4uoetfWEIdY+bsxkePAVgi
3XFd2aKShYxO5Hwu57wX/+jwwFsX0Ni0FYXhH612CqEq6wJ5iiYG2peWb15o
lwsQ3VIU2jl6bBaIMxSAo94aPFzlhc1lo1juraqREAAIGwsXTPBNiSmZN8Px
bUrLHUFMCMmpaxs14IMWNRFYZNBDaoKEuLyYDsTNB/oYT/B5fnF9Mb0IsO01
14VscBDV2KFgAjcTBh4Z+4KzGWQIPTRj7gA81zaQ1zwuBrm8Vx7APQptW3NE
SL1xYsH5cIJ0lLmkZZrLCh4GMa/XFGJR0C5thrWFWcTUQBXqM6WYX47r1uY9
9o4O9x8eBuvyYNAch13wme12nrw6CTuhYuekdxfTs1/goVP+jzwD5i9r47hu
8HI4f7x/AJQH9+ESVcmk8FELqGKAUHEjfHWnDoYHnBvh5+uj44cHYC7F/SB4
7yyJ9F3SnZmioLKEEgVxTrEvjKkpg7ALsfi8pBSa6XnbsMsGooQD76lsEJhJ
m0YhuNyBub5CnWtqVZOWtp2rSssiNrN4QnUYwR7X1NrljUIeTvQcuGOuOx9P
J6T3VXy+q5WbxZlxNra8IabwVaqARzahQPV/YXqYqM/wpOXYEsYrsyBTfEx9
o9Yo1CSSR3pWqivPiDMZgqmAi63iY4Vmo8g/5AvqGNb145mCdxfKWvh5Wwee
L6SlylMUOz7GJdf4ILSn8ATsTxAu28JpSmnuTLxHocgzwlSam07P2Mk5Aawz
vTcs5JL6XBcGdTrRBQmDahlHgmJkQySQHjK9Ay6Dh+CNUI/iOdfalSFM8ZOg
OtK2M4IqiSwAqFBQUAKxzs2Dh2zDDka5BCongQCAPfIEwxD/MxkvVELItmJ6
PQnsR1XmTqd3ihqymec4ufLfOi2BQol6QZLnEo5pZEn3AFT4RBItcp3mq64w
1/NcFOpeFda7w984EIAs6rXyDVyX4ejiYmditV5+OUE2UsMXdl96cEEAzG40
Tn6nJOsdRt7g4rc9npyNqb0hlPaqPSeMk9xnIxgtDz1EKZedOJEQw7PPCG/s
z8AAR/tECFE0rnwjCL7n1kJSGjF/ezV8LSYLQAiF7fnNCo8Emk7bKmQdd0rY
aFJoyGzBGE6lv7sHMOKMilOQIMitkZaqJ11/LeRXmNpsV84JTkEywtnfurqy
b3zRIqEAeX4MlHtwsoeMiHybeLauMAHDGRZ3dbO6drA2KGSZDkVws1fxDZUm
DU+tIDzhMnBp7x8WQncRPn3L9zxEoaIgHRnXPBDYnOi4olxVjSYKhXg/GFDP
6yeJBSRkqgmcjUFdW8UaCb7xCUmwYylccaItMYQHf4/MUnLDGaoIjxmy9jSh
PXDJI8zvARrcJD1FwVPRxm5qwKXoiSWc96G1pkwIXSwFkjrZjoK8yAAioice
rthwJDs+PR98I26P7QymkBAG2jP2MMWhODXhAtr7XlZozPyUBw4Tdon+GT0X
V461LkD6PkBUbZn49p9h3Tm/245eriMNjnzGOQm6IrTjqyE0rOQQ5jBuwavc
2vkBoEBlVBYsW/tp8lkWJDZFWb2zq1af3D3TjeWmlQaz1TwZEujoiBOoA4wP
WaJ8I91FwCNDAohzqvJhpIVmKz1nbeXHPp7f0GX6mQttAToRZ7DjCXL6uSzr
9pAiXE8nl6QwOnfqwqkOrY8L7GVPWOzjso9XrwVl7sdcFzSJVEv27uR87BuE
zvuhNgMqDUqD86HAgubKJTAnS8qCEvy4iTLfDnPRz5kTUVAWj4JC6eMjlnDj
v1KR3jHSpUypfzv97XLVPO5x7tD8tEXAPRv/9m7rMcKZr70Zj2bka+LMM9Rt
6km6YYgExGdvx7dP3b9EcxyniWmowULiBIJZgAiKpR+euTeXfmbxHPHEGFSX
maQRS95L1HnqV7lOUrnFNWoG1amlCoVf8uwcpi1ubs3GwLY+wHLFAUI2qMB3
ESgLsuNS9uFq0vkN7TYcx/CkUYZ+cJZTkyDese9tFHl0rA9cbDHzC2Mm0zO0
9iRzDQmkUzeMMc4DQCjcmKksTaWQi6aulY4ggKOY0v2T90ra1nfN4lpTYdvG
k/c05lN18O8H+AVEqOOHw2NGxG3o5Un4imy+OR6hyc60v6ijKmxnUSv49Mw8
NxRTiKZpuM+5rtOnaqPAtqYZoZULt4X3DfyQZpYw6Tztk1VVFrFyaU6JzSOH
ydax7IPpNQMlwyOBYZ5hC39ZSV95K3rv0BIBuehL6Akcz/oTsKhHDUVjFiLR
p3N4m8SNoOFOetIvnVOLaGqO0njtfS9FCxQCMjr1b4pWrULXjn+TMsJrKVOC
DJR/nQCyjomsuS9bSzPyKXFyQCIZBafRQMu3NxvTuwDd5JWmNmmTuqmc+qLg
qy8PPjS/A7Sn10+diw+JQevpA0xss4eHHzfeuT0CnqWXGvA25xJaHNsmzwmQ
dewfQgwBkPqf1PkSWet7E3K7q/Scsu+CY69WnInZD6MfGkzYSogCeYSxk85T
TmIOIvPR5xVIOBqt6LVGwBop071aren1y/ZPuXO1Hb186Qzog1WmPwO8XMxf
0uaXb/w897sJ3QvfQK/0yc+gIDcS39Paz93J78W9lqK/drFYrC6lc2CXl3SO
CgGLeBNepCaYy8jq0/QOkSxU5knWRl9HIe1V9uetymw9RBG9qTZiqguTylX7
1v05iQIv/V/DfMFfe1UNYdFPf4I4cY2zBWpIZpHbj0bHjd4+9FFdTYpEHL95
7o5Avf75/wCpu7XjvBsAAA==

-->

</rfc>
