Thanks for the update and taking my comments into consideration! On Sun, Apr 28, 2024 at 9:42 AM maqiufang (A) <[email protected]> wrote:
> Hi, Dhruv, > > > > Thanks a lot for your comments, the authors have submitted a new version > to address them: > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-schedule-yang-01. > <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-schedule-yang-01> > Please also see my reply inline… > > > > *From:* netmod [mailto:[email protected]] *On Behalf Of *Dhruv Dhody > *Sent:* Friday, April 12, 2024 6:20 PM > *To:* Kent Watsen <[email protected]> > *Cc:* [email protected] > *Subject:* Re: [netmod] Adoption call for draft-ma-opsawg-schedule-yang-04 > > > > Hi Kent, > > Support adoption! > > A few comments/nits for the authors to consider... > > - In the abstract, I was not sure how to parse "..scheduling information > such as event, policy, services, or resources..", are these examples well > known and established as scheduling information? > > [Qiufang]Actually, the schedule YANG module is intended to serve as common > building blocks for any scheduling context based on date and time, which > should have broad applicability without limiting to scheduled events, > policies, services, resources, etc. The word “information” might be vague, > the authors have used “purposes”, i.e., “This document defines a common > schedule YANG module which is designed to be applicable for scheduling > purposes such as event, policy, services, or resources based on date and > time.” Would this be better? Otherwise, please feel free to propose text at > https://github.com/netmod-wg/schedule-yang. > > - The introduction made sense as a motivation for the document initially, > but it should be rephrased esp that the referenced modules are expected to > be updated to use this common module going forward. You may create an > appendix with this historical context if needed. > > [Qiufang] Agree. The authors have rephrased the introduction section. > Some of the relevant description now as follows: > > “This document defines a common schedule YANG module ("ietf-schedule") > that can be used in several scheduling contexts, e.g., (but not limited > to) [I-D.ietf-opsawg-ucl-acl > <https://netmod-wg.github.io/schedule-yang/draft-ietf-netmod-schedule-yang.html#I-D.ietf-opsawg-ucl-acl> > ], [I-D.contreras-opsawg-scheduling-oam-tests > <https://netmod-wg.github.io/schedule-yang/draft-ietf-netmod-schedule-yang.html#I-D.contreras-opsawg-scheduling-oam-tests>], > and [I-D.ietf-tvr-schedule-yang > <https://netmod-wg.github.io/schedule-yang/draft-ietf-netmod-schedule-yang.html#I-D.ietf-tvr-schedule-yang> > ].” > > Would this be okay for you? > - Section 3.1, the description is a bit sparse; also there are > no examples that use this grouping. Please expand. > > [Qiufang] The description is now expanded in section 3.1, and the example > that uses this grouping is now added as appendix A.1. > > - The description inside the YANG module is old and incorrect, it says 2 > groupings and focused only on iCalendar. > > [Qiufang] Fixed now. thanks. > > - s/RFC XXXX: A YANG Data Model for Scheduling/RFC XXXX: A Common YANG > Data Model for Scheduling/ > > [Qiufang] Fixed. > > - for discard-action, is there a possibility for creating new actions in > future or these two are the only ones? I am asking to make sure that the > choice of modeling this as enum is correct or not. > > [Qiufang] The latest version has used identityref to not restrict any > future actions being defined. Thanks. > > - In these lists "leaf-list date-times" and "leaf-list dates", is there > any ordering constraint that should be added explicitly in text? > > [Qiufang] Note that we simplify the definition now and remove the > leaf-list date-times and dates definition, but we do have the list period > and period-timeticks, once valid entries are added, they will work as > repeating occurrences, regardless of ordering. Make sense? > > - Section 3.4 needs more descriptive text for period and timeticks. The > yang module has a long must statement for verification that should be > explained here in text. > > [Qiufang] The period and timeticks are now defined in 2 groupings to > facilitate human readability and machine readability in section 3.6 and > section 3.7, respectively. Some explanations are also added. Please review > it and let us know if you still think it unclear. > > - Section 3.5 needs more descriptive text for by* leaves -> "An array of > the "bysecond" (or "byminut", "byhour") specifies a list of seconds within > a minute (or minutes within an hour, hours of the day)." The examples in > the appendix gave some hints but the description should be clearer. > > [Qiufang] Sure, some examples have been given in the descriptive text to > help understand the parameters, which is now in Section 3.8. Please let us > know if you still think it unclear. > > - s/byminut/byminute/ > > [Qiufang] Fixed. > - Appendix A.1, the text says end date is Dec 31, 2027 but the > JSON says 1st Dec - "2027-12-01T18:00:00Z" > > [Qiufang] Good catch! Fixed now. > - Appendix A.2, the text says Dec 1, 2025 but the example says > 1st Nov - "2025-11-01T15:00:00" > > [Qiufang] Fixed! Thanks a lot. > > > Thanks! > Dhruv > > > > Best Regards, > > Qiufang > > > > On Tue, Mar 26, 2024 at 9:20 PM Kent Watsen <[email protected]> wrote: > > NETMOD WG, > > This email begins a 2-week adoption poll for: > > A Common YANG Data Model for Scheduling > https://datatracker.ietf.org/doc/draft-ma-opsawg-schedule-yang > > PS: This draft moved from OPSAWG to NETMOD > > There is no known IPR on this draft: > > > https://mailarchive.ietf.org/arch/msg/netmod/mg1KP3m6bCSXh-3N-YKLvEb_udk/ > > Please voice your support or technical objections to adoption on the list > by the end of the day Apr 10 (any time zone). > > Thank you, > Kent (as co-chair) > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
