]> Huawei

101 Software Avenue, Yuhua District Jiangsu 210012 China maqiufang1@huawei.com

Huawei

101 Software Avenue, Yuhua District Jiangsu 210012 China bill.wu@huawei.com

Orange

Rennes 35000 France mohamed.boucadair@orange.com

Lancaster University

United Kingdom d.king@lancaster.ac.uk

Operations and Management netmod calendaring scheduling YANG groupings This document defines a common schedule YANG module which is designed to be applicable for scheduling purposes such as event, policy, services, or resources based on date and time. For the sake of better modularity, the module includes basic, intermediate, and advanced versions of recurrence related groupings.

Introduction This document defines a common schedule YANG module ("ietf-schedule") that can be used in several scheduling contexts, e.g., (but not limited to) , , and . The module includes a set of reusable groupings which are designed to be applicable for scheduling purposes such as event, policy, services or resources based on date and time. Examples to illustrate the use of the common groupings are provided in . Also, sample modules to exemplify how future modules can use the extensibility provisions in "ietf-schedule" are provided in .

Editorial Note (To be removed by RFC Editor) Note to the RFC Editor: This section is to be removed prior to publication. This document contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Please apply the following replacements: XXXX --> the assigned RFC number for this draft 2024-04-16 --> the actual date of the publication of this document

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The meanings of the symbols in tree diagrams are defined in . Also, this document uses the YANG terminology defined in .

Module Overview The "ietf-schedule" module () defines the following groupings: "generic-schedule-params" () "period-of-time" () "recurrence" () "recurrence-utc" () "recurrence-with-time-zone" () "recurrence-utc-with-date-times" () "recurrence-time-zone-with-date-times" () "icalendar-recurrence" () "schedule-status" () provides an overview of the tree structure of the "ietf-schedule" module in terms of its groupings.

Each of these groupings is presented in the following subsections. Examples are provided in .

The "generic-schedule-params" Grouping A system accepts and handles the schedule requests, which may help further automate the scheduling process of events, policy, services, or resources based on date and time. The "generic-schedule-params" grouping () specifies a set of configuration parameters that are used by a system for validating requested schedules.

The "time-zone-identifier" parameter, if provided, specifies the time zone reference of the date and time values with local time format. The "validity" parameter specifies the date and time after which a schedule will be considered as invalid. It determines the latest time that a schedule can be executed by a system and takes precedence over similar attributes that are provided at the schedule instance itself. The "max/min-allowed-start" parameters specify the maximum/minimum scheduled start date and time, a requested schedule will be rejected if the first occurrence of the schedule is later/earlier than the configured values. 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 of last occurrence is later than the configured "max-allowed-end" value. The "discard-action" parameter specifies the action if a requested schedule is considered inactive or out-of-date. 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 The "period-of-time" grouping () represents a time period using either a start ("period-start") and end date and time ("period-end"), or a start ("period-start") and a positive time duration ("duration"). For the first format, the start of the period MUST be before the end of the period.

The "recurrence" Grouping The "recurrence" grouping () specifies a simple recurrence rule.

The "recurrence-first" container defines the first instance in the recurrence set, and the "date-time-start" specifies the date and time at which the first instance in the recurrence set occurs. The frequency ("frequency") which is mandatory, identifies the type of recurrence rule. For example, a "daily" frequency value specifies repeating events based on an interval of a day or more. The interval ("interval") represents at which intervals the recurrence rule repeats. For example, within a daily recurrence rule, an interval value of "8" means every eight days. The default value is "1", meaning every second for a secondly recurrence rule, every minute for a minutely rule, every hour for an hourly rule, every day for a daily rule, and so on. Note that per , no "default" substatement is used here because there are cases (e.g., profiling) where the use of the default is problematic. The repetition can be scoped by a specified end time or by a count of occurrences, indicated by the "recurrence-bound" choice. The "date-time-start" value always counts as the first occurrence.

The "recurrence-utc" Grouping The "recurrence-utc" grouping () specifies a simple recurrence rule in UTC format.

The "recurrence-utc" grouping refines the "recurrence" grouping to require that the date and time values to describe the recurrence be reported in UTC format. It also augments the "recurrence-first" container with a parameter "duration" in units of seconds to allow the time period of the first occurrence to be specified. The "duration" also applies to subsequent recurrence instances. The "recurrence-utc" grouping is designed to be reused in scheduling contexts where machine readability is more desirable.

The "recurrence-with-time-zone" Grouping The "recurrence-with-time-zone" grouping () specifies a simple recurrence rule with a time zone.

The "recurrence-with-time-zone" grouping augments the "recurrence-first" container with the "time-zone-identifier" parameter which MUST be specified if the date and time value is neither reported in the format of UTC nor time zone offset to UTC. It also augments the "recurrence-first" container with a parameter "duration" to allow the time period of the first occurrence to be specified. The "duration" also applies to subsequent recurrence instances. Unlike the definition of "recurrence-utc" grouping , "recurrence-with-time-zone" is intended to promote human readability over machine readability.

The "recurrence-utc-with-date-times" Grouping The "recurrence-utc-with-date-times" grouping () uses the "recurrence-utc" grouping () and adds a "period-timeticks" list to define an aggregate set of repeating occurrences.

The recurrence instances are specified by the union of occurrences defined by both the recurrence rule and "period-timeticks" list. Duplicate instances are ignored. The value of the "period-start" instance must not exceed the value indicated by the value of "frequency" instance, e.g., the timeticks value must not exceed 100 in a secondly recurrence rule, and it must not exceed 6000 in a minutely recurrence rule, and so on.

The "recurrence-time-zone-with-date-times" Grouping The "recurrence-time-zone-with-date-times" grouping () uses the "recurrence-with-time-zone" grouping () and adds a "period" list to define an aggregate set of repeating occurrences.

The recurrence instances are specified by the union of occurrences defined by both the recurrence rule and "period" list. Duplicate instances are ignored.

The "icalendar-recurrence" Grouping The "icalendar-recurrence" grouping () uses the "recurrence-time-zone-with-date-times" grouping () and define more data nodes to enrich the definition of recurrence. The structure of the "icalendar-recurrence" grouping refers to the definition of recurrence component defined in Sections and of .

An array of the "bysecond" (or "byminute", "byhour") specifies a list of seconds within a minute (or minutes within an hour, hours of the day). For example, within a "minutely" recurrence rule, the values of "byminute" node "10" and "20" means the occurrences generates at the 10th and 20th minute within an hour, reducing the number of recurrence instances from all minutes. The parameter "byday" specifies a list of days of the week, with an optional direction which indicates the nth occurrence of a specific day within the "monthly" or "yearly" frequency. For example, within a "monthly" rule, the "weekday" with a value of "monday" and the "direction" with a value of "-1" represents the last Monday of the month. An array of the "bymonthday" (or byyearday", "byyearweek", or "byyearmonth") specifies a list of days of the month (or days of the year, weeks of the year, or months of the year). For example, within a "yearly" recurrence rule, the values of "byyearmonth" instance "1" and "2" means the occurrences generates in January and February, increasing the "yearly" recurrence from every year to every January and February of the year. 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" recurrence rule, the "byday" data node specifies every Monday of the week, the "bysetpos" with value of "-1" represents the last 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 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 and a "byyearweek" is specified. The default value is "monday". 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 generated by any of the specified recurrence rule and date-times, and then excluding any start date and time values specified by "exception-dates" parameter.

The "schedule-status" Grouping The "schedule-status" grouping () defines common parameters for scheduling management/status exposure.

The "schedule-id" parameter is useful to uniquely identify a schedule in a network device or controller if multiple scheduling contexts exists. The "state" parameter is defined to configure/expose the scheduling state, depending on the use of the grouping. The "identityref" type is used for this parameter to allow extensibility in future modules. For example, a "conflict" state is valid in scheduling contexts where multiple systems struggle for the scheduling of the same property. The conflict may be induced by, e.g., multiple entities managing the schedules for the same target component. The "version" parameter is used to track the current schedule version information. The version can be bumped by the entity who create the schedule. The "last-update" parameter identifies when the schedule was last modified. In some contexts, this parameter can be used to track the configuration of a given schedule. In such cases, the "version" may not be used. The "schedule-type" parameter identifies the type of the current schedule. The "counter", "last-occurrence", and "upcoming-occurrence" data nodes are only avaliable when the "schedule-type" is "recurrence". The current grouping captures common parameters that is applicable to typical scheduling contexts known so far. Future modules can define other useful parameters as needed. For example, in a scheduling context with multiple system sources to feed the schedules, the "source" and "precedence" parameters may be needed to reflect how schedules from different sources should be prioritised.

Features and Augmentations The "ietf-schedule" data model defines the recurrence related groupings using a modular approach. Basic, intermediate, and advanced representation of recurrence groupings are defined, with each reusing the previous one and adding more parameters. To allow for different options, two features are defined in the data model: 'basic-recurrence-supported' 'icalendar-recurrence-supported' provides an example about how that could be used. Implementations may support a basic recurrence rule or an advanced one as needed, by declaring different features. Whether only one or both features are supported is implementation specific and depend on specific scheduling context. These groupings can also be augmented to support specific needs. As an example, demonstrates how additional parameters can be added to comply with specifc schedule needs.

Note and Restrictions There are some restrictions that need to be followed when using groupings defined in "ietf-schedule" yang module: The instant in time represented by "period-start" MUST be before the "period-end" for "period-of-time" grouping The combination of the day, month, and year represented for date and time value MUST be valid. See for the maxinum day number based on the month and year. The second MUST have the value "60" at the end of months in which a leap second occurs for date and time value Care must be taken when defining recurrence occurring very often and frequent that can be an additional source of attacks by keeping the system permanently busy with the management of scheduling Schedules received with a starting time in the past with respect to current time SHOULD be ignored

The "ietf-schedule" YANG Module This module imports types defined in .

file "ietf-schedule@2024-04-16.yang" module ietf-schedule { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-schedule"; prefix schedule; import ietf-yang-types { prefix yang; reference "RFC 6991: Common YANG Data Types"; } import ietf-system { prefix sys; reference "RFC 7317: A YANG Data Model for System Management"; } organization "IETF NETMOD Working Group"; contact "WG Web: WG List: Editor: Qiufang Ma Editor: Mohamed Boucadair Author: Daniel King "; description "This YANG module defines a set of common groupings which are applicable for scheduling purposes such as events, policy, services, or resources based on date and time. Copyright (c) 2024 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; revision 2024-04-16 { description "Initial revision."; reference "RFC XXXX: A Common YANG Data Model for Scheduling"; } feature basic-recurrence-supported { description "Indicates that the server supports configuring a basic scheduled recurrence."; } feature icalendar-recurrence-supported { description "Indicates that the server supports configuring a comprehensive scheduled icalendar recurrence"; reference "RFC 5545: Internet Calendaring and Scheduling Core Object Specification (iCalendar), Sections 3.3.10 and 3.8.5"; } typedef weekday { type enumeration { enum sunday { value 0; description "Sunday of the week."; } enum monday { value 1; description "Monday of the week."; } enum tuesday { value 2; description "Tuesday of the week."; } enum wednesday { value 3; description "Wednesday of the week."; } enum thursday { value 4; description "Thursday of the week."; } enum friday { value 5; description "Friday of the week."; } enum saturday { value 6; description "Saturday of the week."; } } description "Seven days of the week."; } typedef duration { type string { pattern '((\+)?|\-)P((([0-9]+)D)?(T(0[0-9]|1[0-9]|2[0-3])' + ':[0-5][0-9]:[0-5][0-9]))|P([0-9]+)W'; } description "Duration of the time. The format can represent nominal durations (weeks designated by 'W' and days designated by 'D') and accurate durations (hours:minutes:seconds follows the designator 'T'). Note that this value type doesn't support the 'Y' and 'M' designators to specify durations in terms of years and months. Negative durations are typically used to schedule an alarm to trigger before an associated time."; reference "RFC 5545: Internet Calendaring and Scheduling Core Object Specification (iCalendar), Sections 3.3.6 and 3.8.6.3"; } identity frequency-type { description "Base identity for frequency type."; } identity secondly { base frequency-type; description "Indicates a repeating rule based on an interval of a second or more."; } identity minutely { base frequency-type; description "Indicates a repeating rule based on an interval of a minute or more."; } identity hourly { base frequency-type; description "Indicates a repeating rule based on an interval of an hour or more."; } identity daily { base frequency-type; description "Indicates a repeating rule based on an interval of a day or more."; } identity weekly { base frequency-type; description "Indicates a repeating rule based on an interval of a week or more."; } identity monthly { base frequency-type; description "Indicates a repeating rule based on an interval of a month or more."; } identity yearly { base frequency-type; description "Indicates a repeating rule based on an interval of a year or more."; } identity schedule-type { description "Base identity for schedule type."; } identity period { base schedule-type; description "Indicates a period based schedule."; } identity recurrence { base schedule-type; description "Indicates a recurrence based schedule."; } identity schedule-state { description "Base identity for schedule state."; } identity enabled { base schedule-state; description "Indicates a recurrence with an enabled state."; } identity disabled { base schedule-state; description "Indicates a recurrence with a disabled state."; } identity out-of-date { base schedule-state; description "Indicates a recurrence with an out-of-date state."; } identity discard-action { description "Indicates that schedule will be discarded."; } identity warning { base discard-action; description "Indicates that a warning message is generated when a schedule is discarded."; } identity error { base discard-action; description "Indicates that an error message is generated when a schedule is discarded."; } identity silently-discard { base discard-action; description "Indicates that an invalid schedule is silently discarded."; } grouping generic-schedule-params { description "Incldues a set of generic configuration parameters that are followed by the entity that supports schedules. These parameters apply to all schedules. Such parameters are used as guards to prevent, e.g., stale configuration."; leaf time-zone-identifier { type sys:timezone-name; description "Indicates the identifier for the time zone in a time zone database."; } leaf validity { type yang:date-and-time; description "Specifies the date and time after which a schedule will be considered as invalid. This paratemer takes precedence over similar attributes that are provided at the schedule instance itself."; } leaf max-allowed-start { type yang:date-and-time; description "Specifies the maximum scheduled start date and time, a requested schedule instance whose first occurrence after this value cannot be accepted by the entity. Specifically, a requested schedule will be rejected if the first occurrence of that new schedule exceeds 'max-allowed-start'."; } leaf min-allowed-start { type yang:date-and-time; description "Specifies the minimum scheduled start date and time, a requested schedule instance whose first occurrence before this value cannot be accepted by the entity. Specifically, a requested schedule will be rejected if the first occurrence of that new schedule is scheduled before 'min-allowed-start'."; } leaf max-allowed-end { type yang:date-and-time; description "A requested schedule will be rejected if the end time of the last occurrence exceeds 'max-allowed-end'."; } leaf discard-action { type identityref { base discard-action; } description "Specifies the behavior when a schedule is discarded when enforcing the guards in this grouping or it is received out-of-date."; } } grouping period-of-time { description "This grouping is defined for period of time property."; reference "RFC 5545: Internet Calendaring and Scheduling Core Object Specification (iCalendar), Section 3.3.9"; leaf period-start { type yang:date-and-time; description "Period start time."; } leaf time-zone-identifier { type sys:timezone-name; description "Indicates the identifier for the time zone in a time zone database. This parameter MUST be specified if 'period-start' value is neither reported in the format of UTC nor time zone offset to UTC."; } choice period-type { description "Indicates the type of the time period. Two types are supported."; case explicit { description "A period of time is identified by its start and its end. 'period-start' indicates the period start."; leaf period-end { type yang:date-and-time; description "Period end time. The start MUST be before the end. If a local time without time zone offset to UTC time is specified, it MUST use the same time zone reference as 'period-start' parameter. If 'period-start' also uses a local time without time zone offset to UTC, it MUST use the time zone as specified by the 'time-zone-identifier' parameter."; } } case duration { description "A period of time is defined by a start and a positive duration of time."; leaf duration { type duration { pattern 'P((([0-9]+)D)?(T(0[0-9]|1[0-9]|2[0-3])' + ':[0-5][0-9]:[0-5][0-9]))|P([0-9]+)W'; } description "A positive duration of the time. This value is equivalent to the format of duration type except that the value cannot be negative."; } } } } grouping recurrence { description "A simple definition of recurrence."; container recurrence-first { description "Specifies the first instance of the recurrence."; leaf date-time-start { type yang:date-and-time; description "Defines the instant date and time of the first instance in the recurrence set."; } } leaf frequency { type identityref { base frequency-type; } mandatory true; description "This parameter is defined to identify the frequency type of the recurrence rule."; } leaf interval { type uint32; description "A positive integer representing at which intervals the recurrence rule repeats. For example, within a 'daily' recurrence rule, a value of '8' means every eight days. The default value is '1', means every second for a 'secondly' recurrence rule, every minute for a 'minutely' rule, and so on."; } choice recurrence-bound { description "Modes to bound the recurrence rule. If no choice is indicated, the recurrence rule is considered to repeat forever."; case until { description "This case defines a way that bounds the recurrence rule in an inclusive manner."; leaf until { type yang:date-and-time; description "This parameter specifies a date and time value to bound the recurrence. If the value specified by this parameter is synchronized with the specified recurrence, it becomes the last instance of the recurrence."; } } case count { description "This case defines the number of occurrences at which to range-bound the recurrence."; leaf count { type uint32; description "The positive number of occurrences at which to range-bound the recurrence."; } } } } grouping recurrence-utc { description "A simple definition of recurrence with time specified in UTC. This grouping is intended to be machine-friendly."; uses recurrence { refine "recurrence-first/date-time-start" { description "Defines the instant date and time of the first instance in the recurrence set. A UTC format MUST be used."; } refine "recurrence-bound/until" { description "This parameter specifies a date and time value to bound the recurrence. If the value specified by this parameter is synchronized with the specified recurrence, it becomes the last instance of the recurrence. A UTC format MUST be used."; } augment "recurrence-first" { description "Adds a parameter indicating how long the occurrence lasts."; leaf duration { type int32; units "seconds"; description "When specified, it refers to the duration of each occurrence. The duration is in units of seconds. The exact duration also applies to all the recurrence instance."; } } } } grouping recurrence-with-time-zone { description "A simple definition of recurrence that allows the time to be specified with a local time and time zone. This grouping is intended to be human-friendly."; uses recurrence { augment "recurrence-first" { description "Adds parameters indicating how long the occurrence lasts and time zone identifier of the occurrence."; leaf duration { type duration; description "When specified, it refers to the duration of the first occurrence. The exact duration also applies to all the recurrence instance."; } leaf time-zone-identifier { type sys:timezone-name; description "Indicates the identifier for the time zone in a time zone database. This parameter MUST be specified if 'date-time-start' and/or 'until' value is neither reported in the format of UTC nor time zone offset to UTC."; } } } } grouping recurrence-utc-with-date-times { description "This grouping defines an aggregate set of repeating occurrences with UTC time format. The recurrence instances are specified by the union of occurrences defined by both the recurrence rule and 'period-timeticks' list. Duplicate instances are ignored."; uses recurrence-utc; list period-timeticks { key "period-start"; description "A list of period with timeticks formats."; leaf period-start { type yang:timeticks; must "(not(derived-from(../../frequency," +"'schedule:secondly')) or (current() < 100)) and " +"(not(derived-from(../../frequency," +"'schedule:minutely')) or (current() < 6000)) and " +"(not(derived-from(../../frequency,'schedule:hourly'))" +" or (current() < 360000)) and " +"(not(derived-from(../../frequency,'schedule:daily'))" +" or (current() < 8640000)) and " +"(not(derived-from(../../frequency,'schedule:weekly'))" +" or (current() < 60480000)) and " +"(not(derived-from(../../frequency," +"'schedule:monthly')) or (current() < 267840000)) and " +"(not(derived-from(../../frequency,'schedule:yearly'))" +" or (current() < 3162240000))" { error-message "The period-start must not exceed the frequency interval."; } description "Start time of the schedule within one recurrence."; } leaf period-end { type yang:timeticks; description "End time of the schedule within one recurrence."; } } } grouping recurrence-time-zone-with-date-times { description "This grouping defines an aggregate set of repeating occurrences with local time format and time zone specified. The recurrence instances are specified by the union of occurrences defined by both the recurrence rule and 'period' list. Duplicate instances are ignored."; uses recurrence-with-time-zone; list period { key "period-start"; description "A list of period with date-and-time formats."; uses period-of-time; } } grouping icalendar-recurrence { description "This grouping is defined to identify properties that contain a recurrence rule."; reference "RFC 5545: Internet Calendaring and Scheduling Core Object Specification (iCalendar), Section 3.8.5"; uses recurrence-time-zone-with-date-times; leaf-list bysecond { type uint32 { range "0..60"; } description "A list of seconds within a minute."; } leaf-list byminute { type uint32 { range "0..59"; } description "A list of minutes within an hour."; } leaf-list byhour { type uint32 { range "0..23"; } description "Specifies a list of hours of the day."; } list byday { key "weekday"; description "Specifies a list of days of the week."; leaf-list direction { when "derived-from(../../frequency, 'schedule:monthly') or " + "(derived-from(../../frequency, 'schedule:yearly') " + " and not(../../byyearweek))"; type int32 { range "-53..-1|1..53"; } description "When specified, it indicates the nth occurrence of a specific day within the monthly or yearly recurrence rule. For example, within a monthly rule, +1 monday represents the first monday within the month, whereas -1 monday represents the last monday of the month."; } leaf weekday { type schedule:weekday; description "Corredponds to seven days of the week."; } } leaf-list bymonthday { type int32 { range "-31..-1|1..31"; } description "Specifies a list of days of the month."; } leaf-list byyearday { type int32 { range "-366..-1|1..366"; } description "Specifies a list of days of the year."; } leaf-list byyearweek { when "derived-from(../frequency, 'schedule:yearly')"; type int32 { range "-53..-1|1..53"; } description "Specifies a list of weeks of the year."; } leaf-list byyearmonth { type uint32 { range "1..12"; } description "Specifies a list of months of the year."; } leaf-list bysetpos { type int32 { range "-366..-1|1..366"; } description "Specifies a list of values that corresponds to the nth occurrence within the set of recurrence instances specified by the rule. It must only be used in conjunction with another by the rule part."; } leaf workweek-start { type schedule:weekday; description "Specifies the day on which the workweek starts. The default value is 'monday'."; } leaf-list exception-dates { type yang:date-and-time; description "Defines a list of exceptions for recurrence."; } } grouping schedule-status { description "This grouping is defined to identify common properties of scheduling status."; leaf schedule-id { type string; description "The schedule identifier that globally identifies a schedule in a device, controller, network, etc. The unicity scope depends on the implementation."; } leaf state { type identityref { base schedule-state; } description "The current state of the schedule."; } leaf version { type uint16; description "The version number of the schedule."; } leaf schedule-type { type identityref { base schedule-type; } config false; description "The schedule type."; } leaf last-update { type yang:date-and-time; config false; description "The timestamp that the schedule is last updated."; } leaf counter { when "derived-from-or-self(../schedule-type, " + "'schedule:recurrence')"; type uint32; config false; description "The counter of occurrences since the schedule was enabled. The count wraps around when it reaches the maximum value."; } leaf last-occurrence { when "derived-from-or-self(../schedule-type, " + "'schedule:recurrence')"; type yang:date-and-time; config false; description "The timestamp of last occurrence."; } leaf upcoming-occurrence { when "derived-from-or-self(../schedule-type, " + "'schedule:recurrence')" + "and derived-from-or-self(../state, 'schedule:enabled')"; type yang:date-and-time; config false; description "The timestamp of next occurrence."; } } } ]]>

Security Considerations This section uses the template described in . The "ietf-schedule" YANG module specified in this document defines schema for data that is designed to be accessed via network management protocols such as NETCONF or RESTCONF . The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS . The Network Configuration Access Control Model (NACM) provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. 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.

IANA Considerations

The "IETF XML" Registry This document registers the following URI in the "IETF XML Registry" .

The "YANG Module Names" Registry This document registers the following YANG module in the "YANG Module Names" registry .

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). This document defines the iCalendar data format for representing and exchanging calendaring and scheduling information such as events, to-dos, journal entries, and free/busy information, independent of any particular calendar service or protocol. [STANDARDS-TRACK] This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK] This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] Huawei Huawei Orange Lancaster University This document defines a YANG data model for policy-based network access control, which provides consistent and efficient enforcement of network access control policies based on group identity. Moreover, this document defines a mechanism to ease the maintenance of the mapping between a user group identifier and a set of IP/MAC addresses to enforce policy-based network access control. In addition, the document defines a RADIUS attribute that is used to communicate the user group identifier as part of identification and authorization information. Telefonica Nokia This document defines a YANG data model for network diagnosis on- demand using Operations, Administration, and Maintenance (OAM) tests. This document defines both 'oam-unitary-test' and 'oam-test-sequence' data models to enable on-demand activation of network diagnosis procedures. Futurewei Technologies LabN Consulting, L.L.C. LabN Consulting, L.L.C. LabN Consulting, L.L.C. Viagenie The YANG model in this document includes three modules, and can be used to manage network resources and topologies with scheduled attributes, such as predictable link loss and link connectivity as a function of time. The intent is to have this information be utilized by Time-Variant Routing systems. This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. YumaWorks Orange Huawei This memo provides guidelines for authors and reviewers of specifications containing YANG modules, including IANA-maintained modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 8407. Also, this document updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained modules. This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text. JHU/APL Thales Alenia Space Futurewei Technologies Ori Industries Huawei This document introduces use cases where Time-Variant Routing (TVR) computations (i.e. routing computations taking into considerations time-based or scheduled changes to a network) could improve routing protocol convergence and/or network performance. Huawei Individual Fraunhofer SIT Volta Networks Cisco This document defines a YANG data model for Event Condition Action (ECA) policy management. The ECA policy YANG module provides the ability to delegate some network management functions to the server (e.g., a NETCONF or RESTCONF server) which can take simple and instant action when a trigger condition on the managed objects is met.

Examples of Format Representation This section provides some examples to illustrate the use of the period and recurrence formats defined as YANG groupings. Note that "grouping" does not define any data nodes in the schema tree, the examples illustrated are just for the ease of understanding. Only the message body is provided with JSON used for encoding .

The "generic-schedule-params" Grouping indicates 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). Schedule requests that fail to meet the requirements are ignored by the system.

The "period-of-time" Grouping The example of a period that starts at 08:00:00 UTC, on January 1, 2025 and ends at 18:00:00 UTC on December 31, 2027 is encoded as shown in .

An example of a period that starts at 08:00:00 UTC, on January 1, 2025 and lasts 15 days and 5 hours and 20 minutes is encoded as shown in .

An example of a period that starts at 2:00 A.M. in Los Angeles on November 19, 2025 and lasts 20 weeks is depicted in .

The "recurrence" Grouping indicates a recurrence of every 2 days for 10 occurrences, starting at 3 p.m. on December 1, 2025 with an offset of -8:00 from UTC:

The "recurrence-utc" Grouping indicates a recurrence from 8:00 AM to 9:00 AM every day, from December 1 to December 31, 2025 in UTC:

The "recurrence-with-time-zone" Grouping indicates a recurrence of every 2 hours for 10 occurrences, lasting 10 minutes, and starting at 3 p.m. on December 1, 2025 in New York:

The "recurrence-utc-with-date-times" Grouping 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:

The "recurrence-time-zone-with-date-times" Grouping indicates a recurrence that occurs every 30 minutes and last for 15 minutes from 9:00 AM to 5:00 PM, and extra two occurrences at 6:00 PM and 6:30 PM with each lasting for 20 minutes on 2025-12-01 (New York):

The "icalendar-recurrence" Grouping indicates 10 occurrences that occur at 8:00 AM (EST), every last Saturday of the month starting in January 2024:

is an example of a recurrence that occurs on the last workday of the month until December 25, 2025, from January 1, 2025:

indicates a recurrence that occurs every 20 minutes from 9:00 AM to 4:40 PM (UTC), with the occurrence starting at 10:20 AM being excluded on 2025-12-01:

The "schedule-status" Grouping indicates the scheduled recurrence status of at the time of 12:15 PM, 2025-12-01 (UTC):

At the time of 12:15 PM, 2025-12-01 (UTC), the recurring event occurred at (note that occurrence at 10:20 AM is excluded): 9:00, 9:20, 9:40, 10:00, 10:40, 11:00, 11:20, 11:40, 12:00. The last occurrence was at 12:00, the upcoming one is at 12:20.

Examples of Using/Extending the "ietf-schedule" Module This non-normative section shows two examples for how the "ietf-schedule" module can be used or extended for scheduled events or attributes based on date and time.

Example: Schedule Tasks to Execute Based on a Recurrence Rule Scheduled tasks can be used to execute specific actions based on certain recurrence rules (e.g., every Friday at 8:00 AM). The following example module which "uses" the "icalendar-recurrence" grouping from "ietf-schedule" module shows how a scheduled task could be defined with different features used for options.

Example: Schedule Network Properties to Change Based on Date and Time Network properties may change over a specific period of time or based on a recurrence rule, e.g., . The following example module which augments the "recurrence-utc-with-date-times" grouping from "ietf-schedule" module shows how a scheduled based attribute could be defined.

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. 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 value that's not covered by the period above is 1000 Kbps by default.

ne1 ne2 1000 2025-12-01T01:00:00Z schedule:daily 2025-12-31T23:59:59Z 360000 2160000 500 7920000 8280000 800 ]]>

Acknowledgments This work is derived from the . There is a desire from the OPSAWG to see this model be separately defined for wide use in scheduling context. Thanks to Adrian Farrel, Wei Pan, Tianran Zhou, Joe Clarke, and Dhruv Dhody for their valuable comments and inputs to this work. Many thanks to the authors of , , and for the constructive discussion during IETF#118.