Thing-to-Thing Research Group (T2TRG) L. Toutain
Internet-Draft IMT Atlantique
Intended status: Informational 16 September 2026
Expires: 20 March 2027
CORECONF for Machine-to-Machine Communication
draft-toutain-t2trg-coreconf-m2m-01
Abstract
The document addresses the specific challenges of M2M interactions
where both endpoints may be constrained nodes, and explores the use
of CORECONF primitives.
This document describes the use of CORECONF (CoAP Management
Interface) for Machine-to-Machine (M2M) communication in constrained
IoT environments. It defines a YANG data model enabling remote
management and configuration of constrained devices using CoAP, CBOR,
and YANG SID identifiers. The serialization in CBOR of this data
model limits the payload size. It documents also how the YANG data
model can interact with common IoT ontologies such as SOSA or SAREF.
The same CORECONF/SID serialization also enables full
interoperability between constrained devices and AI agents, by
exposing device actions and data through an MCP (Model Context
Protocol) server without requiring an intermediate, device-specific
translation layer.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-toutain-t2trg-coreconf-m2m/.
Discussion of this document takes place on the T2TRG Research Group
mailing list (mailto:t2trg@irtf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/t2trg/. Subscribe at
https://www.ietf.org/mailman/listinfo/t2trg/.
Source for this draft and an issue tracker can be found at
https://github.com/ltn22/coreconf-m2m.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Toutain Expires 20 March 2027 [Page 1]
Internet-Draft coreconf-m2m September 2026
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 20 March 2027.
Copyright Notice
Copyright (c) 2026 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Data Representation . . . . . . . . . . . . . . . . . . . 6
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 7
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. YANG Modules needed for coreconf-m2m . . . . . . . . . . . . 7
3.1. Identities Data Model . . . . . . . . . . . . . . . . . . 8
3.2. Overview of the coreconf-m2m Module . . . . . . . . . . . 8
3.2.1. Bootstrap Sub-Tree . . . . . . . . . . . . . . . . . 9
3.2.2. Characteristics Sub-Tree . . . . . . . . . . . . . . 10
3.2.3. Transducer Sub-Tree . . . . . . . . . . . . . . . . . 11
3.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 14
4. CORECONF Overview in the M2M Context . . . . . . . . . . . . 15
4.1. CoAP Methods Mapping . . . . . . . . . . . . . . . . . . 15
4.2. SID Allocations . . . . . . . . . . . . . . . . . . . . . 16
5. CORECONF Traffic . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Resource Discovery . . . . . . . . . . . . . . . . . . . 16
5.2. Querying a quantity . . . . . . . . . . . . . . . . . . . 19
5.3. Notification . . . . . . . . . . . . . . . . . . . . . . 20
6. From CBOR/SID to Textual Identifiers . . . . . . . . . . . . 23
7. Interconnection with an Ontology . . . . . . . . . . . . . . 24
7.1. Extending Ontology to coreconf-m2m . . . . . . . . . . . 24
7.2. SOSA . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Toutain Expires 20 March 2027 [Page 2]
Internet-Draft coreconf-m2m September 2026
7.2.1. Instantiating from YANG . . . . . . . . . . . . . . . 26
7.2.2. Control . . . . . . . . . . . . . . . . . . . . . . . 28
7.2.3. Storing Transducer Quantities . . . . . . . . . . . . 30
7.2.4. Storing Actuator Commands . . . . . . . . . . . . . . 31
7.3. SensorThings . . . . . . . . . . . . . . . . . . . . . . 33
7.3.1. Example . . . . . . . . . . . . . . . . . . . . . . . 33
7.4. SAREF . . . . . . . . . . . . . . . . . . . . . . . . . . 38
8. MCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
9. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 41
9.1. SID translation . . . . . . . . . . . . . . . . . . . . . 41
9.2. SCHC . . . . . . . . . . . . . . . . . . . . . . . . . . 42
10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 42
11. Security Considerations . . . . . . . . . . . . . . . . . . . 43
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
12.1. YANG Module Registration . . . . . . . . . . . . . . . . 43
12.2. SID Range Allocation . . . . . . . . . . . . . . . . . . 43
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
13.1. Normative References . . . . . . . . . . . . . . . . . . 43
13.2. Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. Module Tree . . . . . . . . . . . . . . . . . . . . 47
Appendix B. Complete YANG Module . . . . . . . . . . . . . . . . 49
Appendix C. SID File (CSV) . . . . . . . . . . . . . . . . . . . 64
Appendix D. atmos YANG Module . . . . . . . . . . . . . . . . . 66
Appendix E. atmos SID File (CSV) . . . . . . . . . . . . . . . . 71
Appendix F. ccm2m Ontology . . . . . . . . . . . . . . . . . . . 71
Appendix G. SCHC Rule Set . . . . . . . . . . . . . . . . . . . 75
G.1. Rule 0: Used to fetch a single value (bidirect) . . . . . 76
G.2. Rule 1: Used to iPatch, ack with 7/3. Empty CoAP for
notification in UP . . . . . . . . . . . . . . . . . . . 80
G.3. Rule 2: Used for notitifications (observe) . . . . . . . 82
G.4. Rule 3: Empty messages (e.g., ACK with empty code, or
RST) . . . . . . . . . . . . . . . . . . . . . . . . . . 86
G.5. Rule 4: ICMPv6 destination unreachable (any code) . . . . 86
Appendix H. Private SID Translation . . . . . . . . . . . . . . 88
H.1. Worked Example (atmos first) . . . . . . . . . . . . . . 89
H.2. Second Example: Time-Series Subscription and
Notification . . . . . . . . . . . . . . . . . . . . . . 90
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 90
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 91
1. Introduction
This document proposes a YANG data model designed for constrained
devices and low-power networks. By combining YANG's strong typing
with CBOR's compact binary serialization and CoAP's lightweight
transport, the model enables efficient Machine-to-Machine (M2M) data
exchange while remaining within the bandwidth and energy budgets of
constrained environments. SCHC header compression [RFC8724] may
Toutain Expires 20 March 2027 [Page 3]
Internet-Draft coreconf-m2m September 2026
further be used to reduce the overhead of IPv6, UDP, and CoAP headers
on the most constrained links.
Some data models and protocols already exist for M2M communication in
IoT environments, but none is fully adapted to the constraints of
low-power networks in terms of message size, energy consumption, and
interaction patterns. This section reviews the main existing
approaches and explains why a new model is needed.
SenML [RFC8428] has become a widely adopted format for Machine-to-
Machine (M2M) data exchange in IoT environments, enabling constrained
devices to report sensor measurements and time series in JSON or
CBOR. However, SenML is primarily a data serialization format: it
structures payloads but does not enforce strong type checking, schema
validation, or support for configuration and remote operations.
SenML is also part of the LwM2M framework [OMA-LwM2M], which defines
a broader device management protocol built on CoAP and SenML for
operator-to-device interactions. However, LwM2M relies on periodic
reporting and registration messages that impose a non-trivial
overhead, particularly on Low-Power Wide-Area Networks (LPWANs)
[RFC8376] where bandwidth and energy budgets are severely
constrained.
In some ways, SenML may be described by a YANG Data Model
[I-D.gudi-t2trg-senml-as-coreconf], but the integration in the YANG
ecosystem remains limited.
The CORECONF protocol stack using YANG [RFC7950] for Data Modeling,
CoAP [RFC7252] for data transport, and CBOR [RFC8949] and YANG SID
identifiers [I-D.ietf-core-sid] for the compact data serialization
provides the richer foundation that SenML lacks: a strongly typed
data model, schema validation, and support for full CRUD operations
and actions. However, CORECONF has so far been designed for
operator-to-device management, leaving peer-to-peer M2M communication
— where both endpoints may themselves be constrained nodes — largely
unaddressed.
Some YANG Data Models have been defined for telemetry. [RFC9232]
introduces Network Telemetry used to collect vast amounts of data to
supervise a network. [RFC8639] allows subscribing to a datastore
filtered through XPath and receiving notifications.
[I-D.birkholz-yang-core-telemetry] proposes to extend telemetry to
CORECONF, but using a traditional approach. None of these attempt to
limit the size of the exchanged data, which is essential on the
constrained links this document targets.
Toutain Expires 20 March 2027 [Page 4]
Internet-Draft coreconf-m2m September 2026
This document adopts a different approach. The goal is to define a
YANG Data Model that will benefit from CBOR serialization to optimize
the bandwidth to extend CORECONF for M2M use cases over low-power
links. The data model turns around transducers held by a device. A
transducer is the abstract representation of a sensor and/or an
actuator, transforming an analog value into a digital value, or a
digital value into a physical action. This document focuses on
transducer management: resource discovery, value polling, statistical
computation, threshold alerts, and time-series history notifications.
This is an early-stage work; future revisions will explore other
categories of measurements and interaction patterns.
Beyond its use as a wire format, the structure defined by the YANG
Data Model can be mapped into a Semantic Web ontology, giving each
container, list, and leaf a counterpart class or property that common
IoT ontologies such as SOSA or SensorThings already understand.
Section 7.1 details this mapping and how it lets a device modeled
with coreconf-m2m be integrated into an existing ontology-based
deployment without a device-specific adaptation layer.
1.1. Use Cases
The targeted use cases are remote sensors installed in the field and
connected with LPWAN or Satellite connectivity. SCHC [RFC8724]
[RFC8824] is used to compress headers such as IPv6, UDP and CoAP for
CORECONF traffic. The payload results from the serialization of the
datastore in CBOR.
The model covers the following use cases:
* resource discovery: sensors or actuators, regrouped under the name
transducers, are discovered with their characteristics (units,
precision)
* simple query: each transducer can be individually queried or set.
* statistical computation: the sensor can compute some statistical
values, such as mean, variance, min and max. They can be reset.
* alert notification: when a value reaches a threshold (minimum and
maximum) a notification message is sent
* time series: values are collected by the device and sent when a
limit is reached (number of samples, duration, message size)
Toutain Expires 20 March 2027 [Page 5]
Internet-Draft coreconf-m2m September 2026
1.2. Data Representation
CBOR is designed to be concise to represent numerical information
since it is directly coded in binary and not represented in ASCII.
CBOR also uses binary representation to encode structures such as
Maps and Arrays. The length of a numerical value depends on its
value; for instance, numbers between -24 and 23 are coded on a single
byte, values between -255 and 255 on two bytes,...
Nevertheless, some representations may be less efficient numerically
or less precise. CBOR defines three IEEE 754 encodings on 3, 5, or 9
bytes. The smallest representation introduces a close to 1% error.
CBOR also provides a decimal fraction type (tag 4) encoding a value
as a [exponent, mantissa] pair, which avoids floating-point rounding.
However, this representation requires the exponent (the divider) to
be repeated alongside every individual quantity, adding overhead for
each encoded value.
The assumption leading to this YANG module is to avoid floating-point
numbers for their size or precision and rely on integers with a
precision parameter indicating, if positive, the number of digits
after the decimal point, or the power of 10 if negative.
The module also introduces the notion of time series to record
several measurements during a period of time and send them in a
single message using a notification. Time series values may further
be compressed depending on the nature of the data. This version
proposes a compression based on delta encoding: instead of
transmitting absolute values, each sample is encoded as the
difference from the previous one, which significantly reduces the
CBOR payload size for slowly-varying measurements.
The device can also send an alert when a measured value reaches a
threshold, allowing the receiver to react promptly without waiting
for a scheduled report.
Since the targeted networks are constrained in bandwidth,
measurements are expected to be reported infrequently, so the second
is chosen as the time unit. To limit the size of the timestamps,
they are expressed as the number of seconds elapsed since the
equipment was started, rather than as an absolute date and time. If
the equipment is able to do so, it can indicate its startup epoch to
reconstitute an absolute time.
Toutain Expires 20 March 2027 [Page 6]
Internet-Draft coreconf-m2m September 2026
1.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Terminology
The following terminology is used in this document:
CORECONF: : CoAP Management Interface, as defined in
[I-D.ietf-core-comi].
M2M: : Machine-to-Machine communication, referring to direct data
exchanges between devices without human intervention.
SID: : YANG Schema Item iDentifier, a compact numeric identifier for
YANG data nodes, as defined in [I-D.ietf-core-sid].
Constrained Device: : A device with limited processing, memory, and
energy resources, as characterized in [RFC7228].
Device: : A piece of equipment containing one or more transducers.
Transducer: : an interface between the analog and digital world.
Transducers are sensors reporting values or actuators having an
action on the physical world.
Quantity: : values manipulated by transducers.
Value: : other information stored in the datastore including
quantities
3. YANG Modules needed for coreconf-m2m
coreconf-m2m YANG module is a framework: it defines the generic
structure of a CORECONF server hosting one or several transducers, a
generic name for a sensor or an actuator, but it does not define the
transducers themselves. Each transducer is identified by a unique
identity, and if several transducers report the same kind of
measurement, several instances of the same identity have to be
defined.
Toutain Expires 20 March 2027 [Page 7]
Internet-Draft coreconf-m2m September 2026
A device manufacturer using coreconf-m2m MUST therefore define, or
reuse, a YANG module describing the transducers embedded in its
device, as identities extending the base "transducer-type" identity
defined in coreconf-m2m (see Section 3.1).
3.1. Identities Data Model
The identity data model defines all the transceivers that may be used
inside the hosts, this can be a generic data model or a model
specific to the hosts. This module indicates default parameters used
for that transceiver (units, precision, nature). These values are
mandatory and may be overridden by the coreconf-m2m.
A manufacturer module defines the concrete transducer-type identities
for a given product family; coreconf-m2m only defines the base
"transducer-type" identity that these modules extend. The ATMOS41
weather station example used throughout this document is defined this
way, in a separate "atmos" module that imports coreconf-m2m and
extends its base identity with atmospheric and weather-related
transducer types.
coreconf-m2m defines the template for identities extensions.
Figure 1 gives an example of an identity definition, where "ccm2m"
refers to the coreconf-m2m module.
identity air-temperature {
base ccm2m:transducer-type;
ccm2m:default-category "sensor";
ccm2m:default-unit "Cel";
ccm2m:default-precision "2";
description "Air temperature measurement (°C).";
}
Figure 1: Example of an identity definition using the coreconf-
m2m extensions
Identity names and descriptions SHOULD be explicit, since this
information may be used by a human, e.g. through an interface, or by
an AI agent, to formulate requests.
3.2. Overview of the coreconf-m2m Module
The coreconf-m2m module is organized into three sub-modules:
Toutain Expires 20 March 2027 [Page 8]
Internet-Draft coreconf-m2m September 2026
* "bootstrap" contains the context needed by the client to interact
with the server and its transducers. It mainly contains the time
reference and the transducer list. These values cannot be changed
by the client (config false); only a reboot, which also resets the
communications, allows their modification
- "characteristics" contains stable information describing the
host. This information may be necessary for some ontologies
such as [SOSA] and [SAREF]. These values may be modified
during runtime, and
* "transducers" contains the runtime values of all the sensors and
actuators maintained by the host. It also contains parameters to
control notifications issued by the device.
* an RPC, now limited to resetting all statistics
* two notification types: one to collect time-series history, and
one to alert when a quantity reaches a minimum or maximum
threshold.
Figure 28 in Appendix A gives an overview of the module YANG tree.
3.2.1. Bootstrap Sub-Tree
module: coreconf-m2m
+--ro bootstrap
+--ro reference-epoch? uint64
+--ro uptime uint64
+--ro minimal-step? uint32
+--ro inventory* [type]
+--ro type identityref
+--ro unit-override? string
+--ro precision-override? uint8
+--ro category-override? enumeration
Figure 2: bootstrap sub-tree
The bootstrap sub-tree contains information determined at bootstrap:
* reference-epoch: the absolute time at bootstrap, if a reference
time source (battery-powered clock, GPS, ...) is available on the
device. This leaf is absent if no reference time is available.
* uptime: the number of seconds elapsed since bootstrap. A client
can combine reference-epoch and uptime to estimate clock drift or
propagation delay.
Toutain Expires 20 March 2027 [Page 9]
Internet-Draft coreconf-m2m September 2026
* minimal-step: the minimum number of seconds between two
transceiver readings. For instance, if a node updates its reading
every 2 minutes, querying it more frequently only increases
battery drain without yielding fresher data.
* inventory: the list of transducers known to the device, identified
by their "type" and their configuration overrides (see
Section 3.2.3).
These values can only change on a reboot, which also resets the
communications and forces the client into a new bootstrap phase to
recover the data.
3.2.2. Characteristics Sub-Tree
module: coreconf-m2m
+--rw characteristics
+--rw geo-location
| +--rw reference-frame
| | +--rw alternate-system? string {alternate-systems}?
| | +--rw astronomical-body? string
| | +--rw geodetic-system
| | +--rw geodetic-datum? string
| | +--rw coord-accuracy? decimal64
| | +--rw height-accuracy? decimal64
| +--rw (location)?
| | +--:(ellipsoid)
| | | +--rw latitude? decimal64
| | | +--rw longitude? decimal64
| | | +--rw height? decimal64
| | +--:(cartesian)
| | +--rw x? decimal64
| | +--rw y? decimal64
| | +--rw z? decimal64
| +--rw velocity
| | +--rw v-north? decimal64
| | +--rw v-east? decimal64
| | +--rw v-up? decimal64
| +--rw timestamp? yang:date-and-time
| +--rw valid-until? yang:date-and-time
+--rw name? string
+--rw version? string
+--rw identifier? string
+--rw description? string
+--rw manufacturer? string
+--rw model? string
+--rw hosted-by? string
+--rw installation-time? uint64
Toutain Expires 20 March 2027 [Page 10]
Internet-Draft coreconf-m2m September 2026
Figure 3: characteristics sub-tree
This sub-tree contains stable information about the device that is
not expected to change across reboots:
* geo-location: the fixed geographic position of the device, set
once at deployment and not expected to change during normal
operation. The module reuses the "ietf-geo-location" YANG module
[RFC9179], of which only the "ellipsoid" choice is normally
needed. Note that its coordinates are typed as "decimal64",
encoded in CBOR as a tagged array containing an exponent and a
mantissa. This encoding was not chosen for transducer values, in
order to avoid repeating the exponent (called "precision" in this
model) with every quantity.
If the device is mobile, its coordinates should instead be exposed
through a transducer.
* name: a human-readable name for the device.
* version: the firmware or software version running on the device.
* identifier: a unique identifier for the device, such as a serial
number or EUI.
* description: a free-text description of the device, its purpose,
or its deployment context.
* manufacturer: the name of the device manufacturer.
* model: the commercial model name or number of the device.
* hosted-by: an identifier of the platform hosting this device, when
applicable.
* installation-time: the absolute date and time (Unix epoch, in
seconds) at which the device was installed or commissioned.
Unlike bootstrap/reference-epoch, this is an absolute value, not a
reference point for the device's internal clock.
3.2.3. Transducer Sub-Tree
Toutain Expires 20 March 2027 [Page 11]
Internet-Draft coreconf-m2m September 2026
module: coreconf-m2m
+--rw transducers
+--rw transducer* [type]
+--rw type identityref
+--ro quantity
| +--ro value? int64
| +--ro timestamp? uint64
| +--ro timestamp-source? enumeration
+--ro statistics
+--ro min? int64
+--ro max? int64
+--ro mean? int64
+--ro median? int64
+--ro stdev? uint64
+--ro sample-count? uint64
Figure 4: transducer sub-tree (type, quantity and statistics)
The transducers sub-tree contains the list of transducers (i.e.,
sensors and actuators) maintained by the device, listed in
"/bootstrap/inventory". A transducer is identified by its "type",
the same identityref used in the "/bootstrap/inventory" entry.
This branch holds two kinds of information: "quantity" carries the
values manipulated by the transducer, while "notification-parameters"
configures notifications through which the device can proactively
inform the client.
Quantity contains:
* "value": the raw integer value, computed as value = measurement *
10^precision,
* "timestamp": the relative time of the measurement, in seconds,
* the entity in charge of the timestamp, which can be the device
itself or the receiver.
"statistics" is a sibling of "quantity" and holds the main statistics
locally computed for a specific transducer, accumulated over a window
of samples rather than tied to the current measurement. Statistics
can be reset for a single transducer via the "reset-stats" action, or
for all transducers at once via the "reset-stats" RPC.
Toutain Expires 20 March 2027 [Page 12]
Internet-Draft coreconf-m2m September 2026
module: coreconf-m2m
+--rw transducers
+--rw transducer* [type]
+--rw notification-parameters
+--rw history
| +--ro active? boolean
| +--rw step? uint32
| +--rw precision? uint8
| +--rw max-samples? uint32
| +--rw time-period? uint32
| +--rw encoding? encoding-type
| +--rw max-payload? uint32
+--rw sensor-alert
| +--ro active? boolean
| +--rw t-min? int32
| +--rw t-max? int32
| +--rw hysteresis? uint8
| +--rw dampening? uint32
+--rw check-interval? uint16
Figure 5: notification-parameters sub-tree
Notification Parameters supports two kinds of notifications:
* "sensor-alert" will send a notification when the measured quantity
reaches one or two limits, minimal and maximal, or goes back to a
value between these two bounds. To avoid fluctuations, two
mechanisms are in place:
- "hysteresis" defines a percentage, by default 5% around the
limit, so if a maximum limit is set to 100, an alert message
will be triggered when the quantity is higher than 105 and
another alert will be sent when the quantity becomes lower than
95%. The value is sent in the notification message, so the
client is able to know the state of the alert.
- "dampening" limits the number of messages sent. When a
crossing is suppressed because of dampening, the notification
eventually sent MUST carry a None value, so the client can
distinguish a dampened event from an actual measured value.
* "history" builds time series:
- "step" parameter defines at which interval samples are taken.
- "precision" allows overriding the quantity precision defined in
the transducer. By default the precision is the one associated
with the transducer for "quantity".
Toutain Expires 20 March 2027 [Page 13]
Internet-Draft coreconf-m2m September 2026
- "encoding" indicates how information is stored in the time
series:
o "direct": all the values are stored with the precision.
o "delta": the first value is the reference and the following
ones are the difference with the previous. This allows
limiting the size of the message since CBOR encodes small
numbers more efficiently.
- A notification is sent when a number of measurements is
reached, either:
o the number of samples in the time series reaches "max-
samples",
o "max-payload" is based on the size of the time series.
Since small numbers take less space than large numbers in
CBOR, a time series may contain a different number of
samples.
o the "time-period" after which the collection should be sent.
* "check-interval" controls how often a CON (confirmable)
notification is sent instead of NON (non-confirmable), for both
the history and sensor-alert streams of this transducer: 0
(default) disables it, so all notifications are NON; 1 makes every
notification CON; N sends one CON every N notifications, all
others being NON.
The read-only active flag in both notification types is set when one
or more clients observe a notification. Parameters are common to all
observations of a particular transducer.
3.3. Notifications
As seen in the previous section, each transducer has a "notification-
parameters" branch holding its notification settings. A client MAY
FETCH this branch to retrieve its content and check the current
status of the notification (e.g., the "active" flag).
A client wishing to start a notification MAY first send an iPATCH to
configure its parameters. Parameters changed while a notification is
already active take effect immediately. These parameters are global
to the transducer: a modification impacts every notification
currently active for that transducer, regardless of which client
configured it.
Toutain Expires 20 March 2027 [Page 14]
Internet-Draft coreconf-m2m September 2026
Notification is started by sending a FETCH+Observe request on the
notification stream resource (/s), with a body identifying the SID of
the transducer to observe. Multiple clients may observe the same
transducer simultaneously; each receives an independent copy of every
notification.
The notification ends when either:
* the client explicitly sends a termination message (a GET/FETCH
with the Observe option set to 1, i.e. deregister, using the same
token as the original observation), or
* the client sends a RST in response to a notification, or
* the server sends Confirmable notifications and does not receive an
acknowledgment, or
* an ICMPv6 unreachable message is received by the server in
response to the IPv6/UDP/CoAP packet carrying the notification's
token.
4. CORECONF Overview in the M2M Context
4.1. CoAP Methods Mapping
CORECONF defines mappings for all CoAP methods, but this document
uses only two:
* FETCH is used instead of GET to retrieve values from the YANG Data
Model. Unlike GET, FETCH carries a body specifying the exact SIDs
to retrieve, enabling precise and bandwidth-efficient queries.
Combined with the CoAP Observe option, FETCH also serves to
subscribe to notification streams.
* iPATCH is used instead of PUT or POST to modify quantities and
notification parameters. It supports partial updates: only the
specified nodes are modified, leaving others unchanged, following
the merge semantics of [RFC7396]. Setting a node to an empty
value with iPATCH is the preferred way to clear a parameter,
making DELETE unnecessary for datastore modifications.
The recommended CoAP Content-Format for all exchanges is Content-
Format 140 (application/yang-data+cbor;id=sid [RFC9254]), used
uniformly for FETCH request bodies (which carry the list of SIDs to
retrieve), response bodies, and iPATCH payloads, where data nodes are
identified by their SID.
Toutain Expires 20 March 2027 [Page 15]
Internet-Draft coreconf-m2m September 2026
Using a single content format ensures maximum interoperability with
CORECONF implementations and keeps the payloads as compact as
possible. Limiting exchanges to a single well-known packet format
also benefits SCHC compression [RFC8724]: the fewer distinct header
patterns in use, the more efficiently SCHC rules can compress the
CoAP headers, reducing overhead on the most constrained links.
FETCH and iPATCH requests MUST be sent as Non-Confirmable (NON) CoAP
messages. This leaves the application free to implement its own
retransmission strategy and timer management, which is essential on
constrained networks where the default CoAP confirmable
retransmission behavior may be inappropriate or wasteful.
For notification streams (Observe), Confirmable (CON) messages MAY be
used. A CON notification allows the server to detect that the
observer is no longer reachable when no ACK is received, and to
cancel the Observe subscription accordingly. A RST response from the
client is also a valid way to signal that the subscription should be
terminated.
4.2. SID Allocations
The coreconf-m2m model is intended to be assigned in the IETF
experimental SID space, with a model entry point of 62000.
Appendix C gives the complete SID mapping for this model.
The atmos module, however, cannot be assigned SIDs in the IETF or
another SDO space, unless this commercial module is itself
standardized. For commercial modules, we assume that a registrar
allocates SIDs and implements the constraints defined in
[I-D.ietf-core-comi]. In this example, we assume that the registrar
owns a 10 million SID mega-range. Appendix D gives the atmos.yang
model, and Appendix E gives the corresponding SID mapping, composed
of the identities representing the transducers.
5. CORECONF Traffic
This section illustrates different traffic patterns used in coreconf-
m2m.
5.1. Resource Discovery
The client does not know the transducers managed by the device. It
sends a FETCH on "/bootstrap" (SID 62002) as shown in Figure 6.
Toutain Expires 20 March 2027 [Page 16]
Internet-Draft coreconf-m2m September 2026
CoAP Request:
Non-Confirmable, FETCH, MID:39919
Token: 2aaf
Opt #1: Uri-Path: c
Opt #2: Content-Format: 140 (application/yang-data+cbor;id=sid)
Opt #3: Accept: 140 (application/yang-data+cbor;id=sid)
Payload: 3 bytes
19 F2 32 # unsigned(62002) : /bootstrap
CoAP Response:
Non-Confirmable, 2.05 Content, MID:57745
Token: 2aaf
Opt #1: Content-Format: 140 (application/yang-data+cbor;id=sid)
Payload: 118 bytes
{62002:
{7: 1788334280, 8: 30172, 6: 120,
1: [{3: 10000010}, {3: 10000008}, {3: 10000011}, {3: 10000002},
{3: 10000014}, {3: 10000016}, {3: 10000015}, {3: 10000012},
{3: 10000001}, {3: 10000013}, {3: 10000003}, {3: 10000009},
{3: 10000006}, {3: 10000004}]}}
Figure 6: Resource discovery: FETCH request and response (SCHC
Rule 0)
In the request, the payload 19 F2 32 is the CBOR encoding of the
unsigned integer 62002, which is the SID of "/bootstrap". In the
response, the outer key 62002 identifies the bootstrap branch, and
the inner keys are delta SIDs relative to 62002, as defined in
[RFC9254]: 7 (reference-epoch), 8 (uptime), 6 (minimal-step), and 1
(the "inventory" list). Each entry in the inventory list is itself a
map whose key 3 is a delta SID relative to the list SID (62003), i.e.
"type", carrying the identity SID of one transducer known to the
device; no override is present here, meaning every transducer uses
the default-unit, default-precision and default-category declared on
its identity.
The client MUST have access to the corresponding YANG files to
discover the transducers' default parameters, indicating the unit,
the precision and the nature of the transducer.
Toutain Expires 20 March 2027 [Page 17]
Internet-Draft coreconf-m2m September 2026
coreconf-m2m:bootstrap
reference-epoch 1788334280 (2026-09-02 09:31:20) ← origin of every timestamp in the model
uptime 30172 s
minimal-step 120 s ← floor for history/step
coreconf-m2m:bootstrap/inventory — SID → module → YANG defaults resolution
SID Identity Module Unit Prec. Category
────────────────────────────────────────────────────────────────────────────────────────────
10000010 atmos:solar-radiation atmos W/m2 0 sensor
10000008 atmos:precipitation atmos mm 3 sensor
10000011 atmos:strike-count atmos count 0 sensor
10000002 atmos:average-distance atmos km 0 sensor
10000014 atmos:wind-direction atmos deg 0 sensor
10000016 atmos:wind-speed atmos m/s 2 sensor
10000015 atmos:wind-gust atmos m/s 2 sensor
10000012 atmos:tilt atmos deg 1 sensor
10000001 atmos:air-temperature atmos Cel 1 sensor
10000013 atmos:vapor-pressure atmos kPa 2 sensor
10000003 atmos:barometric-pressure atmos kPa 2 sensor
10000009 atmos:relative-humidity atmos %RH 1 sensor
10000006 atmos:humidity-sensor-temperature atmos Cel 1 sensor
10000004 atmos:compass-heading atmos deg 0 sensor
────────────────────────────────────────────────────────────────────────────────────────────
* override sent by the device; without a star, default value read from the YANG module.
The inventory completed this way stays local: bootstrap is config false and is never sent back.
Connected. 14 sensor(s) discovered, minimal step 120 s.
# Type Unit Prec. Filter
──────────────────────────────────────────────────────────────────────────────
1 solar-radiation W/m2 0 [type='atmos:solar-radiation']
2 precipitation mm 3 [type='atmos:precipitation']
3 strike-count count 0 [type='atmos:strike-count']
4 average-distance km 0 [type='atmos:average-distance']
5 wind-direction deg 0 [type='atmos:wind-direction']
6 wind-speed m/s 2 [type='atmos:wind-speed']
7 wind-gust m/s 2 [type='atmos:wind-gust']
8 tilt deg 1 [type='atmos:tilt']
9 air-temperature Cel 1 [type='atmos:air-temperature']
10 vapor-pressure kPa 2 [type='atmos:vapor-pressure']
11 barometric-pressure kPa 2 [type='atmos:barometric-pressure']
12 relative-humidity %RH 1 [type='atmos:relative-humidity']
13 humidity-sensor-temperature Cel 1 [type='atmos:humidity-sensor-temperature']
14 compass-heading deg 0 [type='atmos:compass-heading']
Figure 7: Decoded transducer inventory from resource discovery
response
Toutain Expires 20 March 2027 [Page 18]
Internet-Draft coreconf-m2m September 2026
5.2. Querying a quantity
A specific quantity may be requested through a FETCH. Figure 8 shows
the exchange for the current value of air-temperature.
CoAP Request:
Non-Confirmable, FETCH, MID:12229
Token: 2dae
Opt #1: Uri-Path: c
Opt #2: Content-Format: 140 (application/yang-data+cbor;id=sid)
Opt #3: Accept: 140 (application/yang-data+cbor;id=sid)
Payload: 9 bytes
[62077, 10000001]
CoAP Response:
Non-Confirmable, 2.05 Content, MID:57779
Token: 2dae
Opt #1: Content-Format: 140 (application/yang-data+cbor;id=sid)
Payload: 6 bytes
{62077: 196}
Figure 8: FETCH request and response for air-temperature current
value (SCHC Rule 0)
The FETCH body [62077, 10000001] is a CORECONF instance-identifier:
the first element (62077) is the SID of
"/transducers/transducer/quantity/value", followed by the list key
value identifying the transducer (type=10000001, i.e. atmos:air-
temperature). The response carries only that leaf: the value 196,
combined with the precision=1 declared on the air-temperature
identity, decodes to 19.6°C. Fetching the "value" leaf directly,
rather than the whole "quantity" sub-tree, avoids returning timestamp
and timestamp-source when only the current reading is needed.
Figure 9 shows the FETCH for the full statistics table of the same
transducer:
Toutain Expires 20 March 2027 [Page 19]
Internet-Draft coreconf-m2m September 2026
CoAP Request:
Non-Confirmable, FETCH, MID:18878
Token: 5420
Opt #1: Uri-Path: c
Opt #2: Content-Format: 140 (application/yang-data+cbor;id=sid)
Opt #3: Accept: 140 (application/yang-data+cbor;id=sid)
Payload: 9 bytes
[62081, 10000001]
CoAP Response:
Non-Confirmable, 2.05 Content, MID:32290
Token: 5420
Opt #1: Content-Format: 140 (application/yang-data+cbor;id=sid)
Payload: 21 bytes
{62081: {4: 196, 1: 217, 2: 203, 3: 202, 6: 7, 5: 8}}
Figure 9: FETCH request and response for air-temperature
statistics (SCHC Rule 0)
The FETCH body [62081, 10000001] requests the statistics sub-tree
(SID 62081) for air-temperature (10000001). In the response, the
inner map keys are delta SIDs relative to 62081, each encoding the
difference between consecutive SIDs to minimize CBOR size. The six
values correspond to the statistics leaves: min (196), max (217),
mean (203), median (202), stdev (7), and sample-count (8), all scaled
by the transducer precision except sample-count.
The client decodes the response and displays the statistics as shown
in Figure 10:
[9] Statistics — air-temperature:
min: 19.6 Cel
max: 21.7 Cel
mean: 20.3 Cel
median: 20.2 Cel
σ: 0.7 Cel
n: 8
Figure 10: Decoded statistics for air-temperature
5.3. Notification
The client first sends an iPATCH to configure the history
notification parameters for the air-temperature transducer, as shown
in Figure 11.
Toutain Expires 20 March 2027 [Page 20]
Internet-Draft coreconf-m2m September 2026
CoAP Request:
Non-Confirmable, iPATCH, MID:42310
Token: 248e
Opt #1: Uri-Path: c
Opt #2: Content-Format: 140 (application/yang-data+cbor;id=sid)
Payload: 22 bytes
{[62060, 10000001]: {62060: {6: 120, 4: 10, 2: 1}}}
CoAP Response:
Non-Confirmable, 2.04 Changed, MID:65147
Token: 248e
Figure 11: iPATCH to configure history notification parameters
for air- temperature (SCHC Rule 1)
The iPATCH key [62060, 10000001] is an instance-identifier targeting
the notification-parameters/history node (SID 62060) for air-
temperature (type 10000001). The value {62060: {6: 120, 4: 10, 2:
1}} sets three history parameters using delta SIDs relative to 62060:
step=120 s, max-samples=10, and encoding=delta (value 1).
An iPATCH is used the same way to configure a sensor-alert: the
client sets the low and high thresholds, and activates the alert, as
shown in Figure 12.
CoAP Request:
Non-Confirmable, iPATCH, MID:42312
Token: 2490
Opt #1: Uri-Path: c
Opt #2: Content-Format: 140 (application/yang-data+cbor;id=sid)
Payload: 24 bytes
{[62068, 10000001]: {62068: {1: true, 4: 350, 5: 50}}}
CoAP Response:
Non-Confirmable, 2.04 Changed, MID:65150
Token: 2490
Figure 12: iPATCH to configure sensor-alert thresholds for air-
temperature (SCHC Rule 1)
Toutain Expires 20 March 2027 [Page 21]
Internet-Draft coreconf-m2m September 2026
The iPATCH key [62068, 10000001] targets the notification-parameters/
sensor-alert node (SID 62068) for air-temperature. The value {62068:
{1: true, 4: 350, 5: 50}} sets three leaves using delta SIDs relative
to 62068: active=true (delta 1), t-max=350 (delta 4), and t-min=50
(delta 5). Since air-temperature has precision=1 (as in Figure 8),
these raw integers represent 35.0 Cel and 5.0 Cel: the device raises
an alert once the temperature leaves that range.
The client then initiates an Observe subscription with a FETCH on the
notification stream resource /s, as shown in Figure 13.
CoAP Request:
Non-Confirmable, FETCH, MID:42311
Token: 248f
Opt #1: Observe: 0
Opt #2: Uri-Path: s
Opt #3: Content-Format: 140 (application/yang-data+cbor;id=sid)
Opt #4: Accept: 140 (application/yang-data+cbor;id=sid)
Payload: 9 bytes
[62048, 10000001]
CoAP Response (subscription acknowledgment):
Non-Confirmable, 2.05 Content, MID:65148
Token: 248f
Opt #1: Observe: 0
Opt #2: Content-Format: 140 (application/yang-data+cbor;id=sid)
Payload: 1 byte
{}
CoAP Notification:
Non-Confirmable, 2.05 Content, MID:65149
Token: 248f
Opt #1: Observe: 1
Opt #2: Content-Format: 140 (application/yang-data+cbor;id=sid)
Payload: 16 bytes
{62048: [189, 14, -3, 1, 5, 7, 3, 2, 1, 2]}
Figure 13: FETCH+Observe subscription on `/s` and history
notification for air- temperature (SCHC Rule 2)
The FETCH body [62048, 10000001] subscribes directly to the time-
series "values" leaf-list (SID 62048) for air-temperature, rather
than the whole time-series entry: since the subscription is already
transducer-specific, echoing the "type" back in every notification
would only repeat what the client already knows. The server
Toutain Expires 20 March 2027 [Page 22]
Internet-Draft coreconf-m2m September 2026
acknowledges with an empty map {}. The notification then carries the
values list under its absolute SID, [189, 14, -3, 1, 5, 7, 3, 2, 1,
2], using delta encoding: 189 is the absolute reference (18.9°C,
precision=1), and each subsequent value is the difference from the
previous one.
The client decodes the delta-encoded time-series values and displays
the result as shown in Figure 14:
[9] air-temperature: 18.9 Cel (09:57:42)
[9] air-temperature: 20.3 Cel (09:59:42)
[9] air-temperature: 20.0 Cel (10:01:42)
[9] air-temperature: 20.1 Cel (10:03:42)
[9] air-temperature: 20.6 Cel (10:05:42)
[9] air-temperature: 21.3 Cel (10:07:42)
[9] air-temperature: 21.6 Cel (10:09:42)
[9] air-temperature: 21.8 Cel (10:11:42)
[9] air-temperature: 21.9 Cel (10:13:42)
[9] air-temperature: 22.1 Cel (10:15:42)
Figure 14: Decoded air-temperature time-series from history
notification
The whole batch of samples is decoded from a single notification
message. Since the device timestamp is not carried in this payload,
the client reconstructs one from the configured "step" (120 s): the
last sample is stamped with the local time at which the notification
was received, and earlier samples are stepped back by 120 s each,
oldest first.
6. From CBOR/SID to Textual Identifiers
The examples throughout this document use CBOR payloads keyed by SIDs
(application/yang-data+cbor;id=sid), which is the compact
representation intended for constrained links. Ontologies generally
use a textual representation, and interacting with a human user
likewise requires presenting the information with understandable
identifiers (see the example in Figure 7).
To perform this translation, the recipient of a coreconf-m2m message
needs access to the .sid file and, in some cases, the YANG file, in
order to recover the transducers' default values.
[I-D.toutain-core-sid-encoding] defines a way to use DNS to locate a
SID and a YANG file.
An experimental service running with the "sid.yt" suffix has been
deployed. It allows finding the SID and YANG files associated with a
specific SID.
Toutain Expires 20 March 2027 [Page 23]
Internet-Draft coreconf-m2m September 2026
7. Interconnection with an Ontology
The goal of coreconf-m2m is to discover the resources managed by the
device and to provide a lightweight transport for information coming
from a sensor or dedicated to an actuator; it is not itself an
ontology. This section discusses how the elements it carries relate
to some existing ontologies and APIs, so that a gateway or
application can align them with a richer semantic model when needed,
once translated to textual identifiers as described in Section 6.
7.1. Extending Ontology to coreconf-m2m
Before looking at how YANG information can be included into an
existing ontology, it may also be important to enrich the ontology
with coreconf-m2m information concerning the device's CORECONF
capabilities; this may be helpful for future interactions with the
device.
This document therefore assumes a small ccm2m: extension vocabulary,
applicable regardless of which ontology (SOSA, SAREF, SensorThings,
...) a device or transducer is otherwise mapped to. Appendix F gives
its full definition, as an OWL ontology in Turtle.
The ccm2m ontology defines a single datatype, ccm2m:SID: a non-
negative integer that uniquely identifies a YANG node, identity, or
feature within a SID file, used instead of a plain
xsd:nonNegativeInteger so that the nature of the value is self-
documenting.
It defines properties attached to a sosa:Platform, giving the
coordinates needed to reach and query the device:
* ccm2m:coapEndpoint is the CoAP access address of the device (e.g.
coap://[::1]);
* ccm2m:accessProtocol is the default applicative protocol used on
that platform (e.g. "coreconf");
* ccm2m:bootstrapSid is the SID used at bootstrap to discover the
YANG model exposed by the platform (see Section 5.1); it is multi-
valued, since several bootstrap SIDs are possible.
It also defines properties attached to a sosa:Sensor, tying it back
to its YANG identity:
* ccm2m:type carries the transducer's identity SID (see Figure 7);
Toutain Expires 20 March 2027 [Page 24]
Internet-Draft coreconf-m2m September 2026
* ccm2m:id is the instance identifier of the sensor on its platform,
distinguishing multiple sensors of the same type;
* ccm2m:precision and ccm2m:outputUnit carry the default-precision
and default-unit declared on that identity, or their overrides
(see Section 3.2.3), and are declared once rather than repeated on
every observation.
Finally, it models the applicative operations that can be performed
on a device or transducer, i.e. its CORECONF capabilities,
deliberately kept outside SOSA/SSN's Sampling/Sensing semantics:
* ccm2m:Control is an applicative operation exposed over CORECONF/
CoAP (a single-value read, a history-buffer notification
subscription, or a threshold-alert notification subscription),
linked to a Platform or Sensor via ccm2m:hasControl. Its
ccm2m:controlType names the operation (e.g. "read-single",
"subscribe-history", "reset-all-stat"), ccm2m:targetSid gives the
SID of the YANG leaf/container it targets, and ccm2m:coapMethod,
ccm2m:coapPath, and ccm2m:contentFormat describe how to invoke it
over CoAP;
* ccm2m:SetupNotification is a Control that configures notification
parameters on a transducer before subscribing (an iPATCH on /c);
its ccm2m:hasParam links to one or more ccm2m:NotificationParam,
each giving, via ccm2m:paramName and ccm2m:paramSid, the YANG leaf
name and SID of one configurable parameter (e.g. "step",
"encoding"; see Figure 5).
Without these properties, a graph would describe what a platform
observes, but not how to obtain the corresponding coreconf-m2m data,
nor how to act on it. The following subsections use this ccm2m:
vocabulary to bridge the elements of coreconf-m2m to specific
ontologies.
7.2. SOSA
The Sensor, Observation, Sample, and Actuator (SOSA) ontology is
maintained jointly by the W3C and the Open Geospatial Consortium
(OGC), as part of the broader SSN (Semantic Sensor Network) ontology
[SOSA]. It defines a sosa:Platform as an entity that hosts other
objects, such as sensors, actuators, or samplers. The device
described by the "characteristics" sub-tree (Section 3.2.2) maps to a
sosa:Platform, and each of its transducers maps to a sosa:Sensor or a
sosa:Actuator hosted by that platform.
Toutain Expires 20 March 2027 [Page 25]
Internet-Draft coreconf-m2m September 2026
SOSA also defines a sosa:Sampler type, but it corresponds more to
sample-taking than to measurement, so it may be present in the
ontology without requiring a link with the coreconf-m2m YANG data
model.
Figure 15 shows a generic, abstract example of such a platform,
expressed in the Turtle RDF syntax, independently of any particular
naming scheme.
@prefix sosa: .
a sosa:Platform ;
sosa:hosts