Summary

  • draft-ietf-ccamp-layer1-types-20 defines reusable Layer 1 identities, typedefs and groupings. Its own security section says the module exposes no writable nodes, read-only state nodes or RPCs by itself.
  • Schema validity and shared vocabulary are valuable receipts. They remain upstream of an importing model, implemented capability, authorized transaction, applied state, OTN resource allocation and observed client service.

The cleanest success can still be entirely abstract

Imagine a release pipeline ending in a perfect result. The YANG file parses. Every imported name resolves. Every identity has a valid base. Every when expression and numeric range passes the checker. The validator reports zero errors and zero warnings.

Nothing in that sequence says a transport shelf has changed.

That is not a criticism of YANG. It is the reason to read the evidence precisely. A compiler or validator answers whether a schema is well formed within its remit. It does not log into an optical device, ask whether the device implements the module, authenticate an operator, evaluate access policy, write intended configuration, commit a transaction, allocate matching labels at two endpoints, program a cross-connect or send a client signal through the resulting path.

Revision 20 of Common YANG Data Types for Layer 1 Networks was posted on 14 September 2026 and expires on 18 March 2027. Datatracker lists it as a CCAMP working-group document intended for Proposed Standard and in the RFC Editor queue. It has passed substantial review. It is still an Internet-Draft, not an RFC, deployed capability statement or operational result.

The distinction is easy to lose because data models look executable. Their trees contain names that resemble controls: bandwidth, label ranges, client signals, ODU types and resizable paths. In an instantiated configuration model, some of those leaves may indeed become writable. But revision 20 supplies reusable building blocks. The building blocks do not reveal whether anyone built the house.

A common language is real infrastructure

The positive case deserves more than a disclaimer. Optical automation fails when two systems use the same word for different shapes or different words for the same shape. A topology model, a tunnel model, a service model and a client-signal model need compatible ways to express the resources that bind them.

ietf-layer1-types supplies that vocabulary. Its tributary-slot-granularity identities distinguish 1.25G, 2.5G and 5G slot structures. Its odu-type hierarchy names Optical Data Unit forms. Its client-signal base covers families including Ethernet, STM, OC and Fibre Channel. Its label groupings attach OTN-specific tributary-port and tributary-slot information to generic traffic-engineering restrictions. Its bandwidth groupings describe the ODU forms a link can support and the form requested along a path.

Those definitions reduce translation work and semantic drift. A controller does not need to invent a private JSON field for every optical concept. A vendor module can extend a common identity rather than replace the whole language. A model author can import a reviewed grouping rather than reproduce it with slightly different limits.

That is a coordination achievement. The mistake begins only when coordination is inflated into execution. Sharing the type ODU4 is not the same thing as exposing an ODU4 resource. Exposing a resource is not reserving it. Reserving it at one point is not proving matching endpoint state. Matching state is not proof of signal continuity.

The common vocabulary is authoritative for the structure it defines. It has no warrant to borrow authority from later layers.

The draft states its own limit

The strongest boundary is not an external critique. It appears in the document's security considerations.

The module defines identities, types and groupings for reuse by other YANG modules. By itself, it exposes no writable data nodes, no read-only state data nodes and no RPCs. The draft therefore finds no additional security issue caused by a directly accessible surface in this module alone. It then moves the risk downstream: modules that instantiate the groupings must analyze their own exposure, because OTN bandwidth and label-range data can reveal sensitive topology information.

This wording separates a library from an application. A library can contain a type called otn-link-bandwidth; that does not mean a datastore currently contains a link-bandwidth object. A grouping can show rw nodes in its tree as they would appear when used; the grouping still needs an importing module and an instantiated location before a management client has something to read or write.

The security boundary proves a wider operational point. If the module alone has no writable node and no RPC, then a screenshot saying “the Layer 1 model is installed” cannot prove a configuration was requested. If no read-only state node exists in the module itself, the same screenshot cannot prove observed device state. The importing module, module-set advertisement, datastore path and operation all matter.

This is where good automation starts: not by diminishing the schema, but by refusing to ask it for a receipt it was designed not to issue.

One import is not a capability claim

Revision 20 is designed to be imported by models for OTN topology, tunnels, client signals and Layer 1 connectivity services. OTN also needs the generic traffic-engineering types alongside the Layer 1-specific definitions. That dependency graph tells an implementer how schemas compose. It does not tell an operator which compositions a particular device supports.

YANG identities are intentionally extensible. A vendor can derive a new ODU identity from the common odu-type base. This is useful when a technology-specific form does not fit the standard list. It is also evidence that a base identity is not a universal capability table.

The draft makes the point concrete. It notes that some ODUk LSP forms can be represented through vendor-specific modules because the related container specification does not guarantee data-plane interoperability. The schema can carry the name without making two implementations interoperate.

A defensible capability claim therefore needs more than an import statement. It needs the device's advertised YANG library or equivalent module inventory, implemented revision and feature set, deviation records, vendor documentation or tests, and a live read of the relevant instantiated nodes. If two endpoints are involved, the evidence must cover both.

Even that proves capability, not present availability. A chassis can support ODU4 while every suitable timeslot is occupied. A controller can understand an ODUflex identity while one endpoint lacks the required adaptation. Capability is the answer to “could this implementation express or perform the function?” Availability is the answer to “can this requested path receive the resources now?” They are different operational questions.

Counting capacity does not reserve it

The otn-link-bandwidth grouping usually represents how many ODUs of each type a link can support. Revision 20 gives a simple illustration: a 100G link might support one ODU4, ten ODU2s or eighty ODU0s.

Those alternatives should not be added as if the link contained 191 independent units of capacity. They are different views of the same underlying resource. The grouping creates a structured way to report them. The allocator still needs to account for current occupation, fragmentation, endpoint constraints, priorities, policy and the requested path.

The label-range groupings have the same boundary. An OTN label combines a Tributary Port Number with a related set of Tributary Slots. The same label must be assigned to the same ODUk LSP at both ends of an OTN link. A range can describe values available for setting up paths, with technology-specific granularity, ODU-type and priority attributes.

A reported range is not a reservation receipt. Between observation and commit, another transaction may consume a slot. A cached topology view may lag the device. Two controllers may race. One endpoint may accept a label the other rejects. A transaction may be validated and then rolled back. A cross-connect may be programmed but fail to carry a stable signal.

The minimum useful audit trail records the exact topology snapshot and timestamp, device identifiers, endpoints, label restrictions, selected TPN and TS set, transaction identifier, authorization decision, commit result, operational-state readback and the test that observed the service. “The model showed slot 17” records only the early part of that chain.

Flexible bandwidth needs more than one number

ODUflex makes the danger of premature certainty visible. Revision 20 distinguishes six ODUflex forms whose nominal bit rates are calculated differently. The path-bandwidth grouping uses a YANG choice: a generic nominal rate, a constant-bit-rate client, GFP n and k, a FlexE client, a FlexE-aware count or a packet payload rate.

The generic case exists for forward compatibility, especially in transit domains where path setup does not depend on the exact ODUflex type. The draft also says to use it only when needed and to prefer the type-specific case whenever possible in order to simplify interoperability.

That is a subtle design judgment. Abstraction can allow a transit node to proceed without understanding every edge adaptation. The same abstraction discards information that another node may need. A generic nominal rate can be syntactically complete while leaving the actual mapping type outside the common record.

The draft further says that the number of available ODUs is insufficient to infer link bandwidth for ODUflex LSPs. The number of tributary slots and the Optical channel Data Tributary Unit type also affect the calculation. Connectivity-matrix and local-link constraints add underlay context.

An operator who reduces this to one “free ODUflex” counter creates false precision. The counter may omit slot arithmetic, ODTU form, resizing support, endpoint compatibility or the underlay segment that binds them. The model supplies fields to preserve those distinctions. The monitoring system must not throw them away and then blame the model for ambiguity.

Resizable is an identity before it is a procedure

Revision 20 defines separate identities for non-resizable ODUflex and ODUflex-resizable. The latter denotes support for hitless-resizing procedures and can represent capability limits such as a smaller number of resizable LSPs.

Seeing the identity in a schema tells a client how support could be named. Seeing it in advertised capabilities suggests the implementation recognizes that name. Seeing it in configured state records intent. None of those alone proves a live LSP resized without traffic loss.

That outcome requires a particular path, endpoints that support the procedure, coordination across the relevant devices, accepted resource changes, applied state and measurements during the transition. “Hitless” is an operational claim. It should be backed by continuity counters, defect indications, packet or client-layer telemetry and timestamps aligned with the resize.

This separation protects both vendors and operators. A vendor should not have a marketing outcome inferred from a base identity. An operator should not accept an identity string as evidence that a maintenance change preserved service. The schema and the test each do useful work when they remain in their own lanes.

Valid payload, authorized action, applied state

NETCONF and RESTCONF give YANG-defined data a protocol surface. Secure transport and mutual authentication identify the parties under the configured trust system. NACM can restrict which authenticated user may read or change which content or invoke which operation.

These controls also produce distinct receipts. Mutual authentication says who terminated the management session. NACM says whether that identity was authorized for the requested path and operation. A syntactically valid payload says the request conformed to the instantiated schema. A protocol ok response records a server decision within the operation's semantics.

The Network Management Datastore Architecture then keeps intended and operational state conceptually separate. An accepted candidate configuration can still await commit. A committed intended value can still fail to become applied state because of hardware limits, asynchronous provisioning or a later rollback. Operational state can include system-derived values that were never written by the client.

The exact checks depend on the server's datastore model and operation. The general rule does not. Never compress session identity, authorization, schema validation, transaction acceptance, intended state and operational state into one green “configured” light.

For an optical path, there is another boundary after operational state. A control plane can report a cross-connect while the physical layer suffers loss of signal, excessive errors or a client adaptation mismatch. A state leaf is evidence from the implementation. Independent observation is evidence about the service.

Publication does not install the vocabulary

The document's progress through IETF review is meaningful. It indicates working-group and IESG scrutiny, YANG review and preparation for publication. It can give implementers a stable common target.

It cannot compel a device to ship the module. Nor can an RFC number, when assigned, update deployed module sets, migrate vendor extensions or repair a controller's assumptions. Implementers still choose releases. Operators still qualify them. Networks still upgrade on different schedules.

Heng Lu's running-code discipline is useful here because it is not anti-specification. It asks specifications to keep their claims bounded until implementation, validation, deployment and use create additional facts. Revision 20 already follows much of that discipline: it provides a narrow shared vocabulary and explicitly says it has no standalone writable, state or RPC surface.

The operational failure would come from the surrounding organization. A program office may announce “Layer 1 automation is standardized” and erase the remaining dependency chain. A procurement team may tick a YANG-support box without comparing module revisions and deviations. A controller team may assume that a valid identity is implemented at both endpoints. An assurance team may treat intended configuration as delivered service.

None of those mistakes makes the shared model weak. They make the evidence ledger weak.

The receipt chain for an optical change

A reliable record starts with the exact document and module revision. It hashes the module and dependency set, records validator versions and retains deviations. It then captures each device's advertised modules, features and revisions.

For the change itself, it records the authenticated principal, NACM decision, operation, target datastore, payload hash, transaction identifier, validation result and commit response. It records whether the server applied the intended values and when the relevant operational nodes converged.

For resources, it preserves the topology snapshot, ODU type, client signal, slot granularity, TPN, tributary-slot set, ODTU form, label priority, endpoint constraints and competing allocation state. For ODUflex it stores the selected choice and inputs used to calculate nominal rate and slot demand. For resizing it records before/after capacity and procedure support.

Finally, it observes the cross-connect and service outside the request path: alarms, continuity, error counters, optical metrics and client-layer traffic. If the claim is hitless, measurement must cover the transition interval. If the claim is end-to-end, evidence must cover every segment that the end-to-end statement includes.

This chain is longer than “YANG succeeded.” It is also more automatable. Each boundary suggests a machine-readable receipt instead of a meeting-room assertion.

What the sources do not prove

The frozen sources establish the proposed common vocabulary, its dependencies, the standard management architecture and the document's stated limits. They do not prove conformance by a named product, deployment by a named network, successful provisioning of a named path, observed interoperability or measured service quality.

This Article does not rank vendors, infer adoption or reconstruct an outage. It makes a narrower claim: a shared Layer 1 schema can reduce semantic ambiguity, and its success should be celebrated at exactly that layer. Operational authority begins only where an implementation instantiates the model, an authorized transaction changes state, resources are allocated and the running network supplies its own evidence.

Sources