idnits 2.17.1 draft-kwatsen-conditional-enablement-00.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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 18, 2013) is 4085 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Configuration Working Group K. Watsen 3 Internet-Draft Juniper Networks 4 Expires: August 22, 2013 February 18, 2013 6 Conditional Enablement of Configuration Nodes 7 draft-kwatsen-conditional-enablement-00 9 Abstract 11 This memo presents a cross-cutting technique whereby a NETCONF server 12 can support conditional enablement of configuration nodes. That is, 13 whether the node is active or not depends on the evaluation of an 14 expression. Two expression types are defined herein, one for latent 15 configuration (present but not actualized) and another for temporal 16 configuration (actualized based on time). This soluton presented is 17 extensible so that additional expression types may be added in the 18 future. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 22, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1. Explicit Nodes Defined in NETMOD Drafts . . . . . . . . . . 3 58 3.2. Precendent in Juniper's JUNOS-Based Products . . . . . . . 4 59 3.3. Use-Cases Scoped By I2RS Working Group . . . . . . . . . . 5 60 4. Expression Types . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.2. Simple Expressions . . . . . . . . . . . . . . . . . . . . 5 63 4.3. Complex Expressions . . . . . . . . . . . . . . . . . . . . 5 64 5. Feature Types . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5.2. Simple . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 5.3. Time . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 6. Conditional Enablement Capability . . . . . . . . . . . . . . . 7 69 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 6.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . . 7 71 6.3. Capability Identifier . . . . . . . . . . . . . . . . . . . 7 72 6.4. New Operations . . . . . . . . . . . . . . . . . . . . . . 7 73 6.5. Modifications to Existing Operations . . . . . . . . . . . 7 74 6.6. Interactions with Other Capabilities . . . . . . . . . . . 8 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 77 9. Normative References . . . . . . . . . . . . . . . . . . . . . 8 79 1. Requirements Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119 [RFC2119]. 85 2. Introduction 87 This memo presents a cross-cutting technique whereby a NETCONF server 88 can support conditional enablement of configuration nodes. That is, 89 whether the node is active or not depends on the evaluation of an 90 expression. Two expression types are defined herein, one for latent 91 configuration (present but not actualized) and another for temporal 92 configuration (actualized based on time). This soluton presented is 93 extensible so that additional expression types may be added in the 94 future. 96 3. Motivation 98 3.1. Explicit Nodes Defined in NETMOD Drafts 100 Two separate drafts presented during the NETMOD meeting and IETF 85 101 had data-models with explicit "enabled" leaves (see examples below). 102 One of the questions asked during the sessions was if cross-cutting 103 concerns, such as if a node were enabled, wouldn't be better 104 supported via meta-data, to which there was general agreement. 106 Example of an "enabled" leaf from 107 draft-ietf-netmod-routing-cfg-06.txt: 109 leaf enabled { 110 type boolean; 111 default "true"; 112 description 113 "Enable/disable the router instance. 115 If this parameter is false, the parent router instance is 116 disabled, despite any other configuration that might be 117 present."; 118 } 120 Figure 1 122 Example of an "enabled" leaf from 123 draft-ietf-netmod-system-mgmt-04.txt: 125 leaf enabled { 126 type boolean; 127 default true; 128 description 129 "Indicates whether this server is enabled for use or not."; 130 } 132 Figure 2 134 3.2. Precendent in Juniper's JUNOS-Based Products 136 Further, there is already a precendent for this strategy in Juniper's 137 JUNOS-based products, where any configuration node can be flagged 138 with an XML attribute stating that it is inactive. 140 Example of a JUNOS "inactive" statement: 142 ... 144 Figure 3 146 Additionally, JUNOS also supports the notion of a list of 147 conditionals that must all be satisfied for an associated 148 configuration to be applied. JUNOS supports the conditionals to be 149 based on chassis type, model type, routing engine, member, and time. 151 Example of a JUNOS "when" statement (this is not YANG): 153 groups { 154 my-group-g1 { 155 system { 156 hostname xyz; 157 } 158 when { 159 model tx1000; 160 routing-engine re0; 161 time 2am to 4am; 162 } 163 } 164 } 166 Figure 4 168 3.3. Use-Cases Scoped By I2RS Working Group 170 Lastly, discusions with the I2RS Working Group have revealed that 171 they believe they have a need for a device to autonomously switch 172 configuration settings based on time. 174 4. Expression Types 176 4.1. Overview 178 Conditional expressions are boolean expressions that evaluate to 179 either "true" or "false". 181 Expressions are contained inside an XML attribute called "enabled". 182 An expression that evaluates to "true" enables the associated node, 183 whereas an expression that evaluates to "false" disables it. 185 A configuration node having no expression set is equivalent to an 186 expression evaluating to "true". That is, all nodes are enabled by 187 default. 189 Example usage: 191 193 4.2. Simple Expressions 195 Simple expressions are the most trivial expressions possible; they 196 are simply either the constant value "true" or "false". 198 expressions = "true" / "false"; 200 Simple expressions are useful to disable a configuration node until 201 it is explicitly reenabled. Since this is such a common use-case, 202 this draft enables simple expressions to be supported without having 203 to implement support for complex expressions. 205 A device advertises support for simple expressions using the feature 206 "simple" in its capability string: 208 ?features=simple 210 4.3. Complex Expressions 212 All expressions that are not "simple" are "complex". These 213 expressions require being able to compare values and evaluate logical 214 expressions; they do not need to perform arithmetic, bitwise 215 operations, or assignments. 217 The grammer is the same for all complex expresssions, the only thing 218 that varies is what variable assignments the device supports (e.g. 219 time, reference to a statistical value, etc.). 221 A device does not explicitly advertise support for complex 222 expressions. Support for complex expressions are implicit when any 223 feature depending on complex expressions (e.g. time) is advertized. 224 For instance: 226 ?features=time 228 Complex expressions use the following grammer: 230 = [ / / / 231 / / ] 232 = "(" ")" 233 = " && " 234 = " || " 235 = " ! " 236 = "true" / "false" 237 = 238 = *char 239 = " == " / " != " / " > " / " < " / " <= " / " >= " 240 = *char 242 # NOTES 243 # 244 # Valid values dependent on what the device advertises 245 # support for. # Similarly, valid values are dependent on 246 # the used in the expression. For instance, the "time" 247 # feature defines the variables "dayofweek" and "houe", each of which 248 # can only be compared to specific values. For instance: ((dayofweek 249 # >= "Mon" && <= "Fri) && (hour >= 9am && hour <= 5pm)) 251 5. Feature Types 253 5.1. Overview 255 The types of expressions a device supports is advertised as a list of 256 "features" in the capability identifier string. 258 5.2. Simple 260 The "simple" feature defines support for constant boolean values 261 "true" and "false". Simple expressions are useful to disable a node 262 until it is explicitly reenabled. 264 5.3. Time 266 The "time" feature defines support for complex expressions using 267 time-oriented values such as "dayofweek" and "hour". Time 268 expressions are useful to implement policies that depend on time. 270 6. Conditional Enablement Capability 272 6.1. Overview 274 The :conditional-enablement capability advertises that the NETCONF 275 server supports the ability for nodes in its to be annotated with 276 metadata specifying conditions when it is enabled or its values vary. 278 6.2. Dependencies 280 None. 282 6.3. Capability Identifier 284 The :conditional-enablement capability is identified by the following 285 capability string: 287 urn:ietf:params:netconf:capability:conditional-enablement:1.0? \ 288 features={name,...} 290 The :conditional-enablement capability URI MUST contain a "features" 291 argument assigned a comma-separated list of names indicating which 292 expression-types the NETCONF peer supports. For example: 294 urn:ietf:params:netconf:capability:conditional-enablement:1.0? \ 295 features=simple,time 297 6.4. New Operations 299 None. 301 6.5. Modifications to Existing Operations 303 The :conditional-enablement capability modifies any operation that 304 transmits configuration, including: 306 308 310 312 A NETCONF server advertising the :conditional capability indicates 313 that any node in its configuration MAY contain XML attributes defined 314 in the "Overview" section of this capability, even though those 315 attributes were not explicitly defined in its YANG module. 317 6.6. Interactions with Other Capabilities 319 None. 321 7. Security Considerations 323 There are no known security considerations at this time. 325 8. IANA Considerations 327 There are no IANA directives. 329 9. Normative References 331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 332 Requirement Levels", BCP 14, RFC 2119, March 1997. 334 Author's Address 336 Kent Watsen 337 Juniper Networks 339 EMail: kwatsen@juniper.net