Hi Med,

On Mon, Jun 30, 2025 at 9:42 AM <mohamed.boucad...@orange.com> wrote:
>
> > De : Per Andersson via Datatracker <nore...@ietf.org>
> >
> > * 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://github.com/netmod-wg/schedule-yang/pull/26 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

_______________________________________________
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org

Reply via email to