idnits 2.17.1 draft-dsdt-nmda-netconf-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 4, 2017) is 2459 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 (-10) exists of draft-ietf-netmod-revised-datastores-03 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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 Intended status: Standards Track J. Schoenwaelder 5 Expires: January 5, 2018 Jacobs University 6 P. Shafer 7 K. Watsen 8 Juniper Networks 9 R. Wilton 10 Cisco Systems 11 July 4, 2017 13 NETCONF Model for NMDA 14 draft-dsdt-nmda-netconf-00 16 Abstract 18 The "Network Management Datastore Architecture" (NMDA) improves on 19 NETCONF by adding new features to give more accurate handling of 20 configuration and operational data. These include ability to inspect 21 the current operational values of configuration data, allowing 22 clients to use identical paths for retrieving the configured values 23 and the operational values. These new features require additional 24 operations in network management applications such as NETCONF. This 25 draft details those new operations. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 5, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. The NMDA Model for NETCONF . . . . . . . . . . . . . . . . . 3 65 2.1. Operations . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.1.1. The Operation . . . . . . . . . . . . . . 3 67 2.1.2. The Operation . . . . . . . . . . . . . . 4 68 2.2. Augmentations to the Base NETCONF Model . . . . . . . . . 4 69 2.3. RPCs and Actions . . . . . . . . . . . . . . . . . . . . 4 70 3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 6. Informative References . . . . . . . . . . . . . . . . . . . 9 74 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 This document provides a YANG model that adds NETCONF ([RFC6241]) 80 support for the emerging "Network Management Datastore Architecture" 81 (NMDA) [I-D.ietf-netmod-revised-datastores]. NMDA defines a 82 framework for datastores, a fundamental concept binding network 83 management data models to network management protocols, enabling data 84 models to be written in a network management protocol agnostic way. 85 NETCONF operations currently refer to the datastores defined in the 86 original model, so new operations are required to allow references to 87 the new datastores. 89 Operations like , and are augmented to 90 allow them to target additional datastores. 92 In addition the original operation is deprecated, since the 93 information it returns is no longer needed. 's deficiencies 94 were a major motivation for the NMDA. 96 1.1. Keywords 98 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 100 "OPTIONAL" in this document are to be interpreted as described in BCP 101 14, [RFC2119] [RFC8174] when, and only when, they appear in all 102 capitals, as shown here.. 104 1.2. Terminology 106 This document uses the terminology defined by the NMDA 107 [I-D.ietf-netmod-revised-datastores]. 109 2. The NMDA Model for NETCONF 111 This section describes the changes needed for NMDA support. These 112 changes are contained in a new YANG ([RFC7950]) model 113 "ietf-netconf-datastores". 115 These changes include the use of source and target parameters based 116 on the "datastore" identity defined in the "ietf-datastores" from 117 [I-D.ietf-netmod-revised-datastores]. The use of identities allows 118 future expansion in a way that the choice-based strategy from the 119 original operations (e.g. , ) do not. 121 2.1. Operations 123 Support for the NMDA includes two new operations defined in this 124 document. 126 2.1.1. The Operation 128 The operation retrieves data from a specific NMDA 129 datastore. This operation is similar to NETCONF's "get-config" 130 operation, but adds flexibility in naming the target datastore. 132 The "source" parameter indicates the datastore which is the source of 133 the data to be retrieved. This is a datastore identity. 135 The "get-data" operation mirrors the "filter" parameter of the 136 "get-config" operation, but it is modified to use "type anydata" for 137 configuration content, rather than the "get-config"'s use of "type 138 anyxml". 140 The "get-data" operation also supports the "with-defaults" parameter 141 as defined in [RFC6243]. The supported values follow the constraints 142 given by the "with-defaults" capability. 144 2.1.1.1. Origin Attribute 146 The "get-data" operation adds a new boolean parameter named "origin", 147 which requests that the server return the "origin" information as 148 detailed in the NMDA. This parameter is only valid for 149 and any datastores with identities derived from the "operational" 150 identity. 152 Data from can come from multiple sources. The server 153 should return the most accurate value for the "origin" attribute as 154 possible, indicating the source of the operational value. 156 When encoding the origin attribute for a hierarchy of returned nodes, 157 the origin attribute may be omitted when the value matches that of 158 the parent node. 160 2.1.2. The Operation 162 The operation changes the contents of a specific 163 datastore, similar to the operation, but with 164 additional flexibility in naming the target datastore. 166 The "target" parameter is a datastore identity that indicates the 167 desired target datastore where changes should be made. 169 The "edit-content" parameter from "edit-config" it is modified to 170 allow use "type anydata" for configuration content, rather than the 171 "edit-config"'s use of "type anyxml". 173 The "default-operation" parameter mirrors the parameter of the 174 "edit-config" operation. 176 2.2. Augmentations to the Base NETCONF Model 178 Several of the operations defined in the base NETCONF data model 179 (ietf-netconf@2011-06-01.yang) will continue to be used under the 180 NMDA. The , , and operations are augmented 181 with a new "datastore" leaf can indicate a desired NMDA datastore. 183 Only writable datastores can be locked. 185 2.3. RPCs and Actions 187 RPC operations and actions can be defined in YANG modules. The 188 evaluation context for constraints and references in operation and 189 actions is . 191 3. YANG Model 193 file "ietf-netconf-datastores@2017-06-30.yang" 195 module ietf-netconf-datastores { 196 yang-version 1.1; 197 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-datastores"; 198 prefix ncds; 200 import ietf-inet-types { 201 prefix inet; 202 } 203 import ietf-datastores { 204 prefix ds; 205 } 206 import ietf-netconf { 207 prefix nc; 208 } 209 import ietf-netconf-with-defaults { 210 prefix ncwd; 211 } 213 organization 214 "IETF NETCONF Working Group"; 215 contact 216 "WG Web: 218 WG List: 220 Author: Martin Bjorklund 221 223 Author: Juergen Schoenwaelder 224 226 Author: Phil Shafer 227 229 Author: Kent Watsen 230 232 Author: Rob Wilton 233 "; 234 description 235 "This YANG module defines a set of NETCONF operations for the 236 Network Management Datastore Architecture (NMDA). 238 Copyright (c) 2017 IETF Trust and the persons identified as 239 authors of the code. All rights reserved. 241 Redistribution and use in source and binary forms, with or 242 without modification, is permitted pursuant to, and subject to 243 the license terms contained in, the Simplified BSD License set 244 forth in Section 4.c of the IETF Trust's Legal Provisions 245 Relating to IETF Documents 246 (http://trustee.ietf.org/license-info). 248 This version of this YANG module is part of RFC XXXX 249 (http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself 250 for full legal notices."; 252 revision 2017-06-30 { 253 description 254 "Initial revision."; 255 reference "RFC XXXX: NETCONF Support for NMDA"; 256 } 258 typedef datastore { 259 type identityref { 260 base ds:datastore; 261 } 262 description 263 "An NMDA datastore."; 264 reference "RFC XXXX: Network Management Datastore Architecture"; 265 } 267 rpc get-data { 268 description 269 "Get data from an NMDA datastore"; 270 input { 271 leaf source { 272 type ncds:datastore; 273 description 274 "Datastore from which to retrieve data."; 275 } 276 anydata filter { 277 description 278 "Subtree or XPath filter to use."; 279 nc:get-filter-element-attributes; 280 } 281 } 282 output { 283 anydata data { 284 description 285 "Copy of the source datastore subset which matched 286 the filter criteria (if any). An empty data 287 container indicates that the request did not 288 produce any results."; 289 } 290 } 291 } 292 rpc edit-data { 293 description 294 "Edit data in an NMDA datastore."; 295 input { 296 leaf target { 297 type ncds:datastore; 298 description 299 "Datastore which data affects."; 300 } 301 leaf default-operation { 302 type enumeration { 303 enum "merge" { 304 description 305 "The default operation is merge."; 306 } 307 enum "replace" { 308 description 309 "The default operation is replace."; 310 } 311 enum "none" { 312 description 313 "There is no default operation."; 314 } 315 } 316 default "merge"; 317 description 318 "The default operation to use."; 319 } 320 uses ncwd:with-defaults-parameters; 321 choice edit-content { 322 mandatory true; 323 description 324 "The content for the edit operation."; 326 anydata config { 327 description 328 "Inline Config content."; 329 } 330 leaf url { 331 if-feature nc:url; 332 type inet:uri; 333 description 334 "URL based config content."; 336 } 337 } 338 } 339 } 341 /* 342 * Augment the lock and unlock operations with a 343 * "datastore" parameter. 344 */ 346 augment "/nc:lock/nc:input/nc:target/nc:config-target" { 347 description 348 "Add NMDA Datastore as target."; 349 leaf datastore { 350 type ncds:datastore; 351 description 352 "Datastore to lock."; 353 } 354 } 355 augment "/nc:unlock/nc:input/nc:target/nc:config-target" { 356 description 357 "Add NMDA Datastore as target."; 358 leaf datastore { 359 type ncds:datastore; 360 description 361 "Datastore to unlock."; 362 } 363 } 365 /* 366 * Augment the validate operation with a 367 * "datastore" parameter. 368 */ 370 augment "/nc:validate/nc:input/nc:source/nc:config-source" { 371 description 372 "Add NMDA Datastore as source."; 373 leaf datastore { 374 type ncds:datastore; 375 description 376 "Datastore to validate."; 377 } 378 } 379 } 381 383 4. IANA Considerations 385 This document has no actions for IANA. 387 5. Security Considerations 389 This document has no security considerations. 391 6. Informative References 393 [I-D.ietf-netmod-revised-datastores] 394 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 395 and R. Wilton, "Network Management Datastore 396 Architecture", draft-ietf-netmod-revised-datastores-03 397 (work in progress), July 2017. 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 401 RFC2119, March 1997, 402 . 404 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 405 and A. Bierman, Ed., "Network Configuration Protocol 406 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 407 . 409 [RFC6243] Bierman, A. and B. Lengyel, "With-defaults Capability for 410 NETCONF", RFC 6243, DOI 10.17487/RFC6243, June 2011, 411 . 413 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 414 RFC 7950, DOI 10.17487/RFC7950, August 2016, 415 . 417 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 418 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 419 May 2017, . 421 Appendix A. Examples 423 Authors' Addresses 425 Martin Bjorklund 426 Tail-f Systems 428 Email: mbj@tail-f.com 429 Juergen Schoenwaelder 430 Jacobs University 432 Email: j.schoenwaelder@jacobs-university.de 434 Phil Shafer 435 Juniper Networks 437 Email: phil@juniper.net 439 Kent Watsen 440 Juniper Networks 442 Email: kwatsen@juniper.net 444 Robert Wilton 445 Cisco Systems 447 Email: rwilton@cisco.com