Authors and *AD,
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the source file.
*AD, please see question #11.
1) <!-- [rfced] FYI - We will do the following when we convert the file to
RFCXML:
- compact the spacing of the definition lists in Sections 8.1 and 8.2
-->
2) <!--[rfced] Note that we have updated the short title, which appears in the
running header in the PDF output, as follows. Please let us know of any
objections.
Original:
Common Schedule YANG
Current:
YANG Scheduling
-->
3) <!--[rfced] To avoid awkward hyphenation, may we update this sentence to
read as
"objects managed by MIB"?
Original:
Section 5 discusses the relationship with the Management Information
Base (MIB) managed objects for scheduling management operations
defined in [RFC3231].
Perhaps:
Section 5 discusses the relationship with the objects managed by
Management Information Base (MIB) for scheduling management operations
defined in [RFC3231].
-->
4) <!--[rfced] Please clarify "to execute independent of when it
ends". Is the meaning that the validity parameter determines when a
schedule can be started and thus "executed independently from when it
ends"?
Original:
It determines the latest time that a schedule can be started to
execute independent of when it ends and takes precedence over
similar attributes that are provided at the schedule instance
itself.
Perhaps:
It determines the latest time that a schedule can be started and
thus executed independently from when it ends, and it takes
precedence over similar attributes that are provided at the
schedule instance itself.
-->
5) <!--[rfced] May we update this sentence to make the two items
mentioned (i.e., "all schedules on a system" and "too short schedule
requests") more parallel and thus easier to read?
Original:
These parameters apply to all schedules on a system and are meant to
provide guards against stale configuration, too short schedule
requests that would prevent validation by admins of some critical
systems, etc.
Perhaps:
These parameters apply to all schedules on a system and are meant
to provide guards against stale configuration, schedule requests
that are too short and that would thus prevent validation by admins
of some critical systems, etc.
-->*
6) <!-- [rfced] We note that Section 4.13 of [I-D.ietf-netmod-rfc8407bis]
mentions
"default" but doesn't mention "mandatory"; however, Section 4.14
mentions both "default" and "mandatory". Should the citations below be updated
to point to Section 4.14 instead?
Original (Section 3.3.3):
Note that per Section 4.13 of [I-D.ietf-netmod-rfc8407bis], neither a
"default" nor a "mandatory" substatement is defined here for both
"frequency" and "interval" parameters because there are cases (e.g.,
profiling) where using these statements is problematic.
Original (Section 3.3.8):
Note that per Section 4.13 of [I-D.ietf-netmod-rfc8407bis], neither a
"default" nor a "mandatory" substatement is defined here because there
are cases (e.g., profiling) where using these statements is problematic.
-->
7) <!--[rfced] For conciseness, may we shorten "the value indicated by the
value
of the..." in the sentence below as follows?
Original:
The value of the "period-start" instance MUST
NOT exceed the value indicated by the value of "frequency" instance...
Perhaps:
The value of the "period-start" instance MUST
NOT exceed the value of the "frequency" instance...
-->
8) <!--[rfced] In the title of Figure 9, is the asterisk (*) in
"schedule-status-*" correct? We ask as we do not see this elsewhere in
the document.
Current:
Figure 9: 'schedule-status-*' Groupings Tree Structure
Perhaps:
Figure 9: 'schedule-status' Groupings Tree Structure
-->
9) <!--[rfced] FYI - As RFC 5545 is also cited within the "ietf-schedule"
module, we've added it to the list of RFCs preceding the module.
Original:
This module imports types defined in [RFC6991] and [RFC7317].
Current:
This module imports types defined in [RFC5545], [RFC6991], and [RFC7317].
-->
10) <!--[rfced] FYI - We made the following update to the format in the
"ietf-schedule" YANG module using the formatting option of pyang.
Original:
error-message
"Frequency must be provided.";
Current:
error-message "Frequency must be provided.";
-->
11) <!--[rfced] *AD - Security Considerations Questions
a) FYI - We updated the Security Considerations section to
match the template at
<https://wiki.ietf.org/group/ops/yang-security-guidelines>.
Please review and let us know if any further updates are
needed.
b) As the Writable nodes, Readable nodes, and RFC/action operations
sections are not applicable to this document, do the following
sentences need to be added accordingly (per the template)?
- "There are no particularly sensitive writable data nodes."
- "There are no particularly sensitive readable data nodes."
- "There are no particularly sensitive RPC or action operations."
c) We note that in the paragraph that relates to the "No data nodes"
section, there is a sentence missing (i.e., from the template: "For
example, reusing some of these groupings will expose privacy-related
information (e.g., 'node-example')". Is that omission intentional or
should it be added for clarity?
>From the template:
Modules that use the groupings that are defined in this document
should identify the corresponding security considerations. For
example, reusing some of these groupings will expose
privacy-related information (e.g., 'node-example').
Current text in the document:
Modules that use the groupings that are defined in this document
should identify the corresponding security considerations, for
example:
-->
12) <!--[rfced] In Appendix A, should each example be listed in separate
sourcecode blocks? They are all currently contained within one block of
sourcecode.
-->
13) <!-- [rfced] FYI, the YANG examples (example-sch-usage-1 - 8.yang and
example-scheduled-backup.yang, example-scheduled-link-bandwidth.yang,
and example-sch-capacity-res.yang) each give errors and warnings from
pyang -ietf. Please confirm this is as expected.
-->
14) <!--[rfced] We note that dates are formatted in different ways in
Appendix A. For example, "January 31, 2025" and "2025-06-01" are used
in Appendices A.1 and A.6, respectively. If these instances should be
consistent, please let us know which form you prefer.
Original:
Figure 10 illustrates the example of a requested schedule that needs
to start no earlier than 08:00 AM, January 1, 2025 and end no later
than 8:00 PM, January 31, 2025 (Beijing time).
...
Figure 18 indicates a recurrence that occurs every two days starting
at 9:00 AM and 3:00 PM for a duration of 30 minutes and 40 minutes
respectively, from 2025-06-01 to 2025-06-30 in UTC:
-->
15) <!--[rfced] The example module in Appendix B references RFC 8345 but
no corresponding reference entry exists. May we add RFC 8345 under the
Informative References section and update the running text as follows?
Original:
The following example module which augments the
"recurrence-utc-with-periods" grouping from "ietf-schedule" module
shows how a scheduled attribute could be defined.
Perhaps:
The following example module, which augments the
"recurrence-utc-with-periods" grouping from "ietf-schedule" module,
shows how a scheduled attribute could be defined. Note that
[RFC8345] and this document are referenced in the module.
-->
16) <!--[rfced] FYI, a normative reference to the XML specification has
been added because this document contains XML.
See the IESG statement on "Guidelines for the Use of Formal
Languages in IETF Specifications"
(https://ietf.org/blog/guidelines-use-formal-languages-ietf-specifications/) -
specifically "The use of a language requires a reference to the
specification for that language. This reference is normative, and
needs to fulfil the usual requirements for normative references
(Section 7 of RFC 2026)." Please review where the XML specification
is cited and let us know if you prefer otherwise.
Original:
Figure 24 shows a configuration example of a link's bandwidth that is
scheduled between 2025-12-01 0:00 UTC to the end of 2025-12-31 with a
daily schedule.
Current:
Figure 24 shows a configuration example in XML [W3C.XML1.0]
of a link's bandwidth that is scheduled between 2025-12-01 0:00 UTC
to the end of 2025-12-31 with a daily schedule.
Normative Reference Entry:
[W3C.XML1.0]
Bray, T., Ed., Paoli, J., Ed., Sperberg-McQueen, C.M., Ed., Maler,
E., Ed., and F. Yergeau, Ed., "Extensible Markup Language (XML)
1.0 (Fifth Edition)", W3C Recommendation, 26 November 2008,
<https://www.w3.org/TR/2008/REC-xml-20081126/>.
-->
17) <!-- [rfced] Please review the language set for each instance of sourcecode
in the MD file to ensure correctness. If the current list of preferred
values for languages
(https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types)
does not contain an applicable language, then feel free to let us know.
Also, it is acceptable to leave the language not set.
-->
18) <!-- [rfced] RFC 6991 has been obsoleted by RFC 9911. May we replace RFC
6991 with RFC 9911? If yes, this will include updating the references in the
YANG module.
-->
19) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
Thank you.
Alanna Paloma and Karen Moore
RFC Production Center
On Feb 19, 2026, at 2:40 PM, RFC Editor via auth48archive
<[email protected]> wrote:
*****IMPORTANT*****
Updated 2026/02/18
RFC Authors:
Your document has now entered AUTH48.
The document was edited in kramdown-rfc as part of the RPC pilot test (see
https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc).
Please review the procedures for AUTH48 using kramdown-rfc:
https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_instructions_completing_auth48_using_kramdown
Once your document has completed AUTH48, it will be published as
an RFC.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9922.md
https://www.rfc-editor.org/authors/rfc9922.html
https://www.rfc-editor.org/authors/rfc9922.pdf
https://www.rfc-editor.org/authors/rfc9922.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9922-diff.html
https://www.rfc-editor.org/authors/rfc9922-rfcdiff.html (side by side)
Diff of the kramdown:
https://www.rfc-editor.org/authors/rfc9922-md-diff.html
https://www.rfc-editor.org/authors/rfc9922-md-rfcdiff.html (side by side)
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9922
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
