update description and change discard-action type as identityref #10
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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?
Med: Fixed/
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.
Med: Fixed
Section 3.1, the description is a bit sparse; also there are no examples that use this grouping. Please expand.
Qiufang: Fixed in #9.
The description inside the YANG module is old and incorrect, it says 2 groupings and focused only on iCalendar.
Qiufang: Fixed.
s/RFC XXXX: A YANG Data Model for Scheduling/RFC XXXX: A Common YANG Data Model for Scheduling/
Med: 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: Fixed
In these lists "leaf-list date-times" and "leaf-list dates", is there any ordering constraint that should be added explicitly in text?
Qiufang: No leaf-list date-times and dates definition in the current module anymore; I don't think ordering affects the recurrence rules
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.
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.
s/byminut/byminute/
Med: Fixed
Appendix A.1, the text says end date is Dec 31, 2027 but the JSON says 1st Dec - "2027-12-01T18:00:00Z"
Med: Fixed
Appendix A.2, the text says Dec 1, 2025 but the example says 1st Nov - "2025-11-01T15:00:00"
Med: Fixed