Summary

  • draft-toutain-t2trg-coreconf-m2m-01 proposes a compact YANG/SID model and an MCP bridge that can resolve a device, sensor, unit and target before issuing a CoAP request.
  • A tool definition, correct SID, protected channel and successful protocol response prove different steps; none alone proves that the caller was entitled to move an actuator or that the requested physical state was reached.
  • A defensible actuation record must bind model revision, identity projection, principal, policy, approval, request, authorization, application commit, device execution and independent postcondition evidence.

The tool call says to set a pump to 1,500 revolutions per minute. Its name is clear, its argument passes the schema, the target SID resolves, the CoAP message is protected and the server returns success. The workflow can mark every digital stage green while the shaft remains stationary behind a tripped interlock.

That is not a paradox. “The server accepted a request” and “the physical system reached the requested state” are different claims. Between them sit firmware, local limits, mechanical load, power, calibration, feedback and time. The better an AI tool hides wire details, the easier it becomes to hide those evidence boundaries too.

Revision 01 of CORECONF for Machine-to-Machine Communication makes that problem concrete. On 2 October 2026 the IETF Datatracker listed it as an active individual Internet-Draft, updated 16 September. The text is dated 16 September, is intended to be Informational and expires 20 March 2027. It has no RFC stream, responsible area director or telechat date. Datatracker warns that an individual submission is not endorsed by the IETF and has no formal standing in its standards process. Discussion on the T2TRG list is a venue, not adoption.

The distinction matters because the proposal is ambitious. It combines YANG typing, compact CBOR, CoAP and YANG Schema Item iDentifiers—SIDs—for constrained devices. Revision 01 then maps the model into SOSA and SensorThings representations and sketches two MCP servers. One operates live devices over CoAP. The other reads and writes historical data in FROST. An agent can query a Thing, follow its Datastreams, obtain a sensor SID and precision, read the device and write the result back as an Observation.

This is useful integration design. It is not yet evidence of deployment, interoperability, latency, reliability or safe actuation.

Removing bespoke translation does not remove the translator

The abstract says the same CORECONF/SID serialization can expose device actions and data to an AI agent without an intermediate, device-specific translation layer. The phrase describes a real benefit: a shared model can replace hand-built serializers for every product.

But the proposed MCP server still performs consequential interpretation. It resolves a hostname, CoAP endpoint, transducer identity, instance SID, target-field SID, unit and precision from FROST. It converts a friendly tool call into a protocol request. It may store the result back into the same database. Whoever controls that resolution controls which physical surface the agent reaches.

A stale endpoint can direct a correct operation to the wrong device. A reused identity can attach a current name to an old transducer. A precision error can turn an integer into the wrong engineering value. A database edit can make a sensor appear to be an actuator or bind an action to the wrong instance. Every packet can remain valid.

The model itself recognizes some of this risk. Identity names and descriptions should be explicit because humans or AI agents may use them to formulate requests. Units and precision may be defaults attached to an identity or overrides on an inventory entry. Bootstrap information is read-only, changes on reboot and forces a new bootstrap phase. These are not display details. They are inputs to action.

The minimum projection receipt therefore needs the exact YANG module and revision, enabled features and deviations, SID allocation or private translation, device and transducer identity, endpoint, unit, precision, category, control type, method, path, target SID, data-source version and freshness. “The tool found the pump” is a conclusion built from all of them.

A control graph is not a permission graph

Revision 01 represents operations as ccm2m:Control instances. A control can name a method, path and target SID. The examples distinguish reading a current value, reading or resetting statistics, configuring history, starting a subscription and writing an actuator value.

That clarity is valuable. setup-history changes parameters; subscribe-history starts delivery. Stopping a subscription is not another SID-targeted action but a CoAP Observe lifecycle event. A reset destroys accumulated statistics without necessarily moving hardware. An instant-write changes a quantity associated with an actuator.

None of those labels identifies the principal entitled to invoke the control. A graph that says an operation exists does not say this model, user, service account or maintenance process may perform it now. It does not express a permitted range, a two-person rule, an emergency stop, a maintenance window, a maximum retry count or which other observers will be affected.

The base CORECONF draft is clearer about the protocol boundary than a superficial reading suggests. Revision 21 requires the server to prevent unauthorized users from reading or writing resources. It defines 4.01 Unauthorized for a client that lacks permission on a data node, datastore, RPC, action or event stream. Its security section points to protected CoAP access and suitable authentication and authorization mechanisms.

MCP also does not equate discoverability with permission. The current 2026-07-28 specification says the tool list may vary with per-request authorization. It requires servers to validate inputs and implement access controls. It advises confirmation for sensitive operations and says tool annotations are untrusted unless they come from a trusted server.

The missing work is binding those decisions across layers. The actuation receipt should identify the MCP server and tool-definition hash, requesting client, authenticated principal, credential audience and scope, policy version, user or policy approval, target device, operation and parameter bounds. It should then preserve the CORECONF authorization result. Otherwise the audit trail has a callable noun but no accountable actor.

Protected delivery is not physical execution

The selected draft requires CORECONF operations over CoAP to use DTLS or OSCORE. That protects communication according to the deployed profile. It does not decide the business or safety rule for a pump, heater or valve. Encryption can faithfully deliver an unauthorized or unsafe request; authentication can identify a principal whose scope was interpreted incorrectly.

The response boundary matters just as much. CORECONF defines protocol and model errors, including unauthorized access, wrong methods, malformed content, missing inputs and out-of-range values. A successful response means the request was processed at that layer. It does not report shaft speed, pressure, temperature, valve position or durable mechanical state unless an application explicitly measures and returns that evidence.

The draft's own actuator example quietly preserves this gap. It describes a fictitious pump whose rotation speed is written as 1,500 rpm. The pump identity uses a placeholder SID because the device does not exist in the example module. A sosa:Actuation records the value written and the time the command was issued. The text distinguishes the command from an observation.

That is exactly right. A command record is not a tachometer reading. Even a later reading needs its own identity, calibration, unit, timestamp source and causal window. If the same gateway produces both the command and the confirming value from one cached row, the second receipt may only repeat the first.

The defensible chain is longer: tool invocation; principal and approval; CORECONF authorization; protected request; application validation; durable mutation or action start; device-local interlock state; physical execution; separately sourced observation; expected range and persistence; reconciliation or rollback. The chain may stop at any point. The system should say where instead of returning one universal “success.”

Shared notification state reveals hidden blast radius

The draft's notification parameters offer a smaller but sharper example. Parameters such as sampling step, maximum samples, time period, encoding, payload limit, thresholds, hysteresis, dampening and confirmable-message cadence are writable. They are common to all observations of one transducer. A change made while notifications are active takes effect immediately and affects every subscriber, regardless of which client configured it.

An MCP action named “start history” can therefore contain a shared configuration write followed by a subscription. To one caller it looks like local setup. To another observer it can change sampling cadence, encoding, threshold behavior or confirmation frequency underneath an existing stream.

The read-only active flag says one or more clients are observing. It does not identify them, their purposes or whether they approved the new settings. A safe tool needs to disclose shared scope, read the prior version, apply a precondition or conflict rule, record the before-and-after values and enumerate affected observers. Cancellation also requires the original Observe token or transport state. A friendly tool name cannot make that state disappear.

This is where least privilege becomes semantic. Permission to subscribe is not necessarily permission to reconfigure everyone else's subscription. Permission to read current temperature is not permission to edit the FROST identity map used by the live controller. Permission to reset one transducer's statistics is not permission to erase the platform-wide record.

Non-confirmable messages move uncertainty upward

The profile requires FETCH and iPATCH requests to be Non-Confirmable CoAP messages. That choice can be rational on low-power networks, where default retransmission is expensive or badly tuned. It also places timeout, retry and duplicate handling in the application.

When the response is missing, the MCP server must not improvise as if it knows whether the request was lost. The write may not have arrived. It may have arrived and committed while the response vanished. A retry may be harmless for a set-value operation and destructive for a non-idempotent action. The evidence needs request identity, message token, attempt number, payload hash, timeout policy, device replay or duplicate behavior and any later readback.

Confirmable notifications solve a different problem. An ACK shows that the CoAP peer received a notification. It does not prove that FROST durably stored the observation, an agent considered it, a human saw an alert or the physical condition ended. If acknowledgements stop, the server may cancel the Observe relationship; the cause still may be client failure, path failure or intentional shutdown.

Compactness does not reduce the need for these distinctions. It makes them more valuable because constrained links provide fewer redundant clues.

Time and units are part of the verdict

The model has a reference epoch, uptime and optional timestamp source. A device without an absolute source may leave the reference epoch absent. A receiver can stamp a current quantity when the device did not. History times may be reconstructed from an arrival time and sampling interval.

Those are legitimate engineering techniques. They create different kinds of time. The instant when a command was issued, the time when firmware accepted it, the reconstructed time of a sample and the wall-clock time when a gateway stored it are not interchangeable.

The same applies to values. A raw integer becomes a physical quantity only through identity, unit and precision. The draft's minimal-step says how frequently new readings can emerge; faster polling may only drain a battery. A postcondition receipt must therefore carry time origin, clock quality, model revision, unit, precision, calibration and freshness. Otherwise a perfectly typed answer can describe an old measurement in the wrong scale.

A validator result is a model receipt, not a safety verdict

Datatracker's YANG validation page reported 19 errors and 8 warnings on 2 October. They include missing revision references and descriptions, canonical-order problems and a warning that a config false bootstrap node is outside the accessible tree.

Those findings are worth recording because the proposal depends on machines and humans interpreting the model consistently. They also need restraint. A formatting or documentation error is not automatically an exploitable defect. The count is not a risk score. It says this exact submitted revision has unresolved validation work.

The inverse error is equally dangerous. A future zero-error result would show that selected validators accepted the modules. It would not prove that the ontology projection is current, the right principal was authorized, two implementations interoperate, an actuator is safe or the physical postcondition occurred. Schema validation belongs in the model receipt and nowhere else.