Subject: [core] CoRE rechartering: proposed text

From: Marco Tiloca <[email-masked]>
Date: Wed, 8 Sep 2021 19:34:26 +0200

Hi all,

During the CoRE session at IETF 111 [1][2], it was proposed to update 
our charter, for better reflecting the current status of our work. This 
is also helpful for the IESG review processing and for newcomers to more 
easily understand the WG scope and direction.

As promised, the Chairs have prepared an initial proposed text for the 
WG to consider. Please, find the proposed text at the end of this mail 
as well as in the CodiMD at [3].

With that as starting point, this mail starts a discussion on the new 
charter text. Please, provide your comments and proposed changes here on 
the mailing list or in the CodiMD at [3] (editing requires to be logged in).

Best,
Marco and Jaime

[1] https://datatracker.ietf.org/doc/minutes-111-core/

[2] 
https://datatracker.ietf.org/meeting/111/materials/slides-111-core-chairs-slides-00.pdf

[3] https://notes.ietf.org/BkpQ-gttSRuVKlEgxho5gw?both

=======================

The CoRE Working Group (WG) provides a framework for resource-oriented 
applications intended to run on constrained IP networks. A constrained 
IP network has limited packet sizes, may exhibit a high degree of packet 
loss, and may have a substantial number of devices that may be powered 
off at any point in time but periodically "wake up" for brief periods of 
time. These networks and the nodes within them are characterized by 
severe limits on throughput, available power, and particularly on the 
complexity that can be supported with limited code size and limited RAM 
per node [RFC 7228]. More generally, we speak of constrained node 
networks whenever at least some of the nodes and networks involved 
exhibit these characteristics. Low-Power Wireless Personal Area Networks 
(LoWPANs) are an example of this type of network. Constrained networks 
can occur as part of home and building automation, energy management, 
and the Internet of Things.

The CoRE WG will define a framework for a limited class of applications: 
those that deal with the manipulation of simple resources on constrained 
networks. This includes applications to monitor simple sensors (e.g., 
temperature sensors, light sensors, and power meters), to control 
actuators (e.g., light switches, heating controllers, and door locks), 
and to manage devices.

The general architecture targeted by the CoRE WG framework consists of 
nodes on the constrained network, called Devices, that are responsible 
for one or more Resources that may represent sensors, actuators, 
combinations of values, and/or other information. Devices send messages 
to change and query resources on other Devices. A Device can send 
notifications about changed resource values to Devices that have 
expressed their interest to receive notification about changes. A Device 
can also publish or be queried about its resources. Typically, a single 
physical host on the network would have just one Device but a host might 
represent multiple logical Devices. The specific terminology to be used 
here is to be decided by the working group.

As part of the framework for building these applications, the CoRE WG 
has defined the Constrained Application Protocol (CoAP) for the 
manipulation of Resources on a Device. CoAP is designed for use between 
Devices on the same constrained network, between Devices and general 
nodes on the Internet, and between Devices on different constrained 
networks both joined by an internet. CoAP is also being used via other 
mechanisms, such as SMS on mobile communication networks. CoAP targets 
the type of operating environments defined in the ROLL and 6Lo WGs, 
which have additional constraints compared to normal IP networks. 
Nevertheless, the CoAP protocol also operates over traditional IP networks.

There also may be intermediary nodes acting as proxies that possibly 
also interconnect between other Internet protocols and the Devices using 
the CoAP protocol. It is worth noting that a proxy does not have to 
occur at the boundary between the constrained network and the more 
general network, but can be deployed at various locations in the 
less-constrained network. The CoRE WG will continue to evolve the 
support of proxies for CoAP to increase their practical applicability.

CoAP supports various forms of "caching". Beyond the benefits of caching 
already well known from REST, caching can be used to increase energy 
savings of low-power nodes by allowing them to be normally-off [RFC 
7228]. For example, a temperature sensor might wake up every five 
minutes and send the current temperature to a proxy that has expressed 
interest in notifications. When the proxy receives a request over CoAP 
or HTTP for that temperature resource, it can respond with the last 
notified value, instead of trying to query the Device which may not be 
reachable at this time. The CoRE WG will continue to evolve this model 
to increase its practical applicability.

The CoRE WG will perform maintenance as well as possible updating and 
complementing on its first four standards-track specifications as required:

- RFC 6690
- RFC 7252
- RFC 7641
- RFC 7959

The CoRE WG will continue to evolve the support for CoAP group 
communication originally developed in the Experimental RFC 7390. The 
CoRE WG will not develop a solution for reliable multicast delivery of 
CoAP messages, which will remain Non-Confirmable when sent over multicast.

RFC 7252 defines a basic HTTP mapping for CoAP, which was further 
elaborated in RFC 8075. This mapping will be evolved and supported by 
further documents as required.

CoAP was initially designed to work over UDP and DTLS. Later on, mapping 
were defined between CoAP and IP-based transports, especially TCP and 
WebSockets including a secure version over TLS (RFC 8323). The CoRE WG 
will continue defining transport mappings for alternative transports as 
required, both IP-based and non IP-based (e.g., SMS and Bluetooth), 
working with the Security Area on potentially addressing the security 
gap. This includes defining appropriate URI schemes. Continued 
compatibility with CoAP over SMS as defined in OMA Lightweight 
Machine-to-Machine (LwM2M) will be considered. Furthermore, the CoRE WG 
will work on solutions to facilitate the signaling of transports 
available to a Device.

The CoRE WG will continue and complete its work on the CoRE Resource 
Directory (draft-ietf-core-resource-directory), as already partially 
adopted by OMA LwM2M, and will perform maintenance as well as possible 
updating, complementing and specification of relevant uses as required. 
A primary related consideration is the interoperability with DNS-SD and 
the work of the dnssd WG. The use of CoAP to transport DNS queries and 
responses will also be investigated. Furthermore, the CoRE WG will also 
continue and complete its work on enabling broker-based 
publish-subscribe-style communication over CoAP 
(draft-ietf-core-coap-pubsub).

The CoRE WG will work on related data formats, such as alternative 
representations of RFC 6690 link format and RFC 7390 group communication 
information. Also, the CoRE WG will complete its work on Constrained 
Resource Identifiers for serializing URI components in CBOR 
(draft-ietf-core-href). Furthermore, the CoRE WG will develop CoRAL 
(draft-ietf-core-coral), a constrained RESTful application language 
suitable also for constrained node networks, which comprises an 
information model and an interaction model, and is intended for driving 
automated software agents that navigate a Web application. The CoRE WG 
will complete the Sensor Measurement Lists (SenML) set of 
specifications, again with consideration to its adoption in OMA LwM2M.

Besides continuing to examine operational and manageability aspects of 
the CoAP protocol itself, the CoRE WG will also complete the work on 
RESTCONF-style management functions available via CoAP that are 
appropriate for constrained node networks (draft-ietf-core-yang-cbor, 
draft-ietf-core-sid, draft-ietf-core-comi, 
draft-ietf-core-yang-library). This requires very close coordination 
with NETCONF and other operations and management WGs. YANG data models 
are used for manageability. Note that the YANG modeling language is not 
a target for change in this process, although additional mechanisms that 
support YANG modules may be employed in specific cases where significant 
performance gains are both attainable and required. The CoRE WG will 
continue to consider the OMA LwM2M management functions as a 
well-accepted alternative form of management and provide support at the 
CoAP protocol level where required.

The CoRE WG originally selected DTLS as the basis for the communication 
security in CoAP. The CoRE WG will work with the TLS WG on the 
efficiency of this solution. The preferred cipher suites will evolve in 
cooperation with the TLS WG and CFRG.

The CoRE WG considered object security as originally defined in JOSE and 
later adapted to the constrained node network requirements in COSE. 
Building on that, the CoRE WG has defined the Object Security for 
Constrained RESTful Environments (OSCORE) protocol (RFC 8613) for 
protecting CoAP messages at the application layer using COSE. The CoRE 
WG will complete the work on the Group OSCORE protocol 
(draft-ietf-core-oscore-groupcomm) that enables OSCORE-protection of 
CoAP messages in group communication environments. Also, the CoRE WG 
will complete an optimization-oriented profiling of the EDHOC protocol 
developed in the LAKE WG, when this is used to establish security 
material for OSCORE (draft-ietf-core-oscore-edhoc). Furthermore, the 
CoRE WG will perform maintenance as well as possible updating and 
complementing of the (Group) OSCORE documents above as required.

The ACE WG is expected to provide solutions on authentication and 
authorization that may need complementary elements on the CoRE side.

The CoRE WG will coordinate on requirements from many organizations and 
SDOs. The CoRE WG will closely coordinate with other IETF WGs, 
particularly of the constrained node networks cluster (6Lo, 6TiSCH, 
LWIG, ROLL, ACE, CBOR, COSE, IOTOPS, LAKE, SUIT), and with further 
appropriate groups in the IETF OPS and Security Areas. Work on these 
subjects, as well as on data/interaction models and design patterns 
(including follow-up work around the CoRE Interfaces draft) will 
additionally benefit from close cooperation with the Thing-to-Thing 
Research Group.

=======================

-- 
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital System
Department: Computer Science
Unit: Cybersecurity

RISE Research Institutes of Sweden
https://www.ri.se

Phone: +46 (0)70 60 46 501
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

---

From: Marco Tiloca <[email-masked]>
Date: Thu, 16 Sep 2021 09:22:18 +0200

Hi all,

During the 2021-09-15 interim meeting [1], we had a good first 
discussion on the proposed new text for the possible updated charter.

As mentioned at the meeting, please take some time to review the new 
text and possibly provide input/comments. Even in case you are just fine 
with the text "as is", it is valuable feedback to say so.

Please, provide your comments and proposed changes:

- In this mail thread, where the first message [2] also includes the new 
proposed charter text;

and/or

- In this CodiMD document [3], where editing requires to be logged in 
with your Datatracker account.

The new charter text is also available on our Github at [4], together 
with a diff from the present charter text at [5].

Thanks,
Marco and Jaime

[1] 
https://datatracker.ietf.org/doc/minutes-interim-2021-core-10-202109151600/

[2] https://mailarchive.ietf.org/arch/msg/core/haBtninO85UjsyqASeeO0FFr_Wo/

[4] 
https://github.com/core-wg/core-wg.github.io/blob/master/core-charter.txt

[5] 
https://github.com/core-wg/core-wg.github.io/commit/133861a92ef62a2130427521455fb58bce23aa3e?branch=133861a92ef62a2130427521455fb58bce23aa3e&diff=split

On 2021-09-08 19:34, Marco Tiloca wrote:
> our charter, for better reflecting the current status of our work. 
> This is also helpful for the IESG review processing and for newcomers 
> to more easily understand the WG scope and direction.
>
> charter text. Please, provide your comments and proposed changes here 
> on the mailing list or in the CodiMD at [3] (editing requires to be 
> logged in).
>
> Best,
> Marco and Jaime
>
>
> IP network has limited packet sizes, may exhibit a high degree of 
> packet loss, and may have a substantial number of devices that may be 
> powered off at any point in time but periodically "wake up" for brief 
> periods of time. These networks and the nodes within them are 
> characterized by severe limits on throughput, available power, and 
> particularly on the complexity that can be supported with limited code 
> size and limited RAM per node [RFC 7228]. More generally, we speak of 
> constrained node networks whenever at least some of the nodes and 
> networks involved exhibit these characteristics. Low-Power Wireless 
> Personal Area Networks (LoWPANs) are an example of this type of 
> network. Constrained networks can occur as part of home and building 
> automation, energy management, and the Internet of Things.
>
> The CoRE WG will define a framework for a limited class of 
> applications: those that deal with the manipulation of simple 
> resources on constrained networks. This includes applications to 
> monitor simple sensors (e.g., temperature sensors, light sensors, and 
> power meters), to control actuators (e.g., light switches, heating 
> controllers, and door locks), and to manage devices.
>
> combinations of values, and/or other information. Devices send 
> messages to change and query resources on other Devices. A Device can 
> send notifications about changed resource values to Devices that have 
> expressed their interest to receive notification about changes. A 
> Device can also publish or be queried about its resources. Typically, 
> a single physical host on the network would have just one Device but a 
> host might represent multiple logical Devices. The specific 
> terminology to be used here is to be decided by the working group.
>
> manipulation of Resources on a Device. CoAP is designed for use 
> between Devices on the same constrained network, between Devices and 
> general nodes on the Internet, and between Devices on different 
> constrained networks both joined by an internet. CoAP is also being 
> used via other mechanisms, such as SMS on mobile communication 
> networks. CoAP targets the type of operating environments defined in 
> the ROLL and 6Lo WGs, which have additional constraints compared to 
> normal IP networks. Nevertheless, the CoAP protocol also operates over 
> traditional IP networks.
>
> also interconnect between other Internet protocols and the Devices 
> using the CoAP protocol. It is worth noting that a proxy does not have 
> to occur at the boundary between the constrained network and the more 
> CoAP supports various forms of "caching". Beyond the benefits of 
> caching already well known from REST, caching can be used to increase 
> energy savings of low-power nodes by allowing them to be normally-off 
> [RFC 7228]. For example, a temperature sensor might wake up every five 
> CoAP was initially designed to work over UDP and DTLS. Later on, 
> mapping were defined between CoAP and IP-based transports, especially 
> TCP and WebSockets including a secure version over TLS (RFC 8323). The 
> CoRE WG will continue defining transport mappings for alternative 
> transports as required, both IP-based and non IP-based (e.g., SMS and 
> Bluetooth), working with the Security Area on potentially addressing 
> the security gap. This includes defining appropriate URI schemes. 
> Continued compatibility with CoAP over SMS as defined in OMA 
> Lightweight Machine-to-Machine (LwM2M) will be considered. 
> Furthermore, the CoRE WG will work on solutions to facilitate the 
> signaling of transports available to a Device.
>
> updating, complementing and specification of relevant uses as 
> required. A primary related consideration is the interoperability with 
> DNS-SD and the work of the dnssd WG. The use of CoAP to transport DNS 
> queries and responses will also be investigated. Furthermore, the CoRE 
> WG will also continue and complete its work on enabling broker-based 
> representations of RFC 6690 link format and RFC 7390 group 
> communication information. Also, the CoRE WG will complete its work on 
> Constrained Resource Identifiers for serializing URI components in 
> CBOR (draft-ietf-core-href). Furthermore, the CoRE WG will develop 
> CoRAL (draft-ietf-core-coral), a constrained RESTful application 
> language suitable also for constrained node networks, which comprises 
> an information model and an interaction model, and is intended for 
> driving automated software agents that navigate a Web application. The 
> CoRE WG will complete the Sensor Measurement Lists (SenML) set of 
> are used for manageability. Note that the YANG modeling language is 
> not a target for change in this process, although additional 
> mechanisms that support YANG modules may be employed in specific cases 
> where significant performance gains are both attainable and required. 
> The CoRE WG will continue to consider the OMA LwM2M management 
> functions as a well-accepted alternative form of management and 
> provide support at the CoAP protocol level where required.
>
> The CoRE WG originally selected DTLS as the basis for the 
> communication security in CoAP. The CoRE WG will work with the TLS WG 
> on the efficiency of this solution. The preferred cipher suites will 
> evolve in cooperation with the TLS WG and CFRG.
>
> The CoRE WG considered object security as originally defined in JOSE 
> and later adapted to the constrained node network requirements in 
> COSE. Building on that, the CoRE WG has defined the Object Security 
> for Constrained RESTful Environments (OSCORE) protocol (RFC 8613) for 
> The CoRE WG will coordinate on requirements from many organizations 
> and SDOs. The CoRE WG will closely coordinate with other IETF WGs, 

-- 
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital System

---

From: Esko Dijk <[email-masked]>
Date: Mon, 20 Sep 2021 12:17:41 +0000

Hello,

Current text looks good to me. It is a quite detailed charter; good to have it updated now to reflect recent progress. Also it is good as an introduction to CoRE, or as overview of the latest status & work.
Possible downside of a detailed charter is that it needs to be updated more often!

Regards
Esko

-----Original Message-----
From: core <[email-masked]> On Behalf Of Marco Tiloca
Sent: Thursday, September 16, 2021 09:22
To: [email-masked] WG ([email-masked]) <[email-masked]>
Subject: Re: [core] CoRE rechartering: proposed text

Hi all,

and/or

Thanks,
Marco and Jaime

[1] 

[4] 

[5] 

-- 
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital System