idnits 2.17.1 draft-ietf-netconf-nmda-netconf-06.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 (May 28, 2018) is 2132 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: A later version (-07) exists of draft-ietf-netconf-rfc7895bis-06 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: November 29, 2018 P. Shafer 7 K. Watsen 8 Juniper Networks 9 R. Wilton 10 Cisco Systems 11 May 28, 2018 13 NETCONF Extensions to Support the Network Management Datastore 14 Architecture 15 draft-ietf-netconf-nmda-netconf-06 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 November 29, 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 [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 checksum 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 support the operational state 125 datastore and it MUST implement at least revision 201X-XX-XX of the 126 "ietf-yang-library" module defined in [I-D.ietf-netconf-rfc7895bis]. 128 A NETCONF client can discover which datastores and YANG modules the 129 server supports by reading the YANG library information from the 130 operational state datastore. 132 The server MUST advertise the following capability in the 133 message (line breaks and whitespaces are used for formatting reasons 134 only): 136 urn:ietf:params:netconf:capability:yang-library:1.1? 137 revision=&checksum= 139 The parameter "revision" has the same value as the revision date of 140 the "ietf-yang-library" module implemented by the server. This 141 parameter MUST be present. 143 The parameter "checksum" contains the YANG library checksum 144 [I-D.ietf-netconf-rfc7895bis]. This parameter MUST be present. 146 With this mechanism, a client can cache the supported datastores and 147 YANG modules for a server and only update the cache if the "checksum" 148 value in the message changes. 150 This document updates [RFC7950], Section 5.6.4, to allow servers to 151 advertise the capability :yang-library:1.1 instead of :yang- 152 library:1.0, and to implement the subtree "/yang-library" 153 [I-D.ietf-netconf-rfc7895bis] instead of "/modules-state". 155 3. NETCONF Extensions 157 This section describes the NETCONF extensions needed to support the 158 NMDA. These changes are defined in a new YANG ([RFC7950]) module 159 "ietf-netconf-nmda". 161 These changes include the use of source and target parameters based 162 on the "datastore" identity defined in the "ietf-datastores" module 163 [RFC8342]. The use of identities allows future expansion in a way 164 that the choice-based strategy from the original operations (e.g., 165 , ) does not. 167 3.1. New NETCONF Operations 169 Two new operations and are defined in this 170 document in order to support the NMDA. These operations are similar 171 to the and operations but they can work on 172 an extensible set of datastores. 174 3.1.1. The Operation 176 The operation retrieves data from a specific NMDA 177 datastore. This operation is similar to NETCONF's 178 operation defined in [RFC6241], but it adds the flexibility to select 179 the source datastore. 181 +---x get-data 182 +---w input 183 | +---w datastore ds:datastore-ref 184 | +---w (filter-spec)? 185 | | +--:(subtree-filter) 186 | | | +---w subtree-filter? 187 | | +--:(xpath-filter) 188 | | +---w xpath-filter? yang:xpath1.0 {nc:xpath}? 189 | +---w config-filter? boolean 190 | +---w (origin-filters)? {origin}? 191 | | +--:(origin-filter) 192 | | | +---w origin-filter* or:origin-ref 193 | | +--:(negated-origin-filter) 194 | | +---w negated-origin-filter* or:origin-ref 195 | +---w max-depth? union 196 | +---w with-origin? empty {origin}? 197 | +---w with-defaults? with-defaults-mode 198 +--ro output 199 +--ro data? 201 The "datastore" parameter indicates the datastore which is the source 202 of the data to be retrieved. This is a datastore identity. 204 The operation accepts a content filter parameter, similar 205 to the "filter" parameter of , but using explicit nodes 206 for subtree filtering ("subtree-filter") and XPath filtering 207 ("xpath-filter"). 209 The "config-filter" parameter can be used to retrieve only "config 210 true" or "config false" nodes. 212 The "origin-filter" parameter, which can be present multiple times, 213 selects nodes matching any of the given values. The 214 "negated-origin-filter", which can be present multiple times, selects 215 nodes that do not match all given values. The "origin-filter" and 216 "negated-origin-filter" parameters cannot be used together. 218 The "max-depth" parameter can be used by the client to limit the 219 number of sub-tree levels that are returned in the reply. 221 3.1.1.1. With-defaults interactions 223 If the "with-defaults" capability is supported by the server, then 224 the "with-defaults" parameter, defined in [RFC6243], is supported for 225 operations that target conventional configuration 226 datastores. 228 The "with-defaults" parameter is optional to support for 229 operations that target . The associated capability to 230 indicate a server's support is identified with the URI: 232 urn:ietf:params:netconf:capability:with-operational-defaults:1.0 234 If the "with-defaults" parameter is supported for 235 operations on , then all retrieval modes specified in 236 either the 'basic-mode' or 'also-supported' parameters of the 237 "with-defaults" capability are permitted. The behavior of the 238 "with-defaults" parameter for is defined as below: 240 o If no "with-defaults" parameter is specified, or if it is set to 241 "explicit", "report-all", or "report-all-tagged", then the "in 242 use" values, as defined in [RFC8342] section 5.3, are returned 243 from the operational state datastore, even if a node happens to 244 have a default statement in the YANG module, and this default 245 value is being used by the server. If the "with-defaults" 246 parameter is set to "report-all-tagged", any values that match the 247 schema default are tagged with additional metadata, as described 248 in [RFC6243] section 3.4. 250 o If the "with-defaults" parameter is set to "trim", all "in use" 251 values are returned, except that the output is filtered to exclude 252 any values that match the default defined in the YANG schema. 254 Support for "with-defaults" in operations on any datastore 255 not defined in [RFC8342] SHOULD be defined by the specification for 256 the datastore. 258 3.1.1.2. Origin Metadata Attribute 260 The operation defines a parameter named "with-origin", 261 which if present, requests that the server includes "origin" metadata 262 annotations in its response, as detailed in the NMDA. This parameter 263 is only valid for the operational state datastore and any datastores 264 with identities derived from the "operational" identity. Otherwise, 265 if an invalid datastore is specified then an error is returned, as 266 specified in "ietf-netconf-nmda" (see Section 4). Note that "origin" 267 metadata annotations are not included in a response unless a client 268 explicitly requests them. 270 Data in the operational state datastore can come from multiple 271 sources. The server should return the most accurate value for the 272 "origin" metadata annotation as possible, indicating the source of 273 the operational value, as specified in Section 5.3.4 of [RFC8342]. 275 When encoding the origin metadata annotation for a hierarchy of 276 returned nodes, the annotation may be omitted for a child node when 277 the value matches that of the parent node, as described in the 278 "ietf-origin" YANG module [RFC8342]. 280 The "with-origin" parameter is optional to support. It is identified 281 with the feature "origin". 283 3.1.1.3. Example: Retrieving an entire subtree from 285 The following example shows the version of the 286 example shown in Section 7.1 of [RFC6241]. 288 290 292 ds:running 293 294 295 296 297 298 299 301 303 304 305 306 307 root 308 superuser 309 Charlie Root 310 311 1 312 1 313 314 315 316 317 318 319 321 3.1.2. The Operation 323 The operation changes the contents of a writable 324 datastore, similar to the operation defined in 325 [RFC6241], but with additional flexibility in naming the target 326 datastore. If an operation is invoked on a non-writable 327 datastore, then an error is returned, as specified in 328 "ietf-netconf-nmda" (see Section 4). 330 +---x edit-data 331 +---w input 332 +---w datastore ds:datastore-ref 333 +---w default-operation? enumeration 334 +---w (edit-content) 335 +--:(config) 336 | +---w config? 337 +--:(url) 338 +---w url? inet:uri {nc:url}? 340 The "datastore" parameter is a datastore identity that indicates the 341 desired target datastore where changes should be made. 343 The "default-operation" parameter is a copy of the 344 "default-operation" parameter of the operation. 346 The "edit-content" choice mirrors the "edit-content" choice of the 347 operation. Note, however, that the "config" element in 348 the "edit-content" choice of uses "anydata" (introduced 349 in YANG 1.1) while the "config" element in the "edit-content" choice 350 of used "anyxml". 352 The operation does not support the "error-option" and the 353 "test-option" parameters that were part of the 354 operation. The error behaviour of corresponds to the 355 "error-option" "rollback-on-error". 357 If the "with-defaults" capability is supported by the server, the 358 semantics of editing modes is the same as for , as 359 described in section 4.5.2 of [RFC6243]. 361 Semantics for "with-defaults" in operations on any non 362 conventional configuration datastores SHOULD be defined by the 363 specification for the datastore. 365 3.1.2.1. Example: Setting a leaf of an interface in 367 The following example shows the version of the first 368 example in Section 7.2 of [RFC6241], setting the MTU to 369 1500 on an interface named "Ethernet0/0" in the running configuration 370 datastore. 372 374 376 ds:running 377 378 379 380 Ethernet0/0 381 1500 382 383 384 385 386 388 390 391 393 The other examples shown in Section 7.2 can be 394 translated to examples in a similar way. 396 3.2. Augmentations to NETCONF Operations 398 Several of the operations defined in the base NETCONF YANG module 399 "ietf-netconf" [RFC6241] may be used with new datastores. Hence, the 400 , , and operations are augmented with a new 401 "datastore" leaf that can select the desired datastore. If a , 402 , or operation is not supported on a particular 403 datastore then an error is returned, as specified in 404 "ietf-netconf-nmda" (see Section 4). 406 4. NETCONF Datastores YANG Module 408 This module imports definitions from [RFC6991], [RFC6241], [RFC6243], 409 and [RFC8342]. 411 RFC Ed.: update the date below with the date of RFC publication and 412 remove this note. 414 file "ietf-netconf-nmda@2018-05-22" 416 module ietf-netconf-nmda { 417 yang-version 1.1; 418 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"; 419 prefix ncds; 421 import ietf-yang-types { 422 prefix yang; 423 reference "RFC 6991: Common YANG Data Types."; 424 } 425 import ietf-inet-types { 426 prefix inet; 427 reference "RFC 6991: Common YANG Data Types."; 428 } 429 import ietf-datastores { 430 prefix ds; 431 reference "RFC 8342: Network Management Datastore Architecture."; 432 } 433 import ietf-origin { 434 prefix or; 435 reference "RFC 8342: 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-05-22 { 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 8342: 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."; 555 reference 556 "RFC 6241: Network Configuration Protocol, Section 6."; 557 } 558 leaf xpath-filter { 559 if-feature nc:xpath; 560 type yang:xpath1.0; 561 description 562 "This parameter contains an XPath expression identifying 563 the portions of the target datastore to retrieve. 565 If the expression returns a node-set, all nodes in the 566 node-set are selected by the filter. Otherwise, if the 567 expression does not return a node-set, then the get-data 568 operation fails. 570 The expression is evaluated in the following XPath 571 context: 573 o The set of namespace declarations are those in 574 scope on the 'xpath-filter' leaf element. 576 o The set of variable bindings is empty. 578 o The function library is the core function library, 579 and the XPath functions defined in section 10 in 580 RFC 7950. 582 o The context node is the root node of the target 583 datastore."; 584 } 585 } 587 leaf config-filter { 588 type boolean; 589 description 590 "Filter for nodes with the given value for their 591 'config' property."; 592 } 593 choice origin-filters { 594 when 'derived-from-or-self(datastore, "ds:operational")'; 595 if-feature origin; 596 description 597 "Filters based on the 'origin' annotation."; 599 leaf-list origin-filter { 600 type or:origin-ref; 601 description 602 "Filter based on the 'origin' annotation. A node matches 603 the filter if its 'origin' annotation is derived from or 604 equal to any of the given filter values."; 605 } 606 leaf-list negated-origin-filter { 607 type or:origin-ref; 608 description 609 "Filter based on the 'origin' annotation. A node matches 610 the filter if its 'origin' annotation is not derived 611 from and not equal to all of the given filter values."; 612 } 613 } 615 leaf max-depth { 616 type union { 617 type uint16 { 618 range "1..65535"; 619 } 620 type enumeration { 621 enum "unbounded" { 622 description 623 "All descendant nodes are included."; 624 } 625 } 626 } 627 default "unbounded"; 628 description 629 "For each node selected by the filter, this parameter 630 selects how many conceptual sub-tree levels should be 631 returned in the reply. If the depth is 1, the reply 632 includes just the selected nodes but no children. If the 633 depth is 'unbounded', all descendant nodes are included."; 634 } 636 leaf with-origin { 637 when 'derived-from-or-self(../datastore, "ds:operational")'; 638 if-feature origin; 639 type empty; 640 description 641 "If this parameter is present, the server will return 642 the 'origin' annotation for the nodes that has one."; 643 } 645 uses ncwd:with-defaults-parameters { 646 if-feature with-defaults; 647 } 648 } 650 output { 651 anydata data { 652 description 653 "Copy of the source datastore subset which matched 654 the filter criteria (if any). An empty data 655 container indicates that the request did not 656 produce any results."; 657 } 658 } 659 } 661 rpc edit-data { 662 description 663 "Edit data in an NMDA datastore. 665 If an error condition occurs such that an error severity 666 element is generated, the server will stop 667 processing the operation and restore the 668 specified configuration to its complete state at 669 the start of this operation."; 670 input { 671 leaf datastore { 672 type ds:datastore-ref; 673 mandatory true; 674 description 675 "Datastore which is the target of the edit-data operation. 677 If the target datastore is not writable, or is not 678 supported by the server, then the server MUST return an 679 element with an value of 680 'invalid-value'."; 681 } 682 leaf default-operation { 683 type enumeration { 684 enum "merge" { 685 description 686 "The default operation is merge."; 687 } 688 enum "replace" { 689 description 690 "The default operation is replace."; 691 } 692 enum "none" { 693 description 694 "There is no default operation."; 695 } 696 } 697 default "merge"; 698 description 699 "The default operation to use."; 700 } 701 choice edit-content { 702 mandatory true; 703 description 704 "The content for the edit operation."; 706 anydata config { 707 description 708 "Inline config content."; 709 } 710 leaf url { 711 if-feature nc:url; 712 type inet:uri; 713 description 714 "URL based config content."; 715 } 716 } 717 } 718 } 720 /* 721 * Augment the lock and unlock operations with a 722 * "datastore" parameter. 723 */ 725 augment "/nc:lock/nc:input/nc:target/nc:config-target" { 726 description 727 "Add NMDA Datastore as target."; 728 leaf datastore { 729 type ds:datastore-ref; 730 description 731 "Datastore to lock. 733 The lock operation is only supported on writable datastores. 735 If the lock operation is not supported by the server on the 736 specified target datastore, then the server MUST return an 737 element with an value of 738 'invalid-value'."; 739 } 740 } 741 augment "/nc:unlock/nc:input/nc:target/nc:config-target" { 742 description 743 "Add NMDA Datastore as target."; 744 leaf datastore { 745 type ds:datastore-ref; 746 description 747 "Datastore to unlock. 749 The unlock operation is only supported on writable 750 datastores. 752 If the unlock operation is not supported by the server on 753 the specified target datastore, then the server MUST return 754 an element with an value of 755 'invalid-value'."; 756 } 757 } 759 /* 760 * Augment the validate operation with a 761 * "datastore" parameter. 762 */ 764 augment "/nc:validate/nc:input/nc:source/nc:config-source" { 765 description 766 "Add NMDA Datastore as source."; 767 leaf datastore { 768 type ds:datastore-ref; 769 description 770 "Datastore to validate. 772 The validate operation is supported only on configuration 773 datastores. 775 If the validate operation is not supported by the server on 776 the specified target datastore, then the server MUST return 777 an element with an value of 778 'invalid-value'."; 780 } 781 } 782 } 784 786 5. IANA Considerations 788 This document registers two capability identifier URNs in the 789 "Network Configuration Protocol (NETCONF) Capability URNs" registry: 791 Index 792 Capability Identifier 793 --------------------- 794 :yang-library 795 urn:ietf:params:netconf:capability:yang-library:1.1 797 :with-operational-defaults 798 urn:ietf:params:netconf:capability:with-operational-defaults:1.0 800 This document registers a URI in the "IETF XML Registry" [RFC3688]. 801 Following the format in RFC 3688, the following registration has been 802 made. 804 URI: urn:ietf:params:xml:ns:yang:ietf-netconf-nmda 806 Registrant Contact: The IESG. 808 XML: N/A, the requested URI is an XML namespace. 810 This document registers a YANG module in the "YANG Module Names" 811 registry [RFC6020]. 813 name: ietf-netconf-nmda 814 namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-nmda 815 prefix: ncds 816 reference: RFC XXXX 818 6. Security Considerations 820 The YANG module defined in this document extends the base operations 821 of the NETCONF [RFC6241] protocol. The lowest NETCONF layer is the 822 secure transport layer and the mandatory-to-implement secure 823 transport is Secure Shell (SSH) [RFC6242]. 825 The network configuration access control model [RFC8341] provides the 826 means to restrict access for particular NETCONF users to a 827 preconfigured subset of all available NETCONF protocol operations and 828 content. 830 The security considerations for the base NETCONF protocol operations 831 (see Section 9 of [RFC6241]) apply to the new NETCONF and 832 operations defined in this document. 834 7. References 835 7.1. Normative References 837 [I-D.ietf-netconf-rfc7895bis] 838 Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 839 and R. Wilton, "YANG Library", draft-ietf-netconf- 840 rfc7895bis-06 (work in progress), April 2018. 842 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 843 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 844 RFC2119, March 1997, . 847 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 848 DOI 10.17487/RFC3688, January 2004, . 851 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 852 the Network Configuration Protocol (NETCONF)", RFC 6020, 853 DOI 10.17487/RFC6020, October 2010, . 856 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 857 and A. Bierman, Ed., "Network Configuration Protocol 858 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 859 . 861 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 862 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 863 . 865 [RFC6243] Bierman, A. and B. Lengyel, "With-defaults Capability for 866 NETCONF", RFC 6243, DOI 10.17487/RFC6243, June 2011, 867 . 869 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 870 6991, DOI 10.17487/RFC6991, July 2013, . 873 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 874 RFC 7950, DOI 10.17487/RFC7950, August 2016, 875 . 877 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 878 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 879 May 2017, . 881 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 882 Access Control Model", STD 91, RFC 8341, DOI 10.17487/ 883 RFC8341, March 2018, . 886 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 887 and R. Wilton, "Network Management Datastore Architecture 888 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 889 . 891 7.2. Informative References 893 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 894 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 895 . 897 Authors' Addresses 899 Martin Bjorklund 900 Tail-f Systems 902 Email: mbj@tail-f.com 904 Juergen Schoenwaelder 905 Jacobs University 907 Email: j.schoenwaelder@jacobs-university.de 909 Phil Shafer 910 Juniper Networks 912 Email: phil@juniper.net 914 Kent Watsen 915 Juniper Networks 917 Email: kwatsen@juniper.net 919 Robert Wilton 920 Cisco Systems 922 Email: rwilton@cisco.com