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.
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]
