idnits 2.17.1 draft-openconfig-netmod-model-catalog-02.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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 331 has weird spacing: '...version oc-...' -- The document date (March 12, 2017) is 2602 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7895 (Obsoleted by RFC 8525) == Outdated reference: A later version (-08) exists of draft-ietf-netmod-yang-model-classification-04 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Shaikh 3 Internet-Draft R. Shakir 4 Intended status: Informational Google 5 Expires: September 13, 2017 K. D'Souza 6 AT&T 7 March 12, 2017 9 Catalog and registry for YANG models 10 draft-openconfig-netmod-model-catalog-02 12 Abstract 14 This document presents an approach for a YANG model catalog and 15 registry that allows users to find models relevant to their use cases 16 from the large and growing number of YANG modules being published. 17 The model catalog may also be used to define bundles of YANG modules 18 required to realize a particular service or function. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 13, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Model catalog and registry requirements . . . . . . . . . . . 3 56 3. Organizing YANG modules . . . . . . . . . . . . . . . . . . . 5 57 3.1. Module information . . . . . . . . . . . . . . . . . . . 5 58 4. Identifying interoperable models . . . . . . . . . . . . . . 7 59 4.1. Release bundle information . . . . . . . . . . . . . . . 7 60 5. Specifying functionality with feature bundles . . . . . . . . 8 61 5.1. Feature bundle information . . . . . . . . . . . . . . . 9 62 6. Module implementations . . . . . . . . . . . . . . . . . . . 10 63 6.1. Implementation information . . . . . . . . . . . . . . . 10 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 9. YANG modules . . . . . . . . . . . . . . . . . . . . . . . . 11 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 68 10.1. Normative references . . . . . . . . . . . . . . . . . . 38 69 10.2. Informative references . . . . . . . . . . . . . . . . . 38 70 Appendix A. Change summary . . . . . . . . . . . . . . . . . . . 39 71 A.1. Changes between revisions -01 and -02 . . . . . . . . . . 39 72 A.2. Changes between revisions -00 and -01 . . . . . . . . . . 39 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 75 1. Introduction 77 As YANG [RFC6020][RFC7950] adoption and usage grows, the number of 78 YANG models (and corresponding module and submodule files) published 79 is increasing rapidly. This growing collection of modules 80 potentially enables a large set of management use cases, but from a 81 user perspective, it is a daunting task to navigate the largely ad- 82 hoc landscape of models to determine their functionality, 83 compatibility, and available implementations. For example, the IETF 84 Routing Area Coordination page [RTG-AD-YANG] currently tracks over 85 150 YANG models related to layer 2 and layer 3 technologies. 87 YANG models are also being developed and published beyond the IETF, 88 for example by open source projects, other standards organizations, 89 and industry forums. These efforts are generally independent from 90 each other and sometimes result in overlapping models. While we 91 recognize that models may come from multiple sources, the current 92 approach of having a flat online listing of models is not sufficient 93 to help users find the models they need, along with the information 94 to retrieve and utilize the models in actual operational systems. 95 There is a need for a wider registry and catalog of available models 96 that provides a central reference for model consumers and developers. 98 The idea of a model catalog is inspired by service catalogs in 99 traditional IT environments. Service catalogs serve as software- 100 based registries of available services with information needed to 101 discover and invoke them. 103 In earlier proposals [I-D.openconfig-netmod-model-structure] we 104 motivated the need for a common structure that allows a set of models 105 to be used together coherently in order to manage, for example, a 106 complete network device. Other efforts have subsequently proposed 107 further options for modeling the complete device structure 108 [I-D.rtgyangdt-rtgwg-device-model]. We also briefly described the 109 notion of a model catalog to provide a structured view of all of the 110 models available from different organizations. In this document, we 111 further elaborate on some of the details and use cases for a model 112 catalog and registry. 114 There are recent proposals that address related issues in terms of 115 understanding the set of YANG models available on a device [RFC7895], 116 and how to classify models based on their role in describing a multi- 117 layer service [I-D.ietf-netmod-yang-model-classification]. The 118 latter, in particular, describes a taxonomy for classifying YANG 119 models that could also be used in the model catalog, though it does 120 not address the problem of expressing model functionality, which is a 121 key requirement. 123 2. Model catalog and registry requirements 125 At a high level, the model catalog must provide enough information 126 for users to determine which YANG modules or module bundles are 127 available to describe a specific service or technology, and 128 attributes of those modules that would help the user select the best 129 model for their scenario. While this draft does not specifically 130 address selection criteria -- they would be specific to each user -- 131 some examples include: 133 o model maturity, including availability of server implementations 134 (e.g., native device support) 136 o availablility of co-requisite models, and complexity of the model 137 dependencies 139 o identity and reputation of the entity or organization publishing 140 the model 142 The model catalog should, therefore, include key information about 143 YANG modules, including: 145 o organization responsible for publishing and maintaining the module 146 with contact information; organizations may include standards 147 bodies (SDOs), industry forums, open source projects, individuals, 148 etc. 150 o classification of the module or model, which could be along 151 several axes, e.g., functional category, service vs. element 152 models, commercial vs. free-to-use, etc.; currently, identities 153 are available for the classifications defined in 154 [I-D.ietf-netmod-yang-model-classification] 156 o groupings of modules (and their versions) that are compatible with 157 each other, and together provide a defined set of functionality 159 o for open models, the license under which the model is distributed; 160 this is important if there are limitations on how the model may be 161 modified or redistributed 163 o module dependencies, e.g., a list of all of the YANG modules that 164 are required 166 o pointer to the YANG module, e.g., a machine-readable URI and 167 authentication information to allow users to verify that the model 168 they retrieve is authentic and unaltered 170 o implementation information, for example, a list of available 171 server implementations that support the module 173 Establishing a globally applicable classification scheme for models 174 is not straightforward -- each organization developing models likely 175 has its own taxonomy or organization strategy for YANG modules. This 176 is an area of the catalog that is likely to require extensibility and 177 customization, e.g., by letting each organization augment the schema 178 with its own categories. Similarly, users may want to define their 179 own classifications for use by internal systems. 181 The proposed catalog schema should be useful as a local database, 182 deployed by a single user, and also as a global registry that can be 183 used to discover available models. For example, the local catalog 184 could be used to define the approved set of models for use within an 185 organization, while the registry serves as a channel for all model 186 developers to make information about their models available. The 187 IETF XML Registry [RFC3688], maintained by IANA serves a similar 188 purpose for XML documents used in IETF protocols, but it is limited 189 to IETF-defined YANG models, is tied to XML encoded data, and has a 190 very limited schema. 192 The registry implementation could be as simple as a metadata database 193 that reflects the proposed catalog schema, along with means for 194 online access and viewing. A key requirement for the online registry 195 would be a robust query capability that allows users to search for 196 modules meeting a variety of selection criteria, along with an easy 197 way to retrieve modules (where applicable). 199 3. Organizing YANG modules 201 We propose a schema for the model catalog defined using YANG (see the 202 modules in Section 9). The YANG modules and groupings in the catalog 203 are organized at the top level by the publishing organization and its 204 associated contact information. The catalog structure is shown 205 below. 207 +--rw organizations 208 +--rw organization* [name] 209 +--rw name string 210 +--rw type? identityref 211 +--rw contact? string 212 +--rw modules 213 | ... 214 +--rw release-bundles 215 | ... 216 +--rw feature-bundles 217 | ... 218 +--rw implementations 219 ... 221 In this model, each organization publishes a list of available 222 modules, each module having associated data describing its version, 223 dependencies, and other basic metadata. Organizations may also 224 publish release bundles, which are groupings of compatible modules, 225 or feature bundles, which describes specific functionality. 227 3.1. Module information 229 Each module has several types of information associated with it. 230 These are described below (only node names are shown). 232 +--rw modules 233 +--rw module* [name version] 234 +--rw name 235 +--rw version 236 +--rw namespace? 237 +--rw prefix? 238 +--rw revision? 239 +--rw summary? 240 +--rw classification 241 | +--rw category? 242 | +--rw subcategory? 243 | +--rw deployment-status? 244 +--rw dependencies 245 | +--rw required-module* 246 +--rw access 247 | +--rw uri? 248 | +--rw md5-hash? 249 +--rw submodules 250 +--rw submodule* [name] 251 +--rw name 252 +--rw access 253 +--rw uri? 254 +--rw md5-hash? 256 The basic information includes module metadata, such as its version 257 which may be different from the YANG revision statement as in 258 [OC-SEMVER]. Other common information includes the module's prefix, 259 namespace, and a summary of its functionality. 261 The classification data includes some base information but leaves the 262 taxonomy largely to model publishers. The category and subcategory 263 leaves are identities that are expected to be augmented with 264 additional values. The current version includes classification 265 categories defined in [I-D.ietf-netmod-yang-model-classification]. 266 The classification also includes a status to indicate the development 267 or deployment status of the module, e.g., whether it is purely 268 experimental, or mature enough for production use. 270 Module dependencies are represented as a simple list of references to 271 co-requisite modules indicated by 'import' statements in the module. 272 Only the first-level dependencies are included in the list. That is, 273 each of the listed dependences can be examined in turn to determine 274 its dependencies. 276 The access data contains information required to retrieve and 277 validate the module. Specifically, it includes a URI that can be 278 used to download modules directly. It also includes a simple MD5 279 checksum to allow checking the data integrity of the module. Further 280 data for verifying authenticity and origin of the module may be added 281 in future versions of the catalog. 283 For YANG modules that are composed of submodules, the submodules 284 container provides their names and access information. Note that the 285 submodules are an integral part of their parent modules, and hence 286 are listed together with their parent and corresponding version. 288 4. Identifying interoperable models 290 YANG models for configuration and operational state data are under 291 active development and still maturing, especially with regard to 292 their use in production networks. As models (and their corresponding 293 YANG modules) evolve and are revised, there is a significant 294 challenge for users to identify the set of models that are known, or 295 designed, to work together. This is made more complicated by the 296 fact that models are being sourced by different organizations which 297 may use different modeling conventions. Since there are often cross- 298 dependencies between modules (e.g., interface configuration and 299 various routing protocols), it is critical that users understand 300 which modules can be used together. 302 The model catalog defines the notion of "release" bundles which 303 provide a grouping of YANG modules that are part of a cohesive 304 release. For example, a release bundle can be defined at a granular 305 level to collect all of the modules related to interface 306 configuration that are known to work together. These bundles can be 307 further grouped into larger releases of models that interoperate, 308 e.g., a release containing interoperable routing, interface, and 309 policy-related modules. 311 Release bundles are also useful for implementors to know which 312 dependencies must have what versions in order to work with a given 313 module. For example, when an implementor wishes to support a new 314 version of a module, the release bundle provides information about 315 what other modules need to be upgraded in order to be compatible. It 316 is expected that the publisher of the bundle ensures version 317 compatibility of the release, although release bundles and the 318 modules they include do not necessarily need to be from the same 319 organization. We expect, however, that users and publishers of 320 modules would be the primary source of release bundle definitions, 321 and vendors and implementors would be the primary consumers. 323 4.1. Release bundle information 325 The schema for release bundles is shown below (only node names are 326 shown). 328 +--rw release-bundles 329 +--rw release-bundle* [name version] 330 +--rw name string 331 +--rw version oc-cat-types:module-version-type 332 +--rw members 333 +--rw member* [id] 334 +--rw id 335 +--rw type? 336 +--rw module? 337 +--rw release-bundle? 338 +--rw publisher? 339 +--rw compatible-versions* 341 The release bundle has a name and version assigned to the bundle 342 itself, and a list of members that are part of the bundle. The list 343 may include a reference to a module or another bundle. The 344 compatible-versions list indicate which semantic versions [OC-SEMVER] 345 of the respective module or bundle are known to work together. 347 5. Specifying functionality with feature bundles 349 From an operational perspective, the utility of a single module is 350 quite limited. Most, if not all, use cases require multiple modules 351 that work together coherently. Managing a network device typically 352 requires configuration and operational state models for device-wide 353 services, network protocols, virtual instances, etc. Network 354 services, such as those delivered by many service providers, require 355 not only infrastructure-level management models, such as devices and 356 protocols, but also service-level models that describe service 357 parameters. 359 The model catalog and registry provides a common way to define 360 feature bundles that describe the set of schema paths required to 361 realize a feature or service. The feature bundle paths are specified 362 against a release bundle that ensures the paths are drawn from a set 363 of compatible modules and/or bundles. 365 Feature bundles are useful for defining specific sets of 366 functionality that can be further composed to build higher level 367 features or services. For example, a Layer 3 VPN bundle could be 368 composed of more specific features such as interfaces, routing, 369 policy, and QoS. Note these bundle definitions complement the 370 configuration models for such services, which may focus on providing 371 an abstracted set of configuration or operational state variables. 372 These variables would then be mapped onto device level variables. 374 Feature bundle definitions can also be used by organizations to 375 identify a canonical set of modules that should be used to build a 376 particular service. Users within the organization can be assured 377 that the corresponding bundles are known and approved to work 378 together to support the desired service. 380 Finally, a key use case for feature bundles is to define specific 381 units of compliance for an implementation. Users can define a 382 feature bundle containing only those paths that are required for a 383 given usage, allowing an implementor or vendor to focus their 384 implementation and testing on those paths rather than having to 385 implement the entire contents of a module or bundle. The implementor 386 may also wish to publish a deviation module that indicates which 387 paths are not supported. 389 5.1. Feature bundle information 391 The schema for feature bundles in the catalog is shown below (note 392 only node names are shown). 394 +--rw feature-bundles 395 +--rw feature-bundle* [name version] 396 +--rw name 397 +--rw version 398 +--rw path* 399 +--rw release-bundle 400 | +--rw name? 401 | +--rw publisher? 402 | +--rw version? 403 +--rw feature-bundles 404 +--rw feature-bundle* [name] 405 +--rw name 406 +--rw publisher? 407 +--rw version? 409 Each feature bundle includes basic information such as the name of 410 the feature or service, the bundle version, and the set of specific 411 schema paths. The schema paths are based on the release bundle 412 specified as part of the feature bundle. For simplicity, only one 413 release bundle may be specified. If the schema paths in a feature 414 bundle cross release bundle boundaries, a new release bundle should 415 be created to include all of the paths needed by the feature bundle. 416 The feature bundle may itself be composed of more granular feature 417 bundles. This allows the definition of "base" features that can be 418 reused across feature bundles. 420 6. Module implementations 422 Model implementors can use the catalog to indicate the data models 423 they support using the implementation container. An implementation 424 is expected to indicate a set of feature bundles it supports. The 425 feature bundles may be defined by a user (i.e., a set of compliance 426 units), or by the implementor or vendor to indicate the full list of 427 what is supported. 429 6.1. Implementation information 431 The implementation information in the catalog is shown below (only 432 node names are shown): 434 +--rw implementations 435 +--rw implementation* [id] 436 +--rw id 437 +--rw description? 438 +--rw reference? 439 +--rw platform? 440 +--rw platform-version? 441 +--rw status? 442 +--rw feature-bundles 443 +--rw feature-bundle* [name version] 444 +--rw name 445 +--rw publisher? 446 +--rw version 448 The implementation container provides information about the platform 449 and version on which the feature bundles are supported, as well as 450 the status of the implementation. It also includes a URI reference 451 to retrieve artifacts or further information on the implementation. 452 The list of supported feature bundles are references to defined 453 feature bundles in the catalog. 455 7. Security Considerations 457 The model catalog and registry described in this document do not 458 define actual configuration and state data, hence are not directly 459 responsible for security risks. 461 However, since the model catalog is intended to be an authoritative 462 and authenticated database of published modules, there are security 463 considerations in securing the catalog (both contents and access), 464 and also in authenticating organizations that deposit data into the 465 catalog. 467 8. IANA Considerations 469 The YANG model catalog is intended to complement the IANA XML 470 Registry. YANG modules defined in this document may be entered in 471 the XML registry if they are placed or redirected for the standards 472 track, with an appropriate namespace URI. 474 9. YANG modules 476 The main model catalog and associated types modules are listed below. 478 file "openconfig-catalog-types.yang" 480 module openconfig-catalog-types { 482 yang-version "1"; 484 // namespace 485 namespace "http://openconfig.net/yang/catalog-types"; 487 prefix "oc-cat-types"; 489 import openconfig-extensions { prefix oc-ext; } 491 // meta 492 organization "OpenConfig working group"; 494 contact 495 "OpenConfig working group 496 www.openconfig.net"; 498 description 499 "This module defines types and identities used by the OpenConfig 500 YANG module catalog model."; 502 oc-ext:openconfig-version "0.2.0"; 504 revision "2017-03-08" { 505 description 506 "OpenConfig public release"; 507 reference "0.2.0"; 508 } 510 revision "2016-02-15" { 511 description 512 "Initial OpenConfig public release"; 513 reference "0.1.0"; 515 } 517 revision "2015-10-18" { 518 description 519 "Initial revision"; 520 reference "TBD"; 521 } 523 // extension statements 525 // feature statements 527 // identity statements 529 identity CATALOG_MEMBER_TYPE { 530 description 531 "Base identity for elements in the catalog"; 532 } 534 identity MODULE { 535 base CATALOG_MEMBER_TYPE; 536 description 537 "Module elements in the catalog"; 538 } 540 identity RELEASE_BUNDLE { 541 base CATALOG_MEMBER_TYPE; 542 description 543 "Release bundle elements in the catalog"; 544 } 546 identity FEATURE_BUNDLE { 547 base CATALOG_MEMBER_TYPE; 548 description 549 "Feature bundle elements in the catalog"; 550 } 552 identity IMPLEMENTATION_STATUS_TYPE { 553 description 554 "Indications of the status of a module's implementation on a 555 device or server"; 556 } 558 identity IN_PROGRESS { 559 base IMPLEMENTATION_STATUS_TYPE; 560 description 561 "Implementation is in progress"; 563 } 565 identity PLANNED { 566 base IMPLEMENTATION_STATUS_TYPE; 567 description 568 "Implementation is planned"; 569 } 571 identity COMPLETE { 572 base IMPLEMENTATION_STATUS_TYPE; 573 description 574 "Implementation is complete and fully supports the model"; 575 } 577 identity PARTIAL { 578 base IMPLEMENTATION_STATUS_TYPE; 579 description 580 "Implementation is complete, but only supports the model 581 partially"; 582 } 584 identity MODULE_STATUS_TYPE { 585 description 586 "Indicates the deployment status of the module"; 587 } 589 identity EXPERIMENTAL { 590 base MODULE_STATUS_TYPE; 591 description 592 "Module should be considered experimental, not deployed in 593 production settings"; 594 } 596 identity PRODUCTION { 597 base MODULE_STATUS_TYPE; 598 description 599 "Module is suitable for use in production, or has been 600 deployed in production"; 601 } 603 identity MODULE_CATEGORY_BASE { 604 description 605 "Base identity for the module category. It is expected that 606 publishing organizations will define additional derived 607 identities to describe their categorization scheme."; 608 } 610 identity MODULE_SUBCATEGORY_BASE { 611 description 612 "Base identity for the module subcategory. It is expected that 613 publishing organizations will define additional derived 614 identities to describe their categorization scheme."; 615 } 617 identity ORGANIZATION_TYPE { 618 description 619 "Publishing organization type for the set of modules"; 620 } 622 identity STANDARDS { 623 base ORGANIZATION_TYPE; 624 description 625 "Standards development organization (SDO) publisher type"; 626 } 628 identity INDUSTRY { 629 base ORGANIZATION_TYPE; 630 description 631 "Industry forum or other industry group"; 632 } 634 identity COMMERCIAL { 635 base ORGANIZATION_TYPE; 636 description 637 "Commercial entity, company, etc."; 638 } 640 identity INDIVIDUAL { 641 base ORGANIZATION_TYPE; 642 description 643 "For modules published by an individual"; 644 } 646 identity IETF_MODEL_LAYER { 647 base MODULE_CATEGORY_BASE; 648 description 649 "Describes layering of models based on their abstraction 650 level as defined by IETF model classification proposals"; 651 reference 652 "IETF draft-ietf-netmod-yang-model-classification"; 653 } 655 identity IETF_MODEL_TYPE { 656 base MODULE_SUBCATEGORY_BASE; 657 description 658 "IETF proposed classification dimension of YANG model types as 660 standard YANG models, vendor-specific, or user-specific YANG 661 models and extensions"; 662 reference 663 "IETF draft-ietf-netmod-yang-model-classification"; 664 } 666 identity IETF_NETWORK_SERVICE { 667 base IETF_MODEL_LAYER; 668 description 669 "Service-layer model as defined by IETF classification 670 proposal"; 671 } 673 identity IETF_NETWORK_ELEMENT { 674 base IETF_MODEL_LAYER; 675 description 676 "Network element-layer model as defined by IETF classification 677 proposal"; 678 } 680 identity IETF_TYPE_STANDARD { 681 base IETF_MODEL_TYPE; 682 description 683 "Models published by standards-defining organizations (SDOs)"; 684 } 686 identity IETF_TYPE_VENDOR { 687 base IETF_MODEL_TYPE; 688 description 689 "Developed by organizations (e.g., vendors) with the intent 690 to support a specific set of implementations under control of 691 that organization"; 692 } 694 identity IETF_TYPE_USER { 695 base IETF_MODEL_TYPE; 696 description 697 "Developed by organizations that operate YANG-based 698 infrastructure including devices and orchestrators. 699 The intent of these models is to express the specific needs 700 for a certain implementation, above and beyond what is provided 701 by vendors"; 702 } 704 typedef module-version-type { 705 type string; 706 description 707 "This type defines acceptable formats for the version of a 708 module. The version may be a semantic version, or a YANG 709 revision statement date, and may include wildcards when 710 included in a bundle compatibility list, e.g.: 712 semver format: .. 713 examples: 0.1.0, 2.1.0, 1.1.*, 2.*.* 715 revision format: YYYY-MM-DD 716 example: 2016-11-31"; 717 } 719 } 721 723 file "openconfig-module-catalog.yang" 725 module openconfig-module-catalog { 727 yang-version "1"; 729 // namespace 730 namespace "http://openconfig.net/yang/module-catalog"; 732 prefix "oc-cat"; 734 // import some basic types 735 import openconfig-inet-types { prefix oc-inet; } 736 import openconfig-catalog-types { prefix oc-cat-types; } 737 import openconfig-extensions { prefix oc-ext; } 739 // meta 740 organization "OpenConfig working group"; 742 contact 743 "OpenConfig working group 744 www.openconfig.net"; 746 description 747 "This module provides a schema for cataloging and descrbing 748 YANG models published across various organizations. The catalog 749 contains several categories of data: 751 * organizations -- entities that publish and/or maintain 752 individual YANG modules or groups of modules 754 * modules -- information regarding individual YANG modules, 755 including their versions, dependencies, submodules, and how 756 to access them 758 * release bundles -- groups of modules that are compatible and 759 consistent with each other (as determined by the publisher of 760 of the bundle). The release bundle does not necessarily 761 correspond to a functional area, e.g., it could the entire 762 set of modules published by an organization 764 * feature bundles -- sets of schema paths across a 765 release bundle that provide a specific set of functionality 767 * implementations -- information about available module and/or 768 bundle implementations and their status"; 770 oc-ext:openconfig-version "0.2.0"; 772 revision "2017-03-08" { 773 description 774 "OpenConfig public release"; 775 reference "0.2.0"; 776 } 778 revision "2016-02-15" { 779 description 780 "Initial OpenConfig public release"; 781 reference "0.1.0"; 782 } 784 revision "2015-10-18" { 785 description 786 "Initial revision"; 787 reference "TBD"; 788 } 790 // grouping statements 792 grouping catalog-module-common-config { 793 description 794 "Data definitions common for both bundles and standalone 795 modules"; 797 leaf name { 798 type string; 799 description 800 "The name of the module or bundle. For modules, this 801 should reflect the 'module' or 'submodule' 802 statement in the YANG module file. 804 For bundles, this is the canonical name for the overall 805 bundle of modules which is to be released together. 806 This name should be consistent over multiple 807 releases"; 808 } 810 leaf version { 811 type oc-cat-types:module-version-type; 812 description 813 "For individual modules, this is the version number, e.g., 814 a semantic version. The version may be the same as the date 815 indicated in the module revision statement. 817 For bundles, this is a semantic version number for the 818 overall bundle. This version is to be defined as per the 819 approach specified in the OpenConfig semantic version 820 guidance - and is of the form x.y.z, where x is the major 821 version, y is the minor version, and z is the patch level"; 822 reference 823 "Semantic versioning for OpenConfig models"; 824 } 825 } 827 grouping feature-bundle-included-reference { 828 description 829 "References to the included feature bundles"; 831 leaf name { 832 type leafref { 833 path "../../../../../../../organizations/" + 834 "organization[name=current()/../publisher]/" + 835 "feature-bundles/feature-bundle/name"; 836 } 837 description 838 "Name of the referenced feature bundle"; 839 } 841 leaf publisher { 842 type leafref { 843 path "../../../../../../../organizations/organization/" + 844 "name"; 845 } 846 description 847 "Publisher of the referenced feature bundle"; 848 } 850 leaf version { 851 type oc-cat-types:module-version-type; 852 description 853 "Version of the referenced feature bundle"; 854 } 855 } 857 grouping catalog-implementation-bundle-config { 858 description 859 "References to the feature bundles supported by an 860 implementation"; 862 uses feature-bundle-included-reference; 863 } 865 grouping catalog-implementation-bundle-top { 866 description 867 "Top-level grouping for the list of feature bundles 868 supported by an implementation"; 870 container feature-bundles { 871 description 872 "Enclosing container for the list of feature bundles"; 874 list feature-bundle { 875 key "name version"; 876 description 877 "List of feature bundles supported by the implementation"; 879 uses catalog-implementation-bundle-config; 880 } 881 } 882 } 884 grouping catalog-implementation-config { 885 description 886 "Data describing any available implementations"; 888 leaf id { 889 type string; 890 description 891 "An identifier for the implementation, provided by the 892 implementor. This id should uniquely identify a specific 893 implementation of the module, e.g., based on the vendor, 894 platform, and platform version."; 896 } 898 leaf description { 899 type string; 900 description 901 "A text summary of important information about the 902 implementation"; 903 } 905 leaf reference { 906 type union { 907 type oc-inet:uri; 908 type string; 909 } 910 description 911 "A URI (preferred) or text reference to more detailed 912 information about the implementation."; 913 } 915 leaf platform { 916 type string; 917 description 918 "Name of the platform on which the implementation 919 is available -- this could be the model name of a network 920 device, a server OS, etc."; 921 } 923 leaf platform-version { 924 type string; 925 description 926 "Implementor-defined version name or number of the 927 module implementation, corresponding to the platform. 928 This could be the firmware version of a network device 929 such as a router, OS version, or other server platform 930 version."; 931 } 933 leaf status { 934 type identityref { 935 base oc-cat-types:IMPLEMENTATION_STATUS_TYPE; 936 } 937 description 938 "Indicates the status of the implementation, e.g., 939 complete, partial, in-progress, etc. Implementors 940 may define additional values for the base identity"; 941 } 942 } 943 grouping catalog-implementation-top { 944 description 945 "Top level grouping for information on model implementations"; 947 container implementations { 948 description 949 "Container for module implementation information"; 951 list implementation { 952 key "id"; 953 description 954 "List of available implementations, keyed by an identifier 955 provided by either the implementor or the module 956 maintainer. Such a key avoids needing a complex composite 957 key to uniquely identify an implementation."; 959 uses catalog-implementation-config; 960 uses catalog-implementation-bundle-top; 961 } 962 } 963 } 965 grouping catalog-module-dependency-config { 966 description 967 "Information about module dependencies"; 969 leaf-list required-module { 970 type leafref { 971 path "../../name"; 972 } 973 description 974 "List of references to modules that are imported by the 975 current module. This list should reflect all of the 'import' 976 statements in the module."; 977 } 978 } 980 grouping catalog-module-dependency-top { 981 description 982 "Top-level grouping for module dependency data"; 984 container dependencies { 985 description 986 "Data about dependencies of the module"; 988 uses catalog-module-dependency-config; 989 } 991 } 993 grouping catalog-module-classification-config { 994 description 995 "Data describing the module's classification(s)"; 997 leaf category { 998 type identityref { 999 base oc-cat-types:MODULE_CATEGORY_BASE; 1000 } 1001 description 1002 "Categorization of the module based on identities defined 1003 or used by the publishing organizations."; 1004 } 1006 leaf subcategory { 1007 type identityref { 1008 base oc-cat-types:MODULE_SUBCATEGORY_BASE; 1009 } 1010 description 1011 "Sub-categorization of the module based on identities 1012 defined or used by the publishing organizations."; 1013 } 1015 leaf deployment-status { 1016 type identityref { 1017 base oc-cat-types:MODULE_STATUS_TYPE; 1018 } 1019 description 1020 "Deployment status of the module -- experimental, 1021 standards-track, production, etc."; 1022 } 1023 } 1025 grouping catalog-module-classification-top { 1026 description 1027 "Data definitions related to module classfications"; 1029 container classification { 1030 description 1031 "Container for data describing the module's classification"; 1033 uses catalog-module-classification-config; 1034 } 1035 } 1037 grouping catalog-module-access-config { 1038 description 1039 "Data pertaining to retrieval and usage of the module"; 1041 leaf uri { 1042 type oc-inet:uri; 1043 description 1044 "URI where module can be downloaded. Modules may be 1045 made available from the catalog maintainer, or directly 1046 from the publisher"; 1047 } 1049 leaf md5-hash { 1050 type string; 1051 description 1052 "Optional MD5 hash of the module file. If specified, the 1053 hash may be used by users to validate data integrity"; 1054 } 1055 } 1057 grouping catalog-module-access-top { 1058 description 1059 "Top level groupig for data related to accessing a module 1060 or submodule"; 1062 container access { 1063 description 1064 "Container for data pertaining to retrieval and usage of the 1065 module"; 1067 uses catalog-module-access-config; 1068 } 1069 } 1071 grouping catalog-module-submodule-config { 1072 description 1073 "Data definitions for submodules belonging to a 1074 module"; 1076 leaf name { 1077 type string; 1078 description 1079 "Name of the submodule as indicated by its top-level 1080 'submodule' statement"; 1081 } 1083 } 1085 grouping catalog-module-submodule-top { 1086 description 1087 "Top-level grouping for submodule information"; 1089 container submodules { 1090 description 1091 "Data for the submodules belonging to a submodule. If the 1092 module does not have any submodules, this container 1093 should be empty."; 1095 list submodule { 1096 key "name"; 1097 description 1098 "List of submodules included by a module. All submodules 1099 specified by 'include' statements in the module should be 1100 included in this list."; 1102 uses catalog-module-submodule-config; 1103 uses catalog-module-access-top; 1104 } 1105 } 1106 } 1108 grouping catalog-module-base-config { 1109 description 1110 "Basic information describing the module, e.g., the 1111 YANG metadata in the module preface."; 1113 leaf namespace { 1114 type string; 1115 description 1116 "Published namespace of module, i.e., defined by the 1117 'namespace' "; 1118 } 1120 leaf prefix { 1121 type string; 1122 description 1123 "Published prefix of the module"; 1124 } 1126 leaf revision { 1127 type string; 1128 description 1129 "Date in the revision statement of the module"; 1130 } 1132 leaf summary { 1133 type string; 1134 description 1135 "Summary description of the module"; 1136 } 1137 } 1139 grouping release-bundle-member-config { 1140 description 1141 "Data for each member of a bundle"; 1143 leaf id { 1144 type string; 1145 description 1146 "Identifier for the bundle member"; 1147 } 1149 leaf type { 1150 type identityref { 1151 base oc-cat-types:CATALOG_MEMBER_TYPE; 1152 } 1153 description 1154 "The type of member that is to be included within the 1155 release bundle. Release bundles may include modules and 1156 other release bundles. Both member modules and member 1157 bundles should specify the list of compatible versions."; 1158 } 1160 leaf module { 1161 when "../type = 'oc-cat-types:MODULE'" { 1162 description 1163 "The module name is specified for bundle membrs that are 1164 modules"; 1165 } 1166 type leafref { 1167 path "../../../../../../../organizations/" + 1168 "organization[name=current()/../publisher]/modules/" + 1169 "module/name"; 1170 } 1171 description 1172 "Name of the module set which is included in this bundle - 1173 for example, 'openconfig-bgp'"; 1174 } 1176 leaf release-bundle { 1177 when "../type = 'oc-cat-types:RELEASE_BUNDLE'" { 1178 description 1179 "The release bundle is specified for bundle members that 1180 are release bundles"; 1181 } 1182 type leafref { 1183 path "../../../../../../../organizations/" + 1184 "organization[name=current()/../publisher]/" + 1185 "release-bundles/release-bundle/name"; 1186 } 1187 description 1188 "Name of the module set which is included in this bundle - 1189 for example, 'openconfig-bgp'"; 1190 } 1192 leaf publisher { 1193 type leafref { 1194 path "../../../../../../../organizations/organization/" + 1195 "name"; 1196 } 1197 description 1198 "Reference to the name of the publishing organization"; 1199 } 1201 leaf-list compatible-versions { 1202 type oc-cat-types:module-version-type; 1203 description 1204 "A list of semantic version specification of the versions 1205 of the specified module or release bundle which are 1206 compatible when building this version of the bundle. 1208 Version specifications may be added when changes are made 1209 to a module within a bundle, and this does not affect the 1210 interaction between it and other modules. It is expected 1211 that backwards compatible changes to an individual module or 1212 member bundle do not affect the compatibility of that 1213 with other members, and hence wildcard matches are allowed 1214 within this list."; 1215 } 1216 } 1218 grouping release-bundle-member-top { 1220 description 1221 "Parameters relating to models within release bundles"; 1223 container members { 1224 description 1225 "List of bundle members which make up this release bundle. A 1226 member is defined as an individual YANG module specified 1227 in the YANG catalogue, or another release 1228 bundle which can be used to group multiple YANG 1229 models together."; 1231 list member { 1232 key "id"; 1233 description 1234 "A set of modules or bundles which are part of the bundle 1235 of models. For example, if 'ietf-yang-types' were to be 1236 specified within the bundle, then this would refer to the 1237 individual entry within the module catalogue. If the type 1238 of the entry is set to bundle, then for example, 1239 openconfig-bgp could be referenced - which itself consists 1240 of separate modules."; 1242 uses release-bundle-member-config; 1244 } 1245 } 1246 } 1248 grouping release-bundle-top { 1249 description 1250 "Top-level container for a release bundle"; 1252 container release-bundles { 1253 description 1254 "List of release bundles"; 1256 list release-bundle { 1257 key "name version"; 1259 description 1260 "List of release bundles - sets of modules and/or 1261 bundles which are interoperable"; 1263 uses catalog-module-common-config; 1264 uses release-bundle-member-top; 1265 } 1266 } 1267 } 1269 grouping feature-bundle-release-config { 1270 description 1271 "Data definitions to identify the release bundle that the 1272 feature bundle is based on."; 1274 leaf name { 1275 type leafref { 1276 path "../../../../release-bundles/release-bundle/name"; 1277 } 1278 description 1279 "Reference to the name of the release bundle used for the 1280 feature paths."; 1281 } 1283 leaf version { 1284 type leafref { 1285 path "../../../../release-bundles/" + 1286 "release-bundle[name=current()/../name]/version"; 1287 } 1288 description 1289 "Reference to the release bundle version used for the 1290 feature paths"; 1291 } 1293 leaf publisher { 1294 type leafref { 1295 path "../../../../release-bundles/" + 1296 "release-bundle[name=current()/../name]/publisher"; 1297 } 1298 description 1299 "Reference to the publisher of the release bundle used for 1300 the feature paths"; 1301 } 1302 } 1304 grouping feature-bundle-release-top { 1305 description 1306 "Top-level grouping for data about the release bundle used 1307 to specify the feature bundle"; 1309 container release-bundle { 1310 description 1311 "Data to identify the release bundle from which the feature 1312 paths should be specified. If the feature crosses 1313 release bundles, a new release bundle should be 1314 created to support the feature bundle."; 1316 leaf name { 1317 type leafref { 1318 path "../../../../../../organizations/" + 1319 "organization[name=current()/../publisher]/" + 1320 "release-bundles/release-bundle/name"; 1321 } 1322 description 1323 "Name of the module set which is included in this bundle - 1324 for example, 'openconfig-bgp'"; 1325 } 1326 leaf publisher { 1327 type leafref { 1328 path "../../../../../../organizations/organization/" + 1329 "name"; 1330 } 1331 description 1332 "Reference to the name of the publishing organization"; 1333 } 1335 leaf version { 1336 type oc-cat-types:module-version-type; 1337 description 1338 "Version of the referenced release bundle"; 1339 } 1340 } 1341 } 1343 grouping feature-bundle-config { 1344 description 1345 "Data definitions for the feature bundle"; 1347 uses catalog-module-common-config; 1349 leaf-list path { 1350 type string; 1351 description 1352 "The list of schema paths included in the feature. The 1353 paths specify subtrees, i.e., all data underneath the 1354 specified path are included in the feature."; 1355 } 1356 } 1358 grouping feature-bundle-feature-config { 1359 description 1360 "Data definitions for included feature bundles"; 1362 uses feature-bundle-included-reference; 1363 } 1365 grouping feature-bundle-feature-top { 1366 description 1367 "Top level grouping for the list of included feature 1368 bundles"; 1370 container feature-bundles { 1371 description 1372 "Enclosing container for the list of included feature 1373 bundles. Feature bundles may be composed from other 1374 smaller feature units"; 1376 list feature-bundle { 1377 key "name"; 1378 description 1379 "The list of feature bundles included in the current 1380 feature bundle."; 1382 uses feature-bundle-feature-config; 1383 } 1384 } 1386 } 1388 grouping feature-bundle-top { 1389 description 1390 "Top-level grouping for OpenConfig feature bundles"; 1392 container feature-bundles { 1393 description 1394 "Enclosing container for the list of feature bundles"; 1396 list feature-bundle { 1397 key "name version"; 1398 description 1399 "List of feature bundles"; 1401 uses feature-bundle-config; 1402 uses feature-bundle-release-top; 1403 uses feature-bundle-feature-top; 1404 } 1405 } 1406 } 1408 grouping catalog-module-top { 1409 description 1410 "Top level structure of the module catalog"; 1412 container modules { 1413 description 1414 "Modules published by this organization"; 1416 list module { 1417 key "name version"; 1418 description 1419 "List of published modules from the organization"; 1421 uses catalog-module-common-config; 1422 uses catalog-module-base-config; 1423 uses catalog-module-classification-top; 1424 uses catalog-module-dependency-top; 1425 uses catalog-module-access-top; 1426 uses catalog-module-submodule-top; 1427 } 1428 } 1429 } 1431 grouping catalog-organization-config { 1432 description 1433 "Top level grouping for data related to an organization that 1434 publishes module, bundles, etc."; 1436 leaf name { 1437 type string; 1438 description 1439 "Name of the maintaining organization -- the name should be 1440 supplied in the official format used by the organization. 1441 Standards Body examples: 1442 IETF, IEEE, MEF, ONF, etc. 1443 Commercial entity examples: 1444 AT&T, Facebook, 1445 Name of industry forum examples: 1446 OpenConfig, OpenDaylight, ON.Lab"; 1447 } 1449 leaf type { 1450 type identityref { 1451 base oc-cat-types:ORGANIZATION_TYPE; 1452 } 1453 description 1454 "Type of the publishing organization"; 1455 } 1457 leaf contact { 1458 type string; 1459 description 1460 "Contact information for the publishing organization (web 1461 site, email address, etc.)"; 1462 } 1463 } 1465 grouping catalog-organization-top { 1466 description 1467 "Top level grouping for list of maintaining organizations"; 1469 container organizations { 1470 description 1471 "List of organizations owning modules"; 1473 list organization { 1474 key "name"; 1476 description 1477 "List of organizations publishing YANG modules or 1478 module bundles"; 1480 uses catalog-organization-config; 1481 uses catalog-module-top; 1482 uses release-bundle-top; 1483 uses feature-bundle-top; 1484 uses catalog-implementation-top; 1485 } 1486 } 1487 } 1489 grouping catalog-top { 1490 description 1491 "Top-level grouping for the YANG model catalog"; 1493 uses catalog-organization-top; 1494 } 1496 // data definition statements 1498 uses catalog-top; 1500 } 1502 1504 Required extensions and types modules included below. 1506 file "openconfig-extensions.yang" 1508 module openconfig-extensions { 1510 yang-version "1"; 1512 // namespace 1513 namespace "http://openconfig.net/yang/openconfig-ext"; 1514 prefix "oc-ext"; 1516 // meta 1517 organization "OpenConfig working group"; 1519 contact 1520 "OpenConfig working group 1521 www.openconfig.net"; 1523 description 1524 "This module provides extensions to the YANG language to allow 1525 OpenConfig specific functionality and meta-data to be defined."; 1527 revision "2017-01-29" { 1528 description 1529 "Added extension for annotating encrypted values."; 1530 reference "TBD"; 1531 } 1533 revision "2015-10-09" { 1534 description 1535 "Initial OpenConfig public release"; 1536 reference "TBD"; 1537 } 1539 revision "2015-10-05" { 1540 description 1541 "Initial revision"; 1542 reference "TBD"; 1543 } 1545 // extension statements 1546 extension openconfig-version { 1547 argument "semver" { 1548 yin-element false; 1549 } 1550 description 1551 "The OpenConfig version number for the module. This is 1552 expressed as a semantic version number of the form: 1553 x.y.z 1554 where: 1555 * x corresponds to the major version, 1556 * y corresponds to a minor version, 1557 * z corresponds to a patch version. 1558 This version corresponds to the model file within which it is 1559 defined, and does not cover the whole set of OpenConfig models. 1560 Where several modules are used to build up a single block of 1561 functionality, the same module version is specified across each 1562 file that makes up the module. 1564 A major version number of 0 indicates that this model is still 1565 in development (whether within OpenConfig or with industry 1566 partners), and is potentially subject to change. 1568 Following a release of major version 1, all modules will 1569 increment major revision number where backwards incompatible 1570 changes to the model are made. 1572 The minor version is changed when features are added to the 1573 model that do not impact current clients use of the model. 1575 The patch-level version is incremented when non-feature changes 1576 (such as bugfixes or clarifications to human-readable 1577 descriptions that do not impact model functionality) are made 1578 that maintain backwards compatibility. 1580 The version number is stored in the module meta-data."; 1581 } 1583 extension openconfig-encrypted-value { 1584 description 1585 "This extension provides an annotation on schema nodes to 1586 indicate that the corresponding value should be stored and 1587 reported in encrypted form. 1589 Clients reading the configuration or applied configuration 1590 for the node should expect to receive only the encrypted value. 1591 This annotation may be used on nodes such as secure passwords 1592 in which the device never reports a cleartext value, even 1593 if the input is provided as cleartext."; 1594 } 1595 } 1596 1598 file "openconfig-inet-types.yang" 1600 module openconfig-inet-types { 1602 yang-version "1"; 1603 namespace "http://openconfig.net/yang/types/inet"; 1604 prefix "oc-inet"; 1606 import openconfig-extensions { prefix "oc-ext"; } 1608 organization 1609 "OpenConfig working group"; 1611 contact 1612 "OpenConfig working group 1613 www.openconfig.net"; 1615 description 1616 "This module contains a set of Internet address related 1617 types for use in OpenConfig modules."; 1619 oc-ext:openconfig-version "0.1.0"; 1621 revision 2017-01-26 { 1622 description 1623 "Initial module for inet types"; 1624 reference "0.1.0"; 1625 } 1627 // IPv4 and IPv6 types. 1629 typedef ipv4-address { 1630 type string { 1631 pattern '^(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|' + 1632 '25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4]' + 1633 '[0-9]|25[0-5])$'; 1634 } 1635 description 1636 "An IPv4 address in dotted quad notation."; 1637 } 1639 typedef ipv6-address { 1640 type string { 1641 pattern 1642 // Must support compression through different lengths 1643 // therefore this regexp is complex. 1644 '^(([0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}|' + 1645 '([0-9a-fA-F]{1,4}:){1,7}:|' + 1646 '([0-9a-fA-F]{1,4}:){1,6}:[0-9a-fA-F]{1,4}' + 1647 '([0-9a-fA-F]{1,4}:){1,5}(:[0-9a-fA-F]{1,4}){1,2}|' + 1648 '([0-9a-fA-F]{1,4}:){1,4}(:[0-9a-fA-F]{1,4}){1,3}|' + 1649 '([0-9a-fA-F]{1,4}:){1,3}(:[0-9a-fA-F]{1,4}){1,4}|' + 1650 '([0-9a-fA-F]{1,4}:){1,2}(:[0-9a-fA-F]{1,4}){1,5}|' + 1651 '[0-9a-fA-F]{1,4}:((:[0-9a-fA-F]{1,4}){1,6})|' + 1652 ':((:[0-9a-fA-F]{1,4}){1,7}|:)' + 1653 ')$'; 1654 } 1655 description 1656 "An IPv6 address represented as either a full address; shortened 1657 or mixed-shortened formats."; 1658 } 1660 typedef ipv4-prefix { 1661 type string { 1662 pattern '^(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|' + 1663 '25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4]' + 1664 '[0-9]|25[0-5])/(([0-9])|([1-2][0-9])|(3[0-2]))$'; 1665 } 1666 description 1667 "An IPv4 prefix represented in dotted quad notation followed by 1668 a slash and a CIDR mask (0 <= mask <= 32)."; 1669 } 1671 typedef ipv6-prefix { 1672 type string { 1673 pattern 1674 '^(([0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}|' + 1675 '([0-9a-fA-F]{1,4}:){1,7}:|' + 1676 '([0-9a-fA-F]{1,4}:){1,6}:[0-9a-fA-F]{1,4}' + 1677 '([0-9a-fA-F]{1,4}:){1,5}(:[0-9a-fA-F]{1,4}){1,2}|' + 1678 '([0-9a-fA-F]{1,4}:){1,4}(:[0-9a-fA-F]{1,4}){1,3}|' + 1679 '([0-9a-fA-F]{1,4}:){1,3}(:[0-9a-fA-F]{1,4}){1,4}|' + 1680 '([0-9a-fA-F]{1,4}:){1,2}(:[0-9a-fA-F]{1,4}){1,5}|' + 1681 '[0-9a-fA-F]{1,4}:((:[0-9a-fA-F]{1,4}){1,6})|' + 1682 ':((:[0-9a-fA-F]{1,4}){1,7}|:)' + 1683 ')/(12[0-8]|1[0-1][0-9]|[1-9][0-9]|[0-9])$'; 1684 } 1685 description 1686 "An IPv6 prefix represented in full, shortened, or mixed 1687 shortened format followed by a slash and CIDR mask (0 <= mask <= 1688 128)."; 1689 } 1691 typedef ip-address { 1692 type union { 1693 type ipv4-address; 1694 type ipv6-address; 1695 } 1696 description 1697 "An IPv4 or IPv6 address with no prefix specified."; 1698 } 1700 typedef ip-prefix { 1701 type union { 1702 type ipv4-prefix; 1703 type ipv6-prefix; 1704 } 1705 description 1706 "An IPv4 or IPv6 prefix."; 1707 } 1709 typedef as-number { 1710 type uint32; 1711 description 1712 "A numeric identifier for an autonomous system (AS). An AS is a 1713 single domain, under common administrative control, which forms 1714 a unit of routing policy. Autonomous systems can be assigned a 1715 2-byte identifier, or a 4-byte identifier which may have public 1716 or private scope. Private ASNs are assigned from dedicated 1717 ranges. Public ASNs are assigned from ranges allocated by IANA 1718 to the regional internet registries (RIRs)."; 1719 reference 1720 "RFC 1930 Guidelines for creation, selection, and registration 1721 of an Autonomous System (AS) 1722 RFC 4271 A Border Gateway Protocol 4 (BGP-4)"; 1723 } 1725 typedef dscp { 1726 type uint8 { 1727 range "0..63"; 1728 } 1729 description 1730 "A differentiated services code point (DSCP) marking within the 1731 IP header."; 1732 reference 1733 "RFC 2474 Definition of the Differentiated Services Field 1734 (DS Field) in the IPv4 and IPv6 Headers"; 1735 } 1737 typedef ipv6-flow-label { 1738 type uint32 { 1739 range "0..1048575"; 1740 } 1741 description 1742 "The IPv6 flow-label is a 20-bit value within the IPv6 header 1743 which is optionally used by the source of the IPv6 packet to 1744 label sets of packets for which special handling may be 1745 required."; 1746 reference 1747 "RFC 2460 Internet Protocol, Version 6 (IPv6) Specification"; 1748 } 1750 typedef port-number { 1751 type uint16; 1752 description 1753 "A 16-bit port number used by a transport protocol such as TCP 1754 or UDP."; 1755 reference 1756 "RFC 768 User Datagram Protocol 1757 RFC 793 Transmission Control Protocol"; 1758 } 1760 typedef uri { 1761 type string; 1762 description 1763 "An ASCII-encoded Uniform Resource Identifier (URI) as defined 1764 in RFC 3986."; 1765 reference 1766 "RFC 3986 Uniform Resource Identifier (URI): Generic Syntax"; 1767 } 1768 } 1770 1772 10. References 1774 10.1. Normative references 1776 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1777 the Network Configuration Protocol (NETCONF)", RFC 6020, 1778 DOI 10.17487/RFC6020, October 2010, 1779 . 1781 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1782 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1783 . 1785 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1786 DOI 10.17487/RFC3688, January 2004, 1787 . 1789 [RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 1790 Library", RFC 7895, DOI 10.17487/RFC7895, June 2016, 1791 . 1793 10.2. Informative references 1795 [RTG-AD-YANG] 1796 Wu, Q. and D. Sinicrope, "Routing Area Yang Coordinator's 1797 Summary Page", October 2015, 1798 . 1801 [OC-SEMVER] 1802 OpenConfig operator working group, "Semantic Versioning 1803 for OpenConfig models", September 2015, 1804 . 1807 [I-D.openconfig-netmod-model-structure] 1808 Shaikh, A., Shakir, R., D'Souza, K., and L. Fang, 1809 "Operational Structure and Organization of YANG Models", 1810 draft-openconfig-netmod-model-structure-00 (work in 1811 progress), March 2015. 1813 [I-D.rtgyangdt-rtgwg-device-model] 1814 Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps, 1815 "Network Device YANG Organizational Models", draft- 1816 rtgyangdt-rtgwg-device-model-05 (work in progress), August 1817 2016. 1819 [I-D.ietf-netmod-yang-model-classification] 1820 Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module 1821 Classification", draft-ietf-netmod-yang-model- 1822 classification-04 (work in progress), October 2016. 1824 Appendix A. Change summary 1826 A.1. Changes between revisions -01 and -02 1828 o Included additional explanation for release and feature bundles 1830 o Changed feature bundles to be based on schema paths 1832 o Included version 0.2.0 of catalog modules. 1834 A.2. Changes between revisions -00 and -01 1836 o Added release bundle definitions. 1838 o Added IETF module classification identities based on draft-ietf- 1839 netmod-yang-model-classification. 1841 Authors' Addresses 1842 Anees Shaikh 1843 Google 1844 1600 Amphitheatre Pkwy 1845 Mountain View, CA 94043 1846 US 1848 Email: aashaikh@google.com 1850 Rob Shakir 1851 Google 1852 1600 Amphitheatre Pkwy 1853 Mountain View, CA 94043 1854 US 1856 Email: rjs@rob.sh 1858 Kevin D'Souza 1859 AT&T 1860 200 S. Laurel Ave 1861 Middletown, NJ 1862 US 1864 Email: kd6913@att.com