idnits 2.17.00 (12 Aug 2021) /tmp/idnits22300/draft-ietf-netconf-nmda-netconf-08.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 directly say this. It does mention RFC7950 though, so this could be OK. -- The draft header indicates that this document updates RFC6241, but the abstract doesn't seem to directly say this. It does mention RFC6241 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 17, 2018) is 1305 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) == Outdated reference: draft-ietf-netconf-rfc7895bis has been published as RFC 8525 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: 6241, 7950 (if approved) J. Schoenwaelder 5 Intended status: Standards Track Jacobs University 6 Expires: April 20, 2019 P. Shafer 7 K. Watsen 8 Juniper Networks 9 R. Wilton 10 Cisco Systems 11 October 17, 2018 13 NETCONF Extensions to Support the Network Management Datastore 14 Architecture 15 draft-ietf-netconf-nmda-netconf-08 17 Abstract 19 This document extends the NETCONF protocol defined in RFC 6241 in 20 order to support the Network Management Datastore Architecture 21 defined in RFC 8342. 23 This document updates both RFC 6241 and RFC 7950. The update to RFC 24 6241 adds new operations and , and augments 25 existing operations , , and . The update to 26 RFC 7950 requires the usage of I-D.ietf-netconf-rfc7895bis by NETCONF 27 servers implementing the Network Management Datastore Architecture. 29 RFC Ed.: Please replace "I-D.ietf-netconf-rfc7895bis" above with its 30 final RFC assignment and remove this note. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 20, 2019. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Datastore and YANG Library Requirements . . . . . . . . . . . 3 70 3. NETCONF Extensions . . . . . . . . . . . . . . . . . . . . . 4 71 3.1. New NETCONF Operations . . . . . . . . . . . . . . . . . 4 72 3.1.1. The Operation . . . . . . . . . . . . . . 4 73 3.1.2. The Operation . . . . . . . . . . . . . . 8 74 3.2. Augmentations to NETCONF Operations . . . . . . . . . . . 10 75 4. NETCONF Datastores YANG Module . . . . . . . . . . . . . . . 10 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 20 80 7.2. Informative References . . . . . . . . . . . . . . . . . 21 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 83 1. Introduction 85 This document extends the NETCONF protocol defined in [RFC6241] in 86 order to support the Network Management Datastore Architecture (NMDA) 87 defined in [RFC8342]. 89 This document updates [RFC6241] in order to enable NETCONF clients to 90 interact with all the datastores supported by a server implementing 91 the NMDA. The update both adds new operations and 92 , and augments existing operations , , and 93 . 95 This document also updates [RFC7950] in order to enable NETCONF 96 clients to both discover which datastores are supported by the 97 NETCONF server, as well as determine which modules are supported in 98 each datastore. The update requires NETCONF servers implementing the 99 NMDA to support [I-D.ietf-netconf-rfc7895bis]. 101 1.1. Terminology 103 This document uses the terminology defined by the NMDA [RFC8342]. 105 The following term is defined in [I-D.ietf-netconf-rfc7895bis]: 107 o YANG library content identifier 109 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described in BCP 112 14, [RFC2119] [RFC8174] when, and only when, they appear in all 113 capitals, as shown here. 115 1.2. Tree Diagrams 117 Tree diagrams used in this document follow the notation defined in 118 [RFC8340]. 120 2. Datastore and YANG Library Requirements 122 RFC Ed.: Update 201X-XX-XX below with correct date. 124 An NMDA-compliant NETCONF server MUST implement the module 125 "ietf-netconf-nmda" defined in this document, MUST support the 126 operational state datastore, and it MUST implement at least revision 127 201X-XX-XX of the "ietf-yang-library" module defined in 128 [I-D.ietf-netconf-rfc7895bis]. 130 A NETCONF client can discover which datastores and YANG modules the 131 server supports by reading the YANG library information from the 132 operational state datastore. 134 The server MUST advertise the following capability in the 135 message (line breaks and whitespaces are used for formatting reasons 136 only): 138 urn:ietf:params:netconf:capability:yang-library:1.1? 139 revision=&content-id= 141 The parameter "revision" has the same value as the revision date of 142 the "ietf-yang-library" module implemented by the server. This 143 parameter MUST be present. 145 The parameter "content-id" contains the YANG library content 146 identifier [I-D.ietf-netconf-rfc7895bis]. This parameter MUST be 147 present. 149 With this mechanism, a client can cache the supported datastores and 150 YANG modules for a server and only update the cache if the 151 "content-id" value in the message changes. 153 This document updates [RFC7950], Section 5.6.4, to allow servers to 154 advertise the capability :yang-library:1.1 instead of :yang- 155 library:1.0, and to implement the subtree "/yang-library" 156 [I-D.ietf-netconf-rfc7895bis] instead of "/modules-state". 158 3. NETCONF Extensions 160 This section describes the NETCONF extensions needed to support the 161 NMDA. These changes are defined in a new YANG ([RFC7950]) module 162 "ietf-netconf-nmda". 164 These changes include the use of source and target parameters based 165 on the "datastore" identity defined in the "ietf-datastores" module 166 [RFC8342]. The use of identities allows future expansion in a way 167 that the choice-based strategy from the original operations (e.g., 168 , ) does not. 170 3.1. New NETCONF Operations 172 Two new operations and are defined in this 173 document in order to support the NMDA. These operations are similar 174 to the and operations but they can work on 175 an extensible set of datastores. 177 3.1.1. The Operation 179 The operation retrieves data from a specific NMDA 180 datastore. This operation is similar to NETCONF's 181 operation defined in [RFC6241], but it adds the flexibility to select 182 the source datastore. 184 +---x get-data 185 +---w input 186 | +---w datastore ds:datastore-ref 187 | +---w (filter-spec)? 188 | | +--:(subtree-filter) 189 | | | +---w subtree-filter? 190 | | +--:(xpath-filter) 191 | | +---w xpath-filter? yang:xpath1.0 {nc:xpath}? 192 | +---w config-filter? boolean 193 | +---w (origin-filters)? {origin}? 194 | | +--:(origin-filter) 195 | | | +---w origin-filter* or:origin-ref 196 | | +--:(negated-origin-filter) 197 | | +---w negated-origin-filter* or:origin-ref 198 | +---w max-depth? union 199 | +---w with-origin? empty {origin}? 200 | +---w with-defaults? with-defaults-mode 201 +--ro output 202 +--ro data? 204 The "datastore" parameter indicates the datastore which is the source 205 of the data to be retrieved. This is a datastore identity. 207 The operation accepts a content filter parameter, similar 208 to the "filter" parameter of , but using explicit nodes 209 for subtree filtering ("subtree-filter") and XPath filtering 210 ("xpath-filter"). 212 The "config-filter" parameter can be used to retrieve only "config 213 true" or "config false" nodes. 215 The "origin-filter" parameter, which can be present multiple times, 216 selects nodes equal to or derived from any of the given values. The 217 "negated-origin-filter", which can be present multiple times, selects 218 nodes that do are not equal or derived from any of the given values. 219 The "origin-filter" and "negated-origin-filter" parameters cannot be 220 used together. 222 The "max-depth" parameter can be used by the client to limit the 223 number of sub-tree levels that are returned in the reply. 225 3.1.1.1. Origin Metadata Attribute 227 The operation defines a parameter named "with-origin", 228 which if present, requests that the server includes "origin" metadata 229 annotations in its response, as detailed in the NMDA. This parameter 230 is only valid for the operational state datastore and any datastores 231 with identities derived from the "operational" identity. Otherwise, 232 if an invalid datastore is specified then an error is returned, as 233 specified in "ietf-netconf-nmda" (see Section 4). Note that "origin" 234 metadata annotations are not included in a response unless a client 235 explicitly requests them. 237 Data in the operational state datastore can come from multiple 238 sources. The server should return the most accurate value for the 239 "origin" metadata annotation as possible, indicating the source of 240 the operational value, as specified in Section 5.3.4 of [RFC8342]. 242 When encoding the origin metadata annotation for a hierarchy of 243 returned nodes, the annotation may be omitted for a child node when 244 the value matches that of the parent node, as described in the 245 "ietf-origin" YANG module [RFC8342]. 247 The "with-origin" parameter is OPTIONAL to support. It is identified 248 with the feature "origin". 250 3.1.1.2. With-defaults interactions 252 If the "with-defaults" capability is supported by the server, then 253 the "with-defaults" parameter, defined in [RFC6243], is supported for 254 operations that target conventional configuration 255 datastores. 257 The "with-defaults" parameter is OPTIONAL to support for 258 operations that target . The associated capability to 259 indicate a server's support is identified with the URI: 261 urn:ietf:params:netconf:capability:with-operational-defaults:1.0 263 If the "with-defaults" parameter is supported for 264 operations on , then all retrieval modes specified in 265 either the 'basic-mode' or 'also-supported' parameters of the 266 "with-defaults" capability are permitted. The behavior of the 267 "with-defaults" parameter for is defined as below: 269 o If no "with-defaults" parameter is specified, or if it is set to 270 "explicit", "report-all", or "report-all-tagged", then the "in 271 use" values, as defined in [RFC8342] section 5.3, are returned 272 from the operational state datastore, even if a node happens to 273 have a default statement in the YANG module, and this default 274 value is being used by the server. If the "with-defaults" 275 parameter is set to "report-all-tagged", any values that match the 276 schema default are tagged with additional metadata, as described 277 in [RFC6243] section 3.4. 279 o If the "with-defaults" parameter is set to "trim", all "in use" 280 values are returned, except that the output is filtered to exclude 281 any values that match the default defined in the YANG schema. 283 Support for "with-defaults" in operations on any datastore 284 not defined in [RFC8342] should be defined by the specification for 285 the datastore. 287 3.1.1.3. Example: Retrieving an entire subtree from 289 The following example shows the version of the 290 example shown in Section 7.1 of [RFC6241], which selects 291 the entire "/users" subtree: 293 295 297 ds:running 298 299 300 301 302 303 304 306 308 309 310 311 312 root 313 superuser 314 Charlie Root 315 316 1 317 1 318 319 320 321 322 323 324 326 3.1.1.4. Example: Retrieving a filtered subtree from 328 The following example shows how the "origin-filter" can be used to 329 retrieve nodes from . The example uses the fictional 330 data model defined in Appendix C of [RFC8342]. 332 334 337 ds:operational 338 339 340 341 or:intended 342 or:system 343 344 345 347 349 350 353 354 2001:db8::2:3 355 60794 356 established 357 358 359 360 362 3.1.2. The Operation 364 The operation changes the contents of a writable 365 datastore, similar to the operation defined in 366 [RFC6241], but with additional flexibility in naming the target 367 datastore. If an operation is invoked on a non-writable 368 datastore, then an error is returned, as specified in 369 "ietf-netconf-nmda" (see Section 4). 371 +---x edit-data 372 +---w input 373 +---w datastore ds:datastore-ref 374 +---w default-operation? enumeration 375 +---w (edit-content) 376 +--:(config) 377 | +---w config? 378 +--:(url) 379 +---w url? inet:uri {nc:url}? 381 The "datastore" parameter is a datastore identity that indicates the 382 desired target datastore where changes should be made. 384 The "default-operation" parameter selects the default operation to 385 use. It is a copy of the "default-operation" parameter of the 386 operation. 388 The "edit-content" parameter specifies the content for the edit 389 operation. It mirrors the "edit-content" choice of the 390 operation. Note, however, that the "config" element in the 391 "edit-content" choice of uses "anydata" (introduced in 392 YANG 1.1) while the "config" element in the "edit-content" choice of 393 used "anyxml". 395 The operation does not support the "error-option" and the 396 "test-option" parameters that were part of the 397 operation. The error behaviour of corresponds to the 398 "error-option" "rollback-on-error". 400 If the "with-defaults" capability is supported by the server, the 401 semantics of editing modes is the same as for , as 402 described in section 4.5.2 of [RFC6243]. 404 Semantics for "with-defaults" in operations on any non 405 conventional configuration datastores should be defined by the 406 specification for the datastore. 408 3.1.2.1. Example: Setting a leaf of an interface in 410 The following example shows the version of the first 411 example in Section 7.2 of [RFC6241], setting the MTU to 412 1500 on an interface named "Ethernet0/0" in the running configuration 413 datastore. 415 417 419 ds:running 420 421 422 423 Ethernet0/0 424 1500 425 426 427 428 429 431 433 434 436 The other examples shown in Section 7.2 can be 437 translated to examples in a similar way. 439 3.2. Augmentations to NETCONF Operations 441 Several of the operations defined in the base NETCONF YANG module 442 "ietf-netconf" [RFC6241] may be used with new datastores. Hence, the 443 , , and operations are augmented with a new 444 "datastore" leaf that can select the desired datastore. If a , 445 , or operation is not supported on a particular 446 datastore then an error is returned, as specified in 447 "ietf-netconf-nmda" (see Section 4). 449 4. NETCONF Datastores YANG Module 451 This module imports definitions from [RFC6991], [RFC6241], [RFC6243], 452 and [RFC8342]. 454 RFC Ed.: update the date below with the date of RFC publication and 455 remove this note. 457 file "ietf-netconf-nmda@2018-10-09" 459 module ietf-netconf-nmda { 460 yang-version 1.1; 461 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"; 462 prefix ncds; 464 import ietf-yang-types { 465 prefix yang; 466 reference "RFC 6991: Common YANG Data Types."; 467 } 468 import ietf-inet-types { 469 prefix inet; 470 reference "RFC 6991: Common YANG Data Types."; 471 } 472 import ietf-datastores { 473 prefix ds; 474 reference "RFC 8342: Network Management Datastore Architecture."; 475 } 476 import ietf-origin { 477 prefix or; 478 reference "RFC 8342: Network Management Datastore Architecture."; 479 } 480 import ietf-netconf { 481 prefix nc; 482 reference "RFC 6241: Network Configuration Protocol (NETCONF)"; 483 } 484 import ietf-netconf-with-defaults { 485 prefix ncwd; 486 reference "RFC 6243: With-defaults Capability for NETCONF."; 487 } 489 organization 490 "IETF NETCONF Working Group"; 491 contact 492 "WG Web: 494 WG List: 496 Author: Martin Bjorklund 497 499 Author: Juergen Schoenwaelder 500 502 Author: Phil Shafer 503 505 Author: Kent Watsen 506 508 Author: Rob Wilton 509 "; 510 description 511 "This YANG module defines a set of NETCONF operations to support 512 the Network Management Datastore Architecture (NMDA). 514 Copyright (c) 2018 IETF Trust and the persons identified as 515 authors of the code. All rights reserved. 517 Redistribution and use in source and binary forms, with or 518 without modification, is permitted pursuant to, and subject to 519 the license terms contained in, the Simplified BSD License set 520 forth in Section 4.c of the IETF Trust's Legal Provisions 521 Relating to IETF Documents 522 (http://trustee.ietf.org/license-info). 524 This version of this YANG module is part of RFC XXXX 525 (http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself 526 for full legal notices."; 528 // RFC Ed.: update the date below with the date of RFC publication 529 // and remove this note. 530 // RFC Ed.: replace XXXX with actual RFC number and remove this 531 // note. 532 revision 2018-10-09 { 533 description 534 "Initial revision."; 535 reference 536 "RFC XXXX: NETCONF Extensions to Support the Network Management 537 Datastore Architecture"; 538 } 540 feature origin { 541 description 542 "Indicates that the server supports the 'origin' annotation."; 543 reference 544 "RFC 8342: Network Management Datastore Architecture"; 545 } 547 feature with-defaults { 548 description 549 "NETCONF :with-defaults capability; If the server advertises 550 the :with-defaults capability for a session, then this 551 feature must also be enabled for that session. Otherwise, 552 this feature must not be enabled."; 553 reference 554 "RFC 6243: With-defaults Capability for NETCONF, section 4; and 555 RFC XXXX: NETCONF Extensions to Support the Network Management 556 Datastore Architecture, section 3.1.1.1."; 558 } 560 rpc get-data { 561 description 562 "Retrieve data from an NMDA datastore. The content returned 563 by get-data must satisfy all filters, i.e., the filter 564 criteria are logically ANDed. 566 Any ancestor nodes (including list keys) of nodes selected by 567 the filters are included in the response. 569 The 'with-origin' parameter is only valid for an operational 570 datastore. If 'with-origin' is used with an invalid datastore, 571 then the server MUST return an element with an 572 value of 'invalid-value'. 574 The 'with-defaults' parameter only applies to the operational 575 datastore if the NETCONF :with-defaults and 576 :with-operational-defaults capabilities are both advertised. 577 If the 'with-defaults' parameter is present in a request for 578 which it is not supported, then the server MUST return an 579 element with an value of 580 'invalid-value'."; 581 input { 582 leaf datastore { 583 type ds:datastore-ref; 584 mandatory true; 585 description 586 "Datastore from which to retrieve data. 588 If the datastore is not supported by the server, then the 589 server MUST return an element with an 590 value of 'invalid-value'."; 591 } 593 choice filter-spec { 594 description 595 "The content filter specification for this request."; 597 anydata subtree-filter { 598 description 599 "This parameter identifies the portions of the 600 target datastore to retrieve."; 601 reference 602 "RFC 6241: Network Configuration Protocol, Section 6."; 603 } 604 leaf xpath-filter { 605 if-feature nc:xpath; 606 type yang:xpath1.0; 607 description 608 "This parameter contains an XPath expression identifying 609 the portions of the target datastore to retrieve. 611 If the expression returns a node-set, all nodes in the 612 node-set are selected by the filter. Otherwise, if the 613 expression does not return a node-set, then the get-data 614 operation fails. 616 The expression is evaluated in the following XPath 617 context: 619 o The set of namespace declarations are those in 620 scope on the 'xpath-filter' leaf element. 622 o The set of variable bindings is empty. 624 o The function library is the core function library, 625 and the XPath functions defined in section 10 in 626 RFC 7950. 628 o The context node is the root node of the target 629 datastore."; 630 } 631 } 633 leaf config-filter { 634 type boolean; 635 description 636 "Filter for nodes with the given value for their 637 'config' property. If this leaf is not present, all 638 nodes are selected. 640 For example, when this leaf is set to 'true', only 'config 641 true' nodes are selected."; 642 } 643 choice origin-filters { 644 when 'derived-from-or-self(datastore, "ds:operational")'; 645 if-feature origin; 646 description 647 "Filters based on the 'origin' annotation."; 649 leaf-list origin-filter { 650 type or:origin-ref; 651 description 652 "Filter based on the 'origin' annotation. A node matches 653 the filter if its 'origin' annotation is derived from or 654 equal to any of the given filter values."; 655 } 656 leaf-list negated-origin-filter { 657 type or:origin-ref; 658 description 659 "Filter based on the 'origin' annotation. A node matches 660 the filter if its 'origin' annotation is not derived 661 from and not equal to any of the given filter values."; 662 } 663 } 665 leaf max-depth { 666 type union { 667 type uint16 { 668 range "1..65535"; 669 } 670 type enumeration { 671 enum "unbounded" { 672 description 673 "All descendant nodes are included."; 674 } 675 } 676 } 677 default "unbounded"; 678 description 679 "For each node selected by the filters, this parameter 680 selects how many conceptual sub-tree levels should be 681 returned in the reply. If the depth is 1, the reply 682 includes just the selected nodes but no children. If the 683 depth is 'unbounded', all descendant nodes are included."; 684 } 686 leaf with-origin { 687 when 'derived-from-or-self(../datastore, "ds:operational")'; 688 if-feature origin; 689 type empty; 690 description 691 "If this parameter is present, the server will return 692 the 'origin' annotation for the nodes that has one."; 693 } 695 uses ncwd:with-defaults-parameters { 696 if-feature with-defaults; 697 } 698 } 700 output { 701 anydata data { 702 description 703 "Copy of the source datastore subset which matched 704 the filter criteria (if any). An empty data 705 container indicates that the request did not 706 produce any results."; 707 } 708 } 709 } 711 rpc edit-data { 712 description 713 "Edit data in an NMDA datastore. 715 If an error condition occurs such that an error severity 716 element is generated, the server will stop 717 processing the operation and restore the 718 specified configuration to its complete state at 719 the start of this operation."; 720 input { 721 leaf datastore { 722 type ds:datastore-ref; 723 mandatory true; 724 description 725 "Datastore which is the target of the edit-data operation. 727 If the target datastore is not writable, or is not 728 supported by the server, then the server MUST return an 729 element with an value of 730 'invalid-value'."; 731 } 732 leaf default-operation { 733 type enumeration { 734 enum "merge" { 735 description 736 "The default operation is merge."; 737 } 738 enum "replace" { 739 description 740 "The default operation is replace."; 741 } 742 enum "none" { 743 description 744 "There is no default operation."; 745 } 746 } 747 default "merge"; 748 description 749 "The default operation to use."; 750 } 751 choice edit-content { 752 mandatory true; 753 description 754 "The content for the edit operation."; 756 anydata config { 757 description 758 "Inline config content."; 759 } 760 leaf url { 761 if-feature nc:url; 762 type inet:uri; 763 description 764 "URL based config content."; 765 } 766 } 767 } 768 } 770 /* 771 * Augment the lock and unlock operations with a 772 * "datastore" parameter. 773 */ 775 augment "/nc:lock/nc:input/nc:target/nc:config-target" { 776 description 777 "Add NMDA Datastore as target."; 778 leaf datastore { 779 type ds:datastore-ref; 780 description 781 "Datastore to lock. 783 The lock operation is only supported on writable datastores. 785 If the lock operation is not supported by the server on the 786 specified target datastore, then the server MUST return an 787 element with an value of 788 'invalid-value'."; 789 } 790 } 791 augment "/nc:unlock/nc:input/nc:target/nc:config-target" { 792 description 793 "Add NMDA Datastore as target."; 794 leaf datastore { 795 type ds:datastore-ref; 796 description 797 "Datastore to unlock. 799 The unlock operation is only supported on writable 800 datastores. 802 If the unlock operation is not supported by the server on 803 the specified target datastore, then the server MUST return 804 an element with an value of 805 'invalid-value'."; 806 } 807 } 809 /* 810 * Augment the validate operation with a 811 * "datastore" parameter. 812 */ 814 augment "/nc:validate/nc:input/nc:source/nc:config-source" { 815 description 816 "Add NMDA Datastore as source."; 817 leaf datastore { 818 type ds:datastore-ref; 819 description 820 "Datastore to validate. 822 The validate operation is supported only on configuration 823 datastores. 825 If the validate operation is not supported by the server on 826 the specified target datastore, then the server MUST return 827 an element with an value of 828 'invalid-value'."; 830 } 831 } 832 } 834 836 5. IANA Considerations 838 This document registers two capability identifier URNs in the 839 "Network Configuration Protocol (NETCONF) Capability URNs" registry: 841 Index 842 Capability Identifier 843 --------------------- 844 :yang-library:1.1 845 urn:ietf:params:netconf:capability:yang-library:1.1 847 :with-operational-defaults 848 urn:ietf:params:netconf:capability:with-operational-defaults:1.0 850 This document registers a URI in the "IETF XML Registry" [RFC3688]. 851 Following the format in RFC 3688, the following registration has been 852 made. 854 URI: urn:ietf:params:xml:ns:yang:ietf-netconf-nmda 856 Registrant Contact: The IESG. 858 XML: N/A, the requested URI is an XML namespace. 860 This document registers a YANG module in the "YANG Module Names" 861 registry [RFC6020]. 863 name: ietf-netconf-nmda 864 namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-nmda 865 prefix: ncds 866 reference: RFC XXXX 868 6. Security Considerations 870 The YANG module defined in this document extends the base operations 871 of the NETCONF [RFC6241] protocol. The lowest NETCONF layer is the 872 secure transport layer and the mandatory-to-implement secure 873 transport is Secure Shell (SSH) [RFC6242]. 875 The network configuration access control model [RFC8341] provides the 876 means to restrict access for particular NETCONF users to a 877 preconfigured subset of all available NETCONF protocol operations and 878 content. 880 The security considerations for the base NETCONF protocol operations 881 (see Section 9 of [RFC6241]) apply to the new NETCONF and 882 operations defined in this document. 884 7. References 885 7.1. Normative References 887 [I-D.ietf-netconf-rfc7895bis] 888 Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 889 and R. Wilton, "YANG Library", draft-ietf-netconf- 890 rfc7895bis-06 (work in progress), April 2018. 892 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 893 Requirement Levels", BCP 14, RFC 2119, 894 DOI 10.17487/RFC2119, March 1997, . 897 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 898 DOI 10.17487/RFC3688, January 2004, . 901 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 902 the Network Configuration Protocol (NETCONF)", RFC 6020, 903 DOI 10.17487/RFC6020, October 2010, . 906 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 907 and A. Bierman, Ed., "Network Configuration Protocol 908 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 909 . 911 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 912 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 913 . 915 [RFC6243] Bierman, A. and B. Lengyel, "With-defaults Capability for 916 NETCONF", RFC 6243, DOI 10.17487/RFC6243, June 2011, 917 . 919 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 920 RFC 6991, DOI 10.17487/RFC6991, July 2013, 921 . 923 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 924 RFC 7950, DOI 10.17487/RFC7950, August 2016, 925 . 927 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 928 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 929 May 2017, . 931 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 932 Access Control Model", STD 91, RFC 8341, 933 DOI 10.17487/RFC8341, March 2018, . 936 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 937 and R. Wilton, "Network Management Datastore Architecture 938 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 939 . 941 7.2. Informative References 943 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 944 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 945 . 947 Authors' Addresses 949 Martin Bjorklund 950 Tail-f Systems 952 Email: mbj@tail-f.com 954 Juergen Schoenwaelder 955 Jacobs University 957 Email: j.schoenwaelder@jacobs-university.de 959 Phil Shafer 960 Juniper Networks 962 Email: phil@juniper.net 964 Kent Watsen 965 Juniper Networks 967 Email: kwatsen@juniper.net 969 Robert Wilton 970 Cisco Systems 972 Email: rwilton@cisco.com