Thing-to-Thing Research Group (T2TRG) L. Toutain Internet-Draft IMT Atlantique Intended status: Informational 4 June 2026 Expires: 6 December 2026 CORECONF for Machine-to-Machine Communication draft-toutain-t2trg-coreconf-m2m-00 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 6 December 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Toutain Expires 6 December 2026 [Page 1] Internet-Draft coreconf-m2m June 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Data Representation . . . . . . . . . . . . . . . . . . . 4 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. The coreconf-m2m YANG Module . . . . . . . . . . . . . . . . 6 3.1. Module Overview . . . . . . . . . . . . . . . . . . . . . 6 3.2. State and Characteristics Sub-Tree . . . . . . . . . . . 8 3.3. transducer sub-tree . . . . . . . . . . . . . . . . . . . 8 3.3.1. quantity . . . . . . . . . . . . . . . . . . . . . . 9 3.3.2. Notification Parameters . . . . . . . . . . . . . . . 9 3.4. Starting Notifications . . . . . . . . . . . . . . . . . 10 4. CORECONF Overview in the M2M Context . . . . . . . . . . . . 11 4.1. CoAP Methods Mapping . . . . . . . . . . . . . . . . . . 11 5. CORECONF Traffic . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Resource Discovery . . . . . . . . . . . . . . . . . . . 12 5.2. Querying a quantity . . . . . . . . . . . . . . . . . . . 14 5.3. Notification . . . . . . . . . . . . . . . . . . . . . . 16 6. SID Allocation . . . . . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8.1. YANG Module Registration . . . . . . . . . . . . . . . . 18 8.2. SID Range Allocation . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 20 Appendix A. Complete YANG Module . . . . . . . . . . . . . . . . 22 Appendix B. SID File (CSV) . . . . . . . . . . . . . . . . . . . 32 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 34 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 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 further be used to reduce the overhead of IPv6, UDP, and CoAP headers Toutain Expires 6 December 2026 [Page 2] Internet-Draft coreconf-m2m June 2026 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. 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. This document focuses on transducer management: resource Toutain Expires 6 December 2026 [Page 3] Internet-Draft coreconf-m2m June 2026 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. 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) 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 3 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. Toutain Expires 6 December 2026 [Page 4] Internet-Draft coreconf-m2m June 2026 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. 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. Toutain Expires 6 December 2026 [Page 5] Internet-Draft coreconf-m2m June 2026 Quantity: values manipulated by transducers. Value: other information stored in the datastore including quantities 3. The coreconf-m2m YANG Module The device acts as a CoAP server implementing CORECONF and exposes its state through a set of Transducers. A Transducer represents either a sensor (providing measurements) or an actuator (accepting commands). Each Transducer type is identified by a YANG identity. When multiple Transducers of the same type are present on the device, they are distinguished by an instance identifier. 3.1. Module Overview For simplicity reasons, we regroup in a single YANG module two elements. The first element is a set of Transducer identities, which in a real deployment would typically reside in a separate device- specific module. In this example, 12 transducers are defined, corresponding to the weather station ATMOS41 (see https://metergroup.com/fr/products/atmos-41/). The second element defines the data structures: * a container including a device description and a list of associated transducers. Each transducer is identified by an identityref and an instance number, allowing several transducers of the same type. Each transducer contains: - a quantity measured from the field or set by the client. - a list of statistics (mean, variance, min, max), resettable via RPC. - alert parameters: threshold values (minimum and maximum) triggering a notification when the measured quantity crosses them. - time series parameters: collection settings controlling when a series of samples is sent (number of samples, duration, message size). * 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. Toutain Expires 6 December 2026 [Page 6] Internet-Draft coreconf-m2m June 2026 Figure 1 gives an overview of the module YANG tree: module: coreconf-m2m +--ro state | +--ro uptime? uint64 +--rw characteristics | +--rw name? string | +--rw version? string | +--rw identifier? string +--rw transducers +--rw transducer* [type id] +--rw type identityref +--rw id uint8 +--rw unit? string +--rw nature? transducer-nature +--rw precision? int8 +--ro quantity | +--ro value? int64 | +--ro timestamp? uint64 | +--ro u-timestamp? uint32 | +--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 +--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 +---x reset-stats rpcs: +---x reset-stats Toutain Expires 6 December 2026 [Page 7] Internet-Draft coreconf-m2m June 2026 notifications: +---n history | +--ro last? boolean | +--ro time-series* [type id] | +--ro type identityref | +--ro id uint8 | +--ro values* int64 | +--ro internal | +--ro last-update? uint64 | +--ro start-time? uint64 | +--ro messages-sent? uint64 +---n sensor-alert +--ro target* [type id] +--ro type identityref +--ro id uint8 +--ro value? int64 Figure 1: coreconf-m2m module tree 3.2. State and Characteristics Sub-Tree These two sub-trees contain global parameters generic to the device, such as uptime. They are still under development and their content is not yet fully defined. 3.3. transducer sub-tree Transducers sub-tree contains the list of transducers (i.e. sensors, actuators) maintained by the device. A transducer is identified by two elements: * a “type” identityref giving the nature of the transducer, * an “id” giving the instance number allowing several transducers of the same type. At this level, three other leaves are defined: * “unit” is a string giving the nature of the quantity. This value may be taken from SenML maintained by IANA. The use of a string, instead of identityref is intentional. Units are short names. YANG Identity may be larger and less flexible. * “nature” reveals if a transducer is a sensor, from which the quantity can be read, or an actuator where the quantity can be written. Toutain Expires 6 December 2026 [Page 8] Internet-Draft coreconf-m2m June 2026 * “precision”: is the number of digits after the decimal point. Quantity values are integers multiplied by 10^precision. It can be noted that precision can also be negative for very large values. These five leaves form the first level of the transducers tree. The recommended approach is to query with depth=0, which returns only the transducer list with its identifying leaves (type, id, unit, nature, precision). This lightweight exchange is sufficient for resource discovery and minimizes traffic on constrained networks. A query with depth=1 is also possible and returns transducers together with their associated quantity values in a single message. However, the response may be significantly larger, as it includes timestamp and statistics data that the client may not need. On low- power links, it is therefore preferable to perform discovery and value retrieval as two separate queries. 3.3.1. quantity The “quantity” sub-tree pushes the leaves to a deeper level, to avoid being retrieved during the resource discovery phase. Quantity contains: * the value adjusted with the precision to be an integer, * the timestamp in seconds and microseconds, * the entity in charge of the timestamp, which can be the device itself or the receiver. Under “quantity”, the sub-level “statistics” includes major statistic for a specific transducer. Locally computed statistics. Statistics may be erased for each transducer by calling the “reset-stats” action, or globally for all transducers with the “reset-stats” RPC. 3.3.2. Notification Parameters The model 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 Toutain Expires 6 December 2026 [Page 9] Internet-Draft coreconf-m2m June 2026 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. * “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. - “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. 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.4. Starting Notifications A client wishing to initiate a notification MAY first send an iPATCH to set up notification parameters. Parameters set during an active notification are immedialty applied. Toutain Expires 6 December 2026 [Page 10] Internet-Draft coreconf-m2m June 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. 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. 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-Formats for all exchanges are: * Content-Format 141 (application/yang-fetch+cbor) for FETCH request bodies, which carry the list of SIDs to retrieve. * Content-Format 142 (application/yang-data+cbor;id=sid) for all response bodies and iPATCH payloads, where data nodes are identified by their SID. Using these two content formats ensures maximum interoperability with CORECONF implementations and keeps the payloads as compact as possible. Limiting exchanges to a small number of well-known packet formats 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. Toutain Expires 6 December 2026 [Page 11] Internet-Draft coreconf-m2m June 2026 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. 5. CORECONF Traffic The following examples show some CoAP messages between a client and a device (the CoAP server). In the example, the device is an ATMOS41 weather station, able to measure 12 parameters. An identity is associated with each parameter and a unique SID, as illustrated in Figure 2: identity solar-radiation { base transducer-type; description "Solar radiation measurement (W/m2)."; } identity precipitation { base transducer-type; description "Precipitation measurement (mm)."; } identity air-temperature { base transducer-type; description "Air temperature measurement (°C)."; } Figure 2: Excerpt of YANG identity definitions for the ATMOS41 transducers (see Appendix for the complete module) 5.1. Resource Discovery The client does not know the transducers managed by the device. It sends a FETCH on “/transducers/transducer” with a depth of 0, as shown in Figure 3. Toutain Expires 6 December 2026 [Page 12] Internet-Draft coreconf-m2m June 2026 CoAP Request: Non-Confirmable, FETCH, MID:47709 Token: 8ed4 Opt #1: Uri-Path: c Opt #2: Content-Format: 141 (application/yang-fetch+cbor) Opt #3: Uri-Query: d=0 Opt #4: Accept: 142 (application/yang-data+cbor;id=sid) Payload: 5 bytes 1A 000186DF # unsigned(100063) : /transducers/transducer CoAP Response: Non-Confirmable, 2.05 Content, MID:39441 Token: 8ed4 Opt #1: Content-Format: 142 (application/yang-data+cbor;id=sid) Payload: 220 bytes {100063: [{33: 100008, 1: 0, 17: 1, 34: "W/m2"}, {33: 100006, 1: 0, 17: 3, 34: "mm"}, {33: 100009, 1: 0, 17: 0, 34: ""}, {33: 100002, 1: 0, 17: 1, 34: "km"}, {33: 100013, 1: 0, 17: 1, 34: "deg"}, {33: 100015, 1: 0, 17: 2, 34: "m/s"}, {33: 100014, 1: 0, 17: 2, 34: "m/s"}, {33: 100010, 1: 0, 17: 1, 34: "deg"}, {33: 100001, 1: 0, 17: 1, 34: "degC"}, {33: 100012, 1: 0, 17: 3, 34: "kPa"}, {33: 100003, 1: 0, 17: 2, 34: "kPa"}, {33: 100007, 1: 0, 17: 1, 34: "%RH"}]} Figure 3: Resource discovery: FETCH request and response In the request, the payload 1A 000186DF is the CBOR encoding of the unsigned integer 100063, which is the SID of “/transducers/ transducer”. In the response, the outer key 100063 identifies the list, and each entry is a CBOR map whose keys are delta SIDs relative to the list SID, as defined in [RFC9254]. The values encode the transducer type (as an identity SID), instance id, precision, and unit string. The client may translate the identityref values to the names defined in the YANG module. Figure 4 shows the resulting transducer table: Toutain Expires 6 December 2026 [Page 13] Internet-Draft coreconf-m2m June 2026 1 solar-radiation W/m2 [type='solar-radiation'][id='0'] 2 precipitation mm [type='precipitation'][id='0'] 3 strike-count [type='strike-count'][id='0'] 4 average-distance km [type='average-distance'][id='0'] 5 wind-direction deg [type='wind-direction'][id='0'] 6 wind-speed m/s [type='wind-speed'][id='0'] 7 wind-gust m/s [type='wind-gust'][id='0'] 8 tilt deg [type='tilt'][id='0'] 9 air-temperature degC [type='air-temperature'][id='0'] 10 vapor-pressure kPa [type='vapor-pressure'][id='0'] 11 barometric-pressure kPa [type='barometric-pressure'][id='0'] 12 relative-humidity %RH [type='relative-humidity'][id='0'] Figure 4: Decoded transducer list from resource discovery response 5.2. Querying a quantity A specific quantity may be requested through a FETCH. Figure 5 shows the exchange for the current value of air-temperature. CoAP Request: Non-Confirmable, FETCH, MID:47710 Token: 8ed5 Opt #1: Uri-Path: c Opt #2: Content-Format: 141 (application/yang-fetch+cbor) Opt #3: Accept: 142 (application/yang-data+cbor;id=sid) Payload: 12 bytes [100092, 100001, 0] CoAP Response: Non-Confirmable, 2.05 Content, MID:39442 Token: 8ed5 Opt #1: Content-Format: 142 (application/yang-data+cbor;id=sid) Payload: 8 bytes {100092: 112} Figure 5: FETCH request and response for air-temperature current value The FETCH body [100092, 100001, 0] is a CORECONF instance-identifier: the first element is the SID of the requested leaf, followed by the list key values identifying the transducer (type=100001 for air- temperature, id=0). The response value 112, combined with precision=1, decodes to 11.2°C. Toutain Expires 6 December 2026 [Page 14] Internet-Draft coreconf-m2m June 2026 Figure 6 shows the FETCH for the full statistics table of the same transducer: CoAP Request: Non-Confirmable, FETCH, MID:47711 Token: 8ed6 Opt #1: Uri-Path: c Opt #2: Content-Format: 141 (application/yang-fetch+cbor) Opt #3: Accept: 142 (application/yang-data+cbor;id=sid) Payload: 12 bytes [100082, 100001, 0] CoAP Response: Non-Confirmable, 2.05 Content, MID:39443 Token: 8ed6 Opt #1: Content-Format: 142 (application/yang-data+cbor;id=sid) Payload: 24 bytes {100082: {4: 79, 1: 119, 2: 94, 3: 103, 6: 12, 5: 53}} Figure 6: FETCH request and response for air-temperature statistics The FETCH body [100082, 100001, 0] requests the quantity sub-tree (SID 100082) for air-temperature (100001), instance 0. In the response, the inner map keys are delta SIDs relative to 100082, each encoding the difference between consecutive SIDs to minimize CBOR size. The six values correspond to the statistics leaves: min, max, mean, median, stdev, and sample-count, all scaled by the transducer precision. The client decodes the response and displays the statistics as shown in Figure 7: [9] Statistics — air-temperature: min: 7.9 degC max: 11.9 degC mean: 9.4 degC median: 10.3 degC σ: 1.2 degC n: 53 Figure 7: Decoded statistics for air-temperature Toutain Expires 6 December 2026 [Page 15] Internet-Draft coreconf-m2m June 2026 5.3. Notification The client first sends an iPATCH to configure the history notification parameters for the solar-radiation transducer, as shown in Figure 8. CoAP Request: Non-Confirmable, iPATCH, MID:47712 Token: 8ed7 Opt #1: Uri-Path: c Opt #2: Content-Format: 142 (application/yang-data+cbor;id=sid) Payload: 28 bytes {[100066, 100008, 0]: {100066: {6: 5000, 4: 3, 2: 1}}} CoAP Response: Non-Confirmable, 2.04 Changed, MID:39444 Token: 8ed7 Figure 8: iPATCH to configure history notification parameters for solar- radiation The iPATCH key [100066, 100008, 0] is an instance-identifier targeting the notification-parameters node (SID 100066) for solar- radiation (SID 100008), instance 0. The value {100066: {6: 5000, 4: 3, 2: 1}} sets three history parameters using delta SIDs relative to 100066: step=5000 ms (one sample every 5 seconds), max-samples=3, and encoding=delta (value 1). The client then initiates an Observe subscription with a FETCH on the notification stream resource /s, as shown in Figure 9. Toutain Expires 6 December 2026 [Page 16] Internet-Draft coreconf-m2m June 2026 CoAP Request: Non-Confirmable, FETCH, MID:47713 Token: 8ed8 Opt #1: Observe: 0 Opt #2: Uri-Path: s Opt #3: Content-Format: 141 (application/yang-fetch+cbor) Opt #4: Accept: 142 (application/yang-data+cbor;id=sid) Payload: 12 bytes [100044, 100008, 0] CoAP Response (subscription acknowledgment): Non-Confirmable, 2.05 Content, MID:39445 Token: 8ed8 Opt #1: Observe: 0 Opt #2: Content-Format: 142 (application/yang-data+cbor;id=sid) Payload: 1 byte {} CoAP Notification: Non-Confirmable, 2.05 Content, MID:39446 Token: 8ed8 Opt #1: Observe: 1 Opt #2: Content-Format: 142 (application/yang-data+cbor;id=sid) Payload: 43 bytes {100042: {2: [{6: 100008, 1: 0, 7: [1043, 82, 82, 362, 316, 318, 226, 94, -147, -16]}]}} Figure 9: FETCH+Observe subscription on `/s` and history notification for solar-radiation The FETCH body [100044, 100008, 0] subscribes to the history time- series stream (SID 100044) for solar-radiation. The server acknowledges with an empty map {}. In the notification, the outer key 100042 identifies the history notification; the inner structure uses delta SIDs to encode type, id, and the values list. The values [1043, 82, 82, ...] use delta encoding: 1043 is the absolute reference (104.3 W/m²), and each subsequent value is the difference from the previous one, yielding a compact representation of slowly- varying measurements. The client decodes the delta-encoded time-series values and displays the result as shown in Figure 10: Toutain Expires 6 December 2026 [Page 17] Internet-Draft coreconf-m2m June 2026 [1] solar-radiation: 104.3 W/m2 (16:50:29) [1] solar-radiation: 112.5 W/m2 (16:52:29) [1] solar-radiation: 120.7 W/m2 (16:54:29) [1] solar-radiation: 156.9 W/m2 (16:56:29) [1] solar-radiation: 188.5 W/m2 (16:58:29) [1] solar-radiation: 220.3 W/m2 (17:00:29) [1] solar-radiation: 242.9 W/m2 (17:02:29) [1] solar-radiation: 252.3 W/m2 (17:04:29) [1] solar-radiation: 237.6 W/m2 (17:06:29) [1] solar-radiation: 236.0 W/m2 (17:08:29) Figure 10: Decoded solar-radiation time-series from history notification 6. SID Allocation The SID range 100000–100399 is used as an example throughout this document. Official values MUST be assigned by IANA prior to publication. The complete SID file is provided in Figure 12. 7. Security Considerations CORECONF operations over CoAP MUST be secured using either DTLS [RFC6347] or OSCORE [RFC8613]. In M2M scenarios where a central manager is absent, the trust model requires particular attention. 8. IANA Considerations 8.1. YANG Module Registration This document registers the following YANG module in the “YANG Module Names” registry [RFC7950]: +=========+=======================================+======+=========+ | Name | Namespace |Prefix|Reference| +=========+=======================================+======+=========+ |coreconf-| urn:ietf:params:xml:ns:yang:coreconf- | cm2m | This | | m2m | m2m | | document| +---------+---------------------------------------+------+---------+ Table 1 8.2. SID Range Allocation This document requests the SID range starting at entry-point TBD with a size of 100, as defined in [I-D.ietf-core-sid]. Toutain Expires 6 December 2026 [Page 18] Internet-Draft coreconf-m2m June 2026 Transducer identites MUST be sperated from this document and defined in anjother YANG module. 9. References 9.1. Normative References [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. Zuniga, "SCHC: Generic Framework for Static Context Header Compression and Fragmentation", RFC 8724, DOI 10.17487/RFC8724, April 2020, . [RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)", RFC 8824, DOI 10.17487/RFC8824, June 2021, . [RFC9254] Veillette, M., Ed., Petrov, I., Ed., Pelov, A., Bormann, C., and M. Richardson, "Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR)", RFC 9254, DOI 10.17487/RFC9254, July 2022, . [RFC9363] Minaburo, A. and L. Toutain, "A YANG Data Model for Static Context Header Compression (SCHC)", RFC 9363, DOI 10.17487/RFC9363, March 2023, . [I-D.ietf-core-comi] Veillette, M., Van der Stok, P., Pelov, A., Bierman, A., and C. Bormann, "CoAP Management Interface (CORECONF)", Toutain Expires 6 December 2026 [Page 19] Internet-Draft coreconf-m2m June 2026 Work in Progress, Internet-Draft, draft-ietf-core-comi-21, 2 March 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, . [RFC9179] Hopps, C., "A YANG Grouping for Geographic Locations", RFC 9179, DOI 10.17487/RFC9179, February 2022, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC7396] Hoffman, P. and J. Snell, "JSON Merge Patch", RFC 7396, DOI 10.17487/RFC7396, October 2014, . [RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. Bormann, "Sensor Measurement Lists (SenML)", RFC 8428, DOI 10.17487/RFC8428, August 2018, . [RFC9232] Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and A. Wang, "Network Telemetry Framework", RFC 9232, DOI 10.17487/RFC9232, May 2022, . [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Subscription to YANG Notifications", RFC 8639, DOI 10.17487/RFC8639, September 2019, . Toutain Expires 6 December 2026 [Page 20] Internet-Draft coreconf-m2m June 2026 [I-D.ietf-core-sid] Veillette, M., Pelov, A., Petrov, I., Bormann, C., and M. Richardson, "YANG Schema Item iDentifier (YANG SID)", Work in Progress, Internet-Draft, draft-ietf-core-sid-24, 22 December 2023, . [I-D.ietf-core-yang-cbor] Veillette, M., Petrov, I., Pelov, A., Bormann, C., and M. Richardson, "Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR)", Work in Progress, Internet-Draft, draft-ietf-core-yang-cbor-20, 11 April 2022, . [I-D.gudi-t2trg-senml-as-coreconf] G, M., Toutain, L., Fernandez, A., and J. BONNIN, "SenML is CORECONF (almost)", Work in Progress, Internet-Draft, draft-gudi-t2trg-senml-as-coreconf-00, 7 October 2024, . [I-D.birkholz-yang-core-telemetry] Birkholz, H. and E. Voit, "Concise YANG Telemetry", Work in Progress, Internet-Draft, draft-birkholz-yang-core- telemetry-01, 16 July 2018, . [OMA-LwM2M] "Lightweight Machine to Machine Technical Specification: Core", 2020, . [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, . Toutain Expires 6 December 2026 [Page 21] Internet-Draft coreconf-m2m June 2026 Appendix A. Complete YANG Module module coreconf-m2m { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:coreconf-m2m"; prefix m2m; import ietf-geo-location { prefix geo; reference "RFC 9179"; } organization "METER Group, Inc."; contact "Technical Support https://www.metergroup.com/"; description "YANG data model for a generic M2M CoMI weather station. This model defines the operational state data for sensor readings."; revision 2026-05-07 { description "Fix typedef naming conflict (transducer-type renamed to transducer-nature) and missing closing brace in enum unknown."; } revision 2026-03-29 { description "Move container statistics inside container quantity."; } revision 2026-03-25 { description "Add dampening leaf to sensor-alert notification parameters."; } revision 2026-03-23 { description "Make active leaf config false (reflects observe subscription state). Add must constraint t-min < t-max on sensor-alert. Add timestamp-source enum in quantity to indicate timestamp origin (source = timestamped by the sensor, receiver = timestamped on receipt)."; } revision 2026-03-22 { description "Rename branch measurement to transducer Toutain Expires 6 December 2026 [Page 22] Internet-Draft coreconf-m2m June 2026 (container, list, identity, notification)."; } revision 2026-03-08 { description "Module renamed to coreconf-m2m for generic M2M CoMI use."; } revision 2026-03-02 { description "Major update for CoMI compliance: - Added multi-sensor support (id key). - Measurements are now configurable (writable). - Added standard deviation (stdev). - Added uptime to state. - Removed tilt from fixed state (now a measurement type). - Removed legacy RPCs (subscribe, get-stats) in favor of CoMI/Observe. - Cleaned up measurement lists and notifications."; } revision 2026-02-27 { description "Initial revision for testing."; } identity transducer-type { description "Base identity for all measurement types."; } identity solar-radiation { base transducer-type; description "Solar radiation measurement (W/m2)."; } identity precipitation { base transducer-type; description "Precipitation measurement (mm)."; } identity air-temperature { base transducer-type; description "Air temperature measurement (°C)."; } identity relative-humidity { base transducer-type; description "Relative humidity measurement (%)."; Toutain Expires 6 December 2026 [Page 23] Internet-Draft coreconf-m2m June 2026 } identity barometric-pressure { base transducer-type; description "Barometric pressure measurement (kPa)."; } identity vapor-pressure { base transducer-type; description "Vapor pressure measurement (kPa)."; } identity wind-speed { base transducer-type; description "Horizontal wind speed measurement (m/s)."; } identity wind-direction { base transducer-type; description "Wind direction measurement (degrees)."; } identity wind-gust { base transducer-type; description "Wind gust measurement (m/s)."; } identity strike-count { base transducer-type; description "Lightning strike count."; } identity average-distance { base transducer-type; description "Average lightning distance (km)."; } identity tilt { base transducer-type; description "Sensor tilt measurement (degrees)."; } identity x-orientation { base transducer-type; description "X-axis orientation (raw accelerometer data)."; } identity y-orientation { Toutain Expires 6 December 2026 [Page 24] Internet-Draft coreconf-m2m June 2026 base transducer-type; description "Y-axis orientation (raw accelerometer data)."; } identity north-wind-speed { base transducer-type; description "North wind speed component (m/s)."; } identity east-wind-speed { base transducer-type; description "East wind speed component (m/s)."; } typedef encoding-type { type enumeration { enum direct { value 0; description "Value is encoded directly as an integer."; } enum delta { value 1; description "Value is encoded as a delta from the previous value."; } } description "Encoding used for the measurement values."; } typedef transducer-nature { type enumeration { enum sensor { value 0; description "Physical sensor; quantity can be read."; } enum actuator { value 1; description "Actuator; quantity can be written."; } enum sensor-actuator { value 2; description "Both sensor and actuator."; } enum internal { value 3; description "Internal operational parameter."; } enum unknown { value 255; Toutain Expires 6 December 2026 [Page 25] Internet-Draft coreconf-m2m June 2026 description "Unknown."; } } description "Nature of a transducer."; } grouping transducers-list { list time-series { key "type id"; description "List of measurements included in this notification."; leaf type { type identityref { base transducer-type; } description "The type of measurement."; } leaf id { type uint8; description "Instance identifier for this measurement type."; } leaf-list values { type int64; ordered-by user; description "List of encoded measurement values."; } } } container state { config false; description "Operational state data of the weather station."; leaf uptime { type uint64; units "seconds"; description "Time elapsed since the last boot."; } } container characteristics { description "Static descriptive information about the device."; leaf name { type string; description "Human-readable name of the device."; } leaf version { type string; description "Firmware or software version of the device."; Toutain Expires 6 December 2026 [Page 26] Internet-Draft coreconf-m2m June 2026 } leaf identifier { type string; description "Unique identifier of the device (e.g., serial number or EUI)."; } uses geo:geo-location { refine "geo-location/reference-frame/geodetic-system/geodetic-datum" { default "wgs-84"; } } } container transducers { description "Current measurement values accessible via polling or configuration."; list transducer { key "type id"; description "List of available measurements."; leaf type { type identityref { base transducer-type; } description "The type of measurement."; } leaf id { type uint8; description "Instance identifier to distinguish multiple sensors of the same type."; } leaf unit { type string; description "Unit of measurement (e.g., 'C', 'm/s', '%')."; } leaf nature { type transducer-nature; description "Indicates whether this is a sensor, actuator, computed value, or internal parameter."; } leaf precision { type int8; default 1; description "Number of decimal places. Real value = raw_value * 10^-precision."; } container quantity { config false; description "Operational state for this transducer."; Toutain Expires 6 December 2026 [Page 27] Internet-Draft coreconf-m2m June 2026 leaf value { type int64; description "The current raw integer value of the transducer."; } leaf timestamp { type uint64; units "seconds"; description "Epoch timestamp (seconds) of the last transducer update."; } leaf u-timestamp { type uint32; units "microseconds"; description "Microsecond fraction of the timestamp (0..999999)."; } leaf timestamp-source { type enumeration { enum source { value 0; description "Timestamp generated by the sensor itself."; } enum receiver { value 1; description "Timestamp applied by the receiver upon arrival."; } } description "Origin of the timestamp associated with this measurement."; } container statistics { config false; description "Read-only accumulated statistics for this measurement."; leaf min { type int64; description "Minimum value observed since last reset."; } leaf max { type int64; description "Maximum value observed since last reset."; } leaf mean { type int64; description "Mean value observed since last reset."; } leaf median { type int64; description "Estimated median value observed since last reset."; } leaf stdev { type uint64; Toutain Expires 6 December 2026 [Page 28] Internet-Draft coreconf-m2m June 2026 description "Standard deviation since last reset."; } leaf sample-count { type uint64; description "Number of samples used for statistics calculation."; } } } container notification-parameters { description "Configuration parameters controlling how this transducer is reported in CoMI notification streams."; container history { description "Parameters for the history time-series stream."; leaf active { type boolean; config false; description "True when a FETCH+Observe subscription is active on `/s` for this transducer history stream."; } leaf step { type uint32; units "milliseconds"; description "Time interval between samples in the notification stream."; } leaf precision { type uint8; default 1; description "Number of decimal places for values encoded in time-series notifications."; } leaf max-samples { type uint32; description "Maximum number of samples kept in the time-series buffer."; } leaf time-period { type uint32; units "seconds"; description "Duration of the time window covered by the history buffer."; } leaf encoding { type encoding-type; default "delta"; description "Encoding used for the values list in notifications."; } leaf max-payload { Toutain Expires 6 December 2026 [Page 29] Internet-Draft coreconf-m2m June 2026 type uint32; units "bytes"; description "Maximum payload size in bytes. When exceeded, the notification is sent early. 0 means no size limit."; } } container sensor-alert { description "Parameters for threshold-based sensor-alert notifications."; must "not(t-min and t-max) or t-min < t-max" { error-message "t-min must be strictly less than t-max."; } leaf active { type boolean; config false; description "True when a FETCH+Observe subscription is active on `/s` for this transducer sensor-alert stream."; } leaf t-min { type int32; description "Minimum threshold. Alert raised when value falls below."; } leaf t-max { type int32; description "Maximum threshold. Alert raised when value exceeds."; } leaf hysteresis { type uint8 { range "0..100"; } default 5; units "percent"; description "Hysteresis applied to threshold crossings, as a percentage."; } leaf dampening { type uint32; default 0; units "milliseconds"; description "Minimum time between two consecutive sensor-alert notifications. 0 means no dampening."; } } } action reset-stats { description Toutain Expires 6 December 2026 [Page 30] Internet-Draft coreconf-m2m June 2026 "Reset accumulated statistics for this transducer."; } } } rpc reset-stats { description "Reset accumulated statistics for all transducers."; } notification history { description "History time-series notification sent to Observe subscribers."; leaf last { type boolean; default "false"; description "True if this is the last notification for the current series."; } uses transducers-list { augment "time-series" { container internal { description "Internal operational state for this time-series entry."; leaf last-update { type uint64; units "seconds"; description "Epoch timestamp of the last sample appended."; } leaf start-time { type uint64; units "seconds"; description "Epoch timestamp of the first sample."; } leaf messages-sent { type uint64; description "Number of notification messages sent since subscription."; } } } } } notification sensor-alert { description "Alert notification when a value exceeds a threshold."; list target { key "type id"; description "Measurement instances that triggered this alert."; leaf type { type identityref { Toutain Expires 6 December 2026 [Page 31] Internet-Draft coreconf-m2m June 2026 base transducer-type; } } leaf id { type uint8; } leaf value { type int64; description "The measurement value that triggered this alert."; } } } } Figure 11: Complete coreconf-m2m YANG module Appendix B. SID File (CSV) The following table lists the SID assignments for the coreconf-m2m module (assignment range: 100000–100399, revision 2026-03-29). SID,Namespace,Identifier 100000,module,coreconf-m2m 100001,identity,air-temperature 100002,identity,average-distance 100003,identity,barometric-pressure 100004,identity,east-wind-speed 100005,identity,north-wind-speed 100006,identity,precipitation 100007,identity,relative-humidity 100008,identity,solar-radiation 100009,identity,strike-count 100010,identity,tilt 100011,identity,transducer-type 100012,identity,vapor-pressure 100013,identity,wind-direction 100014,identity,wind-gust 100015,identity,wind-speed 100016,identity,x-orientation 100017,identity,y-orientation 100018,data,/coreconf-m2m:characteristics 100019,data,/coreconf-m2m:characteristics/geo-location 100020,data,/coreconf-m2m:characteristics/geo-location/height 100021,data,/coreconf-m2m:characteristics/geo-location/latitude 100022,data,/coreconf-m2m:characteristics/geo-location/longitude 100023,data,/coreconf-m2m:characteristics/geo-location/reference-frame 100024,data,/coreconf-m2m:characteristics/geo-location/reference-frame/alternate-system 100025,data,/coreconf-m2m:characteristics/geo-location/reference-frame/astronomical-body Toutain Expires 6 December 2026 [Page 32] Internet-Draft coreconf-m2m June 2026 100026,data,/coreconf-m2m:characteristics/geo-location/reference-frame/geodetic-system 100027,data,/coreconf-m2m:characteristics/geo-location/reference-frame/geodetic-system/coord-accuracy 100028,data,/coreconf-m2m:characteristics/geo-location/reference-frame/geodetic-system/geodetic-datum 100029,data,/coreconf-m2m:characteristics/geo-location/reference-frame/geodetic-system/height-accuracy 100030,data,/coreconf-m2m:characteristics/geo-location/timestamp 100031,data,/coreconf-m2m:characteristics/geo-location/valid-until 100032,data,/coreconf-m2m:characteristics/geo-location/velocity 100033,data,/coreconf-m2m:characteristics/geo-location/velocity/v-east 100034,data,/coreconf-m2m:characteristics/geo-location/velocity/v-north 100035,data,/coreconf-m2m:characteristics/geo-location/velocity/v-up 100036,data,/coreconf-m2m:characteristics/geo-location/x 100037,data,/coreconf-m2m:characteristics/geo-location/y 100038,data,/coreconf-m2m:characteristics/geo-location/z 100039,data,/coreconf-m2m:characteristics/identifier 100040,data,/coreconf-m2m:characteristics/name 100041,data,/coreconf-m2m:characteristics/version 100042,data,/coreconf-m2m:history 100043,data,/coreconf-m2m:history/last 100044,data,/coreconf-m2m:history/time-series 100045,data,/coreconf-m2m:history/time-series/id 100046,data,/coreconf-m2m:history/time-series/internal 100047,data,/coreconf-m2m:history/time-series/internal/last-update 100048,data,/coreconf-m2m:history/time-series/internal/messages-sent 100049,data,/coreconf-m2m:history/time-series/internal/start-time 100050,data,/coreconf-m2m:history/time-series/type 100051,data,/coreconf-m2m:history/time-series/values 100052,data,/coreconf-m2m:reset-stats 100053,data,/coreconf-m2m:reset-stats/input 100054,data,/coreconf-m2m:reset-stats/output 100055,data,/coreconf-m2m:sensor-alert 100056,data,/coreconf-m2m:sensor-alert/target 100057,data,/coreconf-m2m:sensor-alert/target/id 100058,data,/coreconf-m2m:sensor-alert/target/type 100059,data,/coreconf-m2m:sensor-alert/target/value 100060,data,/coreconf-m2m:state 100061,data,/coreconf-m2m:state/uptime 100062,data,/coreconf-m2m:transducers 100063,data,/coreconf-m2m:transducers/transducer 100064,data,/coreconf-m2m:transducers/transducer/id 100065,data,/coreconf-m2m:transducers/transducer/nature 100066,data,/coreconf-m2m:transducers/transducer/notification-parameters 100067,data,/coreconf-m2m:transducers/transducer/notification-parameters/history 100068,data,/coreconf-m2m:transducers/transducer/notification-parameters/history/active 100069,data,/coreconf-m2m:transducers/transducer/notification-parameters/history/encoding 100070,data,/coreconf-m2m:transducers/transducer/notification-parameters/history/max-payload 100071,data,/coreconf-m2m:transducers/transducer/notification-parameters/history/max-samples 100072,data,/coreconf-m2m:transducers/transducer/notification-parameters/history/precision 100073,data,/coreconf-m2m:transducers/transducer/notification-parameters/history/step Toutain Expires 6 December 2026 [Page 33] Internet-Draft coreconf-m2m June 2026 100074,data,/coreconf-m2m:transducers/transducer/notification-parameters/history/time-period 100075,data,/coreconf-m2m:transducers/transducer/notification-parameters/sensor-alert 100076,data,/coreconf-m2m:transducers/transducer/notification-parameters/sensor-alert/active 100077,data,/coreconf-m2m:transducers/transducer/notification-parameters/sensor-alert/dampening 100078,data,/coreconf-m2m:transducers/transducer/notification-parameters/sensor-alert/hysteresis 100079,data,/coreconf-m2m:transducers/transducer/notification-parameters/sensor-alert/t-max 100080,data,/coreconf-m2m:transducers/transducer/notification-parameters/sensor-alert/t-min 100081,data,/coreconf-m2m:transducers/transducer/precision 100082,data,/coreconf-m2m:transducers/transducer/quantity 100083,data,/coreconf-m2m:transducers/transducer/quantity/statistics 100084,data,/coreconf-m2m:transducers/transducer/quantity/statistics/max 100085,data,/coreconf-m2m:transducers/transducer/quantity/statistics/mean 100086,data,/coreconf-m2m:transducers/transducer/quantity/statistics/median 100087,data,/coreconf-m2m:transducers/transducer/quantity/statistics/min 100088,data,/coreconf-m2m:transducers/transducer/quantity/statistics/sample-count 100089,data,/coreconf-m2m:transducers/transducer/quantity/statistics/stdev 100090,data,/coreconf-m2m:transducers/transducer/quantity/timestamp 100091,data,/coreconf-m2m:transducers/transducer/quantity/timestamp-source 100092,data,/coreconf-m2m:transducers/transducer/quantity/u-timestamp 100093,data,/coreconf-m2m:transducers/transducer/quantity/value 100094,data,/coreconf-m2m:transducers/transducer/reset-stats 100095,data,/coreconf-m2m:transducers/transducer/reset-stats/input 100096,data,/coreconf-m2m:transducers/transducer/reset-stats/output 100097,data,/coreconf-m2m:transducers/transducer/type 100098,data,/coreconf-m2m:transducers/transducer/unit Figure 12: SID assignments for coreconf-m2m (CSV format) Acknowledgments This work has been supported by the SCHC Chair from IMT Atlantique and Afnic. Author's Address Laurent Toutain IMT Atlantique Email: laurent.toutain@imt-atlantique.fr Toutain Expires 6 December 2026 [Page 34]