Hi Med, > On Aug 6, 2025, at 1:05 AM, [email protected] wrote: > > Hi Acee, > > Thank you > > For your remaining question on point#2: > >> 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? > > This means that there will be one valid recurrence at that end if it matches > the other recurrence rule parts. For example, if we have a rule to enable an > ACL every Monday noon until a given date xx/xx/xx. If that until date is a > Monday, then the recurrence will happen that Monday as well. If that date is > !=Monday, the rule will end by then but without enabling the ACL that end day. > > The description was anchored in your favorite RFC 5545 :-) > > The UNTIL rule part defines a DATE or DATE-TIME value that bounds > the recurrence rule in an inclusive manner. If the value > specified by UNTIL is synchronized with the specified recurrence, > this DATE or DATE-TIME becomes the last instance of the > recurrence. > > 5545 has an example to shows the difference between inclusive/non-inclusive: > > The following is an example of the "VEVENT" calendar component > used to represent a multi-day event scheduled from June 28th, 2007 > to July 8th, 2007 inclusively. Note that the "DTEND" property is > set to July 9th, 2007, since the "DTEND" property specifies the > non-inclusive end of the event.
I guess I don't see the need for a non-inclusive ending (just use an earlier ending time). I'm glad ietf-schedule.yang chose the inclusive manner. Thanks, Acee > > Cheers, > Med > >> -----Message d'origine----- >> De : Acee Lindem <[email protected]> >> Envoyé : mercredi 6 août 2025 01:41 >> À : BOUCADAIR Mohamed INNOV/NET <[email protected]> >> Cc : Routing ADs <[email protected]>; Routing Directorate <rtg- >> [email protected]>; [email protected] >> Objet : Re: [netmod] Routing Directorate Review for "A Common YANG >> Data Model for Scheduling" - draft-ietf-netmod-schedule-yang-08 >> >> >> 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, [email protected] wrote: >>> >>> Hi Acee, >>> Thanks for the careful review. Much appreciated! >>> A diff to track the changes made so far can be seen at: >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fau >> thor-tools.ietf.org%2Fapi%2Fiddiff%3Furl_1%3Dhttps%3A%2F%2Fnetmod- >> wg.github.io%2Fschedule-yang%2Fdraft-ietf-netmod-schedule- >> yang.txt%26url_2%3Dhttps%3A%2F%2Fnetmod-wg.github.io%2Fschedule- >> yang%2Facee-review%2Fdraft-ietf-netmod-schedule- >> yang.txt&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C9522f0405e3 >> f426dd0ea08ddd47980a3%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6 >> 38900340504632719%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIl >> YiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7 >> C0%7C%7C%7C&sdata=mVAsX%2FEX2eqPDT4oJhT6CPQLPgHsQ86Hd2K%2BiQ9AU%2FU% >> 3D&reserved=0 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: >>> >>> >>> >> https://fra01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftra >> c. >>> >> tools.ietf.org%2Farea%2Frtg%2Ftrac%2Fwiki%2FRtgDir&data=05%7C02%7Cmo >> ha >>> >> med.boucadair%40orange.com%7C9522f0405e3f426dd0ea08ddd47980a3%7C90c7 >> a2 >>> >> 0af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638900340504655046%7CUnknown%7C >> TW >>> >> FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi >> Is >>> >> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Xcm5i1Iibl4yqRS% >> 2B >>> 1HJP3H2XJWRsEwKRM42QM8aFpZs%3D&reserved=0 >>> >>> 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 -- [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. > > ____________________________________________________________________________________________________________ > 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]
