Summary

  • draft-dikshit-netmod-comparability-scope-extension-00 proposes four ordered declarations—node-local, domain-local, controller-scoped and global—so a schema-aware consumer can reject obviously invalid comparisons or aggregations.
  • The narrower declaration governs when two values differ, but the declaration is not evidence that a domain identifier is correct, controller custody is continuous, metric semantics match or automated remediation is safe.

A counter can be perfectly encoded and still be unsafe to add to another counter. One may reset per line card while the other survives a restart. One may describe packets before filtering and the other packets after filtering. Two values called “drops” may use different observation points, populations or time windows. Aggregation converts those differences into a clean number, then hides the mistake that created it.

Revision -00 of the comparability-scope draft attacks a narrow part of that problem. It proposes the YANG extension csc:comparability-scope for metric-producing nodes. The value sits in the model and tells a consumer how widely the author believes the measurement may be compared. Because the annotation is machine-readable, a validator can stop some bad sums before a dashboard, alert or control loop sees them.

The document's status matters. The IETF Datatracker lists it as an active individual Internet-Draft and explicitly says that it is not endorsed by the IETF and has no formal standing. Its structured record currently assigns neither an RFC stream nor an intended RFC status. The -00 text nevertheless carries “Intended status: Standards Track” in its own header. That is an author's proposed destination, not evidence of working-group adoption, IETF consensus or imminent publication. The full module text, detailed domain-id-ref design and a reference implementation and corpus remain future work.

Four scopes, one ordering

The proposal orders four scopes from narrow to broad. node-local permits comparison only for values produced by the same originating node. domain-local widens the boundary to one declared administrative or protocol domain and depends on a companion domain identifier. controller-scoped permits comparison across nodes managed by the same controller while the assignment record is retained; the claim does not cross a change of controller. global asserts that the metric remains comparable across nodes, domains and controller boundaries for the lifetime the module states.

This is a lattice with an important asymmetry: broader is not automatically better. If one value is global and another is node-local, the narrower boundary controls. The pair is usable only when the read context satisfies node-local; the global claim cannot promote its partner. If two domain-local values point to different domain identifiers, the proposed checks reject the pair. Two node-local values from different nodes are rejected unconditionally.

That negative power is valuable. It moves one class of error from a late operational investigation into a pre-aggregation admission decision. It also gives model authors a reviewable vocabulary instead of leaving scope in a prose description that collectors may ignore.

A rejection is not an attestation

The validator sees declarations and referenced identifiers. It does not observe the world that made them. A module author can mark a value global without testing different implementations. An inventory system can attach the wrong domain identifier. Controller A can hand a node to Controller B while a historical record remains stale. A vendor can change normalization or reset behavior without changing the leaf name. Static acceptance cannot distinguish any of those cases.

Even the strongest-sounding value, global, is only a claim with the widest evidence burden. To rely on it, an operator needs a metric contract: unit and scaling, sampling window, observation point, reset and wrap behavior, filters, missing-data treatment, population, normalization and module-stated lifetime. RFC 8911 and RFC 8912 illustrate why metric identifiers and registry metadata should bind to stable specifications. They make identity more disciplined; they do not measure whether every producer follows the specification.

The same distinction appears in network state. RFC 8342 separates intended from operational state because a modeled instruction and observed reality are different things. A scope annotation belongs to the modeled side of that divide. Runtime telemetry must still show that domain membership and controller custody were correct during the measurement interval and that delivery did not create a false comparison through gaps or skew.

The companion draft is broader—and still not the proof

The related individual draft on telemetry-identifier scoping, currently revision -01, discusses semantic scope, VRFs, address families, observation domains, normalization, aggregation and time. That is a broader requirements surface. The comparability-scope -00 is more surgical: it proposes a value-level YANG extension and static rejection rules.

Keeping those documents distinct avoids two errors. The extension is not a complete telemetry identity architecture. Conversely, a rich identity tuple does not automatically establish comparability. Identity tells an analyst what was measured; comparability needs evidence that two measurements can answer the same question under the proposed operation.

The target draft cites revision 15 of the routing-area QoS model as a motivating example. The citation helps show why counter scope matters. It does not demonstrate that the extension is implemented by that model, deployed by vendors or validated in operations.

Automation raises the burden again

A bad chart wastes attention. A bad aggregate that drives remediation can change the network. Suppose a controller sums “drop” counters across domains after accepting a global declaration. The total crosses a threshold, so automation shifts traffic, changes policy or restarts a service. If one source used a different observation point, the remediation is acting on a manufactured incident.

The scope extension can reject a combination already known to violate the declared boundary. It cannot authorize the action that follows. Safe automation needs independent controls: a pinned metric specification, verified domain and controller history, continuity checks, cross-source semantic tests, a bounded blast radius, canary execution, rollback evidence and an accountable owner. A scope mismatch should fail closed before aggregation; a scope match should open the next evidence gate, not close the decision.

Sources

Primary draft and status: comparability-scope extension revision 00; current Datatracker record; revision history; I-D announcement.

Normative context and adjacent work: YANG 1.1, RFC 7950; Network Management Datastore Architecture, RFC 8342; Performance Metrics Registry Information Model, RFC 8911; Performance Metrics Registry, RFC 8912; telemetry identifier scoping revision 01; routing-area QoS model revision 15.