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]<mailto:kent%[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
