Network Working Group A. Bierman Internet-Draft YumaWorks Intended status: Standards Track July 6, 2015 Expires: January 7, 2016 The YANG Package Statement draft-bierman-netmod-yang-package-00 Abstract This document describes mechanisms for defining a conceptual collection of YANG modules and protocol capability URIs, called a YANG package. Typically, modules with high cohesion that are designed to be used together to manage a service or product feature are included in a YANG package. The purpose of the package is not constrained by this document. For example, a YANG package may describe conformance requirements or simply describe the modules and protocol capabilities implemented in a specific platform. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 January 7, 2016. Copyright Notice Copyright (c) 2015 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Bierman Expires January 7, 2016 [Page 1]
Internet-Draft YANG Packages July 2015 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.1. YANG . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1.2. YANG Package . . . . . . . . . . . . . . . . . . . . 4 1.2. Solution Overview . . . . . . . . . . . . . . . . . . . . 5 1.2.1. Objectives . . . . . . . . . . . . . . . . . . . . . 5 1.2.2. YANG Package . . . . . . . . . . . . . . . . . . . . 5 1.2.3. YANG Package File . . . . . . . . . . . . . . . . . . 5 1.2.4. YANG Package Examples . . . . . . . . . . . . . . . . 6 2. YANG Package Statement . . . . . . . . . . . . . . . . . . . 10 2.1. The "package" Statement . . . . . . . . . . . . . . . . . 10 2.1.1. The "package" Substatements . . . . . . . . . . . . . 10 2.2. The "yang-package-version" Statement . . . . . . . . . . 11 2.3. The "uses-package" Statement . . . . . . . . . . . . . . 11 2.3.1. The "uses-package" Substatements . . . . . . . . . . 12 2.4. The "uses-revision" Statement . . . . . . . . . . . . . . 12 2.5. The "imports-module" Statement . . . . . . . . . . . . . 12 2.5.1. The "imports-module" Substatements . . . . . . . . . 12 2.6. The "uses-module" Statement . . . . . . . . . . . . . . . 13 2.6.1. The "uses-module" Substatements . . . . . . . . . . . 13 2.7. The "uses-feature" Statement . . . . . . . . . . . . . . 13 2.7.1. The "uses-feature" Substatements . . . . . . . . . . 13 2.8. The "uses-capability" Statement . . . . . . . . . . . . . 13 2.8.1. The "uses-capability" Substatements . . . . . . . . . 14 2.9. The "uses-parameter" Statement . . . . . . . . . . . . . 14 2.9.1. The "uses-parameter" Substatements . . . . . . . . . 14 2.10. The "uses-value" Statement . . . . . . . . . . . . . . . 15 2.10.1. The "uses-value" Substatements . . . . . . . . . . . 15 3. Updating a YANG Package . . . . . . . . . . . . . . . . . . . 16 4. YANG Package Identifier . . . . . . . . . . . . . . . . . . . 16 5. YANG Package ABNF . . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . 20 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 21 A.1. bierman-yang-conformance-03 to bierman-yang-package-00 . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 Bierman Expires January 7, 2016 [Page 2]
Internet-Draft YANG Packages July 2015 1. Introduction The YANG data modelling language [I-D.ietf-netmod-rfc6020bis] is used to manage conceptual hierarchical data in a modular fashion. It is highly extensible, and modules from any organization can be defined to work together. Unfortunately, YANG has no way to describe any functionality or service which is defined in multiple YANG modules. As described in [I-D.bogdanovic-netmod-yang-model-classification], vendor-specific YANG modules are expected to co-exist with standard modules from multiple standards organizations. Operators and developers need a higher layer of data organization than a list of individual YANG modules, in order to more easily manage networks with YANG data models. There is a need for standard mechanisms to describe a set of YANG modules, grouped together for a specific purpose. The exact purpose of such a mechanism may vary by use-case, and is not restricted by this document. Often YANG modules are designed such that a framework module (e.g., ietf-interfaces module in [RFC7223]) is designed to be augmented by many other modules. There are no machine-readable statements in YANG to describe which modules are needed for the implementation of a service or product feature. YANG features are used to specify a set of optional related statements, such as data definition statements. There are no machine-readable statements in YANG to describe which features are needed for the implementation of a service or product feature. Capability URIs are used in protocols such as NETCONF [RFC6241] and RESTCONF [I-D.ietf-netconf-restconf] to identify an optional protocol feature. such as the ":confirmed-commit" capability in NETCONF. There are no machine-readable statements in YANG to describe which protocol capabilities are needed for the implementation of a service or product feature. Constrained devices may have limited host and network resources. Retrieval of a large list of YANG modules, or sending of a large NETCONF <hello> message could significantly impact network performance. It is important to minimize all network management traffic in this type of environment. Advertisement of YANG packages instead of a complete list of YANG modules (with revision, features, and deviation parameters) could save a significant amount of host and network resources. Bierman Expires January 7, 2016 [Page 3]
Internet-Draft YANG Packages July 2015 1.1. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119]. 1.1.1. YANG The following terms are defined in [I-D.ietf-netmod-rfc6020bis]: q o data node o feature o module o notification statement o rpc statement 1.1.2. YANG Package The following terms are used within this document: o conditional node: An object that has one or more "if-feature" sub- statements associated with it. Note that objects affected by "when" statements are not considered conditional for conformance purposes. o macro-data: The reusable YANG statements that are not protocol- accessible. These include the "typedef", "grouping", "feature", and "identity" statements. o module base: There is an implied "base" version of the module, which includes all statements which are not conditional. The module base may be empty, a subset of all statements, or the entire module. Note that a "deviation" statement is always part of the module base since it cannot be conditional. o object: a conceptual data structure represented by a YANG data, rpc, or notification statement. o YANG package: A set of YANG modules that provide a particular service or product feature. Also called "package". Bierman Expires January 7, 2016 [Page 4]
Internet-Draft YANG Packages July 2015 1.2. Solution Overview 1.2.1. Objectives The solution in this document attempts to achieve the following objectives: o Provide simple documentation mechanisms that are readable and easy to understand, and can be maintained over time. o Provide simple mechanisms that can scale in usage from one module to thousands of modules. o Describe the usage relationship between an augmented module and the augmenting module. o Describe the usage relationship between modules that represent parts of the same conceptual high-level service. 1.2.2. YANG Package A YANG package is a conceptual set of YANG modules describing some service or product feature. Typically, modules with high cohesion that are designed to be used together to manage a service or device feature are included in a YANG package. The purpose of the package is not constrained by this document. A YANG package may describe conformance requirements or simply describe the modules implemented in a specific platform. YANG packages are specified using a text file similar to YANG modules, however they are separate from YANG modules, since the purpose of a YANG package is to describe a set of YANG modules. Unlike YANG modules, YANG package definitions cannot represent YANG data nodes that would appear in a protocol message. A YANG package is identified with a module-qualified name similar to a YANG module. YANG modules and YANG packages share the same YANG identifier namespace, so the same naming conventions apply to YANG packages as YANG modules. 1.2.3. YANG Package File A YANG package file consists of UTF-8 characters. The syntax is exactly the same as for YANG modules. Several YANG statements are "imported" from the YANG ABNF, and some new statements are defined. Specifically, YANG package syntax is the same as [I-D.ietf-netmod-rfc6020bis], sections 6, 6.1, 6.2, and 6.3. Bierman Expires January 7, 2016 [Page 5]
Internet-Draft YANG Packages July 2015 At least one revision statement MUST be present in a YANG package file. A new revision MUST be added each time the YANG package file is published. This requirement is more strict than RFC 6020 to ensure that package revisions can be properly identified without ambiguity. A YANG package has a lifecycle status, based on the YANG "status" statement. 1.2.4. YANG Package Examples In this example, a package named "example-routing-pkg" is defined to describe the routing modules supported by a particular vendor name Example, Inc. Bierman Expires January 7, 2016 [Page 6]
Internet-Draft YANG Packages July 2015 package example-routing-pkg { organization "Example, Inc."; contact "support at example.com"; description "This package describes the routing modules required to support Example, Inc. base routing service."; revision 2015-07-01 { description "First revision"; reference "TBD"; } imports-module ietf-inet-types { uses-revision 2013-07-15; } imports-module ietf-yang-types { uses-revision 2013-07-15; } uses-module ietf-routing { uses-revision 2015-05-25; uses-feature multiple-ribs; uses-feature router-id; } uses-module ietf-interfaces { uses-revision 2014-05-08; uses-feature pre-provisioning; } uses-module ietf-ipv4-unicast-routing { uses-revision 2014-05-25; } uses-module ietf-ipv6-unicast-routing { uses-revision 2014-05-25; } uses-module example-routing-extensions { uses-revision 2015-06-24; } } In this example, a package named "example-routing-bgp-pkg" is defined to describe the BGP modules supported by a particular vendor name Example, Inc. Bierman Expires January 7, 2016 [Page 7]
Internet-Draft YANG Packages July 2015 package example-routing-bgp-pkg { organization "Example, Inc."; contact "support at example.com"; description "This package describes the routing modules required to support Example, Inc. BGP routing service."; revision 2015-07-01 { description "First revision"; reference "TBD"; } uses-package example-routing-pkg { uses-revision 2015-07-01; } uses-module example-routing-bgp { uses-revision 2014-04-17; } } In this example, the YANG package described the NETCONF server features that the Example, Inc NMS platform requires to function. package example-netconf-pkg { organization "Example, Inc."; contact "support at example.com"; description "This package describes the NETCONF functionality required to support Example, Inc. NMS platforms."; revision 2015-07-01 { description "First revision"; } imports-module ietf-inet-types { uses-revision 2013-07-15; } imports-module ietf-yang-types { uses-revision 2013-07-15; } uses-module ietf-netconf { uses-revision 2011-06-01; uses-feature candidate; Bierman Expires January 7, 2016 [Page 8]
Internet-Draft YANG Packages July 2015 uses-feature confirmed-commit; } uses-capability "urn:ietf:params:netconf:capability:notification:1.0" { description "Notification delivery support is required."; reference "RFC 5277, section 3.1"; } uses-capability "urn:ietf:params:netconf:capability:interleave:1.0" { description "Interleave of commands is required while notification delivery is active ."; reference "RFC 5277, section 6"; } uses-module ietf-netconf-with-defaults { uses-revision 2011-06-01; description "Support for <with-defaults> RPC parameter is required."; reference "RFC 6243, section 5"; } uses-module ietf-netconf-acm { uses-revision 2012-02-22; description "Base module implementation of NACM is required."; reference "RFC 6536, section 3.5.2"; } uses-module ietf-netconf-monitoring { uses-revision 2010-10-04; description "Implementation of NETCONF monitoring is required."; reference "RFC 6022, section 5"; } uses-module ietf-netconf-notifications { uses-revision 2012-02-06; reference "RFC 6470, section 2.2"; } } Bierman Expires January 7, 2016 [Page 9]
Internet-Draft YANG Packages July 2015 2. YANG Package Statement 2.1. The "package" Statement The "package" statement defines the YANG package's name, and contains all YANG package statements. The "package" statement's argument is the name of the YANG package, followed by a block of substatements that hold detailed package information. The package name follows the rules for identifiers in RFC 6020bis, section 6.2. A YANG package name is defined in the same conceptual namespace as YANG module names. The same rules for selecting non-conflicting names apply as defined in RFC 6020bis, section 7.1. If standard YANG packages are defined by the IETF, then an IANA registry for YANG package names will be needed, similar to mechanism described in RFC 6020bis, section 15. A YANG package includes a status statement to indicate the package lifecycle status. The YANG "status" statement is used for this purpose. The default status is "current". A current YANG package SHOULD NOT use any package, module, feature, or capability that is deprecated. A current YANG package MUST NOT use any package, module, feature, or capability that is obsolete. Only current YANG packages SHOULD be used in a server. A deprecated package MAY be used with the understanding that support for the package may be removed at any time in the future. An obsolete package MUST NOT be used. 2.1.1. The "package" Substatements Bierman Expires January 7, 2016 [Page 10]
Internet-Draft YANG Packages July 2015 +----------------------+---------------------+-------------+ | Substatement | Reference | Cardinality | +----------------------+---------------------+-------------+ | contact | RFC 6020bis, 7.1.8 | 0..1 | | description | RFC 6020bis, 7.19.3 | 0..1 | | imports-module | 2.5 | 0..n | | organization | RFC 6020bis, 7.1.7 | 0..1 | | reference | RFC 6020bis, 7.19.4 | 0..1 | | revision | RFC 6020bis, 7.1.9 | 1..n | | status | RFC 6020bis, 7.19.2 | 0..1 | | uses-capability | 2.8 | 0..n | | uses-module | 2.6 | 0..n | | uses-package | 2.3 | 0..n | | yang-package-version | 2.2 | 0..1 | +----------------------+---------------------+-------------+ package Substatements 2.2. The "yang-package-version" Statement The optional "yang-package-version" statement specifies which version of the YANG Package specification language was used in developing the module. The statement's argument is a string. If present, it MUST contain the value "1", which is the current YANG Package language version and the default value. Handling of the "yang-package-version" statement for versions other than "1" (the version defined here) is out of scope for this specification. Any document that defines a higher version will need to define the backward compatibility of such a higher version. 2.3. The "uses-package" Statement The "uses-package" statement is used to indicate that support for an another YANG package. It takes as an argument the name of the YANG package to use, followed by a block of substatements that hold detailed server support requirements. A "uses-package" statement MUST NOT specify any YANG package name that would create a dependency loop, such that the package containing the "uses-package" statement would be required to use itself. The "uses-revision" sub-statement is required, and identifies the revision of the package used. Bierman Expires January 7, 2016 [Page 11]
Internet-Draft YANG Packages July 2015 2.3.1. The "uses-package" Substatements +---------------+---------------------+-------------+ | Substatement | Reference | Cardinality | +---------------+---------------------+-------------+ | description | RFC 6020bis, 7.19.3 | 0..1 | | reference | RFC 6020bis, 7.19.4 | 0..1 | | uses-revision | 2.4 | 1 | +---------------+---------------------+-------------+ uses-package Substatements 2.4. The "uses-revision" Statement The "uses-revision" statement is a mandatory statement used to identify the revision date for the parent package or module statement uses in the YANG package. It takes as argument a date string in the form "YYYY-MM-DD" where "YYYY" is the year, "MM" is the month, and "DD" is the day. The "uses-revision" statement has no substatements. 2.5. The "imports-module" Statement The "imports-module" statement is used to indicate that the macro- data from the specified module is used. It takes as an argument the name of the module to import, followed by a block of substatements that describe detailed module import usage information. The "uses-revision" sub-statement is required, and identifies at least one revision of the module imported. YANG permits the macro- data from more than one revision of a module to be used within a server (i.e., import using a revision-date), so multiple "uses-revision" statements are permitted. 2.5.1. The "imports-module" Substatements +---------------+---------------------+-------------+ | Substatement | Reference | Cardinality | +---------------+---------------------+-------------+ | description | RFC 6020bis, 7.19.3 | 0..1 | | reference | RFC 6020bis, 7.19.4 | 0..1 | | uses-revision | 2.4 | 1..n | +---------------+---------------------+-------------+ imports-module Substatements Bierman Expires January 7, 2016 [Page 12]
Internet-Draft YANG Packages July 2015 2.6. The "uses-module" Statement The "uses-module" statement is used to indicate support for the protocol accessible objects in the specified base module. It takes as an argument the name of the module to use, followed by a block of substatements that describe detailed module usage information. The "uses-revision" sub-statement is required, and identifies the revision of the module used. 2.6.1. The "uses-module" Substatements +---------------+---------------------+-------------+ | Substatement | Reference | Cardinality | +---------------+---------------------+-------------+ | description | RFC 6020bis, 7.19.3 | 0..1 | | reference | RFC 6020bis, 7.19.4 | 0..1 | | uses-revision | 2.4 | 1 | | uses-feature | 2.7 | 0..n | +---------------+---------------------+-------------+ uses-module Substatements 2.7. The "uses-feature" Statement The "uses-feature" statement is used to indicate that the specified YANG feature is used in the YANG package. It takes as argument the name of the YANG feature that is required, and is followed by a block of substatements that describe the YANG feature usage within the YANG package. 2.7.1. The "uses-feature" Substatements +--------------+---------------------+-------------+ | Substatement | Reference | Cardinality | +--------------+---------------------+-------------+ | description | RFC 6020bis, 7.19.3 | 0..1 | | reference | RFC 6020bis, 7.19.4 | 0..1 | +--------------+---------------------+-------------+ uses-feature Substatements 2.8. The "uses-capability" Statement The "uses-capability" statement is used to indicate that the specified protocol capability URI is used in the YANG package. It takes as argument a URI string identifying the protocol capability Bierman Expires January 7, 2016 [Page 13]
Internet-Draft YANG Packages July 2015 that is used, and is followed by a block of substatements that describe the protocol capability usage within the YANG package. 2.8.1. The "uses-capability" Substatements +----------------+---------------------+-------------+ | Substatement | Reference | Cardinality | +----------------+---------------------+-------------+ | description | RFC 6020bis, 7.19.3 | 0..1 | | reference | RFC 6020bis, 7.19.4 | 0..1 | | uses-parameter | 2.9 | 0..n | +----------------+---------------------+-------------+ uses-capability Substatements 2.9. The "uses-parameter" Statement The "uses-parameter" statement is used to indicate that the specified URI parameter for the parent "uses-capability" statement is used in the YANG package. It takes as argument a string identifying the parameter name that is used, and MAY be followed by a block of substatements that describe the protocol parameter usage within the YANG package. If this parameter appears more than once within a "uses-capability" statement then all the specified parameters are used in the YANG package. 2.9.1. The "uses-parameter" Substatements +--------------+---------------------+-------------+ | Substatement | Reference | Cardinality | +--------------+---------------------+-------------+ | description | RFC 6020bis, 7.19.3 | 0..1 | | reference | RFC 6020bis, 7.19.4 | 0..1 | | uses-value | 2.10 | 0..n | +--------------+---------------------+-------------+ uses-parameter Substatements Usage Example: Bierman Expires January 7, 2016 [Page 14]
Internet-Draft YANG Packages July 2015 package example-url { description "A package for requiring that the scheme parameter be present in the :url capability. Any value is allowed."; uses-capability "urn:ietf:params:netconf:capability:url:1.0" { description "Support for the :url capability is required."; reference "RFC 6241, section 8.8"; uses-parameter scheme { description "Support for the scheme parameter is required."; reference "RFC 6241, section 8.8.3"; } } } 2.10. The "uses-value" Statement The "uses-value" statement is used to indicate a parameter value used in the parent "uses-capability" statement. It takes as argument a string identifying a parameter value that is used, and MAY be followed by a block of substatements that describe the protocol parameter value usage within the YANG package. 2.10.1. The "uses-value" Substatements +--------------+---------------------+-------------+ | Substatement | Reference | Cardinality | +--------------+---------------------+-------------+ | description | RFC 6020bis, 7.19.3 | 0..1 | | reference | RFC 6020bis, 7.19.4 | 0..1 | +--------------+---------------------+-------------+ uses-value Substatements Usage Example Bierman Expires January 7, 2016 [Page 15]
Internet-Draft YANG Packages July 2015 package example-url-ftp { description "A profile for requiring FTP support for the 'url' capability."; uses-capability "urn:ietf:params:netconf:capability:url:1.0" { description "Support for the :url capability is required."; reference "RFC 6241, section 8.8"; uses-parameter scheme { description "Support for the 'scheme' parameter is required."; reference "RFC 6241, section 8.8.3"; uses-value ftp { description "Support for 'ftp' transfer is required."; } } } } 3. Updating a YANG Package If a YANG package is modified then a new "revision" statement MUST be added identifying the new revision date. There are no other YANG package update restrictions. 4. YANG Package Identifier The YANG Package Identifier is a URI, used to identify a YANG package within a protocol capability URI. This document does not specify any protocol procedures for advertisement of a YANG Package Identifier. The YANG Package Identifier MUST match the rule for a "pkg-uri": pkg-uri = yang-pkg-uri parameter-list parameter-list = "?" pkg-parameter "&" rev-parameter pkg-parameter = "name=" package-name rev-parameter = "rev=" revision-date Where: o "yang-pkg-uri" is the IANA-assigned URI to identify a YANG package o "package-name" is the name of the YANG package o "revision-date" is the revision date of the YANG package Bierman Expires January 7, 2016 [Page 16]
Internet-Draft YANG Packages July 2015 Both parameters MUST be present in the YANG Package Identifier. Example: (wrapped for display purposes only) urn:ietf:params:xml:ns:yang:pkg?name=example-routing-pkg &rev=2015-07-01 5. YANG Package ABNF The following ABNF grammar is defined in accordance with [RFC5234] and [RFC7405]. Within the ABNF grammar, unordered statements are marked with comments. This grammar assumes that the scanner replaces YANG comments with a single space character. <CODE BEGINS> file "yang-package.abnf" package-stmt = optsep package-keyword sep identifier-arg-str optsep "{" stmtsep [yang-package-version-stmt] meta-stmts [status-stmt stmtsep] req-revision-stmts package-body-stmts "}" optsep yang-package-version-stmt = yang-package-version-keyword sep yang-package-version-arg-str optsep stmtend yang-package-version-arg-str = < a string that matches the rule yang-package-version-arg > yang-package-version-arg = "1" req-revision-stmts = 1*(revision-stmt stmtsep) uses-revision-stmt = revision-keyword sep date-arg-str stmtend package-body-stmts = *((uses-package-stmt / uses-module-stmt / imports-module-stmt / uses-capability-stmt) stmtsep) Bierman Expires January 7, 2016 [Page 17]
Internet-Draft YANG Packages July 2015 uses-package-stmt = uses-package-keyword sep identifier-arg-str optsep (";" / "{" stmtsep ;; these stmts can appear in any order uses-revision-stmt stmtsep [description-stmt stmtsep] [reference-stmt stmtsep] "}") uses-module-stmt = uses-module-keyword sep identifier-arg-str optsep (";" / "{" stmtsep ;; these stmts can appear in any order uses-revision-stmt stmtsep [description-stmt stmtsep] [reference-stmt stmtsep] *(uses-feature-stmt stmtsep) "}") uses-feature-stmt = uses-feature-keyword sep identifier-arg-str optsep (";" / "{" stmtsep ;; these stmts can appear in any order [description-stmt stmtsep] [reference-stmt stmtsep] "}") imports-module-stmt = imports-module-keyword sep identifier-arg-str optsep (";" / "{" stmtsep ;; these stmts can appear in any order uses-revision-stmt stmtsep [description-stmt stmtsep] [reference-stmt stmtsep] "}") uses-capability-stmt = uses-capability-keyword sep uri-str optsep (";" / "{" stmtsep ;; these stmts can appear in any order [description-stmt stmtsep] [reference-stmt stmtsep] *(uses-parameter-stmt stmtsep) Bierman Expires January 7, 2016 [Page 18]
Internet-Draft YANG Packages July 2015 "}") uses-parameter-stmt = uses-parameter-keyword sep identifier-arg-str optsep (";" / "{" stmtsep ;; these stmts can appear in any order [description-stmt stmtsep] [reference-stmt stmtsep] *(uses-value-stmt stmtsep) "}") uses-value-stmt = uses-value-keyword sep value-arg-str optsep (";" / "{" stmtsep ;; these stmts can appear in any order [description-stmt stmtsep] [reference-stmt stmtsep] "}") value-arg-str = <string containing parameter value> ;; new keywords imports-module-keyword = 'imports-module' package-keyword = 'package' uses-revision-keyword = 'uses-revision' uses-capability-keyword = 'uses-capability' uses-feature-keyword = 'uses-feature' uses-module-keyword = 'uses-module' uses-parameter-keyword = 'uses-parameter' uses-package-keyword = 'uses-package' uses-value-keyword = 'uses-value' yang-package-version-keyword = 'yang-package-version' ;; the following rules are defined in RFC 6020bis, section 12 description-stmt identifier-arg-str meta-stmts opt-set reference-stmt revision-keyword revision-stmt status-stmt stmtsep uri-str Bierman Expires January 7, 2016 [Page 19]
Internet-Draft YANG Packages July 2015 <CODE ENDS> 6. IANA Considerations TODO: The YANG Package Identifier URI needs to be registered 7. Security Considerations No security threats are introduced by this document. This document describes mechanisms for specifying collections of YANG modules and protocol capabilities. It does not describe any protocol interactions or conceptual interface, such as a YANG module. However, if the YANG package list supported by a device is advertised by a server, it may help an attacker identify the server capabilities and server implementations with known bugs. Server vulnerabilities may be specific to particular modules, module revisions, or module features. This information may be included in a YANG package instance document. 8. References 8.1. Normative References [I-D.ietf-netmod-rfc6020bis] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", draft-ietf- netmod-rfc6020bis-06 (work in progress), July 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, December 2014. 8.2. Informative References [I-D.bogdanovic-netmod-yang-model-classification] Bogdanovic, D., Claise, B., and C. Moberg, "YANG model classification", draft-bogdanovic-netmod-yang-model- classification-03 (work in progress), June 2015. Bierman Expires January 7, 2016 [Page 20]
Internet-Draft YANG Packages July 2015 [I-D.ietf-netconf-restconf] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", draft-ietf-netconf-restconf-06 (work in progress), June 2015. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [RFC7223] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 7223, May 2014. Appendix A. Change Log -- RFC Ed.: remove this section before publication. A.1. bierman-yang-conformance-03 to bierman-yang-package-00 o removed all mention of YANG conformance since YANG packages do not specify new YANG conformance mechanisms. Author's Address Andy Bierman YumaWorks Email: andy@yumaworks.com Bierman Expires January 7, 2016 [Page 21]