Skip to content

Compressed charter text #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Compressed charter text #1

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
4e65916
Compressed charter text
marco-tiloca-sics Oct 13, 2021
df781f5
Landing page
marco-tiloca-sics Mar 2, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
63 changes: 44 additions & 19 deletions core-charter.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,40 +1,65 @@
Charter for Working Group
Charter for Working Group

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 Working Group (WG) provides a framework for resource-oriented applications intended to run on constrained IP networks. A constrained IP network may have additional constraints compared to normal IP networks such as limited packet sizes, and a high degree of packet loss. 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 or limited RAM per node [RFC 7228]. 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.
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.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't we just refer to RFC7228 here? Do we need to explain this again and again?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

7228 would be a great reference for "nodes on the constrained network", but constrainedness is not what this paragraph is about.


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.
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.

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:
The CoRE WG has completed a set of standards-track specifications building on the CoAP specification [RFC 7252] and will perform maintenance as well as possible updating and complementing the framework in areas of resource discovery, group communication, data formats, operation and management, and CoAP related security.

- RFC 6690
- RFC 7252
- RFC 7641
- RFC 7959
Candidate work items include:

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.
* evolve the support for CoAP group communication originally developed in the Experimental RFC 7390(but not develop a solution for reliable multicast delivery of CoAP messages)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that this work should have been parcelled out to another WG (perhaps ACE, perhaps a new WG).
I don't think that we should keep this work in CORE, going forward.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why? Group communication is one of the unique features of CoAP, and it should be further developed with the rest of CoAP.
(ACE is completely unrelated to this subject.)


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.
* continue defining transport mappings for alternative transports as required, both IP-based and non IP-based

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.
* solutions to facilitate the signalling of transports available to a Device.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find this objective very vague. It sounds like an entirely new GRASP or mDNS or DHCP based protocol.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's not what it is. We probably have to expand this text slightly.


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).
* continue and complete its work on the CoRE Resource Directory
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why on earth? DNS-SD is stuck in the DNS world. They wouldn't be able to do this.


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.
* consideration of interoperability with DNS-SD and the work of the dnssd WG.

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.
* use of CoAP to transport DNS queries and responses will also be investigated.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should do this work in CORE.
I think that DNSOP should do this work. Of course, CORE will get consulted, but I think that we shouldn't do this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Of course, the two WGs should work together on this. Doing this right will need to be in CoRE.


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.
* enabling broker-based publish-subscribe-style communication over CoAP

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.
* related data formats, such as alternative representations of RFC 6690 link

The ACE WG is expected to provide solutions on authentication and authorization that may need complementary elements on the CoRE side.
* Constrained Resource Identifiers for serializing URI components in CBOR

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.
* develop CoRAL, a constrained RESTful application language intended for driving automated software agents that navigate a Web application

* complete the Sensor Measurement Lists (SenML) set of specifications
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that SenML belongs in CORE anymore. Probably doesn't belong in ASDF.
Is there much work left to do?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maintenance of a protocol is usually done where it originated.
(No, not much work, but the occasional nit.)


* continuing to examine operational and manageability aspects of the CoAP protocol itself

* complete the work on RESTCONF-style management functions available via CoAP that are appropriate for constrained node networks

* efficiency of DTLS as the basis for the communication security in CoAP
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know what this work item is, but I definitely don't feel it belongs here.


* preferred cipher suites in cooperation with the TLS WG and CFRG.

* complete the work on the Group OSCORE protocol that enables protection of CoAP messages in group communication environments.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why can't LAKE do this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because the intention is to integrate this with CoAP so it is efficient.


* perform maintenance as well as possible updating and complementing of the (Group) OSCORE documents above as required.

* solutions on authentication and authorization may need complementary elements on the CoRE side.

The CoRE WG will coordinate:

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okay, but really are even doing anything explicit?
6TISCH is closed. ROLL has never used CoAP or CBOR (that might be a bug)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, remove closed WGs.


* with further appropriate groups in the IETF OPS and Security Areas,

* with the IRTF Thing-to-Thing Research Group, and

* with other SDOs building on CoAP such as OMA Specworks.
21 changes: 14 additions & 7 deletions index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,9 +6,9 @@ You can see the current drafts on the [CoRE WG Github](https://github.com/core-w

### Upcoming Meetings

We will be having [virtual interim meetings](https://datatracker.ietf.org/meeting/upcoming) every other week, until July.
We will be having [virtual interim meetings](https://datatracker.ietf.org/meeting/upcoming) every other week, until 2022-03-02.

We will meet at [IETF 111](https://datatracker.ietf.org/meeting/111/session/core), on Wednesday, 2021-07-28.
We will meet at [IETF 113](https://datatracker.ietf.org/meeting/113/session/core), on Friday, 2022-03-25.

### CoAP Implementations

Expand Down Expand Up @@ -51,11 +51,6 @@ There is a number of [available implementations of CoAP](http://coap.technology)
[WG Draft](https://tools.ietf.org/html/draft-ietf-core-dynlink) /
[Repo](https://github.com/core-wg/dynlink) /
[Issues](https://github.com/core-wg/dynlink/issues)
* **echo-request-tag** -
[Editors’ Draft](https://core-wg.github.io/echo-request-tag/draft-ietf-core-echo-request-tag.html) /
[WG Draft](https://tools.ietf.org/html/draft-ietf-core-echo-request-tag) /
[Repo](https://github.com/core-wg/echo-request-tag) /
[Issues](https://github.com/core-wg/echo-request-tag/issues)
* **fasor** -
[Editors’ Draft](https://core-wg.github.io/fasor/draft-ietf-core-fasor.html) /
[WG Draft](https://tools.ietf.org/html/draft-ietf-core-fasor) /
Expand Down Expand Up @@ -179,6 +174,16 @@ Editors’ Draft /
[WG Draft](https://tools.ietf.org/html/draft-ietf-core-dev-urn) /
Repo /
Issues
* **[RFC9100](https://tools.ietf.org/html/rfc9175) senml-versions** -
[Editors’ Draft](https://core-wg.github.io/senml-versions/draft-ietf-core-senml-versions.html) /
[WG Draft](https://tools.ietf.org/html/draft-ietf-core-senml-versions) /
[Repo](https://github.com/core-wg/senml-versions) /
[Issues](https://github.com/core-wg/senml-versions/issues)
* **[RFC9175](https://tools.ietf.org/html/rfc9175) echo-request-tag** -
[Editors’ Draft](https://core-wg.github.io/echo-request-tag/draft-ietf-core-echo-request-tag.html) /
[WG Draft](https://tools.ietf.org/html/draft-ietf-core-echo-request-tag) /
[Repo](https://github.com/core-wg/echo-request-tag) /
[Issues](https://github.com/core-wg/echo-request-tag/issues)

### All CoRE WG RFCs

Expand All @@ -199,3 +204,5 @@ Issues
* [Additional Units for Sensor Measurement Lists (SenML)](https://tools.ietf.org/html/rfc8798)
* [Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)](https://tools.ietf.org/html/rfc8974)
* [Uniform Resource Names for Device Identifiers](https://tools.ietf.org/html/rfc9039)
* [Sensor Measurement Lists (SenML) Features and Versions](https://tools.ietf.org/html/rfc9100)
* [Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing](https://tools.ietf.org/html/rfc9175)