Diff: rfc9922v1.md - rfc9922.md

	rfc9922v1.md	rfc9922.md

	skipping to change at line 55 ¶	skipping to change at line 55 ¶
	code: 35000	code: 35000
	country: France	country: France
	email: mohamed.boucadair@orange.com	email: mohamed.boucadair@orange.com
	-	-
	fullname: Daniel King	fullname: Daniel King
	organization: Lancaster University	organization: Lancaster University
	country: United Kingdom	country: United Kingdom
	email: d.king@lancaster.ac.uk	email: d.king@lancaster.ac.uk

	normative:	normative:

	W3C.XML1.0:
	target: https://www.w3.org/TR/2008/REC-xml-20081126/
	title: "Extensible Markup Language (XML) 1.0 (Fifth Edition)"
	date: 2008-11-26
	author:
	- name: Tim Bray
	role: editor
	- name: Jean Paoli
	role: editor
	- name: C. M. Sperberg-McQueen
	role: editor
	- name: Eve Maler
	role: editor
	- name: Francois Yergeau
	role: editor
	rc:
	W3C Recommendation

	informative:	informative:
	I-D.ietf-netmod-eca-policy:	I-D.ietf-netmod-eca-policy:
	display: NETMOD-ECA-POLICY	display: NETMOD-ECA-POLICY

	I-D.ietf-netmod-rfc8407bis:	I-D.ietf-netmod-rfc8407bis:
	display: YANG-GUIDE	display: YANG-GUIDE

	I-D.ietf-ntp-ntpv5:	I-D.ietf-ntp-ntpv5:
	display: NTPv5	display: NTPv5

	skipping to change at line 95 ¶	skipping to change at line 78 ¶

	I-D.ietf-opsawg-ucl-acl:	I-D.ietf-opsawg-ucl-acl:
	display: YANG-NAC	display: YANG-NAC

	I-D.ietf-tvr-schedule-yang:	I-D.ietf-tvr-schedule-yang:
	display: YANG-SCHEDULE	display: YANG-SCHEDULE

	I-D.liu-netmod-yang-schedule:	I-D.liu-netmod-yang-schedule:
	display: YANG-CONFIG-SCHEDULE	display: YANG-CONFIG-SCHEDULE


		W3C.XML1.0:
		target: https://www.w3.org/TR/2008/REC-xml-20081126/
		title: "Extensible Markup Language (XML) 1.0 (Fifth Edition)"
		date: 2008-11-26
		author:
		- name: Tim Bray
		role: editor
		- name: Jean Paoli
		role: editor
		- name: C. M. Sperberg-McQueen
		role: editor
		- name: Eve Maler
		role: editor
		- name: Francois Yergeau
		role: editor
		rc:
		W3C Recommendation

	--- abstract	--- abstract

	<!-- [rfced] FYI - We will do the following when we convert the file to RFCXML:	<!-- [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	- compact the spacing of the definition lists in Sections 8.1 and 8.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

	This document defines common types and groupings that are meant to be used	This document defines common types and groupings that are meant to be used
	for scheduling purposes, such as events, policies, services, or resources based on	for scheduling purposes, such as events, policies, services, or resources based on
	date and time. For the sake of better modularity, the YANG module includes a	date and time. For the sake of better modularity, the YANG module includes a
	set of recurrence-related groupings with varying levels of representation	set of recurrence-related groupings with varying levels of representation
	(i.e., from basic to advanced) to accommodate a variety of requirements.	(i.e., from basic to advanced) to accommodate a variety of requirements.
	It also defines groupings for validating requested schedules and reporting schedul ing statuses.	It also defines groupings for validating requested schedules and reporting schedul ing statuses.

	--- middle	--- middle

	# Introduction {#intro}	# Introduction {#intro}

	skipping to change at line 136 ¶	skipping to change at line 126 ¶
	{{?I-D.ietf-opsawg-ucl-acl}}, {{?I-D.ietf-opsawg-scheduling-oam-tests}},	{{?I-D.ietf-opsawg-ucl-acl}}, {{?I-D.ietf-opsawg-scheduling-oam-tests}},
	and {{?I-D.ietf-tvr-schedule-yang}}. The module includes a set of reusable groupings that	and {{?I-D.ietf-tvr-schedule-yang}}. The module includes a set of reusable groupings that
	are designed to be applicable for scheduling purposes, such as events, policies,	are designed to be applicable for scheduling purposes, such as events, policies,
	services, or resources based on date and time. It also defines groupings for validati ng	services, or resources based on date and time. It also defines groupings for validati ng
	requested schedules and reporting scheduling statuses.	requested schedules and reporting scheduling statuses.

	This document does not make any assumption about the nature of actions that are	This document does not make any assumption about the nature of actions that are
	triggered by the schedules. Detection and resolution of any schedule conflicts	triggered by the schedules. Detection and resolution of any schedule conflicts
	are beyond the scope of this document.	are beyond the scope of this document.


	<!--[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].

	{{sec-mib}} discusses the relationship with the Management Information Base (MIB)	{{sec-mib}} discusses the relationship with the Management Information Base (MIB)
	managed objects for scheduling management operations defined in {{!RFC3231}}.	managed objects for scheduling management operations defined in {{!RFC3231}}.

	{{usage}} describes a set of examples to illustrate the use of the common schedule gr oupings ({{sec-grp}}).	{{usage}} describes a set of examples to illustrate the use of the common schedule gr oupings ({{sec-grp}}).
	{{sec-ext}} provides sample modules to exemplify how future modules can use the exten sibility	{{sec-ext}} provides sample modules to exemplify how future modules can use the exten sibility
	provisions in the "ietf-schedule" module ({{sec-schedule}}). Also, {{ex-framework}} p rovides	provisions in the "ietf-schedule" module ({{sec-schedule}}). Also, {{ex-framework}} p rovides
	an example of using the "ietf-schedule" module for scheduled use of a resources frame work (e.g., {{?RFC8413}}).	an example of using the "ietf-schedule" module for scheduled use of a resources frame work (e.g., {{?RFC8413}}).

	# Conventions and Definitions	# Conventions and Definitions


	skipping to change at line 194 ¶	skipping to change at line 170 ¶
	iCalendar:	iCalendar:
	: Refers to Internet Calendaring per {{!RFC5545}}.	: Refers to Internet Calendaring per {{!RFC5545}}.

	Interval:	Interval:
	: Refers to an integer that specifies the interval at which a recurrence rule repeats . Values are taken from the "INTERVAL" rule in {{Section 3.3.10 of !RFC5545}}.	: Refers to an integer that specifies the interval at which a recurrence rule repeats . Values are taken from the "INTERVAL" rule in {{Section 3.3.10 of !RFC5545}}.
	: For example, "1" means every second for a secondly rule, every minute for a minutel y rule, every hour for an hourly rule, etc.	: For example, "1" means every second for a secondly rule, every minute for a minutel y rule, every hour for an hourly rule, etc.

	System:	System:
	: Refers to an entity that hosts a schedule that is managed using the YANG module def ined in this document.	: Refers to an entity that hosts a schedule that is managed using the YANG module def ined in this document.


		"schedule-status-*" refers to any of "schedule-status", "schedule-status-with-time-zo
		ne", and "schedule-status-with-name".

	# Module Overview {#sec-overview}	# Module Overview {#sec-overview}

	## Features {#sec-features}	## Features {#sec-features}

	The "ietf-schedule" data model defines the recurrence-related groupings using	The "ietf-schedule" data model defines the recurrence-related groupings using
	a modular approach. To that aim, a variety of representations of recurrence	a modular approach. To that aim, a variety of representations of recurrence
	groupings ranging from basic to advanced (iCalender-like) are defined.	groupings ranging from basic to advanced (iCalender-like) are defined.
	To allow for different options, two features are defined in the data model:	To allow for different options, two features are defined in the data model:

	* "basic-recurrence"	* "basic-recurrence"
	* "icalendar-recurrence"	* "icalendar-recurrence"

	Refer to {{sec-aug}} and {{features}} for the use of these features.	Refer to {{sec-aug}} and {{features}} for the use of these features.

	## Types and Identities {#sec-types}	## Types and Identities {#sec-types}

	The "ietf-schedule" module ({{sec-schedule}}) defines the following identities:	The "ietf-schedule" module ({{sec-schedule}}) defines the following identities:

	* "schedule-type": Indicates the type of schedule. The following types are defined so far:	* "schedule-type": Indicates the type of schedule. The following types are defined so far:

	+ one-shot: The schedule will trigger an action that has either the duration sp ecified as 0 or the end time specified as the same as the start time, and then the sc hedule will disable itself ({{Section 3.3 of !RFC3231}}).	+ one-shot: This type is used for a schedule that triggers an action that has e ither the duration specified as 0 or the end time specified as the same as the start time, and then the schedule will disable itself ({{Section 3.3 of !RFC3231}}).
	+ period: This type is used for a period-based schedule consisting of either (1 ) a start and end or (2) a start and positive duration of time. If neither an end nor a duration is indicated, the period is considered to last forever.	+ period: This type is used for a period-based schedule consisting of either (1 ) a start and end or (2) a start and positive duration of time. If neither an end nor a duration is indicated, the period is considered to last forever.
	+ recurrence: This type is used for a recurrence-based schedule. A recurrence m ay be periodic (i.e., repeat over the same period, e.g., every five minutes) or not ( i.e., repeat in a non-regular manner, e.g., every day at 8 and 9 AM).	+ recurrence: This type is used for a recurrence-based schedule. A recurrence m ay be periodic (i.e., repeat over the same period, e.g., every five minutes) or not ( i.e., repeat in a non-regular manner, e.g., every day at 8 and 9 AM).
	* "frequency-type": Characterizes the repeating interval rule of a recurrence sche dule (secondly, minutely, etc.).	* "frequency-type": Characterizes the repeating interval rule of a recurrence sche dule (secondly, minutely, etc.).
	* "schedule-state": Indicates the status of a schedule (enabled, disabled, conflic ted, finished, etc.). This identity can also be used	* "schedule-state": Indicates the status of a schedule (enabled, disabled, conflic ted, finished, etc.). This identity can also be used
	to manage the state of individual instances of a recurrence-based schedule.	to manage the state of individual instances of a recurrence-based schedule.
	* "discard-action-type": Specifies the action for the responder to take (e.g., gen erate a warning or an error message) when	* "discard-action-type": Specifies the action for the responder to take (e.g., gen erate a warning or an error message) when
	a requested schedule cannot be accepted for any reason and is discarded.	a requested schedule cannot be accepted for any reason and is discarded.

	## Scheduling Groupings {#sec-grp}	## Scheduling Groupings {#sec-grp}


	skipping to change at line 267 ¶	skipping to change at line 245 ¶

	The "description" parameter includes a description of the schedule. No constraint is imposed	The "description" parameter includes a description of the schedule. No constraint is imposed
	on the structure nor the use of this parameter.	on the structure nor the use of this parameter.

	The "time-zone-identifier" parameter, if provided, specifies the	The "time-zone-identifier" parameter, if provided, specifies the
	time zone reference {{!RFC7317}} of the local date and time values. This parameter	time zone reference {{!RFC7317}} of the local date and time values. This parameter
	MUST be specified if any of the date and time values are in the format of local ti me.	MUST be specified if any of the date and time values are in the format of local ti me.
	It MUST NOT be applied to date and time values that are specified in the format	It MUST NOT be applied to date and time values that are specified in the format
	of UTC or time zone offset to UTC.	of UTC or time zone offset to UTC.


	<!--[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.

	The "validity" parameter specifies the date and time after which a schedule	The "validity" parameter specifies the date and time after which a schedule
	will not be considered as valid. It determines the latest time that a schedule	will not be considered as valid. It determines the latest time that a schedule

	can be started to execute independent of when it ends, and it takes precedence ove r	can be started and thus executed independently from when it ends, and it takes pre cedence over
	similar attributes that are provided at the schedule instance itself. A requested	similar attributes that are provided at the schedule instance itself. A requested
	schedule may still be accepted, but any occurrences that start later than the conf igured value will not be executed.	schedule may still be accepted, but any occurrences that start later than the conf igured value will not be executed.

	The "max/min-allowed-start" parameters specify the maximum/minimum scheduled	The "max/min-allowed-start" parameters specify the maximum/minimum scheduled
	start date and time. A requested schedule will be rejected if the first	start date and time. A requested schedule will be rejected if the first
	occurrence of the schedule starts later/earlier than the configured values.	occurrence of the schedule starts later/earlier than the configured values.

	The "max-allowed-end" parameter specifies the maximum allowed end time of	The "max-allowed-end" parameter specifies the maximum allowed end time of
	the last occurrence. A requested schedule will be rejected if the end time	the last occurrence. A requested schedule will be rejected if the end time
	of the last occurrence is later than the configured "max-allowed-end" value.	of the last occurrence is later than the configured "max-allowed-end" value.

	The "discard-action" parameter specifies the action if a requested schedule	The "discard-action" parameter specifies the action if a requested schedule
	cannot be accepted for any reason and is discarded. Possible reasons include,	cannot be accepted for any reason and is discarded. Possible reasons include,
	but are not limited to, the requested schedule failing to satisfy the guards in th is grouping,	but are not limited to, the requested schedule failing to satisfy the guards in th is grouping,
	conflicting with existing schedules, or being out-of-date (e.g., the expected star t has already passed).	conflicting with existing schedules, or being out-of-date (e.g., the expected star t has already passed).


	<!--[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	These parameters apply to all schedules on a system and are meant
	to provide guards against stale configuration, schedule requests	to provide guards against stale configuration, schedule requests

	that are too short and that would thus prevent validation by admins	that are too short and that would thus prevent validation by admins of some critic
	of some critical systems, etc.	al systems, etc.

	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.

	### The "period-of-time" Grouping {#sec-period}	### The "period-of-time" Grouping {#sec-period}

	The "period-of-time" grouping ({{pt-tree}}) represents a time period using	The "period-of-time" grouping ({{pt-tree}}) represents a time period using
	either a start date and time ("period-start") and end date and time ("period-end") or a	either a start date and time ("period-start") and end date and time ("period-end") or a
	start date and time ("period-start") and a non-negative time duration ("duration") . For the first	start date and time ("period-start") and a non-negative time duration ("duration") . For the first
	format, the start of the period MUST be no later than the end of the period. If ne ither an end date and time ("period-end")	format, the start of the period MUST be no later than the end of the period. If ne ither an end date and time ("period-end")
	nor a duration ("duration") is indicated, the period is considered to last forever .	nor a duration ("duration") is indicated, the period is considered to last forever .
	If the duration ("duration") value is 0 or the end time ("period-end") is the same as the start time ("period-start"), the period	If the duration ("duration") value is 0 or the end time ("period-end") is the same as the start time ("period-start"), the period
	is considered as a one-shot schedule. If no start date and time ("period-start")	is considered as a one-shot schedule. If no start date and time ("period-start")

	skipping to change at line 375 ¶	skipping to change at line 318 ¶
	+-- interval? uint32	+-- interval? uint32
	~~~~	~~~~
	{: #rec-grp-tree title="'recurrence-basic' Grouping Tree Structure"}	{: #rec-grp-tree title="'recurrence-basic' Grouping Tree Structure"}

	The frequency parameter ("frequency") identifies the type of recurrence rule. For e xample,	The frequency parameter ("frequency") identifies the type of recurrence rule. For e xample,
	a "daily" frequency value specifies repeating events based on an interval of a day or more.	a "daily" frequency value specifies repeating events based on an interval of a day or more.

	Consistent with {{Section 3.3.10 of !RFC5545}}, the interval parameter ("interval") represents at which interval the recurrence rule repeats. For example,	Consistent with {{Section 3.3.10 of !RFC5545}}, the interval parameter ("interval") represents at which interval the recurrence rule repeats. For example,
	within a "daily" recurrence rule, an interval value of "8" means every eight days.	within a "daily" recurrence rule, an interval value of "8" means every eight days.


	<!-- [rfced] We note that Section 4.13 of [I-D.ietf-netmod-rfc8407bis] mentions	Note that, per {{Section 4.13 of ?I-D.ietf-netmod-rfc8407bis}}, no "default"
	"default" but doesn't mention "mandatory"; however, Section 4.14	substatement is defined here for both "frequency" and "interval"
	mentions both "default" and "mandatory". Should the citations below be updated	parameters because there are cases (e.g., profiling) where using these statements i
	to point to Section 4.14 instead?	s problematic. No "mandatory" substatement is defined here for the same reason.

	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.

	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 i
	s problematic.
	YANG modules using this grouping SHOULD refine these two nodes with either a	YANG modules using this grouping SHOULD refine these two nodes with either a
	"mandatory" or a "default" statement if they always need to be configured or have d efault values.	"mandatory" or a "default" statement if they always need to be configured or have d efault values.
	This recommendation MAY be ignored in cases such as when this grouping is used by a nother grouping.	This recommendation MAY be ignored in cases such as when this grouping is used by a nother grouping.

	The "recurrence-description" parameter includes a description of the period. No con straint is imposed	The "recurrence-description" parameter includes a description of the period. No con straint is imposed
	on the structure nor the use of this parameter.	on the structure nor the use of this parameter.

	### The "recurrence-utc" Grouping {#sec-rec-utc}	### The "recurrence-utc" Grouping {#sec-rec-utc}

	The "recurrence-utc" grouping ({{rec-utc-grp-tree}}) uses the "recurrence-basic"	The "recurrence-utc" grouping ({{rec-utc-grp-tree}}) uses the "recurrence-basic"

	skipping to change at line 517 ¶	skipping to change at line 443 ¶
	\| +-- count? uint32	\| +-- count? uint32
	+-- recurrence-description? string	+-- recurrence-description? string
	+-- frequency? identityref	+-- frequency? identityref
	+-- interval? uint32	+-- interval? uint32
	+-- period-timeticks* [period-start]	+-- period-timeticks* [period-start]
	+-- period-start yang:timeticks	+-- period-start yang:timeticks
	+-- period-end? yang:timeticks	+-- period-end? yang:timeticks
	~~~~	~~~~
	{: #rec-utc-dt-grp-tree title="'recurrence-utc-with-periods' Grouping Tree Structure" }	{: #rec-utc-dt-grp-tree title="'recurrence-utc-with-periods' Grouping Tree Structure" }


	<!--[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...

	The recurrence instances are specified by the union of occurrences defined	The recurrence instances are specified by the union of occurrences defined
	by both the recurrence rule and "period-timeticks" list. This list uses the	by both the recurrence rule and "period-timeticks" list. This list uses the

	"yang:timeticks" type defined in {{!RFC6991}}. Duplicate instances	"yang:timeticks" type defined in {{!RFC9911}}. Duplicate instances
	are ignored. The value of the "period-start" instance MUST NOT exceed the	are ignored. The value of the "period-start" instance MUST NOT exceed the

	value indicated by the value of the "frequency" instance, i.e., the "timeticks"	value of the "frequency" instance, i.e., the "timeticks"
	value must not exceed 100 in a secondly recurrence rule, and it must not	value must not exceed 100 in a secondly recurrence rule, and it must not
	exceed 6000 in a minutely recurrence rule, and so on.	exceed 6000 in a minutely recurrence rule, and so on.

	### The "recurrence-time-zone-with-periods" Grouping {#sec-rec-tz-dt}	### The "recurrence-time-zone-with-periods" Grouping {#sec-rec-tz-dt}

	The "recurrence-time-zone-with-periods" grouping ({{rec-tz-dt-grp-tree}}) uses	The "recurrence-time-zone-with-periods" grouping ({{rec-tz-dt-grp-tree}}) uses
	the "recurrence-with-time-zone" grouping ({{sec-rec-tz}}) and	the "recurrence-with-time-zone" grouping ({{sec-rec-tz}}) and
	adds a "period" list to define an aggregate set of repeating occurrences.	adds a "period" list to define an aggregate set of repeating occurrences.

	~~~~ yangtree	~~~~ yangtree

	skipping to change at line 648 ¶	skipping to change at line 562 ¶

	The "bysetpos" conveys a list of values that corresponds to the nth occurrence	The "bysetpos" conveys a list of values that corresponds to the nth occurrence
	within the set of recurrence instances to be specified. For example, in a "monthly "	within the set of recurrence instances to be specified. For example, in a "monthly "
	recurrence rule, the "byday" data node specifies every Monday of the week, and the	recurrence rule, the "byday" data node specifies every Monday of the week, and the
	"bysetpos" with a value of "-1" represents the last Monday of the month.	"bysetpos" with a value of "-1" represents the last Monday of the month.
	Not setting the "bysetpos" data node represents every Monday of the month.	Not setting the "bysetpos" data node represents every Monday of the month.

	The "workweek-start" data node specifies the day on which the week starts. This is	The "workweek-start" data node specifies the day on which the week starts. This is
	significant when a "weekly" recurrence rule has an interval greater than 1, and	significant when a "weekly" recurrence rule has an interval greater than 1, and
	a "byday" data node is specified. This is also significant when in a "yearly" rule	a "byday" data node is specified. This is also significant when in a "yearly" rule

	and a "byyearweek" is specified. Note that, per {{Section 4.13 of ?I-D.ietf-netmod	and a "byyearweek" is specified. Note that, per {{Section 4.13 of ?I-D.ietf-netmod
	-rfc8407bis}}, neither a "default"	-rfc8407bis}}, no "default"
	nor a "mandatory" substatement is defined here because there are cases (e.g., prof	substatement is defined here because there are cases (e.g., profiling)
	iling)	where using these statements is problematic. No "mandatory" substatement is define
	where using these statements is problematic.	d here for the same reason.
	YANG modules using this grouping SHOULD refine the "workweek-start" node with eith er a	YANG modules using this grouping SHOULD refine the "workweek-start" node with eith er a
	"mandatory" or a "default" statement if it always needs to be configured or has a default value.	"mandatory" or a "default" statement if it always needs to be configured or has a default value.
	This MAY be ignored in cases such as when this grouping is used by another groupin g.	This MAY be ignored in cases such as when this grouping is used by another groupin g.

	The "exception-dates" data node specifies a list of exceptions for recurrence. The	The "exception-dates" data node specifies a list of exceptions for recurrence. The
	final recurrence set is generated by gathering all of the date and time values	final recurrence set is generated by gathering all of the date and time values
	created by any of the specified recurrence rules and date-times and then	created by any of the specified recurrence rules and date-times and then
	excluding any start date and time values specified by "exception-dates" parameter.	excluding any start date and time values specified by "exception-dates" parameter.

	### The "schedule-status", "schedule-status-with-time-zone", and "schedule-status-wit h-name" Groupings {#sec-schedule-status}	### The "schedule-status", "schedule-status-with-time-zone", and "schedule-status-wit h-name" Groupings {#sec-schedule-status}

	The "schedule-status", "schedule-status-with-time-zone", and "schedule-status-with -name" groupings ({{sche-status-tree}}) define common parameters	The "schedule-status", "schedule-status-with-time-zone", and "schedule-status-with -name" groupings ({{sche-status-tree}}) define common parameters
	for scheduling management/status exposure. The "schedule-status-with-time-zone" gr ouping has the same	for scheduling management/status exposure. The "schedule-status-with-time-zone" gr ouping has the same
	structure as "schedule-status" but with an additional parameter to identify a time zone. Similarly, the "schedule-status-with-name" grouping has the same structure as "schedule-status" but with an additional parameter to identify a schedule "schedule-n ame". These	structure as "schedule-status" but with an additional parameter to identify a time zone. Similarly, the "schedule-status-with-name" grouping has the same structure as "schedule-status" but with an additional parameter to identify a schedule "schedule-n ame". These
	structures are defined in the module to allow for better modularity and flexibilit y.	structures are defined in the module to allow for better modularity and flexibilit y.


	<!--[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

	~~~~ yangtree	~~~~ yangtree
	grouping schedule-status:	grouping schedule-status:
	+-- state? identityref	+-- state? identityref
	+-- version? uint16	+-- version? uint16
	+-- schedule-type? identityref	+-- schedule-type? identityref
	+--ro local-time? yang:date-and-time	+--ro local-time? yang:date-and-time
	+--ro last-update? yang:date-and-time	+--ro last-update? yang:date-and-time
	+--ro counter? yang:counter32	+--ro counter? yang:counter32
	+--ro last-occurrence? yang:date-and-time	+--ro last-occurrence? yang:date-and-time
	+--ro upcoming-occurrence? yang:date-and-time	+--ro upcoming-occurrence? yang:date-and-time

	skipping to change at line 813 ¶	skipping to change at line 716 ¶
	\|schedLastFailure\| Not Supported \|	\|schedLastFailure\| Not Supported \|
	\|schedLastFailed\| last-failed-occurrence\|	\|schedLastFailed\| last-failed-occurrence\|
	\|schedStorageType\| Not Supported \|	\|schedStorageType\| Not Supported \|
	\|schedVariable\| Not applicable \|	\|schedVariable\| Not applicable \|
	\|schedValue\| Not applicable \|	\|schedValue\| Not applicable \|
	\|schedTriggers\| counter/failure-counter \|	\|schedTriggers\| counter/failure-counter \|
	{: #mapping title="YANG/MIB Mapping"}	{: #mapping title="YANG/MIB Mapping"}

	# The "ietf-schedule" YANG Module {#sec-schedule}	# The "ietf-schedule" YANG Module {#sec-schedule}


	<!--[rfced] FYI - As RFC 5545 is also cited within the "ietf-schedule"	This module imports types defined in {{!RFC9911}} and {{!RFC7317}}.
	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].

	<!--[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.";

	This module imports types defined in {{!RFC5545}}, {{!RFC6991}}, and {{!RFC7317}}.

	~~~~ yang	~~~~ yang
	file "ietf-schedule@2026-02-18.yang"	file "ietf-schedule@2026-02-18.yang"
	module ietf-schedule {	module ietf-schedule {
	yang-version 1.1;	yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-schedule";	namespace "urn:ietf:params:xml:ns:yang:ietf-schedule";
	prefix schedule;	prefix schedule;

	import ietf-yang-types {	import ietf-yang-types {
	prefix yang;	prefix yang;
	reference	reference

	"RFC 6991: Common YANG Data Types";	"RFC 9911: Common YANG Data Types";
	}	}

	import ietf-system {	import ietf-system {
	prefix sys;	prefix sys;
	reference	reference
	"RFC 7317: A YANG Data Model for System Management";	"RFC 7317: A YANG Data Model for System Management";
	}	}

	organization	organization
	"IETF NETMOD Working Group";	"IETF NETMOD Working Group";

	skipping to change at line 1765 ¶	skipping to change at line 1647 ¶
	RESTCONF protocol operations and content.	RESTCONF protocol operations and content.

	The "ietf-schedule" module defines a set of identities, types, and	The "ietf-schedule" module defines a set of identities, types, and
	groupings. These nodes are intended to be reused by other YANG	groupings. These nodes are intended to be reused by other YANG
	modules. The module by itself does not expose any data nodes that	modules. The module by itself does not expose any data nodes that
	are writable, data nodes that contain read-only state, or RPCs. As	are writable, data nodes that contain read-only state, or RPCs. As
	such, there are no additional security issues related to the "ietf-schedule"	such, there are no additional security issues related to the "ietf-schedule"
	module that need to be considered.	module that need to be considered.

	Modules that use the groupings that are defined in this document	Modules that use the groupings that are defined in this document

	should identify the corresponding security considerations, for example:	should identify the corresponding security considerations. For example,
		reuising the following groupings will expose privacy-related information:

	* Scheduling depends on reliable and accurate time synchronization. Inaccurate dat e	* Scheduling depends on reliable and accurate time synchronization. Inaccurate dat e
	and time setting can lead to scheduling events being triggered at incorrect	and time setting can lead to scheduling events being triggered at incorrect
	intervals, potentially causing system failures or security vulnerabilities.	intervals, potentially causing system failures or security vulnerabilities.
	* Recurring events may conceal abnormal behavior or security threats, which	* Recurring events may conceal abnormal behavior or security threats, which
	may be drowned out by normal events, especially when they are triggered frequent ly.	may be drowned out by normal events, especially when they are triggered frequent ly.
	* The absence of detailed logs and audit records of each occurrence trigger time	* The absence of detailed logs and audit records of each occurrence trigger time
	and action results and therefore may make security incidents difficult to trace.	and action results and therefore may make security incidents difficult to trace.
	* Care must be taken when defining recurrences occurring very often and	* Care must be taken when defining recurrences occurring very often and
	frequent that can be an additional source of attacks by keeping the system	frequent that can be an additional source of attacks by keeping the system

	skipping to change at line 1821 ¶	skipping to change at line 1704 ¶
	: RFC 9922	: RFC 9922

	--- back	--- back

	# Examples of Scheduling Format Representation {#usage}	# Examples of Scheduling Format Representation {#usage}

	This section provides some examples to illustrate the use of the	This section provides some examples to illustrate the use of the
	period and recurrence formats defined in {{sec-schedule}}. The following	period and recurrence formats defined in {{sec-schedule}}. The following
	modules are used for illustration purposes and make examples verifiable:	modules are used for illustration purposes and make examples verifiable:


	<!--[rfced] In Appendix A, should each example be listed in separate
	sourcecode blocks? They are all currently contained within one block of
	sourcecode.

	<!-- [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.

	~~~~ yang	~~~~ yang
	module example-sch-usage-1 {	module example-sch-usage-1 {
	yang-version 1.1;	yang-version 1.1;
	namespace "http://example.com/example-sch-usage-1";	namespace "http://example.com/example-sch-usage-1";
	prefix "ex-schu-1";	prefix "ex-schu-1";

	import ietf-schedule {	import ietf-schedule {
	prefix "schedule";	prefix "schedule";
	}	}


	skipping to change at line 2100 ¶	skipping to change at line 1972 ¶
	}	}
	~~~~	~~~~
	{: #ex-6 title="Simple Schedule with Recurrence with Time Zone Indication"}	{: #ex-6 title="Simple Schedule with Recurrence with Time Zone Indication"}

	## The "recurrence-utc-with-periods" Grouping	## The "recurrence-utc-with-periods" Grouping

	{{ex-7}} indicates a recurrence that occurs every two days starting at 9:00 AM	{{ex-7}} 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,	and 3:00 PM for a duration of 30 minutes and 40 minutes, respectively,
	from 2025-06-01 to 2025-06-30 in UTC:	from 2025-06-01 to 2025-06-30 in UTC:


	<!--[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:

	~~~~ json	~~~~ json
	{	{
	"example-sch-usage-6:recurrence-utc-with-periods": {	"example-sch-usage-6:recurrence-utc-with-periods": {
	"recurrence-first": {	"recurrence-first": {
	"start-time-utc": "2025-06-01T09:00:00Z"	"start-time-utc": "2025-06-01T09:00:00Z"
	},	},
	"frequency": "ietf-schedule:daily",	"frequency": "ietf-schedule:daily",
	"interval": 2,	"interval": 2,
	"utc-until": "2025-06-30T23:59:59Z",	"utc-until": "2025-06-30T23:59:59Z",
	"period-timeticks": [	"period-timeticks": [

	skipping to change at line 2333 ¶	skipping to change at line 2190 ¶
	organization	organization
	"Example, Inc.";	"Example, Inc.";

	contact	contact
	"Support at example.com";	"Support at example.com";

	description	description
	"Example of a module defining a scheduled-based backup	"Example of a module defining a scheduled-based backup
	operation.";	operation.";


	revision "2023-01-19" {	revision "2026-02-20" {
	description	description
	"Initial version.";	"Initial version.";
	reference	reference
	"RFC 9922: A YANG Data Model for Scheduling.";	"RFC 9922: A YANG Data Model for Scheduling.";
	}	}

	container scheduled-backup-tasks {	container scheduled-backup-tasks {
	description	description
	"A container for backing up all current running configurations	"A container for backing up all current running configurations
	on the device.";	on the device.";

	skipping to change at line 2438 ¶	skipping to change at line 2295 ¶
	}	}
	}	}
	~~~~	~~~~

	## Example: Schedule Network Properties to Change Based on Date and Time {#augments}	## Example: Schedule Network Properties to Change Based on Date and Time {#augments}

	Network properties may change over a specific period of time or based on a	Network properties may change over a specific period of time or based on a
	recurrence rule, e.g., {{?RFC9657}}.	recurrence rule, e.g., {{?RFC9657}}.
	The following example module, which augments the "recurrence-utc-with-periods"	The following example module, which augments the "recurrence-utc-with-periods"
	grouping from the "ietf-schedule" module, shows how a scheduled attribute	grouping from the "ietf-schedule" module, shows how a scheduled attribute

	could be defined.	could be defined. Note that
		{{?RFC8345}} and this document are referenced in the module.
	<!--[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.

	~~~~ yang	~~~~ yang
	module example-scheduled-link-bandwidth {	module example-scheduled-link-bandwidth {
	yang-version 1.1;	yang-version 1.1;
	namespace "http://example.com/example-scheduled-link-bandwidth";	namespace "http://example.com/example-scheduled-link-bandwidth";
	prefix "ex-scattr";	prefix "ex-scattr";

	import ietf-network {	import ietf-network {
	prefix "nw";	prefix "nw";
	reference	reference

	skipping to change at line 2483 ¶	skipping to change at line 2325 ¶

	organization	organization
	"Example, Inc.";	"Example, Inc.";

	contact	contact
	"Support at example.com";	"Support at example.com";

	description	description
	"Example of a module defining a scheduled link bandwidth.";	"Example of a module defining a scheduled link bandwidth.";


	revision "2023-01-19" {	revision "2026-02-20" {
	description	description
	"Initial version.";	"Initial version.";
	reference	reference
	"RFC 9922: A YANG Data Model for Scheduling";	"RFC 9922: A YANG Data Model for Scheduling";
	}	}

	grouping link-bandwidth-grouping {	grouping link-bandwidth-grouping {
	description	description
	"Grouping of the link bandwidth definition.";	"Grouping of the link bandwidth definition.";
	leaf scheduled-bandwidth {	leaf scheduled-bandwidth {

	skipping to change at line 2555 ¶	skipping to change at line 2397 ¶
	}	}
	}	}
	~~~~	~~~~

	{{ex-13}} shows a configuration example in XML {{W3C.XML1.0}} of a link's bandwidth that is	{{ex-13}} 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	scheduled between 2025-12-01 0:00 UTC to the end of 2025-12-31 with a daily
	schedule. In each day, the bandwidth value is scheduled to be 500 Kbps between	schedule. In each day, the bandwidth value is scheduled to be 500 Kbps between
	1:00 AM to 6:00 AM and 800 Kbps between 10:00 PM to 11:00 PM. The bandwidth	1:00 AM to 6:00 AM and 800 Kbps between 10:00 PM to 11:00 PM. The bandwidth
	value that is not covered by the period above is 1000 Kbps.	value that is not covered by the period above is 1000 Kbps.


	<!--[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/>.

	~~~ xml	~~~ xml
	<?xml version="1.0" encoding="utf-8"?>	<?xml version="1.0" encoding="utf-8"?>
	<link-attributes	<link-attributes
	xmlns="http://example.com/example-scheduled-link-bandwidth"	xmlns="http://example.com/example-scheduled-link-bandwidth"
	xmlns:schedule="urn:ietf:params:xml:ns:yang:ietf-schedule">	xmlns:schedule="urn:ietf:params:xml:ns:yang:ietf-schedule">
	<link>	<link>
	<source-node>ne1</source-node>	<source-node>ne1</source-node>
	<destination-node>ne2</destination-node>	<destination-node>ne2</destination-node>
	<default-bandwidth>1000</default-bandwidth>	<default-bandwidth>1000</default-bandwidth>
	<recurrence-first>	<recurrence-first>

	skipping to change at line 2709 ¶	skipping to change at line 2522 ¶

	Many thanks to the authors of {{?I-D.ietf-tvr-schedule-yang}}, {{?I-D.ietf-opsawg- scheduling-oam-tests}}, and {{?I-D.ietf-netmod-eca-policy}}	Many thanks to the authors of {{?I-D.ietf-tvr-schedule-yang}}, {{?I-D.ietf-opsawg- scheduling-oam-tests}}, and {{?I-D.ietf-netmod-eca-policy}}
	for the constructive discussion during IETF#118.	for the constructive discussion during IETF#118.

	Other related efforts were explored in the past, e.g., {{?I-D.liu-netmod-yang-sche dule}}.	Other related efforts were explored in the past, e.g., {{?I-D.liu-netmod-yang-sche dule}}.

	Thanks to {{{Reshad Rahman}}} for the great YANG Doctors review, {{{Mahesh Jethana ndani}}} for the AD review, {{{Per Andersson}}} for the OPSDIR review,	Thanks to {{{Reshad Rahman}}} for the great YANG Doctors review, {{{Mahesh Jethana ndani}}} for the AD review, {{{Per Andersson}}} for the OPSDIR review,
	{{{Peter Yee}}} for the GENART review, and {{{Acee Lindem}}} for the RTGDIR review .	{{{Peter Yee}}} for the GENART review, and {{{Acee Lindem}}} for the RTGDIR review .

	Thanks to {{{Éric Vyncke}}}, {{{Erik Kline}}}, and {{{Mike Bishop}}} for the IESG review.	Thanks to {{{Éric Vyncke}}}, {{{Erik Kline}}}, and {{{Mike Bishop}}} for the IESG review.


	<!-- [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.

	<!-- [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.

	<!-- [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.

End of changes. 26 change blocks.
	215 lines changed or deleted	44 lines changed or added
This html diff was produced by rfcdiff 1.48.