Hi Med, Thanks for your quick response. I think many of my issues are based on RFC 5545 which I feel was a poor choice to use as a model for recurrent schedule. However, I realize the IESG telecat is a too late to consider this type of comment (I've experienced this as an author with some AD's 11th hour telechat comments đ). In this context, I agree with your responses. See one remaining question at #2.
> On Aug 4, 2025, at 3:29âŻAM, mohamed.boucad...@orange.com wrote: > > 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 <acee.i...@gmail.com> > EnvoyĂ© : samedi 2 aoĂ»t 2025 21:35 > Ă : Routing ADs <rtg-...@ietf.org> > Cc : Routing Directorate <rtg-...@ietf.org>; netmod@ietf.org > 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. Ok. > > 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."; Ok - I guess I still don't understand. Does this mean there is one more recurrence at the even if one isn't due according to 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. I won't repeat it again, but using the RFC 5545 terminology was a poor choice. At least "weekend" isn't used to terminate a weekly recurrence. > > 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 Ok - look at my suggested changes in the nits and see if any are needed for consistency. > > 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. Thanks, > > 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. Ok. > > 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. I guess I've definitely worked with project managers who scheduled new tasks to start before the previous ones completed. > > 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. Ok. > > 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. Thanks. > > Nits: > > I've attached some editorial suggestions. > [Med] Thank you. Went with most of the suggestions. Thanks - I don't claim to have made all the right choices between recurrence, recurrence rule, and recurrence set. Acee > > > Thanks, > Acee > _______________________________________________ > 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
