draft-ietf-netmod-yang-08.txt   draft-ietf-netmod-yang-09.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 October 22, 2009 Intended status: Standards Track December 1, 2009
Expires: April 25, 2010 Expires: June 4, 2010
YANG - A data modeling language for NETCONF YANG - A data modeling language for NETCONF
draft-ietf-netmod-yang-08 draft-ietf-netmod-yang-09
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 25, 2010. This Internet-Draft will expire on June 4, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 46 skipping to change at page 2, line 46
5.3. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 30 5.3. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 30
5.3.1. YANG XML Namespace . . . . . . . . . . . . . . . . . 30 5.3.1. YANG XML Namespace . . . . . . . . . . . . . . . . . 30
5.4. Resolving Grouping, Type, and Identity Names . . . . . . 30 5.4. Resolving Grouping, Type, and Identity Names . . . . . . 30
5.5. Nested Typedefs and Groupings . . . . . . . . . . . . . . 30 5.5. Nested Typedefs and Groupings . . . . . . . . . . . . . . 30
5.6. Conformance . . . . . . . . . . . . . . . . . . . . . . . 31 5.6. Conformance . . . . . . . . . . . . . . . . . . . . . . . 31
5.6.1. Basic Behavior . . . . . . . . . . . . . . . . . . . 32 5.6.1. Basic Behavior . . . . . . . . . . . . . . . . . . . 32
5.6.2. Optional Features . . . . . . . . . . . . . . . . . . 32 5.6.2. Optional Features . . . . . . . . . . . . . . . . . . 32
5.6.3. Deviations . . . . . . . . . . . . . . . . . . . . . 32 5.6.3. Deviations . . . . . . . . . . . . . . . . . . . . . 32
5.6.4. Announcing Conformance Information in the <hello> 5.6.4. Announcing Conformance Information in the <hello>
Message . . . . . . . . . . . . . . . . . . . . . . . 33 Message . . . . . . . . . . . . . . . . . . . . . . . 33
5.7. Data Store Modification . . . . . . . . . . . . . . . . . 35
6. YANG syntax . . . . . . . . . . . . . . . . . . . . . . . . . 36 6. YANG syntax . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.1. Lexicographical Tokenization . . . . . . . . . . . . . . 36 6.1. Lexicographical Tokenization . . . . . . . . . . . . . . 36
6.1.1. Comments . . . . . . . . . . . . . . . . . . . . . . 36 6.1.1. Comments . . . . . . . . . . . . . . . . . . . . . . 36
6.1.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 36 6.1.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 36
6.1.3. Quoting . . . . . . . . . . . . . . . . . . . . . . . 36 6.1.3. Quoting . . . . . . . . . . . . . . . . . . . . . . . 36
6.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 38 6.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 38
6.2.1. Identifiers and their namespaces . . . . . . . . . . 38 6.2.1. Identifiers and their namespaces . . . . . . . . . . 38
6.3. Statements . . . . . . . . . . . . . . . . . . . . . . . 39 6.3. Statements . . . . . . . . . . . . . . . . . . . . . . . 39
6.3.1. Language Extensions . . . . . . . . . . . . . . . . . 39 6.3.1. Language Extensions . . . . . . . . . . . . . . . . . 39
6.4. XPath Evaluations . . . . . . . . . . . . . . . . . . . . 39 6.4. XPath Evaluations . . . . . . . . . . . . . . . . . . . . 39
6.4.1. XPath Context . . . . . . . . . . . . . . . . . . . . 40 6.4.1. XPath Context . . . . . . . . . . . . . . . . . . . . 40
6.5. Schema Node Identifier . . . . . . . . . . . . . . . . . 40 6.5. Schema Node Identifier . . . . . . . . . . . . . . . . . 40
7. YANG Statements . . . . . . . . . . . . . . . . . . . . . . . 42 7. YANG Statements . . . . . . . . . . . . . . . . . . . . . . . 42
7.1. The module Statement . . . . . . . . . . . . . . . . . . 42 7.1. The module Statement . . . . . . . . . . . . . . . . . . 42
7.1.1. The module's Substatements . . . . . . . . . . . . . 43 7.1.1. The module's Substatements . . . . . . . . . . . . . 43
skipping to change at page 4, line 12 skipping to change at page 4, line 13
7.6.6. XML Mapping Rules . . . . . . . . . . . . . . . . . . 62 7.6.6. XML Mapping Rules . . . . . . . . . . . . . . . . . . 62
7.6.7. NETCONF <edit-config> Operations . . . . . . . . . . 62 7.6.7. NETCONF <edit-config> Operations . . . . . . . . . . 62
7.6.8. Usage Example . . . . . . . . . . . . . . . . . . . . 63 7.6.8. Usage Example . . . . . . . . . . . . . . . . . . . . 63
7.7. The leaf-list Statement . . . . . . . . . . . . . . . . . 63 7.7. The leaf-list Statement . . . . . . . . . . . . . . . . . 63
7.7.1. Ordering . . . . . . . . . . . . . . . . . . . . . . 64 7.7.1. Ordering . . . . . . . . . . . . . . . . . . . . . . 64
7.7.2. The leaf-list's Substatements . . . . . . . . . . . . 65 7.7.2. The leaf-list's Substatements . . . . . . . . . . . . 65
7.7.3. The min-elements Statement . . . . . . . . . . . . . 65 7.7.3. The min-elements Statement . . . . . . . . . . . . . 65
7.7.4. The max-elements Statement . . . . . . . . . . . . . 65 7.7.4. The max-elements Statement . . . . . . . . . . . . . 65
7.7.5. The ordered-by Statement . . . . . . . . . . . . . . 66 7.7.5. The ordered-by Statement . . . . . . . . . . . . . . 66
7.7.6. XML Mapping Rules . . . . . . . . . . . . . . . . . . 66 7.7.6. XML Mapping Rules . . . . . . . . . . . . . . . . . . 66
7.7.7. NETCONF <edit-config> operations . . . . . . . . . . 66 7.7.7. NETCONF <edit-config> operations . . . . . . . . . . 67
7.7.8. Usage Example . . . . . . . . . . . . . . . . . . . . 67 7.7.8. Usage Example . . . . . . . . . . . . . . . . . . . . 68
7.8. The list Statement . . . . . . . . . . . . . . . . . . . 69 7.8. The list Statement . . . . . . . . . . . . . . . . . . . 69
7.8.1. The list's Substatements . . . . . . . . . . . . . . 70 7.8.1. The list's Substatements . . . . . . . . . . . . . . 70
7.8.2. The list's key Statement . . . . . . . . . . . . . . 70 7.8.2. The list's key Statement . . . . . . . . . . . . . . 70
7.8.3. The list's unique Statement . . . . . . . . . . . . . 71 7.8.3. The list's unique Statement . . . . . . . . . . . . . 71
7.8.4. The list's Child Node Statements . . . . . . . . . . 72 7.8.4. The list's Child Node Statements . . . . . . . . . . 72
7.8.5. XML Mapping Rules . . . . . . . . . . . . . . . . . . 72 7.8.5. XML Mapping Rules . . . . . . . . . . . . . . . . . . 72
7.8.6. NETCONF <edit-config> operations . . . . . . . . . . 73 7.8.6. NETCONF <edit-config> operations . . . . . . . . . . 73
7.8.7. Usage Example . . . . . . . . . . . . . . . . . . . . 73 7.8.7. Usage Example . . . . . . . . . . . . . . . . . . . . 73
7.9. The choice Statement . . . . . . . . . . . . . . . . . . 77 7.9. The choice Statement . . . . . . . . . . . . . . . . . . 77
7.9.1. The choice's Substatements . . . . . . . . . . . . . 77 7.9.1. The choice's Substatements . . . . . . . . . . . . . 77
skipping to change at page 7, line 34 skipping to change at page 7, line 35
choice Statement . . . . . . . . . . . . . . . . . . . . 166 choice Statement . . . . . . . . . . . . . . . . . . . . 166
13.8. Error Message for the "insert" Operation . . . . . . . . 167 13.8. Error Message for the "insert" Operation . . . . . . . . 167
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 168 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 168
15. Security Considerations . . . . . . . . . . . . . . . . . . . 169 15. Security Considerations . . . . . . . . . . . . . . . . . . . 169
16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 170 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 170
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 171 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 171
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 172 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 172
18.1. Normative References . . . . . . . . . . . . . . . . . . 172 18.1. Normative References . . . . . . . . . . . . . . . . . . 172
18.2. Non-Normative References . . . . . . . . . . . . . . . . 173 18.2. Non-Normative References . . . . . . . . . . . . . . . . 173
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 174 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 174
A.1. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 174 A.1. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 174
A.2. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 174 A.2. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 174
A.3. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 174 A.3. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 174
A.4. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 174 A.4. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 175
A.5. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 175 A.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 175
A.6. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 175 A.6. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 175
A.7. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 176 A.7. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 176
A.8. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 176 A.8. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 176
A.9. Version -00 . . . . . . . . . . . . . . . . . . . . . . . 177 A.9. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 177
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 178 A.10. Version -00 . . . . . . . . . . . . . . . . . . . . . . . 178
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 179
1. Introduction 1. Introduction
YANG is a data modeling language used to model configuration and YANG is a data modeling language used to model configuration and
state data manipulated by the Network Configuration Protocol state data manipulated by the Network Configuration Protocol
(NETCONF) protocol, NETCONF remote procedure calls, and NETCONF (NETCONF) protocol, NETCONF remote procedure calls, and NETCONF
notifications. YANG is used to model the operations and content notifications. YANG is used to model the operations and content
layers of NETCONF (see the NETCONF Configuration Protocol [RFC4741], layers of NETCONF (see the NETCONF Configuration Protocol [RFC4741],
section 1.1). section 1.1).
skipping to change at page 36, line 5 skipping to change at page 35, line 14
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capability> <capability>
http://example.com/syslog?module=syslog&deviations=my-devs http://example.com/syslog?module=syslog&deviations=my-devs
</capability> </capability>
<capability> <capability>
http://example.com/my-deviations?module=my-devs http://example.com/my-deviations?module=my-devs
</capability> </capability>
</hello> </hello>
5.7. Data Store Modification
Data models may allow the server to alter the configuration data
store. A formal mechanism for specifying the circumstances where
these changes are allowed is out of scope for this specification.
6. YANG syntax 6. YANG syntax
The YANG syntax is similar to that of SMIng [RFC3780] and programming The YANG syntax is similar to that of SMIng [RFC3780] and programming
languages like C and C++. This C-like syntax was chosen specifically languages like C and C++. This C-like syntax was chosen specifically
for its readability, since YANG values the time and effort of the for its readability, since YANG values the time and effort of the
readers of models above those of modules writers and YANG tool-chain readers of models above those of modules writers and YANG tool-chain
developers. This section introduces the YANG syntax. developers. This section introduces the YANG syntax.
YANG modules use the UTF-8 [RFC3629] character encoding. YANG modules use the UTF-8 [RFC3629] character encoding.
skipping to change at page 55, line 36 skipping to change at page 55, line 36
| when | 7.19.5 | 0..1 | | when | 7.19.5 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.5.3. The must Statement 7.5.3. The must Statement
The "must" statement, which is optional, takes as an argument a The "must" statement, which is optional, takes as an argument a
string which contains an XPath expression. It is used to formally string which contains an XPath expression. It is used to formally
declare a constraint on valid data. The constraint is enforced declare a constraint on valid data. The constraint is enforced
according to the rules in Section 8. according to the rules in Section 8.
When a data store is validated, all "must" constraints are When a datastore is validated, all "must" constraints are
conceptually evaluated once for each corresponding instance in the conceptually evaluated once for each corresponding instance in the
data tree, and for all leafs with default values in use (see data tree, and for all leafs with default values in use (see
Section 7.6.1). If an instance does not exist in the data tree, and Section 7.6.1). If an instance does not exist in the data tree, and
it does not have a default value, its "must" statements are not it does not have a default value, its "must" statements are not
evaluated. evaluated.
All such constraints MUST evaluate to true for the data to be valid. All such constraints MUST evaluate to true for the data to be 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:
skipping to change at page 66, line 46 skipping to change at page 66, line 46
7.7.6. XML Mapping Rules 7.7.6. XML Mapping Rules
A leaf-list node is encoded as a series of XML elements. Each A leaf-list node is encoded as a series of XML elements. Each
element's name is the leaf-list's identifier, and its XML namespace element's name is the leaf-list's identifier, and its XML namespace
is the module's XML namespace. is the module's XML namespace.
The value of the leaf-list node is encoded to XML according to the The value of the leaf-list node is encoded to XML according to the
type, and sent as character data in the element. type, and sent as character data in the element.
The XML elements representing leaf-list entries MUST appear in the
order specified by the user if the leaf-list is "ordered-by user",
otherwise the order is implementation-dependent. The XML elements
representing leaf-list entries MAY be interleaved with other sibling
elements, unless the leaf-list defines RPC input or output
parameters.
See Section 7.7.8 for an example. See Section 7.7.8 for an example.
7.7.7. NETCONF <edit-config> operations 7.7.7. NETCONF <edit-config> operations
Leaf-list entries can be created and deleted, but not modified, Leaf-list entries can be created and deleted, but not modified,
through <edit-config>, by using the "operation" attribute in the through <edit-config>, by using the "operation" attribute in the
leaf-list entry's XML element. leaf-list entry's XML element.
In an "ordered-by user" leaf-list, the attributes "insert" and In an "ordered-by user" leaf-list, the attributes "insert" and
"value" in the YANG XML namespace (Section 5.3.1) can be used to "value" in the YANG XML namespace (Section 5.3.1) can be used to
skipping to change at page 73, line 11 skipping to change at page 73, line 11
The list's key nodes are encoded as subelements to the list's The list's key nodes are encoded as subelements to the list's
identifier element, in the same order as they are defined within the identifier element, in the same order as they are defined within the
key statement. key statement.
The rest of the list's child nodes are encoded as subelements to the The rest of the list's child nodes are encoded as subelements to the
list element, after the keys. If the list defines RPC input or list element, after the keys. If the list defines RPC input or
output parameters, the subelements are encoded in the same order as output parameters, the subelements are encoded in the same order as
they are defined within the list statement. Otherwise, the they are defined within the list statement. Otherwise, the
subelements are encoded in any order. subelements are encoded in any order.
The XML elements representing list entries MUST appear in the order
specified by the user if the list is "ordered-by user", otherwise the
order is implementation-dependent. The XML elements representing
list entries MAY be interleaved with other sibling elements, unless
the list defines RPC input or output parameters.
7.8.6. NETCONF <edit-config> operations 7.8.6. NETCONF <edit-config> operations
List entries can be created, deleted, replaced and modified through List entries can be created, deleted, replaced and modified through
<edit-config>, by using the "operation" attribute in the list's XML <edit-config>, by using the "operation" attribute in the list's XML
element. In each case, the values of all keys are used to uniquely element. In each case, the values of all keys are used to uniquely
identify a list entry. If all keys are not specified for a list identify a list entry. If all keys are not specified for a list
entry, a "missing-element" error is returned. entry, a "missing-element" error is returned.
In an "ordered-by user" list, the attributes "insert" and "key" in In an "ordered-by user" list, the attributes "insert" and "key" in
the YANG XML namespace (Section 5.3.1) can be used to control where the YANG XML namespace (Section 5.3.1) can be used to control where
skipping to change at page 81, line 9 skipping to change at page 81, line 9
o Otherwise, it is enforced if the ancestor node exists. o Otherwise, it is enforced if the ancestor node exists.
The constraint is further enforced according to the rules in The constraint is further enforced according to the rules in
Section 8. Section 8.
7.9.5. XML Mapping Rules 7.9.5. XML Mapping Rules
The choice and case nodes are not visible in XML. The choice and case nodes are not visible in XML.
The child nodes of the selected "case" statement MUST be encoded in
the same order as they are defined in the "case" statement if they
are part of a RPC input or output parameter definition. Otherwise,
the subelements are be encoded in any order.
7.9.6. NETCONF <edit-config> operations 7.9.6. NETCONF <edit-config> operations
Since only one of the choice's cases can be valid at any time, the Since only one of the choice's cases can be valid at any time, the
creation of a node from one case implicitly deletes all nodes from creation of a node from one case implicitly deletes all nodes from
all other cases. If an <edit-config> operation creates a node, the all other cases. If an <edit-config> operation creates a node, the
NETCONF server will delete any existing nodes that are defined in NETCONF server will delete any existing nodes that are defined in
other cases inside the choice. other cases inside the choice.
7.9.7. Usage Example 7.9.7. Usage Example
skipping to change at page 136, line 39 skipping to change at page 136, line 39
o An "enumeration" type may have new enums added, provided the old o An "enumeration" type may have new enums added, provided the old
enums's values do not change. enums's values do not change.
o A "bits" type may have new bits added, provided the old bit o A "bits" type may have new bits added, provided the old bit
positions do not change. positions do not change.
o A "range", "length", or "pattern" statement may expand the allowed o A "range", "length", or "pattern" statement may expand the allowed
value space. value space.
o A "default" statement may be added to a leaf that does not have a
default value (either directly or indirectly through its type).
o A "units" statement may be added. o A "units" statement may be added.
o A "reference" statement may be added or updated. o A "reference" statement may be added or updated.
o A "must" statement may be removed or its constraint relaxed. o A "must" statement may be removed or its constraint relaxed.
o A "mandatory" statement may be removed or changed from "true" to o A "mandatory" statement may be removed or changed from "true" to
"false". "false".
o A "min-elements" statement may be removed, or changed to require o A "min-elements" statement may be removed, or changed to require
skipping to change at page 143, line 17 skipping to change at page 143, line 17
In YANG, almost all statements are unordered. The ABNF grammar In YANG, almost all statements are unordered. The ABNF grammar
[RFC5234] defines the canonical order. To improve module [RFC5234] defines the canonical order. To improve module
readability, it is RECOMMENDED that clauses be entered in this order. readability, it is RECOMMENDED that clauses be entered in this order.
Within the ABNF grammar, unordered statements are marked with Within the ABNF grammar, unordered statements are marked with
comments. comments.
This grammar assumes that the scanner replaces YANG comments with a This grammar assumes that the scanner replaces YANG comments with a
single space character. single space character.
== begin "yang.abnf" <CODE BEGINS> file "yang.abnf"
module-stmt = optsep module-keyword sep identifier-arg-str module-stmt = optsep module-keyword sep identifier-arg-str
optsep optsep
"{" stmtsep "{" stmtsep
module-header-stmts module-header-stmts
linkage-stmts linkage-stmts
meta-stmts meta-stmts
revision-stmts revision-stmts
body-stmts body-stmts
"}" optsep "}" optsep
skipping to change at page 164, line 8 skipping to change at page 164, line 8
SP = %x20 SP = %x20
; space ; space
VCHAR = %x21-7E VCHAR = %x21-7E
; visible (printing) characters ; visible (printing) characters
WSP = SP / HTAB WSP = SP / HTAB
; whitespace ; whitespace
== end "yang.abnf" <CODE ENDS>
13. Error Responses for YANG Related Errors 13. Error Responses for YANG Related Errors
A number of NETCONF error responses are defined for error cases A number of NETCONF error responses are defined for error cases
related to the data-model handling. If the relevant YANG statement related to the data-model handling. If the relevant YANG statement
has an "error-app-tag" substatement, that overrides the default value has an "error-app-tag" substatement, that overrides the default value
specified below. specified below.
13.1. Error Message for Data that Violates a unique Statement 13.1. Error Message for Data that Violates a unique Statement
skipping to change at page 174, line 9 skipping to change at page 174, line 9
[XSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0", World [XSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0", World
Wide Web Consortium Recommendation REC-xslt-19991116, Wide Web Consortium Recommendation REC-xslt-19991116,
November 1999, November 1999,
<http://www.w3.org/TR/1999/REC-xslt-19991116>. <http://www.w3.org/TR/1999/REC-xslt-19991116>.
Appendix A. ChangeLog Appendix A. ChangeLog
RFC Editor: remove this section upon publication as an RFC. RFC Editor: remove this section upon publication as an RFC.
A.1. Version -08 A.1. Version -09
o Specified that we do not specify formal rules for how the server
may modify configuration data stores.
o Added rule to allow defaults to be added to leafs in an updated
module.
o Clarified how ordered-by user lists and leaf-lists entries are
encoded in XML.
o Clarified how child nodes to "case" are encoded in the XML.
A.2. Version -08
o Clarified text on leaf deafults. o Clarified text on leaf deafults.
o Added the term "top-level data node" to the terminology section. o Added the term "top-level data node" to the terminology section.
o Clarified how prefixes are mapped to namespaces in XPath o Clarified how prefixes are mapped to namespaces in XPath
expressions. expressions.
o Added "reference" as a substatement to "revision". o Added "reference" as a substatement to "revision".
o Added "choice" as a substatement to "case". o Added "choice" as a substatement to "case".
o Clarified that a leafreaf must be conditional if the leaf it o Clarified that a leafreaf must be conditional if the leaf it
refers to is conditional. refers to is conditional.
o Clarified how identityref default values are represented. o Clarified how identityref default values are represented.
o Various bug fixes, clarifications and editorial fixes. o Various bug fixes, clarifications and editorial fixes.
A.2. Version -07 A.3. Version -07
o The argument string of "augment", "refine", and "deviation" is o The argument string of "augment", "refine", and "deviation" is
described not as an XPath but as a "schema node identifier". described not as an XPath but as a "schema node identifier".
o Clarified that there must be no circular references in a leafref. o Clarified that there must be no circular references in a leafref.
A.3. Version -06 A.4. Version -06
o Various bug fixes, clarifications and editorial fixes after WGLC. o Various bug fixes, clarifications and editorial fixes after WGLC.
o Removed "require-instance" for leafref. o Removed "require-instance" for leafref.
o Allow leafrefs to refer to leaf-lists. o Allow leafrefs to refer to leaf-lists.
o Clarified the XPath context in Section 6.4.1, and for "must", o Clarified the XPath context in Section 6.4.1, and for "must",
"when", "augment", "path" and "instance-identifier". "when", "augment", "path" and "instance-identifier".
A.4. Version -05 A.5. Version -05
o Replaced the data types "float32" and "float64" with "decimal64". o Replaced the data types "float32" and "float64" with "decimal64".
o Specified that the elements in the XML encoding of configuration o Specified that the elements in the XML encoding of configuration
data can occur in any order. data can occur in any order.
o Clarified that "augment" cannot add multiple nodes with the same o Clarified that "augment" cannot add multiple nodes with the same
name. name.
o Clarified what "when" means in RPC input / output. o Clarified what "when" means in RPC input / output.
o Wrote the IANA Considerations section. o Wrote the IANA Considerations section.
o Changed requirement for minimum identifier length to 64 o Changed requirement for minimum identifier length to 64
characters. characters.
A.5. Version -04 A.6. Version -04
o Using "revision-date" substatement to "import" and "include". o Using "revision-date" substatement to "import" and "include".
o Corrected grammar and text for instance-identifier. o Corrected grammar and text for instance-identifier.
o Fixed bugs in some examples. o Fixed bugs in some examples.
o Rewrote the YIN description to use a declarative style. o Rewrote the YIN description to use a declarative style.
o Added two error codes in Section 13. o Added two error codes in Section 13.
skipping to change at page 175, line 41 skipping to change at page 176, line 12
o Corrected grammar for key-arg; now allowing optional prefix on o Corrected grammar for key-arg; now allowing optional prefix on
each leaf identifier. each leaf identifier.
o Clarified that "unique" constraints only check instances with o Clarified that "unique" constraints only check instances with
values for all referenced leafs. values for all referenced leafs.
o Clarified how mandatory and min-elements constraints are enforced. o Clarified how mandatory and min-elements constraints are enforced.
o Editorial fixes. o Editorial fixes.
A.6. Version -03 A.7. Version -03
o Added import by revision (yang-00413) o Added import by revision (yang-00413)
o Changed type "keyref" to "leafref", and added the statement o Changed type "keyref" to "leafref", and added the statement
"require-instance" (yang-01253) "require-instance" (yang-01253)
o Clarified that data sent from the server must be in the canonical o Clarified that data sent from the server must be in the canonical
form. form.
o Clarified when and how constraints in the models are enforced. o Clarified when and how constraints in the models are enforced.
o Many editorial fixes o Many editorial fixes
o Added more strict grammar for the "deviate" statement. o Added more strict grammar for the "deviate" statement.
A.7. Version -02 A.8. Version -02
o Added module update rules. (yang-00000) o Added module update rules. (yang-00000)
o Added "refine" statement as a substatement to "uses". (yang-00088) o Added "refine" statement as a substatement to "uses". (yang-00088)
o Allow "augment" on top-level and in "uses" only. (yang-00088) o Allow "augment" on top-level and in "uses" only. (yang-00088)
o Allow "when" on all data defintion statements. (yang-00088) o Allow "when" on all data defintion statements. (yang-00088)
o Added section "Constraints" and clarified when constraints are o Added section "Constraints" and clarified when constraints are
skipping to change at page 176, line 34 skipping to change at page 177, line 5
o Added "prefix" as a substatement to "belongs-to". (yang-00755) o Added "prefix" as a substatement to "belongs-to". (yang-00755)
o Added section on Conformance. (yang-01281) o Added section on Conformance. (yang-01281)
o Added "deviation" statement. (yang-01281) o Added "deviation" statement. (yang-01281)
o Added "identity" statement and "identityref" type. (yang-01339) o Added "identity" statement and "identityref" type. (yang-01339)
o Aligned grammar for "enum" with text. o Aligned grammar for "enum" with text.
A.8. Version -01 A.9. Version -01
o Removed "Appendix A. Derived YANG Types". o Removed "Appendix A. Derived YANG Types".
o Removed "Appendix C. XML Schema Considerations". o Removed "Appendix C. XML Schema Considerations".
o Removed "Appendix F. Why We Need a New Modeling Language". o Removed "Appendix F. Why We Need a New Modeling Language".
o Moved "Appendix B. YIN" to its own section. o Moved "Appendix B. YIN" to its own section.
o Moved "Appendix D. YANG ABNF Grammar" to its own section. o Moved "Appendix D. YANG ABNF Grammar" to its own section.
skipping to change at page 177, line 31 skipping to change at page 178, line 5
o Fixed whitespace issues in the ABNF grammar. o Fixed whitespace issues in the ABNF grammar.
o Added the term "mandatory node", and refer to it in the o Added the term "mandatory node", and refer to it in the
description of augment (see Section 7.15), and choice (see description of augment (see Section 7.15), and choice (see
Section 7.9.3). Section 7.9.3).
o Added support for multiple "pattern" statements in "type". o Added support for multiple "pattern" statements in "type".
o Several clarifications and fixed typos. o Several clarifications and fixed typos.
A.9. Version -00 A.10. Version -00
Changes from draft-bjorklund-netconf-yang-02.txt Changes from draft-bjorklund-netconf-yang-02.txt
o Fixed bug in grammar for bit-stmt o Fixed bug in grammar for bit-stmt
o Fixed bugs in example XPath expressions o Fixed bugs in example XPath expressions
o Added keyword 'presence' to the YIN mapping table o Added keyword 'presence' to the YIN mapping table
Author's Address Author's Address
 End of changes. 24 change blocks. 
28 lines changed or deleted 71 lines changed or added

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