idnits 2.17.1 draft-ietf-netmod-yang-solutions-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 (March 17, 2020) is 1494 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-netmod-yang-versioning-reqs-02 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 R. Wilton, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Informational March 17, 2020 5 Expires: September 18, 2020 7 YANG Versioning Solution Overview 8 draft-ietf-netmod-yang-solutions-00 10 Abstract 12 This document gives an overview of the different documents that 13 comprise a full solution to the YANG versioning requirements 14 document. The purpose of this document is to help readers understand 15 how the discrete parts of the YANG versioning solution fit together 16 during working group development of the solution documents. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 18, 2020. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Solution Documents . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Updated YANG Module Revision Handling . . . . . . . . . . 3 55 2.2. YANG Semantic Versioning . . . . . . . . . . . . . . . . 4 56 2.3. Versioned YANG packages . . . . . . . . . . . . . . . . . 4 57 2.4. Dynamic YANG schema selection . . . . . . . . . . . . . . 5 58 2.5. YANG Schema Comparison . . . . . . . . . . . . . . . . . 6 59 3. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 64 6.2. Informative References . . . . . . . . . . . . . . . . . 8 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 67 1. Introduction 69 [I-D.ietf-netmod-yang-versioning-reqs] documents the requirements for 70 any solution to the YANG [RFC7950] versioning problem. In 71 particular, chapter 5 lists the formal requirements that a solution 72 requires. 74 The complete solution to all of the YANG versioning requirements is 75 comprised of five documents, each addressing different aspects of the 76 solution. These documents are: 78 1. [I-D.verdt-netmod-yang-module-versioning] 80 2. [I-D.verdt-netmod-yang-semver] 82 3. [I-D.rwilton-netmod-yang-packages] 84 4. [I-D.wilton-netmod-yang-ver-selection] 86 5. [I-D.verdt-netmod-yang-schema-comparison] 88 The aim of this document is to help readers understand how these 89 different solution documents fit together, and also which documents 90 contribute solutions that address particular individual requirements. 92 Open issues, across all of the solution documents are tracked at 93 . 95 2. Solution Documents 97 2.1. Updated YANG Module Revision Handling 99 In summary, [I-D.verdt-netmod-yang-module-versioning] specifies 100 minimal extensions and updates to the YANG language, YANG Library, 101 and YANG author guidelines to provide more flexible YANG module 102 revision handling. The intent is that these changes and extensions 103 could be folded into future revisions of the updated specifications. 104 The document provides a base solution for all requirements except Req 105 2.2, Req 3.1 and Req 3.2. 107 The extensions and changes in the document can be summarized thus: 109 o It defines a YANG extension statement to indicate where non- 110 backwards-compatible changes have occurred in a module's revision 111 history. 113 o It relaxes the rules for the module revision history to allow for 114 a non-linear module revision history. I.e., any given module 115 revision may have multiple revisions directly derived from it. 117 o It defines a new import extension statement that restricts the 118 allowed module revisions that satisfy the import to only those 119 derived from a specified module revision. 121 o It defines a revision label extension statement to allow an 122 informative name to be associated with a particular revision date, 123 and to be used in import statements, YANG module filenames, and is 124 available in YANG library. One example of how the revision label 125 could be used is to associate a semantic versioning scheme to YANG 126 module revisions. 128 o It updates the YANG rules for changes between module revisions 129 that are allowed to be classified as backwards-compatible. In 130 particular, marking a node as obsolete is no longer classified as 131 a backwards compatible change. 133 o It provides updated guidance on how servers handle deprecated and 134 obsolete YANG nodes and augments YANG library with additional 135 leaves to report the server's behavior to clients. 137 o It provides an extension statement to allow a description 138 statement to be associated with a YANG status statement, providing 139 more information about why the status has changed. 141 o It defines how versioning relates to YANG instance data. 143 o It refines the guidelines for updating modules, taking into 144 consideration that non-backwards-compatible changes are sometimes 145 necessary for various pragmatic reasons. 147 2.2. YANG Semantic Versioning 149 [I-D.verdt-netmod-yang-semver] defines a semantic versioning scheme, 150 derived from the semver.org 2.0.0 specification, that can be used in 151 conjunction with the revision label extension statement defined in 152 Section 2.1 to allow semantic version numbers to be used to manage 153 the revision lifecycle of YANG modules and other related YANG assets, 154 e.g., YANG packages. This document provides an enhanced solution for 155 Req 2.1, but organizations authoring modules are not obliged to use 156 this specific versioning scheme, and could choose a different 157 overlaid versioning scheme, or none at all and rely solely on 158 revision dates. 160 The aims of the YANG semantic versioning scheme are: 162 o to generally allow clients to determine whether NBC changes have 163 occurred between two revisions from the version number alone, 164 without having to check the full revision history; 166 o to give a more informative identifier for a branched revision 167 history over revision dates alone; 169 o to allow revision branches that contain fixes for published non- 170 latest releases. 172 2.3. Versioned YANG packages 174 The two previous solution documents primarily address version and 175 revision management of individual modules. 176 [I-D.rwilton-netmod-yang-packages] provides a mechanism to group sets 177 of related YANG modules revisions together, into constructs called 178 YANG packages, and to apply a versioning scheme to the groups. 180 The core part of this document are YANG module definitions that 181 define a YANG package. The definitions are used as an augmentation 182 to YANG library and also in YANG instance data documents for offline 183 access. 185 The principle aims of YANG packages are: 187 To define an efficient hierarchical structure that can precisely 188 specify a YANG schema. 190 To provide an simple alternative mechanism to manage conformance 191 of modules. Rather than checking conformance against a set of 192 individual YANG module revisions and enabled features, it should 193 be easier to check for conformance against a much smaller set of 194 YANG package versions. 196 To provide a more efficient mechanism for servers to share 197 conformance information with clients. Rather that downloading and 198 comparing all individual module revisions and features via YANG 199 library, the client can just check whether the package version is 200 compatible instead. The package definition could be retrieved and 201 cached from multiple sources. 203 To define constructs that can be used for YANG schema selection. 205 Although the YANG packages document does not satisfy any versioning 206 requirements directly, it provides foundational building blocks for 207 the schema selection solution, described in Section 2.4, that does 208 address two of the requirements. 210 2.4. Dynamic YANG schema selection 212 [I-D.wilton-netmod-yang-ver-selection] specifies a solution for 213 requirements 3.1 and 3.2 via the use of 214 [I-D.rwilton-netmod-yang-packages] and a model and protocol based 215 schema selection scheme that can be used by clients to choose which 216 schemas to use when interacting with the device from the available 217 schema that are supported and advertised by the server. 219 The dynamic YANG schema selection solution: 221 allows servers to define named 'schema-sets' which specify the 222 schema for each supported datastore via references to YANG 223 packages; 225 can support clients choosing a single default schema-set (from 226 those advertised by the server) that is used for all NETCONF/ 227 RESTCONF protocol sessions; 229 can support clients enabling multiple compatible secondary schema- 230 sets that can be used on separate NETCONF/RESTCONF protocol 231 sessions; 233 can support clients configuring named custom schema-sets that can 234 be selected as default or secondary schema-sets; 236 can support different module versions via placing them in 237 different schema-sets; 238 can support different schema families (e.g., IETF YANG modules , 239 native vendor, or OpenConfig); 241 allows considerable freedom in the schema selection capabilities 242 that servers choose to support. 244 2.5. YANG Schema Comparison 246 The final piece of the solution jigsaw is a document that describes 247 how to algorithmically compare YANG schema, addressing Req 2.2. 249 [I-D.verdt-netmod-yang-schema-comparison] specifies an algorithm that 250 can be used to compare two revisions of a YANG schema to determine 251 the overall scope of the changes, and a list of the specific changes, 252 between the two revisions. 254 The YANG Schema Comparison solution: 256 defines a algorithm for comparing two YANG schema, identifying the 257 differences and classifying them as backwards-compatible, non- 258 backwards-compatible or editorial; 260 can be used to compare individual YANG module revisions; 262 can be used to compare YANG schema defined using YANG packages; 264 can filter the comparison output to the subset of the schema nodes 265 that are of interest, providing a more precise answer for clients 266 to determine whether they would likely be affected when upgrading 267 between two schema versions; 269 defines YANG extensions to improve the accuracy of the comparison 270 algorithm by explicitly annotating the type of change to 271 statements within a YANG module, for use where the type of change 272 would otherwise be ambiguous to a simple programmatic comparison 273 algorithm. 275 3. Contributors 277 This document grew out of the YANG module versioning design team that 278 started after IETF 101. The following individuals are (or have been) 279 members of that design team and have contributed to defining the 280 problem, specifying the requirements, and working on a solution: 282 o Balazs Lengyel 284 o Benoit Claise 285 o Ebben Aries 287 o Jason Sterne 289 o Joe Clarke 291 o Juergen Schoenwaelder 293 o Mahesh Jethanandani 295 o Michael (Wangzitao) 297 o Qin Wu 299 o Reshad Rahman 301 o Rob Wilton 303 o Susan Hares 305 o Wu Bo 307 4. Security Considerations 309 The document does not define any new protocol or data model. There 310 is no security impact. 312 5. IANA Considerations 314 None. 316 6. References 318 6.1. Normative References 320 [I-D.ietf-netmod-yang-versioning-reqs] 321 Clarke, J., "YANG Module Versioning Requirements", draft- 322 ietf-netmod-yang-versioning-reqs-02 (work in progress), 323 December 2019. 325 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 326 RFC 7950, DOI 10.17487/RFC7950, August 2016, 327 . 329 6.2. Informative References 331 [I-D.rwilton-netmod-yang-packages] 332 Wilton, R., Rahman, R., Clarke, J., Sterne, J., and W. Bo, 333 "YANG Packages", draft-rwilton-netmod-yang-packages-03 334 (work in progress), February 2020. 336 [I-D.verdt-netmod-yang-module-versioning] 337 Claise, B., Clarke, J., Rahman, R., Wilton, R., Lengyel, 338 B., Sterne, J., and K. D'Souza, "Updated YANG Module 339 Revision Handling", draft-verdt-netmod-yang-module- 340 versioning-01 (work in progress), October 2019. 342 [I-D.verdt-netmod-yang-schema-comparison] 343 Wilton, R., "YANG Schema Comparison", draft-verdt-netmod- 344 yang-schema-comparison-00 (work in progress), November 345 2019. 347 [I-D.verdt-netmod-yang-semver] 348 Claise, B., Clarke, J., Rahman, R., Wilton, R., Lengyel, 349 B., Sterne, J., and K. D'Souza, "YANG Semantic 350 Versioning", draft-verdt-netmod-yang-semver-01 (work in 351 progress), October 2019. 353 [I-D.wilton-netmod-yang-ver-selection] 354 Wilton, R., Rahman, R., Clarke, J., Sterne, J., and W. Bo, 355 "YANG Schema Selection", draft-wilton-netmod-yang-ver- 356 selection-02 (work in progress), February 2020. 358 Author's Address 360 Robert Wilton (editor) 361 Cisco Systems, Inc. 363 Email: rwilton@cisco.com