Hi, Qiufang: Thanks for your valuable review, please see reply inline below.
发件人: maqiufang (A) [mailto:[email protected]] 发送时间: 2026年1月13日 15:39 收件人: Operations and Management Area Working Group Discussion List <[email protected]> 主题: [OPSAWG]Comments on draft-ietf-opsawg-scheduling-oam-tests-03 Hi, authors, WG, I have reviewed draft-ietf-opsawg-oam-tests, and I have a few comments/suggestions for your consideration. As the co-author of I-D.ietf-netmod-schedule-yang, happy to see the reuse of the schedule groupings in this draft. While in the current structure, each yang module includes both the period-of-time and recurrence related groupings, I am uncertain if this is intentional, as these two groupings represent two different types of schedules: period-of-time defines a single time schedule (i.e., one-time execution), and recurrence defines a repeating pattern (e.g., daily, hourly) for recurring executions. If both schedule types are intended to be supported, would it be clearer to structure them using a choice-case statement? [Qin Wu] Thanks for your clarification, in our cases, we want to support both one time schedule and periodical schedule. yes, we use both schedule groupings at the top level of scheduling oam test YANG data model, we understand two schedule type can not be used at the same time. That means we can not fill the values for both schedule type. Your proposed change sounds reasonable to me, I have created one new issue ticket for this https://github.com/vlopezalvarez/draft-contreras-opsawg-scheduling-oam-tests/issues/47 Some additional comments/thoughts: ・ The draft defines state machines for unitary-test-status and test-sequence-status(Figures 2 and 4), but it does not explicitly clarify the triggers for state transitions. For example, how to transit from planned to configured? It is also unclear to me what is the relationships between stop and finished. [Qin Wu] Good comment, yes, we can add some clarification text on triggers for state transitions. The question is do you think we should add some leaf to specify those triggers? Regarding the relation between stop and finished, the key difference between stop and finished, is stop is done manually while finished is done automatically, which is also indicating the end of lifecycle management. Do you have any suggestions on these relationship clarification? ・ While the draft mentions that output results of OAM tests depend on the underlying OAM models, it may be helpful to emphasize the need for collecting and correlating results from multiple test nodes to form a unified diagnostic report, to implement the use cases discussed in Section 2. [Qin Wu] I believe you are referred to section 6.2 “Coverage of Input Parameters and Output Results”, yes, we can add some text to emphasize the need for collecting and correlating, but how to collect and correlate results is beyond scope of this document, agree? ・ Operational Considerations section does not mention the performance impact of scheduling a collection of OAM tests, but maybe this needs to be considered as well. [Qin Wu]:Interesting, When multiple OAM tasks are scheduled to run concurrently, it might face some performance issues, since YANG model defined in this document is designed for management and orchestration systems , we need to make sure that management and orchestration systems have sufficient resource to conduct those multiple concurrent OAM tasks. Thanks for your time and efforts on this work. Best Regards, Qiufang
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
