Summary

  • Revision 16 of draft-ietf-rtgwg-qos-model models classifiers, meters, queues, schedulers, policy attachment and operational statistics. A valid policy reference on an interface records intended treatment; it does not prove that hardware instantiated the resources or that packets received the expected service.
  • The operational module also defines a protected action that can reset QoS counters. It is marked nacm:default-deny-all because clearing can disrupt monitoring and hide evidence. A zero value without a bounded observation window and clear history cannot prove that no traffic, congestion, loss or attack occurred.

Zero arrived without its history

Consider an incident review that begins with an apparently clean screen. The intended policy remains attached to the outbound interface. Classifier matches are zero. The meter has no exceeding or violating packets. Queue depth, tail drops and ECN marks all read zero. One interpretation is favorable: the suspected burst never reached this point. Another is procedural: the counters were created after a restart, stopped updating, belonged to a detached policy, or were cleared before the analyst arrived.

The value alone cannot choose among these histories.

Revision 16 of the RTGWG draft is unusually useful because it places the tension inside one model family. The configuration modules define classifiers and actions, combine them into policies and attach a policy to a target interface in one direction. The operational module exposes classifier, meter and queue statistics. It then supplies a clear action that can reset all counters or a selected category, immediately or at a scheduled time.

The draft does not hide the consequence. It marks the action nacm:default-deny-all and says that clearing can disrupt monitoring and potentially hide evidence of anomalies or attacks. That is more than a security footnote. It is an evidence-custody rule.

A policy reference is a mandate, not a packet receipt

The model's basic path is intelligible. A classifier contains filters. Actions can mark, meter, count, discard, queue, schedule or invoke a child policy. Ordered classifiers and their actions form a policy. The qos-target-policy augmentation binds one policy of a particular type to an interface for ingress or egress traffic.

That binding is valuable. It gives automation a stable object to review and lets different management systems refer to the same intended policy. But a reference in configuration is not direct observation that silicon accepted the match, allocated the queue or scheduled a packet.

RFC 8342 provides the useful vocabulary. Intended configuration, applied configuration and operational state are not interchangeable. A successful NETCONF or RESTCONF edit establishes that an authorized management transaction was accepted under the relevant datastore rules. It does not by itself prove that a line card had enough queue resources, that vendor-specific rounding preserved the requested rate, or that a later packet matched the branch leadership had in mind.

The draft also permits vendor-specific policy types, identities and augmentations. That extensibility is necessary because devices expose different capabilities. It also means common syntax cannot silently be promoted into cross-vendor behavioral equivalence. Two devices may accept similarly shaped policies while mapping them to different hardware granularities or unsupported actions.

Hierarchical policies illustrate the same boundary. The module forbids direct self-reference and requires implementations to reject cyclic chains. Passing that structural test is important. It proves neither resource feasibility nor the service result of an acyclic chain.

Counters are local witnesses with bounded authority

The operational module exposes a rich set of receipts. Classifier statistics include matched packets, bytes and average rate. Meter statistics distinguish conforming, exceeding and violating traffic, plus drops. Queue statistics include current, average and peak size, output counts, tail drops, RED or WRED behavior and ECN markings.

These values can answer concrete questions. Did packets reach this classifier? Did the meter place them outside the committed profile? Did this queue build or overflow? At which interface and direction did the device report that observation?

They cannot answer every later question. A classifier match does not prove the packet entered the expected hardware queue. A queue output count does not prove the next hop carried it. A local ECN mark does not prove an endpoint reacted. A period with no drops does not establish an application's latency or a contractual SLA. Each counter belongs to the measurement point that owns it.

Named statistics introduce another deliberate tradeoff. The model permits a name to aggregate counts across selected classifiers, meters or queues, or to retain them separately. Aggregation helps a dashboard show one service total. It can also erase which component contributed the event. Before using an aggregate for accountability, leadership needs the non-aggregated evidence or an independently reproducible mapping from the total back to its contributors.

The evidence chain should therefore remain staged:

  1. an accountable owner approves the service objective and target traffic;
  2. a reviewed policy revision records intended classifiers and actions;
  3. authorized management writes and datastore confirmation show acceptance;
  4. device state proves classifier, meter, queue and scheduler realization;
  5. known test traffic moves the expected counters in a bounded window;
  6. local queue, drop, ECN and rate evidence describes treatment at that interface;
  7. downstream measurement establishes path and application outcome; and
  8. every counter clear has an attributable before-and-after receipt stored away from the device.

No earlier receipt should inherit the authority of the next one.

Clearing is an evidence mutation, even when authorized

NACM's default denial is a good starting control. A user cannot invoke the clear action unless an explicit rule allows it. Mutual authentication and secure NETCONF or RESTCONF transport can establish which management identity sent the request and protect the command in transit.

Those controls answer who was permitted to ask. They do not answer whether the evidence should have been destroyed at that moment. Authorization is not justification.

A defensible clear record needs the requester, approver, reason, interface, direction, policy, counter category, requested start time, actual completion time, pre-clear snapshot, post-clear baseline and the external location holding the receipt. A scheduled clear needs cancellation and clock evidence as well. If the same device both resets the counters and keeps the only audit entry, failure or compromise can erase the observation and its explanation together.

This is why configuration, observation and clearing should be separate roles. The engineer who changes a meter rate need not automatically receive the ability to erase the meter's history. The analyst who reads congestion state need not be able to rewrite the policy. The person responding to an incident should not discover after the fact that a routine capacity task silently reset the relevant window.

A counter reset is not always wrong. It can establish a fresh test baseline, manage finite telemetry, or delimit a maintenance window. The mistake is allowing the new zero to masquerade as a statement about the time before the reset.

Observability itself exposes the policy

Protecting the operational data cannot mean publishing it indiscriminately. The draft lists the disclosure paths plainly. Classifier filters can expose prefixes, ports, protocols and DSCP values that reveal what the operator considers important. Actions reveal where traffic is marked, shaped or dropped. Meter and queue parameters expose rate and capacity choices.

Live counters add another surface. An attacker able to inject probes and read classifier counts may infer which rule matched. Meter colors can reveal policing thresholds. Queue depth, RED drops and ECN marks can disclose congestion timing and capacity. An operator-assigned policy name may contain a customer or topology label.

Read authority, write authority and clear authority therefore require different least-privilege decisions. Blocking all observation would make the configured policy unverifiable. Granting broad observation can turn the management plane into a policy oracle. The answer is scoped access, independent audit and retention proportionate to the operational consequence.

The same separation applies to DiffServ itself. An unauthorized DSCP mark can steal a higher class of service; a malicious discard or meter change can deny service. Even a legitimate mark remains per-hop evidence. A downstream boundary may remark it, and an endpoint may still fail. Local policy is not an end-to-end promise.

A validated draft is still work in progress

The exact text is revision 16, dated 25 September 2026, and expires 29 March 2027. Datatracker identifies it as an active RTGWG Working Group document in I-D Exists. Its header proposes Standards Track, while the Datatracker intended-status field is empty. Neither surface is an RFC approval.

Datatracker's YANG validation reports zero errors and six warnings for the extracted modules. That is evidence about machine validation of this revision. It is not evidence of vendor implementation, resource realization, interoperability, production deployment or a measured service outcome. Placeholder RFC references also remain in the draft.

The mature claim is narrower. The work offers a common vocabulary for QoS intent and local operational evidence, while its clear action reveals the governance condition for interpreting that evidence honestly.

Sources