--- 1/draft-ietf-netmod-yang-model-classification-03.txt 2016-10-26 18:15:59.639785184 -0700 +++ 2/draft-ietf-netmod-yang-model-classification-04.txt 2016-10-26 18:15:59.663785787 -0700 @@ -1,20 +1,20 @@ NETMOD D. Bogdanovic Internet-Draft Volta Networks, Inc. Intended status: Informational B. Claise -Expires: April 2, 2017 C. Moberg +Expires: April 29, 2017 C. Moberg Cisco Systems, Inc. - September 29, 2016 + October 26, 2016 YANG Module Classification - draft-ietf-netmod-yang-model-classification-03 + draft-ietf-netmod-yang-model-classification-04 Abstract The YANG [RFC6020] data modeling language is currently being considered for a wide variety of applications throughout the networking industry at large. Many standards-defining organizations (SDOs), open source software projects, vendors and users are using YANG to develop and publish YANG modules for a wide variety of applications. At the same time, there is currently no well-known terminology to categorize various types of YANG modules. @@ -35,21 +35,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 2, 2017. + This Internet-Draft will expire on April 29, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -63,29 +63,28 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. First Dimension: YANG Module Abstraction Layers . . . . . . . 4 2.1. Network Service YANG Modules . . . . . . . . . . . . . . 6 2.2. Network Element YANG Modules . . . . . . . . . . . . . . 7 3. Second Dimension: Module Types . . . . . . . . . . . . . . . 7 3.1. Standard YANG Modules . . . . . . . . . . . . . . . . . . 8 3.2. Vendor-specific YANG Modules and Extensions . . . . . . . 8 3.3. User-specific YANG Modules and Extensions . . . . . . . . 9 - 4. Adding The Classification Type to YANG Module Catalogs . . . 9 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 - 8. Change log [RFC Editor: Please remove] . . . . . . . . . . . 10 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 - 9.2. Informative References . . . . . . . . . . . . . . . . . 11 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 + 7. Change log [RFC Editor: Please remove] . . . . . . . . . . . 9 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 + 8.2. Informative References . . . . . . . . . . . . . . . . . 10 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction The Internet Engineering Steering Group (IESG) has been actively encouraging IETF working groups to use the YANG modeling language [RFC6020], [RFC7950] and NETCONF protocol [RFC6241] for configuration management purposes, especially in new working group charters [Writable-MIB-Module-IESG-Statement]. YANG is also gaining wide acceptance as the de-facto standard @@ -390,115 +389,81 @@ This module type obviously requires the infrastructure to support the introduction of user-provided modules and extensions. This would include ability to describe the service-to-network decomposition in orchestrators and the module to configuration decomposition in devices. The lifecycles of these modules are generally aligned with the change cadence of the infrastructure. -4. Adding The Classification Type to YANG Module Catalogs - - The suggested classification in this document would be an useful - information in a catalog of YANG modules. Such a catalog allows for - easy lookup and reusability of YANG modules. Practically, the YANG - module classification type would be an additional leaf to a YANG - module specified in [I-D.openconfig-netmod-model-catalog]: - - leaf module-class{ - type enum { - service - device - notApplicable - } - description - "Categorization of the YANG module based on - draft-ietf-netmod-yang-model-classification."; - } - - Note: this leaf should actually be moved to - [I-D.openconfig-netmod-model-catalog]. Note2: since a YANG module - can belong to both service and device, the ENUM is not appropriate. - An extensible list of module type is more appropriate. - - Indeed, without inspecting the YANG module itself, it's difficult to - determine whether its type is a network service or a network element. - The YANG module name might provide some useful information but is not - a definitive answer. - -5. Security Considerations +4. Security Considerations This document doesn't have any Security Considerations. -6. IANA Considerations +5. IANA Considerations This document has no IANA actions. -7. Acknowledgements +6. Acknowledgements Thanks to David Ball and David Hansford for feedback and suggestions. -8. Change log [RFC Editor: Please remove] +7. Change log [RFC Editor: Please remove] version 00: Renamed and small fixes based on WG feedback. version 01: Language fixes, collapsing of vendor data models and extensions, and the introduction of user data models and extensions. version 02: Updated the YANG Module Catalog section, terminology alignment (YANG data model versus YANG module), explain better the distinction between the Network Element and Service YANG data models even if sometimes there are grey areas, editorial pass. Changed the use of the term 'model' to 'module' to be better aligned with RFC6020. -9. References +8. References -9.1. Normative References +8.1. Normative References [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC7223] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . -9.2. Informative References +8.2. Informative References [I-D.ietf-netmod-acl-model] Bogdanovic, D., Koushik, K., Huang, L., and D. Blair, "Network Access Control List (ACL) YANG Data Model", - draft-ietf-netmod-acl-model-08 (work in progress), July + draft-ietf-netmod-acl-model-09 (work in progress), October 2016. [I-D.ietf-ospf-yang] Yeung, D., Qu, Y., Zhang, Z., Bogdanovic, D., and K. Koushik, "Yang Data Model for OSPF Protocol", draft-ietf- ospf-yang-05 (work in progress), July 2016. - [I-D.openconfig-netmod-model-catalog] - D'Souza, K., Shaikh, A., and R. Shakir, "Catalog and - registry for YANG models", draft-openconfig-netmod-model- - catalog-01 (work in progress), July 2016. - [Writable-MIB-Module-IESG-Statement] "Writable MIB Module IESG Statement", . [YANG-Data-Model-for-L3VPN-service-delivery] "YANG Data Model for L3VPN service delivery", . Authors' Addresses