Hi, Qiufang: See reply inline below marked with [QW]. [OPSAWG]Re: I-D Action: draft-ietf-opsawg-scheduling-oam-tests-05.txt "maqiufang (A)" <[email protected]> Thu, 09 April 2026 02:34 UTCShow header<https://mailarchive.ietf.org/arch/msg/opsawg/0jssReRBLBkOckUsXclIbu4Hnlk/> Hi, Joe and Qin,
Please see inline for some responses to Joe’s first comment… From: Joe Clarke (jclarke) [mailto:[email protected]] Sent: Wednesday, April 8, 2026 11:34 PM To: Qin Wu <[email protected]>; [email protected]<mailto:[email protected]> Cc: Victor Lopez (Nokia) <[email protected]> Subject: [OPSAWG]Re: I-D Action: draft-ietf-opsawg-scheduling-oam-tests-05.txt Thanks for the changes, Qin. >>The numexecutions leaf is odd to me. First, I think something like >>"execution-count" might read better. But, more importantly, how does this >>factor into recurrence/frequency? If I choose 3 executions, >>are they executed simultaneously? One after the other? On the frequency >>intervals? [Qin Wu] In the current version, we import “recurrence-basics” grouping from RFC9922, in such grouping, only frequency and interval parameters are specified, however it doesn’t restrict the number of times the same test sequence is executed, therefore we believe numexecutions leaf can be used to limit the number of times the same test sequence is executed. See the PR I have submitted: https://github.com/vlopezalvarez/draft-contreras-opsawg-scheduling-oam-tests/pull/80/changes Alternatively, we can import “recurrence-utc” grouping, which has “count” parameter used to restrict the number of times the same test sequence is executed. [JMC] I appreciate the renaming, but my other questions remain. Should there be some text to explain how each execution specified in that leaf are run? [Qiufang] Agree that something like the following in the description could help: Each execution occurs at the scheduled recurrence interval. [QW]:Sounds good input, thanks. I initially interpreted this parameter as a retry count upon failure, but Qin's response seems to indicate that it is used to limit how many times the test is executed in a recurrence rule. [QW]:That is my understanding, I would like to see my coauthors to chime in if they think differently. I suppose I choose 3 for execution-count and I schedule a frequency of 10 minutes, but my period-start and period-end only include time for two tests to run. This would then be maximum number of tests iterations to run in the scheduled time? [Qiufang] In my understanding, the module design shows that “period” and “recurrence” are different cases inside “schedule-type” choice, and the “period” itself implies just one single execution. My assumption is that “execution-count” is meant to be used with the “recurrence” schedule type, i.e., it might be clearer either to define the “execution-count” inside the container recurrence, or to add a when statement to specific this parameter is only valid when the schedule type is recurrence. [QW]: Yes, I agree it is much clearer if we define “execution-count” within the recurrence container, add when statement explicitly is another choice, I prefer the former proposal. Nit: the tress diagram says the choice name “schedule-type”, but it should be “schedule-class” as per the YANG module definition. [QW]: Good catch, will fix this. And what if I want tests run indefinitely? [Qiufang] Suggest adding some text such as: if no count is indicated, the test is considered to run indefinitely. [QW]:Sounds good to me. As I clarified earlier, I am not sure such feature is useful and whether it will be treated as exceptional case or some kind of failure. Best Regards, Qiufang
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
