Hi Acee, Thanks for the careful review. Much appreciated!
A diff to track the changes made so far 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/acee-review/draft-ietf-netmod-schedule-yang.txt Please see inline. Cheers, Med De : Acee Lindem <[email protected]> Envoyé : samedi 2 août 2025 21:35 À : Routing ADs <[email protected]> Cc : Routing Directorate <[email protected]>; [email protected] Objet : [netmod] Routing Directorate Review for "A Common YANG Data Model for Scheduling" - draft-ietf-netmod-schedule-yang-08 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see: http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Early Review/Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-netmod-schedule-yang-08 Reviewer: Acee Lindem Review Date: 08/07/2025 IETF LC End Date: Already Over Intended Status: Standards Track Summary: This document contains a YANG data model for scheduling event, policies, services, or resources based on date and time. The module includes a set of reusable groupings which are designed to be applicable for scheduling purposes such as event, policy, services or resources based on date and time. It also defines groupings for validating requested schedules and reporting scheduling status. The document is very well written. However, I think that following that the recurrence model in RFC 5545 is overly complex and some of the more esoteric options should have been omitted. I doubt they will ever be used and, if needed, these could have been done in a separate augmentation. Major Issues: None Minor Issues: I have the following minor comments. 1. What is an out-of-date schedule compared to a finished schedule? [Med] This is about a schedule that is received out-of-date; that is the expected start date is already passed. Updated the text. 2. For recurrence-end, what does "inclusive" mean in this context. [Med] This is a terminology imported from rfc5545. This is to indicate whether the value indicated as an end is also part of the schedule. This is covered by the sentence right after. This is clarified in the sentence right after: "This parameter specifies a date and time value to inclusively terminate the recurrence in UTC format. If the value specified by this parameter is synchronized with the specified recurrence, it becomes the last instance of the recurrence."; Tweaked the text to made that clear: NEW: "This parameter specifies a date and time value to inclusively terminate the recurrence in UTC format. That is, if the value specified by this parameter is synchronized with the specified recurrence rule, it becomes the last instance of the recurrence rule."; 3. "weekday" is a very confusing type as this term normally refers to the Monday through Friday. Why not day-of-week? [Med] We considered this in the past, but we decided to ease mapping with RFC5545. 3. The distinction between "recurrence rule", "recurrence set", and "recurrence" is not clear and can be confusing in the node descriptions. Assure consistency given the context. I tried to remedy this in the nits but after starting down this path, I think the authors have a different intent. Perhaps the usage should be defined up front. [Med] All these terms were inherited from 5545. Updated the terminology section with new entries to introduce these terms. 4. Unless I'm misunderstanding the frequency, it seems the period-end would also need to be constrained by the frequency and be less than the period-start? [Med] Agree. Fixed. 5. For a recurrence rule, the frequency must be specified. If the interval is not specified, is it assumed to be 1? [Med] Yes, per RFC5545: The default value is "1", meaning every second for a SECONDLY rule, every minute for a MINUTELY rule, every hour for an HOURLY rule, every day for a DAILY rule, every week for a WEEKLY rule, every month for a MONTHLY rule, and every year for a YEARLY rule. We used to have the default value listed in the description but we removed it is this was raised as an issue by other reviewers. However, we don't specify such default here for the reasons recorded in the draft: 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. 6. For a recurrence specifying a duration, it would seem the duration would need to be less than the recurrence <frequenct, interval> otherwise the end of an instance could overlap the start of the next instance. [Med] We left that one unconstrained on purpose as this may depend on the scheduled task. 7. Why are the identifiers for the by.... scrunched together without hyphens? Why not by-second, by-hour, etc.? bysetpos is a terrible identifier. I don't think following the terminology in RFC 5545 was a wise decision. [Med] This was considered in the past and we decided to ease mapping with 5545. 8. What is a "time zone database"? This term should be defined or there should be a reference. [Med] After re-reading, I don' think that term is needed. Deleting it. Nits: I've attached some editorial suggestions. [Med] Thank you. Went with most of the suggestions. Thanks, Acee _______________________________________________ netmod mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[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]
