Hi authors, WG,
Sorry for a late WGLC review. I would like to thank the authors working on
this document. Like Adrian, I also think that this document will be useful,
but I do have a few concerns/comments.
Moderate level comments:
(1) p 4, sec 3.1. Features
Refer to Section 3.4 for the use of these features.
I'm not sure that these YANG features are really useful/helpful. Given this
module only defines groupings, then if modules using these groupings are also
predicated by these features then the same constraint on basic-recurrence or
icalendar-recurrence will affect all modules.
Will it always be the case that they will want a shared fate, or would it be
better for the modules using these groupings to define their own module
specific feature statements? I.e., this draft could suggest that uses of the
groupings define their own features if needed, or just say nothing at all and
assume that they will do the right thing.
(2) p 7, sec 3.3.1. The "generic-schedule-params" Grouping
grouping generic-schedule-params:
+-- description? string
Most of the definitions include a description, but I would have thought that in
many instances the description would likely be superfluous to requirements. Of
course, when the groupings are used the description statement could be
deviated, but I think that it may be better to elide the description from the
groupings and then it could be augmented in during the uses statements, if
needed by the uses of these groupings.
(3) p 7, sec 3.3.1. The "generic-schedule-params" Grouping
+-- time-zone-identifier? sys:timezone-name
+-- validity? yang:date-and-time
+-- max-allowed-start? yang:date-and-time
+-- min-allowed-start? yang:date-and-time
+-- max-allowed-end? yang:date-and-time
Quite a few of the definitions include both a time-zone-identifier and also
various leaves using the yang:date-and-time. I think that the text description
of these leaves needs to be very explicit regarding what time-offset should be
used, what valid values are, etc. E.g., if I say that the time-zone is PST but
then use data-and-time values at +01:00, then what does that mean?
Possibly, you might want to consider introducing a date-and-time-no-zone type
to avoid the ambiguity.
(4) p 14, sec 3.3.6. The "recurrence-utc-with-date-times" Grouping
grouping generic-schedule-params:
...
grouping period-of-time:
...
grouping recurrence-basic:
...
grouping recurrence-utc:
...
grouping recurrence-with-time-zone:
...
grouping recurrence-utc-with-date-times:
+-- recurrence-first
| +-- start-time-utc? yang:date-and-time
| +-- duration? uint32
+-- (recurrence-end)?
| +--:(until)
| | +-- utc-until? yang:date-and-time
| +--:(count)
| +-- count? uint32
+-- recurrence-description? string
+-- frequency identityref
+-- interval? uint32
+-- period-timeticks* [period-start]
+-- period-start yang:timeticks
+-- period-end? yang:timeticks
I found the naming of this group and associated description to be somewhat
confusing. I.e., I can see that this recurrence uses utc and date-times, but
then so does recurrence-utc ... Would it be better if this was called
something like recurrence-utc-with-periods?
A similar comment applies to recurrence-time-zone-with-date-times?
Minor level comments:
(5) p 7, sec 3.3.1. The "generic-schedule-params" Grouping
+-- discard-action? identityref
grouping period-of-time:
...
grouping recurrence-basic:
...
grouping recurrence-utc:
...
grouping recurrence-with-time-zone:
...
grouping recurrence-utc-with-date-times:
...
grouping recurrence-time-zone-with-date-times:
...
grouping icalendar-recurrence:
...
grouping schedule-status:
...
grouping schedule-status-with-name:
...
This module defines a lot of very similar groupings. I am slightly concerned
that this gives too many options and variants for doing it in different ways.
I think that it may be nicer if we offered fewer choices for the recurrence
groups, which would presumably mean that when it is used, it is used in a more
standard way.
I.e., perhaps recurrence-basic, recurrence-utc, and
recurrence-time-zone-with-date-times would be sufficient, and then the module
using these grouping could deviate remove the parts that they don't need?
(6) p 13, sec 3.3.5. The "recurrence-with-time-zone" Grouping
grouping generic-schedule-params:
...
grouping period-of-time:
...
grouping recurrence-basic:
...
grouping recurrence-utc:
...
grouping recurrence-with-time-zone:
+-- recurrence-first
| +-- start-time? yang:date-and-time
| +-- duration? duration
| +-- time-zone-identifier? sys:timezone-name
+-- (recurrence-end)?
| +--:(until)
| | +-- until? yang:date-and-time
| +--:(count)
| +-- count? uint32
+-- recurrence-description? string
+-- frequency identityref
+-- interval? uint32
Does the time-zone-identifier only relate the start-time (because it is under
the recurrence-first container) or also the until time?
Nit level comments:
(7) p 41, sec 7. Security Considerations
The "ietf-schedule" module defines a set of types and groupings.
These nodes are intended to be reused by other YANG modules. The
module by itself does not expose any data nodes that are writable,
data nodes that contain read-only state, or RPCs. As such, there are
no additional security issues related to the "ietf- schedule" module
that need to be considered.
you seem to have an extra space lurking in "ietf- schedule".
Kind regards,
Rob
From: James Cumming (Nokia) <james.cumming=40nokia....@dmarc.ietf.org>
Date: Thursday, 16 January 2025 at 22:39
To: draft-ietf-netmod-schedule-y...@ietf.org
<draft-ietf-netmod-schedule-y...@ietf.org>
Cc: NETMOD WG Chairs <netmod-cha...@ietf.org>, netmod@ietf.org <netmod@ietf.org>
Subject: [netmod] WG Last Call - A Common YANG Data Model for Scheduling
All,
This starts working group last call on the Common YANG Data Model for
Scheduling draft.
https://datatracker.ietf.org/doc/draft-ietf-netmod-schedule-yang/03/
The IPR call prior to WGLC is concluded with no IPR was previously disclosed.
(Thread:
https://mailarchive.ietf.org/arch/search/?as=1&email_list=&end_date=&q=subject%3A%28+IPR+call+prior+to+WGLC+-+A+Common+YANG+Data+Model+for+Scheduling%29&qdr=a&start_date=)
The working group last call ends on January 31st.
Please send your comments to the working group mailing list.
Positive comments, e.g., "I've reviewed this document and believe it is ready
for publication", are welcome!
This is useful and important, even from authors.
Thank you,
James (Document shepherd)
_______________________________________________
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
