idnits 2.17.1 draft-ietf-netconf-nmda-netconf-01.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 draft header indicates that this document updates RFC7950, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 497 has weird spacing: '...library urn:...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 30, 2017) is 2342 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: 'RFC3688' is mentioned on line 499, but not defined == Missing Reference: 'RFC6020' is mentioned on line 510, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-netmod-revised-datastores-05 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bjorklund 3 Internet-Draft Tail-f Systems 4 Updates: 7950 (if approved) J. Schoenwaelder 5 Intended status: Standards Track Jacobs University 6 Expires: May 3, 2018 P. Shafer 7 K. Watsen 8 Juniper Networks 9 R. Wilton 10 Cisco Systems 11 October 30, 2017 13 NETCONF Model for NMDA 14 draft-ietf-netconf-nmda-netconf-01 16 Abstract 18 The "Network Management Datastore Architecture" (NMDA) improves on 19 NETCONF by adding new features to give more accurate handling of 20 configuration and operational data. These include ability to inspect 21 the current operational values of configuration data, allowing 22 clients to use identical paths for retrieving the configured values 23 and the operational values. These new features require additional 24 operations in network management applications such as NETCONF. This 25 document details those new operations. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 3, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. The NMDA Model for NETCONF . . . . . . . . . . . . . . . . . 3 65 2.1. Operations . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.1.1. The Operation . . . . . . . . . . . . . . 3 67 2.1.2. The Operation . . . . . . . . . . . . . . 4 68 2.2. Augmentations to the Base NETCONF Model . . . . . . . . . 5 69 2.3. RPCs and Actions . . . . . . . . . . . . . . . . . . . . 5 70 2.4. YANG Library Capability . . . . . . . . . . . . . . . . . 5 71 3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 6. Informative References . . . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 77 1. Introduction 79 This document provides a YANG model that adds NETCONF ([RFC6241]) 80 support for the "Network Management Datastore Architecture" (NMDA) 81 [I-D.ietf-netmod-revised-datastores]. NMDA defines a framework for 82 datastores, a fundamental concept binding network management data 83 models to network management protocols, enabling data models to be 84 written in a network management protocol agnostic way. NETCONF 85 operations currently refer to the datastores defined in the original 86 model, so new operations are required to allow references to the new 87 datastores. 89 Operations like , and are augmented to 90 allow them to target additional datastores. 92 In addition the original operation is deprecated, since the 93 information it returns is no longer needed. 's deficiencies 94 were a major motivation for the NMDA. 96 1.1. Keywords 98 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 100 "OPTIONAL" in this document are to be interpreted as described in BCP 101 14, [RFC2119] [RFC8174] when, and only when, they appear in all 102 capitals, as shown here.. 104 1.2. Terminology 106 This document uses the terminology defined by the NMDA 107 [I-D.ietf-netmod-revised-datastores]. 109 2. The NMDA Model for NETCONF 111 This section describes the changes needed for NMDA support. These 112 changes are contained in a new YANG ([RFC7950]) model 113 "ietf-netconf-datastores". 115 These changes include the use of source and target parameters based 116 on the "datastore" identity defined in the "ietf-datastores" from 117 [I-D.ietf-netmod-revised-datastores]. The use of identities allows 118 future expansion in a way that the choice-based strategy from the 119 original operations (e.g., , ) do not. 121 2.1. Operations 123 Support for the NMDA includes two new operations defined in this 124 document. 126 2.1.1. The Operation 128 The operation retrieves data from a specific NMDA 129 datastore. This operation is similar to NETCONF's 130 operation, but adds flexibility in naming the source datastore. 132 The "source" parameter indicates the datastore which is the source of 133 the data to be retrieved. This is a datastore identity. 135 The operation accepts a content filter parameter, similar 136 to the "filter" parameter of "get-config", but using explicit nodes 137 for subtree filtering and XPath filtering. 139 Additional filters are defined to retrieve only "config true" nodes 140 or nodes matching a given "origin" value. 142 The operation also supports the "with-defaults" parameter 143 as defined in [RFC6243]. The supported values follow the constraints 144 given by the "with-defaults" capability. 146 2.1.1.1. Origin Metadata Attribute 148 The operation adds a new parameter named "with-origin", 149 which if present, requests that the server includes "origin" metadata 150 anotations in its response, as detailed in the NMDA. This parameter 151 is only valid for and any datastores with identities 152 derived from the "operational" identity. Otherwise, if an invalid 153 datastore is specified then an element is returned with 154 an value of "invalid-value". "origin" metadata 155 annotations are not included unless a client explicitly requesteds 156 them. 158 Data from can come from multiple sources. The server 159 should return the most accurate value for the "origin" metadata 160 annotation as possible, indicating the source of the operational 161 value, as specified in section 5.3.4 of the NMDA. 163 When encoding the origin metadata annotation for a hierarchy of 164 returned nodes, the annotation may be omitted for a child node when 165 the value matches that of the parent node (as described in ietf- 166 origin@2017-08-17). [RFC Editor, please check published revision 167 date.] 169 The "with-origin" parameter is optional to support. It is identified 170 with the URI: 172 urn:ietf:params:netconf:capability:with-origin:1.0 174 2.1.2. The Operation 176 The operation changes the contents of a specific 177 datastore, similar to the operation, but with 178 additional flexibility in naming the target datastore. 180 The "datastore" parameter is a datastore identity that indicates the 181 desired target datastore where changes should be made. 183 The "edit-content" parameter from "edit-config" it is modified to 184 allow use "type anydata" for configuration content, rather than the 185 "edit-config"'s use of "type anyxml". 187 The "default-operation" parameter mirrors the parameter of the 188 operation. 190 2.2. Augmentations to the Base NETCONF Model 192 Several of the operations defined in the base NETCONF data model 193 (ietf-netconf@2011-06-01.yang) will continue to be used under the 194 NMDA. The , , and operations are augmented 195 with a new "datastore" leaf can indicate a desired NMDA datastore. 197 Only writable datastores can be locked. 199 2.3. RPCs and Actions 201 RPC operations and actions can be defined in YANG modules. The 202 evaluation context for constraints and references in RPC operations 203 and actions is , as specified in the NMDA. 205 2.4. YANG Library Capability 207 RFC Ed.: Update 201X-XX-XX below with correct date. 209 Support for NMDA requires the server to implement at least revision 210 201X-XX-XX of the "ietf-yang-library" module defined in 211 [I-D.nmdsdt-netconf-rfc7895bis]. The server MUST advertise the 212 following capability in the message (line breaks and 213 whitespaces are used for formatting reasons only): 215 urn:ietf:params:netconf:capability:yang-library:1.1? 216 revision=&checksum= 218 The parameter "revision" has the same value as the revision date of 219 the "ietf-yang-library" module implemented by the server. This 220 parameter MUST be present. 222 The parameter "checksum" has the same value as the leaf 223 "/yang-library/checksum" from "ietf-yang-library". This parameter 224 MUST be present. 226 With this mechanism, a client can cache the supported modules for a 227 server and only update the cache if the "checksum" value in the 228 message changes. 230 This document updates [RFC7950], section 5.6.4, to allow servers to 231 advertise the capability :yang-library:1.1 instead of :yang- 232 library:1.0, and to implement the subtree "/yang-library" 233 [I-D.nmdsdt-netconf-rfc7895bis] instead of "/modules-state". 235 3. YANG Model 237 file "ietf-netconf-datastores@2017-08-24.yang" 239 module ietf-netconf-datastores { 240 yang-version 1.1; 241 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-datastores"; 242 prefix ncds; 244 import ietf-yang-types { 245 prefix yang; 246 } 247 import ietf-inet-types { 248 prefix inet; 249 } 250 import ietf-datastores { 251 prefix ds; 252 } 253 import ietf-origin { 254 prefix or; 255 } 256 import ietf-netconf { 257 prefix nc; 258 } 259 import ietf-netconf-with-defaults { 260 prefix ncwd; 261 } 263 organization 264 "IETF NETCONF Working Group"; 265 contact 266 "WG Web: 268 WG List: 270 Author: Martin Bjorklund 271 273 Author: Juergen Schoenwaelder 274 276 Author: Phil Shafer 277 279 Author: Kent Watsen 280 282 Author: Rob Wilton 283 "; 284 description 285 "This YANG module defines a set of NETCONF operations for the 286 Network Management Datastore Architecture (NMDA). 288 Copyright (c) 2017 IETF Trust and the persons identified as 289 authors of the code. All rights reserved. 291 Redistribution and use in source and binary forms, with or 292 without modification, is permitted pursuant to, and subject to 293 the license terms contained in, the Simplified BSD License set 294 forth in Section 4.c of the IETF Trust's Legal Provisions 295 Relating to IETF Documents 296 (http://trustee.ietf.org/license-info). 298 This version of this YANG module is part of RFC XXXX 299 (http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself 300 for full legal notices."; 302 revision 2017-08-24 { 303 description 304 "Initial revision."; 305 reference "RFC XXXX: NETCONF Support for NMDA"; 306 } 308 feature origin { 309 description 310 "Indicates that the server supports the 'origin' annotation."; 311 reference "RFC XXXX: Network Management Datastore Architecture"; 312 } 314 typedef datastore { 315 type identityref { 316 base ds:datastore; 317 } 318 description 319 "An NMDA datastore."; 320 reference "RFC XXXX: Network Management Datastore Architecture"; 321 } 323 rpc get-data { 324 description 325 "Retrieve data from an NMDA datastore."; 326 input { 327 leaf datastore { 328 type ncds:datastore; 329 mandatory true; 330 description 331 "Datastore from which to retrieve data."; 332 } 334 choice filter-spec { 335 description 336 "The content filter specification for this request."; 338 anydata subtree-filter { 339 description 340 "This parameter identifies the portions of the 341 target datastore to retrieve."; 342 reference "RFC 6241, Section 6."; 343 } 344 leaf xpath-filter { 345 if-feature nc:xpath; 346 type yang:xpath1.0; 347 description 348 "This parameter contains an XPath expression 349 identifying the portions of the target 350 datastore to retrieve."; 351 } 352 } 354 container where { 355 description 356 "Filter content with the specified criteria. All given 357 criteria are logically AND:ed."; 359 leaf config { 360 type boolean; 361 description 362 "Filter for nodes with the given value for their 363 'config' property."; 364 } 365 leaf origin { 366 if-feature origin; 367 type identityref { 368 base or:origin; 369 } 370 description 371 "Filter based on 'origin' annotation. A node matches the 372 filter if its 'origin' annotation is derived from or 373 equal to the given filter value."; 374 } 375 } 377 leaf with-origin { 378 when 'derived-from-or-self(../datastore, "or:operational")'; 379 if-feature origin; 380 type empty; 381 description 382 "If this parameter is present, the server will return 383 the 'origin' annotation for the nodes that has one."; 384 } 386 uses ncwd:with-defaults-parameters; 387 } 389 output { 390 anydata data { 391 description 392 "Copy of the source datastore subset which matched 393 the filter criteria (if any). An empty data 394 container indicates that the request did not 395 produce any results."; 396 } 397 } 398 } 400 rpc edit-data { 401 description 402 "Edit data in an NMDA datastore."; 403 input { 404 leaf datastore { 405 type ncds:datastore; 406 description 407 "Datastore which data affects."; 408 } 409 leaf default-operation { 410 type enumeration { 411 enum "merge" { 412 description 413 "The default operation is merge."; 414 } 415 enum "replace" { 416 description 417 "The default operation is replace."; 418 } 419 enum "none" { 420 description 421 "There is no default operation."; 422 } 423 } 424 default "merge"; 425 description 426 "The default operation to use."; 428 } 429 choice edit-content { 430 mandatory true; 431 description 432 "The content for the edit operation."; 434 anydata config { 435 description 436 "Inline Config content."; 437 } 438 leaf url { 439 if-feature nc:url; 440 type inet:uri; 441 description 442 "URL based config content."; 443 } 444 } 445 } 446 } 448 /* 449 * Augment the lock and unlock operations with a 450 * "datastore" parameter. 451 */ 453 augment "/nc:lock/nc:input/nc:target/nc:config-target" { 454 description 455 "Add NMDA Datastore as target."; 456 leaf datastore { 457 type ncds:datastore; 458 description 459 "Datastore to lock."; 460 } 461 } 462 augment "/nc:unlock/nc:input/nc:target/nc:config-target" { 463 description 464 "Add NMDA Datastore as target."; 465 leaf datastore { 466 type ncds:datastore; 467 description 468 "Datastore to unlock."; 469 } 470 } 472 /* 473 * Augment the validate operation with a 474 * "datastore" parameter. 475 */ 477 augment "/nc:validate/nc:input/nc:source/nc:config-source" { 478 description 479 "Add NMDA Datastore as source."; 480 leaf datastore { 481 type ncds:datastore; 482 description 483 "Datastore to validate."; 484 } 485 } 486 } 488 490 4. IANA Considerations 492 This document registers one capability identifier URN from the 493 "Network Configuration Protocol (NETCONF) Capability URNs" registry: 495 Index Capability Identifier 496 ------------- --------------------------------------------------- 497 :yang-library urn:ietf:params:netconf:capability:yang-library:1.1 499 This document registers a URI in the "IETF XML Registry" [RFC3688]. 500 Following the format in RFC 3688, the following registration has been 501 made. 503 URI: urn:ietf:params:xml:ns:yang:ietf-netconf-datastores 505 Registrant Contact: The IESG. 507 XML: N/A, the requested URI is an XML namespace. 509 This document registers a YANG module in the "YANG Module Names" 510 registry [RFC6020]. 512 name: ietf-netconf-datastores 513 namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-datastores 514 prefix: ncds 515 reference: RFC XXXX 517 5. Security Considerations 519 This document has no security considerations. 521 6. Informative References 523 [I-D.ietf-netmod-revised-datastores] 524 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 525 and R. Wilton, "Network Management Datastore 526 Architecture", draft-ietf-netmod-revised-datastores-05 527 (work in progress), October 2017. 529 [I-D.nmdsdt-netconf-rfc7895bis] 530 Bierman, A., Bjorklund, M., and K. Watsen, "YANG Library", 531 draft-nmdsdt-netconf-rfc7895bis-01 (work in progress), 532 July 2017. 534 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 535 Requirement Levels", BCP 14, RFC 2119, 536 DOI 10.17487/RFC2119, March 1997, . 539 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 540 and A. Bierman, Ed., "Network Configuration Protocol 541 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 542 . 544 [RFC6243] Bierman, A. and B. Lengyel, "With-defaults Capability for 545 NETCONF", RFC 6243, DOI 10.17487/RFC6243, June 2011, 546 . 548 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 549 RFC 7950, DOI 10.17487/RFC7950, August 2016, 550 . 552 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 553 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 554 May 2017, . 556 Authors' Addresses 558 Martin Bjorklund 559 Tail-f Systems 561 Email: mbj@tail-f.com 563 Juergen Schoenwaelder 564 Jacobs University 566 Email: j.schoenwaelder@jacobs-university.de 567 Phil Shafer 568 Juniper Networks 570 Email: phil@juniper.net 572 Kent Watsen 573 Juniper Networks 575 Email: kwatsen@juniper.net 577 Robert Wilton 578 Cisco Systems 580 Email: rwilton@cisco.com