One document matched: draft-bierman-netmod-yang-package-00.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<?rfc toc="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<rfc ipr="trust200902" category="std"
docName="draft-bierman-netmod-yang-package-00" >
<front>
<title abbrev="YANG Packages">The YANG Package Statement</title>
<author initials="A" surname="Bierman" fullname='Andy Bierman' >
<organization>YumaWorks</organization>
<address>
<email>andy@yumaworks.com</email>
</address>
</author>
<date/>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The YANG data modelling language <xref target="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
<xref target="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.
</t>
<t>
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.
</t>
<t>
Often YANG modules are designed such that a framework module
(e.g., ietf-interfaces module in <xref target="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.
</t>
<t>
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.
</t>
<t>
Capability URIs are used in protocols such as NETCONF <xref target="RFC6241"/>
and RESTCONF <xref target="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.
</t>
<t>
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.
</t>
<section title="Terminology">
<t>
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, <xref target="RFC2119"/>.
</t>
<section title="YANG">
<t>
The following terms are defined in <xref target="I-D.ietf-netmod-rfc6020bis"/>:
q
</t>
<t>
<list style="symbols">
<t>
data node
</t>
<t>
feature
</t>
<t>
module
</t>
<t>
notification statement
</t>
<t>
rpc statement
</t>
</list>
</t>
</section>
<section title="YANG Package">
<t>
The following terms are used within this document:
</t>
<t>
<list style="symbols">
<t>
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.
</t>
<t>
macro-data: The reusable YANG statements that are not
protocol-accessible. These include the "typedef", "grouping",
"feature", and "identity" statements.
</t>
<t>
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.
</t>
<t>
object: a conceptual data structure represented by a YANG data,
rpc, or notification statement.
</t>
<t>
YANG package: A set of YANG modules that provide a particular service or
product feature. Also called "package".
</t>
</list>
</t>
</section>
</section>
<section title="Solution Overview">
<section title="Objectives">
<t>
The solution in this document attempts to achieve the following objectives:
</t>
<t>
<list style="symbols">
<t>
Provide simple documentation mechanisms that are readable and easy
to understand, and can be maintained over time.
</t>
<t>
Provide simple mechanisms that can scale in usage from one module
to thousands of modules.
</t>
<t>
Describe the usage relationship between an augmented module and the
augmenting module.
</t>
<t>
Describe the usage relationship between modules that represent
parts of the same conceptual high-level service.
</t>
</list>
</t>
</section>
<section title="YANG Package">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="YANG Package File">
<t>
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 <xref target="I-D.ietf-netmod-rfc6020bis"/>,
sections 6, 6.1, 6.2, and 6.3.
</t>
<t>
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.
</t>
<t>
A YANG package has a lifecycle status, based on the YANG "status" statement.
</t>
</section>
<section title="YANG Package Examples">
<t>
In this example, a package named "example‑routing‑pkg"
is defined to describe the routing modules
supported by a particular vendor name Example, Inc.
</t>
<figure>
<artwork><![CDATA[
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;
}
}
]]></artwork>
</figure>
<t>
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.
</t>
<figure>
<artwork><![CDATA[
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;
}
}
]]></artwork>
</figure>
<t>
In this example, the YANG package described the NETCONF server features
that the Example, Inc NMS platform requires to function.
</t>
<figure>
<artwork><![CDATA[
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;
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";
}
}
]]></artwork>
</figure>
</section>
</section>
</section>
<section title="YANG Package Statement">
<section title="The "package" Statement">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<section title="The "package" Substatements">
<?rfc compact="yes"?><texttable title="package Substatements">
<ttcol align='left'> Substatement</ttcol>
<ttcol align='left'>Reference</ttcol>
<ttcol align='left'>Cardinality</ttcol>
<c>contact</c>
<c>RFC 6020bis, 7.1.8</c>
<c>0..1</c>
<c>description</c>
<c>RFC 6020bis, 7.19.3</c>
<c>0..1</c>
<c>imports-module</c>
<c><xref format="counter" target="imports-module"/></c>
<c>0..n</c>
<c>organization</c>
<c>RFC 6020bis, 7.1.7</c>
<c>0..1</c>
<c>reference</c>
<c>RFC 6020bis, 7.19.4</c>
<c>0..1</c>
<c>revision</c>
<c>RFC 6020bis, 7.1.9</c>
<c>1..n</c>
<c>status</c>
<c>RFC 6020bis, 7.19.2</c>
<c>0..1</c>
<c>uses-capability</c>
<c><xref format="counter" target="uses-capability"/></c>
<c>0..n</c>
<c>uses-module</c>
<c><xref format="counter" target="uses-module"/></c>
<c>0..n</c>
<c>uses-package</c>
<c><xref format="counter" target="uses-package"/></c>
<c>0..n</c>
<c>yang-package-version</c>
<c><xref format="counter" target="yang-package-version"/></c>
<c>0..1</c>
</texttable>
<?rfc compact="no"?></section>
</section>
<section title="The "yang-package-version" Statement" anchor="yang-package-version">
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="The "uses-package" Statement" anchor="uses-package">
<t>
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.
</t>
<t>
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.
</t>
<t>
The "uses‑revision" sub-statement is required, and identifies the revision
of the package used.
</t>
<section title="The "uses-package" Substatements">
<?rfc compact="yes"?><texttable title="uses-package Substatements">
<ttcol align='left'> Substatement</ttcol>
<ttcol align='left'>Reference</ttcol>
<ttcol align='left'>Cardinality</ttcol>
<c>description</c>
<c>RFC 6020bis, 7.19.3</c>
<c>0..1</c>
<c>reference</c>
<c>RFC 6020bis, 7.19.4</c>
<c>0..1</c>
<c>uses-revision</c>
<c><xref format="counter" target="uses-revision"/></c>
<c>1</c>
</texttable>
<?rfc compact="no"?></section>
</section>
<section title="The "uses-revision" Statement" anchor="uses-revision">
<t>
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.
</t>
</section>
<section title="The "imports-module" Statement" anchor="imports-module">
<t>
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.
</t>
<t>
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.
</t>
<section title="The "imports-module" Substatements">
<?rfc compact="yes"?><texttable title="imports-module Substatements">
<ttcol align='left'> Substatement</ttcol>
<ttcol align='left'>Reference</ttcol>
<ttcol align='left'>Cardinality</ttcol>
<c>description</c>
<c>RFC 6020bis, 7.19.3</c>
<c>0..1</c>
<c>reference</c>
<c>RFC 6020bis, 7.19.4</c>
<c>0..1</c>
<c>uses-revision</c>
<c><xref format="counter" target="uses-revision"/></c>
<c>1..n</c>
</texttable>
<?rfc compact="no"?></section>
</section>
<section title="The "uses-module" Statement" anchor="uses-module">
<t>
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.
</t>
<t>
The "uses‑revision" sub-statement is required, and identifies the revision
of the module used.
</t>
<section title="The "uses-module" Substatements">
<?rfc compact="yes"?><texttable title="uses-module Substatements">
<ttcol align='left'> Substatement</ttcol>
<ttcol align='left'>Reference</ttcol>
<ttcol align='left'>Cardinality</ttcol>
<c>description</c>
<c>RFC 6020bis, 7.19.3</c>
<c>0..1</c>
<c>reference</c>
<c>RFC 6020bis, 7.19.4</c>
<c>0..1</c>
<c>uses-revision</c>
<c><xref format="counter" target="uses-revision"/></c>
<c>1</c>
<c>uses-feature</c>
<c><xref format="counter" target="uses-feature"/></c>
<c>0..n</c>
</texttable>
<?rfc compact="no"?></section>
</section>
<section title="The "uses-feature" Statement" anchor="uses-feature">
<t>
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.
</t>
<section title="The "uses-feature" Substatements">
<?rfc compact="yes"?><texttable title="uses-feature Substatements">
<ttcol align='left'> Substatement</ttcol>
<ttcol align='left'>Reference</ttcol>
<ttcol align='left'>Cardinality</ttcol>
<c>description</c>
<c>RFC 6020bis, 7.19.3</c>
<c>0..1</c>
<c>reference</c>
<c>RFC 6020bis, 7.19.4</c>
<c>0..1</c>
</texttable>
<?rfc compact="no"?></section>
</section>
<section title="The "uses-capability" Statement" anchor="uses-capability">
<t>
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
that is used, and is followed by a block of substatements that
describe the protocol capability usage within the YANG package.
</t>
<section title="The "uses-capability" Substatements">
<?rfc compact="yes"?><texttable title="uses-capability Substatements">
<ttcol align='left'> Substatement</ttcol>
<ttcol align='left'>Reference</ttcol>
<ttcol align='left'>Cardinality</ttcol>
<c>description</c>
<c>RFC 6020bis, 7.19.3</c>
<c>0..1</c>
<c>reference</c>
<c>RFC 6020bis, 7.19.4</c>
<c>0..1</c>
<c>uses-parameter</c>
<c><xref format="counter" target="uses-parameter"/></c>
<c>0..n</c>
</texttable>
<?rfc compact="no"?></section>
</section>
<section title="The "uses-parameter" Statement" anchor="uses-parameter">
<t>
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.
</t>
<t>
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.
</t>
<t>
If this parameter appears more than once within a
"uses‑capability" statement then all the specified parameters are
used in the YANG package.
</t>
<section title="The "uses-parameter" Substatements">
<?rfc compact="yes"?><texttable title="uses-parameter Substatements">
<ttcol align='left'> Substatement</ttcol>
<ttcol align='left'>Reference</ttcol>
<ttcol align='left'>Cardinality</ttcol>
<c>description</c>
<c>RFC 6020bis, 7.19.3</c>
<c>0..1</c>
<c>reference</c>
<c>RFC 6020bis, 7.19.4</c>
<c>0..1</c>
<c>uses-value</c>
<c><xref format="counter" target="uses-value"/></c>
<c>0..n</c>
</texttable>
<?rfc compact="no"?> <t>
Usage Example:
</t>
<figure>
<artwork><![CDATA[
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";
}
}
}
]]></artwork>
</figure>
</section>
</section>
<section title="The "uses-value" Statement" anchor="uses-value">
<t>
The "uses‑value" statement is used to indicate a parameter value
used in the parent "uses‑capability" statement.
</t>
<t>
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.
</t>
<section title="The "uses-value" Substatements">
<?rfc compact="yes"?><texttable title="uses-value Substatements">
<ttcol align='left'> Substatement</ttcol>
<ttcol align='left'>Reference</ttcol>
<ttcol align='left'>Cardinality</ttcol>
<c>description</c>
<c>RFC 6020bis, 7.19.3</c>
<c>0..1</c>
<c>reference</c>
<c>RFC 6020bis, 7.19.4</c>
<c>0..1</c>
</texttable>
<?rfc compact="no"?> <t>
Usage Example
</t>
<figure>
<artwork><![CDATA[
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.";
}
}
}
}
]]></artwork>
</figure>
</section>
</section>
</section>
<section title="Updating a YANG Package">
<t>
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.
</t>
</section>
<section title="YANG Package Identifier">
<t>
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.
</t>
<t>
The YANG Package Identifier MUST match the rule for a "pkg‑uri":
</t>
<figure>
<artwork><![CDATA[
pkg-uri = yang-pkg-uri parameter-list
parameter-list = "?" pkg-parameter "&" rev-parameter
pkg-parameter = "name=" package-name
rev-parameter = "rev=" revision-date
]]></artwork>
</figure>
<t>
Where:
</t>
<t>
<list style="symbols">
<t>
"yang‑pkg‑uri" is the IANA-assigned URI to identify a YANG package
</t>
<t>
"package‑name" is the name of the YANG package
</t>
<t>
"revision‑date" is the revision date of the YANG package
</t>
</list>
</t>
<t>
Both parameters MUST be present in the YANG Package Identifier.
</t>
<t>
Example: (wrapped for display purposes only)
</t>
<figure>
<artwork><![CDATA[
urn:ietf:params:xml:ns:yang:pkg?name=example-routing-pkg
&rev=2015-07-01
]]></artwork>
</figure>
</section>
<section title="YANG Package ABNF">
<t>
The following ABNF grammar is defined in accordance with <xref target="RFC5234"/>
and <xref target="RFC7405"/>.
</t>
<t>
Within the ABNF grammar, unordered statements are marked with
comments.
</t>
<t>
This grammar assumes that the scanner replaces YANG comments with a
single space character.
</t>
<figure>
<artwork><![CDATA[
<CODE BEGINS> file "yang-package.abnf"
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
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)
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)
"}")
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
]]></artwork>
</figure>
<figure>
<artwork><![CDATA[
<CODE ENDS>
]]></artwork>
</figure>
</section>
<section title="IANA Considerations">
<t>
TODO: The YANG Package Identifier URI needs to be registered
</t>
</section>
<section title="Security Considerations">
<t>
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.
</t>
<t>
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.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<organization>Harvard University</organization>
</author>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<format type="TXT" octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt"/>
</reference>
<reference anchor='RFC5234'>
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author initials='D.' surname='Crocker' fullname='D. Crocker'>
<organization /></author>
<author initials='P.' surname='Overell' fullname='P. Overell'>
<organization /></author>
<date year='2008' month='January' />
<abstract>
<t>Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='STD' value='68' />
<seriesInfo name='RFC' value='5234' />
<format type='TXT' octets='26359' target='http://www.rfc-editor.org/rfc/rfc5234.txt' />
</reference>
<reference anchor='I-D.ietf-netmod-rfc6020bis'>
<front>
<title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
<author initials='M' surname='Bjorklund' fullname='Martin Bjorklund'>
<organization />
</author>
<date month='July' day='5' year='2015' />
<abstract><t>YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. This document obsoletes RFC 6020.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-netmod-rfc6020bis-06' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-netmod-rfc6020bis-06.txt' />
</reference>
<reference anchor='RFC7405'>
<front>
<title>Case-Sensitive String Support in ABNF</title>
<author initials='P.' surname='Kyzivat' fullname='P. Kyzivat'>
<organization /></author>
<date year='2014' month='December' />
<abstract>
<t>This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner.</t></abstract></front>
<seriesInfo name='RFC' value='7405' />
<format type='TXT' octets='6668' target='http://www.rfc-editor.org/rfc/rfc7405.txt' />
</reference>
</references>
<references title="Informative References">
<reference anchor='RFC6241'>
<front>
<title>Network Configuration Protocol (NETCONF)</title>
<author initials='R.' surname='Enns' fullname='R. Enns' role="editor">
<organization/>
</author>
<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund' role="editor">
<organization/>
</author>
<author initials='J.' surname='Schoenwaelder' fullname='J. Schoenwaelder' role="editor">
<organization/>
</author>
<author initials='A.' surname='Bierman' fullname='A. Bierman' role="editor">
<organization/>
</author>
<date year='2011' month='June'/>
</front>
<seriesInfo name='RFC' value='6241'/>
</reference>
<reference anchor='RFC7223'>
<front>
<title>A YANG Data Model for Interface Management</title>
<author initials='M.' surname='Bjorklund' fullname='M. Bjorklund'>
<organization /></author>
<date year='2014' month='May' />
<abstract>
<t>This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes configuration data and state data (status information and counters for the collection of statistics).</t></abstract></front>
<seriesInfo name='RFC' value='7223' />
<format type='TXT' octets='70537' target='http://www.rfc-editor.org/rfc/rfc7223.txt' />
</reference>
<reference anchor="I-D.bogdanovic-netmod-yang-model-classification">
<front>
<title>YANG model classification</title>
<author initials="D" surname="Bogdanovic" fullname="Dean Bogdanovic">
<organization/>
</author>
<author initials="B" surname="Claise" fullname="Benoit Claise">
<organization/>
</author>
<author initials="C" surname="Moberg" fullname="Carl Moberg">
<organization/>
</author>
<date month="June" day="3" year="2015"/>
<abstract>
<t>
The YANG [RFC6020] data modeling language is currently being considered for a wide variety of applications throughout the networking industry at large. Many standards organizations and open source projects are using YANG to develop and publish models of configuration, state data and operations for a wide variety of networking applications. At the same time, there is currently no well-known terminology to categorize the various types of YANG models that are being worked on. A consistent terminology would help with the categorization of models, assist in the analysis the YANG data modeling efforts in the IETF and in other places, and bring clarity to the YANG-related discussions between the different groups. This document describes a set of concepts and associated terms to support consistent classification of YANG models.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-bogdanovic-netmod-yang-model-classification-03"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-bogdanovic-netmod-yang-model-classification-03.txt"/>
</reference>
<reference anchor="I-D.ietf-netconf-restconf">
<front>
<title>RESTCONF Protocol</title>
<author initials="A." surname="Bierman" fullname="A. Bierman">
<organization>YumaWorks</organization>
</author>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
<organization>Tail-f Systems</organization>
</author>
<author initials="K." surname="Watsen" fullname="K. Watsen">
<organization>Juniper Networks</organization>
</author>
<date year="2015" month="June"/>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-netconf-restconf-06"/>
<format type='TXT'
target='http://www.ietf.org/id/draft-ietf-netconf-restconf-06.txt'/>
</reference>
<!-- END RESTCONF -->
</references>
<section title="Change Log">
<figure>
<artwork><![CDATA[
-- RFC Ed.: remove this section before publication.
]]></artwork>
</figure>
<section title="bierman-yang-conformance-03 to bierman-yang-package-00">
<t>
<list style="symbols">
<t>
removed all mention of YANG conformance since YANG packages do not
specify new YANG conformance mechanisms.
</t>
</list>
</t>
</section>
</section>
</back></rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:12:00 |