Compressed charter text #1
Conversation
|
|
||
| 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. |
There was a problem hiding this comment.
Can't we just refer to RFC7228 here? Do we need to explain this again and again?
There was a problem hiding this comment.
7228 would be a great reference for "nodes on the constrained network", but constrainedness is not what this paragraph is about.
|
|
||
| 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) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.)
|
|
||
| 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. |
There was a problem hiding this comment.
I find this objective very vague. It sounds like an entirely new GRASP or mDNS or DHCP based protocol.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Why on earth? DNS-SD is stuck in the DNS world. They wouldn't be able to do this.
|
|
||
| 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Of course, the two WGs should work together on this. Doing this right will need to be in CoRE.
| 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 |
There was a problem hiding this comment.
I don't think that SenML belongs in CORE anymore. Probably doesn't belong in ASDF.
Is there much work left to do?
There was a problem hiding this comment.
Maintenance of a protocol is usually done where it originated.
(No, not much work, but the occasional nit.)
|
|
||
| * 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 |
There was a problem hiding this comment.
I don't know what this work item is, but I definitely don't feel it belongs here.
|
|
||
| * 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 |
There was a problem hiding this comment.
Because the intention is to integrate this with CoAP so it is efficient.
|
|
||
| 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), |
There was a problem hiding this comment.
okay, but really are even doing anything explicit?
6TISCH is closed. ROLL has never used CoAP or CBOR (that might be a bug)
|
With all these comments leading into the woods, I'm getting more certain that we don't want to do this recharter. |
No description provided.