One document matched: draft-vial-core-mirror-proxy-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC3406 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3406.xml">
<!ENTITY RFC2141 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2141.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY RFC5988 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5988.xml">
<!ENTITY I-D.ietf-core-link-format SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-link-format.xml">
<!ENTITY I-D.ietf-core-coap SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-coap.xml">
<!ENTITY I-D.arkko-core-sleepy-sensors SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.arkko-core-sleepy-sensors.xml">
<!ENTITY I-D.shelby-core-resource-directory SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.shelby-core-resource-directory.xml">
<!ENTITY I-D.ietf-core-observe SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-core-observe.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-vial-core-mirror-proxy-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title>CoRE Mirror Proxy</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Matthieu Vial" initials="M.V."
surname="Vial">
<organization>Schneider-Electric</organization>
<address>
<postal>
<street></street>
<city>Grenoble</city>
<region></region>
<code></code>
<country>FRANCE</country>
</postal>
<phone>+33 (0)47657 6522</phone>
<email>matthieu.vial@schneider-electric.com</email>
</address>
</author>
<date year="2012" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Internet</area>
<workgroup>CoRE</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>CoRE</keyword>
<keyword>Sleeping devices</keyword>
<keyword>Proxy</keyword>
<keyword>M2M</keyword>
<keyword>Resource Discovery</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document introduces the concept of Mirror Proxy that enables sleeping devices to participate in a REST architecture despite the fact that they are not web servers. Most constrained devices may sleep during long periods preventing them from acting as traditional web servers. However as client-only endpoints they can rely on a Mirror Proxy to cache and serve the content they provide.</t>
</abstract>
</front>
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<middle>
<section title="Introduction">
<t>The Constrained RESTful Environments (CoRE) working group aims at realizing the REST architecture in a suitable form for the most constrained nodes (e.g. 8-bit microcontrollers with limited RAM and ROM) and networks (e.g. 6LoWPAN). As pointed out by <xref target="I-D.arkko-core-sleepy-sensors"/>, the server model is far from being optimum for devices with high energy constraints. Since the client model seems to be the most efficient energy mode for sleeping device, this document proposes to define a new intermediary called Mirror Proxy whose role is to make a sleeping device appears like any other web server in the network. On that point, a Mirror Proxy is similar to a caching reverse proxy except that there is no origin server but rather an "origin" client. So the Mirror Proxy serves content and also advertises resources on behalf of its registered endpoints.</t>
<t>This document defines the REST interface required to support the Mirror Proxy function on a constrained web server. </t>
</section>
<!-- **************************************************************** -->
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
<t>This specification requires readers to be familiar with all the terms and concepts that are discussed in [RFC5988] and <xref target="I-D.shelby-core-resource-directory"/>. Readers should also be familiar with the terms and concepts discussed in <xref target="I-D.ietf-core-coap"/> and <xref target="I-D.ietf-core-link-format"/>. This specification makes use of the following additional terminology:</t>
<t>
<list style="hanging">
<t hangText="Sleeping endpoint (SEP):">A sleeping network node that participates in a constrained REST environment but can only act as a CoAP client endpoint due to limited energy budget. </t>
<t hangText="Mirror Proxy (MP):">A web entity that caches, serves and advertises content on behalf of a sleeping endpoint. </t>
</list>
</t>
</section>
<!-- **************************************************************** -->
<section title="Architecture">
<t>The Mirror Proxy architecture is shown in <xref target="architecture"/>. A Mirror Proxy (MP) hosts resources in its own resource tree on behalf of other web entities which are called sleeping endpoint (SEP). For energy efficiency a SEP is a client-only CoAP endpoint and hence is not able to serve content by itself. The MP implements REST interfaces allowing a SEP to maintain a set of cached resources that will be served in turn by the MP. A CoAP client discovers resources from the SEP hosted on the MP using traditional mechanisms such as /.well-known/core <xref target="I-D.ietf-core-link-format"/> or Resource Directory <xref target="I-D.shelby-core-resource-directory"/>.</t>
<t>SEP are assumed to proactively register and maintain mirror entries on the MP, which are soft state and need to be periodically refreshed. A SEP is provided with interfaces to register, update and remove a mirror entry with associated resources. Furthermore, a mechanism to discover a MP using the CoRE Link Format is defined.</t>
<figure anchor="architecture" title="Mirror Proxy architecture">
<artwork align="left"><![CDATA[
Registration Mapping
+-----+ | |
| SEP |---- | | +--------+
+-----+ ---- | ....|.....| RD |
--|- +------+. | +--------+
+-----+ | ----| | | +--------+
| SEP | ---------|-----| MP |----|-----| Client |
+-----+ | ----| | | +--------+
--|- +------+ |
+-----+ ---- | |
| SEP |---- | |
+-----+
]]></artwork>
</figure>
<section title="Resource mapping in a Mirror Proxy">
<t>The resources that a SEP wishes to be served are described using link-format <xref target="I-D.ietf-core-link-format"/>. The description is identical to the /.well-known/core resource found on a typical CoRE web server. Upon successful registration a MP allocates a mirror entry resource for a SEP. The resources specified by the SEP during registration are created as sub-resources of the mirror entry on the MP. The MP updates its own /.well-known/core resource to reflect the changes in its resource tree. When the web server of the MP registers its resources in a Resource Directory (RD), the MP must also register the resources of the SEP with the RD. A MP MUST register the resources of a SEP in a separate resource directory entry. Once a mirror entry has expired, the MP deletes the resources associated to that entry, clears the content cache accordingly and finally updates its /.well-known/core resource. The RD and MP entries are supposed to have the same lifetime so the MP don't need to explicitly delete the RD entry except when the SEP uses the Removal interface.</t>
<t>Once the resources have been created on the MP, the SEP can refresh the content of its resources at its own pace. The SEP updates the cached content on the MP using PUT requests. The SEP may also poll its writable resources using GET requests. When a SEP registers with a MP, the REST interface defined with the Interface Description (if) attribute is only valid from a client point of view. A Mirror Proxy MUST accept PUT requests coming from a SEP even if the Interface Description attribute doesn't allow this method.</t>
<t>The MP may accept to establish an observation relation between a mapped resource from a SEP and a client using <xref target="I-D.ietf-core-observe"/>.</t>
</section>
<section title="Cache refresh strategies">
<t>For non periodic cache refresh, confirmable PUT requests are preferable for reliability. But most of the SEP can't stay awake while waiting for a response. This is especially true when the MP is not in the direct neighborhood of the SEP and the latency is higher. A link layer (L2) like 802.15.4 supports low-level buffering that allows a SEP to poll its parent router for incoming traffic and sleep between poll requests. <xref target="refresh_l2"/> is an example of reliable cache refresh with L2 buffering.</t>
<figure anchor="refresh_l2" title="Confirmable cache refresh with L2 buffering">
<artwork align="left"><![CDATA[
SEP Router MP
| [sleep] | |
| | |
| --- (CON) PUT /mp/0/val --------> | ---PUT---> |
| [sleep] | |
| | |
| --- L2 poll request -------------> | |
| [sleep] | |
| | |
| [CoAP retransmissions if necessary] | |
| | |
| --- L2 poll request -------------> | |
| [sleep] [L2 buffering] | <--2.04--- |
| | |
| --- L2 poll request -------------> | |
| <-- (ACK) 2.04 Changed ----------- | |
| [sleep] | |
| | |
]]></artwork>
</figure>
<t>When no L2 buffering is available another solution is to send a burst of non confirmable PUT requests and come back to sleep mode without waiting for a response. Unfortunately there is currently no option in CoAP to indicate that the client endpoint is not interested in the response to the request. <xref target="refresh_no_suppr"/> shows that the MP generates "2.04 Changed" even if the client endpoint is not able to process them because it is sleeping.</t>
<figure anchor="refresh_no_suppr" title="Non-confirmable cache refresh without response suppression">
<artwork align="left"><![CDATA[
SEP MP
| [long sleep] |
| |
| --- (NON) PUT /mp/0/val ---------------------> |
| [short sleep] |
| X-- (NON) 2.04 Changed ----- |
| --- (NON) PUT /mp/0/val ---------------------> |
| [short sleep] |
| X-- (NON) 2.04 Changed ----- |
| --- (NON) PUT /mp/0/val ---------------------> |
| [long sleep] |
| X-- (NON) 2.04 Changed ----- |
| |
]]></artwork>
</figure>
<t><xref target="refresh_suppr"/> depicts how a new suppression option in CoAP could improve network efficiency. This mechanism is also valuable for periodic refresh but in that case there is no compelling need to repeat the request at each round.</t>
<figure anchor="refresh_suppr" title="Non-confirmable cache refresh with response suppression">
<artwork align="left"><![CDATA[
SEP MP
| [long sleep] |
| |
| --- (NON) PUT /mp/0/val (Suppr-Rsp: All) ----> |
| [short sleep] |
| --- (NON) PUT /mp/0/val (Suppr-Rsp: All) ----> |
| [short sleep] |
| --- (NON) PUT /mp/0/val (Suppr-Rsp: All) ----> |
| [long sleep] |
| |
]]></artwork>
</figure>
<t>Note: The registration and update procedures between the SEP and the MP must also be reliable. Moreover POST requests used for registration are not idempotent so it is not possible to repeat them as non-confirmable requests. In that regard, a CoAP option indicating the sleeping constraints of a SEP might help to synchronize with a MP. Also the response suppression mechanism may delay the time needed for a SEP to detect that its mirrored resources are unreachable.</t>
</section>
<section title="Placing a Mirror Proxy">
<t>The Mirror Proxy functionality can be distributed over multiple server endpoints in the network or centralized on a more powerful web server. The closest the Mirror Proxy is from the sleeping endpoint, the shortest is the round-trip time (RTT). A shorter RTT gives better energy efficiency for CoAP transactions. And a Mirror Proxy in the direct neighborhood of a sleeping endpoint may even avoid having to configure global connectivity for the latter. However in a wireless sensor network relying on local connectivity may result in fragility due to device mobility or radio fluctuations. This could lead a constrained endpoint to frequently try to discover another suitable Mirror Proxy. In that regard, a centralized Mirror Proxy gives more stability but usually at the expense of energy performance. A centralized Mirror Proxy also concentrates network traffic on a central point and may cause network congestion in a wireless sensor network. However data flow of a sleeping endpoint is expected to be low hence mitigating the risk of network congestion.</t>
<t>A sleeping endpoint MAY register with more than one Mirror Proxy but in that case the resources of a sleeping endpoint appear duplicated during resource discovery. Since there is currently no way to de-duplicate the resources, multiple registrations are discouraged.</t>
</section>
</section>
<section title="Mirror Proxy interfaces">
<t>The interface is mostly identical to that of a Resource Directory <xref target="I-D.shelby-core-resource-directory"/> so this document only points out the differences.</t>
<section title="Discovery">
<t>The discovery procedure is identical except that the resource type is replaced with "core-mp".</t>
</section>
<section title="Registration">
<t>The registration interface is identical and the following additional actions are required.</t>
<t>The MP MUST check it has enough memory to create the resources for the new SEP before accepting the registration. If the MP is out of memory it MUST reply with a status code 5.03 "Service Unavailable". In that case the SEP SHOULD try to find another MP.</t>
<t>Upon successful registration, a Mirror Proxy MUST update its /.well-known/core resource to reflect the changes in its resource tree. If the web server of a Mirror Proxy is publishing its own resources in a Resource Directory, it MUST also register the resources of the sleeping endpoint.</t>
<t>Since each SEP may register resources with different lifetimes, the MP MUST register each SEP as a separate resource directory entry in the RD. The MP creates different RD entries by reusing the SEP name provided during MP registration. If no name was provided, the MP can use its own name and a new Instance identifier.</t>
</section>
<section title="Update">
<t>The update interface is identical.</t>
<t>Upon successful update, /.well-known/core and the Resource Directory (if applicable) MUST be updated accordingly.</t>
</section>
<section title="Validation">
<t>The validation interface is not supported on a Mirror Proxy since the sleeping endpoint is not a server endpoint.</t>
</section>
<section title="Removal">
<t>The removal interface is identical.</t>
<t>Upon successful removal, /.well-known/core and the Resource Directory (if applicable) MUST be updated accordingly.</t>
</section>
<section title="Lookup">
<t>The lookup interface is not supported. An endpoint can discover the resources associated to a sleeping endpoint by getting the /.well-known/core resource of the Mirror Proxy or using the lookup interface of the Resource Directory if any is available.</t>
</section>
</section>
<section title="Examples">
<t>The following example details the typical message flow between a SEP and a MP.</t>
<t>The SEP is here a light switch providing the content below:</t>
<figure>
<artwork align="left"><![CDATA[
</dev/>;rt="ipso:dev",
</dev/mfg >;rt="ipso:dev-mfg",
</dev/mdl>;rt="ipso:dev-mdl",
</lt/>;rt="ipso:lt",
</lt/ctr>;rt="ipso:lt-ctr"
]]></artwork>
</figure>
<section title="Discovery">
<figure>
<artwork align="left"><![CDATA[
SEP MP
| |
| ----- GET /.well-known/core?rt=core-mp ------> |
| |
| |
| <---- 2.05 Content "</mp>; rt="core-mp" ------ |
| |
Req: GET coap://[ff02::1]/.well-known/core?rt=core-mp
Res: 2.05 Content
</mp>;rt="core-mp"
]]></artwork>
</figure>
</section>
<section title="Registration">
<figure>
<artwork align="left"><![CDATA[
SEP MP
| |
| --- POST /mp "</dev..." --------------------> |
| |
| |
| <-- 2.01 Created Location: /mp/0 ------------- |
| |
Req: POST coap://mp.example.org/mp?h=switch<=1024
Etag: 0x3f
Payload:
</dev/>;rt="ipso:dev",
</dev/mfg >;rt="ipso:dev-mfg",
</dev/mdl>;rt="ipso:dev-mdl",
</dev/n>;rt="ipso:dev-name",
</lt/>;rt="ipso:lt",
</lt/ctr>;rt="ipso:lt-ctr"
Res: 2.01 Created
Location: /mp/0
]]></artwork>
</figure>
<t>The resources below have been created on the MP.</t>
<figure>
<artwork align="left"><![CDATA[
</mp/0/dev/>;rt="ipso:dev",
</mp/0/dev/mfg >;rt="ipso:dev-mfg",
</mp/0/dev/mdl>;rt="ipso:dev-mdl",
</mp/0/dev/n>;rt="ipso:dev-name",
</mp/0/lt/>;rt="ipso:lt",
</mp/0/lt/ctr>;rt="ipso:lt-ctr"
]]></artwork>
</figure>
<t>Then the MP registers those new resources in the RD.</t>
<figure>
<artwork align="left"><![CDATA[
MP RD
| |
| --- POST /rd "</mp/0..." -------------------> |
| |
| |
| <-- 2.01 Created Location: /rd/6534 ---------- |
| |
Req: POST coap://rd.example.org/rd?h=switch<=1024
Etag: 0x6a
Payload:
</mp/0/dev/>;rt="ipso:dev",
</mp/0/dev/mfg >;rt="ipso:dev-mfg",
</mp/0/dev/mdl>;rt="ipso:dev-mdl",
</mp/0/dev/n>;rt="ipso:dev-name",
</mp/0/lt/>;rt="ipso:lt",
</mp/0/lt/ctr>;rt="ipso:lt-ctr"
Res: 2.01 Created
Location: /rd/6534
]]></artwork>
</figure>
</section>
<section title="Content refresh">
<t>Just after registration, the SEP refreshes the content of static resources such as the manufacturer name (/dev/mfg) and model name (/dev/mdl). These resources are updated with almost infinite max-age so there is no need to send more PUT requests afterward as long as the mirror proxy entry is refreshed on the MP.</t>
<figure>
<artwork align="left"><![CDATA[
SEP MP
| |
| --- PUT /mp/0/dev/mfg "Exa..." -------------> |
| |
| |
| <-- 2.04 Changed ----------------------------- |
| |
Req: PUT coap://mp.example.org/mp/0/dev/mfg (Max-Age: 0xFFFFFFFF)
Payload: Example.Com
Res: 2.04 Changed
]]></artwork>
</figure>
<t>When the switch is activated the SEP wakes up and sends a request to refresh the light control resource. The Max-Age option in the request indicates the maximum time between two PUT requests even if the switch keeps the same state.</t>
<figure>
<artwork align="left"><![CDATA[
SEP MP
| |
| --- PUT /mp/0/lt/ctr "1" -------------------> |
| |
| |
| <-- 2.04 Changed ----------------------------- |
| |
Req: PUT coap://mp.example.org/mp/0/lt/ctr (Max-Age: 1 hour)
Payload: 1
Res: 2.04 Changed
]]></artwork>
</figure>
<t>A client may have subscribed to change of values for the resource /mp/0/lt/ctr on the MP. In that case, the MP would have to notify the CoAP client right after a PUT request from the SEP. A typical exchange would be:</t>
<figure>
<artwork align="left"><![CDATA[
SEP MP Client
| | |
| | <-- GET /mp/0/lt/ctr -- |
| | (observe) |
| | |
| | -- 2.05 Content "0" --> |
| | |
| - PUT /mp/0/lt/ctr "1" -> | |
| | |
| <- 2.04 Changed --------- | |
| | |
| | -- 2.05 Content "1" --> |
]]></artwork>
</figure>
</section>
<section title="Polling ">
<t>A SEP may ask a MP to mirror writable resources. In that case the SEP needs to poll the MP to detect whether the resources have been updated. The example below shows a SEP polling a writable resource once a day to update its name.</t>
<figure>
<artwork align="left"><![CDATA[
SEP MP Client
| | |
| - GET /mp/0/dev/n ------> | |
| | |
| <- 2.03 Valid ----------- | |
| | |
| | <-- PUT /mp/0/dev/n --- |
| [1 day] | |
| | -- 2.04 Changed ------> |
| | |
| - GET /mp/0/dev/n ------> | |
| | |
| <- 2.05 Content --------- | |
| | |
]]></artwork>
</figure>
</section>
</section>
<section title="TODO">
<t>We need a way to identify a SEP registered in multiple proxies as a single entity. Otherwise clients may have a wrong view of the available services during resource discovery. The duplicate resources are indeed seen as new devices.</t>
<t>We need a simple mechanism to define allowed methods on mirrored resources that is independant of the resource profile. A second Interface Description attribute with the CRUD letters might work.</t>
<t>We may add a CoAP option that would permit a MP to indicate in a response that a client has updated another writable resource in the cache for the requesting SEP. This would gives better response time than polling.</t>
<t>When a SEP registers with multiple MP and each MP reuses the same SEP's name to register with the RD, the resource directory entry might be overwritten. We need to figure out what piece of information is the handler for a resource directory entry in a RD database.</t>
<section title="Extensions">
<t>Implicit registration could be useful for highly constrained SEP that don't have enough energy to maintain soft state in a MP. Like the proposition in <xref target="I-D.arkko-core-sleepy-sensors"/>, we could use a multicast address to infer a resource type. Alternatively we could allow explicit registration from a third-party endpoint.</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks to Zach Shelby who is the author of the Resource Directory interface.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>"core-mp" resource type needs to be registered if an appropriate registry is created.</t>
<t>This document suggest the creation of a new CoAP option to suppress an undesired response to a request. But this new option should be detailed in a separate draft.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document needs the same security considerations as described in Section 7 of <xref target="RFC5988"/> and Section 6 of <xref target="I-D.ietf-core-link-format"/>.</t>
<t>Unrestricted access to mirrored resources may allow a malicious web client to poison the cache on a MP. A MP SHOULD authenticate the SEP and restrict allowed methods according to the interface description supplied during resource registration.</t>
<t>A malicious client could start a denial of service attack by trying to mirror a large resource on a MP. Memory exhaustion would prevent the other sleeping endpoints from mirroring their resources.</t>
<t>A malicious client could trigger the removal or the update interface on a MP to delete mirrored resources. This would cause an interruption of service for the targeted SEP until it registers again its resources. A MP SHOULD authenticate client endpoints using the interfaces that can modify a SEP description.</t>
<t>A MP could loose or delete the mirror proxy entry associated to a SEP without sending an explicit notification (e.g. after reboot). A SEP SHOULD be able to detect this situation by processing the response code while sending requests to the proxy. Especially an error code "4.04 Not Found" SHOULD cause the SEP to register again. A SEP MAY also register with multiple proxies to alleviate the risk of interruption of service.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
&I-D.ietf-core-link-format;
&I-D.ietf-core-coap;
&I-D.shelby-core-resource-directory;
&I-D.ietf-core-observe;
&RFC5988;
&RFC2119;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&I-D.arkko-core-sleepy-sensors;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 01:58:10 |