idnits 2.17.1 draft-ietf-netconf-nmda-netconf-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 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 486 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 11, 2017) is 2388 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 488, but not defined == Missing Reference: 'RFC6020' is mentioned on line 499, but not defined == Outdated reference: A later version (-10) exists of draft-ietf-netmod-revised-datastores-04 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: April 14, 2018 P. Shafer 7 K. Watsen 8 Juniper Networks 9 R. Wilton 10 Cisco Systems 11 October 11, 2017 13 NETCONF Model for NMDA 14 draft-ietf-netconf-nmda-netconf-00 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 draft 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 April 14, 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 . . . . . . . . . 4 69 2.3. RPCs and Actions . . . . . . . . . . . . . . . . . . . . 5 70 2.4. YANG Library Capability . . . . . . . . . . . . . . . . . 5 71 3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 6. Informative References . . . . . . . . . . . . . . . . . . . 11 75 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Introduction 80 This document provides a YANG model that adds NETCONF ([RFC6241]) 81 support for the "Network Management Datastore Architecture" (NMDA) 82 [I-D.ietf-netmod-revised-datastores]. NMDA defines a framework for 83 datastores, a fundamental concept binding network management data 84 models to network management protocols, enabling data models to be 85 written in a network management protocol agnostic way. NETCONF 86 operations currently refer to the datastores defined in the original 87 model, so new operations are required to allow references to the new 88 datastores. 90 Operations like , and are augmented to 91 allow them to target additional datastores. 93 In addition the original operation is deprecated, since the 94 information it returns is no longer needed. 's deficiencies 95 were a major motivation for the NMDA. 97 1.1. Keywords 99 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in BCP 102 14, [RFC2119] [RFC8174] when, and only when, they appear in all 103 capitals, as shown here.. 105 1.2. Terminology 107 This document uses the terminology defined by the NMDA 108 [I-D.ietf-netmod-revised-datastores]. 110 2. The NMDA Model for NETCONF 112 This section describes the changes needed for NMDA support. These 113 changes are contained in a new YANG ([RFC7950]) model 114 "ietf-netconf-datastores". 116 These changes include the use of source and target parameters based 117 on the "datastore" identity defined in the "ietf-datastores" from 118 [I-D.ietf-netmod-revised-datastores]. The use of identities allows 119 future expansion in a way that the choice-based strategy from the 120 original operations (e.g. , ) do not. 122 2.1. Operations 124 Support for the NMDA includes two new operations defined in this 125 document. 127 2.1.1. The Operation 129 The operation retrieves data from a specific NMDA 130 datastore. This operation is similar to NETCONF's "get-config" 131 operation, but adds flexibility in naming the target datastore. 133 The "source" parameter indicates the datastore which is the source of 134 the data to be retrieved. This is a datastore identity. 136 The operation accepts a content filter parameter, similar 137 to the "filter" parameter of "get-config", but using explicit nodes 138 for subtree filtering and XPath filtering. 140 Additional filters are defined to retrieve only "config true" nodes 141 or nodes matching a given "origin" value. 143 The "get-data" operation also supports the "with-defaults" parameter 144 as defined in [RFC6243]. The supported values follow the constraints 145 given by the "with-defaults" capability. 147 2.1.1.1. Origin Attribute 149 The "get-data" operation adds a new boolean parameter named 150 "with-origin", which requests that the server returns the "origin" 151 information as detailed in the NMDA. This parameter is only valid 152 for and any datastores with identities derived from the 153 "operational" identity. 155 Data from can come from multiple sources. The server 156 should return the most accurate value for the "origin" attribute as 157 possible, indicating the source of the operational value. 159 When encoding the origin attribute for a hierarchy of returned nodes, 160 the origin attribute may be omitted when the value matches that of 161 the parent node. 163 2.1.2. The Operation 165 The operation changes the contents of a specific 166 datastore, similar to the operation, but with 167 additional flexibility in naming the target datastore. 169 The "target" parameter is a datastore identity that indicates the 170 desired target datastore where changes should be made. 172 The "edit-content" parameter from "edit-config" it is modified to 173 allow use "type anydata" for configuration content, rather than the 174 "edit-config"'s use of "type anyxml". 176 The "default-operation" parameter mirrors the parameter of the 177 "edit-config" operation. 179 2.2. Augmentations to the Base NETCONF Model 181 Several of the operations defined in the base NETCONF data model 182 (ietf-netconf@2011-06-01.yang) will continue to be used under the 183 NMDA. The , , and operations are augmented 184 with a new "datastore" leaf can indicate a desired NMDA datastore. 186 Only writable datastores can be locked. 188 2.3. RPCs and Actions 190 RPC operations and actions can be defined in YANG modules. The 191 evaluation context for constraints and references in operation and 192 actions is . 194 2.4. YANG Library Capability 196 RFC Ed.: Update 201X-XX-XX below with correct date. 198 Support for NMDA requires the server to implement at least revision 199 201X-XX-XX of the "ietf-yang-library" module defined in 200 [I-D.nmdsdt-netconf-rfc7895bis]. The server MUST advertise the 201 following capability in the message (line breaks and 202 whitespaces are used for formatting reasons only): 204 urn:ietf:params:netconf:capability:yang-library:1.1? 205 revision=&checksum= 207 The parameter "revision" has the same value as the revision date of 208 the "ietf-yang-library" module implemented by the server. This 209 parameter MUST be present. 211 The parameter "checksum" has the same value as the leaf 212 "/yang-library/checksum" from "ietf-yang-library". This parameter 213 MUST be present. 215 With this mechanism, a client can cache the supported modules for a 216 server and only update the cache if the "checksum" value in the 217 message changes. 219 This document updates [RFC7950], section 5.6.4, to allow servers to 220 advertise the capability :yang-library:1.1 instead of :yang- 221 library:1.0, and to implement the subtree "/yang-library" 222 [I-D.nmdsdt-netconf-rfc7895bis] instead of "/modules-state". 224 3. YANG Model 226 file "ietf-netconf-datastores@2017-08-24.yang" 228 module ietf-netconf-datastores { 229 yang-version 1.1; 230 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-datastores"; 231 prefix ncds; 233 import ietf-yang-types { 234 prefix yang; 235 } 236 import ietf-inet-types { 237 prefix inet; 238 } 239 import ietf-datastores { 240 prefix ds; 241 } 242 import ietf-origin { 243 prefix or; 244 } 245 import ietf-netconf { 246 prefix nc; 247 } 248 import ietf-netconf-with-defaults { 249 prefix ncwd; 250 } 252 organization 253 "IETF NETCONF Working Group"; 254 contact 255 "WG Web: 257 WG List: 259 Author: Martin Bjorklund 260 262 Author: Juergen Schoenwaelder 263 265 Author: Phil Shafer 266 268 Author: Kent Watsen 269 271 Author: Rob Wilton 272 "; 273 description 274 "This YANG module defines a set of NETCONF operations for the 275 Network Management Datastore Architecture (NMDA). 277 Copyright (c) 2017 IETF Trust and the persons identified as 278 authors of the code. All rights reserved. 280 Redistribution and use in source and binary forms, with or 281 without modification, is permitted pursuant to, and subject to 282 the license terms contained in, the Simplified BSD License set 283 forth in Section 4.c of the IETF Trust's Legal Provisions 284 Relating to IETF Documents 285 (http://trustee.ietf.org/license-info). 287 This version of this YANG module is part of RFC XXXX 288 (http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself 289 for full legal notices."; 291 revision 2017-08-24 { 292 description 293 "Initial revision."; 294 reference "RFC XXXX: NETCONF Support for NMDA"; 295 } 297 feature origin { 298 description 299 "Indicates that the server supports the 'origin' annotation."; 300 reference "RFC XXXX: Network Management Datastore Architecture"; 301 } 303 typedef datastore { 304 type identityref { 305 base ds:datastore; 306 } 307 description 308 "An NMDA datastore."; 309 reference "RFC XXXX: Network Management Datastore Architecture"; 310 } 312 rpc get-data { 313 description 314 "Retrieve data from an NMDA datastore."; 315 input { 316 leaf source { 317 type ncds:datastore; 318 mandatory true; 319 description 320 "Datastore from which to retrieve data."; 321 } 323 choice filter-spec { 324 description 325 "The content filter specification for this request."; 327 anydata subtree-filter { 328 description 329 "This parameter identifies the portions of the 330 target datastore to retrieve."; 331 reference "RFC 6241, Section 6."; 333 } 334 leaf xpath-filter { 335 if-feature nc:xpath; 336 type yang:xpath1.0; 337 description 338 "This parameter contains an XPath expression 339 identifying the portions of the target 340 datastore to retrieve."; 341 } 342 } 344 container where { 345 description 346 "Filter content with the specified criteria. All given 347 criteria are logically AND:ed."; 349 leaf config { 350 type boolean; 351 description 352 "Filter for nodes with the given value for their 353 'config' property."; 354 } 355 leaf origin { 356 if-feature origin; 357 type identityref { 358 base or:origin; 359 } 360 description 361 "Filter based on 'origin' annotation. A node matches the 362 filter if its 'origin' annotation is derived from or 363 equal to the given filter value."; 364 } 365 } 367 leaf with-origin { 368 when 'derived-from-or-self(../source, "or:operational")'; 369 if-feature origin; 370 type boolean; 371 default false; 372 description 373 "If this parameter is 'true', the server will return 374 the 'origin' annotation for the nodes that has one."; 375 } 377 uses ncwd:with-defaults-parameters; 378 } 380 output { 381 anydata data { 382 description 383 "Copy of the source datastore subset which matched 384 the filter criteria (if any). An empty data 385 container indicates that the request did not 386 produce any results."; 387 } 388 } 389 } 391 rpc edit-data { 392 description 393 "Edit data in an NMDA datastore."; 394 input { 395 leaf target { 396 type ncds:datastore; 397 description 398 "Datastore which data affects."; 399 } 400 leaf default-operation { 401 type enumeration { 402 enum "merge" { 403 description 404 "The default operation is merge."; 405 } 406 enum "replace" { 407 description 408 "The default operation is replace."; 409 } 410 enum "none" { 411 description 412 "There is no default operation."; 413 } 414 } 415 default "merge"; 416 description 417 "The default operation to use."; 418 } 419 choice edit-content { 420 mandatory true; 421 description 422 "The content for the edit operation."; 424 anydata config { 425 description 426 "Inline Config content."; 427 } 428 leaf url { 429 if-feature nc:url; 430 type inet:uri; 431 description 432 "URL based config content."; 433 } 434 } 435 } 436 } 438 /* 439 * Augment the lock and unlock operations with a 440 * "datastore" parameter. 441 */ 443 augment "/nc:lock/nc:input/nc:target/nc:config-target" { 444 description 445 "Add NMDA Datastore as target."; 446 leaf datastore { 447 type ncds:datastore; 448 description 449 "Datastore to lock."; 450 } 451 } 452 augment "/nc:unlock/nc:input/nc:target/nc:config-target" { 453 description 454 "Add NMDA Datastore as target."; 455 leaf datastore { 456 type ncds:datastore; 457 description 458 "Datastore to unlock."; 459 } 460 } 462 /* 463 * Augment the validate operation with a 464 * "datastore" parameter. 465 */ 467 augment "/nc:validate/nc:input/nc:source/nc:config-source" { 468 description 469 "Add NMDA Datastore as source."; 470 leaf datastore { 471 type ncds:datastore; 472 description 473 "Datastore to validate."; 474 } 475 } 476 } 477 479 4. IANA Considerations 481 This document registers one capability identifier URN from the 482 "Network Configuration Protocol (NETCONF) Capability URNs" registry: 484 Index Capability Identifier 485 ------------- --------------------------------------------------- 486 :yang-library urn:ietf:params:netconf:capability:yang-library:1.1 488 This document registers a URI in the "IETF XML Registry" [RFC3688]. 489 Following the format in RFC 3688, the following registration has been 490 made. 492 URI: urn:ietf:params:xml:ns:yang:ietf-netconf-datastores 494 Registrant Contact: The IESG. 496 XML: N/A, the requested URI is an XML namespace. 498 This document registers a YANG module in the "YANG Module Names" 499 registry [RFC6020]. 501 name: ietf-netconf-datastores 502 namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-datastores 503 prefix: ncds 504 reference: RFC XXXX 506 5. Security Considerations 508 This document has no security considerations. 510 6. Informative References 512 [I-D.ietf-netmod-revised-datastores] 513 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 514 and R. Wilton, "Network Management Datastore 515 Architecture", draft-ietf-netmod-revised-datastores-04 516 (work in progress), August 2017. 518 [I-D.nmdsdt-netconf-rfc7895bis] 519 Bierman, A., Bjorklund, M., and K. Watsen, "YANG Library", 520 draft-nmdsdt-netconf-rfc7895bis-01 (work in progress), 521 July 2017. 523 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 524 Requirement Levels", BCP 14, RFC 2119, 525 DOI 10.17487/RFC2119, March 1997, . 528 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 529 and A. Bierman, Ed., "Network Configuration Protocol 530 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 531 . 533 [RFC6243] Bierman, A. and B. Lengyel, "With-defaults Capability for 534 NETCONF", RFC 6243, DOI 10.17487/RFC6243, June 2011, 535 . 537 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 538 RFC 7950, DOI 10.17487/RFC7950, August 2016, 539 . 541 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 542 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 543 May 2017, . 545 Appendix A. Examples 547 Authors' Addresses 549 Martin Bjorklund 550 Tail-f Systems 552 Email: mbj@tail-f.com 554 Juergen Schoenwaelder 555 Jacobs University 557 Email: j.schoenwaelder@jacobs-university.de 559 Phil Shafer 560 Juniper Networks 562 Email: phil@juniper.net 564 Kent Watsen 565 Juniper Networks 567 Email: kwatsen@juniper.net 568 Robert Wilton 569 Cisco Systems 571 Email: rwilton@cisco.com