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
162
163
164 11
165 2016-09-12T23:20:50.52Z
166 P1D
167 R5/P1W
168
169
170
171
172
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