idnits 2.17.1 draft-ma-netmod-with-system-03.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** The abstract seems to contain references ([RFC8342]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 908 has weird spacing: '...olicies xmlns...' -- The document date (10 April 2022) is 739 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: 'RFC8526' is mentioned on line 1562, but not defined == Missing Reference: 'RFC8040' is mentioned on line 1548, but not defined == Missing Reference: 'RFC8641' is mentioned on line 338, but not defined == Missing Reference: 'RFC8639' is mentioned on line 338, but not defined == Missing Reference: 'RFC6470' is mentioned on line 338, but not defined == Missing Reference: 'RFC7952' is mentioned on line 1056, but not defined == Missing Reference: 'RFC8340' is mentioned on line 1215, but not defined == Missing Reference: 'RFC3688' is mentioned on line 1509, but not defined == Missing Reference: 'RFC6020' is mentioned on line 1522, but not defined == Missing Reference: 'RFC6242' is mentioned on line 1564, but not defined == Missing Reference: 'RFC8446' is mentioned on line 1566, but not defined == Missing Reference: 'RFC8341' is mentioned on line 1568, but not defined == Outdated reference: A later version (-09) exists of draft-ma-netmod-immutable-flag-00 Summary: 2 errors (**), 0 flaws (~~), 17 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD Q. Ma, Ed. 3 Internet-Draft Huawei 4 Updates: RFC8342, RFC6241, RFC8526, RFC8040 (if K. Watsen 5 approved) Watsen Networks 6 Intended status: Standards Track Q. Wu 7 Expires: 12 October 2022 C. Feng 8 Huawei 9 J. Lindblad 10 Cisco Systems 11 10 April 2022 13 System-defined Configuration 14 draft-ma-netmod-with-system-03 16 Abstract 18 This document updates NMDA [RFC8342] to define a read-only 19 conventional configuration datastore called "system" to hold system- 20 defined configurations. To avoid clients' explicit copy/paste of 21 referenced system-defined configuration into the target configuration 22 datastore (e.g., ), a "resolve-system" parameter has been 23 defined to allow the server acting as a "system client" to copy 24 referenced system-defined nodes automatically. The solution enables 25 clients manipulating the target configuration datastore (e.g., 26 ) to overlay and reference nodes defined in , 27 override values of configurations defined in , and configure 28 descendant nodes of system-defined nodes. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 12 October 2022. 47 Copyright Notice 49 Copyright (c) 2022 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Revised BSD License text as 58 described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Revised BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 66 1.3. Updates to RFC 8342 . . . . . . . . . . . . . . . . . . . 5 67 1.4. Updates to RFC 6241, RFC 8526 . . . . . . . . . . . . . . 5 68 1.5. Updates to RFC 8040 . . . . . . . . . . . . . . . . . . . 6 69 1.5.1. Query Parameter . . . . . . . . . . . . . . . . . . . 6 70 1.5.2. Query Parameter URI . . . . . . . . . . . . . . . . . 6 71 2. Kinds of System Configuration . . . . . . . . . . . . . . . . 7 72 2.1. Immediately-Active . . . . . . . . . . . . . . . . . . . 7 73 2.2. Conditionally-Active . . . . . . . . . . . . . . . . . . 7 74 2.3. Inactive-Until-Referenced . . . . . . . . . . . . . . . . 7 75 3. Static Characteristics . . . . . . . . . . . . . . . . . . . 7 76 3.1. Read-only to Clients . . . . . . . . . . . . . . . . . . 7 77 3.2. May Change via Software Upgrades . . . . . . . . . . . . 8 78 3.3. No Impact to . . . . . . . . . . . . . . . 8 79 4. Dynamic Behavior . . . . . . . . . . . . . . . . . . . . . . 8 80 4.1. Conceptual Model . . . . . . . . . . . . . . . . . . . . 8 81 4.2. Explicit Declaration of System Configuration . . . . . . 9 82 4.3. Servers Auto-configuring Referenced System 83 Configuration . . . . . . . . . . . . . . . . . . . . . . 10 84 4.4. Modifying (overriding) System Configuration . . . . . . . 10 85 4.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 11 86 4.5.1. Server Configuring of Automatically . . . . 11 87 4.5.2. Declaring a System-defined Node in 88 Explicitly . . . . . . . . . . . . . . . . . . . . . 17 89 4.5.3. Modifying a System-instantiated Leaf's Value . . . . 20 90 4.5.4. Configuring Descendant Nodes of a System-defined 91 Node . . . . . . . . . . . . . . . . . . . . . . . . 22 92 5. The Configuration Datastore . . . . . . . . . . . . 23 93 6. The "ietf-system-datastore" Module . . . . . . . . . . . . . 25 94 6.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 25 95 6.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 25 96 6.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 26 97 7. The "ietf-netconf-resolve-system" Module . . . . . . . . . . 28 98 7.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 28 99 7.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 29 100 7.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 32 101 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 102 8.1. The "IETF XML" Registry . . . . . . . . . . . . . . . . . 35 103 8.2. The "YANG Module Names" Registry . . . . . . . . . . . . 35 104 8.3. RESTCONF Capability URN Registry . . . . . . . . . . . . 35 105 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35 106 9.1. Regarding the "ietf-system-datastore" YANG Module . . . . 35 107 9.2. Regarding the "ietf-netconf-resolve-system" YANG 108 Module . . . . . . . . . . . . . . . . . . . . . . . . . 36 109 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36 110 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 36 111 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 112 Normative References . . . . . . . . . . . . . . . . . . . . . 36 113 Informative References . . . . . . . . . . . . . . . . . . . . 37 114 Appendix A. Key Use Cases . . . . . . . . . . . . . . . . . . . 38 115 A.1. Device Powers On . . . . . . . . . . . . . . . . . . . . 38 116 A.2. Client Commits Configuration . . . . . . . . . . . . . . 39 117 A.3. Operator Installs Card into a Chassis . . . . . . . . . . 40 118 Appendix B. Changes between Revisions . . . . . . . . . . . . . 41 119 Appendix C. Open Issues tracking . . . . . . . . . . . . . . . . 42 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 122 1. Introduction 124 NMDA [RFC8342] defines system configuration as the configuration that 125 is supplied by the device itself and should be present in 126 when it is in use. 128 However, there is a desire to enable a server to better document the 129 system configuration. Clients can benefit from a standard mechanism 130 to see what system configuration is available in a server. 132 In some cases, the client references a system configuration which 133 isn't present in the target datastore (e.g., ). Having to 134 copy the entire contents of the system configuration into the target 135 datastore should be avoided or reduced when possible while ensuring 136 that all referential integrity constraints are satisfied. 138 In some other cases, configuration of descendant nodes of system- 139 defined configuration needs to be supported. For example, the system 140 configuration may contain an almost empty physical interface, while 141 the client needs to be able to add, modify, remove a number of 142 descendant nodes. Some descendant nodes may not be modifiable (e.g., 143 "name" and "type" set by the system). 145 This document updates NMDA [RFC8342] to define a read-only 146 conventional configuration datastore called "system" to hold system- 147 defined configurations. To avoid clients' explicit copy/paste of 148 referenced system-defined configuration into the target configuration 149 datastore (e.g., ), a "resolve-system" parameter has been 150 defined to allow the server acting as a "system client" to copy 151 referenced system-defined nodes automatically. The solution enables 152 clients manipulating the target configuration datastore (e.g., 153 ) to overlay and reference nodes defined in , 154 override values of configurations defined in , and configure 155 descendant nodes of system-defined nodes. 157 Conformance to this document requires servers to implement the "ietf- 158 system-datastore" YANG Module. 160 1.1. Terminology 162 This document assumes that the reader is familiar with the contents 163 of [RFC6241], [RFC7950], [RFC8342], [RFC8407], and [RFC8525] and uses 164 terminologies from those documents. 166 The following terms are defined in this document as follows: 168 System configuration: Configuration that is provided by the system 169 itself. System configuration is present in once it's 170 created (regardless of being applied by the device), and appears 171 in which is subject to validation. Applied system 172 configuration also appears in with origin="system". 174 System configuration datastore: A configuration datastore holding 175 the complete configuration provided by the system itself. This 176 datastore is referred to as "". 178 This document redefines the term "conventional configuration 179 datastore" from RFC 8342 to add "system" to the list of conventional 180 configuration datastores: 182 Conventional configuration datastore: One of the following set of 183 configuration datastores: , , , 184 , and . These datastores share a common 185 datastore schema, and protocol operations allow copying data 186 between these datastores. The term "conventional" is chosen as a 187 generic umbrella term for these datastores. 189 1.2. Requirements Language 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 193 "OPTIONAL" in this document are to be interpreted as described in BCP 194 14 [RFC2119] [RFC8174] when, and only when, they appear in all 195 capitals, as shown here. 197 1.3. Updates to RFC 8342 199 This document updates RFC 8342 to define a configuration datastore 200 called "system" to hold system configuration, it also redefines the 201 term "conventional configuration datastore" from RFC 8342 to add 202 "system" to the list of conventional configuration datastores. The 203 contents of datastore are read-only to clients but may 204 change dynamically. The aware client may retrieve all three 205 types of system configuration defined in Section 2, reference nodes 206 defined in , override values of configurations defined in 207 , and configure descendant nodes of system-defined nodes. 209 The server will merge and to create . 210 As always, system configuration will appear in with 211 origin="system" when it is in use. 213 The datastore makes system configuration visible to clients 214 in order for being referenced or configurable prior to present in 215 . 217 1.4. Updates to RFC 6241, RFC 8526 219 This document augments and RPC operations 220 defined in [RFC6241] and [RFC8526] respectively, with a new 221 additional input parameter "resolve-system". The RPC 222 operation defined in [RFC6241] is also augmented to support "resolve- 223 system" parameter. 225 The "resolve-system" parameter is optional and has no value. When it 226 is provided and the server detects that there is a reference to a 227 system-defined node during the validation, the server will 228 automatically copy the referenced system configuration into the 229 validated datastore to make the configuration valid without the 230 client doing so explicitly. Legacy Clients interacting with servers 231 that support this parameter don't see any changes in / and behaviors. 234 According to the NETCONF constraint enforcement model defined in the 235 section 8.3 of [RFC7950], if the target datastore of the / or is "running" or "startup", the 237 server's copy referenced nodes from to the target datastore 238 MUST be enforced at the end of the / or 239 operations during the validation. If the target 240 datastore of the / or is 241 "candidate", the server's copy referenced nodes from to the 242 target datastore is delayed until a or operation 243 takes place. 245 1.5. Updates to RFC 8040 247 This document extends Section 4.8 and Section 9.1.1 of [RFC8040] to 248 add a new query parameter "resolve-system" and corresponding query 249 parameter capability URI. 251 1.5.1. Query Parameter 253 The "resolve-system" parameter controls whether to allow a server 254 copy any referenced system-defined configuration automatically 255 without the client doing so explicitly. This parameter is only 256 allowed with no values carried. If this parameter has any unexpected 257 value, then a "400 Bad Request" status-line is returned. 259 +----------------+---------+-----------------------------------------+ 260 | Name | Methods | Description | 261 +----------------+---------+-----------------------------------------+ 262 |resolve-system | POST, | resolve any references not resolved by | 263 | | PUT | the client and copy referenced | 264 | | | system configuration into | 265 | | | automatically. This parameter can be | 266 | | | given in any order. | 267 +----------------+---------+-----------------------------------------+ 269 1.5.2. Query Parameter URI 271 To enable the RESTCONF client to discover if the "resolve-system" 272 query parameter is supported by the server, the following capability 273 URI is defined, which is advertised by the server if supported, using 274 the "ietf-restconf-monitoring" module defined in RFC 8040: 276 urn:ietf:params:restconf:capability:resolve-system:1.0 278 2. Kinds of System Configuration 280 There are three types of system configurations: immediately-active 281 system configuration, conditionally-active system configuration and 282 inactive-until-referenced system configuration. 284 2.1. Immediately-Active 286 Immediately-active system configurations are those generated in 287 and applied immediately when the device is powered on (e.g., 288 a loop-back interface) , irrespective of physical resource present or 289 not, a special functionality enabled or not. 291 2.2. Conditionally-Active 293 System configurations which are generated in and applied 294 based on specific conditions being met in a system, e.g., if a 295 physical resource is present (e.g., insert interface card), the 296 system will automatically detect it and load pre-provisioned 297 configuration; when the physical resource is not present( remove 298 interface card), the system configuration will be automatically 299 cleared. Another example is when a special functionality is enabled, 300 e.g., when QoS function is enabled, QoS policies are automatically 301 created by the system. 303 2.3. Inactive-Until-Referenced 305 There are some predefined objects(e.g., application ids, anti-x 306 signatures, trust anchor certs, etc.) as a convenience for the 307 clients. The clients can also define their own data objects for 308 their unique requirements. Inactive-until-referenced system 309 configurations are generated in immediately when it is 310 powered on, but they are not applied and active until being 311 referenced. 313 3. Static Characteristics 315 3.1. Read-only to Clients 317 The configuration datastore is a read-only configuration 318 datastore (i.e., edits towards directly MUST be denied), 319 though the client may be allowed to override the value of a system- 320 initialized data node (see Section 4.4). Configuration defined in 321 is merged into , and present in if 322 it is actively in use by the device. Thus unless the resource is no 323 longer available (e.g., the interface removed physically), there is 324 no way to actually delete system configuration from a server, even if 325 a client may be allowed to delete the configuration copied from 326 into . Any deletable system-provided configuration 327 must be defined in [RFC8808], which is used to 328 initialize when the device is first-time powered on or 329 reset to its factory default condition. 331 3.2. May Change via Software Upgrades 333 System configuration MAY change dynamically, e.g., depending on 334 factors like device upgrade or if system-controlled resources(e.g., 335 HW available) change. In some implementations, when QoS function is 336 enabled, QoS-related policies are created by system. If the system 337 configuration gets changed, YANG notification (e.g., "push-change- 338 update" notification) [RFC8641][RFC8639][RFC6470] can be used to 339 notify the client. Any update of the contents in will not 340 cause the automatic update of , even if some of the system 341 configuration has already been copied into explicitly or 342 automatically before the update. 344 3.3. No Impact to 346 This work intends to have no impact to . As always, 347 system configuration will appear in with 348 "origin=system". This work enables a subset of those system 349 generated nodes to be defined like configuration, i.e., made visible 350 to clients in order for being referenced or configurable prior to 351 present in . "Config false" nodes are out of scope, 352 hence existing "config false" nodes are not impacted by this work. 354 4. Dynamic Behavior 356 4.1. Conceptual Model 358 This document introduces a mandatory datastore named "system" which 359 is used to hold all three types of system configurations defined in 360 Section 2. 362 When the device is powered on, immediately-active system 363 configuration will be generated in and applied immediately 364 but inactive-until-referenced system configuration only becomes 365 active if it is referenced by client-defined configuration. While 366 conditionally-active system configuration will be created and 367 immediately applied if the condition on system resources is met when 368 the device is powered on or running. 370 All above three types of system configurations will appear in 371 . Clients MAY reference nodes defined in , override 372 values of configurations defined in , and configure 373 descendant nodes of system-defined nodes, by copying or writing 374 intended configurations into the target configuration datastore 375 (e.g., ). 377 The server will merge and to create , in 378 which process, the data node appears in takes precedence 379 over the same node in if the server allows the node to be 380 modifiable; additional nodes to a list entry or new list/leaf-list 381 entries appear in extends the list entry or the whole list/ 382 leaf-list defined in if the server allows the list/leaf-list 383 to be updated. In addition, the configuration datastore 384 represents the configuration after all configuration transformation 385 to are performed (e.g., system-defined template expansion, 386 removal of inactive system configuration). If a server implements 387 , MUST be merged into . 389 Servers MUST enforce that configuration references in are 390 resolved within the datastore and ensure that 391 contains any referenced system objects. Clients MUST either 392 explicitly copy system-defined nodes into or use the 393 "resolve-system" parameter. The server MUST enforce that the 394 referenced system nodes configured into by the client is 395 consistent with . Note that aware clients know how 396 to discover what nodes exist in . How clients unaware of the 397 datastore can find appropriate configurations is beyond the 398 scope of this document. 400 No matter how the referenced system objects are copied into 401 , the nodes copied into would always be returned 402 after a read of , regardless if the client is 403 aware. 405 4.2. Explicit Declaration of System Configuration 407 It is possible for a client to explicitly declare system 408 configuration nodes in the target datastore (e.g., ) with 409 the same values as in , by configuring a node (list/leaf-list 410 entry, leaf, etc) in the target datastore (e.g., ) that 411 matches the same node and value in . 413 This explicit configuration of system-defined nodes in can 414 be useful, for example, when the client doesn't want a "system 415 client" to have a role or hasn't implemented the "resolve-system" 416 parameter. The client can explicitly declare (i.e. configure in 417 ) the list entries (with at least the keys) for any system 418 configuration list entries that are referenced elsewhere in 419 . The client does not necessarily need to declare all the 420 contents of the list entry (i.e. the descendant nodes) - only the 421 parts that are required to make the appear valid. 423 4.3. Servers Auto-configuring Referenced System Configuration 425 This document defines a new parameter "resolve-system" to the input 426 for the , and operations. 427 Clients that are aware of the "resolve-system" parameter MAY use this 428 parameter to avoid the requirement to provide a referentially 429 complete configuration in . 431 If the "resolve-system" is present, the server MUST copy relevant 432 referenced system-defined nodes into the target datastore (e.g., 433 ) without the client doing the copy/paste explicitly, to 434 resolve any references not resolved by the client. The server acting 435 as a "system client" like any other remote clients copies the 436 referenced system-defined nodes when triggered by the "resolve- 437 system" parameter. If the "resolve-system" parameter is not given by 438 the client, the server SHOULD NOT modify in any way 439 otherwise not specified by the client. 441 The server may automatically configure the list entries (with at 442 least the keys) in the target datastore (e.g., ) for any 443 system configuration list entries that are referenced elsewhere by 444 the clients. Similarly, not all the contents of the list entry 445 (i.e., the descendant nodes) are necessarily copied by the server - 446 only the parts that are required to make the valid. A read 447 back of (i.e., , or operation) 448 returns those automatically copied nodes. 450 4.4. Modifying (overriding) System Configuration 452 In some cases, a server may allow some parts of system configuration 453 to be modified. List keys in system configuration can't be changed 454 by a client, but other descendant nodes in a list entry may be 455 modifiable or non-modifiable. Leafs and leaf-lists outside of lists 456 may also be modifiable or non-modifiable. Even if some system 457 configuration has been copied into earlier, whether it is 458 modifiable or not in follows general YANG and NACM rules, 459 and other server-internal restrictions. If a system configuration 460 node is non-modifiable, then writing a different value for that node 461 in MUST return an error. The immutability of system 462 configuration is further defined in [I-D.ma-netmod-immutable-flag]. 464 Modification of system configuration is achieved by the client 465 writing configuration to that overrides the system 466 configuration. Configurations defined in take precedence 467 over system configuration nodes in if the server allows the 468 nodes to be modified. 470 A server may also allow a client to add data nodes to a list entry in 471 by writing those additional nodes in . Those 472 additional data nodes may not exist in (i.e. an *addition* 473 rather than an override). 475 While modifying (overriding) system configuration nodes may be 476 supported by a server, there is no mechanism for deleting a system 477 configuration node unless the resource is no longer available. For 478 example, a "mandatory true" leaf may have a value in which 479 can be modified (overridden) by a client setting that leaf to a value 480 in . But the leaf could not be deleted. Another example of 481 this might be that system initializes a value for a particular leaf 482 which is overridden by the client with intended value in . 483 The client may delete the leaf in , but system-initialized 484 value defined in will be in use and appear in . 486 Comment 1: What if contains a set of values for a leaf-list, 487 and a client configures another set of values for that leaf-list in 488 , will the set of values in completely replace the 489 set of values in ? Or the two sets of values are merged 490 together? 492 Comment 2: how "ordered-by user" lists and leaf-lists are merged? Do 493 the values go before or after, or is this a case where a 494 full-replace is needed. 496 4.5. Examples 498 This section shows the examples of server-configuring of 499 automatically, declaring a system-defined node in 500 explicitly, modifying a system-instantiated leaf's value and 501 configuring descendant nodes of a system-defined node. For each 502 example, the corresponding XML snippets are provided. 504 4.5.1. Server Configuring of Automatically 506 In this subsection, the following fictional module is used: 508 module example-application { 509 yang-version 1.1; 510 namespace "urn:example:application"; 511 prefix "app"; 513 import ietf-inet-types { 514 prefix "inet"; 515 } 516 container applications { 517 list application { 518 key "name"; 519 leaf name { 520 type string; 521 } 522 leaf protocol { 523 type enumeration { 524 enum tcp; 525 enum udp; 526 } 527 } 528 leaf destination-port { 529 type inet:port-number; 530 } 531 } 532 } 533 } 535 The server may predefine some applications as a convenience for the 536 clients. These predefined objects are applied only after being 537 referenced by other configurations, which fall into the "inactive- 538 until-referenced" system configuration as defined in Section 2. The 539 system-instantiated application entries may be present in as 540 follows: 542 543 544 ftp 545 tcp 546 21 547 548 549 tftp 550 udp 551 69 552 553 554 smtp 555 tcp 556 25 557 558 ... 559 561 The client may also define its customized applications. Suppose the 562 configuration of applications is present in as follows: 564 565 566 my-app-1 567 tcp 568 2345 569 570 571 my-app-2 572 udp 573 69 574 575 577 A fictional ACL YANG module is used as follows, which defines a 578 leafref for the leaf-list "application" data node to refer to an 579 existing application name. 581 module example-acl { 582 yang-version 1.1; 583 namespace "urn:example:acl"; 584 prefix "acl"; 586 import example-application { 587 prefix "app"; 588 } 589 import ietf-inet-types { 590 prefix "inet"; 591 } 593 container acl { 594 list acl_rule { 595 key "name"; 596 leaf name { 597 type string; 598 } 599 container matches { 600 choice l3 { 601 container ipv4 { 602 leaf source_address { 603 type inet:ipv4-prefix; 604 } 605 leaf destination_address { 606 type inet:ipv4-prefix; 607 } 608 } 609 } 610 choice applications { 611 leaf-list application { 612 type leafref { 613 path "/app:applications/app:application/app:name"; 614 } 615 } 616 } 617 } 618 leaf packet_action { 619 type enumeration { 620 enum forward; 621 enum drop; 622 enum redirect; 623 } 624 } 625 } 626 } 627 } 629 If a client configures an ACL rule referencing system predefined 630 nodes which are not present in , the client MAY issue an 631 operation with the parameter "resolve-system" as 632 follows: 634 636 637 638 639 640 641 642 643 allow_access_to_ftp_tftp 644 645 646 198.51.100.0/24 647 192.0.2.0/24 648 649 ftp 650 tftp 651 my-app-1 652 653 forward 654 655 656 657 658 659 661 Then following gives the configuration of applications in 662 which is returned in the response to a follow-up 663 operation: 665 666 667 my-app-1 668 tcp 669 2345 670 671 672 my-app-2 673 udp 674 69 675 676 677 ftp 678 679 680 tftp 681 682 684 Then the configuration of applications is present in as 685 follows: 687 690 691 my-app-1 692 tcp 693 2345 694 695 696 my-app-2 697 udp 698 69 699 700 701 ftp 702 tcp 703 21 704 705 706 tftp 707 udp 708 69 709 710 712 Since the configuration of application "smtp" is not referenced by 713 the client, it does not appear in but only in . 715 4.5.2. Declaring a System-defined Node in Explicitly 717 It's also possible for a client to explicitly declare the system- 718 defined configurations that are referenced. For instance, in the 719 above example, the client MAY also explicitly configure the following 720 system defined applications "ftp" and "tftp" only with the list key 721 "name" before referencing: 723 725 726 727 728 729 730 731 732 ftp 733 734 735 tftp 736 737 738 739 740 742 Then the client issues an operation to configure an ACL 743 rule referencing applications "ftp" and "tftp" without the parameter 744 "resolve-system" as follows: 746 748 749 750 751 752 753 754 755 allow_access_to_ftp_tftp 756 757 758 198.51.100.0/24 759 192.0.2.0/24 760 761 ftp 762 tftp 763 my-app-1 764 765 forward 766 767 768 769 770 772 Then following gives the configuration of applications in 773 which is returned in the response to a follow-up 774 operation, all the configuration of applications are explicitly 775 configured by the client: 777 778 779 my-app-1 780 tcp 781 2345 782 783 784 my-app-2 785 udp 786 69 787 788 789 ftp 790 791 792 tftp 793 794 796 Then the configuration of applications is present in as 797 follows: 799 802 803 my-app-1 804 tcp 805 2345 806 807 808 my-app-2 809 udp 810 69 811 812 813 ftp 814 tcp 815 21 816 817 818 tftp 819 udp 820 69 821 822 824 Since the application names "ftp" and "tftp" are explicitly 825 configured by the client, they take precedence as the value in 826 , the "origin" attribute will be set to "intended". 828 4.5.3. Modifying a System-instantiated Leaf's Value 830 In this subsection, we will use this fictional QoS data model: 832 module example-qos-policy { 833 yang-version 1.1; 834 namespace "urn:example:qos"; 835 prefix "qos"; 837 container qos-policies { 838 list policy { 839 key "name"; 840 leaf name { 841 type string; 842 } 843 list queue { 844 key "queue-id"; 845 leaf queue-id { 846 type int32 { 847 range "1..32"; 848 } 849 } 850 leaf maximum-burst-size { 851 type int32 { 852 range "0..100"; 853 } 854 } 855 } 856 } 857 } 858 } 860 Suppose a client creates a qos policy "my-policy" with 4 system 861 instantiated queues(1~4). The Configuration of qos-policies is 862 present in as follows: 864 865 my-policy 866 867 1 868 50 869 870 871 2 872 60 873 874 875 3 876 70 877 878 879 4 880 80 881 882 884 A client modifies the value of maximum-burst-size to 55 in queue-id 885 1: 887 889 890 891 892 893 894 895 my-policy 896 897 1 898 55 899 900 901 902 903 905 Then the configuration of qos-policies is present in as 906 follows: 908 911 my-policy 912 913 1 914 55 915 916 917 2 918 60 919 920 921 3 922 70 923 924 925 4 926 80 927 928 930 4.5.4. Configuring Descendant Nodes of a System-defined Node 932 This subsection also uses the fictional interface YANG module defined 933 in Appendix C.3 of [RFC8342]. Suppose the system provides a loopback 934 interface (named "lo0") with a default IPv4 address of "127.0.0.1" 935 and a default IPv6 address of "::1". 937 The configuration of "lo0" interface is present in as 938 follows: 940 941 942 lo0 943 127.0.0.1 944 ::1 945 946 948 The configuration of "lo0" interface is present in as 949 follows: 951 953 954 lo0 955 127.0.0.1 956 ::1 957 958 960 Later on, the client further configures the description node of a 961 "lo0" interface as follows: 963 965 966 967 968 969 970 971 972 lo0 973 loopback 974 975 976 977 978 980 Then the configuration of interface "lo0" is present in 981 as follows: 983 985 986 lo0 987 loopback 988 127.0.0.1 989 ::1 990 991 993 5. The Configuration Datastore 995 NMDA servers claiming to support this document MUST implement a 996 configuration datastore, and they SHOULD also implement the 997 datastore. 999 Following guidelines for defining datastores in the appendix A of 1000 [RFC8342], this document introduces a new datastore resource named 1001 'system' that represents the system configuration. A device MAY 1002 implement the mechanism defined in this document without implementing 1003 the "system" datastore, which would only eliminate the ability to 1004 programmatically determine the system configuration. 1006 * Name: "system" 1008 * YANG modules: all 1010 * YANG nodes: all "config true" data nodes up to the root of the 1011 tree, generated by the system 1013 * Management operations: The content of the datastore is set by the 1014 server in an implementation dependent manner. The content can not 1015 be changed by management operations via NETCONF, RESTCONF, the 1016 CLI, etc, but may change itself by upgrades and/or when resource- 1017 conditions are met. The datastore can be read using the standard 1018 NETCONF/RESTCONF protocol operations. 1020 * Origin: This document does not define any new origin identity when 1021 it interacts with datastore and flows into 1022 . The "system" origin Metadata Annotation [RFC7952] 1023 is used to indicate the origin of a data item is system. 1025 * Protocols: YANG-driven management protocols, such as NETCONF and 1026 RESTCONF. 1028 * Defining YANG module: "ietf-system-datastore". 1030 The datastore's content is defined by the server and read-only to 1031 clients. Upon the content is created or changed, it will be merged 1032 into datastore. Unlike [RFC8808], it MAY 1033 change dynamically, e.g., depending on factors like device upgrade or 1034 system-controlled resources change (e.g., HW available). The 1035 datastore doesn't persist across reboots; the contents of 1036 will be lost upon reboot and recreated by the system with 1037 the same or changed contents. RPC operation defined 1038 in [RFC8808] can reset it to its factory default configuration 1039 without including configuration generated due to the system update or 1040 client-enabled functionality. 1042 The datastore is defined as a conventional configuration 1043 datastore and shares a common datastore schema with other 1044 conventional datastores. The configuration datastore must 1045 always be valid, as defined in Section 8.1 of [RFC7950]. 1047 6. The "ietf-system-datastore" Module 1049 6.1. Data Model Overview 1051 This YANG module defines a new YANG identity named "system" that uses 1052 the "ds:datastore" identity defined in [RFC8342]. A client can 1053 discover the datastore support on the server by reading the 1054 YANG library information from the operational state datastore. Note 1055 that no new origin identity is defined in this document, the 1056 "or:system" origin Metadata Annotation [RFC7952] is used to indicate 1057 the origin of a data item is system. Support for the "origin" 1058 annotation is identified with the feature "origin" defined in 1059 [RFC8526]. 1061 The following diagram illustrates the relationship amongst the 1062 "identity" statements defined in the "ietf-system-datastore" and 1063 "ietf-datastores" YANG modules: 1065 Identities: 1066 +--- datastore 1067 | +--- conventional 1068 | | +--- running 1069 | | +--- candidate 1070 | | +--- startup 1071 | | +--- system 1072 | | +--- intended 1073 | +--- dynamic 1074 | +--- operational 1075 The diagram above uses syntax that is similar to but not defined in [RFC8340]. 1077 6.2. Example Usage 1079 This section gives an example of data retrieval from . The 1080 YANG module used are shown in Appendix C.2 of [RFC8342]. All the 1081 messages are presented in a protocol-independent manner. JSON is 1082 used only for its conciseness. 1084 Suppose the following data is added to : 1086 { 1087 "bgp": { 1088 "local-as": "64501", 1089 "peer-as": "64502", 1090 "peer": { 1091 "name": "2001:db8::2:3" 1092 } 1093 } 1094 } 1095 REQUEST (a or GET request sent from the NETCONF or 1096 RESTCONF client): 1098 Datastore: 1099 Target:/bgp 1101 An example of RESTCONF request: 1103 GET /restconf/ds/system/bgp HTTP/1.1 1104 Host: example.com 1105 Accept: application/yang-data+xml 1107 RESPONSE ("local-port" leaf value is supplied by the system): 1109 { 1110 "bgp": { 1111 "peer": { 1112 "name": "2001:db8::2:3", 1113 "local-port": "60794" 1114 } 1115 } 1116 } 1118 6.3. YANG Module 1120 1121 file="ietf-system-datastore@2021-05-14.yang" 1122 module ietf-system-datastore { 1123 yang-version 1.1; 1124 namespace "urn:ietf:params:xml:ns:yang:ietf-system-datastore"; 1125 prefix sysds; 1127 import ietf-datastores { 1128 prefix ds; 1129 reference 1130 "RFC 8342: Network Management Datastore Architecture(NMDA)"; 1131 } 1133 organization 1134 "IETF NETMDOD (Network Modeling) Working Group"; 1136 contact 1137 "WG Web: 1138 WG List: 1139 Author: Qiufang Ma 1140 1141 Author: Chong Feng 1142 1144 Author: Qin Wu 1145 "; 1147 description 1148 "This module defines a new YANG identity that uses the 1149 ds:datastore identity defined in [RFC8342]. 1151 Copyright (c) 2021 IETF Trust and the persons identified 1152 as authors of the code. All rights reserved. 1154 Redistribution and use in source and binary forms, with 1155 or without modification, is permitted pursuant to, and 1156 subject to the license terms contained in, the Simplified 1157 BSD License set forth in Section 4.c of the IETF Trust's 1158 Legal Provisions Relating to IETF Documents 1159 (https://trustee.ietf.org/license-info). 1161 This version of this YANG module is part of RFC HHHH 1162 (https://www.rfc-editor.org/info/rfcHHHH); see the RFC 1163 itself for full legal notices. 1165 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1166 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1167 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1168 are to be interpreted as described in BCP 14 (RFC 2119) 1169 (RFC 8174) when, and only when, they appear in all 1170 capitals, as shown here."; 1172 revision 2021-05-14 { 1173 description 1175 "Initial version."; 1176 reference 1177 "RFC XXXX: System-defined Configuration"; 1178 } 1180 identity system { 1181 base ds:conventional; 1182 description 1183 "This read-only datastore contains the complete configuration 1184 provided by the system itself."; 1185 } 1186 } 1187 1189 7. The "ietf-netconf-resolve-system" Module 1191 This YANG module is optional to implement. 1193 7.1. Data Model Overview 1195 This YANG module augments NETCONF , and 1196 operations with a new parameter "resolve-system" in the 1197 input parameters. If the "resolve-system" parameter is present, the 1198 server will copy the referenced system configuration into target 1199 datastore automatically. A NETCONF client can discover the "resolve- 1200 system" parameter support on the server by checking the YANG library 1201 information with "ietf-netconf-resolve-system" included from the 1202 operational state datastore. 1204 The following tree diagram [RFC8340] illustrates the "ietf-netconf- 1205 resolve-system" module: 1207 module: ietf-netconf-resolve-system 1208 augment /nc:edit-config/nc:input: 1209 +---w resolve-system? empty 1210 augment /nc:copy-config/nc:input: 1211 +---w resolve-system? empty 1212 augment /ncds:edit-data/ncds:input: 1213 +---w resolve-system? empty 1215 The following tree diagram [RFC8340] illustrates "edit-config", 1216 "copy-config" and "edit-data" rpcs defined in "ietf-netconf" and 1217 "ietf-netconf-nmda" respectively, augmented by "ietf-netconf-resolve- 1218 system" YANG module : 1220 rpcs: 1221 +---x edit-config 1222 | +---w input 1223 | +---w target 1224 | | +---w (config-target) 1225 | | +--:(candidate) 1226 | | | +---w candidate? empty {candidate}? 1227 | | +--:(running) 1228 | | +---w running? empty {writable-running}? 1229 | +---w default-operation? enumeration 1230 | +---w test-option? enumeration {validate}? 1231 | +---w error-option? enumeration 1232 | +---w (edit-content) 1233 | | +--:(config) 1234 | | | +---w config? 1235 | | +--:(url) 1236 | | +---w url? inet:uri {url}? 1237 | +---w resolve-system? empty 1238 +---x copy-config 1239 | +---w input 1240 | +---w target 1241 | | +---w (config-target) 1242 | | +--:(candidate) 1243 | | | +---w candidate? empty {candidate}? 1244 | | +--:(running) 1245 | | | +---w running? empty {writable-running}? 1246 | | +--:(startup) 1247 | | | +---w startup? empty {startup}? 1248 | | +--:(url) 1249 | | +---w url? inet:uri {url}? 1250 | +---w source 1251 | | +---w (config-source) 1252 | | +--:(candidate) 1253 | | | +---w candidate? empty {candidate}? 1254 | | +--:(running) 1255 | | | +---w running? empty 1256 | | +--:(startup) 1257 | | | +---w startup? empty {startup}? 1258 | | +--:(url) 1259 | | | +---w url? inet:uri {url}? 1260 | | +--:(config) 1261 | | +---w config? 1262 | +---w resolve-system? empty 1263 +---x edit-data 1264 +---w input 1265 +---w datastore ds:datastore-ref 1266 +---w default-operation? enumeration 1267 +---w (edit-content) 1268 | +--:(config) 1269 | | +---w config? 1270 | +--:(url) 1271 | +---w url? inet:uri {nc:url}? 1272 +---w resolve-system? empty 1274 7.2. Example Usage 1276 This section gives an example of an request to 1277 reference system-defined data nodes which are not present in 1278 with a "resolve-system" parameter. A retrieval of 1279 to show the auto-copied referenced system objects after the 1280 request is also given. The YANG module used is shown 1281 as follows, leafrefs refer to an existing name and address of an 1282 interface: 1284 module example-interface-management { 1285 yang-version 1.1; 1286 namespace "urn:example:interfacemgmt"; 1287 prefix "inm"; 1289 container interfaces { 1290 list interface { 1291 key name; 1292 leaf name { 1293 type string; 1294 } 1295 leaf description { 1296 type string; 1297 } 1298 leaf mtu { 1299 type uint16; 1300 } 1301 leaf ip-address { 1302 type inet:ip-address; 1303 } 1304 } 1305 } 1306 container default-address { 1307 leaf ifname { 1308 type leafref { 1309 path "../../interfaces/interface/name"; 1310 } 1311 } 1312 leaf address { 1313 type leafref { 1314 path "../../interfaces/interface[name = current()/../ifname]" 1315 + "/ip-address"; 1316 } 1317 } 1318 } 1319 } 1321 Image that the system provides a loopback interface (named "lo0") 1322 with a predefined MTU value of "1500" and a predefined IP address of 1323 "127.0.0.1". The datastore shows the following 1324 configuration of loopback interface: 1326 1327 1328 lo0 1329 1500 1330 127.0.0.1 1331 1332 1334 The client sends an operation to add the configuration 1335 of default-address with a "resolve-system" parameter: 1337 1338 1339 1340 1341 1342 1343 1344 lo0 1345
127.0.0.1
1346 1347 1348 1349 1350 1352 Since the "resolve-system" parameter is provided, the server will 1353 resolve any leafrefs to system configurations and copy the referenced 1354 system-defined nodes into automatically with the same value 1355 (i.e., the name and ip-address data nodes of lo0 interface) in 1356 at the end of operation constraint 1357 enforcement. After the processing, a positive resonse is returned: 1359 1361 1362 1364 Then the client sends a operation towards : 1366 1368 1369 1370 1371 1372 1373 1374 1375 1376 1378 Given that the referenced interface "name" and "ip-address" of lo0 1379 are configured by the server, the following response is returned: 1381 1383 1384 1385 1386 lo0 1387 127.0.0.1 1388 1389 1390 1391 1393 7.3. YANG Module 1395 1396 file="ietf-netconf-resolve-system@2021-05-14.yang" 1397 module ietf-netconf-resolve-system { 1398 yang-version 1.1; 1399 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-resolve-system"; 1400 prefix ncrs; 1402 import ietf-netconf { 1403 prefix nc; 1404 reference 1405 "RFC 6241: Network Configuration Protocol (NETCONF)"; 1406 } 1408 import ietf-netconf-nmda { 1409 prefix ncds; 1410 reference 1411 "RFC 8526: NETCONF Extensions to Support the Network 1412 Management Datastore Architecture"; 1413 } 1414 organization 1415 "IETF NETMOD (Network Modeling) Working Group"; 1417 contact 1418 "WG Web: 1419 WG List: 1420 Author: Qiufang Ma 1421 1422 Author: Chong Feng 1423 1424 Author: Qin Wu 1425 "; 1427 description 1428 "This module defines an extension to the NETCONF protocol 1429 that allows the NETCONF client to control whether the server 1430 is allowed to copy referenced system configuration 1431 automatically without the client doing so explicitly. 1433 Copyright (c) 2021 IETF Trust and the persons identified 1434 as authors of the code. All rights reserved. 1436 Redistribution and use in source and binary forms, with 1437 or without modification, is permitted pursuant to, and 1438 subject to the license terms contained in, the Simplified 1439 BSD License set forth in Section 4.c of the IETF Trust's 1440 Legal Provisions Relating to IETF Documents 1441 (https://trustee.ietf.org/license-info). 1443 This version of this YANG module is part of RFC HHHH 1444 (https://www.rfc-editor.org/info/rfcHHHH); see the RFC 1445 itself for full legal notices. 1447 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 1448 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 1449 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 1450 are to be interpreted as described in BCP 14 (RFC 2119) 1451 (RFC 8174) when, and only when, they appear in all 1452 capitals, as shown here."; 1454 revision 2021-05-14 { 1455 description 1456 "Initial version."; 1457 reference 1458 "RFC XXXX: System-defined Configuration"; 1459 } 1461 augment /nc:edit-config/nc:input { 1462 description 1463 "Allows the server to automatically configure 1464 referenced system configuration to make configuration 1465 valid."; 1466 leaf resolve-system { 1467 type empty ; 1468 description 1469 "When present, the server is allowed to automatically 1470 configure referenced system configuration into the 1471 target configuration datastore."; 1472 } 1473 } 1475 augment /nc:copy-config/nc:input { 1476 description 1477 "Allows the server to automatically configure 1478 referenced system configuration to make configuration 1479 valid."; 1480 leaf resolve-system { 1481 type empty ; 1482 description 1483 "When present, the server is allowed to automatically 1484 configure referenced system configuration into the 1485 target configuration datastore."; 1486 } 1487 } 1489 augment /ncds:edit-data/ncds:input { 1490 description 1491 "Allows the server to automatically configure 1492 referenced system configuration to make configuration 1493 valid."; 1494 leaf resolve-system { 1495 type empty ; 1496 description 1497 "When present, the server is allowed to automatically 1498 configure referenced system configuration into the 1499 target configuration datastore."; 1500 } 1501 } 1502 } 1503 1505 8. IANA Considerations 1506 8.1. The "IETF XML" Registry 1508 This document registers two XML namespace URNs in the 'IETF XML 1509 registry', following the format defined in [RFC3688]. 1511 URI: urn:ietf:params:xml:ns:yang:ietf-system-datastore 1512 Registrant Contact: The IESG. 1513 XML: N/A, the requested URIs are XML namespaces. 1515 URI: urn:ietf:params:xml:ns:yang:ietf-netconf-resolve-system 1516 Registrant Contact: The IESG. 1517 XML: N/A, the requested URIs are XML namespaces. 1519 8.2. The "YANG Module Names" Registry 1521 This document registers two module names in the 'YANG Module Names' 1522 registry, defined in [RFC6020] . 1524 name: ietf-system-datastore 1525 prefix: sys 1526 namespace: urn:ietf:params:xml:ns:yang:ietf-system-datatstore 1527 RFC: XXXX // RFC Ed.: replace XXXX and remove this comment 1529 name: ietf-netconf-resolve-system 1530 prefix: ncrs 1531 namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-resolve-system 1532 RFC: XXXX // RFC Ed.: replace XXXX and remove this comment 1534 8.3. RESTCONF Capability URN Registry 1536 This document registers a capability in the "RESTCONF Capability 1537 URNs" registry [RFC8040]: 1539 Index Capability Identifier 1540 ------------------------------------------------------------------------------- 1541 :resolve-system urn:ietf:params:restconf:capability:resolve-system:1.0 1543 9. Security Considerations 1545 9.1. Regarding the "ietf-system-datastore" YANG Module 1547 The YANG module defined in this document extends the base operations 1548 for NETCONF [RFC6241] and RESTCONF [RFC8040]. The lowest NETCONF 1549 layer is the secure transport layer, and the mandatory-to-implement 1550 secure transport is Secure Shell (SSH) [RFC6242]. The lowest 1551 RESTCONF layer is HTTPS, and the mandatory-to-implement secure 1552 transport is TLS [RFC8446]. 1554 The Network Configuration Access Control Model (NACM) [RFC8341] 1555 provides the means to restrict access for particular NETCONF users to 1556 a preconfigured subset of all available NETCONF protocol operations 1557 and content. 1559 9.2. Regarding the "ietf-netconf-resolve-system" YANG Module 1561 The YANG module defined in this document extends the base operations 1562 for NETCONF [RFC6241] and [RFC8526]. The lowest NETCONF layer is the 1563 secure transport layer, and the mandatory-to-implement secure 1564 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 1565 is HTTPS, and the mandatory-to-implement secure transport is TLS 1566 [RFC8446]. 1568 The Network Configuration Access Control Model (NACM) [RFC8341] 1569 provides the means to restrict access for particular NETCONF users to 1570 a preconfigured subset of all available NETCONF protocol operations 1571 and content. 1573 The security considerations for the base NETCONF protocol operations 1574 (see Section 9 of [RFC6241] apply to the new extended RPC operations 1575 defined in this document. 1577 10. Contributors 1579 Chongfeng Xie 1580 China Telecom 1581 Beijing 1582 China 1584 Email: xiechf@chinatelecom.cn 1586 Jason Sterne 1587 Nokia 1589 Email: jason.sterne@nokia.com 1591 Acknowledgements 1593 Thanks to Robert Wilton, Balazs Lengyel, Andy Bierman, Juergen 1594 Schoenwaelder, Alex Clemm, Martin Bjorklund, Timothy Carey for 1595 reviewing, and providing important input to, this document. 1597 References 1599 Normative References 1601 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1602 Requirement Levels", BCP 14, RFC 2119, 1603 DOI 10.17487/RFC2119, March 1997, 1604 . 1606 Informative References 1608 [I-D.ma-netmod-immutable-flag] 1609 Ma, Q., Wu, Q., and H. Li, "Immutable Metadata 1610 Annotation", Work in Progress, Internet-Draft, draft-ma- 1611 netmod-immutable-flag-00, 10 February 2022, 1612 . 1615 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1616 and A. Bierman, Ed., "Network Configuration Protocol 1617 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1618 . 1620 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1621 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1622 . 1624 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1625 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1626 May 2017, . 1628 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1629 and R. Wilton, "Network Management Datastore Architecture 1630 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1631 . 1633 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 1634 Documents Containing YANG Data Models", BCP 216, RFC 8407, 1635 DOI 10.17487/RFC8407, October 2018, 1636 . 1638 [RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 1639 and R. Wilton, "YANG Library", RFC 8525, 1640 DOI 10.17487/RFC8525, March 2019, 1641 . 1643 [RFC8808] Wu, Q., Lengyel, B., and Y. Niu, "A YANG Data Model for 1644 Factory Default Settings", RFC 8808, DOI 10.17487/RFC8808, 1645 August 2020, . 1647 Appendix A. Key Use Cases 1649 Following provides three use cases related to system-defined 1650 configuration lifecycle management. The simple interface data model 1651 defined in Appendix C.3 of [RFC8342] is used. For each use case, 1652 snippets of , , and are 1653 shown. 1655 A.1. Device Powers On 1657 : 1659 No configuration for “lo0” appears in ; 1661 : 1663 1664 1665 lo0 1666 127.0.0.1 1667 ::1 1668 1669 1671 : 1673 1674 1675 lo0 1676 127.0.0.1 1677 ::1 1678 1679 1681 : 1683 1685 1686 lo0 1687 127.0.0.1 1688 ::1 1689 1690 1692 A.2. Client Commits Configuration 1694 If a client creates an interface "et-0/0/0" but the interface does 1695 not physically exist at this point: 1697 : 1699 1700 1701 et-0/0/0 1702 Test interface 1703 1704 1706 : 1708 1709 1710 lo0 1711 127.0.0.1 1712 ::1 1713 1714 1716 : 1718 1719 lo0 1720 127.0.0.1 1721 ::1 1722 1723 1724 et-0/0/0 1725 Test interface 1726 1727 1728 1730 : 1732 1734 1735 lo0 1736 127.0.0.1 1737 ::1 1738 1739 1741 A.3. Operator Installs Card into a Chassis 1743 : 1745 1746 1747 et-0/0/0 1748 Test interface 1749 1750 1752 : 1754 1755 1756 lo0 1757 127.0.0.1 1758 ::1 1759 1760 1761 et-0/0/0 1762 1500 1763 1764 1766 : 1768 1769 lo0 1770 127.0.0.1 1771 ::1 1772 1773 1774 et-0/0/0 1775 Test interface 1776 1500 1777 1778 1779 1781 : 1783 1785 1786 lo0 1787 127.0.0.1 1788 ::1 1789 1790 1791 et-0/0/0 1792 Test interface 1793 1500 1794 1795 1796 1798 Appendix B. Changes between Revisions 1800 v02 - v03 1802 * Define a RESTCONF capability URI for "resolve-system" RESTCONF 1803 query parameter; 1805 * Augment RPC operation to support "resolve-system" 1806 for input parameter; 1808 * Editorial changes for clarification and explanation. E.g., 1809 definition of system configuration, is always valid? 1810 Will the update of be reflected into ? Clarify 1811 "read-only to clients" and "modifying system configuration", non- 1812 deletable system configuration, etc 1814 v00 - v02 1816 * Remove the "with-system" parameter to retrieve with 1817 system configuration merged in. 1819 * Add a new parameter named "resolve-system" to allow the server to 1820 populate referenced system configuration into 1821 automatically in order to make valid. 1823 * Usage examples refinement. 1825 v02 - v00 1827 * Restructure the document content based on input in the system 1828 defined configuration interim meeting. 1830 * Updates NMDA to define a read-only conventional configuration 1831 datastore called "system". 1833 * Retrieval of implicit hidden system configuration via with "with-system" parameter to support non-NMDA servers. 1836 * Provide system defined configuration classification. 1838 * Define Static Characteristics and dynamic behavior for system 1839 defined configuration. 1841 * Separate "ietf-system-datastore" Module from "ietf-netconf-with- 1842 system" Module. 1844 * Provide usage examples for dynamic behaviors. 1846 * Provide usage examples for two YANG modules. 1848 * Provide three use cases related to system-defined configuration 1849 lifecycle management. 1851 * Classify the relation with . 1853 Appendix C. Open Issues tracking 1855 * Should the "with-origin" parameter be supported for ? 1857 Authors' Addresses 1859 Qiufang Ma (editor) 1860 Huawei 1861 101 Software Avenue, Yuhua District 1862 Nanjing 1863 Jiangsu, 210012 1864 China 1865 Email: maqiufang1@huawei.com 1867 Kent Watsen 1868 Watsen Networks 1869 Email: kent+ietf@watsen.net 1870 Qin Wu 1871 Huawei 1872 101 Software Avenue, Yuhua District 1873 Nanjing 1874 Jiangsu, 210012 1875 China 1876 Email: bill.wu@huawei.com 1878 Feng Chong 1879 Huawei 1880 101 Software Avenue, Yuhua District 1881 Nanjing 1882 Jiangsu, 210012 1883 China 1884 Email: frank.fengchong@huawei.com 1886 Jan Lindblad 1887 Cisco Systems 1888 Email: jlindbla@cisco.com