Hi, Dan: Thanks for your valuable comments and input, I have created issue tickets to keep track of your issues https://github.com/vlopezalvarez/draft-contreras-opsawg-scheduling-oam-tests/issues/38 https://github.com/vlopezalvarez/draft-contreras-opsawg-scheduling-oam-tests/issues/39 https://github.com/vlopezalvarez/draft-contreras-opsawg-scheduling-oam-tests/issues/44
Please see my reply inline below. -----邮件原件----- 发件人: Daniel King [mailto:[email protected]] 代表 [email protected] 发送时间: 2026年1月4日 18:33 收件人: [email protected] 主题: [OPSAWG]Review of RE: I-D Action: draft-ietf-opsawg-scheduling-oam-tests-03.txt Howdy Authors, Thanks for the excellent work on the I-D. I've been following the work since its inception and thought I'd finally spend some (biological) CPU cycles to review the latest version of the document. Firstly, the document does a great job in defining network-wide behaviour for an OAM scheduling wrapper. Demonstrating how existing OAM YANG models, together with the common scheduling approach, help align implementations and reduce duplicated modelling effort. The IETF should always strive to explain how its technologies can be applied, and I think this document does a great job of that. Ok, onto my review. Nothing too controversial. Hopefully, you find these useful. Poke me for anything that is not clear. #1 Abstract text change: - "network diagnosis on-demand" With: - "to support on-demand network diagnosis" [Qin Wu] OK #2 Abstract clarity Replace text: - "relying upon … OAM tests" With: - "using … OAM tests" (Personally, I found "relying upon" read awkwardly.) [Qin Wu] Good, incorporated. #3 Abstract applicability Replace text: - "primarily intended for use by an SDN controller or network orchestrator, rather than by individual network nodes." With: - "intended for use by external management and orchestration systems (including SDN controllers and network orchestrators), rather than by individual network nodes". [Qin Wu] Incorporated. #4 Introduction Replace: - "the management of OAM operations becomes also essential" With: - "managing OAM operations is also essential" [Qin Wu] Incorporated. #6 Introduction Replace: - "as the scheduling of test generally implies" With: - "as scheduling tests generally implies" [Qin Wu] Incorporated. #7 Terminology typo In Section 1.1, replace: - "it includes the type test" With: - "it includes the test type" [Qin Wu] Incorporated. #8 Prefix table module name mismatch In Table 1 (Section 1.3), replace: - "ietf-oam-unitary-tests" With: - "ietf-oam-unitary-test" (Need to decide on singular or plural for consistency. Especially as your module name is singular elsewhere.) [Qin Wu] Incorporated. #9 Section 2 Replace: - "Following, some illustrative examples are presented." With: - "The following illustrative examples are provided." [Qin Wu] Incorporated. #11 Troubleshooting In 2.1, replace: - "find the candidate root cause" With: - "identify likely root causes" [Qin Wu] Incorporated. #12 Birth certificate In 2.2, replace: - "if the service is a Virtual Private Network (VPN). Two-Way…” With: - "if the service is a Virtual Private Network (VPN), Two-Way…" [Qin Wu] Incorporated. #13 Proactive Supervision In 2.3, replace: - "require to fulfill" With: - "require fulfilment of" [Qin Wu] Incorporated. #14 Proactive Supervision In 2.3, split/replace the final clause: - "…before they impact the customer or end user, or to prevent or minimize…" With: - "…before they impact the customer or end user. This helps prevent or minimize…" [Qin Wu] Incorporated. #15 Section 3.1 Replace: - "out of the scope" With: - "out of scope" [Qin Wu] Incorporated. #16 Section 3.2 spacing typo Replace: - "identifies theproperties" With: - "identifies the properties" [Qin Wu] Good catch, incorporated. #17 Section 3.2 Section 3.1 explicitly mentions 'unitary-test-status', but you repeat it in section 3.2. Is it really needed in this sub-section too? It feels clunky and redundant to me, but hey ho. - "`unitary-test-status` enumerates the state of the OAM test." [Qin Wu] This draft define 2 YANG Data models, one focus on a single OAM unitary tests while the other focus on collection of OAM unitary tests, both can be reused as one common building block. For ietf-oam-test-sequence with a collection of OAM unitary tests, each OAM unitary test can have its own test-sequence-status. test-sequence-status will be different for each unitary test in the collection of OAM unitary tests. Does this clarify? #18 Clarify sequencing semantics Add to 3.2 (after the first paragraph) a short, normative description of: - How ordering is expressed (e.g., list order, explicit index, or `ordered-by user`) [Qin Wu] See snippet of Tree diagram module: ietf-oam-test-sequence +--rw oam-test-sequence +--rw test-sequence* [name] +--rw name string +--rw test-ref* [name] | +--rw name string I think the sequence of each oam-test-sequence can be random, but for the sequence of a collection of unitary test under test-ref list, it is ordered by user, in my opinion. Since when we conduct oam sequence test, we have specific test sequence, e.g., Test A=>Test B=> Test C. I will add order by user for name under test-ref. - Whether "stop on first failure" is supported/expected (and where indicated) [Qin Wu] Good comment, when we conduct oam sequence test, we can allow one of test to fail or we can stop the whole sequence test in case of one of tests fails, I think we can add one new leaf To indicate such capability. - Where repetition applies (whole sequence vs per-unitary-test) [Qin Wu] if you look at the tree diagram for ietf-oam-unitary-test and ietf-oam-test-sequence respectively, you will see schedule parameters are associated with each oam test sequence instead of each oam unitary test. So we can use schedule parameters to allow repetition of each oam test sequence, e.g., repeat test sequence every one hour. Within oam sequence test, we can have multiple oam unitary tests, e.g., testA, testB, Test C, but we don't allow repetition of unitary tests within oam sequence test. We can make this clear in the text. Thinking aloud, I'm wondering what would happen without this; could implementers interpret sequences differently? [Qin Wu] Thanks, these are useful inputs, we will take them into account. #19 Unit test module filename vs revision mismatch In 4.1, `<CODE BEGINS> file [email protected], but the module revision block shows revision "2025-09-15". [Qin Wu] OK #20 YANG module copyright year. In the YANG module header (4.1), update “Copyright (c) 2024 …” [Qin Wu] OK #21 Status enum mismatch: “finish(ed)” Text uses “finished”; YANG uses `enum "finish"`. Replace YANG `enum "finish"` with `enum "finished"` and update references. [Qin Wu] Accepted #22 Status consistency: “on-going” vs “ongoing”. Just need to be consistent in the document/code. [Qin Wu] Agree, incorporated in. #23 Naming consistency: “oam-unitary-tests” vs “oam-unitary-test”. Again, just need to be consistent in the document/code. [Qin Wu] OK #24 Using Device Mode Within OAM Scheduling Models - “Using Device Mode Within OAM Scheduling Models” With: - “Using Device Models Within OAM Scheduling Models” [Qin Wu] OK #25 Using Device Mode Within OAM Scheduling Models Replace: - “As an exmaple” With: - “As an example” [Qin Wu] OK #26 Using Device Mode Within OAM Scheduling Models - “This approach requires to recreate new YANG models…” With: - “This approach requires recreating YANG models…” [Qin Wu] OK #27 Conflict reporting I wondered if this approach was too course. Currently conflicts are effectively “encoded” as “error”. Could we add a structured approach with additional detail (such as): - A `conflict-info` container (resource, overlapping task, time window, reason), or; - Reuse/align with the schedule model’s conflict/status reporting (preferred if available). [Qin Wu] Joe raised similar comments, I am thinking to redefine the unitary-test-status and test-sequence-status grouping as identity type and indicate error cause using child identity. Yes, introducing 'conflict-info' container is another option, but add complexity, in my opinion. Yes, we will reuse schedule model for conflict/status reporting as well. #28 Pre-execution admission control In 6.1, replace: - “When a new `unitary-test` or `test-sequence` are scheduled…” With: - “When a new `unitary-test` or `test-sequence` is scheduled…” [Qin Wu] Done. Actually, thinking further, how about a sentence clarifying whether the server is expected to: - reject conflicts at create-time, or; - accept and later mark as conflict, and how that behaviour is advertised (capability/feature/status)? [Qin Wu] Yes, well thought. I think we assume at the design time, we don't check schedule conflict, by default, we have accepted conflict at the design time, Will detect and report conflict during running time. I think we are good enough. And we don't have way to mark as conflict or how to mark them as conflict should not in the scope of this document, in my opinion. #29 Security Considerations Replace: - “In which refers to the scheduling of the tests, security considerations in …” With: - “With respect to scheduling, the security considerations in … also apply.” [Qin Wu] Accept. BR, Dan. -----Original Message----- From: [email protected] <[email protected]> Sent: 20 October 2025 16:33 To: [email protected] Cc: [email protected] Subject: [OPSAWG]I-D Action: draft-ietf-opsawg-scheduling-oam-tests-03.txt Internet-Draft draft-ietf-opsawg-scheduling-oam-tests-03.txt is now available. It is a work item of the Operations and Management Area Working Group (OPSAWG) WG of the IETF. Title: A YANG Data Model for Network Diagnosis using Scheduled Sequences of OAM Tests Authors: Luis M. Contreras Victor Lopez Qin Wu Name: draft-ietf-opsawg-scheduling-oam-tests-03.txt Pages: 33 Dates: 2025-10-20 Abstract: This document defines a YANG data model for network diagnosis on- demand relying upon Operations, Administration, and Maintenance (OAM) tests. This document defines both 'oam-unitary-test' and 'oam-test- sequence' YANG modules to manage the lifecycle of network diagnosis procedures, primarily intended for use by an SDN controller or network orchestrator, rather than by individual network nodes. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-scheduling-oam-tests/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-opsawg-scheduling-oam-tests-03.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-scheduling-oam-tests-03 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
