Early Review of draft-ietf-opsawg-scheduling-oam-tests-09
review-ietf-opsawg-scheduling-oam-tests-09-yangdoctors-early-busi-2026-09-15-00

The YANG data models defined in this document rely on the use of schema mount,
as defined in RFC8528, so some of my comments may be due to my lack of detailed
understanding of how schema mount works. An additional review from some Yang
Doctor who is very familiar with schema mount would be helpful.

Nevertheless, the document looks on the right track but I think some more work
is needed to clarify some aspects of the model and of its design.

Minor comments
==============

1) Introduction and/or Section 2

Following the definitions in RFC8309 and RFC8969, I understand that this YANG
data model can be defined as "network model" while the other YANG data models
are "device models". I would suggest stating this explicitly.

2) Introduction

I am not sure how much RFC8531, RFC8532 and RFC8533 have been actually
implemented/deployed or extended with technology-specific augmentations, but I
would suggest aligning the examples to those provided by these RFCs.

OLD

   o [RFC8531] "A YANG Data Model for Connection Oriented OAM": defines
   a YANG data model for connection-oriented OAM protocols.  The main
   aim of this document is to define a generic YANG data model that can
   be used to configure, control, and monitor connection-oriented OAM
   protocols such as MPLS-TP OAM [RFC6371], TRILL OAM [RFC7174], PBB-TE
   OAM [IEEE-8021ag], and T-MPLS [ITU-T-G81131] OAM.

   o [RFC8532] "A YANG Data Model for Connectionless OAM Protocols":
   provides a generic YANG data model that can be used to configure,
   control, and monitor connectionless OAM protocols such as BFD
   (Bidirectional Forwarding Detection) [RFC5880], LBM (Loopback
   Messaging)[IEEE-8021ag], and VCCV (Virtual Circuit Connectivity
   Verification)[RFC5085].

   o [RFC8533] "A YANG Data Model for Retrieval Methods for the
   Management of OAM Protocols that Use Connectionless Communications":
   provides a YANG data model that can be used to retrieve information
   related to OAM protocols such as BFD (Bidirectional Forwarding
   Detection)[RFC5880], LBM (Loopback Messaging) [IEEE-8021ag], and VCCV
   (Virtual Circuit Connectivity Verification) [RFC5085].

NEW

   o [RFC8531] "A YANG Data Model for Connection Oriented OAM": defines
   a YANG data model for connection-oriented OAM protocols.  The main
   aim of this document is to define a generic YANG data model that can
   be used to configure, control, and monitor connection-oriented OAM
   protocols such as MPLS-TP OAM [RFC6371] and TRILL OAM [RFC7174].

   o [RFC8532] "A YANG Data Model for Connectionless OAM Protocols":
   provides a generic YANG data model that can be used to configure,
   control, and monitor connectionless OAM protocols such as BFD
   (Bidirectional Forwarding Detection) [RFC5880], ICMP Ping [RFC792]
   [RFC4443], and LSP Ping [RFC8029].

   o [RFC8533] "A YANG Data Model for Retrieval Methods for the
   Management of OAM Protocols that Use Connectionless Communications":
   provides a YANG data model that can be used to retrieve information
   related to OAM protocols such as BFD (Bidirectional Forwarding
   Detection) [RFC5880], ICMP Ping [RFC792] [RFC4443], and LSP Ping
   [RFC8029].

3) Section 1.1

The definition of the OAM unitary test and the OAM test sequence is not fully
consistent.

For example, in the current definition, it seems that the time constraints and
the number of repetitions apply only to the OAM test sequence but the
"ietf-oam-unitary-test" YANG module defines them also for the OAM unitary tests.

OLD

   o OAM Unitary Test: A set of parameters that define a type of OAM
   test to be invoked.  As an example, it includes the test type,
   configuration parameters, and target results.

   o OAM Test Sequence: A set of OAM Unitary Tests that are run based on
   a set of time constraints, number of repetitions, order, and
   reporting outputs.

NEW

   o OAM Unitary Test: A single OAM test which is executed at each scheduled
   time.

   o OAM Test Sequence: A set of OAM Unitary Tests that are executed on a
   specified order at each scheduled time.

4) Section 2 - Figure 1

Since the YANG data model defined in this document is re-using through schema
mounting the OAM device models (e.g., RFC8531), I would mention them in this
Figure

5) Section 4.1

The description is mixing the name of the grouping in RFC9922 and the name of
the attributes/containers in the ietf-oam-unitary-test YANG module/tree, making
difficult for a reader to match the description with the YANG tree in Figure 1
below. I would suggest some editorial clean-up

6) Section 4.1 - planned and configured states

The description of these two states applies only to the case where the OAM
unitary test is configured on a single network element but in the YANG data
model the "ne-config" is a list so the OAM unitary test can be configured on
multiple network elements

OLD

   *  "planned": The initial state where the test is planned by the
      management and hasn't been applied to the network element.

   *  "configured": The state where the test is being configured.  This
      state is triggered when the planned test configuration is applied
      to the network element.

NEW

   *  "planned": The initial state where the test is planned by the
      management and hasn't been applied to any the network element.

   *  "configured": The state where the test is being configured.  This
      state is triggered when the planned test configuration is applied
      to one more network elements.

7) Section 4.1 - stop state

It is not possible to manually stop a test using the YANG data model defined in
this document. I assume that the intention is to capture the case where the
test is stopped in the network element through mechanisms which are outside the
scope of this document

OLD

   *  "stop": The state where the test is manually stopped.  This state
      is triggered when the test is manually interrupted.  A manual stop
      is not a successful completion and is not an execution error; the
      next cycle, if any, starts from "planned".

NEW

   *  "stop": The state where the test is manually stopped.  This state
      is triggered when the test is manually interrupted, using
      mechanisms which are outside the scope of this document.  A manual
      stop is not a successful completion and is not an execution error;
      the next cycle, if any, starts from "planned".

8) Section 4.2 - last sentence before Figure 4

My understanding of the "ordered-by user" for the test-ref list is that the OAM
unitary tests are run one after the other following the order specified by the
user. Therefore, it is not clear to me how the user can configure two or more
tests to run concurrently

9) Section 4.2

The description of the state machine in Figure 5 is a bit confusing: some
states seem referring to the OAM test unit (e.g., on-going) while other states
seems referring to the whole set of OAM test units in the sequence (e.g.,
"success").

The YANG data model defines a single state for the whole sequence so it is not
clear for example which status can be reported when one OAM test unit is
on-going and another is in error or where multiple OAM test units are in error
with different error conditions

Note: the comments 6), 7) and 8) are also applicable to the description of the
states in section 4.2

10) Section 5.1 - YANG module (L76-L116)

Why the unitary test status is defined as a set of derived identities and not
as an enumeration?

From the description in section 4.1, it seems they are not intended to be
extended by other modules

From the YANG code it seems that the reason could be to allow defining a
hierarchy of derived identities for the error state to report also the type of
error. If this is the case it is better to be explicit in the text of section
4.1 as well as in the definition of the base identity to make sure that the
base identity is not extended by other modules.

Another approach could be to redefine this as an enumeration and to define an
additional data node (e.g., error-type) to report the error condition: this
data node can be constrained with a when statement to exist if and only if the
test status is "error"

11) Section 5.1 - YANG module (L76-L116)

The descriptions are self-referencing. I would suggest to add a reference to
section 4.1 (or better move the state machine definition to a new section 4.1.1
and reference it)

12) Section 5.1 - YANG module (L118-L128)

The descriptions are self-referencing

However, the error conditions "resource-contention" and "priority" are
mentioned but not defined in section 4.1.

I assume that the "resource-contention" represents a case where the test failed
because there were no resources available on the network elements to run the
test at the scheduled time. It would be worthwhile adding some description.

I do not know what error condition could the "priority" value represent.

I would suggest to either add some text (and a proper reference in the YANG
module) in section 4.1 or to provide more detailed explanation in the YANG
module to define the different error conditions.

Moreover, looking at the YANG module, the error conditions are defined as
identities: are you assuming that they can be extended by OAM-specific or
vendor-specific error conditions to be defined in other models?

IMHO, it seems valuable to allow other YANG data models to define new
identities for e.g., OAM test specific error conditions.

I would mention this option explicitly.

13) Section 5.1 - YANG module (L128)

Why "basic-test-type"?

It give the impression that some enhanced test types would be defined

What about "unitary-test-type" or just "test-type"?

14) Section 5.1 - YANG module (L162-169)

RFC9228 is "Delivered-To Email Header Field" and it does not define any YANG
data model for LSP Ping

I was not able to find any RFC which defines a YANG data model for LSP Ping

Please consider aligning the first paragraph in section 5.1 (which also
references RFC9228) based on the resolution of this comment

15) Section 5.1 - YANG module (L174-175)

RFC9107 is "BGP Optimal Route Reflection (BGP ORR)" and it does not define any
YANG data model for BFD

I think that the RFC which defines the YANG data model for BFD is RFC9314

OLD

       reference
        "RFC 9107: BFD (Bidirectional Forwarding Detection) YANG Model";

NEW

       reference
        "RFC 9107: YANG Data Model for Bidirectional Forwarding
                   Detection (BFD)";

Please consider aligning the first paragraph in section 5.1 (which also
references RFC9107) based on the resolution of this comment

16) Section 5.1 - YANG module (L177-180)

The grouping oam-unitary-test is used only once in this YANG module but it is
also re-used in the "ietf-oam-test-sequence" YANG module

I would suggest mentioning explicitly in the description statement that this
grouping is intended to be reusable from other YANG data models

OLD

  grouping oam-unitary-test {
    description
       "Specifies a grouping for OAM unitary test for network
        diagnosis procedures.";

NEW

  grouping oam-unitary-test {
    description
       "Specifies a grouping for OAM unitary test for network
        diagnosis procedures.

        This grouping has been defined to allow being imported and
        reused by other YANG modules.";

17) Section 5.1 - YANG module (L193)

I am not sure that the inet:host data type is applicable to any technology
(e.g., optical technology)

Since this YANG data model is a network model, what about re-using the node-id
data type defined in RFC8345?

18) Section 5.1 - YANG module (L201-208 and L217-232)

Maybe this is due to my lack of detailed understanding of how schema mount
works but the description of the managed data node and of the root mount point
is not quite clear.

Since this issue is related to the design choice to use schema mount which is
applicable to both YANG data models, I would suggest more explanation is
provided in section 4 (or in section 6) and an example is also provided in an
appendix.

19) Section 5.1 - YANG module (L209-216)

Why the test-type is different for different network elements involved in the
same test?

20) Section 5.2 - YANG module (L61-105)

Why the sequence test status is defined as a set of derived identities and not
as an enumeration?

From the description in section 4.2, it seems they are not intended to be
extended by other modules

From the YANG code it seems that the reason could be to allow defining a
hierarchy of derived identities for the error state to report also the type of
error. If this is the case it is better to be explicit in the text of section
4.2 as well as in the definition of the base identity to make sure that the
base identity is not extended by other modules.

Another approach could be to redefine this as an enumeration and to define an
additional data node (e.g., error-type) to report the error condition: this
data node can be constrained with a when statement to exist if and only if the
test status is "error"

21) Section 5.2 - YANG module (L61-105)

The descriptions are self-referencing. I would suggest to add a reference to
section 4.2 (or better move the state machine definition to a new section 4.2.1
and reference it)

22) Section 5.2 - YANG module (L106-115)

The descriptions are self-referencing

However, the error conditions "resource-contention" and "priority" are
mentioned but not defined in section 4.2.

I assume that the "resource-contention" represents a case where the test failed
because there were no resources available on the network elements to run the
test at the scheduled time. It would be worthwhile adding some description.

I do not know what error condition could the "priority" value represent.

I would suggest to either add some text (and a proper reference in the YANG
module) in section 4.1 or to provide more detailed explanation in the YANG
module to define the different error conditions.

Moreover, looking at the YANG module, the error conditions are defined as
identities: are you assuming that they can be extended by OAM-specific or
vendor-specific error conditions to be defined in other models?

IMHO, it seems valuable to allow other YANG data models to define new
identities for e.g., OAM test specific error conditions.

I would mention this option explicitly.

23) Section 5.2 - YANG module (L161-168)

The need for the "execution-count" is not clear: why the "recurrent-end" choice
defined in the schedule:recurrence-utc grouping is not sufficient?

24) Section 6

Since this section describes some design assumptions in the YANG data models of
section 5, I would suggest to add a forward pointer from section 4.1 and
section 4.2 to this section

25) Section 6

Maybe this is due to my lack of detailed understanding of how schema mount
works but the need for the test-type data node is not fully clear to me

Cannot the test-type be understood from the device YANG data model being
mounted under the root?

26) Section 7.1 - second paragraph

Since this paragraph describes some design assumptions in the YANG data models
of section 5 on the error processing (see some comments above on the YANG
design), I would suggest to add a forward pointer from section 4.1 and section
4.2 to this section

27) Section 7.1 - second paragraph

From the text in this paragraph it seems that other modules can extend the
state machines defined in section 4.1 and section 4.2 (see also previous
comments): please clarify

IMHO, it makes a lot of sense to allow extensibility for the error codes but I
do not think we need to allow for extensibility of the states in the state
machine

28) Section 7.1 - last paragraph

I assume that the pre-emption applies only to the OAM sessions being setup
using the YANG data models defined in this document, while other OAM sessions
being running on the devices through other mechanims should not be pre-empted
(e.g., through CLI or by configuring the device YANG data model directly).
Otherwise, we need to discuss how these other mechanisms can work in case the
OAM sessions are pre-empted.

29) Section 7.2

The requirements can be met if and only if schema-mount is mounting the proper
sub-tree and the device OAM YANG data models are properly design

30) Section 7.3

This section describe the use of the "managed" leaf only for configuration
while the description in the YANG data model and section 6 describes this as
"accessing" the data nodes (which I have interpreted as both in read and write
operations)

Moreover, when the "managed" leaf is set to false, it is not clear to me what
is the expected behavior from the controller: how does it know the proper OAM
session needs to be configured on the network elements? how does it know which
OAM session being configured on the network elements map with the scheduled OAM
test?

31) Appendix A.1

Has the JSON example been validated with yanglint?

At the first glance it seems not (for example the "recurrence-first" is defined
as a container in YANG and instantiated as a data node in the JSON example)

32) Appendix A.1

The first paragraph says that the example covers the "four configurations
(Control-Client, Server, Session-Sender and Session-Reflector)" but I can only
find the configuraiton of the Session-Sender and Session-Reflector

33) Appendix A.1

The second paragraph says that Figure 6 is an "example of a request message
body to create a TWAMP OAM test" but the JSON example provides a complete tree
and also config false data nodes

Since yanglint can only validate complete data trees rather than message
bodies, I would suggest to split Figure 6 into two data tree JSON examples, one
for config data (with no config false data nodes) and one for state data
(including config false data nodes)

34) Appendix A.1

Maybe this is due to my lack of detailed understanding of how schema mount
works but I am not sure the mounting point should mount the session-sender and
session-reflector container or an instance of the test-session list since the
scheduled OAM unitary test should trigger a single session on the device

35) Appendix A.1

Maybe this is due to my lack of detailed understanding of how schema mount
works but I am not sure that, given the definition of the OAM unitary test,
both TWAP test sessions (Test1 and Test2) should/could belong to the same OAM
unitary test: I would expect them to be either defined as part of two different
OAM unitary tests or be combined into the same OAM sequence test

36) Appendix A.1

Maybe this is due to my lack of detailed understanding of how schema mount
works but it would be helpful to complete the example with the corresponding
instances of the TWAMP YANG data model as well as with other schema-mount
related YANG modules e.g., to show how the instances of the TWAMP YANG data
model are actually mounted into the instances of this YANG data model

37) Appendix A.1

Maybe this is due to my lack of detailed understanding of how schema mount
works but, looking at the examples in RFC8528 and RFC8530, it seems that the
"root" container should be instantiated in the JSON code and the "ietf-twamp:"
prefix should be used for the mounted attributes

38) Appendix A.1

Maybe this is due to my lack of detailed understanding of how schema mount
works but, looking at the examples in RFC8528 and RFC8530, it seems that the
"root" container should be instantiated in the JSON code and the "ietf-twamp:"
prefix should be used for the mounted attributes

39) Appendix A.2

In this example, the YANG data model for LSP Ping to be mounted is omitted.
Since I am finding any RFC defining the YANG data model for LSP Ping, I have
some difficulties to review this example

Nits
====

1) Title

The Abstract and the content indicates that this document defines two YANG data
models

c/A YANG Data Model/YANG Data Models/

2) GitHub reference

The GitHub reference is pointing to a repository which either does no longer
exist or is private (it returns a 404 error)

3) Section 1 - Last paragraph

Based on the latest guidelines in RFC9907, the narrative text should highlight
only modules that are not compliant with NMDA. Therefore the last paragraph can
be removed.

4) Section 4.1 - Figure 3

There are two lines between the "success" and the "planned" state

5) Section 5 - YANG modules

The line alignment and line lengths looks a bit weird.

I would suggest to run pyang with the "-f yang" option to fix the line
alignment and with the "--max-line-length 69" to check the line lengths

6) Section 5.1 - first paragraph

This YANG module is no longer importing from RFC8294 but from RFC9911:

OLD

   This module imports typedefs from [RFC9922], [RFC8528] and [RFC8294],

NEW

   This module imports typedefs from [RFC9922], [RFC8528] and [RFC9911],

7) Section 5.1

The YANG module date in the <CODE BEGINS> does not match the date in the
revision statement.

Morever, I do not know if this is a real issue but usually the <CODE BEGIN> and
the filename are on the same line.

OLD
   <CODE BEGINS>
    file ietf-oam-unitary-test@2026-01-13.yang

NEW
   <CODE BEGINS> file "ietf-oam-unitary-test@2026-09-14.yang"

You can also use the following syntax to instruct Kramdown to automatically
create the proper markers and filename (but, unfortunately, still requires to
manually change the date to align with the date in the revision statement):

   {: sourcecode-markers="true"
   sourcecode-name="ietf-oam-unitary-test@2026-09-14.yang"}

8) Section 5.1 - YANG module (L6)

The comment can be removed

9) Section 5.1 - YANG module (L55-59)

BFP 14 keywords are not used so it is suggested to remove these lines

9) Section 5.1 - YANG module (L70-71)

Aling with the name of the draft:

OLD
         "RFCXXXX: A YANG Data Model for Network Diagnosis by Scheduling
          Sequences of OAM Tests";

NEW
      "RFC XXXX: A YANG Data Model for Network Diagnosis using
                 Scheduled Sequences of OAM Tests";

10) Section 5.1 - YANG module (L138-139)

The reference to RFC8531 does not match the RFC title

OLD

       reference
         "RFC 8531: Connection-Oriented OAM YANG Data Model";

NEW

       reference
         "RFC 8531: Generic YANG Data Model for Connection-Oriented
                    Operations, Administration, and Maintenance (OAM)
                    Protocols";

11) Section 5.1 - YANG module (L145-146)

The reference to RFC8532 does not match the RFC title

OLD

       reference
         "RFC 8532: Generic YANG Data Model for Connectionless OAM";

NEW

       reference
         "RFC 8532: Generic YANG Data Model for the Management of
                    Operations, Administration, and Maintenance (OAM)
                    Protocols That Use Connectionless
                    Communications";

12) Section 5.1 - YANG module (L152-153)

The reference to RFC9617 does not match the RFC title

OLD

       reference
        "RFC 9617: In Situ OAM (IOAM) YANG Data Model";

NEW

       reference
        "RFC 9617: A YANG Data Model for In Situ Operations,
                   Administration, and Maintenance (IOAM)";

13) Section 5.2 - Revision date

The YANG module has been updated after January 2026: the date in the revision
statement and in the <CODE-BEGIN> should be updated and kept aligned