idnits 2.17.1 draft-wilton-netmod-yang-ver-selection-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 == Line 372 has weird spacing: '...tastore ds:...' -- The document date (March 11, 2019) is 1871 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) == Unused Reference: 'I-D.ietf-netconf-rfc7895bis' is defined on line 638, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netmod-module-tags' is defined on line 643, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netmod-yang-instance-file-format' is defined on line 648, but no explicit reference was found in the text == Unused Reference: 'RFC5246' is defined on line 673, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 678, but no explicit reference was found in the text == Unused Reference: 'RFC6242' is defined on line 683, but no explicit reference was found in the text == Unused Reference: 'RFC6536' is defined on line 687, but no explicit reference was found in the text == Unused Reference: 'RFC8040' is defined on line 696, but no explicit reference was found in the text == Unused Reference: 'I-D.bierman-netmod-yang-package' is defined on line 711, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netmod-artwork-folding' is defined on line 715, but no explicit reference was found in the text == Unused Reference: 'RFC8199' is defined on line 721, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-netmod-module-tags-07 == Outdated reference: A later version (-21) exists of draft-ietf-netmod-yang-instance-file-format-02 == Outdated reference: A later version (-03) exists of draft-rwilton-netmod-yang-packages-00 == Outdated reference: A later version (-01) exists of draft-verdt-netmod-yang-semver-00 ** Downref: Normative reference to an Informational draft: draft-verdt-netmod-yang-versioning-reqs (ref. 'I-D.verdt-netmod-yang-versioning-reqs') ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341) == Outdated reference: A later version (-12) exists of draft-ietf-netmod-artwork-folding-01 Summary: 3 errors (**), 0 flaws (~~), 18 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Wilton 3 Internet-Draft R. Rahman 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: September 12, 2019 March 11, 2019 7 YANG Schema Version Selection 8 draft-wilton-netmod-yang-ver-selection-00 10 Abstract 12 This document defines protocol mechanisms to allow clients to choose 13 which YANG schema to use for interactions with a server, out of the 14 available YANG schema supported by a server. The provided 15 functionality allow servers to support clients in a backwards 16 compatible way, at the same time allowing for non-backwards- 17 compatible updates to YANG modules. 19 This draft provides a solution to YANG versioning requirements 3.1 20 and 3.2. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 12, 2019. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 2 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 5. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 61 6. Version selection from a server perspective . . . . . . . . . 6 62 7. Version selection from a clients perspective . . . . . . . . 7 63 8. Limitations of the solution . . . . . . . . . . . . . . . . . 7 64 9. Schema Version Selection YANG module . . . . . . . . . . . . 8 65 10. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 67 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 68 13. Open Questions/Issues . . . . . . . . . . . . . . . . . . . . 14 69 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 70 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 15.1. Normative References . . . . . . . . . . . . . . . . . . 14 72 15.2. Informative References . . . . . . . . . . . . . . . . . 15 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 75 1. Terminology and Conventions 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 79 "OPTIONAL" in this document are to be interpreted as described in BCP 80 14 [RFC2119] [RFC8174] when, and only when, they appear in all 81 capitals, as shown here. 83 This document uses terminology introduced in the YANG versioning 84 requirements draft [I-D.verdt-netmod-yang-versioning-reqs]. 86 This document also makes of the following terminology introduced in 87 the Network Management Datastore Architecture [RFC8342]: 89 o datastore schema 91 In addition, this document makes use of the following terminology: 93 o bc: Used as an abbreviation for a backwards-compatible change. 95 o nbc: Used as an abbreviation for a non-backwards-compatible 96 change. 98 o editorial change: A backwards-compatible change that does not 99 change the YANG module semantics in any way. 101 o YANG schema: The combined set of schema nodes for a set of YANG 102 module revisions, taking into consideration any deviations and 103 enabled features. 105 o versioned schema: A YANG schema with an associated YANG semantic 106 version number, e.g., as might be described by a YANG package. 108 o schema set: A set of related versioned YANG schema, one for each 109 datastore that is supported. 111 TODO - the bc/nbc/editorial terminology should probably be defined 112 and referenced from the YANG module versioning solution draft. 113 'schema' and 'versioned schema' could be defined in the packages 114 draft. 116 2. Introduction 118 This document describes how NETCONF and RESTCONF clients can choose a 119 particular YANG schema they wish to choose to interact with a server 120 with. 122 [I-D.verdt-netmod-yang-versioning-reqs] defines requirements that any 123 solution to YANG versioning must have. 125 [I-D.verdt-netmod-yang-semver] specifies a partial solution to the 126 YANG versioning requirements that focuses on using semantic 127 versioning within individual YANG modules, but does not address all 128 the requirements listed in the requirements draft. Of particular 129 relevance here, requirements 3.1 and 3.2 are not addressed. 131 [I-D.rwilton-netmod-yang-packages] describes how sets of related YANG 132 modules can be grouped together into a logical entity that is 133 versioned using the YANG semantic versioning number scheme. 134 Different packages can be defined for different sets of YANG modules, 135 e.g., packages could be defined for the IETF YANG modules, OpenConfig 136 YANG modules, a vendor's YANG modules. Different versions of these 137 package definitions can be defined as the contents of these packages 138 evolve over time, and as the versions of the YANG modules included in 139 the package evolve. 141 This draft defines how YANG packages can be used to represent 142 versioned datastore schema, and how clients can choose which 143 versioned schemas to use during interactions with a device. 145 3. Background 147 There are three ways that the lifecycle of a data model can be 148 managed: 150 1. Disallow all non-backwards-compatible updates to a YANG module. 151 Broadly this is the approach adopted by [RFC7950], but it has 152 been shown to be too inflexible in some cases. E.g. it makes it 153 hard to fix bugs in a clean fashion - it is not clear that 154 allowing two independent data nodes (one deprecated, one current) 155 to configure the same underlying property is robustly backwards 156 compatible in all scenarios, particularly if the value space and/ 157 or default values differ between the module revisions. 159 2. Allow non-backwards-compatible updates to YANG modules, and use a 160 mechanism such as semantic version numbers to communicate the 161 likely impact of any changes to module users, but require that 162 clients handle non-backwards-compatible changes in servers by 163 migrating to new versions of the modules. Without version 164 selection, this is what the [I-D.verdt-netmod-yang-semver] 165 approach likely achieves. 167 3. Allow non-backwards-compatible updates to YANG modules, but also 168 provide mechanisms to allow servers to support multiple versions 169 of YANG modules, and provide clients with some ability to select 170 which versions of YANG modules they wish to interact with, 171 subject to some reasonable constraints. This is the approach 172 that this draft aims to address. It is worth noting that the 173 idea of supporting multiple versions of an API is not new in the 174 wider software industry, and there any many examples of where 175 this approach has been successfully used. 177 4. Objectives 179 The goals of the schema version selection draft are: 181 o To provide a mechanism where non-backwards-compatible changes and 182 bug fixes can be made to YANG modules without forcing clients to 183 immediately migrate to new versions of those modules as they get 184 implemented. 186 o To allow servers to support multiple versions of a particular YANG 187 schema, and to allow clients to choose which YANG schema version 188 to use when interoperating with the server. The aim here is to 189 give operators more flexibility as to when they update their 190 software. 192 o To provide a mechanism to allow different YANG schema families 193 (e.g., SDO models, OpenConfig models, Vendor models) to be 194 supported by a server, and to allow clients to choose which YANG 195 schema family is used to interoperate with the server. 197 The following points are non objective of this draft: 199 o This draft does not provide a mechanism to allow clients to choose 200 arbitrary sets of YANG module versions to interoperate with the 201 server. 203 o Servers are not required to concurrently support clients using 204 different YANG schema families or versioned schema. A server MAY 205 choose to only allow a single schema family or single versioned 206 schema to be used by all clients. 208 o There is no requirement for a server to support every published 209 version of a YANG package, particularly if some package versions 210 are backwards compatible. Clients are required to interoperate 211 with backwards compatible updates of YANG modules. E.g., if a 212 particular package was available in versions 1.0.0, 1.1.0, 1.2.0, 213 2.0.0, 3.0.0 and 3.1.0, then a server may choose to only support 214 versions 1.2.0, 2.0.0, and 3.1.0, with the knowledge that all 215 clients should be able to interoperate with the server. 217 o There is no requirement to support all parts of all versioned 218 schemas. For some nbc changes in modules, it is not possible for 219 a server to support both the old and new module versions, and to 220 convert between the two. Where appropriate deviations can be 221 used, and otherwise an out of band mechanism is used to indicate 222 where a mapping has failed. 224 5. Solution Overview 226 An overview the solution is as follows: 228 1. YANG packages are defined for the different versioned schema 229 supported by a server: 231 * Separate packages can be defined for different families of 232 schema, e.g., SDO, OpenConfig, or vendor native. 234 * Separate packages can be defined for each versioned schema 235 within a schema family. 237 * Separate packages may be defined for different datastores, if 238 the datastores use different datastore schema. For example, a 239 different datastore schema, and hence package, might be used 240 for vs the conventional datastores. 242 2. Each server advertises, via an operational data model: 244 * All of the YANG packages that may be used during version 245 selection. The packages can also be made available for 246 offline consumption via instance data documents, as described 247 in [I-D.rwilton-netmod-yang-packages]. 249 * Grouped sets of versioned schema, where each set defines the 250 versioned schema used by each supported datastore, and each 251 versioned schema is represented by a YANG package instance. 253 3. Each server supports configuration to: 255 * Allow a client to configure which schema version set to use 256 for the default NETCONF/RESTCONF connections. 258 * Allow a client to configure additional separate NETCONF and 259 RESTCONF protocol instances, which use different schema 260 version sets on those protocol instances. 262 * An RPC mechanism could also be defined to select schema, but 263 is not currently discussed in this draft. 265 4. The server internally maps requests between the different 266 protocol instances to the internal device implementation. 268 6. Version selection from a server perspective 270 The general premise of this solution is that servers generally 271 implement one native schema, and the version selection scheme is used 272 to support older version of that native schema and also foreign 273 schema specified by external entities. 275 Overall the solution relies on the ability to map instance data 276 between different schema versions. Depending on the scope of 277 difference between the schema versions then some of these mappings 278 may be very hard, or even impossible, to implement. Hence, there is 279 still a strong incentive to try and minimize nbc changes between 280 schema versions to minimize the mapping complexity. 282 Server implementations MUST serialize configuration requests across 283 the different schema. The expectation is that this would be achieved 284 by mapping all requests to the devices native schema version. 286 Datastore validation needs to be performed in two places, firstly in 287 whichever schema a clients is interacting in, and secondly in the 288 native schema for the device. This could have a negative performance 289 impact. 291 Depending on the complexity of the mappings between schema versions, 292 it may be necessary for the mappings to be stateful. 294 TODO - Figure out how hot fixes that slightly modify the schema are 295 handled. 297 7. Version selection from a clients perspective 299 Clients can use configuration to choose which schema sets are 300 available. 302 Clients cannot choose arbitrary individual YANG module versions, and 303 are instead constrained by the versions that the server makes 304 available. 306 Each client protocol connection is to one particular schema set. 307 From that client session perspective it appears as if the client is 308 interacting with a regular server. If the client queries YANG 309 library that the version of YANG Library that is returned matches the 310 schema set that is being used for that server instance. 312 The server may not support a schema with the exact version desired by 313 the client, and they have to accept a later version that is backwards 314 compatible with their desired version. Clients may also have to 315 accept later schema versions that contain NBC fixes, although the 316 assumption is that such nbc fixes should be designed to minimize the 317 impact on clients. 319 There is no guarantee that servers will always be able to support all 320 older schema versions. Deviations should be used where necessary to 321 indicate that the server is unable to faithfully implement the older 322 schema version. 324 If clients interact with a server using multiple versions, they 325 should not exact that all data nodes in later module versions can 326 always be backported to older schema versions. TODO - Specify how 327 mapping errors can be reported to client. 329 8. Limitations of the solution 331 Not all schema conversions are possible. E.g. an impossible type 332 conversion, or something has been removed. The solution is 333 fundamentally limited by how the schemas actually change, this 334 solution does not provide a magic bullet that can solve all 335 versioning issues. 337 9. Schema Version Selection YANG module 339 The YANG schema version selection YANG module is used by a device to 340 report the schema-sets that are available, and to allow clients to 341 choose which schema-set they wish to use. 343 Feature are used to allow servers to decide whether they allow the 344 primary schema-set to be changed, and/or allow secondary schema-sets 345 to be configured. 347 The primary schema-set is the datastore schema reported by YANG 348 Library if a client connects to the device using the standard 349 NETCONF/RESTCONF protocol numbers. 351 If secondary schema-sets are configured, then the client can choose 352 whether NETCONF or RESTCONF is supported, which port numbers the 353 protocols should run on (if available), and what RESTCONF root path 354 prefix to use (e.g. if all of the RESTCONF protocol instances run on 355 port 443. 357 Different schema-sets may support different datastores. 359 The "ietf-schema-version-selection" YANG module has the following 360 structure: 362 module: ietf-schema-version-selection 363 +--rw schema-selection 364 +--rw schema-sets* [name] 365 | +--rw name string 366 | +--rw netconf! {secondary-schema-set}? 367 | | +--rw port? inet:port-number 368 | +--rw restconf! {secondary-schema-set}? 369 | | +--rw port? inet:port-number 370 | | +--rw root-path? inet:uri 371 | +--ro datastores* [datastore] 372 | +--ro datastore ds:datastore-ref 373 | +--ro package 374 | +--ro name? 375 | | -> /yanglib:yang-library/pkg:package/name 376 | +--ro version? leafref 377 +--rw default-schema-set? 378 -> /schema-selection/schema-sets/name 379 {default-schema-set}? 381 10. YANG Module 383 The YANG module definition for the module described in the previous 384 sections. 386 file "ietf-schema-version-selection@2019-03-11.yang" 387 module ietf-schema-version-selection { 388 yang-version 1.1; 389 namespace 390 "urn:ietf:params:xml:ns:yang:ietf-schema-version-selection"; 391 prefix "ver-sel"; 393 import ietf-inet-types { 394 prefix inet; 395 reference "RFC 6991: Common YANG Data Types."; 396 } 397 import ietf-datastores { 398 prefix ds; 399 reference 400 "RFC 8342: Network Management Datastore Architecture (NMDA)"; 401 } 402 import ietf-yang-library { 403 prefix yanglib; 404 reference "RFC 8525: YANG Library"; 405 } 406 import ietf-yang-library-packages { 407 prefix pkg; 408 reference "draft-rwilton-netmod-yang-packages-01"; 409 } 411 organization 412 "IETF NETMOD (Network Modeling) Working Group"; 414 contact 415 "WG Web: 416 WG List: 418 Author: Reshad Rahman 419 421 Author: Rob Wilton 422 "; 424 description 425 "This module provide a data model to advertise and allow the 426 selection of schema versions by clients. 428 Copyright (c) 2019 IETF Trust and the persons identified as 429 authors of the code. All rights reserved. 431 Redistribution and use in source and binary forms, with or 432 without modification, is permitted pursuant to, and subject 433 to the license terms contained in, the Simplified BSD License 434 set forth in Section 4.c of the IETF Trust's Legal Provisions 435 Relating to IETF Documents 436 (http://trustee.ietf.org/license-info). 438 This version of this YANG module is part of RFC XXXX; see 439 the RFC itself for full legal notices."; 441 // RFC Ed.: update the date below with the date of RFC publication 442 // and remove this note. 443 // RFC Ed.: replace XXXX with actual RFC number and remove this 444 // note. 445 revision 2019-03-11 { 446 description 447 "Initial revision"; 448 reference 449 "RFC XXXX: YANG Schema Version Selection"; 450 } 452 /* 453 * Typedefs 454 */ 456 typedef yang-sem-ver { 457 type string { 458 pattern '\d+[.]\d+[.]\d+[mM]?'; 459 } 460 description 461 "Represents a YANG semantic version number."; 462 reference 463 "TODO - Should be defined by YANG versioning types module"; 464 } 466 feature "default-schema-set" { 467 description 468 "Feature that allows clients to choose the default schema set 469 to be used for clients that connect using the standard network 470 configuration protocol port number or URL. 472 Implementations may choose to only support this feature in 473 to report the default-schema-set without 474 allowing it to be configured."; 475 } 476 feature "secondary-schema-set" { 477 description 478 "Feature to choose if secondary schema sets may be configured 479 by clients. 481 Implementations may choose to only support this feature in 482 to report secondary schema sets without 483 allowing them to be configured."; 484 } 486 container schema-selection { 487 description 488 "YANG schema version selection"; 490 list schema-sets { 491 key "name"; 493 description 494 "All schema-sets that are available for client selection."; 496 leaf name { 497 type "string" { 498 length "1..255"; 499 } 500 description 501 "The server assigned name of the schema-set. 503 This should include the schema family, and appropriate 504 versioning or release information"; 505 } 507 container netconf { 508 if-feature "secondary-schema-set"; 510 presence "Make this schema-set available via NETCONF"; 511 description 512 "NETCONF protocol settings for this schema set, if 513 available"; 515 leaf port { 516 type inet:port-number; 517 description 518 "The port numnber to use for interacting with this 519 schema-set. If not configured,then the port number is 520 server allocated."; 521 reference 522 "RFC 6242: Using the NETCONF Protocol over SSH"; 523 } 525 } 527 container restconf { 528 if-feature "secondary-schema-set"; 530 presence 531 "Make this schema-set available via RESTCONF"; 532 description 533 "RESTCONF protocol settings for this schema set, if 534 available"; 536 leaf port { 537 type inet:port-number; 538 default "443"; 539 description 540 "The port numnber to use for interacting with this 541 schema-set. If not configured, then the port number 542 defaults to the standard RESTCONF https port number of 543 443"; 544 reference 545 "RFC 8040: RESTCONF Protocol, section 2.1"; 546 } 548 leaf root-path { 549 type inet:uri; 550 default "/restconf"; 551 description 552 "The default root path to use to access the RESTCONF 553 protocol instance for this schema-set"; 555 } 556 } 558 list datastores { 559 key "datastore"; 560 config false; 562 description 563 "The list of datastores supported for this schema set"; 565 leaf datastore { 566 type ds:datastore-ref; 567 description 568 "The datastore that this datastore schema is associated 569 with"; 570 reference 571 "RFC 8342: Network Management Datastore Architecture 572 (NMDA)"; 574 } 576 container package { 577 description 578 "YANG package associated with this datastore schema"; 580 leaf name { 581 type leafref { 582 path "/yanglib:yang-library/pkg:package/pkg:name"; 583 } 584 description 585 "The name of the YANG package this schema relates to"; 586 } 587 leaf version { 588 type leafref { 589 path '/yanglib:yang-library/' 590 + 'pkg:package[pkg:name = current()/../name]/' 591 + 'pkg:version'; 592 } 594 description 595 "The version of the YANG package this schema relates 596 to"; 597 } 598 } 599 } 600 } 602 leaf default-schema-set { 603 if-feature "default-schema-set"; 604 type leafref { 605 path '/schema-selection/schema-sets/name'; 606 } 607 description 608 "Specifies the default schema-set used by this device. This 609 is the set of datastore schema that is used if a client 610 connects using the standard protocol port numbers and URLs"; 611 } 612 } 613 } 614 616 11. Security Considerations 618 To be defined. 620 12. IANA Considerations 622 TODO - Add registrations for YANG modules defined in this draft. 624 13. Open Questions/Issues 626 All issues, along with the draft text, are currently being tracked 627 at: TODO - URL 629 14. Acknowledgements 631 The ideas that formed this draft are based on discussions with the 632 YANG versioning design team, and other members of the NETMOD WG. 634 15. References 636 15.1. Normative References 638 [I-D.ietf-netconf-rfc7895bis] 639 Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K., 640 and R. Wilton, "YANG Library", draft-ietf-netconf- 641 rfc7895bis-07 (work in progress), October 2018. 643 [I-D.ietf-netmod-module-tags] 644 Hopps, C., Berger, L., and D. Bogdanovic, "YANG Module 645 Tags", draft-ietf-netmod-module-tags-07 (work in 646 progress), March 2019. 648 [I-D.ietf-netmod-yang-instance-file-format] 649 Lengyel, B. and B. Claise, "YANG Instance Data File 650 Format", draft-ietf-netmod-yang-instance-file-format-02 651 (work in progress), February 2019. 653 [I-D.rwilton-netmod-yang-packages] 654 Wilton, R., "YANG Packages", draft-rwilton-netmod-yang- 655 packages-00 (work in progress), December 2018. 657 [I-D.verdt-netmod-yang-semver] 658 Claise, B., Clarke, J., Rahman, R., Wilton, R., Lengyel, 659 B., Sterne, J., and K. D'Souza, "YANG Semantic Versioning 660 for Modules", draft-verdt-netmod-yang-semver-00 (work in 661 progress), March 2019. 663 [I-D.verdt-netmod-yang-versioning-reqs] 664 Clarke, J., "YANG Module Versioning Requirements", draft- 665 verdt-netmod-yang-versioning-reqs-02 (work in progress), 666 November 2018. 668 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 669 Requirement Levels", BCP 14, RFC 2119, 670 DOI 10.17487/RFC2119, March 1997, 671 . 673 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 674 (TLS) Protocol Version 1.2", RFC 5246, 675 DOI 10.17487/RFC5246, August 2008, 676 . 678 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 679 and A. Bierman, Ed., "Network Configuration Protocol 680 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 681 . 683 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 684 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 685 . 687 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 688 Protocol (NETCONF) Access Control Model", RFC 6536, 689 DOI 10.17487/RFC6536, March 2012, 690 . 692 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 693 RFC 7950, DOI 10.17487/RFC7950, August 2016, 694 . 696 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 697 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 698 . 700 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 701 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 702 May 2017, . 704 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 705 and R. Wilton, "Network Management Datastore Architecture 706 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 707 . 709 15.2. Informative References 711 [I-D.bierman-netmod-yang-package] 712 Bierman, A., "The YANG Package Statement", draft-bierman- 713 netmod-yang-package-00 (work in progress), July 2015. 715 [I-D.ietf-netmod-artwork-folding] 716 Watsen, K., Wu, Q., Farrel, A., and B. Claise, "Handling 717 Long Lines in Inclusions in Internet-Drafts and RFCs", 718 draft-ietf-netmod-artwork-folding-01 (work in progress), 719 March 2019. 721 [RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 722 Classification", RFC 8199, DOI 10.17487/RFC8199, July 723 2017, . 725 Authors' Addresses 727 Robert Wilton 728 Cisco Systems, Inc. 730 Email: rwilton@cisco.com 732 Reshad Rahman 733 Cisco Systems, Inc. 735 Email: rrahman@cisco.com