Summary

  • Revision 10 of the OPSAWG draft on scheduled OAM tests says a later edit to a unitary-test template should not silently alter an already configured diagnostic sequence. Its sequence model now embeds a list of unitary tests where revision 09 used test references, alongside changes to module and status names.
  • The same revision says the user controls test order and that order can affect reported results. Yet the new unitary-test list omits the earlier ordered-by user YANG statement. Under RFC 7950, an unmarked list defaults to system order. This is a discrepancy in a working draft, not evidence that a deployed system ran tests incorrectly.

Imagine a scheduled investigation that first checks reachability, then measures delay, then probes a path after a fault has been isolated. A result without the execution order cannot fully explain what was measured. That is why the latest version of draft-ietf-opsawg-scheduling-oam-tests matters beyond its catalogue of YANG nodes. The draft proposes two models for management systems and controllers to schedule individual OAM tests and sequences of them. It is not a command sent to every network node and is not yet an RFC.

The change from revision 09 to 10 recognizes one kind of diagnostic drift. The new text says each configured sequence is local configuration: subsequent changes to a unitary-test template should not silently rewrite it. The YANG sequence list now includes a unitary-test entry using the unitary-test grouping rather than the old test-ref list. The intent is intelligible. A stored investigation should not unexpectedly inherit tomorrow's template edits and then be compared with yesterday's run as though the procedure were identical. The draft does not, however, demonstrate an implementation that preserves such a snapshot.

The second boundary is less settled. Section 4.2 still describes an ordered collection and says the user should have full control over the order because changing it can change the reporting output. It even says an ordered-by user YANG statement needs to be specified. The revision-09 test-ref list carried that statement. In revision 10, the new unitary-test list has no ordered-by statement; its description says both user and system order are supported. RFC 7950 is unambiguous about the default: without the statement, the model describes a system-ordered list. Prose expressing an operator's intention does not supply a missing YANG declaration.

This does not prove an outage, a vulnerability or noncompliance by any product. It identifies a review question in a changing Internet-Draft. If a test sequence is meant to be operator ordered, what schema entry preserves that order when configuration is written, read back and executed? If the group instead wants system order, which result claims should stop implying that a user-specified sequence was followed? The answer belongs to the draft authors and working group, not to a reporter pretending the choice has been made.

There are other changes in version 10: a more specific priority-conflict identity and a node identifier that can use a hostname or a network-topology node ID. Those may help explain failures and select targets, but neither repairs the missing ordering declaration. Nor should a statement that templates stay stable be mistaken for proof that a particular run's ordered procedure was recorded.

The contrast with the IETF's common scheduling model is important. RFC 9922 supplies time and recurrence groupings reused in this draft. A previous BTW analysis asked whether a still-valid schedule proves today's authorization to perform its action. This story asks a narrower, separate question: within an authorized occurrence, can a later reader reconstruct which tests ran in which order? Time validity, permission and diagnostic reproducibility are different pieces of evidence.

Sources