Summary

  • Revision 01 adds a hierarchical, read-only description of which SCHC rules and fields may be changed; it does not turn that description into the identity of the caller entitled to change them.
  • A defensible mutation requires both management-plane authorization and the complete SCHC parent-to-child permission path, plus revision control, validation, activation evidence and a rollback receipt.

The request arrives over an authenticated management channel. Its operator is a member of a group allowed to update configuration. The target field also reports change-tv. Two green signals appear in the workflow, and an automated controller concludes that the edit is authorized.

What has actually been proven? The first signal says this session may perform a class of management operation. The second says this Field Descriptor is, in principle, allowed to accept a Target Value change. Neither signal alone proves that this principal may change this field in this device's Context at this moment. Even together they do not prove that the expected prior rule is still present, that the peer can activate the new meaning safely, or that the change can be reversed.

This is a reconstructed control-room scenario, not a reported incident. But it exposes the exact design question raised by draft-ietf-schc-access-control-01, submitted on 29 September 2026: when a specification labels an object mutable, where does the authority to mutate it come from?

The compression saving is a governance dependency

SCHC works by keeping shared knowledge out of each packet. Under RFC 8724, a RuleID can stand in for known header values and compression behavior because the compressor and decompressor share a Context. A compression Rule contains Field Descriptors: identifiers, lengths, positions, directions, Target Values, Matching Operators and Compression/Decompression Actions.

That efficiency makes rule integrity operationally consequential. If one side interprets a RuleID through a different Context, the compressed bits do not carry enough information to repair the disagreement. RFC 9363's security section is unusually direct: a malicious rule change can alter an application IPv6 address, block communication or support eavesdropping. It says a device must be allowed to modify only its own rules and the requester identity must be validated.

The new draft addresses the other half of that problem. Generic access to a YANG subtree is too coarse when one entry's Uri-Path Target Value may change but the application prefix in the same rule must remain fixed. The important unit is not merely “write this module.” It is “perform this class of mutation at this exact level.”

A three-level mutability ceiling

Revision 01 augments the RFC 9363 YANG model with read-only leaves. ac-modify-set-of-rules sits at the rule level. Its values distinguish no change, modification of an existing element, and adding or removing elements. ac-modify-compression-rule governs Field Descriptions inside a compression rule. ac-modify-field narrows the permitted change to no change, Target Value only, or Target Value together with Matching Operator and Compression/Decompression Action.

The hierarchy matters. The compression-rule leaf is active only if its parent allows modification; the field leaf is active only if both parents do. A permissive child cannot tunnel through a restrictive parent. If an access leaf is absent, the draft says the information cannot be modified.

These leaves are config false. They are reported state, not knobs the remote editor writes to grant itself power. That is a strong design instinct: the subject of a permission should not be able to manufacture the permission while exercising it.

But the data still answers a bounded question. It describes the mutation shape that the rule model will tolerate. It does not contain a username, device owner, group, credential, session, policy version or delegation. “Change the Target Value” is a verb and object. It is not a principal.

The actor lives in another layer

The draft does not ignore this. Its YANG Access Control section cites NACM and says NACM lets users or groups perform specific actions. RFC 8341 connects an authenticated session to a username and groups, evaluates protocol-operation and data-node rules, and returns access-denied when the request is not permitted. It also requires one stable set of access rules for the processing of an entire message.

That is the actor/request layer. NETCONF requires authenticated connections and can expose validation, candidate datastores, locks and rollback-on-error as capabilities. RESTCONF maps authorized HTTP edits into YANG data and offers entity tags and If-Match for collision detection. CORECONF brings a compact CoAP/YANG transaction to constrained devices and requires unauthorized reads and writes to be prevented, pointing deployments toward DTLS, OSCORE and authorization mechanisms such as ACE OAuth.

None of this makes the SCHC leaves redundant. NACM's CRUDX model can say that a group may update a data node. It does not naturally express why the Target Value of one Uri-Path descriptor is mutable while the application prefix beside it is not. Conversely, change-tv cannot establish which authenticated session is in that group.

The safe equation is conjunctive:

This principal may perform this request and this exact SCHC element may undergo this kind of mutation.

If an implementation treats either side as a substitute for the other, authority expands by accident. A broad management role swallows the field boundary, or a permissive field label becomes a bearer token for anyone who can reach the endpoint.

The unanswered lifecycle questions

Authorization is only the first gate. Revision 01 does not yet say who provisions the read-only leaves, how they are derived, how a right is revoked, or how an in-flight request is bound to the right observed before the edit. It does not define a principal-to-Context ownership binding. It does not specify compare-and-swap, locks, multi-field atomicity, collision resolution, activation coordination, peer confirmation, audit record or rollback.

That is not evidence that SCHC deployments cannot provide these functions. NETCONF and RESTCONF already supply several useful transaction tools, and implementations can compose them with operational controls. It is evidence that the current draft's access leaves are not a complete change-governance protocol.

The distinction is especially important for shared Context. A datastore can accept a syntactically valid edit while the corresponding peer still holds the previous Rule. “Write succeeded” describes a management transaction. It does not yet describe a safe protocol transition. Leaders need an activation boundary: which rule revision became authoritative, for which peers, at what time, with what compatibility result?

RFC 8040's entity tags offer one practical pattern. A controller can retrieve the current representation, send an If-Match precondition and reject an edit when another writer has changed the resource. NETCONF locking and candidate configuration offer a different pattern. Yet even perfect collision control does not answer when both SCHC endpoints should use the new meaning. Transaction integrity and protocol synchronization touch each other but are not identical.

Read the work-in-progress markers literally

Revision 01 is an active Working Group Internet-Draft with a Standards Track header, not an RFC. Its incompleteness is visible. The Terminology section contains ToDo. Security Considerations and IANA Considerations are TBD. The embedded YANG module carries a 2023 revision and text about compound acknowledgements and “RFC YYYY” that belongs to another subject. The field-access enumeration descriptions still read “Reserved slot number.”

Those artifacts should neither be mocked nor silently repaired by a reader. They are change-risk indicators. An implementation can experiment with the current hierarchy, but procurement, automation and compliance should not treat names, semantics or security composition as frozen.

The July 2026 SCHC architecture draft reinforces that caution. It calls Context integrity critical, recommends audit and restoration of a known-good Context, and says lifecycle and management sections remain to be developed. No frozen source establishes production adoption, interoperability results, incident frequency or performance.

Build a receipt that can survive disagreement

A consequential change should retain at least:

  1. authenticated principal, groups, session and transport protection;
  2. protocol operation, target Context, Set of Rules and RuleID;
  3. the prior rule revision or entity tag and the exact before/after values;
  4. all applicable SCHC permission leaves, including restrictive parents;
  5. the NACM or equivalent policy revision used for the decision;
  6. validation, transaction and collision outcome;
  7. activation time, affected peers and compatibility evidence;
  8. result observation, owner, rollback point and rollback test.

This is the engineering form of narrow authority. The management layer may authenticate and authorize the actor. The SCHC model may constrain the object. The transaction layer may make the edit coherent. The protocol operator still owns activation and operational consequence. No layer should borrow a mandate from another merely because all appear in one API call.

Sources