idnits 2.17.1 draft-liu-netmod-yang-schedule-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 24, 2016) is 2740 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 87, but not defined == Unused Reference: 'RFC6021' is defined on line 367, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 374, but no explicit reference was found in the text == Unused Reference: 'RFC6087' is defined on line 383, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Downref: Normative reference to an Informational RFC: RFC 7399 -- Obsolete informational reference (is this intentional?): RFC 6087 (Obsoleted by RFC 8407) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group X. Liu 2 Internet-Draft Kuatro Technologies 3 Intended status: Standards Track I. Bryskin 4 Expires: April 24, 2017 Huawei Technologies 5 V. Beeram 6 Juniper Networks 7 T. Saad 8 Cisco Systems Inc 9 H. Shah 10 Ciena 11 O. Gonzalez de Dios 12 Telefonica 13 October 24, 2016 15 A YANG Data Model for Configuration Scheduling 16 draft-liu-netmod-yang-schedule-02 18 Abstract 20 This document describes a data model for configuration scheduling. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on April 24, 2017. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction...................................................2 63 1.1. Terminology...............................................2 64 2. Motivation.....................................................3 65 3. Configuration Scheduling YANG Data Model Overview..............3 66 4. Usage Example..................................................4 67 5. Configuration Scheduling YANG Module...........................5 68 6. Security Considerations........................................9 69 7. References.....................................................9 70 7.1. Normative References......................................9 71 7.2. Informative References....................................9 73 1. Introduction 75 This document introduces a YANG [RFC6020] data model for 76 configuration scheduling. This model can be used together with other 77 YANG data models to specify a schedule applied on a configuration 78 data node, so that the configuration data can take effect according 79 to the schedule. 81 1.1. Terminology 83 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 85 "OPTIONAL" in this document are to be interpreted as described in BCP 86 14, [RFC2119]. 88 The following terms are defined in [RFC6020] and are not redefined 89 here: 91 o augment 93 o data model 95 o data node 97 2. Motivation 99 Some applications benefit from resource scheduling to allow operators 100 to plan ahead of time. Traffic engineering is one of such examples 101 [RFC7399]. When configuration and state models are designed for such 102 applications, it has been considered that certain data objects need 103 to be configured according to predefined schedules. In other 104 situations, operators need to de-configure certain data objects at 105 predefined schedules for the purposes such as maintenance. These data 106 objects are interpreted and implemented by the applicable 107 applications. 109 3. Configuration Scheduling YANG Data Model Overview 111 This document defines a YANG data model that specifies configuration 112 schedules for other YANG data models. For each targeted configuration 113 data object or a group of configuration data objects, an entry is 114 specified along with requested schedules using this configuration 115 schedule model. The application implementing the targeted schema 116 nodes implements the configuration schedules, configuring or de- 117 configuring the specified objects according to the specified 118 schedules. The model schema of the targeted application does not need 119 changes, so the data model described in this document can be used for 120 any data model. The configuration scheduling YANG data model has the 121 following structure: 123 module: ietf-schedule 124 +--rw configuration-schedules 125 +--rw target* [object] 126 +--rw object yang:xpath1.0 127 +--rw data-value? string 128 +--rw schedules 129 | +--rw schedule* [schedule-id] 130 | +--rw schedule-id uint32 131 | +--rw inclusive-exclusive? enumeration 132 | +--rw start? yang:date-and-time 133 | +--rw schedule-duration? string 134 | +--rw repeat-interval? string 135 +--ro state 136 +--ro next-event 137 +--ro start? yang:date-and-time 138 +--ro duration? string 139 +--ro operation? enumerationmodule: ietf-schedule 141 4. Usage Example 143 The following model defines a list of TE (Traffic Engineering) links 144 which can be configured with specified schedules: 146 module: example 147 +--rw te-links 148 +--rw te-link* [id] 149 +--rw id string 151 The following configuration requests that 153 o link-1 is configured weekly for five one-day periods, starting 154 from 2016-09-12T23:20:50.52Z. 156 o link-2 is de-configured for two hours, starting from 2016-09- 157 15T01:00:00.00Z. 159 160 161 /ex:te-links/ex:te-link[ex:link-id='link-1'] 162 163 164 11 165 2016-09-12T23:20:50.52Z 166 P1D 167 R5/P1W 168 169 170 171 172 /ex:te-links/ex:te-link[ex:link-id='link-2'] 173 174 175 12 176 exclusive 177 2016-09-15T01:00:00.00Z 178 P2H 179 180 181 182 184 5. Configuration Scheduling YANG Module 186 file "ietf-schedule@2016-10-11.yang" 187 module ietf-schedule { 188 yang-version 1; 189 namespace "urn:ietf:params:xml:ns:yang:ietf-schedule"; 190 // replace with IANA namespace when assigned 192 prefix "sch"; 194 import ietf-yang-types { 195 prefix "yang"; 196 } 198 organization "TBD"; 199 contact "TBD"; 200 description 201 "The model allows time scheduling parameters to be specified."; 203 revision "2016-10-11" { 204 description "Initial revision"; 205 reference "TBD"; 206 } 208 /* 209 * Groupings 210 */ 212 grouping schedule-config-attributes { 213 description 214 "A group of attributes for a schedule."; 216 leaf inclusive-exclusive { 217 type enumeration { 218 enum inclusive { 219 description "The schedule element is inclusive."; 221 } 222 enum exclusive { 223 description "The schedule element is exclusive."; 224 } 225 } 226 default "inclusive"; 227 description 228 "Whether the list item is inclusive or exclusive."; 229 } 230 leaf start { 231 type yang:date-and-time; 232 description "Start time."; 233 } 234 leaf schedule-duration { 235 type string { 236 pattern 237 'P(\d+Y)?(\d+M)?(\d+W)?(\d+D)?T(\d+H)?(\d+M)?(\d+S)?'; 238 } 239 description "Schedule duration in ISO 8601 format."; 240 } 241 leaf repeat-interval { 242 type string { 243 pattern 244 'R\d*/P(\d+Y)?(\d+M)?(\d+W)?(\d+D)?T(\d+H)?(\d+M)?' 245 + '(\d+S)?'; 246 } 247 description "Repeat interval in ISO 8601 format."; 248 } 249 } // schedule-config-attributes 251 grouping schedule-state-attributes { 252 description 253 "State attributes for a schedule."; 254 container next-event { 255 description 256 "The state information of the nexte scheduled event."; 257 leaf start { 258 type yang:date-and-time; 259 description "Start time."; 260 } 261 leaf duration { 262 type string { 263 pattern 264 'P(\d+Y)?(\d+M)?(\d+W)?(\d+D)?T(\d+H)?(\d+M)?(\d+S)?'; 265 } 266 description "Schedule duration in ISO 8601 format."; 267 } 268 leaf operation { 269 type enumeration { 270 enum configure { 271 description 272 "Create the configuration data."; 273 } 274 enum deconfigure { 275 description 276 "Remove the configuration data."; 277 } 278 enum set { 279 description 280 "Set the specified configuration data."; 281 } 282 enum reset { 283 description 284 "Revert the specified configuration data back to the 285 original value."; 286 } 287 } 288 description "Operation type."; 289 } 290 } // next-event 291 } // schedule-state-attributes 293 grouping schedules { 294 description 295 "A list of schedules defining when a particular 296 configuration takes effect."; 297 container schedules { 298 description 299 "Container of a schedule list defining when a particular 300 configuration takes effect."; 301 list schedule { 302 key "schedule-id"; 303 description "A list of schedule elements."; 304 leaf schedule-id { 305 type uint32; 306 description "Identifies the schedule element."; 307 } 308 uses schedule-config-attributes; 309 } 310 } 311 } // schedules 313 /* 314 * Configuration data nodes 315 */ 316 container configuration-schedules { 317 description 318 "Serves as top-level container for a list of configuration 319 schedules."; 320 list target { 321 key "object"; 322 description 323 "A list of targets that configuration schedules are 324 applied."; 325 leaf object { 326 type yang:xpath1.0; 327 description 328 "Xpath defining the data items of interest."; 329 } 330 leaf data-value { 331 type string; 332 description 333 "The ephemeral value applied to the leaf data node 334 specified by data-objects. 335 This is applicable when object is a leaf."; 336 } 337 uses schedules; 338 container state { 339 config false; 340 description 341 "Operational state data."; 342 uses schedule-state-attributes; 343 } // state 345 } // target 346 } // configuration-schedules 347 } 348 350 6. Security Considerations 352 The configuration, state, action and notification data defined in 353 this document are designed to be accessed via the NETCONF protocol 354 [RFC6241]. The data-model by itself does not create any security 355 implications. The security considerations for the NETCONF protocol 356 are applicable. The NETCONF protocol used for sending the data 357 supports authentication and encryption. 359 7. References 361 7.1. Normative References 363 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 364 Network Configuration Protocol (NETCONF)", RFC 6020, 365 October 2010. 367 [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, 368 October 2010. 370 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, 371 "Network Configuration Protocol (NETCONF)", RFC 6241, June 372 2011. 374 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 375 Syntax Specifications: ABNF", RFC 2234, Internet Mail 376 Consortium and Demon Internet Ltd., November 1997. 378 [RFC7399] Farrel, A. and King, D., "Unanswered Questions in the Path 379 Computation Element Architecture", RFC 7399, October 2014. 381 7.2. Informative References 383 [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of YANG 384 Data Model Documents", RFC 6087, January 2011. 386 Authors' Addresses 388 Xufeng Liu 389 Kuatro Technologies 390 8281 Greensboro Drive, Suite 200 391 McLean, VA 22102 392 USA 394 Email: xliu@kuatrotech.com 396 Igor Bryskin 397 Huawei Technologies 398 Email: Igor.Bryskin@huawei.com 400 Vishnu Pavan Beeram 401 Juniper Networks 402 Email: vbeeram@juniper.net 404 Tarek Saad 405 Cisco Systems Inc 406 Email: tsaad@cisco.com 408 Himanshu Shah 409 Ciena 410 Email: hshah@ciena.com 412 Oscar Gonzalez de Dios 413 Telefonica 414 Email: oscar.gonzalezdedios@telefonica.com