draft-ietf-netmod-rfc6020bis-13.txt   draft-ietf-netmod-rfc6020bis-14.txt 
Network Working Group M. Bjorklund, Ed. Network Working Group M. Bjorklund, Ed.
Internet-Draft Tail-f Systems Internet-Draft Tail-f Systems
Intended status: Standards Track June 10, 2016 Intended status: Standards Track June 17, 2016
Expires: December 12, 2016 Expires: December 19, 2016
The YANG 1.1 Data Modeling Language The YANG 1.1 Data Modeling Language
draft-ietf-netmod-rfc6020bis-13 draft-ietf-netmod-rfc6020bis-14
Abstract Abstract
YANG is a data modeling language used to model configuration data, YANG is a data modeling language used to model configuration data,
state data, remote procedure calls, and notifications for network state data, remote procedure calls, and notifications for network
management protocols. This document describes the syntax and management protocols. This document describes the syntax and
semantics of version 1.1 of the YANG language. YANG version 1.1 is a semantics of version 1.1 of the YANG language. YANG version 1.1 is a
maintenance release of the YANG language, addressing ambiguities and maintenance release of the YANG language, addressing ambiguities and
defects in the original specification. There are a small number of defects in the original specification. There are a small number of
backward incompatibilities from YANG version 1. This document also backward incompatibilities from YANG version 1. This document also
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 12, 2016. This Internet-Draft will expire on December 19, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 51 skipping to change at page 2, line 51
5. Language Concepts . . . . . . . . . . . . . . . . . . . . . . 29 5. Language Concepts . . . . . . . . . . . . . . . . . . . . . . 29
5.1. Modules and Submodules . . . . . . . . . . . . . . . . . 29 5.1. Modules and Submodules . . . . . . . . . . . . . . . . . 29
5.1.1. Import and Include by Revision . . . . . . . . . . . 31 5.1.1. Import and Include by Revision . . . . . . . . . . . 31
5.1.2. Module Hierarchies . . . . . . . . . . . . . . . . . 32 5.1.2. Module Hierarchies . . . . . . . . . . . . . . . . . 32
5.2. File Layout . . . . . . . . . . . . . . . . . . . . . . . 33 5.2. File Layout . . . . . . . . . . . . . . . . . . . . . . . 33
5.3. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 34 5.3. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 34
5.3.1. YANG XML Namespace . . . . . . . . . . . . . . . . . 34 5.3.1. YANG XML Namespace . . . . . . . . . . . . . . . . . 34
5.4. Resolving Grouping, Type, and Identity Names . . . . . . 34 5.4. Resolving Grouping, Type, and Identity Names . . . . . . 34
5.5. Nested Typedefs and Groupings . . . . . . . . . . . . . . 34 5.5. Nested Typedefs and Groupings . . . . . . . . . . . . . . 34
5.6. Conformance . . . . . . . . . . . . . . . . . . . . . . . 35 5.6. Conformance . . . . . . . . . . . . . . . . . . . . . . . 35
5.6.1. Basic Behavior . . . . . . . . . . . . . . . . . . . 36 5.6.1. Basic Behavior . . . . . . . . . . . . . . . . . . . 35
5.6.2. Optional Features . . . . . . . . . . . . . . . . . . 36 5.6.2. Optional Features . . . . . . . . . . . . . . . . . . 36
5.6.3. Deviations . . . . . . . . . . . . . . . . . . . . . 36 5.6.3. Deviations . . . . . . . . . . . . . . . . . . . . . 36
5.6.4. Announcing Conformance Information in NETCONF . . . . 37 5.6.4. Announcing Conformance Information in NETCONF . . . . 37
5.6.5. Implementing a Module . . . . . . . . . . . . . . . . 38 5.6.5. Implementing a Module . . . . . . . . . . . . . . . . 38
5.7. Datastore Modification . . . . . . . . . . . . . . . . . 41 5.7. Datastore Modification . . . . . . . . . . . . . . . . . 41
6. YANG Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 41 6. YANG Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.1. Lexical Tokenization . . . . . . . . . . . . . . . . . . 42 6.1. Lexical Tokenization . . . . . . . . . . . . . . . . . . 42
6.1.1. Comments . . . . . . . . . . . . . . . . . . . . . . 42 6.1.1. Comments . . . . . . . . . . . . . . . . . . . . . . 42
6.1.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 42 6.1.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 42
6.1.3. Quoting . . . . . . . . . . . . . . . . . . . . . . . 42 6.1.3. Quoting . . . . . . . . . . . . . . . . . . . . . . . 42
skipping to change at page 34, line 44 skipping to change at page 34, line 44
Grouping, type, and identity names are resolved in the context in Grouping, type, and identity names are resolved in the context in
which they are defined, rather than the context in which they are which they are defined, rather than the context in which they are
used. Users of groupings, typedefs, and identities are not required used. Users of groupings, typedefs, and identities are not required
to import modules or include submodules to satisfy all references to import modules or include submodules to satisfy all references
made by the original definition. This behaves like static scoping in made by the original definition. This behaves like static scoping in
a conventional programming language. a conventional programming language.
For example, if a module defines a grouping in which a type is For example, if a module defines a grouping in which a type is
referenced, when the grouping is used in a second module, the type is referenced, when the grouping is used in a second module, the type is
resolved in the context of the original module, not the second resolved in the context of the original module, not the second
module. There is no ambiguity if both modules define the type, since module. There is no ambiguity if both modules define the type.
there is no ambiguity.
5.5. Nested Typedefs and Groupings 5.5. Nested Typedefs and Groupings
Typedefs and groupings may appear nested under many YANG statements, Typedefs and groupings may appear nested under many YANG statements,
allowing these to be lexically scoped by the statement hierarchy allowing these to be lexically scoped by the statement hierarchy
under which they appear. This allows types and groupings to be under which they appear. This allows types and groupings to be
defined near where they are used, rather than placing them at the top defined near where they are used, rather than placing them at the top
level of the hierarchy. The close proximity increases readability. level of the hierarchy. The close proximity increases readability.
Scoping also allows types to be defined without concern for naming Scoping also allows types to be defined without concern for naming
skipping to change at page 66, line 46 skipping to change at page 66, line 46
When a datastore is validated, all "must" constraints are When a datastore is validated, all "must" constraints are
conceptually evaluated once for each node in the accessible tree (see conceptually evaluated once for each node in the accessible tree (see
Section 6.4.1). Section 6.4.1).
All such constraints MUST evaluate to "true" for the data to be All such constraints MUST evaluate to "true" for the data to be
valid. valid.
The XPath expression is conceptually evaluated in the following The XPath expression is conceptually evaluated in the following
context, in addition to the definition in Section 6.4.1: context, in addition to the definition in Section 6.4.1:
o The context node is the node in the accessible tree for which the o If the "must" statement is a substatement of a "notification"
"must" statement is defined. statement, the context node is the node representing the
notification in the accessible tree.
o If the "must" statement is a substatement of an "input" statement,
the context node is the node representing the operation in the
accessible tree.
o If the "must" statement is a substatement of an "output"
statement, the context node is the node representing the operation
in the accessible tree.
o Otherwise, the context node is the node in the accessible tree for
which the "must" statement is defined.
The result of the XPath expression is converted to a boolean value The result of the XPath expression is converted to a boolean value
using the standard XPath rules. using the standard XPath rules.
Note that since all leaf values in the data tree are conceptually Note that since all leaf values in the data tree are conceptually
stored in their canonical form (see Section 9.1), any XPath stored in their canonical form (see Section 9.1), any XPath
comparisons are done on the canonical value. comparisons are done on the canonical value.
Also note that the XPath expression is conceptually evaluated. This Also note that the XPath expression is conceptually evaluated. This
means that an implementation does not have to use an XPath evaluator means that an implementation does not have to use an XPath evaluator
skipping to change at page 150, line 46 skipping to change at page 150, line 46
9.9. The leafref Built-In Type 9.9. The leafref Built-In Type
The leafref type is restricted to the value space of some leaf or The leafref type is restricted to the value space of some leaf or
leaf-list node in the schema tree and optionally further restricted leaf-list node in the schema tree and optionally further restricted
by corresponding instance nodes in the data tree. The "path" by corresponding instance nodes in the data tree. The "path"
substatement (Section 9.9.2) is used to identify the referred leaf or substatement (Section 9.9.2) is used to identify the referred leaf or
leaf-list node in the schema tree. The value space of the referring leaf-list node in the schema tree. The value space of the referring
node is the value space of the referred node. node is the value space of the referred node.
If the "require-instance" property (Section 9.9.3) is "true", there If the "require-instance" property (Section 9.9.3) is "true", there
MUST exist an node in the data tree, or a node with a default value MUST exist a node in the data tree, or a node with a default value in
in use (see Section 7.6.1 and Section 7.7.2), of the referred schema use (see Section 7.6.1 and Section 7.7.2), of the referred schema
tree leaf or leaf-list node with the same value as the leafref value tree leaf or leaf-list node with the same value as the leafref value
in a valid data tree. in a valid data tree.
If the referring node represents configuration data, and the If the referring node represents configuration data, and the
"require-instance" property (Section 9.9.3) is "true", the referred "require-instance" property (Section 9.9.3) is "true", the referred
node MUST also represent configuration. node MUST also represent configuration.
There MUST NOT be any circular chains of leafrefs. There MUST NOT be any circular chains of leafrefs.
If the leaf that the leafref refers to is conditional based on one or If the leaf that the leafref refers to is conditional based on one or
skipping to change at page 151, line 41 skipping to change at page 151, line 41
present if a list has multiple keys. The syntax is formally defined present if a list has multiple keys. The syntax is formally defined
by the rule "path-arg" in Section 14. by the rule "path-arg" in Section 14.
The predicates are only used when more than one key reference is The predicates are only used when more than one key reference is
needed to uniquely identify a leaf instance. This occurs if a list needed to uniquely identify a leaf instance. This occurs if a list
has multiple keys, or a reference to a leaf other than the key in a has multiple keys, or a reference to a leaf other than the key in a
list is needed. In these cases, multiple leafrefs are typically list is needed. In these cases, multiple leafrefs are typically
specified, and predicates are used to tie them together. specified, and predicates are used to tie them together.
The "path" expression evaluates to a node set consisting of zero, The "path" expression evaluates to a node set consisting of zero,
one, or more nodes. If the leaf with the leafref type represents one, or more nodes. If the "require-instance" property is "true",
configuration data, this node set MUST be non-empty. this node set MUST be non-empty.
The "path" XPath expression is conceptually evaluated in the The "path" XPath expression is conceptually evaluated in the
following context, in addition to the definition in Section 6.4.1: following context, in addition to the definition in Section 6.4.1:
o If the "path" statement is defined within a typedef, the context o If the "path" statement is defined within a typedef, the context
node is the leaf or leaf-list node in the data tree that node is the leaf or leaf-list node in the data tree that
references the typedef. references the typedef.
o Otherwise, the context node is the node in the data tree for which o Otherwise, the context node is the node in the data tree for which
the "path" statement is defined. the "path" statement is defined.
 End of changes. 8 change blocks. 
13 lines changed or deleted 24 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/