--- 1/draft-ietf-netmod-rfc6020bis-13.txt 2016-06-17 06:16:19.432876044 -0700 +++ 2/draft-ietf-netmod-rfc6020bis-14.txt 2016-06-17 06:16:19.792884885 -0700 @@ -1,18 +1,18 @@ Network Working Group M. Bjorklund, Ed. Internet-Draft Tail-f Systems -Intended status: Standards Track June 10, 2016 -Expires: December 12, 2016 +Intended status: Standards Track June 17, 2016 +Expires: December 19, 2016 The YANG 1.1 Data Modeling Language - draft-ietf-netmod-rfc6020bis-13 + draft-ietf-netmod-rfc6020bis-14 Abstract 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 @@ -27,21 +27,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 December 12, 2016. + This Internet-Draft will expire on December 19, 2016. 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 @@ -86,21 +86,21 @@ 5. Language Concepts . . . . . . . . . . . . . . . . . . . . . . 29 5.1. Modules and Submodules . . . . . . . . . . . . . . . . . 29 5.1.1. Import and Include by Revision . . . . . . . . . . . 31 5.1.2. Module Hierarchies . . . . . . . . . . . . . . . . . 32 5.2. File Layout . . . . . . . . . . . . . . . . . . . . . . . 33 5.3. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 34 5.3.1. YANG XML Namespace . . . . . . . . . . . . . . . . . 34 5.4. Resolving Grouping, Type, and Identity Names . . . . . . 34 5.5. Nested Typedefs and Groupings . . . . . . . . . . . . . . 34 5.6. Conformance . . . . . . . . . . . . . . . . . . . . . . . 35 - 5.6.1. Basic Behavior . . . . . . . . . . . . . . . . . . . 36 + 5.6.1. Basic Behavior . . . . . . . . . . . . . . . . . . . 35 5.6.2. Optional Features . . . . . . . . . . . . . . . . . . 36 5.6.3. Deviations . . . . . . . . . . . . . . . . . . . . . 36 5.6.4. Announcing Conformance Information in NETCONF . . . . 37 5.6.5. Implementing a Module . . . . . . . . . . . . . . . . 38 5.7. Datastore Modification . . . . . . . . . . . . . . . . . 41 6. YANG Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 41 6.1. Lexical Tokenization . . . . . . . . . . . . . . . . . . 42 6.1.1. Comments . . . . . . . . . . . . . . . . . . . . . . 42 6.1.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 42 6.1.3. Quoting . . . . . . . . . . . . . . . . . . . . . . . 42 @@ -1543,22 +1543,21 @@ Grouping, type, and identity names are resolved in the context in which they are defined, rather than the context in which they are used. Users of groupings, typedefs, and identities are not required to import modules or include submodules to satisfy all references made by the original definition. This behaves like static scoping in a conventional programming language. 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 resolved in the context of the original module, not the second - module. There is no ambiguity if both modules define the type, since - there is no ambiguity. + module. There is no ambiguity if both modules define the type. 5.5. Nested Typedefs and Groupings Typedefs and groupings may appear nested under many YANG statements, allowing these to be lexically scoped by the statement hierarchy under which they appear. This allows types and groupings to be defined near where they are used, rather than placing them at the top level of the hierarchy. The close proximity increases readability. Scoping also allows types to be defined without concern for naming @@ -2961,22 +2960,34 @@ When a datastore is validated, all "must" constraints are conceptually evaluated once for each node in the accessible tree (see Section 6.4.1). All such constraints MUST evaluate to "true" for the data to be valid. The XPath expression is conceptually evaluated in the following 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 - "must" statement is defined. + o If the "must" statement is a substatement of a "notification" + 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 using the standard XPath rules. Note that since all leaf values in the data tree are conceptually stored in their canonical form (see Section 9.1), any XPath comparisons are done on the canonical value. Also note that the XPath expression is conceptually evaluated. This means that an implementation does not have to use an XPath evaluator @@ -6753,22 +6765,22 @@ 9.9. The leafref Built-In Type The leafref type is restricted to the value space of some leaf or leaf-list node in the schema tree and optionally further restricted by corresponding instance nodes in the data tree. The "path" 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 node is the value space of the referred node. 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 - in use (see Section 7.6.1 and Section 7.7.2), of the referred schema + MUST exist a node in the data tree, or a node with a default value in + 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 in a valid data tree. If the referring node represents configuration data, and the "require-instance" property (Section 9.9.3) is "true", the referred node MUST also represent configuration. There MUST NOT be any circular chains of leafrefs. If the leaf that the leafref refers to is conditional based on one or @@ -6794,22 +6806,22 @@ present if a list has multiple keys. The syntax is formally defined by the rule "path-arg" in Section 14. The predicates are only used when more than one key reference is 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 list is needed. In these cases, multiple leafrefs are typically specified, and predicates are used to tie them together. The "path" expression evaluates to a node set consisting of zero, - one, or more nodes. If the leaf with the leafref type represents - configuration data, this node set MUST be non-empty. + one, or more nodes. If the "require-instance" property is "true", + this node set MUST be non-empty. The "path" XPath expression is conceptually evaluated in the following context, in addition to the definition in Section 6.4.1: 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 references the typedef. o Otherwise, the context node is the node in the data tree for which the "path" statement is defined.