idnits 2.17.1 draft-ietf-netconf-nmda-netconf-04.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 (March 1, 2018) is 2241 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) -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-netconf-rfc6536bis' == Outdated reference: A later version (-07) exists of draft-ietf-netconf-rfc7895bis-05 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 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: September 2, 2018 P. Shafer 7 K. Watsen 8 Juniper Networks 9 R. Wilton 10 Cisco Systems 11 March 1, 2018 13 NETCONF Extensions to Support the Network Management Datastore 14 Architecture 15 draft-ietf-netconf-nmda-netconf-04 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 I-D.ietf-netmod-revised-datastores. 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 REF Editor: please replace "I-D.ietf-netmod-revised-datastores" and 30 "I-D.ietf-netconf-rfc7895bis" above with their final RFC assignments. 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 September 2, 2018. 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 . . . . . . . . . . . 9 75 4. NETCONF Datastores YANG Module . . . . . . . . . . . . . . . 9 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 19 80 7.2. Informative References . . . . . . . . . . . . . . . . . 20 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 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 [I-D.ietf-netmod-revised-datastores]. 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 104 [I-D.ietf-netmod-revised-datastores]. 106 The following term is defined in [I-D.ietf-netconf-rfc7895bis]: 108 o YANG library checksum 110 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in BCP 113 14, [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 1.2. Tree Diagrams 118 Tree diagrams used in this document follow the notation defined in 119 [I-D.ietf-netmod-yang-tree-diagrams]. 121 2. Datastore and YANG Library Requirements 123 RFC Ed.: Update 201X-XX-XX below with correct date. 125 An NMDA-compliant NETCONF server MUST support the operational state 126 datastore and it MUST implement at least revision 201X-XX-XX of the 127 "ietf-yang-library" module defined in [I-D.ietf-netconf-rfc7895bis]. 129 The server MUST advertise the following capability in the 130 message (line breaks and whitespaces are used for formatting reasons 131 only): 133 urn:ietf:params:netconf:capability:yang-library:1.1? 134 revision=&checksum= 136 The parameter "revision" has the same value as the revision date of 137 the "ietf-yang-library" module implemented by the server. This 138 parameter MUST be present. 140 The parameter "checksum" contains the YANG library checksum 141 [I-D.ietf-netconf-rfc7895bis]. This parameter MUST be present. 143 With this mechanism, a client can cache the supported modules for a 144 server and only update the cache if the "checksum" value in the 145 message changes. 147 This document updates [RFC7950], Section 5.6.4, to allow servers to 148 advertise the capability :yang-library:1.1 instead of :yang- 149 library:1.0, and to implement the subtree "/yang-library" 150 [I-D.ietf-netconf-rfc7895bis] instead of "/modules-state". 152 3. NETCONF Extensions 154 This section describes the NETCONF extensions needed to support the 155 NMDA. These changes are defined in a new YANG ([RFC7950]) module 156 "ietf-netconf-nmda". 158 These changes include the use of source and target parameters based 159 on the "datastore" identity defined in the "ietf-datastores" module 160 [I-D.ietf-netmod-revised-datastores]. The use of identities allows 161 future expansion in a way that the choice-based strategy from the 162 original operations (e.g., , ) does not. 164 3.1. New NETCONF Operations 166 Two new operations and are defined in this 167 document in order to support the NMDA. These operations are similar 168 to the and operations but they can work on 169 an extensible set of datastores. 171 3.1.1. The Operation 173 The operation retrieves data from a specific NMDA 174 datastore. This operation is similar to NETCONF's 175 operation defined in [RFC6241], but it adds the flexibility to select 176 the source datastore. 178 +---x get-data 179 +---w input 180 | +---w datastore ds:datastore-ref 181 | +--(filter-spec)? 182 | | +--:(subtree-filter) 183 | | | +---w subtree-filter? 184 | | +--:(xpath-filter) 185 | | +---w xpath-filter? yang:xpath1.0 {nc:xpath}? 186 | +---w config-filter? boolean 187 | +--(origin-filters)? {origin}? 188 | | +--:(origin-filter) 189 | | | +---w origin-filter* or:origin-ref 190 | | +--:(negated-origin-filter) 191 | | +---w negated-origin-filter* or:origin-ref 192 | +---w max-depth? union 193 | +---w with-origin? empty {origin}? 194 | +---w with-defaults? with-defaults-mode 195 +--ro output 196 +--ro data? 198 The "datastore" parameter indicates the datastore which is the source 199 of the data to be retrieved. This is a datastore identity. 201 The operation accepts a content filter parameter, similar 202 to the "filter" parameter of , but using explicit nodes 203 for subtree filtering ("subtree-filter") and XPath filtering 204 ("xpath-filter"). 206 The "config-filter" parameter can be used to retrieve only "config 207 true" or "config false" nodes. 209 The "origin-filter" parameter, which can be present multiple times, 210 selects nodes matching any of the given values. The 211 "negated-origin-filter", which can be present multiple times, selects 212 nodes that do not match all given values. The "origin-filter" and 213 "negated-origin-filter" parameters cannot be used together. 215 The "max-depth" parameter can be used by the client to limit the 216 number of sub-tree levels that are returned in the reply. 218 3.1.1.1. With-defaults interactions 220 If the "with-defaults" capability is supported by the server, then 221 the "with-defaults" parameter, defined in [RFC6243], is supported for 222 operations that target conventional configuration 223 datastores. 225 The "with-defaults" parameter is optional to support for 226 operations that target . The associated capability to 227 indicate a server's support is identified with the URI: 229 urn:ietf:params:netconf:capability:with-operational-defaults:1.0 231 If the "with-defaults" parameter is supported for 232 operations on , then all retrieval modes specified in 233 either the 'basic-mode' or 'also-supported' parameters of the 234 "with-defaults" capability are permitted. The behavior of the 235 "with-defaults" parameter for is defined as below: 237 o If no "with-defaults" parameter is specified, or if it is set to 238 "explicit", "report-all", or "report-all-tagged", then the "in 239 use" values, as defined in [I-D.ietf-netmod-revised-datastores] 240 section 5.3, are returned from the operational state datastore, 241 even if a node happens to have a default statement in the YANG 242 module, and this default value is being used by the server. If 243 the "with-defaults" parameter is set to "report-all-tagged", any 244 values that match the schema default are tagged with additional 245 metadata, as described in [RFC6243] section 3.4. 247 o If the "with-defaults" parameter is set to "trim", all "in use" 248 values are returned, except that the output is filtered to exclude 249 any values that match the default defined in the YANG schema. 251 Support for "with-defaults" in operations on any datastore 252 not defined in [I-D.ietf-netmod-revised-datastores] SHOULD be defined 253 by the specification for the datastore. 255 3.1.1.2. Origin Metadata Attribute 257 The operation defines a parameter named "with-origin", 258 which if present, requests that the server includes "origin" metadata 259 annotations in its response, as detailed in the NMDA. This parameter 260 is only valid for the operational state datastore and any datastores 261 with identities derived from the "operational" identity. Otherwise, 262 if an invalid datastore is specified then an error is returned, as 263 specified in "ietf-netconf-nmda" (see Section 4). Note that "origin" 264 metadata annotations are not included in a response unless a client 265 explicitly requests them. 267 Data in the operational state datastore can come from multiple 268 sources. The server should return the most accurate value for the 269 "origin" metadata annotation as possible, indicating the source of 270 the operational value, as specified in Section 5.3.4 of 271 [I-D.ietf-netmod-revised-datastores]. 273 When encoding the origin metadata annotation for a hierarchy of 274 returned nodes, the annotation may be omitted for a child node when 275 the value matches that of the parent node, as described in the 276 "ietf-origin" YANG module [I-D.ietf-netmod-revised-datastores]. 278 The "with-origin" parameter is optional to support. It is identified 279 with the feature "origin". 281 3.1.1.3. Example: Retrieving an entire subtree from 283 The following example shows the version of the 284 example shown in Section 7.1 of [RFC6241]. 286 288 290 ds:running 291 292 293 294 295 296 297 299 301 302 303 304 305 root 306 superuser 307 Charlie Root 308 309 1 310 1 311 312 313 314 315 316 317 319 3.1.2. The Operation 321 The operation changes the contents of a writable 322 datastore, similar to the operation defined in 323 [RFC6241], but with additional flexibility in naming the target 324 datastore. If an operation is invoked on a non-writable 325 datastore, then an error is returned, as specified in 326 "ietf-netconf-nmda" (see Section 4). 328 +---x edit-data 329 +---w input 330 +---w datastore ds:datastore-ref 331 +---w default-operation? enumeration 332 +--(edit-content) 333 +--:(config) 334 | +---w config? 335 +--:(url) 336 +---w url? inet:uri {nc:url}? 338 The "datastore" parameter is a datastore identity that indicates the 339 desired target datastore where changes should be made. 341 The "default-operation" parameter is a copy of the 342 "default-operation" parameter of the operation. 344 The "edit-content" choice mirrors the "edit-content" choice of the 345 operation. Note, however, that the "config" element in 346 the "edit-content" choice of uses "anydata" (introduced 347 in YANG 1.1) while the "config" element in the "edit-content" choice 348 of used "anyxml". 350 The operation does not support the "error-option" and the 351 "test-option" parameters that were part of the 352 operation. The error behaviour of corresponds to the 353 "error-option" "rollback-on-error". 355 If the "with-defaults" capability is supported by the server, the 356 semantics of editing modes is the same as for , as 357 described in section 4.5.2 of [RFC6243]. 359 Semantics for "with-defaults" in operations on any non 360 conventional configuration datastores SHOULD be defined by the 361 specification for the datastore. 363 3.1.2.1. Example: Setting a leaf of an interface in 365 The following example shows the version of the first 366 example in Section 7.2 of [RFC6241], setting the MTU to 367 1500 on an interface named "Ethernet0/0" in the running configuration 368 datastore. 370 372 374 ds:running 375 376 377 378 Ethernet0/0 379 1500 380 381 382 383 384 386 388 389 391 The other examples shown in Section 7.2 can be 392 translated to examples in a similar way. 394 3.2. Augmentations to NETCONF Operations 396 Several of the operations defined in the base NETCONF YANG module 397 "ietf-netconf" [RFC6241] may be used with new datastores. Hence, the 398 , , and operations are augmented with a new 399 "datastore" leaf that can select the desired datastore. If a , 400 , or operation is not supported on a particular 401 datastore then an error is returned, as specified in 402 "ietf-netconf-nmda" (see Section 4). 404 4. NETCONF Datastores YANG Module 406 This module imports definitions from [RFC6991], [RFC6241], [RFC6243], 407 and [I-D.ietf-netmod-revised-datastores]. 409 RFC Ed.: update the date below with the date of RFC publication and 410 remove this note. 412 file "ietf-netconf-nmda@2018-02-28.yang" 414 module ietf-netconf-nmda { 415 yang-version 1.1; 416 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"; 417 prefix ncds; 419 import ietf-yang-types { 420 prefix yang; 421 reference "RFC 6991: Common YANG Data Types."; 422 } 423 import ietf-inet-types { 424 prefix inet; 425 reference "RFC 6991: Common YANG Data Types."; 426 } 427 import ietf-datastores { 428 prefix ds; 429 // RFC Ed.: update the reference below with the actual RFC number 430 reference "RFC XXXX: Network Management Datastore Architecture."; 431 } 432 import ietf-origin { 433 prefix or; 434 // RFC Ed.: update the reference below with the actual RFC number 435 reference "RFC XXXX: Network Management Datastore Architecture."; 436 } 437 import ietf-netconf { 438 prefix nc; 439 reference "RFC 6241: Network Configuration Protocol (NETCONF)"; 440 } 441 import ietf-netconf-with-defaults { 442 prefix ncwd; 443 reference "RFC 6243: With-defaults Capability for NETCONF."; 444 } 446 organization 447 "IETF NETCONF Working Group"; 448 contact 449 "WG Web: 451 WG List: 453 Author: Martin Bjorklund 454 456 Author: Juergen Schoenwaelder 457 459 Author: Phil Shafer 460 462 Author: Kent Watsen 463 465 Author: Rob Wilton 466 "; 467 description 468 "This YANG module defines a set of NETCONF operations to support 469 the Network Management Datastore Architecture (NMDA). 471 Copyright (c) 2018 IETF Trust and the persons identified as 472 authors of the code. All rights reserved. 474 Redistribution and use in source and binary forms, with or 475 without modification, is permitted pursuant to, and subject to 476 the license terms contained in, the Simplified BSD License set 477 forth in Section 4.c of the IETF Trust's Legal Provisions 478 Relating to IETF Documents 479 (http://trustee.ietf.org/license-info). 481 This version of this YANG module is part of RFC XXXX 482 (http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself 483 for full legal notices."; 485 // RFC Ed.: update the date below with the date of RFC publication 486 // and remove this note. 487 // RFC Ed.: replace XXXX with actual RFC number and remove this 488 // note. 489 revision 2018-02-28 { 490 description 491 "Initial revision."; 492 reference 493 "RFC XXXX: NETCONF Extensions to Support the Network Management 494 Datastore Architecture"; 495 } 497 feature origin { 498 description 499 "Indicates that the server supports the 'origin' annotation."; 500 reference 501 "RFC XXXX: Network Management Datastore Architecture"; 502 } 504 feature with-defaults { 505 description 506 "NETCONF :with-defaults capability; If the server advertises 507 the :with-defaults capability for a session, then this 508 feature must also be enabled for that session. Otherwise, 509 this feature must not be enabled."; 510 reference 511 "RFC 6243: With-defaults Capability for NETCONF, section 4; and 512 RFC XXXX: NETCONF Extensions to Support the Network Management 513 Datastore Architecture, section 3.1.1.1."; 514 } 516 rpc get-data { 517 description 518 "Retrieve data from an NMDA datastore. The content returned 519 by get-data must satisfy all filters, i.e., the filter 520 criteria are logically ANDed. 522 The 'with-origin' parameter is only valid for an operational 523 datastore. If 'with-origin' is used with an invalid datastore, 524 then the server MUST return an element with an 525 value of 'invalid-value'. 527 The 'with-defaults' parameter only applies to the operational 528 datastore if the NETCONF :with-defaults and 529 :with-operational-defaults capabilities are both advertised. 530 If the 'with-defaults' parameter is present in a request for 531 which it is not supported, then the server MUST return an 532 element with an value of 533 'invalid-value'."; 534 input { 535 leaf datastore { 536 type ds:datastore-ref; 537 mandatory true; 538 description 539 "Datastore from which to retrieve data. 541 If the datastore is not supported by the server, then the 542 server MUST return an element with an 543 value of 'invalid-value'."; 544 } 546 choice filter-spec { 547 description 548 "The content filter specification for this request."; 550 anydata subtree-filter { 551 description 552 "This parameter identifies the portions of the 553 target datastore to retrieve."; 554 reference 555 "RFC 6241: Network Configuration Protocol, Section 6."; 556 } 557 leaf xpath-filter { 558 if-feature nc:xpath; 559 type yang:xpath1.0; 560 description 561 "This parameter contains an XPath expression identifying 562 the portions of the target datastore to retrieve. 564 If the expression returns a node-set, all nodes in the 565 node-set are selected by the filter. Otherwise, if the 566 expression does not return a node-set, then the get-data 567 operation fails. 569 The expression is evaluated in the following XPath 570 context: 572 o The set of namespace declarations are those in 573 scope on the 'xpath-filter' leaf element. 575 o The set of variable bindings is empty. 577 o The function library is the core function library, 578 and the XPath functions defined in section 10 in 579 RFC 7950. 581 o The context node is the root node of the target 582 datastore."; 583 } 584 } 586 leaf config-filter { 587 type boolean; 588 description 589 "Filter for nodes with the given value for their 590 'config' property."; 591 } 592 choice origin-filters { 593 when 'derived-from-or-self(datastore, "ds:operational")'; 594 if-feature origin; 595 description 596 "Filters based on the 'origin' annotation."; 598 leaf-list origin-filter { 599 type or:origin-ref; 600 description 601 "Filter based on the 'origin' annotation. A node matches 602 the filter if its 'origin' annotation is derived from or 603 equal to any of the given filter values."; 604 } 605 leaf-list negated-origin-filter { 606 type or:origin-ref; 607 description 608 "Filter based on the 'origin' annotation. A node matches 609 the filter if its 'origin' annotation is not derived 610 from and not equal to all of the given filter values."; 611 } 612 } 614 leaf max-depth { 615 type union { 616 type uint16 { 617 range "1..65535"; 618 } 619 type enumeration { 620 enum "unbounded"; 621 } 622 } 623 default "unbounded"; 624 description 625 "For each node selected by the filter, this parameter 626 selects how many conceptual sub-tree levels should be 627 returned in the reply. If the depth is 1, the reply 628 includes just the selected nodes but no children. If the 629 depth is 'unbounded', all descendant nodes are included."; 630 } 632 leaf with-origin { 633 when 'derived-from-or-self(../datastore, "ds:operational")'; 634 if-feature origin; 635 type empty; 636 description 637 "If this parameter is present, the server will return 638 the 'origin' annotation for the nodes that has one."; 639 } 641 uses ncwd:with-defaults-parameters { 642 if-feature with-defaults; 643 } 644 } 646 output { 647 anydata data { 648 description 649 "Copy of the source datastore subset which matched 650 the filter criteria (if any). An empty data 651 container indicates that the request did not 652 produce any results."; 653 } 654 } 655 } 657 rpc edit-data { 658 description 659 "Edit data in an NMDA datastore. 661 If an error condition occurs such that an error severity 662 element is generated, the server will stop 663 processing the operation and restore the 664 specified configuration to its complete state at 665 the start of this operation."; 666 input { 667 leaf datastore { 668 type ds:datastore-ref; 669 mandatory true; 670 description 671 "Datastore which is the target of the edit-data operation. 673 If the target datastore is not writable, or is not 674 supported by the server, then the server MUST return an 675 element with an value of 676 'invalid-value'."; 677 } 678 leaf default-operation { 679 type enumeration { 680 enum "merge" { 681 description 682 "The default operation is merge."; 683 } 684 enum "replace" { 685 description 686 "The default operation is replace."; 687 } 688 enum "none" { 689 description 690 "There is no default operation."; 691 } 692 } 693 default "merge"; 694 description 695 "The default operation to use."; 697 } 698 choice edit-content { 699 mandatory true; 700 description 701 "The content for the edit operation."; 703 anydata config { 704 description 705 "Inline config content."; 706 } 707 leaf url { 708 if-feature nc:url; 709 type inet:uri; 710 description 711 "URL based config content."; 712 } 713 } 714 } 715 } 717 /* 718 * Augment the lock and unlock operations with a 719 * "datastore" parameter. 720 */ 722 augment "/nc:lock/nc:input/nc:target/nc:config-target" { 723 description 724 "Add NMDA Datastore as target."; 725 leaf datastore { 726 type ds:datastore-ref; 727 description 728 "Datastore to lock. 730 The lock operation is only supported on writable datastores. 732 If the lock operation is not supported by the server on the 733 specified target datastore, then the server MUST return an 734 element with an value of 735 'invalid-value'."; 736 } 737 } 738 augment "/nc:unlock/nc:input/nc:target/nc:config-target" { 739 description 740 "Add NMDA Datastore as target."; 741 leaf datastore { 742 type ds:datastore-ref; 743 description 744 "Datastore to unlock. 746 The unlock operation is only supported on writable 747 datastores. 749 If the unlock operation is not supported by the server on 750 the specified target datastore, then the server MUST return 751 an element with an value of 752 'invalid-value'."; 753 } 754 } 756 /* 757 * Augment the validate operation with a 758 * "datastore" parameter. 759 */ 761 augment "/nc:validate/nc:input/nc:source/nc:config-source" { 762 description 763 "Add NMDA Datastore as source."; 764 leaf datastore { 765 type ds:datastore-ref; 766 description 767 "Datastore to validate. 769 The validate operation is supported only on configuration 770 datastores. 772 If the validate operation is not supported by the server on 773 the specified target datastore, then the server MUST return 774 an element with an value of 775 'invalid-value'."; 777 } 778 } 779 } 781 783 5. IANA Considerations 785 This document registers two capability identifier URNs in the 786 "Network Configuration Protocol (NETCONF) Capability URNs" registry: 788 Index 789 Capability Identifier 790 --------------------- 791 :yang-library 792 urn:ietf:params:netconf:capability:yang-library:1.1 794 :with-operational-defaults 795 urn:ietf:params:netconf:capability:with-operational-defaults:1.0 797 This document registers a URI in the "IETF XML Registry" [RFC3688]. 798 Following the format in RFC 3688, the following registration has been 799 made. 801 URI: urn:ietf:params:xml:ns:yang:ietf-netconf-nmda 803 Registrant Contact: The IESG. 805 XML: N/A, the requested URI is an XML namespace. 807 This document registers a YANG module in the "YANG Module Names" 808 registry [RFC6020]. 810 name: ietf-netconf-nmda 811 namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-nmda 812 prefix: ncds 813 reference: RFC XXXX 815 6. Security Considerations 817 The YANG module defined in this document extends the base operations 818 of the NETCONF [RFC6241] protocol. The lowest NETCONF layer is the 819 secure transport layer and the mandatory-to-implement secure 820 transport is Secure Shell (SSH) [RFC6242]. 822 The network configuration access control model 823 [I-D.ietf-netconf-rfc6536bis] provides the means to restrict access 824 for particular NETCONF users to a preconfigured subset of all 825 available NETCONF protocol operations and content. 827 The security considerations for the base NETCONF protocol operations 828 (see Section 9 of [RFC6241]) apply to the new NETCONF and 829 operations defined in this document. 831 7. References 832 7.1. Normative References 834 [I-D.ietf-netconf-rfc6536bis] 835 Bierman, A. and M. Bjorklund, "Network Configuration 836 Access Control Module", draft-ietf-netconf-rfc6536bis-09 837 (work in progress), December 2017. 839 [I-D.ietf-netconf-rfc7895bis] 840 Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 841 and R. Wilton, "YANG Library", draft-ietf-netconf- 842 rfc7895bis-05 (work in progress), February 2018. 844 [I-D.ietf-netmod-revised-datastores] 845 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 846 and R. Wilton, "Network Management Datastore 847 Architecture", draft-ietf-netmod-revised-datastores-10 848 (work in progress), January 2018. 850 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 851 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 852 RFC2119, March 1997, . 855 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 856 DOI 10.17487/RFC3688, January 2004, . 859 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 860 the Network Configuration Protocol (NETCONF)", RFC 6020, 861 DOI 10.17487/RFC6020, October 2010, . 864 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 865 and A. Bierman, Ed., "Network Configuration Protocol 866 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 867 . 869 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 870 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 871 . 873 [RFC6243] Bierman, A. and B. Lengyel, "With-defaults Capability for 874 NETCONF", RFC 6243, DOI 10.17487/RFC6243, June 2011, 875 . 877 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 878 6991, DOI 10.17487/RFC6991, July 2013, . 881 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 882 RFC 7950, DOI 10.17487/RFC7950, August 2016, 883 . 885 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 886 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 887 May 2017, . 889 7.2. Informative References 891 [I-D.ietf-netmod-yang-tree-diagrams] 892 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft- 893 ietf-netmod-yang-tree-diagrams-06 (work in progress), 894 February 2018. 896 Authors' Addresses 898 Martin Bjorklund 899 Tail-f Systems 901 Email: mbj@tail-f.com 903 Juergen Schoenwaelder 904 Jacobs University 906 Email: j.schoenwaelder@jacobs-university.de 908 Phil Shafer 909 Juniper Networks 911 Email: phil@juniper.net 913 Kent Watsen 914 Juniper Networks 916 Email: kwatsen@juniper.net 918 Robert Wilton 919 Cisco Systems 921 Email: rwilton@cisco.com