Summary

  • Revision 04 of draft-hi-ccamp-cmis-control-yang became available on 9 September 2026. It is an active individual Internet-Draft in I-D Exists, not a CCAMP working-group document, RFC or deployed standard.
  • The new Control Handover section says that adding a page to remote-write-allowed-pages delegates its writes to the remote system. Removing it revokes that authority and requires the host NOS to reapply local values; remote writes not yet applied should be rejected.
  • The same revision explicitly leaves atomicity and mutual exclusion for multi-step CMIS operations outside scope. A sequence that is partly applied at the cutoff therefore has no common protocol state proving that the remote side stopped before the host resumed.
  • Daniel Kade proposes a local, page-scoped quiescence state machine between revocation and host control. It is deployment guidance, not an IETF requirement, and it should expose only the minimum transition facts needed for safe local verification.

Revision 04 turns an allowlist into a transfer of control

The immutable revision 04 text is dated 9 September 2026. The Datatracker API record identifies it as the active revision, expiring on 13 March 2027, with the states Active and I-D Exists. It is an individual submission with no RFC stream or responsible Area Director. Its header says Standards Track, but an intended status is not adoption.

The draft addresses an awkward part of coherent-optics management. Pluggable Digital Coherent Optics modules expose memory pages through the Common Management Interface Specification. A host network operating system may understand standardized functions. A remote optical controller or local third-party application may need a vendor-specific custom page or a feature that the host has not implemented yet. The proposed YANG modules give those other systems register-level read, write, action, RPC and monitoring paths.

Revision 04 adds a sharper boundary around that access. It describes raw CMIS access as a complement to abstracted models, not their replacement. It recommends staged deployment: laboratory, bring-up and troubleshooting first; read-only and monitoring-centred production use before narrowly validated writes. It also adds a section called Control Handover.

The rule is concrete. Put a page in remote-write-allowed-pages, and write control for that page is delegated to the remote system. While delegation is active, the host NOS must not autonomously modify its registers, except for a safety intervention such as shutting down a transmitter. The host should notify the remote system after such an intervention.

Remove the page, and the delegation is revoked. The host must enforce its local configuration on that page, overwriting values changed remotely or resetting them to defaults according to the model. Revocation applies to operations initiated after the governance change. Implementations should reject an in-flight remote write that has not yet been applied.

That is more than an access-control list. It assigns operational ownership, creates an exception, and specifies what must happen when ownership returns.

Permission can change at one instant; hardware state may not

The difficult phrase is “not yet been applied”. A single write may have a visible completion point. A multi-step optical operation may not. One step can select a page, another can stage parameters and another can trigger the change. Several related pages may participate. If revocation lands between those steps, the system needs to distinguish an operation that never started, one that completed, one that was cancelled and one whose effects are indeterminate.

Revision 04 does not pretend to solve that problem. Its security section says the document does not define atomicity or mutual exclusion for multi-step CMIS operations between the host NOS and a remote system. Coordination is the operator's responsibility and outside scope.

That limitation is honest. It is also where deployment governance begins. The allowlist can say who may send the next request. It cannot by itself prove that the previous writer has stopped changing the device, that a partially applied sequence has been reversed, or that the host's restored configuration was applied in a safe order. A permission transition and a device-state transition are not the same event.

This distinction matters because the draft identifies powerful effects. Register writes can change output power and frequency and may interfere with other active wavelengths. Lower Memory must never be remotely writable because it carries host-management flags and page-selection registers. Firmware-management CDB pages 9Fh through AFh must also stay outside the write allowlist because they can initiate a firmware update and create persistent compromise. These prohibitions are useful hard boundaries. They do not settle the final state of an allowed but interrupted operation.

The last reader can matter as much as the last writer

Some CMIS registers have clear-on-read semantics. Reading them consumes the event: if the remote system reads first, the host may no longer see what was there, and the reverse is also true. Revision 04 treats simultaneous use of a delegated page as a delegation-design error and assigns responsibility for reading the page, including clear-on-read behaviour, to the remote system while it owns the delegation.

On handback, that responsibility must cross the boundary too. The host should not destroy unread evidence while trying to prove that control returned cleanly. Nor should it assume silence means no event occurred if the remote side already consumed the register. A complete transition therefore needs the identity of the last responsible reader or an explicit statement that clear-on-read state could not be preserved. This is evidence custody, not merely permission syntax.

RFC 8341 gives NETCONF and RESTCONF a common access-control model for users, operations and data nodes. Revision 04 explains why it adds another layer: NACM cannot restrict an action or RPC by the value of an input such as a target CMIS page number. Page-level governance narrows the address space after the user has already been authorised. Neither layer is designed to certify the completion of a cross-writer handover.

Put a quiescence barrier between revocation and autonomy

The minimum repair is not a global transaction manager. It is a local page-handover state machine with four ordinary states and one exceptional branch.

REMOTE_ACTIVE identifies the controller, device or interface, page set and governance version under which remote writes are valid. Revocation moves the scope to QUIESCING, where new remote operations are denied and each in-flight operation is classified as completed, cancelled or indeterminate. A multi-step sequence needs one terminal disposition, not a hopeful inference from the last transport response.

The host then enters HOST_RECONCILING. It reapplies local configuration in a declared order, preserves or accounts for clear-on-read evidence, and checks the local safety invariants that matter for the interface: the intended page selection, transmitter condition, frequency, output power and link state where applicable. Only a successful local check moves the page set to HOST_ACTIVE and restores autonomous host management.

A separate SAFETY_OVERRIDE path preserves the draft's emergency exception. It permits immediate protective action without waiting for ordinary quiescence. But the exception remains visible, names the pages or function affected, notifies the remote side when possible and converges through reconciliation. Emergency power should interrupt normal ownership, not silently rewrite its history.

The record can stay small: module or draft revision and digest; device, interface and page set; current owner; governance version; cutoff time; transition state; disposition of in-flight work; the last accepted operation identifier if locally available; host configuration version; clear-on-read custody; safety intervention; reconciliation result; and responsible operator. Vendor register values, private topology and exploitable detail do not need to leave the administrative domain.

This follows the restraint of Heng Lu's Minimum Initial Specification: make the shared safety and state-transition rules deterministic, while leaving vendor semantics and operating policy local. The Policy Mirror supplies the complementary discipline that the rule, authority and result behind an automated change should remain reconstructable. The state machine is my proposal. Neither essay nor revision 04 requires it.

A careful draft still needs implementation evidence

Revision 04 adds several sound limits. Unfiltered page-memory reads can saturate the slow shared management bus, so the draft prefers targeted operations, filtering, bounds and rate limits. It allows systems to impose restrictions stricter than an operator's allowlist, although advertising those restrictions is deferred to a future revision. It says abstracted models should be preferred where they exist.

The evidence boundary is equally important. The new implementation-status section retains only its unfilled template fields. IETF 126 CCAMP minutes record participant questions about operator feedback, implementation dependence, overlap with abstracted models and whether the work should be experimental. Those comments are not a working-group decision. They reinforce that the design has not yet earned a deployment claim.

No public source in this package proves a race, outage, optical interference, firmware compromise or faulty product. The finding is narrower: revision 04 now defines who controls an allowed page and how revocation restores host values, while expressly leaving multi-step exclusion to operators. Before production relies on that handover, an operator needs a locally testable point at which the remote writer is quiet and the host state is valid again.

Sources