YANG Data ExtensionsYumaWorksandy@yumaworks.comTail-f Systemsmbj@tail-f.comJuniper Networkskwatsen@juniper.net
This document describes YANG mechanisms for
defining abstract data structures with YANG.
It is intended to replace and extend
the "yang‑data" extension statement
defined in RFC 8040.
There is a need for standard mechanisms to allow the
definition of abstract data that is not intended to
be implemented as configuration or operational state.
The "yang‑data" extension statement from RFC 8040
is defined for this purpose, however it is limited in its
functionality.
The intended use of the "yang‑data" extension is to model all or part
of a protocol message, such as the "errors" definition in
ietf-restconf.yang , or the contents of a file. However,
protocols are often layered such that the header or payload portions
of the message can be extended by external documents. The YANG
statements that model a protocol need to support this extensibility
that is already found in that protocol.
This document defines a new YANG extension statement called
"augment‑yang‑data", which allows abstract data structures to be
augmented from external modules, similar to the existing YANG
"augment" statement. Note that "augment" cannot be used to augment a
yang data structure since a YANG compiler or other tool is not
required to understand the "yang‑data" extension.
The "yang‑data" extension from has been copied here and
updated to be more flexible. There is no longer a requirement for the
"yang‑data" statement to result in exactly one container object.
There is no longer an assumption that a yang data structure can only
be used as a top-level abstraction, instead of nested within some
other data structure.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
.
The following terms are used within this document:
yang data structure: A data structure defined with the "yang‑data"
statement.
The following terms are defined in the
Network Management Datastore Architecture
(NMDA) .
and are not redefined here:
configuration
operational state
The following terms are defined in :
absolute-schema-nodeid
container
data definition statement
data node
leaf
leaf-list
list
This document places restrictions on the "yang‑data" external
statements that can be used with the "yang‑data" and
"augment‑yang‑data" extensions. The conceptual data definitions
are considered to be in the same identifier namespace
as defined in section 6.2.1 of . In particular,
bullet 7:
This means that conceptual data defined with the "yang‑data"
or "augment‑yang‑data" statements cannot have the same local-name
as sibling nodes from regular YANG data definition statements or
other "yang‑data" or "augment‑yang‑data" statements.
This does not mean a yang data structure has to be used as
a top-level protocol message or other top-level data structure.
A yang data structure does not have to result in a single container.
The "ietf‑yang‑data‑ext" module defines the "augment‑yang‑data" extension
to augment conceptual data already defined with the
"yang‑data" extension. The RESTCONF "yang‑data" extension has been moved
to this document and updated.
RFC Ed.: update the date below with the date of RFC publication and
remove this note.
<CODE BEGINS> file "ietf-yang-data-ext@2018-02-19.yang"<CODE ENDS>
TBD
This document defines YANG extensions that are used to define
conceptual YANG data. It does not introduce any new vulnerabilities
beyond those specified in YANG 1.1 .
Key words for use in RFCs to Indicate Requirement LevelsHarvard UniversityIn 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.The YANG 1.1 Data Modeling Language
YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).
RESTCONF Protocol
This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).
Network Management Datastore Architecture
Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as NETCONF and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model.
Is there a need for a separate grouping and uses mechanism for yang-data?
Currently only real grouping-stmt and uses-stmt are used.
Is there a need for a special-purpose extension to define yang-data for
the contents of the <error‑info> node in NETCONF <rpc‑error> and
RESTCONF <errors> responses? This node is defined with anyxml so
there is no way for a YANG tool to use real schema nodes, based on the
RPC operation being requested or the error-app-tag that is being returned.