Subject: Re: [core] CoRE rechartering: proposed text

From: Marco Tiloca <[email-masked]>
Date: Thu, 14 Oct 2021 15:56:20 +0200

Hi all,

Following the discussion at the 2021-10-13 interim meeting [1], we have 
now made available the compressed charter text proposed by Göran --- Thanks!

This is essentially a subset of the original proposal from 2021-09-08 
with roughly the same content but fewer words. Hence, it is an improved 
starting point to build a revised charter for more convenient consideration.

You can find the compressed text as a Pull Request at [2] and at the top 
of the usual CodiMD document at [3]. No word-smithing has been done on 
this text yet.

Please, provide any comment and contribution on [2] and [3] as you prefer.

Thanks,
Marco and Jaime

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

[2] https://github.com/core-wg/core-wg.github.io/pull/1

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

On 2021-09-20 14:17, Esko Dijk wrote:
> 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,
>
> 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fminutes-interim-2021-core-10-202109151600%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cdb0df2811ff940f7d5f308d97c30adbd%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637677371541036914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=QOc1k5wnajJE0H%2B7gSKx5RAmjWrI6eC3pIJz38f1Ksk%3D&amp;reserved=0
>
> [2] https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fcore%2FhaBtninO85UjsyqASeeO0FFr_Wo%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cdb0df2811ff940f7d5f308d97c30adbd%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637677371541036914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=1opdeqGfrPVvgperbBLRrb%2Fn9oMMxQHHGp9li5UnlW4%3D&amp;reserved=0
>
> [3] https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnotes.ietf.org%2FBkpQ-gttSRuVKlEgxho5gw%3Fboth&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cdb0df2811ff940f7d5f308d97c30adbd%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637677371541036914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=wy7ZjbOS%2Fq8AKEu5N4l67WVb322r0pYYvwEYjsLQomo%3D&amp;reserved=0
>
> [4]
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcore-wg%2Fcore-wg.github.io%2Fblob%2Fmaster%2Fcore-charter.txt&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cdb0df2811ff940f7d5f308d97c30adbd%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637677371541036914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=GUk2LT8JmyhSRH1cXjWjKkc%2BPtDfiRKjrUNsQVofLok%3D&amp;reserved=0
>
> [5]
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcore-wg%2Fcore-wg.github.io%2Fcommit%2F133861a92ef62a2130427521455fb58bce23aa3e%3Fbranch%3D133861a92ef62a2130427521455fb58bce23aa3e%26diff%3Dsplit&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cdb0df2811ff940f7d5f308d97c30adbd%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637677371541036914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=PrCkKcNmh%2FxDWOyfRCSeuClrvu9oPpjNJJai77AGiZE%3D&amp;reserved=0
>
>
> On 2021-09-08 19:34, Marco Tiloca wrote:
>> 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fminutes-111-core%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cdb0df2811ff940f7d5f308d97c30adbd%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637677371541036914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=hp16Z5Pul%2BWqb3%2B3tZLBcqG9zpdacPKES39lKlQwYxk%3D&amp;reserved=0
>>
>> [2]
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F111%2Fmaterials%2Fslides-111-core-chairs-slides-00.pdf&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cdb0df2811ff940f7d5f308d97c30adbd%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637677371541036914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=5KYC8BayVPx1Av5wXVkYHRruS1WZelLIVdmsutk0q8o%3D&amp;reserved=0
>>
>> [3] https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnotes.ietf.org%2FBkpQ-gttSRuVKlEgxho5gw%3Fboth&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cdb0df2811ff940f7d5f308d97c30adbd%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637677371541036914%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=wy7ZjbOS%2Fq8AKEu5N4l67WVb322r0pYYvwEYjsLQomo%3D&amp;reserved=0
>>
>>
>> =======================
>>
>> 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: Carsten Bormann <[email-masked]>
Date: Thu, 14 Oct 2021 17:46:22 +0200

> You can find the compressed text as a Pull Request at [2] and at the top of the usual CodiMD document at [3]. No word-smithing has been done on this text yet.

Pre-warning: I think the long shopping list in the middle needs subheadings (which charters don’t have yet), so expect a PR from me within a week (unless someone else beats me to it).

Grüße, Carsten

> [1] https://datatracker.ietf.org/doc/minutes-interim-2021-core-12-202110131600/
>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 16 Oct 2021 18:57:27 -0400

Hi, I commented on the pull request

> https://github.com/core-wg/core-wg.github.io/pull/1

In summary, I think that we have done a poor job at all of the DTLS things,
and we should have done more work with the TLS WG on this.
That might mean that the IESG needs, when removing this from our charter,
inserting it into the TLS WG charter.

for instance:
> * efficiency of DTLS as the basis for the communication security in CoAP

On the GroupCom security side, unless the work is about to be approved by the
IESG, then I think it should get another WG.  Alas, "short-lived WGs" can
take years to spin up, so I guess it will stay here.  I suggest that the WG
may wish to allocate alternating virtual interims to this in order to
establish a cadence and get the work finished.

Given the virtual interim cadence, I would like to discourage the WG from
holding meetings during the plenary week.

I see that senML document is at the IESG.
I think that if there is more work to do on SenML that it be done elsewhere.

> * optimization-oriented profiling of the EDHOC protocol to establish security material for OSCORE

Why can't LAKE do this?

> * with other IETF WGs, particularly of the constrained node networks
> cluster (6Lo, 6TiSCH, LWIG, ROLL, ACE, CBOR, COSE, IOTOPS, LAKE, SUIT,
> ASDF),

okay, but really are even doing anything explicit?
Can we even depend upon people being in all these groups given the conflicts?
That's partly what IOTOPS is *for*

> * continue and complete its work on the CoRE Resource Directory

Since we say that we want to be DNS-SD interoperable, I wonder if, at this
point, the work should be transferred to DNS-SD. I have seen no evidence that
we've consulted with DNS-SD.  Maybe I missed that part.

I think that any WG that tries to focus on more than three items will find
that really, it will focus is on zero items.  yang-cbor situation is what happens.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 17 Oct 2021 01:16:05 +0200

Hi Michael,

I commented on the individual proposals in the GitHub repo, but I’m really surprised at how bad most of them would be for getting any useful work done.
Whether some work should be in a specific WG does not depend on some abstract academic concept of how the world is structured, but on having the people assembled who can do good work.  E.g., I’m having a hard time believing that any useful work on using CoAP with DTLS would happen in the TLS WG; the people there have quite different priorities.  SenML may not be useful to you, but it is out there in actual use and we have done and are doing occasional maintenance (RFC 8798, draft-ietf-core-senml-data-ct); no other WG is going to do that properly (even though, yes, it may be weird to have a WG that does both a protocol and a couple of data formats that go with that protocol; er, maybe not so unusual).

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Sat, 16 Oct 2021 20:14:45 -0400

Carsten Bormann <[email-masked]> wrote:
    > I commented on the individual proposals in the GitHub repo, but I’m
    > really surprised at how bad most of them would be for getting any
    > useful work done.

There is a lot of useful work in CORE's charter which is not getting done.

    > Whether some work should be in a specific WG does not depend on some
    > abstract academic concept of how the world is structured, but on having
    > the people assembled who can do good work.  E.g., I’m having a hard
    > time believing that any useful work on using CoAP with DTLS would
    > happen in the TLS WG;

I probably have even more wounds on this than you.
But, we won't get it done here.  Let's not say we are going to try.

    > the people there have quite different priorities.
    > SenML may not be useful to you, but it is out there in actual use and
    > we have done and are doing occasional maintenance (RFC 8798,

It's because I think it's useful that I think it deserves its own place.
When a WG has so many focuses it has no focuses.  I point to OPSAWG.

I think that we all agree that the existing charter would never get approved today.
That's why rechartering is scary.

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 17 Oct 2021 07:09:30 +0200

> There is a lot of useful work in CORE's charter which is not getting done.

Making it harder to do that work is not going to help with this.

I understand that the progress of CORECONF is frustrating.
But that is no reason to shut down other work that is proceeding at a reasonable pace.
It’s not like the OSCORE people will suddenly put time into the latest YANG problem if they can’t work on group communication any more.

> But, we won't get it done here.  Let's not say we are going to try.

A charter is meant to provide a frame for the WG to work in.
If nobody wants to move this forward, it won’t happen if we move it to a WG that isn’t interested.
(I don’t have any particular wounds with the TLS WG because I wouldn’t even try to do work there that is related to CoRE.
We did manage to pull off a DICE WG in 2013 to get RFC 7925; but that was a non-trivial effort; not sure we have anything at that level on our plates right now.)

> It's because I think it's useful that I think it deserves its own place.

That wouldn’t make a lot of sense, because the maintenance needed for SenML is really limited.
(The current wording about “completing” SenML may give the wrong impression.)

> When a WG has so many focuses it has no focuses.  I point to OPSAWG.

I think we have a laser-sharp focus compared to OPSAWG…
(I also think we have a relatively well-working WG going on, in particular since I stopped being involved in its management :-)

> That's why rechartering is scary.

If that is the diagnostic, we probably shouldn’t spend time trying to do it.

Grüße, Carsten