Summary

  • The September 2026 Last Call for draft-ietf-teas-actn-poi-applicability-20 has drawn separate Security and Operations Directorate reviews marked “Not ready”; those assessments are reviewer advice, not an IESG rejection.
  • Security reviewer Yaron Sheffer asks for an architectural threat account. Operations reviewer Nick Buraglio asks how MDSC and PNC state is reconciled through restarts, notification loss, failover and partially completed packet–optical changes.
  • Before delegating live provisioning, an operator needs evidence of authorization, state freshness, in-flight operation ownership, partial-success handling and service outcome. That is an editorial operating test, not a new requirement claimed for the draft.

A diagram can finish before an operation does

A coordinator instructs a packet controller and an optical controller to change one service. The packet side acknowledges; the optical side times out. The diagram still shows an MDSC linked to two PNCs. It cannot tell an operator whether the service is now safe, inconsistent, reversible or simply unknown. This is a hypothetical test case, not a reported deployment failure. It captures the distinction at the heart of two new IETF reviews.

Revision 20 of the ACTN packet–optical integration draft describes how a Multi-Domain Service Coordinator can coordinate packet and optical Provisioning Network Controllers through existing protocols and YANG models. Its IESG Last Call began on 9 September and runs to 23 September 2026. The intended status is Informational. As checked on 21 September, the document remains an Internet-Draft in Last Call, not an approved RFC. The draft already has security and operational sections; the dispute is about whether those sections address the architecture’s most consequential operating cases.

The review record is mixed. Yaron Sheffer’s Security Directorate review, completed on 18 September, and Nick Buraglio’s Operations Directorate review, completed on 19 September, are both recorded as “Not ready.” Buraglio’s own summary calls some concerns minor, while his detailed review labels the operational section’s inadequacy a major issue. Zheng Zhang’s Routing Directorate review is marked “Ready” and asks largely for small clarifications. Directorate reviews inform the process; none is an IESG decision or proof of failure in a working network.

Security is a control relationship, not only a protected channel

The draft’s Section 7 discusses secure protocol transport, authorization and LLDP snooping. Sheffer’s objection is more specific than a demand for another encryption reference. A large ACTN/POI deployment can span administrative domains, vendors and controllers that do not share identical trust. He asks the authors to name the assets and trust boundaries and to analyze the consequences of a compromised or malicious controller, false or stale topology and resource data, unauthorized cross-layer action, information disclosure, exhaustion and packet/optical state left inconsistent.

He suggests a short architectural treatment rather than an exhaustive threat catalogue. He also says he cannot evaluate every technical detail of the broad draft; his review should not be inflated into a finding of an exploited flaw.

That distinction matters at the MDSC–PNC interface. RFC 8453 defines ACTN roles and policy-shaped abstraction. A protected channel can authenticate a PNC and protect messages in transit. It does not automatically prove that a resource view is current, that the sender is allowed to authorize this particular cross-layer action, or that a downstream controller has not lost the state on which a prior acknowledgement depended. The exact permissions, provenance, expiry and reconciliation method belong to an implementation and its operator. The review is asking the draft to make these boundaries legible.

A missing answer after a restart

Buraglio’s central operational question begins when control state diverges. The MDSC builds topology and service knowledge from PNC notifications. A PNC restart, missed notification or partial failure can leave its local view different from the coordinator’s. The review asks how inconsistency is detected and repaired, what happens to an in-flight provisioning operation during a PNC restart or MDSC failover, and how MDSC redundancy affects services already established. Those are separate from whether a controller can compute a path under normal conditions.

He then follows a service through the awkward middle of a change. Sections 4 and 5 describe sequential interactions among MDSC, packet PNCs and optical PNCs, yet the review finds little guidance on timeouts, retries or expected provisioning latency. It asks what should happen if packet reconfiguration succeeds while the optical operation fails, or the reverse. A retry that cannot identify the previous operation could duplicate a request; a rollback that treats both domains as one transaction could misread an already active path.

These are editorial implications of the review’s questions, not incidents alleged by Buraglio or procedures specified by the draft.

The review reaches beyond one failure path. It asks for a brownfield migration account, because live operators have existing optical and IP management systems; for an acknowledgement that multi-layer operation requires cross-disciplinary skills; for a scalability boundary instead of an unqualified deferral; and for attention to binding SID persistence, notification subscription lifecycle and audit trails. Its critique is not that every topic needs a fully standardized answer in an Informational document. It is that an operator needs to know where the specification ends and which unanswered conditions must be designed and tested locally.

The contract to test before delegation

The strongest practical response is an explicit operating contract at each handoff. Before admitting an MDSC to provision across layers, an operator can require a test record with five linked facts: the principal and scope authorized to request the change; the topology/resource version each controller used; the durable identity and state of the in-flight operation; each PNC’s observed commit or failure; and the packet, optical and customer-service observations after the change. This is BTW’s analytical checklist, not a field schema mandated by IETF.

The tests should deliberately interrupt the happy path. Suppress a notification, restart a PNC during a request, fail over the MDSC between domain acknowledgements, delay an optical response and make only one layer accept a change. The point is to discover whether the system reports “unknown” honestly, reconstructs state, freezes an unsafe next action and identifies the party authorized to compensate or roll back. It should also preserve established services when orchestration is unavailable where the design promises that property. A passing diagram or a successful isolated API call cannot establish these behaviors.

That is the fresh decision raised by the September reviews. The earlier question of what an abstract topology represents remains important, but the new question is who bears responsibility when the coordinated operation crosses a trust boundary and its components disagree. The Last Call can still lead to revision, discussion or approval. Nothing in the current record warrants declaring a rejected standard, an observed attack or a deployed outage.

Sources

ACTN/POI draft and current status; Security Directorate Last Call review; Operations Directorate Last Call review; Routing Directorate Last Call review; RFC 8453 ACTN framework.