[netmod] Re: Routing Directorate Review for "A Common YANG Data Model for Scheduling" - draft-ietf-netmod-schedule-yang-08

[Acee Lindem <[e-mail]>]

Hi Med, 

> On Aug 6, 2025, at 1:05 AM, [e-mail] 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 <[e-mail]>
>> Envoyé : mercredi 6 août 2025 01:41
>> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
>> Cc : Routing ADs <[e-mail]>; Routing Directorate <rtg-
>> [e-mail]>; [e-mail]
>> 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, [e-mail] 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 <[e-mail]> Envoyé : samedi 2 août
>> 2025
>>> 21:35 À : Routing ADs <[e-mail]> Cc : Routing Directorate
>>> <[e-mail]>; [e-mail] 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 -- [e-mail] To unsubscribe send an
>> email to
>>> [e-mail]
>>> 
>> ____________________________________________________________________
>> __
>>> ______________________________________
>>> 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.