Summary

  • draft-ietf-asdf-nipc-21 gives IP applications a protocol-neutral interface to non-IP physical components, resolving SDF affordances through mappings to technologies such as BLE and Zigbee.
  • An accepted action is asynchronous: HTTP 202 supplies an action-instance location, while later polling returns only IN_PROGRESS or COMPLETED. Neither state is defined as independent proof of a physical postcondition.
  • A physical-actuation receipt should preserve authorization, target and group membership, SDF and mapping versions, connection and trigger lineage, per-device gateway status, observed state, exceptions and reversal.

The reassuring word in the control room

At two in the morning, COMPLETED looks wonderfully decisive. A building application asked a gateway to open a ventilation damper. The gateway accepted the request, crossed a short-range radio network and closed its action instance. The operator's screen is green.

Yet several different things might now be true. The gateway may have emitted the correct protocol command and received the acknowledgement expected by that protocol. A motor may have turned but stopped before the requested position. The physical device may have acted, while the sensor used to verify it is stale. The action may have targeted yesterday's group membership rather than today's. Or everything may have worked exactly as intended.

Those possibilities do not make a common interface misleading. They show why an interface state must be read at its own boundary. NIPC—an Application Layer Interface for Non-Internet-connected Physical Components—addresses a real integration problem. Many useful devices do not speak IP directly. They sit behind BLE, Zigbee or other operational networks, while applications live on IP networks and want one coherent way to discover models, read properties, invoke actions, enable events and manage groups.

The governance mistake would be to turn the last state in one gateway workflow into the final truth about the world beyond it.

Acceptance, execution and outcome are three different records

NIPC actions make their asynchronous nature explicit. A successful POST returns HTTP 202 Accepted, a Location pointing to the action instance and a Retry-After value. The client waits and polls. RFC 9110 is precise about 202: processing has not been completed, and the request may or may not ultimately be acted upon.

The later NIPC status resource improves that picture, but it is deliberately small. Its vocabulary is IN_PROGRESS or COMPLETED. The draft does not attach a universal physical-state predicate to COMPLETED; it could not sensibly do so for every lamp, valve, latch, sensor, pump and future device class. The gateway knows about an action instance. Whether it also has authoritative evidence of illumination, flow, position or motion depends on the device model, protocol and deployment.

An accountable system therefore keeps three timestamps rather than one. The first records that the gateway accepted a request. The second records the gateway's completion state and the protocol evidence behind it. The third records the intended postcondition—if it is observable—through a property read, an independent sensor, a device event, a local controller or a human check.

This distinction is not pedantry. A service-level claim such as “commands complete within five seconds” is different from “the commanded physical condition is reached within five seconds”. Only the latter includes the world outside the gateway.

A common affordance still has a versioned route to the device

NIPC does not ask an application to speak every underlying protocol. It identifies an operation through an SDF global name: an absolute URI with a fragment that names a property, action or event in a Semantic Definition Format model. The gateway matches that neutral affordance to a registered protocol mapping and carries out the protocol-specific operation.

That separation is powerful. A lighting application can reason about a named action rather than constructing a Zigbee frame. A gateway can gain another protocol or protocol version without changing the application-facing API. RFC 9880 supplies the SDF vocabulary, while separate ASDF work defines how protocol mappings are expressed.

It also creates a versioned dependency chain. The application intended the meaning defined by one SDF model. The gateway selected one mapping. That mapping addressed a particular protocol feature on a particular device. If the model or mapping changes, the same apparent action name may follow a different operational path. A log containing only action name, device ID and COMPLETED cannot later show which interpretation was used.

The receipt need not preserve secrets or full payloads. It should retain a model digest, mapping digest or immutable version, the SDF global name, a hash of the action input, the selected protocol family and the action-instance URI. That is enough to test whether a semantic instruction was translated under the expected rule.

Device identity is necessary, but group identity moves

Before the gateway can operate on a device, it needs instance information: a unique UUID plus credentials or trust material sufficient to establish communication. Revision 21 recommends SCIM provisioning with RFC 7644 and the device schema in RFC 9944, while keeping provisioning outside the NIPC specification itself.

The UUID solves an important addressing problem. It does not prove that the label on a cabinet still corresponds to the same physical unit, that a replacement inherited the intended configuration correctly, or that a device remained in the same operational group. Those are lifecycle claims owned by provisioning and asset governance.

Groups make the distinction visible. A group action returns per-device status. One device can be COMPLETED, another IN_PROGRESS, and a failed member can carry a Problem Details entry under RFC 9457. A single group-level sentence such as “the floor lights were completed” discards the structure the interface took care to preserve.

The relevant evidence is the membership snapshot at invocation time, not merely the current group. It should identify every target UUID and later join each one to its status and observed postcondition. Otherwise a device removed after the incident can vanish from the explanation, while a device added later can appear to have been part of a command it never received.

Connections are part of causality

Some underlying protocols need connection setup. NIPC normally handles that implicitly: establish the connection for the operation and release it when the operation ends. A gateway may also support explicit connection management. When an explicit connection is already active, an operation reuses it and does not tear it down.

That implementation convenience changes the failure surface. A fresh implicit connection can fail during discovery, authentication or service resolution. A reused explicit connection can carry stale protocol state or survive across several application requests. Retries can turn an apparently singular business instruction into multiple device-level attempts.

A physical-actuation receipt should therefore say whether the path was implicit or explicit, which connection instance was used, how many attempts occurred and what acknowledgement or error closed each one. It should distinguish a retry by the gateway from a second instruction by the application. For actions that are not naturally idempotent—a dispenser, counter or motor jog—this is the boundary between safe recovery and accidental repetition.

A trigger can cross protocols while evidence remains fragmented

NIPC triggers connect an event on one device or group to an action on another. The draft deliberately makes the binding protocol-neutral and offers an example in which an event from a BLE device causes an action on a Zigbee device.

The feature is operationally attractive. A button can control a lamp without routing every reaction through a distant application. A sensor event can activate a local response even when higher-level systems are slow. But the causal chain now crosses several clocks and stores: the source event, installed trigger, gateway decision, target-group snapshot, selected protocol mapping, action instance and physical observation.

If only the last status survives, an operator cannot tell whether a surprising actuation began with a genuine event, an obsolete trigger, a duplicated delivery, a changed group or a manual command that happened at the same time. If only the event survives, the operator cannot prove which targets the trigger selected.

Trigger lineage belongs in the receipt. It should include the event instance or event digest, trigger-definition version, installation authority, activation time, target membership and the resulting action-instance references. The aim is not to centralise every radio packet. It is to keep the joins required to reconstruct responsibility.

Authorization and outcome must not borrow from each other

Revision 21 requires the network administrator to authorize applications. It recommends baseline Provisioning, Control and Data roles and permits tighter grants at API or affordance level. It also requires a transport-security mechanism such as TLS, limited bearer-token lifetimes and protected credentials, while recommending rate limits, input validation, monitoring and least privilege.

These controls answer different questions. TLS can protect a session and authenticate the server endpoint. A valid token can authorize an application to invoke an action. The action instance can report gateway completion. A sensor can observe a postcondition. None of those facts silently proves the others.

An unauthorized command that happens to produce the desired state is still a governance failure. An authorized command that produces no measurable state change is still an operational failure. A correct state reached by a different cause should not be credited to the action merely because the timestamps are close.

For that reason, the receipt retains the authorization decision and role, but not the bearer secret. It records the expected postcondition before execution, not after the result is known. It names the observation method and confidence. If the outcome cannot be independently observed, it says so instead of manufacturing certainty.

The physical-actuation receipt

A useful receipt can remain compact. Its request section records an event-scoped actor, role, authorization-decision reference, device or group ID, membership snapshot, SDF global name, model and mapping versions, input hash, requested time and expected postcondition.

Its execution section records the NIPC action-instance URI, acceptance time, connection mode and instance, selected protocol and mapping, attempt count, gateway transition times, per-device status and any Problem Details. Triggered actions add source-event and trigger lineage.

Its observation section records what was actually measured, when, by which sensor or procedure, and how that observation relates to the expected state. It keeps contradictory observations rather than overwriting them. Its governance section names the exception owner, escalation threshold, compensating action, reversal authority, retention period and correction path.

The record should be privacy-safe and proportional. A lamp does not justify permanent behavioural surveillance. A medical, industrial or safety-critical actuator may require stronger independent sensing and longer retention than a convenience light. The common minimum is the causal join, not a universal archive of physical life.

This is an operator evidence pattern, not a proposed NIPC field. The interoperable API can remain narrow. Local institutions can choose observation methods suited to their risks while still making acceptance, execution and outcome distinguishable.

Read the implementation list cautiously

The Datatracker listed revision 21 as an active ASDF working-group Internet-Draft submitted for publication and intended for Proposed Standard at the research cutoff. It was updated on 11 August 2026. It is not yet an RFC.

The draft contains an implementation-status section, but that section expressly says the contributor-supplied information is unverified, does not imply IETF endorsement and is not a full catalogue. It also lists compatibility against different draft revisions. The existence of prototypes or products is useful implementation feedback; it is not evidence that every listed system has the same completion semantics, physical observation or deployed governance controls.

Reality-based reporting preserves those limits. NIPC makes a valuable control boundary clearer. Operators should not erase that clarity by promoting a gateway's final word into proof of a physical world the API does not universally observe.

Sources