Hi Per, Thanks for the follow-up. I like these suggestions. I guess -08 integrates these. For the tz part, a new grouping was added. Let it to the modules that will consume the common module to select the appropriate grouping that fits their need. Cheers, Med (as author) > -----Message d'origine----- > De : Per Andersson <per.ietf@xxxxxxxx> > Envoyé : vendredi 4 juillet 2025 00:15 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@xxxxxxxxxx> > Cc : ops-dir@xxxxxxxx; draft-ietf-netmod-schedule-yang.all@xxxxxxxx; > last-call@xxxxxxxx; netmod@xxxxxxxx > Objet : Re: [OPS-DIR]Re: draft-ietf-netmod-schedule-yang-07 ietf > last call Opsdir review > > > Hi Med, > > On Mon, Jun 30, 2025 at 9:42 AM <mohamed.boucadair@xxxxxxxxxx> wrote: > > > > > De : Per Andersson via Datatracker <noreply@xxxxxxxx> > > > > > > * Section 3.3.8 > > > > > > Why is the iCalendar BYWEEKNO, BYMONTH, and WKST defined as > > > "byyearweek", "byyearmonth", and "workweek-start" > respectively? > > > Suggest to follow the naming convention from RFC 5545, e.g. > > > "byweekno", "bymonth", and "week-start". > > > > > > > [Med] The 5545 labels for these ones do not adequately reflect > their actual definition and preferred to use more meaningful ones > inspired by the definition. For example, we went for " workweek- > start" for WKST rather than "week-start" because 5545 says: "The > WKST rule part specifies the day on which the workweek starts". Idem > for the other two. > > Ok. > > > > > * Section 3.3.9 > > > > > > Why have a leaf with current local time instead of the pattern > > > that > > > was used before with yang:date-and-time leafs and a > > > timezone-identifier if the times are in local time? This > incurs > > > different calculations to be made to infer the time offset > from > > > UTC > > > for the schedule-status groupings and the other groupings. In > one > > > the > > > timezone is supplied and can be feed to a time generating > function > > > to > > > calculate the localtime, in the other the current UTC > timestamp is > > > diffed from the supplied localtime to calculate what timezone > (or > > > offset from UTC) is used. > > > > > > Suggest to use the pattern with timezone-identifier even for > the > > > schedule-status groupings. > > > > > > > [Med] Please refer to > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi > thub.com%2Fnetmod-wg%2Fschedule- > yang%2Fpull%2F26&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C493 > d11011df8415796c708ddba7f24e8%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0 > %7C0%7C638871777427002497%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ > %3D%3D%7C0%7C%7C%7C&sdata=Nyw2Fg%2FImgOry8pc3KtUIR6A%2BpJ%2BUOTYgQDn > RST4umQ%3D&reserved=0 for the rationale for that structure > (basically, follow RFC3231). > > So this construction is because schedules are different if they are > iCalendar or of the other types? Basically, it is an edge case of > iCalendar behaving differently and requiring time to be in local > time. > > I still find the asymmetry of schedule params and schedule status > confusing, that checking the status, i.e. the operational data, > differs in presentation from how I scheduled it. > > For users that want consistency with the schedule parameters, is it > possible to introduce a feature indicating how schedule-status is > reported, together with a choice which selects different cases > dependant on existance of timezone-identifier (if the feature is > enabled)? > > > > > * Section 6 > > > > > > RFC 6991 is listed as a normative reference. However the > numerical > > > values in the must statement in period-start are magical > constants > > > in > > > the YANG module without any further explanation. Suggest to > add a > > > reference and elaborate what the leaf values represent, > instead of > > > just stating "start/stop time". > > > > > > > > > > [Med] Not sure what the description would say here more than this > indicates when a period starts ;-) If you have a particular change > in mind, please share it. > > I meant the leafs period-start and period-end in the period- > timeticks list in the recurrence-utc-with-periods grouping. It is > helpful for a reader to mention what timeticks are (1/100 of a > second) and that the values 100, 6000 etc represent 1 s, 1 min etc. > > OLD: > > description > "Start time of the schedule within one recurrence."; > > NEW: > description > "Start time of the schedule within one recurrence. > > The value is in timeticks format, i.e. 1/100 of a second. > > The hardcoded values in the must statement translate to: > > secondly: 100 = 1 s > minutely: 6000 = 60 s = 1 min > > and so on for all instances in the must statement > invariant."; > > > -- > Per ____________________________________________________________________________________________________________ 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. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
