Hi Qiufang,
Thanks for taking care of most of my comments. There are a few more that I
think we should have a discussion around.
Section 3.2, paragraph 3
> - one-shot: The schedule will trigger an action that has either
> the duration specified as 0 or the end time specified the same
> as start time, and then the schedule will disable itself
> (Section 3.3 of [RFC3231]).
I prefer the description in the YANG module for one-shot, which says "That is a
schedule that will trigger an action without the duration/end time being
specified or the duration being specified as 0/end time being specified the
same as start time, and then the schedule will disable itself.”
The part that this description is missing is that a "schedule-type" of
"one-shot" does not require duration/end time to be specified.
Section 3.3.3, paragraph 3
> The frequency parameter ("frequency") identifies the type of a
> recurrence rule. For example, a "daily" frequency value specifies
> repeating events based on an interval of a day or more.
The document now marks "frequency" as optional. What happens when the
"frequency" is not specified? Is it assumed to be "secondly", "minutely",
"hourly", or "daily"?
Section 3.3.3, paragraph 4
> 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. This MAY be ignored in cases such
> as when this grouping is used by another grouping.
I am not sure what "This" is referring to in the sentence "This MAY be ignored
...". What MAY be ignored? The document has already removed all "default" and
"mandatory" statements and leaves it up to the module that is importing this
grouping to add a "refine" statement to add in any "default" and "mandatory"
statements.
Section 3.3.4, paragraph 4
> The "duration" parameter specifies, in units of seconds, the time
> period of the first occurrence. Unless specified otherwise (e.g.,
> through additional augmented parameters), the "duration" also applies
> to subsequent recurrence instances. When unspecified, each
> occurrence is considered as immediate completion (e.g., execute an
> immediate command that is considered to complete quickly) or hard to
> compute an exact duration (e.g., run a data analysis script whose
> execution time may depend on the data volume and computation resource
> availability).
What happens if the "duration" is specified but the task takes more time than
specified by the "duration"? Is the task terminated?
-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.
Section 3.3.1, paragraph 6
> The "validity" parameter specifies the date and time after which a
> schedule will not be considered as valid. It determines the latest
> time that a schedule can be started to execute independent of when it
> ends and takes precedence over similar attributes that are provided
> at the schedule instance itself. A requested schedule may still be
> accepted but only not have its occurrences that starts later than the
> configured value to be executed.
s/only not have its occurences that starts later than the configured value to
be executed/any occurences that start later than the configured value will not
be executed/
Thanks
> On May 29, 2025, at 8:21 PM, maqiufang (A)
> <[email protected]> wrote:
>
> Hi, all,
>
> This version takes care of the AD review comments as well as some input from
> Kent. Please let the authors know if there is any additional comments and
> suggestions.
>
> Best Regards,
> Qiufang
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Friday, May 30, 2025 11:04 AM
> To: [email protected]
> Cc: [email protected]
> Subject: [netmod] I-D Action: draft-ietf-netmod-schedule-yang-06.txt
>
> Internet-Draft draft-ietf-netmod-schedule-yang-06.txt is now available. It is
> a work item of the Network Modeling (NETMOD) WG of the IETF.
>
> Title: A Common YANG Data Model for Scheduling
> Authors: Qiufang Ma
> Qin Wu
> Mohamed Boucadair
> Daniel King
> Name: draft-ietf-netmod-schedule-yang-06.txt
> Pages: 59
> Dates: 2025-05-29
>
> Abstract:
>
> This document defines common types and groupings that are meant to be
> used for scheduling purposes such as event, policy, services, or
> resources based on date and time. For the sake of better modularity,
> the YANG module includes a set of recurrence related groupings with
> varying levels of representation (i.e., from basic to advanced) to
> accommodate a variety of requirements. It also defines groupings for
> validating requested schedules and reporting scheduling status.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-schedule-yang/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-netmod-schedule-yang-06.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-schedule-yang-06
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> netmod mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> _______________________________________________
> netmod mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
Mahesh Jethanandani
[email protected]
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
