Summary
- RFC 9899 lets operators change a reusable defined set without redefining the parent ACL rule, so an unchanged rule is not a frozen record of its effective matches.
- A defensible history joins the authenticated edit, exact resolved membership, per-device intended and operational state, attachment point, bounded match telemetry and downstream result.
The post-incident comparison looked reassuring. The ACL rule in the repository was identical before and after the event. Its name had not changed. Its match clause still pointed to the same prefix set, and its action was still the same. On that evidence, the team declared the filtering policy stable.
The conclusion failed one level below the rule. Two addresses had been added to the referenced set during the rollout window. The parent object never needed to change. One device had received the new membership, another still held the old membership, and the available counter export did not preserve which resolved set each box had used when the traffic arrived.
No component had necessarily malfunctioned. The audit had simply treated a reference as if it were its referent.
RFC 9899 extends the YANG model for Access Control Lists defined by RFC 8519. The base model describes an ACL as an ordered set of Access Control Entries. Each ACE combines match criteria with actions such as accepting, dropping, rejecting, counting or policing traffic. The rule becomes relevant to traffic after the ACL is applied to an attachment point. The base standard models interface attachment and allows implementations to augment other attachment types.
That sequence already contains distinct facts. A model may describe a rule. A device may advertise support for the match type. A configuration transaction may store the rule. The ACL may be attached to an interface. The device may apply it to forwarding. A packet may match one ACE. The configured action may then affect that packet. An application may or may not observe a useful result. Compressing those steps into “the ACL was there” removes the very evidence an incident review needs.
RFC 9899 adds a particularly consequential form of indirection. It defines reusable sets for IPv4 and IPv6 prefixes, ports, protocols and ICMP types. It also defines aliases that may combine parameters such as a prefix, protocol, port or VLAN. Instead of repeating literals inside every ACE, a rule can refer to a user-named object maintained elsewhere.
The operational advantage is obvious. A security team can maintain one deny-list or customer accept-list and let many rules reuse it. RFC 9899 states the point directly: user-named lists decouple creation of the rule from management of the sets, so members can be added or removed without redefining the parent rule. It also allows ACLs and sets to exist at a network or administrative-domain level and be associated with devices.
That same advantage changes the evidence key. A rule name plus a timestamp is no longer enough. A faithful record needs the exact membership of every referenced set and alias at that timestamp, the module revision that interpreted it, and the resolution used for each target device. If a set is reused by forty rules and twenty devices, one small membership edit may have a much larger semantic blast radius than its diff suggests.
The version question is not cosmetic. Suppose an ACE refers to a prefix set called by a durable internal name. At 10:00, the set contains ten prefixes. At 10:05, an authenticated operator replaces one member. At 10:07, the management controller reports success. At 10:09, one device has applied the new object while another remains on the old operational state. At 10:10, a packet arrives. The parent ACE is identical at every point. Asking only for the ACE revision cannot answer what either device matched.
RFC 8342 supplies the datastore discipline. <running> is not the same concept as <intended>. Intended configuration is the configuration after transformations that the system attempts to apply. The RFC then relates <intended> to the config true portion of <operational> so a client can assess how much intended configuration is currently in use. It also recognizes inactive data, remnant configuration, propagation delay and the possibility that configuration is not immediately or successfully applied.
For an ACL audit, that means the evidence should preserve both the abstract object and the resolved device state. Template expansion, inherited defaults, inactive branches, capability filtering and local augmentation can all change what reaches the operational plane. A central controller's desired state is important. It is not a substitute for the device-specific state that was actually active.
Management acknowledgements have a similarly bounded jurisdiction. RFC 6241 defines NETCONF <ok> as the reply when no errors or warnings occurred during processing of an RPC and no data is returned. RFC 8040 uses HTTP success responses such as 201 or 204 for RESTCONF resource creation or modification. These are useful transaction records. Neither response is defined as a packet-path receipt, an ACE match, or evidence that the protected service reached its objective.
Access to the management plane must also remain separate from the policy being managed. RFC 8341 defines NACM permissions for reading, writing and executing YANG-managed content and operations. RFC 9899 marks sensitive defined sets with nacm:default-deny-write and warns that unauthorized edits could permit traffic that should be denied or deny traffic that should be permitted. NACM can help prove whether an authenticated management user was allowed to make an edit. It does not prove that a later packet was filtered.
Runtime counters narrow the gap without closing every question. RFC 8519 models read-only matched-packet and matched-octet counters for ACEs and, when supported, interface attachment points. A counter increase is stronger enforcement evidence than a repository diff: the reporting device attributed traffic to that ACE. Yet the counter still needs scope, reset history, collection support, clock quality and the resolved rule membership. It normally does not preserve the packet, name a subscriber or prove an end-to-end application result.
A zero counter is especially easy to overread. It can mean no match. It can also mean the feature was unsupported, the ACL was attached elsewhere, the counter reset, the collection interval missed the event, the wrong device was queried or the effective set never contained the address. Negative evidence is useful only when the observation surface and failure modes are recorded.
RFC 9899 expands match expressiveness beyond named sets. It adds optional matching for payload patterns, MPLS fields, VLANs, I-SIDs, fragments and TCP flags, together with a rate-limit action. A payload pattern is expressed by offset, length, binary pattern and operator. The RFC notes that pattern filtering is deterministic for unencrypted data, while usefulness on encrypted traffic depends on an unvarying visible pattern. A schema can express a condition perfectly even when the traffic no longer exposes the bytes required to evaluate it usefully.
RFC 7950 makes YANG a disciplined language for configuration, state data, RPCs and notifications. That precision matters because it prevents systems from disagreeing silently about shape. It does not abolish the distinction between a valid representation and a forwarding effect. Schema validity answers whether the object conforms to the model. Operational readback and traffic evidence answer later questions.
The minimum defensible record therefore resembles a chain, not a screenshot. Keep the authenticated actor and session, NACM decision, exact request body, target datastore and response. Freeze the parent ACL, every ACE, every referenced set and alias, and the relevant module revisions. Record device capability advertisement, association, attachment point, intended state and operational state with clocks. Add counter or log evidence with reset history. Preserve packet or flow evidence when the incident question requires it. Let the downstream service record its own result.
Rollback must use the same resolved unit. Restoring the parent rule while leaving the modified set in place is not a rollback. Reverting a central object without confirming operational state on every associated device is not a completed rollback. A last-known-good package should include the reference graph, member values, module revisions, target list and verification probes—not merely the top-level ACL name.
Heng Lu's Running-Code Primacy is useful here as a restraint on jurisdiction. The configuration service can testify to the transaction it processed. The device can testify to the operational state and counters it exposed. The packet sensor can testify to observed traffic. The application can testify to its committed result. Running code does not make one of those witnesses sovereign over the others.
Reality Layers explains why the unchanged parent rule can become a dangerous symbol: its visual stability encourages people to ignore the mutable layer it references. Data Sovereignty separates technical control from broader authority claims. Minimum Initial Specification supports a thin common model while leaving set ownership, rollout waves, attachment, retention and rollback with operators who can observe their own systems.
The executive question is not “was the ACL unchanged?” It is “what fully resolved policy did this device run at that time, what traffic did it say matched, and which independent record proves what happened next?”
Sources
- https://www.rfc-editor.org/rfc/rfc9899.html
- https://www.rfc-editor.org/rfc/rfc8519.html
- https://www.rfc-editor.org/rfc/rfc8342.html
- https://www.rfc-editor.org/rfc/rfc8341.html
- https://www.rfc-editor.org/rfc/rfc6241.html
- https://www.rfc-editor.org/rfc/rfc8040.html
- https://www.rfc-editor.org/rfc/rfc7950.html
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/on-data-sovereignty-technical-vs-practical-realities/
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance

