Hi Med, Thanks for addressing the remaining comments and for providing the diffs, although the link failed for me.
> > On Jun 12, 2025, at 5:09 AM, [email protected] wrote: > > 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 <[email protected]> >> Envoyé : dimanche 1 juin 2025 15:07 >> À : maqiufang (A) <[email protected]> >> Cc : [email protected] >> 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. [mj] If the text in the document matches the text in the YANG model, we are good. > >> >> 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. [mj] Yes. > >> 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. [mj] Since the recommendation is a SHOULD and not a MUST, modules importing this grouping can still ignore this recommendation. Not sure you need the MAY statement. > > > 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. [mj] Ok. Thanks. > > 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) >> <[email protected]> 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: [email protected] [mailto:[email protected]] >>> Sent: Friday, May 30, 2025 11:04 AM >>> To: [email protected] >>> Cc: [email protected] >>> 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 -- [email protected] To unsubscribe send an >> email to >>> [email protected] >> _______________________________________________ >>> netmod mailing list -- [email protected] To unsubscribe send an >> email to >>> [email protected] >> >> Mahesh Jethanandani >> [email protected] >> >> >> >> _______________________________________________ >> netmod mailing list -- [email protected] >> To unsubscribe send an email to [email protected] > ____________________________________________________________________________________________________________ > 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 -- [email protected] To unsubscribe send an email to [email protected]
