doc: Add RFC documents

1 files changed, 745 insertions, 0 deletions

diff --git a/doc/rfc/rfc9178.txt b/doc/rfc/rfc9178.txt
new file mode 100644
index 0000000..de91b48
--- /dev/null
+++ b/doc/rfc/rfc9178.txt
@@ -0,0 +1,745 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                          J. Arkko
+Request for Comments: 9178                                      Ericsson
+Category: Informational                                      A. Eriksson
+ISSN: 2070-1721                                              Independent
+                                                              A. Keränen
+                                                                Ericsson
+                                                                May 2022
+
+
+Building Power-Efficient Constrained Application Protocol (CoAP) Devices
+                         for Cellular Networks
+
+Abstract
+
+   This memo discusses the use of the Constrained Application Protocol
+   (CoAP) in building sensors and other devices that employ cellular
+   networks as a communications medium.  Building communicating devices
+   that employ these networks is obviously well known, but this memo
+   focuses specifically on techniques necessary to minimize power
+   consumption.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9178.
+
+Copyright Notice
+
+   Copyright (c) 2022 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) 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 Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Goals for Low-Power Operation
+   3.  Link-Layer Assumptions
+   4.  Scenarios
+   5.  Discovery and Registration
+   6.  Data Formats
+   7.  Real-Time Reachable Devices
+   8.  Sleepy Devices
+     8.1.  Implementation Considerations
+   9.  Security Considerations
+   10. IANA Considerations
+   11. References
+     11.1.  Normative References
+     11.2.  Informative References
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   This memo discusses the use of the Constrained Application Protocol
+   (CoAP) [RFC7252] in building sensors and other devices that employ
+   cellular networks as a communications medium.  Building communicating
+   devices that employ these networks is obviously well known, but this
+   memo focuses specifically on techniques necessary to minimize power
+   consumption.  CoAP has many advantages, including being simple to
+   implement; a thousand lines of code for the entire application above
+   the IP layer is plenty for a CoAP-based sensor, for instance.
+   However, while many of these advantages are obvious and easily
+   obtained, optimizing power consumption remains challenging and
+   requires careful design [Tiny-CoAP].
+
+   This memo primarily targets 3GPP cellular networks in their 2G, 3G,
+   LTE, and 5G variants and their future enhancements, including
+   possible power efficiency improvements at the radio and link layers.
+   The exact standards or details of the link layer or radios are not
+   relevant for our purposes, however.  To be more precise, the material
+   in this memo is suitable for any large-scale, public network that
+   employs a point-to-point communications model and radio technology
+   for the devices in the network.
+
+   Our focus is on devices that need to be optimized for power usage and
+   devices that employ CoAP.  As a general technology, CoAP is similar
+   to HTTP.  It can be used in various ways, and network entities may
+   take on different roles.  This freedom allows the technology to be
+   used in efficient and less efficient ways.  Some guidance is needed
+   to understand what types of communication over CoAP are recommended
+   when low power usage is a critical goal.
+
+   The recommendations in this memo should be taken as complementary to
+   device hardware optimization, microelectronics improvements, and
+   further evolution of the underlying link and radio layers.  Further
+   gains in power efficiency can certainly be gained on several fronts;
+   the approach that we take in this memo is to do what can be done at
+   the IP, transport, and application layers to provide the best
+   possible power efficiency.  Application implementors generally have
+   to use the current-generation microelectronics, currently available
+   radio networks and standards, and so on.  This focus in our memo
+   should by no means be taken as an indication that further evolution
+   in these other areas is unnecessary.  Such evolution is useful,
+   ongoing, and generally complementary to the techniques presented in
+   this memo.  However, the list of techniques described in this
+   document as useful for a particular application may change with the
+   evolution of these underlying technologies.
+
+   The rest of this memo is structured as follows.  Section 2 discusses
+   the need and goals for low-power devices.  Section 3 outlines our
+   expectations for the low-layer communications model.  Section 4
+   describes the two scenarios that we address.  Sections 5, 6, 7, and 8
+   give guidelines for the use of CoAP in these scenarios.
+
+   This document was originally finalized in 2016 but is published six
+   years later due to waiting for key references to reach RFC status.
+   Therefore, some of the latest advancements in cellular network, CoAP,
+   and other technologies are not discussed here, and some of the
+   references point to documents that were state of the art in 2016.
+
+2.  Goals for Low-Power Operation
+
+   There are many situations where power usage optimization is
+   unnecessary.  Optimization may not be necessary on devices that can
+   run on a power feed over wired communications media, such as in
+   Power-over-Ethernet (PoE) solutions.  These devices may require a
+   rudimentary level of power optimization techniques just to keep
+   overall energy costs and aggregate power feed sizes at a reasonable
+   level, but more extreme techniques necessary for battery-powered
+   devices are not required.  The situation is similar with devices that
+   can easily be connected to mains power.  Other types of devices may
+   get an occasional charge of power from energy-harvesting techniques.
+   For instance, some environmental sensors can run on solar cells.
+   Typically, these devices still have to regulate their power usage in
+   a strict manner -- for instance, to be able to use solar cells that
+   are as small and inexpensive as possible.
+
+   In battery-operated devices, power usage is even more important.  For
+   instance, one of the authors employs over a hundred different sensor
+   devices in their home network.  A majority of these devices are wired
+   and run on PoE, but in most environments this would be impractical
+   because the necessary wires do not exist.  The future is in wireless
+   solutions that can cover buildings and other environments without
+   assuming a pre-existing wired infrastructure.  In addition, in many
+   cases it is impractical to provide a mains power source.  Often,
+   there are no power sockets easily available in the locations that the
+   devices need to be in, and even if there were, setting up the wires
+   and power adapters would be more complicated than installing a
+   standalone device without any wires.
+
+   Yet, with a large number of devices, the battery lifetimes become
+   critical.  Cost and practical limits dictate that devices can be
+   largely just bought and left on their own.  For instance, with a
+   hundred devices, even a ten-year battery lifetime results in a
+   monthly battery change for one device within the network.  This may
+   be impractical in many environments.  In addition, some devices may
+   be physically difficult to reach for a battery change.  Or, a large
+   group of devices -- such as utility meters or environmental sensors
+   -- cannot be economically serviced too often, even if in theory the
+   batteries could be changed.
+
+   Many of these situations lead to a requirement for minimizing power
+   usage and/or maximizing battery lifetimes.  Using the power usage
+   strategies described in [RFC7228], mains-powered sensor-type devices
+   can use the Always-on strategy, whereas battery-operated or energy-
+   harvesting devices need to adjust behavior based on the communication
+   interval.  For intervals on the order of seconds, the Low-power
+   strategy is appropriate.  For intervals ranging from minutes to
+   hours, either the Low-power or Normally-off strategy is suitable.
+   Finally, for intervals lasting days or longer, Normally-off is
+   usually the best choice.  Unfortunately, much of our current
+   technology has been built with different objectives in mind -- for
+   instance, networked devices that are "always on", gadgets that
+   require humans to recharge them every couple of days, and protocols
+   that have been optimized to maximize throughput rather than conserve
+   resources.
+
+   Long battery lifetimes are required for many applications, however.
+   In some cases, these lifetimes should be on the order of years or
+   even a decade or longer.  Some communication devices already reach
+   multi-year lifetimes, and continuous improvements in low-power
+   electronics and advances in radio technology keep pushing these
+   lifetimes longer.  However, it is perhaps fair to say that battery
+   lifetimes are generally too short at present.
+
+   Power usage cannot be evaluated based solely on lower-layer
+   communications.  The entire system, including upper-layer protocols
+   and applications, is responsible for the power consumption as a
+   whole.  The lower communication layers have already adopted many
+   techniques that can be used to reduce power usage, such as scheduling
+   device wake-up times.  Further reductions will likely need some
+   cooperation from the upper layers so that unnecessary communications,
+   denial-of-service attacks on power consumption, and other power
+   drains are eliminated.
+
+   Of course, application requirements ultimately determine what kinds
+   of communications are necessary.  For instance, some applications
+   require more data to be sent than others.  The purpose of the
+   guidelines in this memo is not to prefer one or the other
+   application, but to provide guidance on how to minimize the amount of
+   communications overhead that is not directly required by the
+   application.  While such optimization is generally useful, it is,
+   relatively speaking, most noticeable in applications that transfer
+   only a small amount of data or operate only infrequently.
+
+3.  Link-Layer Assumptions
+
+   We assume that the underlying communications network can be any
+   large-scale, public network that employs a point-to-point
+   communications model and radio technology.  2G, 3G, LTE, and 5G
+   networks are examples of such networks but are not the only possible
+   networks with these characteristics.
+
+   In the following, we look at some of these characteristics and their
+   implications.  Note that in most cases these characteristics are not
+   properties of the specific networks but rather are inherent in the
+   concept of public networks.
+
+   *  Public Networks
+
+      Using a public network service implies that applications can be
+      deployed without having to build a network to go with them.  For
+      economic reasons, only the largest users (such as utility
+      companies) could afford to build their own network, and even they
+      would not be able to provide worldwide coverage.  This means that
+      applications where coverage is important can be built.  For
+      instance, most transport-sector applications require national or
+      even worldwide coverage to work.
+
+      But there are other implications as well.  By definition, the
+      network is not tailored for this application, and, with some
+      exceptions, the traffic passes through the Internet.  One
+      implication of this is that there are generally no application-
+      specific network configurations or discovery support.  For
+      instance, the public network helps devices to get on the Internet,
+      set up default routers, configure DNS servers, and so on, but does
+      nothing for configuring possible higher-layer functions, such as
+      servers that a device might need to contact to perform its
+      application functions.
+
+      Public networks often provide web proxies and other functionality
+      that can, in some cases, make significant improvements related to
+      delays and costs of communication over the wireless link.  For
+      instance, resolving server DNS names in a proxy instead of the
+      user's device may cut down on the general chattiness of the
+      communications, therefore reducing overall delay in completing the
+      entire transaction.  Likewise, a CoAP proxy or Publish-Subscribe
+      (pub/sub) Broker [CoAP-PubSub] can assist a CoAP device in
+      communication.  However, unlike HTTP web proxies, CoAP proxies and
+      brokers are not yet widely deployed in public networks.
+
+      Similarly, given the lack of available IPv4 addresses, chances are
+      that many devices are behind a Network Address Translation (NAT)
+      device.  This means that they are not easily reachable as servers.
+      Alternatively, the devices may be directly on the global Internet
+      (on either IPv4 or IPv6) and easily reachable as servers.
+      Unfortunately, this may mean that they also receive unwanted
+      traffic, which may have implications for both power consumption
+      and service costs.
+
+   *  Point-to-Point Link Model
+
+      This is a common link model in cellular networks.  One implication
+      of this model is that there will be no other nodes on the same
+      link, except maybe for the service provider's router.  As a
+      result, multicast discovery cannot be reasonably used for any
+      local discovery purposes.  While the configuration of the service
+      provider's router for specific users is theoretically possible,
+      this is difficult to achieve in practice, at least for any small
+      user that cannot afford a network-wide contract for a private APN
+      (Access Point Name).  The public network access service has little
+      per-user tailoring.
+
+   *  Radio Technology
+
+      The use of radio technology means that power is needed to operate
+      the radios.  Transmission generally requires more power than
+      reception.  However, radio protocols have generally been designed
+      so that a device checks periodically to see whether it has
+      messages.  In a situation where messages arrive seldom or not at
+      all, this checking consumes energy.  Research has shown that these
+      periodic checks (such as LTE paging message reception) are often a
+      far bigger contributor to energy consumption than message
+      transmission.
+
+      Note that for situations where there are several applications on
+      the same device wishing to communicate with the Internet in some
+      manner, bundling those applications together so that they can
+      communicate at the same time can be very useful.  Some guidance
+      for these techniques in the smartphone context can be found in
+      [Android-Bundle].
+
+   Naturally, each device has the freedom to decide when it sends
+   messages.  In addition, we assume that there is some way for the
+   devices to control when or how often they want to receive messages.
+   Specific methods for doing this depend on the specific network being
+   used and also tend to change as improvements in the design of these
+   networks are incorporated.  The reception control methods generally
+   come in two variants: (1) fine-grained mechanisms that deal with how
+   often the device needs to wake up for paging messages and (2) cruder
+   mechanisms where the device simply disconnects from the network for a
+   period of time.  There are costs and benefits associated with each
+   method, but those are not relevant for this memo, as long as some
+   control method exists.  Furthermore, devices could use Delay-Tolerant
+   Networking (DTN) mechanisms [RFC4838] to relax the requirements for
+   timeliness of connectivity and message delivery.
+
+4.  Scenarios
+
+   Not all applications or situations are equal.  They may require
+   different solutions or communication models.  This memo focuses on
+   two common scenarios in cellular networks:
+
+   *  Real-Time Reachable Devices
+
+      This scenario involves all communication that requires real-time
+      or near-real-time communications with a device.  That is, a
+      network entity must be able to reach the device with a small time
+      lag at any time, and no previously agreed-upon wake-up schedule
+      can be arranged.  By "real-time", we mean any reasonable end-to-
+      end communications latency, be it measured in milliseconds or
+      seconds.  However, unpredictable sleep states are not expected.
+
+      Examples of devices in this category include sensors that must be
+      measurable from a remote source at any instant in time, such as
+      process automation sensors and actuators that require immediate
+      action, such as light bulbs or door locks.
+
+   *  Sleepy Devices
+
+      This scenario involves the freedom to choose when a device
+      communicates.  The device is often expected to be able to be in a
+      sleep state for much of its time.  The device itself can choose
+      when it communicates, or it lets the network assist in this task.
+
+      Examples of devices in this category include sensors that track
+      slowly changing values, such as temperature sensors and actuators
+      that control a relatively slow process, such as heating systems.
+
+      Note that there may be hard real-time requirements, but they are
+      expressed in terms of how fast the device can communicate -- not
+      in terms of how fast it can respond to network stimuli.  For
+      instance, a fire detector can be classified as a sleepy device as
+      long as it can internally quickly wake up on detecting fire and
+      initiate the necessary communications without delay.
+
+5.  Discovery and Registration
+
+   In both scenarios, the device will be attached to a public network.
+   Without special arrangements, the device will also get a dynamically
+   assigned IP address or an IPv6 prefix.  At least one but typically
+   several router hops separate the device from its communicating peers
+   such as application servers.  As a result, the address or even the
+   existence of the device is typically not immediately obvious to the
+   other nodes participating in the application.  As discussed earlier,
+   multicast discovery has limited value in public networks; network
+   nodes cannot practically discover individual devices in a large
+   public network.  And the devices cannot discover who they need to
+   talk to, as the public network offers just basic Internet
+   connectivity.
+
+   Our recommendation is to initiate a discovery and registration
+   process.  This allows each device to inform its peers that it has
+   connected to the network and that it is reachable at a given IP
+   address.  Registration also facilitates low-power operation, since a
+   device can delegate part of the discovery signaling and reachability
+   requirements to another node.
+
+   The registration part is easy, e.g., with a resource directory.  The
+   device should perform the necessary registration with such a resource
+   directory -- for instance, as specified in [RFC9176].  In order to do
+   this registration, the device needs to know its Constrained RESTful
+   Environments (CoRE) Link Format description, as specified in
+   [RFC6690].  In essence, the registration process involves performing
+   a GET on .well-known/core/?rt=core-rd at the address of the resource
+   directory and then doing a POST on the path of the discovered
+   resource.
+
+   Other mechanisms enabling device discovery and delegation of
+   functionality to a non-sleepy node include those discussed in
+   [CoRE-Mirror] and [CoAP-PubSub].
+
+   However, current CoAP specifications provide only limited support for
+   discovering the resource directory or other registration services.
+   Local multicast discovery only works in LAN-type networks; it does
+   not work in the public cellular networks discussed in this document.
+   We recommend the following alternate methods for discovery:
+
+   *  Manual Configuration
+
+      The DNS name of the resource directory is manually configured.
+      This approach is suitable in situations where the owner of the
+      devices has the resources and capabilities to do the
+      configuration.  For instance, a utility company can typically
+      program its metering devices to point to the company servers.
+
+   *  Manufacturer Server
+
+      The DNS name of the directory or proxy is hardwired to the
+      software by the manufacturer, and the directory or proxy is
+      actually run by the manufacturer.  This approach is suitable in
+      many consumer usage scenarios, where it would be unreasonable to
+      assume that the consumer runs any specific network services.  The
+      manufacturer's web interface and the directory/proxy servers can
+      cooperate to provide the desired functionality to the end user.
+      For instance, the end user can register a device identity in the
+      manufacturer's web interface and ask that specific actions be
+      taken when the device does something.
+
+   *  Delegating Manufacturer Server
+
+      The DNS name of the directory or proxy is hardwired to the
+      software by the manufacturer, but this directory or proxy merely
+      redirects the request to a directory or proxy run by whoever
+      bought the device.  This approach is suitable in many enterprise
+      environments, as it allows the enterprise to be in charge of
+      actual data collection and device registries; only the initial
+      bootstrap goes through the manufacturer.  In many cases, there are
+      even legal requirements (such as EU privacy laws) that prevent
+      providing unnecessary information to third parties.
+
+   *  Common Global Resolution Infrastructure
+
+      The delegating manufacturer server model could be generalized into
+      a reverse-DNS-like discovery infrastructure that could, for
+      example, answer the question "This is a device with identity ID
+      2456; where is my home registration server?"  However, at present,
+      no such resolution system exists.  (Note: The EPCGlobal system for
+      Radio Frequency Identification (RFID) resolution is reminiscent of
+      this approach.)
+
+   Besides manual configuration, these alternate mechanisms are mostly
+   suitable for large manufacturers and deployments.  Good automated
+   mechanisms for discovery of devices that are manufactured and
+   deployed in small quantities are still needed.
+
+6.  Data Formats
+
+   A variety of data formats exist for passing around data.  These data
+   formats include XML, JavaScript Object Notation (JSON) [RFC8259],
+   Efficient XML Interchange (EXI) [W3C.REC-exi-20140211], Concise
+   Binary Object Representation (CBOR) [RFC8949], and various text
+   formats.  Message lengths can have a significant effect on the amount
+   of energy required for the communications, and as such it is highly
+   desirable to keep message lengths minimal.  At the same time, extreme
+   optimization can affect flexibility and ease of programming.  The
+   authors recommend that readers refer to [RFC8428] for a compact but
+   easily processed and extendable format.
+
+7.  Real-Time Reachable Devices
+
+   These devices are often best modeled as CoAP servers.  The device
+   will have limited control over when it receives messages, and it will
+   have to listen actively for messages, up to the limits of the
+   underlying link layer.  If in some phase of its operation the device
+   also acts in the role of a client, it can control how many
+   transmissions it makes on its own behalf.
+
+   The packet reception checks should be tailored according to the
+   requirements of the application.  If sub-second response time is not
+   needed, a more infrequent checking process may save some power.
+
+   For sensor-type devices, the CoAP Observe extension (Observe option)
+   [RFC7641] may be supported.  This allows the sensor to track changes
+   to the sensed value and make an immediate observation response upon a
+   change.  This may reduce the amount of polling needed to be done by
+   the client.  Unfortunately, it does not reduce the time that the
+   device needs to be listening for requests.  Subscription requests
+   from clients other than the currently registered client may come in
+   at any time, the current client may change its request, and the
+   device still needs to respond to normal queries as a server.  As a
+   result, the sensor cannot rely on having to communicate only on its
+   own choice of observation interval.
+
+   In order to act as a server, the device needs to be placed in a
+   public IPv4 address, be reachable over IPv6, or be hosted in a
+   private network.  If the device is hosted on a private network, then
+   all other nodes that need to access this device also need to reside
+   in the same private network.  There are multiple ways to provide
+   private networks over public cellular networks.  One approach is to
+   dedicate a special APN for the private network.  Corporate access via
+   cellular networks has often been arranged in this manner, for
+   instance.  Another approach is to use Virtual Private Network (VPN)
+   technology -- for instance, IPsec-based VPNs.
+
+   Power consumption from unwanted traffic is problematic in these
+   devices, unless they are placed in a private network or protected by
+   an operator-provided firewall service.  Devices on an IPv6 network
+   will be afforded some protection due to the nature of the 2^64
+   address allocation for a single terminal in a 3GPP cellular network;
+   the attackers will be unable to guess the full IP address of the
+   device.  However, this protects only the device from processing a
+   packet, but since the network will still deliver the packet to any of
+   the addresses within the assigned 64-bit prefix, packet reception
+   costs are still incurred.
+
+   Note that the VPN approach cannot prevent unwanted traffic received
+   at the tunnel endpoint address and may require keep-alive traffic.
+   Special APNs can solve this issue but require an explicit arrangement
+   with the service provider.
+
+8.  Sleepy Devices
+
+   These devices are best modeled as devices that can delegate queries
+   to some other node -- for instance, as mirror servers [CoRE-Mirror]
+   or CoAP pub/sub Clients [CoAP-PubSub].  When the device initializes
+   itself, it makes a registration of itself in a server or broker as
+   described above in Section 5 and then continues to send periodic
+   updates of sensor values.
+
+   As a result, the device acts only as a client and not as a server,
+   and can shut down all communication channels during its sleeping
+   period.  The length of the sleeping period depends on power and
+   application requirements.  Some environmental sensors might use a day
+   or a week as the period, while other devices may use smaller values
+   ranging from minutes to hours.
+
+   The ability to shut down communications and act as only a client has
+   four impacts:
+
+   *  Radio transmission and reception can be turned off during the
+      sleeping period, reducing power consumption significantly.
+
+   *  However, some power and time are consumed by having to reattach to
+      the network after the end of a sleep period.
+
+   *  The window of opportunity for unwanted traffic to arrive is much
+      smaller, as the device is listening for traffic only part of the
+      time.  Note, however, that networks may cache packets for some
+      time.  On the other hand, stateful firewalls can effectively
+      remove much of the unwanted traffic for client-type devices.
+
+   *  The device may exist behind a NAT or a firewall without being
+      impacted.  Note that the "simple security" basic IPv6 firewall
+      capability [RFC6092] blocks inbound UDP traffic by default, so
+      just moving to IPv6 is not a direct solution to this problem.
+
+   For sleepy devices that represent actuators, it is also possible to
+   use the mirror server or pub/sub broker model.  A device can receive
+   information from the server or broker about variable changes via
+   either polling or notifications.
+
+8.1.  Implementation Considerations
+
+   There are several challenges related to implementing sleepy devices.
+   They need hardware that can be placed in an appropriate sleep mode
+   but awakened when it is time to do something again.  This is not
+   always easy in all hardware platforms.  It is important to be able to
+   shut down as much of the hardware as possible, preferably down to
+   everything else except a clock circuit.  The platform also needs to
+   support reawakening at suitable timescales, as otherwise the device
+   needs to be powered up too frequently.
+
+   Most commercial cellular modem platforms do not allow applications to
+   suspend the state of the communications stack.  Hence, after a power-
+   off period, they need to re-establish communications, which takes
+   some amount of time and extra energy.
+
+   Implementations should have a coordinated understanding of the state
+   and sleeping schedule.  For instance, it makes no sense to keep a CPU
+   powered up, waiting for a message when the lower layer has been told
+   that the next possible paging opportunity is some time away.
+
+   The cellular networks have a number of adjustable configuration
+   parameters, such as the maximum used paging interval.  Proper
+   settings of these values have an impact on the power consumption of
+   the device, but with current business practices, such settings are
+   rarely negotiated when the user's subscription is provisioned.
+
+9.  Security Considerations
+
+   There are no particular security aspects related to what has been
+   discussed in this memo, except for the ability to delegate queries
+   for a resource to another node.  Depending on how this is done, there
+   are obvious security issues that have largely NOT yet been addressed
+   in the relevant Internet-Drafts [CoRE-Mirror] [CoAP-Alive]
+   [CoAP-Publ-Monitor].  However, we point out that, in general,
+   security issues in delegation can be solved through either reliance
+   on your local network support nodes (which may be quite reasonable in
+   many environments) or explicit end-to-end security.  Explicit end-to-
+   end security through nodes that are awake at different times means,
+   in practice, end-to-end data object security.  We have implemented
+   one such mechanism for sleepy nodes as described in [RFC8387].
+
+   The security considerations relating to CoAP [RFC7252] and the
+   relevant link layers should apply.  Note that cellular networks
+   universally employ per-device authentication, integrity protection,
+   and, for most of the world, encryption of all their communications.
+   Additional protection of transport sessions is possible through
+   mechanisms described in [RFC7252] or data objects.
+
+10.  IANA Considerations
+
+   This document has no IANA actions.
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
+              Interchange Format", STD 90, RFC 8259,
+              DOI 10.17487/RFC8259, December 2017,
+              <https://www.rfc-editor.org/info/rfc8259>.
+
+   [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
+              Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
+              <https://www.rfc-editor.org/info/rfc6690>.
+
+   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
+              Application Protocol (CoAP)", RFC 7252,
+              DOI 10.17487/RFC7252, June 2014,
+              <https://www.rfc-editor.org/info/rfc7252>.
+
+   [RFC7641]  Hartke, K., "Observing Resources in the Constrained
+              Application Protocol (CoAP)", RFC 7641,
+              DOI 10.17487/RFC7641, September 2015,
+              <https://www.rfc-editor.org/info/rfc7641>.
+
+   [RFC8949]  Bormann, C. and P. Hoffman, "Concise Binary Object
+              Representation (CBOR)", STD 94, RFC 8949,
+              DOI 10.17487/RFC8949, December 2020,
+              <https://www.rfc-editor.org/info/rfc8949>.
+
+   [RFC9176]  Amsüss, C., Ed., Shelby, Z., Koster, M., Bormann, C., and
+              P. van der Stok, "Constrained RESTful Environments (CoRE)
+              Resource Directory", RFC 9176, DOI 10.17487/RFC9176, April
+              2022, <https://www.rfc-editor.org/info/rfc9176>.
+
+   [W3C.REC-exi-20140211]
+              Schneider, J., Kamiya, T., Peintner, D., and R. Kyusakov,
+              "Efficient XML Interchange (EXI) Format 1.0 (Second
+              Edition)", World Wide Web Consortium Recommendation REC-
+              exi-20140211, February 2014, <https://www.w3.org/TR/exi/>.
+
+   [RFC8428]  Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C.
+              Bormann, "Sensor Measurement Lists (SenML)", RFC 8428,
+              DOI 10.17487/RFC8428, August 2018,
+              <https://www.rfc-editor.org/info/rfc8428>.
+
+   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
+              Constrained-Node Networks", RFC 7228,
+              DOI 10.17487/RFC7228, May 2014,
+              <https://www.rfc-editor.org/info/rfc7228>.
+
+11.2.  Informative References
+
+   [RFC4838]  Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
+              R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
+              Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
+              April 2007, <https://www.rfc-editor.org/info/rfc4838>.
+
+   [RFC6092]  Woodyatt, J., Ed., "Recommended Simple Security
+              Capabilities in Customer Premises Equipment (CPE) for
+              Providing Residential IPv6 Internet Service", RFC 6092,
+              DOI 10.17487/RFC6092, January 2011,
+              <https://www.rfc-editor.org/info/rfc6092>.
+
+   [Tiny-CoAP]
+              Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O.
+              Novo, "Implementing Tiny COAP Sensors", Work in Progress,
+              Internet-Draft, draft-arkko-core-sleepy-sensors-01, 5 July
+              2011, <https://datatracker.ietf.org/doc/html/draft-arkko-
+              core-sleepy-sensors-01>.
+
+   [RFC8387]  Sethi, M., Arkko, J., Keranen, A., and H. Back, "Practical
+              Considerations and Implementation Experiences in Securing
+              Smart Object Networks", RFC 8387, DOI 10.17487/RFC8387,
+              May 2018, <https://www.rfc-editor.org/info/rfc8387>.
+
+   [CoAP-Alive]
+              Castellani, A. and S. Loreto, "CoAP Alive Message", Work
+              in Progress, Internet-Draft, draft-castellani-core-alive-
+              00, 29 March 2012, <https://datatracker.ietf.org/doc/html/
+              draft-castellani-core-alive-00>.
+
+   [CoAP-Publ-Monitor]
+              Fossati, T., Giacomin, P., and S. Loreto, "Publish and
+              Monitor Options for CoAP", Work in Progress, Internet-
+              Draft, draft-fossati-core-publish-monitor-options-01, 10
+              March 2012, <https://datatracker.ietf.org/doc/html/draft-
+              fossati-core-publish-monitor-options-01>.
+
+   [CoRE-Mirror]
+              Vial, M., "CoRE Mirror Server", Work in Progress,
+              Internet-Draft, draft-vial-core-mirror-proxy-01, 13 July
+              2012, <https://datatracker.ietf.org/doc/html/draft-vial-
+              core-mirror-proxy-01>.
+
+   [CoAP-PubSub]
+              Koster, M., Keranen, A., and J. Jimenez, "Publish-
+              Subscribe Broker for the Constrained Application Protocol
+              (CoAP)", Work in Progress, Internet-Draft, draft-ietf-
+              core-coap-pubsub-10, 4 May 2022,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
+              coap-pubsub-10>.
+
+   [Android-Bundle]
+              "Optimize network access", Android developer note, May
+              2022, <https://developer.android.com/training/efficient-
+              downloads/efficient-network-access.html>.
+
+Acknowledgments
+
+   The authors would like to thank Zach Shelby, Jan Holler, Salvatore
+   Loreto, Matthew Vial, Thomas Fossati, Mohit Sethi, Jan Melen, Joachim
+   Sachs, Heidi-Maria Rissanen, Sebastien Pierrel, Kumar Balachandran,
+   Muhammad Waqas Mir, Cullen Jennings, Markus Isomaki, Hannes
+   Tschofenig, and Anna Larmo for interesting discussions in this
+   problem space.
+
+Authors' Addresses
+
+   Jari Arkko
+   Ericsson
+   FI-02420 Jorvas
+   Finland
+   Email: jari.arkko@piuha.net
+
+
+   Anders Eriksson
+   Independent
+   SE-164 83 Stockholm
+   Sweden
+   Email: anders.e.eriksson@posthem.se
+
+
+   Ari Keränen
+   Ericsson
+   FI-02420 Jorvas
+   Finland
+   Email: ari.keranen@ericsson.com