When YANG service lifecycles disagree

Summary

An individual ONSEN problem-statement draft says similar YANG-derived APIs can differ in lifecycle behaviour, validity, duration and feedback even when their syntax aligns. The document expired on 19 August 2026 and is not an adopted Working Group item or IETF consensus.
A service order, accepted configuration, applied device state, observed health and commercial closure are separate propositions. A green result in one layer cannot prove that every layer assigns the same meaning to “active,” “expired,” “rolled back” or “closed.”
Daniel Kade proposes a service-semantic receipt that binds the exact intent, lifecycle vocabulary, time basis, decomposition, transformations, enforcement evidence, decision authority and closure proof. This is editorial guidance, not an ONSEN or IETF requirement.

The clock expires only one description

The opening scenario does not require a defective parser or a malicious vendor. It requires a composite service and several competent systems. A customer orders high-bandwidth connectivity for a defined interval. The business system records an end time. The service orchestrator decomposes the intent into network services. Controllers turn those services into configurations for multiple segments. Telemetry and assurance components observe what the network is doing.

At the deadline, each system follows its own rule. “Complete” may mean that billing has stopped. “Expired” may mean that no new renewal is permitted. “Decommissioning” may mean that removal has been requested but not applied. “Down” may describe one bearer while the higher-level service remains usable through another path. A cached health calculation may remain green after the intended configuration changed.

None of those statements is necessarily false. The policy mirror lies in the join. Each layer exposes a faithful account of the world it controls, while a dashboard compresses those accounts into one badge. The compression silently appoints one layer’s vocabulary as the authority for the whole service.

YANG can make the data precise without settling that appointment. A schema can define nodes, types, constraints, operations and notifications. Two products can accept the same structure and still disagree about when a transition becomes effective, which clock governs it, whether a partial failure is a rollback, and who may declare the work closed.

What the ONSEN draft actually says

draft-xie-onsen-problem-statement-01 defines service semantics as operational meaning—lifecycle behaviour, validity, duration and feedback—rather than YANG syntax. It says APIs derived from similar models may vary across vendors and deployments, forcing operators and OSS/BSS systems to build bespoke integration.

Its illustrative Data Transmission Service for Data-Intensive workloads is deliberately demanding. A burst of data needs high bandwidth, predictable timing and coordination across heterogeneous or even multi-operator domains. The example order includes start time, end time and bandwidth. Delivery can cross an access segment, a VPN segment and a data-centre egress segment, with a BSS, orchestrator, controller and network devices participating.

The draft generalises from that example. Instantiation, monitoring, troubleshooting, modification and decommissioning often use different tools and interfaces. Lifecycle actions cross orchestrators, controllers and device configurations whose models and assumptions rarely align. Existing abstractions may lack activation time, duration, expiration and rollback constructs. Similar-looking metrics can differ in definition, units, scope or update frequency. Configuration-oriented APIs may offer limited evidence that requested behaviour was applied and remains valid.

Those are problem statements, not a completed remedy. Revision -01 was published on 15 February 2026 and states an expiry of 19 August 2026. The Datatracker page accessed for this article labels it an active individual Internet-Draft, but the printed expiry has passed. Its Operational Considerations and Security Considerations remain unfinished. It explicitly does not propose a specific protocol, solution or data model.

ONSEN itself is an active IETF Working Group with an approved charter. Its remit includes updating service and network abstractions and defining the interface between YANG-based service APIs and OSS/BSS. That institutional fact matters. It does not make this individual draft a Working Group adoption, an IETF Last Call result, an RFC or evidence of implementation.

A schema is not a state treaty

RFC 8969 provides the architectural backdrop. It separates customer-facing service models, network models and device models, and describes mapping down through those layers and feeding operational information back up. It covers instantiation, provisioning, optimization, monitoring, diagnosis and assurance. The framework is an Informational IETF-consensus RFC; it makes the layers intelligible without claiming that every implementation shares one lifecycle state machine.

RFC 8342 makes another essential separation. Intended configuration is what a system attempts to apply. Applied configuration is what is actively in use. Operational state combines applied configuration with system state. Transformations, missing resources, delays and protocol interactions can leave values different, and their lifetimes can differ. “Commit succeeded” therefore cannot be promoted into “the intended service exists as promised.”

RFC 9417 puts the point plainly in the assurance context: knowing that configuration is applied does not imply that a provisioned service is up and operating as expected. Its assurance graph relates a service instance to subservices, health and symptoms. RFC 9418 models that architecture. These mechanisms can expose divergence. They do not reconstruct the customer’s duration, the billing rule, the authority to cancel or the meaning of a terminal state unless those connections are supplied.

Layered VPN models illustrate the same limit. RFC 8299 describes a customer-facing L3VPN service model; RFC 9182 describes an operator-facing L3VPN network model. The models serve different viewpoints. Correct mapping between their fields is necessary, yet lifecycle accountability also requires the operator to say which transition at one layer satisfies which transition at the other.

RFC 9834 keeps administrative and operational status separate for bearers and attachment circuits. The desired administrative state should not be rewritten by the observed state, and both should be considered when judging delivery. This is disciplined modelling. It also warns against the tempting dashboard shortcut of turning whichever status arrived last into the truth of the service.

Six green lights, six different claims

An operator should name the propositions before automating them.

Request acceptance means an API found the request syntactically and contextually acceptable. Validation means constraints known at that boundary passed. Commit means a configuration transaction reached a datastore or system. Intended means transformations have produced the configuration the system seeks to apply. Applied means some configuration is actively in use. Observed health means measurements found no defined symptom at a specified time and scope.

Commercial closure is different again. It may stop charging, release a promise to the customer, start retention periods or close an incident obligation. Resource closure may require confirming that addresses, tunnels, credentials and monitoring subscriptions were removed. Those outcomes do not occur merely because an order object changed state.

A useful interface refuses to collapse the verbs. It can show a chain—accepted, decomposed, committed, applied, observed, retired—while retaining gaps and time. A failed lower segment need not rewrite the original intent. A successful device commit need not erase a pending assurance check. An expired order need not claim that deallocation has completed.

The service-semantic receipt

Daniel Kade proposes a service-semantic receipt for each material lifecycle transition. It is not a new YANG standard and need not force every domain into one universal state vocabulary. It is an evidence join at the boundaries where different vocabularies meet.

The first block identifies the thing being governed: a digest of the order and intent, the model and module revisions, enabled features, relevant deviations and the exact transition requested. “Modify” is not enough; the receipt states what changed and which prior state it presupposed.

The second block supplies time semantics. It records activation target, duration, expiry, timezone, clock source, grace period and the distinction between event time and observation time. If one system treats the end as inclusive and another as exclusive, the difference is visible before traffic is affected.

The third block records decomposition. The customer service points to network-service and device instances with stable identifiers. Each mapping carries its adapter or transformation version. A semantic loss—such as converting “finish transfer by 18:00” into “hold bandwidth until 18:00”—becomes an explicit decision instead of an invisible implementation detail.

The fourth block carries evidence: acceptance, validation, commit, intended, applied and observed timestamps; administrative and operational states; metric definitions, units, scope and freshness; and assurance symptoms. Evidence may disagree. The receipt preserves disagreement rather than averaging it into green.

The authority block names who may activate, modify, cancel, retry, compensate, roll back and close at each layer. A role or bounded automation can be the authority; a personal name is not always necessary. What matters is that the mandate is independently verifiable and limited to this class of effect.

Finally, closure records the terminal proof. Which resources were released? Which credentials or subscriptions remain? Did billing stop at the intended boundary? Is any remnant configuration still applied? What evidence is late or unavailable? The receipt itself expires, because yesterday’s aligned state cannot certify today’s modified service.

A workshop report is evidence with limits

RFC 9968 preserves the 2024 IAB NEMOPS workshop. It reports that model-driven management is generally successful where implemented, while the surrounding ecosystem remains fragmented. Participants discussed service-level modelling, operational state, observability, model mapping, heterogeneous tools and verifiable configuration. Its high-level takeaways include the need for greater service-level modelling and verification.

The status boundary matters. RFC 9968 is Informational and represents the IAB’s consensus to publish a valuable permanent record. It expressly says the views in the proceedings are those of participants and do not necessarily reflect IAB positions; much of the report does not claim workshop consensus. It is evidence of the problem conversation, not a mandate for the receipt proposed here.

Preserve local truth without losing system truth

Semantic alignment does not require centralising every decision. A controller should remain authoritative about what it applied. An assurance system should remain authoritative about the measurements and rules behind its health result. A BSS should retain its order and charging facts. The governance task is to state the translations and hand-offs among them.

That also preserves honest uncertainty. A service can be “customer obligation ended; network removal pending.” A segment can be “administratively down; operational state stale.” A rollback can be “requested; previous configuration unavailable.” Compound states may be less convenient than a green badge, but they are more useful to automation because they name the next responsible action.

No frozen source proves that a named operator has suffered the opening scenario. Nor does it establish a universal state machine, timeout, grace period or control design. The scenario tests a gap that the draft and RFCs make visible. The proposal remains editorial.

The durable lesson is narrower. Matching schemas can carry different institutions’ meanings. Automation becomes governable when a service transition leaves evidence of the intent it served, the transformations it crossed, the state it achieved, the authority that acted and the conditions under which everyone may finally call it closed.

A YANG Service Model Can Match While Its Lifecycle Semantics Diverge

Summary

The clock expires only one description

What the ONSEN draft actually says

A schema is not a state treaty

Six green lights, six different claims

The service-semantic receipt

A workshop report is evidence with limits

Preserve local truth without losing system truth

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing