Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.600.51.1.1\))
From: Acee Lindem <acee.ietf@gmail.com>
In-Reply-To: 
 <PR0P264MB28857C9932475ED1C1E705C0882DA@PR0P264MB2885.FRAP264.PROD.OUTLOOK.COM>
Date: Wed, 6 Aug 2025 07:05:51 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <289D91BA-93DF-47F3-98D0-C009BC88E234@gmail.com>
References: <D17E9BF4-B36C-4907-8F45-F122B6C56AF8@gmail.com>
 <PR0P264MB28858C1145BA7D25456942EB8823A@PR0P264MB2885.FRAP264.PROD.OUTLOOK.COM>
 <34360392-320F-4BB0-A9FB-FF23C5018F1F@gmail.com>
 <PR0P264MB28857C9932475ED1C1E705C0882DA@PR0P264MB2885.FRAP264.PROD.OUTLOOK.COM>
To: mohamed.boucadair@orange.com
Message-ID-Hash: 2ZHZVPCLCY56CUZPIPY6AW7ZCPNL5O74
CC: Routing ADs <rtg-ads@ietf.org>, Routing Directorate <rtg-dir@ietf.org>,
 "netmod@ietf.org" <netmod@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5Bnetmod=5D_Re=3A_Routing_Directorate_Review_for_=22A_Common_YANG?=
 =?utf-8?q?_Data_Model_for_Scheduling=22_-__draft-ietf-netmod-schedule-yang-?=
 =?utf-8?q?08?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/netmod/kJl0UhWhKdcZopTsVioosy-WvQg>

Hi Med,=20

> On Aug 6, 2025, at 1:05=E2=80=AFAM, mohamed.boucadair@orange.com =
wrote:
>=20
> Hi Acee,=20
>=20
> Thank you
>=20
> For your remaining question on point#2:
>=20
>> 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?
>=20
> 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 !=3DMonday, the rule will end by then but without =
enabling the ACL that end day.
>=20
> The description was anchored in your favorite RFC 5545 :-)
>=20
>      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.
>=20
> 5545 has an example to shows the difference between =
inclusive/non-inclusive:
>=20
>      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.=20

Thanks,
Acee



>=20
> Cheers,
> Med
>=20
>> -----Message d'origine-----
>> De : Acee Lindem <acee.ietf@gmail.com>
>> Envoy=C3=A9 : mercredi 6 ao=C3=BBt 2025 01:41
>> =C3=80 : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>
>> Cc : Routing ADs <rtg-ads@ietf.org>; Routing Directorate <rtg-
>> dir@ietf.org>; netmod@ietf.org
>> Objet : Re: [netmod] Routing Directorate Review for "A Common YANG
>> Data Model for Scheduling" - draft-ietf-netmod-schedule-yang-08
>>=20
>>=20
>> Hi Med,
>>=20
>> 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 =F0=9F=98=81).
>> In this context, I agree with your responses. See one remaining
>> question at #2.
>>=20
>>> On Aug 4, 2025, at 3:29=E2=80=AFAM, mohamed.boucadair@orange.com =
wrote:
>>>=20
>>> 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=3Dhttps%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=3D05%7C02%7Cmohamed.boucadair%40orange.com%7C9522f0405e3
>> f426dd0ea08ddd47980a3%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6
>> 38900340504632719%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIl
>> YiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7
>> C0%7C%7C%7C&sdata=3DmVAsX%2FEX2eqPDT4oJhT6CPQLPgHsQ86Hd2K%2BiQ9AU%2FU%
>> 3D&reserved=3D0   Please see inline.
>>> Cheers,
>>> Med
>>> De : Acee Lindem <acee.ietf@gmail.com> Envoy=C3=A9 : samedi 2 ao=C3=BB=
t
>> 2025
>>> 21:35 =C3=80 : Routing ADs <rtg-ads@ietf.org> Cc : Routing =
Directorate
>>> <rtg-dir@ietf.org>; netmod@ietf.org Objet : [netmod] Routing
>>> Directorate Review for "A Common YANG Data Model for Scheduling" -
>>> draft-ietf-netmod-schedule-yang-08
>>>=20
>>>=20
>>> Hello,
>>>=20
>>> 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:
>>>=20
>>>=20
>>>=20
>> https://fra01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Ftra
>> c.
>>>=20
>> tools.ietf.org%2Farea%2Frtg%2Ftrac%2Fwiki%2FRtgDir&data=3D05%7C02%7Cmo
>> ha
>>>=20
>> med.boucadair%40orange.com%7C9522f0405e3f426dd0ea08ddd47980a3%7C90c7
>> a2
>>>=20
>> 0af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638900340504655046%7CUnknown%7C
>> TW
>>>=20
>> FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMi
>> Is
>>>=20
>> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DXcm5i1Iibl4yqRS%
>> 2B
>>> 1HJP3H2XJWRsEwKRM42QM8aFpZs%3D&reserved=3D0
>>>=20
>>> 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.
>>>=20
>>> 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
>>>=20
>>> Summary:
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> Major Issues: None
>>>=20
>>> Minor Issues:
>>>=20
>>> I have the following minor comments.
>>>=20
>>>  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.
>>=20
>> Ok.
>>=20
>>>=20
>>>  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.";
>>=20
>> 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?
>>=20
>>=20
>>=20
>>>=20
>>>  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.
>>=20
>> 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.
>>=20
>>=20
>>>=20
>>>  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
>>=20
>> Ok - look at my suggested changes in the nits and see if any are
>> needed for consistency.
>>=20
>>=20
>>>=20
>>>  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.
>>=20
>> Thanks,
>>=20
>>>=20
>>>  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=E2=80=99t 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.
>>=20
>> Ok.
>>=20
>>>=20
>>>  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.
>>=20
>> I guess I've definitely worked with project managers who scheduled
>> new tasks to start before the previous ones completed.
>>=20
>>=20
>>>=20
>>>  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.
>>=20
>> Ok.
>>=20
>>=20
>>>=20
>>>  8. What is a "time zone database"? This term should be defined
>>>     or there should be a reference.
>>>=20
>>> [Med] After re-reading, I don=E2=80=99 think that term is needed. =
Deleting
>> it.
>>=20
>> Thanks.
>>=20
>>>=20
>>> Nits:
>>>=20
>>>  I've attached some editorial suggestions.
>>> [Med] Thank you. Went with most of the suggestions.
>>=20
>> Thanks - I don't claim to have made all the right choices between
>> recurrence, recurrence rule, and recurrence set.
>> Acee
>>=20
>>=20
>>>=20
>>>=20
>>> Thanks,
>>> Acee
>>> _______________________________________________
>>> netmod mailing list -- netmod@ietf.org To unsubscribe send an
>> email to
>>> netmod-leave@ietf.org
>>>=20
>> ____________________________________________________________________
>> __
>>> ______________________________________
>>> 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.
>>>=20
>>> 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.
>=20
> =
__________________________________________________________________________=
__________________________________
> 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.
>=20
> 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.