Hi Mahesh, Thanks for the follow-up.
A diff to track changes can be seen at: https://author-tools.ietf.org/api/iddiff?url_1=https://netmod-wg.github.io/schedule-yang/draft-ietf-netmod-schedule-yang.txt&url_2=https://netmod-wg.github.io/schedule-yang/Mahesh-follow-up/draft-ietf-netmod-schedule-yang.txt. Please see inline for more context. Cheers, Med (as contributor) > -----Message d'origine----- > De : Mahesh Jethanandani <mjethanand...@gmail.com> > Envoyé : dimanche 1 juin 2025 15:07 > À : maqiufang (A) <maqiufang1=40huawei....@dmarc.ietf.org> > Cc : netmod@ietf.org > Objet : [netmod] Re: I-D Action: draft-ietf-netmod-schedule-yang- > 06.txt > > > Hi Qiufang, > > Thanks for taking care of most of my comments. There are a few more > that I think we should have a discussion around. > > Section 3.2, paragraph 3 > > - one-shot: The schedule will trigger an action that has > either > > the duration specified as 0 or the end time specified the > same > > as start time, and then the schedule will disable itself > > (Section 3.3 of [RFC3231]). > > I prefer the description in the YANG module for one-shot, which says > "That is a schedule that will trigger an action without the > duration/end time being specified or the duration being specified as > 0/end time being specified the same as start time, and then the > schedule will disable itself." > > The part that this description is missing is that a "schedule-type" > of "one-shot" does not require duration/end time to be specified. [Med] Both the narrative text and yang module are in sync. The main aspect of one-shot schedule is that it will disable itself once executed at a given schedule time. > > Section 3.3.3, paragraph 3 > > The frequency parameter ("frequency") identifies the type of a > > recurrence rule. For example, a "daily" frequency value > specifies > > repeating events based on an interval of a day or more. > > The document now marks "frequency" as optional. What happens when > the "frequency" is not specified? Is it assumed to be "secondly", > "minutely", "hourly", or "daily"? > [Med] Good point. We can't impose an arbitrary default here. added a "must" to check the presence of frequency when interval is also supplied. I think that is sufficient. > Section 3.3.3, paragraph 4 > > Note that per Section 4.13 of [I-D.ietf-netmod-rfc8407bis], > neither a > > "default" nor a "mandatory" substatement is defined here for > both > > "frequency" and "interval" parameters because there are cases > (e.g., > > profiling) where using these statements is problematic. YANG > modules > > using this grouping SHOULD refine these two nodes with either a > > "mandatory" or a "default" statement, if they always need to be > > configured or have default values. This MAY be ignored in > cases such > > as when this grouping is used by another grouping. > > I am not sure what "This" is referring to in the sentence "This MAY > be ignored ...". What MAY be ignored? [Med] Changed to "This recommendation ..." The SHOULD part can be ignored. The document has already > removed all "default" and "mandatory" statements and leaves it up to > the module that is importing this grouping to add a "refine" > statement to add in any "default" and "mandatory" statements. > > Section 3.3.4, paragraph 4 > > The "duration" parameter specifies, in units of seconds, the > time > > period of the first occurrence. Unless specified otherwise > (e.g., > > through additional augmented parameters), the "duration" also > applies > > to subsequent recurrence instances. When unspecified, each > > occurrence is considered as immediate completion (e.g., execute > an > > immediate command that is considered to complete quickly) or > hard to > > compute an exact duration (e.g., run a data analysis script > whose > > execution time may depend on the data volume and computation > resource > > availability). > > What happens if the "duration" is specified but the task takes more > time than specified by the "duration"? Is the task terminated? > [Med] That's part of task management, not schedule management. There are similar issues that we don't include here (e.g., what happen when there are no enough resource to execute a task, what if the conflicts are encountered, etc.). These are task-specific. Some of these are discussed in other documents such as: https://datatracker.ietf.org/doc/html/draft-zdm-tvr-applicability-02#section-6.2. Added a sentence to call this out. > -------------------------------------------------------------------- > ----------- > NIT > -------------------------------------------------------------------- > ----------- > > All comments below are about very minor potential issues that you > may choose to address in some way - or ignore - as you see fit. Some > were flagged by automated tools (via > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi > thub.com%2Flarseggert%2Fietf- > reviewtool&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C35b5fd02a > c3c497126ff08dda10d37a9%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7 > C638843800350413364%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUs > IlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D > %7C0%7C%7C%7C&sdata=3C%2FYknFqoKoncPKmHoPO4ckh5i08Y0ckfGufFS7yRmk%3D > &reserved=0), so there will likely be some false positives. There is > no need to let me know what you did with these suggestions. > > Section 3.3.1, paragraph 6 > > The "validity" parameter specifies the date and time after > which a > > schedule will not be considered as valid. It determines the > latest > > time that a schedule can be started to execute independent of > when it > > ends and takes precedence over similar attributes that are > provided > > at the schedule instance itself. A requested schedule may > still be > > accepted but only not have its occurrences that starts later > than the > > configured value to be executed. > > > s/only not have its occurences that starts later than the configured > value to be executed/any occurences that start later than the > configured value will not be executed/ > [Med] OK > Thanks > > > On May 29, 2025, at 8:21 PM, maqiufang (A) > <maqiufang1=40huawei....@dmarc.ietf.org> wrote: > > > > Hi, all, > > > > This version takes care of the AD review comments as well as some > input from Kent. Please let the authors know if there is any > additional comments and suggestions. > > > > Best Regards, > > Qiufang > > > > -----Original Message----- > > From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] > > Sent: Friday, May 30, 2025 11:04 AM > > To: i-d-annou...@ietf.org > > Cc: netmod@ietf.org > > Subject: [netmod] I-D Action: draft-ietf-netmod-schedule-yang- > 06.txt > > > > Internet-Draft draft-ietf-netmod-schedule-yang-06.txt is now > available. It is a work item of the Network Modeling (NETMOD) WG of > the IETF. > > > > Title: A Common YANG Data Model for Scheduling > > Authors: Qiufang Ma > > Qin Wu > > Mohamed Boucadair > > Daniel King > > Name: draft-ietf-netmod-schedule-yang-06.txt > > Pages: 59 > > Dates: 2025-05-29 > > > > Abstract: > > > > This document defines common types and groupings that are meant > to be > > used for scheduling purposes such as event, policy, services, or > > resources based on date and time. For the sake of better > modularity, > > the YANG module includes a set of recurrence related groupings > with > > varying levels of representation (i.e., from basic to advanced) > to > > accommodate a variety of requirements. It also defines > groupings for > > validating requested schedules and reporting scheduling status. > > > > The IETF datatracker status page for this Internet-Draft is: > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fda > ta > > tracker.ietf.org%2Fdoc%2Fdraft-ietf-netmod-schedule- > yang%2F&data=05%7C > > > 02%7Cmohamed.boucadair%40orange.com%7C35b5fd02ac3c497126ff08dda10d37 > a9 > > > %7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638843800350436975%7CU > nk > > > nown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiO > iJ > > > XaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=TtKO%2F > tM > > LCsOkEDgVbGr0m6IYJ5PqZf6erWiISgR6hig%3D&reserved=0 > > > > There is also an HTML version available at: > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > w. > > ietf.org%2Farchive%2Fid%2Fdraft-ietf-netmod-schedule-yang- > 06.html&data > > > =05%7C02%7Cmohamed.boucadair%40orange.com%7C35b5fd02ac3c497126ff08dd > a1 > > > 0d37a9%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6388438003504491 > 83 > > > %7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCI > sI > > > lAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=A > 9e > > AC%2BDfwpqDYzJBG9VjealQLWEC5rPXGUp3DSu9CNw%3D&reserved=0 > > > > A diff from the previous version is available at: > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fau > th > > or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-netmod-schedule- > yang-06 > > > &data=05%7C02%7Cmohamed.boucadair%40orange.com%7C35b5fd02ac3c497126f > f0 > > > 8dda10d37a9%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63884380035 > 04 > > > 61302%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMD > Aw > > > MCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd > at > > a=yar5hfCvBEWo%2FfBGi2x0y%2BTLfsxEhUhfyLee8xiMNL4%3D&reserved=0 > > > > Internet-Drafts are also available by rsync at: > > rsync.ietf.org::internet-drafts > > > > > > _______________________________________________ > > netmod mailing list -- netmod@ietf.org To unsubscribe send an > email to > > netmod-le...@ietf.org > _______________________________________________ > > netmod mailing list -- netmod@ietf.org To unsubscribe send an > email to > > netmod-le...@ietf.org > > Mahesh Jethanandani > mjethanand...@gmail.com > > > > _______________________________________________ > netmod mailing list -- netmod@ietf.org > To unsubscribe send an email to netmod-le...@ietf.org ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
