Subject: [netmod] YANG draft -05 changes

From: Martin Bjorklund <[email-masked]>
Date: Thu, 09 Apr 2009 15:11:28 +0200 (CEST)

Hi,

As discussed in S.F., here is a diff with changes between 04 and
05-to-be.  Please check that my edits are correct!

There are two open issues:

  o  identifier length.  It seems we do have consensus to remove the
     length restriction, so unless anyone else has any comments, I
     will make that change in -05.

  o  the text about schema monitoring (5.6.5).  Should we move this
     into the monitoring draft?  I think it would be better to move it
     out of this draft.

When these issues are resolved, I will post 05 which I think is ready
for WGLC.

/martin
1. Introduction

Today, the NETCONF protocol [RFC4741] lacks a standardized way to
create data models. Instead, vendors are forced to use proprietary
solutions. In order for NETCONF to be a interoperable protocol,
models must be defined in a vendor-neutral way. YANG provides the
language and rules for defining such models for use with NETCONF.

YANG is a data modeling language used to model configuration and
state data manipulated by the NETCONF protocol, NETCONF remote
procedure calls, and NETCONF notifications. YANG models the
operations and content layers of NETCONF (see the NETCONF protocol
[RFC4741], section 1.1).

This document describes the syntax and semantics of the YANG
language, how the data model defined in a YANG module is represented
in XML, and how NETCONF operations are used to manipulate the data.

[skipping...]

4.2.4. Built-in Types

YANG has a set of built-in types, similar to those of many
programming languages, but with some differences due to special
requirements from the management domain. The following table
summarizes the built-in types discussed in Section 9:

+---------------------+-------------+-------------------------------+
| Name | Type | Description |
+---------------------+-------------+-------------------------------+
| binary | Text | Any binary data |
| bits | Text/Number | A set of bits or flags |
| boolean | Text | "true" or "false" |
| decimal64 | Number | 64-bit signed decimal number |
| empty | Empty | A leaf that does not have any |
| | | value |
| enumeration | Text/Number | Enumerated strings with |
| | | associated numeric values |
| float32 | Number | 32-bit IEEE floating point |
| | | real number |
| float64 | Number | 64-bit IEEE floating point |
| | | real number |
| identityref | Text | A reference to an abstract |
| | | identity |
| instance-identifier | Text | References a data tree node |
| int8 | Number | 8-bit signed integer |
| int16 | Number | 16-bit signed integer |
| int32 | Number | 32-bit signed integer |
| int64 | Number | 64-bit signed integer |
| leafref | Text/Number | A reference to a leaf |
| | | instance |
| string | Text | Human readable string |
| uint8 | Number | 8-bit unsigned integer |
| uint16 | Number | 16-bit unsigned integer |
| uint32 | Number | 32-bit unsigned integer |
| uint64 | Number | 64-bit unsigned integer |
| union | Text/Number | Choice of member types |
+---------------------+-------------+-------------------------------+

The "type" statement is covered in Section 9.

[skipping...]

5.3. XML Namespaces

All YANG definitions are specified within a module that is bound to a
particular XML Namespace [XML-NAMES], which is a globally unique URI
[RFC3986]. A NETCONF client or server uses the namespace during XML
encoding of data.

Namespaces for standard modules published in RFC streams MUST be assigned by IANA.
IANA, see Section 14.

Namespaces for private modules are assigned by the organization
owning the module without a central registry. It is RECOMMENDED to
choose namespaces that will have a low probability of colliding with
standard or other enterprise modules, e.g. by using the enterprise or
organization name in the namespace.

The "namespace" statement is covered in Section 7.1.3.

5.3.1. YANG XML Namespace

YANG defines its own XML namespace for NETCONF <edit-config>
operations. This namespace is "urn:ietf:params:xml:ns:yang:1" [XXX
IANA]. "urn:ietf:params:xml:ns:yang:1".

[skipping...]

7.1. The module Statement

The "module" statement defines the module's name, and groups all
statements which belong to the module together. The "module"
statement's argument is the name of the module, followed by a block
of substatements that hold detailed module information. The module
name follows the rules for identifiers in Section 6.2.

Standard module names

Names of modules published in RFC streams MUST be assigned by IANA. IANA,
see Section 14.

[skipping...]

7.2. The submodule Statement

While the primary unit in YANG is a module, a YANG module can itself
be constructed out of several submodules. Submodules allows a module
designer to split a complex model into several pieces where all the
submodules contribute to a single namespace, which is defined by the
module that includes the submodules.

The "submodule" statement is used to give the submodule a name, and
to group all statements which belong to the submodule together.

The "submodule" statement, which MUST be present at most once, takes
as an argument an identifier which is the name of the submodule,
followed by a block of substatements that hold detailed submodule
information.

Standard submodule names

Names of submodules published in RFC streams MUST be assigned by IANA.
IANA, see Section 14.

[skipping...]

7.5.7. XML Encoding Rules

A container node is encoded as an XML element. The element's name is
the container's identifier, and its XML namespace is the module's XML
namespace.

The container's child nodes are encoded as subelements to the
container element, element. If the container defines RPC input or output
parameters, the subelements are encoded in the same order as they are
defined within the container statement. Otherwise, the subelements
are encoded in any order.

A NETCONF server that replies to a <get> or <get-config> request MAY
choose not to send a container element if the container node does not
have the "presence" statement and no child nodes exist. Thus, a
client that receives an <rpc-reply> for a <get> or <get-config>
request, must be prepared to handle the case that a container node
without a presence statement is not present in the XML.

[skipping...]

7.8.5. XML Encoding Rules

A list is encoded as a series of XML elements, one for each entry in
the list. Each element's name is the list's identifier, and its XML
namespace is the module's XML namespace.

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
key statement.

The rest of the list's child nodes are encoded as subelements to the
list element, after the keys, keys. If the list defines RPC input or
output parameters, the subelements are encoded in the same order as
they are defined within the list statement. Otherwise, the
subelements are encoded in any order.

[skipping...]

7.9.2. The choice's case Statement

The "case" statement is used to define branches of the choice. It
takes as an argument an identifier, followed by a block of
substatements that holds detailed case information.

The identifier is used to identify the case node in the schema tree.
A case node does not exist in the data tree.

Within a "case" statement, the "anyxml", "container", "leaf", "list",
"leaf-list", "uses", and "augment" "uses" statements can be used to define child nodes
to the case node. The identifiers of all these child nodes MUST be
unique within all cases in a choice. For example, the following is
illegal:

choice interface-type { // This example is illegal YANG
case a {
leaf ethernet { ... }
}
case b {
container ethernet { ...}
}
}

[skipping...]

7.13.2. The input Statement

The "input" statement, which is optional, is used to define input
parameters to the RPC method. It does not take an argument. The
substatements to "input" defines nodes under the RPC's input node.

If a container in the input tree has a "presence" statement, the
container need not be present in a NETCONF RPC invocation.

If a leaf in the input tree has a "mandatory" statement with the
value "true", the leaf MUST be present in a NETCONF RPC invocation.

If a leaf in the input tree has a default value, the NETCONF server
MUST internally use this default if the leaf is not present in a
NETCONF RPC invocation.

If a "config" statement is present for any node in the input tree, it
is ignored.

If any node has a "when" statement which would evaluate to false,
then this node MUST NOT be present in the input tree.

7.13.2.1. The input's Substatements

+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| choice | 7.9 | 0..n |
| container | 7.5 | 0..n |
| grouping | 7.11 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n |
+--------------+---------+-------------+

7.13.3. The output Statement

The "output" statement, which is optional, is used to define output
parameters to the RPC method. It does not take an argument. The
substatements to "output" defines nodes under the RPC's output node.

If a container in the output tree has a "presence" statement, the
container need not be present in a NETCONF RPC reply

If a leaf in the output tree has a "mandatory" statement with the
value "true", the leaf MUST be present in a NETCONF RPC reply.

If a leaf in the output tree has a default value, the NETCONF client
MUST internally use this default if the leaf is not present in a
NETCONF RPC reply.

If a "config" statement is present for any node in the output tree,
it is ignored.

If any node has a "when" statement which would evaluate to false,
then this node MUST NOT be present in the output tree.

[skipping...]

7.14.2. XML Encoding Rules

A notification node is encoded as a child XML element to the
<notification> element defined in NETCONF Event Notifications
[RFC5277]. The element's name is the notification's identifier, and
its XML namespace is the module's XML namespace.

The notifications's child nodes are encoded as subelements to the
notification node's XML element, in the same order as they are
defined within the notification statement.

[skipping...]

7.15. The augment Statement

The "augment" statement allows a module or submodule to add to the
schema tree defined in another module an external module, or submodule, the current module and
its submodules, and to add to the nodes from a grouping in a "uses"
statement. The argument is a string which identifies a node in the
schema tree. This node is called the augment's target node. The
target node MUST be either a container, list, choice, case, input,
output, or notification node. It is augmented with the nodes defined
in the substatements that follow the "augment" statement.

The argument string is a schema node identifier. The syntax is
formally defined by the rule "augment-arg" in Section 12. If the
"augment" statement is on the top-level in a module or submodule, the
absolute form (defined by the rule "absolute-schema-nodeid" in
Section 12) of a schema node identifier MUST be used. If the
"augment" statement is in a "uses" statement, the descendant form
(defined by the rule "descendant-schema-nodeid" in Section 12) MUST
be used.

The syntax for a schema node identifier is a subset of the XPath
syntax. It is an absolute or relative XPath location path in
abbreviated syntax, where axes and predicates are not permitted.

If the target node is a container, list, case, input, output, or
notification node, the "container", "leaf", "list", "leaf-list",
"uses", and "choice" statements can be used within the "augment"
statement.

If the target node is a choice node, the "case" statement can be used
within the "augment" statement.

If the target node is in another module, then nodes added by the
augmentation MUST NOT be mandatory nodes (see Section 3.1).

The augment statement MUST NOT add multiple nodes with the same name
from the same module to the target node.

7.15.1. The augment's Substatements

+--------------+---------+-------------+
| substatement | section | cardinality |
+--------------+---------+-------------+
| anyxml | 7.10 | 0..n |
| case | 7.9.2 | 0..n |
| choice | 7.9 | 0..n |
| container | 7.5 | 0..n |
| description | 7.19.3 | 0..1 |
| if-feature | 7.18.2 | 0..n |
| leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n |
| list | 7.8 | 0..n |
| reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 |
| uses | 7.12 | 0..n |
| when | 7.19.5 | 0..1 |
+--------------+---------+-------------+

7.15.2. XML Encoding Rules

All data nodes defined in the "augment" statement are defined as XML
elements in the XML namespace of the module where the "augment" is
specified.

When a node is augmented, the augmented augmenting child nodes are encoded after
all normal child nodes. If the node is augmented more than once, the
blocks of augmented child nodes are sorted (in alphanumeric order)
according as
subelements to their namespace URI and name of the first child node augmented node, in
each block. any order.

[skipping...]

7.19.5. The when Statement

The "when" statement makes its parent data definition statement
conditional. The node defined by the parent data definition
statement is only valid when the condition specified by the "when"
statement is satisfied. The statement's argument is an XPath
expression, which is used to formally specify this condition. If the
XPath expression conceptually evaluates to "true" for a particular
instance, then the node defined by the parent data definition
statement is valid, otherwise it is not.

See Section 8.3.2 for additional information.

The XPath expression is conceptually evaluated in the following
context:

o If the "when" statement is a child of an "augment" statement, then
the context node is the augment's target node in the data tree, if
the target node is a data node. Otherwise, the context node is
the closest ancestor node to the target node which is also a data
node.

o If the "when" statement is a child of a "choice" or "case"
statement, then the context node is the closest ancestor node to
the "choice" or "case" node which is also a data node.

o If the "when" statement is a child of any other data definition
statement, the context node is the data definition's node in the
data tree.

o The accessible tree is made up of all nodes in the data tree, and
all leafs with default values.

o The set of namespace declarations is the set of all "import"
statements' prefix and namespace pairs, and the "prefix"
statement's prefix for the "namespace" statement's URI.

o Elements without a namespace refer to nodes in the current module.

o The function library is the core function library defined in
[XPATH], and a function "current()" which returns a node set with
the initial context node.

The accessible data tree depends on the context node:

o If the context node represents configuration, the tree is the data
in one of the datastores <startup/>, <running/>, or <candidate/>.
The XPath root node has all top-level configuration data nodes in
all modules as children.

o If the context node represents state data, the tree is all state
data on the device, and the <running/> datastore. The XPath root
node has all top-level data nodes in all modules as children.

o If the context node represents notification content, the tree is
the notification XML instance document. The XPath root node has
the element representing the notification being defined as the
only child.

o If the context node represents RPC input parameters, the tree is
the RPC XML instance document. The XPath root node has the
element representing the RPC method being defined as the only
child.

o If the context node represents RPC output parameters, the tree is
the RPC reply instance document. The XPath root node has the
elements representing the RPC output parameters as children.

The result of the XPath expression is converted to a boolean value
using the standard XPath rules.

The XPath expression MUST NOT include any references to the context
node or any descendants of the context node.

Note that the XPath expression is conceptually evaluated. This means
that an implementation does not have to use an XPath evaluator on the
device. The augment can very well be implemented with specially
written code.

[skipping...]

8.3.1. Payload Parsing

When content arrives in RPC payloads, it MUST be well-formed and
valid XML,
following the hierarchy and content rules defined by the set of
models the device implements.

[skipping...]

9.2.4. The range Statement

The "range" statement, which is an optional substatement to the
"type" statement, takes as an argument a range expression string. It
is used to restrict integer and floating point decimal built-in types, or types
derived from those.

[skipping...]

9.3. The Floating Point decimal64 Built-in Types Type

The floating point built-in types are float32 and float64. They
represent floating point values decimal64 type represents a subset of single and double precision the real numbers, which can
be represented by decimal numerals. The value space of decimal64 is
the set of numbers that can be obtained by multiplying a 64 bit
signed integer by a negative power of ten, i.e. expressible as
defined in [IEEE.754]. Special values are positive
"i\&#A0;x\&#A0;10^\&#8209;n" where i is an integer64 and negative
infinity, n is an
integer between 1 and not-a-number. 18, inclusively.

9.3.1. Lexicographic Representation

A floating point decimal64 value is lexicographically represented as consisting
of an optional
sign ("+" or "-"), followed by a sequence of decimal mantissa followed, optionally, by the character "E" or
"e", digits,
optionally followed by an integer exponent. The special values positive
and negative infinity and not-a-number have lexical representations
INF, -INF a period ('.') as a decmial indicator and NaN, respectively. a
sequence of decimal digits. If no sign is specified, "+" is assumed.

9.3.2. Canonical Form

The minimal value accepted for canonical form of a
float positive decimal64 does not include the sign
"+". The decimal point is -INF, required. Leading and trailing zeros are
prohibited, subject to the rule that there MUST be at least one digit
before and after the maximal decimal point. The value accepted for a float zero is INF.

9.3.2. Canonical Form

[Editor's Note: TBD] represented as
"0.0".

9.3.3. Restrictions

All floating point types

A decmial64 type can be restricted with the "range" statement
(Section 9.2.4).

9.3.4. Usage Example

type float32 {
range "1..4.5 | 10 | 20..INF";
} The fraction-digits Statement

The "fraction-digits" statement, which is equivalent a substatement to the
"type" statement, MUST be present if the type float32 {
range "1..4.5 | 10 is "decimal64". It
takes as an argument an integer between 1 and 18, inclusively. It
controls the size of the minimum difference between values of a
decimal64 type, by restricting the value space to numbers that are
expressible as i x 10^-n where n is the fraction-digits argument.

9.3.5. Usage Example

type decimal64 {
fraction-digits 2;
range "1 .. 3.14 | 10 | 20..max";
}

[skipping...]

9.12. The union Built-in Type

The union built-in type represents a value that corresponds to one of
its member types.

When the type is "union", the "type" statement (Section 7.4) MUST be
present. It is used to repeatedly specify each member type of the
union. It takes as an argument a string which is the name of a
member type.

A member type can be of any built-in or derived type, except it MUST
NOT be one of the built-in types "empty" or "leafref".

When a string representing a union data type is validated, the string
is validated against each member type, in the order they are
specified in the type statement, until a match is found.

[skipping...]

11.1. Formal YIN Definition

There is a one-to-one correspondence between YANG keywords and YIN
elements. The local name of a YIN element is identical to the
corresponding YANG keyword. This means in particular that the
document element (root) of a YIN document is always <module> or
<submodule>.

YIN elements corresponding to the core YANG keywords belong to the
namespace whose associated URI is
"urn:ietf:params:xml:ns:yang:yin:1". [XXX IANA].

YIN elements corresponding to extension keywords belong to the
namespace of the YANG module where the extension keyword is declared
via the "extension" statement.

[skipping...]

Mapping of arguments of the core YANG statements.

+------------------+---------------+-------------+
| keyword | argument name | yin-element |
+------------------+---------------+-------------+
| anyxml | name | false |
| argument | name | false |
| augment | target-node | false |
| base | name | false |
| belongs-to | module | false |
| bit | name | false |
| case | name | false |
| choice | name | false |
| config | value | false |
| contact | info | true |
| container | name | false |
| default | value | false |
| description | text | true |
| deviate | value | false |
| deviation | target-node | false |
| enum | name | false |
| error-app-tag | value | false |
| error-message | value | true |
| extension | name | false |
| feature | name | false |
| fraction-digits | value | false |
| grouping | name | false |
| identity | name | false |
| if-feature | name | false |
| import | module | false |
| include | module | false |
| input | <no argument> | n/a |
| key | value | false |
| leaf | name | false |
| leaf-list | name | false |
| length | value | false |
| list | name | false |
| mandatory | value | false |
| max-elements | value | false |
| min-elements | value | false |
| module | name | false |
| must | condition | false |
| namespace | uri | false |
| notification | name | false |
| ordered-by | value | false |
| organization | info | true |
| output | <no argument> | n/a |
| path | value | false |
| pattern | value | false |
| position | value | false |
| prefix | value | false |
| presence | value | false |
| range | value | false |
| reference | info | false |
| refine | target-node | false |
| require-instance | value | false |
| revision | date | false |
| revision-date | date | false |
| rpc | name | false |
| status | value | false |
| submodule | name | false |
| type | name | false |
| typedef | name | false |
| unique | tag | false |
| units | name | false |
| uses | name | false |
| value | value | false |
| when | condition | false |
| yang-version | value | false |
| yin-element | value | false |
+------------------+---------------+-------------+

Table 1

[skipping...]

12. YANG ABNF Grammar

In YANG, almost all statements are unordered. The ABNF grammar
[RFC5234] defines the canonical order. To improve module
readability, it is RECOMMENDED that clauses be entered in this order.

Within the ABNF grammar, unordered statements are marked with
comments.

This grammar assumes that the scanner replaces YANG comments with a
single space character.

module-stmt = optsep module-keyword sep identifier-arg-str
optsep
"{" stmtsep
module-header-stmts
linkage-stmts
meta-stmts
revision-stmts
body-stmts
"}" optsep

submodule-stmt = optsep submodule-keyword sep identifier-arg-str
optsep
"{" stmtsep
submodule-header-stmts
linkage-stmts
meta-stmts
revision-stmts
body-stmts
"}" optsep

module-header-stmts = ;; these stmts can appear in any order
[yang-version-stmt stmtsep]
namespace-stmt stmtsep
prefix-stmt stmtsep

submodule-header-stmts =
;; these stmts can appear in any order
[yang-version-stmt stmtsep]
belongs-to-stmt stmtsep

meta-stmts = ;; these stmts can appear in any order
[organization-stmt stmtsep]
[contact-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
linkage-stmts = ;; these stmts can appear in any order
*(import-stmt stmtsep)
*(include-stmt stmtsep)

revision-stmts = *(revision-stmt stmtsep)

body-stmts = *((extension-stmt /
feature-stmt /
identity-stmt /
typedef-stmt /
grouping-stmt /
data-def-stmt /
augment-stmt /
rpc-stmt /
notification-stmt /
deviation-stmt) stmtsep)

data-def-stmt = container-stmt /
leaf-stmt /
leaf-list-stmt /
list-stmt /
choice-stmt /
anyxml-stmt /
uses-stmt

case-data-def-stmt = container-stmt /
leaf-stmt /
leaf-list-stmt /
list-stmt /
anyxml-stmt /
uses-stmt

yang-version-stmt = yang-version-keyword sep yang-version-arg-str
optsep stmtend

yang-version-arg-str = < a string which matches the rule
yang-version-arg >

yang-version-arg = "1"

import-stmt = import-keyword sep identifier-arg-str optsep
"{" stmtsep
prefix-stmt stmtsep
[revision-date-stmt stmtsep]
"}"

include-stmt = include-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
[revision-date-stmt stmtsep]
"}")

namespace-stmt = namespace-keyword sep uri-str optsep stmtend

uri-str = < a string which matches the rule
URI in RFC 3986 >

prefix-stmt = prefix-keyword sep prefix-arg-str
optsep stmtend

belongs-to-stmt = belongs-to-keyword sep identifier-arg-str
optsep
"{" stmtsep
prefix-stmt stmtsep
"}"

organization-stmt = organization-keyword sep string
optsep stmtend

contact-stmt = contact-keyword sep string optsep stmtend

description-stmt = description-keyword sep string optsep
stmtend

reference-stmt = reference-keyword sep string optsep stmtend

units-stmt = units-keyword sep string optsep stmtend

revision-stmt = revision-keyword sep revision-date optsep
(";" /
"{" stmtsep
[description-stmt stmtsep]
"}")

revision-date = date-arg-str

revision-date-stmt = revision-date-keyword sep revision-date stmtend

extension-stmt = extension-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[argument-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")

argument-stmt = argument-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
[yin-element-stmt stmtsep]
"}")

yin-element-stmt = yin-element-keyword sep yin-element-arg-str
stmtend

yin-element-arg-str = < a string which matches the rule
yin-element-arg >

yin-element-arg = true-keyword / false-keyword

identity-stmt = identity-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[base-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")

base-stmt = base-keyword sep identifier-ref-arg-str
optsep stmtend

feature-stmt = feature-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
*(if-feature-stmt stmtsep)
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")

if-feature-stmt = if-feature-keyword sep identifier-ref-arg-str
optsep stmtend

typedef-stmt = typedef-keyword sep identifier-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
type-stmt stmtsep
[units-stmt stmtsep]
[default-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}"

type-stmt = type-keyword sep identifier-ref-arg-str optsep
(";" /
"{" stmtsep
type-body-stmts
"}")

type-body-stmts = numerical-restrictions /
decimal64-specification /
string-restrictions /
enum-specification /
leafref-specification /
identityref-specification /
instance-identifier-specification /
bits-specification /
union-specification

numerical-restrictions = range-stmt stmtsep

range-stmt = range-keyword sep range-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[error-message-stmt stmtsep]
[error-app-tag-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")

decimal64-specification = fraction-digits-stmt

fraction-digits-stmt = fraction-digits-keyword sep
fraction-digits-arg-str stmtend

fraction-digits-arg-str = < a string which matches the rule
fraction-digits-arg >

fraction-digits-arg = ("1" ["2" / "3" / "4" / "5" / "6" / "7" / "8"])
/ "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"

string-restrictions = ;; these stmts can appear in any order
[length-stmt stmtsep]
*(pattern-stmt stmtsep)
length-stmt = length-keyword sep length-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[error-message-stmt stmtsep]
[error-app-tag-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")

pattern-stmt = pattern-keyword sep string optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[error-message-stmt stmtsep]
[error-app-tag-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")

default-stmt = default-keyword sep string stmtend

enum-specification = 1*(enum-stmt stmtsep)

enum-stmt = enum-keyword sep string optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[value-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")

leafref-specification =
;; these stmts can appear in any order
path-stmt stmtsep
[require-instance-stmt stmtsep]

path-stmt = path-keyword sep path-arg-str stmtend

require-instance-stmt = require-instance-keyword sep
require-instance-arg-str stmtend

require-instance-arg-str = < a string which matches the rule
require-instance-arg >

require-instance-arg = true-keyword / false-keyword
instance-identifier-specification =
[require-instance-stmt stmtsep]

identityref-specification =
base-stmt stmtsep

union-specification = 1*(type-stmt stmtsep)

bits-specification = 1*(bit-stmt stmtsep)

bit-stmt = bit-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[position-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}"
"}")

position-stmt = position-keyword sep
position-value-arg-str stmtend

position-value-arg-str = < a string which matches the rule
position-value-arg >

position-value-arg = non-negative-decimal-value non-negative-integer-value

status-stmt = status-keyword sep status-arg-str stmtend

status-arg-str = < a string which matches the rule
status-arg >

status-arg = current-keyword /
obsolete-keyword /
deprecated-keyword

config-stmt = config-keyword sep
config-arg-str stmtend

config-arg-str = < a string which matches the rule
config-arg >

config-arg = true-keyword / false-keyword

mandatory-stmt = mandatory-keyword sep
mandatory-arg-str stmtend
mandatory-arg-str = < a string which matches the rule
mandatory-arg >

mandatory-arg = true-keyword / false-keyword

presence-stmt = presence-keyword sep string stmtend

ordered-by-stmt = ordered-by-keyword sep
ordered-by-arg-str stmtend

ordered-by-arg-str = < a string which matches the rule
ordered-by-arg >

ordered-by-arg = user-keyword / system-keyword

must-stmt = must-keyword sep string optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[error-message-stmt stmtsep]
[error-app-tag-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")

error-message-stmt = error-message-keyword sep string stmtend

error-app-tag-stmt = error-app-tag-keyword sep string stmtend

min-elements-stmt = min-elements-keyword sep
min-value-arg-str stmtend;

min-value-arg-str = < a string which matches the rule
min-value-arg >

min-value-arg = non-negative-decimal-value non-negative-integer-value

max-elements-stmt = max-elements-keyword sep
max-value-arg-str stmtend;

max-value-arg-str = < a string which matches the rule
max-value-arg >

max-value-arg = unbounded-keyword /
positive-decimal-value
positive-integer-value

value-stmt = value-keyword sep decimal-value integer-value stmtend
grouping-stmt = grouping-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
*((typedef-stmt /
grouping-stmt) stmtsep)
*(data-def-stmt stmtsep)
"}")

container-stmt = container-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
*(must-stmt stmtsep)
[presence-stmt stmtsep]
[config-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
*((typedef-stmt /
grouping-stmt) stmtsep)
*(data-def-stmt stmtsep)
"}")

leaf-stmt = leaf-keyword sep identifier-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
type-stmt stmtsep
[units-stmt stmtsep]
*(must-stmt stmtsep)
[default-stmt stmtsep]
[config-stmt stmtsep]
[mandatory-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}"

leaf-list-stmt = leaf-list-keyword sep identifier-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
type-stmt stmtsep
[units-stmt stmtsep]
*(must-stmt stmtsep)
[config-stmt stmtsep]
[min-elements-stmt stmtsep]
[max-elements-stmt stmtsep]
[ordered-by-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}"

list-stmt = list-keyword sep identifier-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
*(must-stmt stmtsep)
[key-stmt stmtsep]
*(unique-stmt stmtsep)
[config-stmt stmtsep]
[min-elements-stmt stmtsep]
[max-elements-stmt stmtsep]
[ordered-by-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
*((typedef-stmt /
grouping-stmt) stmtsep)
1*(data-def-stmt stmtsep)
"}"

key-stmt = key-keyword sep key-arg-str stmtend

key-arg-str = < a string which matches the rule
key-arg >

key-arg = node-identifier *(sep node-identifier)

unique-stmt = unique-keyword sep unique-arg-str stmtend

unique-arg-str = < a string which matches the rule
unique-arg >

unique-arg = descendant-schema-nodeid
*(sep descendant-schema-nodeid)
choice-stmt = choice-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
[default-stmt stmtsep]
[config-stmt stmtsep]
[mandatory-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
*((short-case-stmt / case-stmt) stmtsep)
"}")

short-case-stmt = container-stmt /
leaf-stmt /
leaf-list-stmt /
list-stmt /
anyxml-stmt

case-stmt = case-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
*(case-data-def-stmt stmtsep)
"}")

anyxml-stmt = anyxml-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
*(must-stmt stmtsep)
[config-stmt stmtsep]
[mandatory-stmt stmtsep]
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
"}")

uses-stmt = uses-keyword sep identifier-ref-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
*(refine-stmt stmtsep)
*(uses-augment-stmt stmtsep)
"}")

refine-stmt = refine-keyword sep refine-arg-str optsep
(";" /
"{" stmtsep
(refine-container-stmts /
refine-leaf-stmts /
refine-leaf-list-stmts /
refine-list-stmts /
refine-choice-stmts /
refine-case-stmts /
refine-anyxml-stmts)
"}")

refine-arg-str = < a string which matches the rule
refine-arg >

refine-arg = descendant-schema-nodeid

refine-container-stmts =
;; these stmts can appear in any order
*(must-stmt stmtsep)
[presence-stmt stmtsep]
[config-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]

refine-leaf-stmts = ;; these stmts can appear in any order
*(must-stmt stmtsep)
[default-stmt stmtsep]
[config-stmt stmtsep]
[mandatory-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]

refine-leaf-list-stmts =
;; these stmts can appear in any order
*(must-stmt stmtsep)
[config-stmt stmtsep]
[min-elements-stmt stmtsep]
[max-elements-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]

refine-list-stmts = ;; these stmts can appear in any order
*(must-stmt stmtsep)
[config-stmt stmtsep]
[min-elements-stmt stmtsep]
[max-elements-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]

refine-choice-stmts = ;; these stmts can appear in any order
[default-stmt stmtsep]
[config-stmt stmtsep]
[mandatory-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]

refine-case-stmts = ;; these stmts can appear in any order
[description-stmt stmtsep]
[reference-stmt stmtsep]

refine-anyxml-stmts = ;; these stmts can appear in any order
[config-stmt stmtsep]
[mandatory-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]

uses-augment-stmt = augment-keyword sep uses-augment-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
1*((data-def-stmt stmtsep) /
(case-stmt stmtsep))
"}"

uses-augment-arg-str = < a string which matches the rule
uses-augment-arg >

uses-augment-arg = descendant-schema-nodeid
augment-stmt = augment-keyword sep augment-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
[when-stmt stmtsep]
*(if-feature-stmt stmtsep)
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
1*((data-def-stmt stmtsep) /
(case-stmt stmtsep))
"}"

augment-arg-str = < a string which matches the rule
augment-arg >

augment-arg = absolute-schema-nodeid schema-nodeid

unknown-statement = prefix ":" identifier [sep string] optsep
(";" / "{" *unknown-statement "}")

when-stmt = when-keyword sep string stmtend

rpc-stmt = rpc-keyword sep identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
*(if-feature-stmt stmtsep)
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
*((typedef-stmt /
grouping-stmt) stmtsep)
[input-stmt stmtsep]
[output-stmt stmtsep]
"}")

input-stmt = input-keyword optsep
"{" stmtsep
;; these stmts can appear in any order
*((typedef-stmt /
grouping-stmt) stmtsep)
1*(data-def-stmt stmtsep)
"}"

output-stmt = output-keyword optsep
"{" stmtsep
;; these stmts can appear in any order
*((typedef-stmt /
grouping-stmt) stmtsep)
1*(data-def-stmt stmtsep)
"}"

notification-stmt = notification-keyword sep
identifier-arg-str optsep
(";" /
"{" stmtsep
;; these stmts can appear in any order
*(if-feature-stmt stmtsep)
[status-stmt stmtsep]
[description-stmt stmtsep]
[reference-stmt stmtsep]
*((typedef-stmt /
grouping-stmt) stmtsep)
*(data-def-stmt stmtsep)
"}")

deviation-stmt = deviation-keyword sep
deviation-arg-str optsep
"{" stmtsep
;; these stmts can appear in any order
[description-stmt stmtsep]
[reference-stmt stmtsep]
(deviate-not-supported-stmt /
1*(deviate-add-stmt /
deviate-replace-stmt /
deviate-delete-stmt))
"}"

deviation-arg-str = < a string which matches the rule
deviation-arg >

deviation-arg = absolute-schema-nodeid

deviate-not-supported-stmt =
deviate-keyword sep
not-supported-keyword optsep
(";" /
"{" stmtsep
"}")

deviate-add-stmt = deviate-keyword sep add-keyword optsep
(";" /
"{" stmtsep
[units-stmt stmtsep]
*(must-stmt stmtsep)
*(unique-stmt stmtsep)
[default-stmt stmtsep]
[config-stmt stmtsep]
[mandatory-stmt stmtsep]
[min-elements-stmt stmtsep]
[max-elements-stmt stmtsep]
"}")

deviate-delete-stmt = deviate-keyword sep delete-keyword optsep
(";" /
"{" stmtsep
[units-stmt stmtsep]
*(must-stmt stmtsep)
*(unique-stmt stmtsep)
[default-stmt stmtsep]
"}")

deviate-replace-stmt = deviate-keyword sep replace-keyword optsep
(";" /
"{" stmtsep
[type-stmt stmtsep]
[units-stmt stmtsep]
[default-stmt stmtsep]
[config-stmt stmtsep]
[mandatory-stmt stmtsep]
[min-elements-stmt stmtsep]
[max-elements-stmt stmtsep]
"}")

;; Ranges

range-arg-str = < a string which matches the rule
range-arg >

range-arg = range-part *(optsep "|" optsep range-part)

range-part = range-boundary
[optsep ".." optsep range-boundary]

range-boundary = neginf-keyword / posinf-keyword / min-keyword / max-keyword /
decimal-value
integer-value / float-value decimal-value

;; Lengths

length-arg-str = < a string which matches the rule
length-arg >

length-arg = length-part *(optsep "|" optsep length-part)
length-part = length-boundary
[optsep ".." optsep length-boundary]

length-boundary = min-keyword / max-keyword /
non-negative-decimal-value
non-negative-integer-value

;; Date

date-arg-str = < a string which matches the rule
date-arg >

date-arg = 4DIGIT "-" 2DIGIT "-" 2DIGIT

;; Schema Node Identifiers

schema-nodeid = absolute-schema-nodeid /
relative-schema-nodeid
descendant-schema-nodeid

absolute-schema-nodeid = 1*("/" node-identifier)

relative-schema-nodeid =
descendant-schema-nodeid /
(("." / "..") "/"
*relative-schema-nodeid)

descendant-schema-nodeid =
node-identifier
absolute-schema-nodeid

node-identifier = [prefix ":"] identifier

;; Instance Identifiers

instance-identifier = 1*("/" (node-identifier *predicate))

predicate = "[" *WSP (predicate-expr / pos) *WSP "]"

predicate-expr = (node-identifier / ".") *WSP "=" *WSP
((DQUOTE string DQUOTE) /
(SQUOTE string SQUOTE))

pos = non-negative-decimal-value) non-negative-integer-value

;; leafref path

path-arg-str = < a string which matches the rule
path-arg >

path-arg = absolute-path / relative-path

absolute-path = 1*("/" (node-identifier *path-predicate))
relative-path = 1*(".." "/") descendant-path

descendant-path = node-identifier
[*path-predicate absolute-path]

path-predicate = "[" *WSP path-equality-expr *WSP "]"

path-equality-expr = node-identifier *WSP "=" *WSP path-key-expr

path-key-expr = current-function-invocation *WSP "/" *WSP
rel-path-keyexpr

rel-path-keyexpr = 1*(".." *WSP "/" *WSP)
*(node-identifier *WSP "/" *WSP)
node-identifier

;;; Keywords, using abnfgen's syntax for case-sensitive strings

;; statment keywords
anyxml-keyword = 'anyxml'
argument-keyword = 'argument'
augment-keyword = 'augment'
base-keyword = 'base'
belongs-to-keyword = 'belongs-to'
bit-keyword = 'bit'
case-keyword = 'case'
choice-keyword = 'choice'
config-keyword = 'config'
contact-keyword = 'contact'
container-keyword = 'container'
default-keyword = 'default'
description-keyword = 'description'
enum-keyword = 'enum'
error-app-tag-keyword = 'error-app-tag'
error-message-keyword = 'error-message'
extension-keyword = 'extension'
deviation-keyword = 'deviation'
deviate-keyword = 'deviate'
feature-keyword = 'feature'
fraction-digits-keyword = 'fraction-digits'
grouping-keyword = 'grouping'
identity-keyword = 'identity'
if-feature-keyword = 'if-feature'
import-keyword = 'import'
include-keyword = 'include'
input-keyword = 'input'
key-keyword = 'key'
leaf-keyword = 'leaf'
leaf-list-keyword = 'leaf-list'
length-keyword = 'length'
list-keyword = 'list'
mandatory-keyword = 'mandatory'
max-elements-keyword = 'max-elements'
min-elements-keyword = 'min-elements'
module-keyword = 'module'
must-keyword = 'must'
namespace-keyword = 'namespace'
notification-keyword= 'notification'
ordered-by-keyword = 'ordered-by'
organization-keyword= 'organization'
output-keyword = 'output'
path-keyword = 'path'
pattern-keyword = 'pattern'
position-keyword = 'position'
prefix-keyword = 'prefix'
presence-keyword = 'presence'
range-keyword = 'range'
reference-keyword = 'reference'
refine-keyword = 'refine'
require-instance-keyword = 'require-instance'
revision-keyword = 'revision'
revision-date-keyword = 'revision-date'
rpc-keyword = 'rpc'
status-keyword = 'status'
submodule-keyword = 'submodule'
type-keyword = 'type'
typedef-keyword = 'typedef'
unique-keyword = 'unique'
units-keyword = 'units'
uses-keyword = 'uses'
value-keyword = 'value'
when-keyword = 'when'
yang-version-keyword= 'yang-version'
yin-element-keyword = 'yin-element'

;; other keywords

add-keyword = 'add'
current-keyword = 'current'
delete-keyword = 'delete'
deprecated-keyword = 'deprecated'
false-keyword = 'false'
max-keyword = 'max'
min-keyword = 'min'
nan-keyword = 'NaN'
neginf-keyword = '-INF'
not-supported-keyword = 'not-supported'
obsolete-keyword = 'obsolete'
posinf-keyword = 'INF'
replace-keyword = 'replace'
system-keyword = 'system'
true-keyword = 'true'
unbounded-keyword = 'unbounded'
user-keyword = 'user'

current-function-invocation = current-keyword *WSP "(" *WSP ")"

;; Basic Rules

prefix-arg-str = < a string which matches the rule
prefix-arg >

prefix-arg = prefix

prefix = identifier

identifier-arg-str = < a string which matches the rule
identifier-arg >

identifier-arg = identifier

identifier = (ALPHA / "_")
*(ALPHA / DIGIT / "_" / "-" / ".")

identifier-ref-arg-str = < a string which matches the rule
identifier-ref-arg >

identifier-ref-arg = [prefix ":"] identifier

string = < an unquoted string as returned by
the scanner >

decimal-value

integer-value = ("-" non-negative-decimal-value) non-negative-integer-value) /
non-negative-decimal-value

non-negative-decimal-value
non-negative-integer-value

non-negative-integer-value = "0" / positive-decimal-value

positive-decimal-value positive-integer-value

positive-integer-value = (non-zero-digit *DIGIT)

zero-decimal-value

zero-integer-value = 1*DIGIT

stmtend = ";" / "{" *unknown-statement "}"

sep = 1*(WSP / line-break)
; unconditional separator

optsep = *(WSP / line-break)
stmtsep = *(WSP / line-break / unknown-statement)

line-break = CRLF / LF

non-zero-digit = %x31-39

float-value = neginf-keyword /
posinf-keyword /
nan-keyword /

decimal-value "." zero-decimal-value
*1("E" ("+"/"-") zero-decimal-value) = integer-value ("." zero-integer-value)

SQUOTE = %x27
; ' (Single Quote)

;;
;; RFC 4234 core rules.
;;

ALPHA = %x41-5A / %x61-7A
; A-Z / a-z

CR = %x0D
; carriage return

CRLF = CR LF
; Internet standard newline

DIGIT = %x30-39
; 0-9

DQUOTE = %x22
; " (Double Quote)

HEXDIG = DIGIT /
%x61 / %x62 / %x63 / %x64 / %x65 / %x66
; only lower-case a..f

HTAB = %x09
; horizontal tab

LF = %x0A
; linefeed

SP = %x20
; space

VCHAR = %x21-7E
; visible (printing) characters

WSP = SP / HTAB
; white space

13. Error Responses for YANG Related Errors

A number of NETCONF error responses are defined for error cases
related to the data-model handling. If the relevant YANG statement
has an "error-app-tag" substatement, that overrides the default value
specified below.

13.1. Error Message for Data that Violates a unique Statement:

If a NETCONF operation would result in configuration data where a
unique constraint is invalidated, the following error is returned:

Tag: operation-failed
Error-app-tag: data-not-unique
Error-info: <non-unique>: Contains an instance identifier which
points to a leaf which invalidates the unique
constraint. This element is present once for each
leaf invalidating the unique constraint.

The <non-unique> element is in the YANG
namespace ("urn:ietf:params:xml:ns:yang:1"
[XXX IANA]). ("urn:ietf:params:xml:ns:yang:1").

[skipping...]

13.6. Error Message for Data that Violates a mandatory choice
statement:

If a NETCONF operation would result in configuration data where no
nodes exists in a mandatory choice, the following error is returned:

Tag: data-missing
Error-app-tag: missing-choice
Error-path: Path to the element with the missing choice.
Error-info: <missing-choice>: Contains the name of the missing
mandatory choice.

The <missing-choice> element is in the YANG
namespace ("urn:ietf:params:xml:ns:yang:1"
[XXX IANA]). ("urn:ietf:params:xml:ns:yang:1").

[skipping...]

14. IANA Considerations

+-------------------------------------------------------------------+
| Open Question |
+-------------------------------------------------------------------+
| Write this section properly. We need

This document defines a registry for (sub)module |
| names YANG module and submodule names.
The name of the registry is "YANG Module Names".

The registry shall record for each entry:

o the name of the module namespaces. |
+-------------------------------------------------------------------+ or submodule

o for modules, the assigned XML namespace

o for submodules, the name of the module it belongs to

o a reference to the (sub)module's documentation (the RFC number)

For allocation, RFC publication is required as per RFC 5226
[RFC5226]. All registered YANG module names must comply with the
rules for identifiers stated in Section 6.2. There are no initial
assignments.

The module name prefix 'ietf-' is reserved for IETF stream documents
while the module name prefix 'irtf-' is reserved for IRTF stream
documents. Modules published in other RFC streams must have a
similar suitable prefix. The prefix 'iana-' is reserved for modules
maintained by IANA.

This document registers two URIs for the YANG and YIN XML namespace namespaces
in the IETF XML registry [RFC3688]. Following the format in RFC
3688, the following registration is requested.

URI: urn:ietf:params:xml:ns:yang:yin:1
URI: urn:ietf:params:xml:ns:yang:1

Registrant Contact: The IESG.

XML: N/A, the requested URIs are XML namespaces.

[skipping...]

17. Acknowledgements

The authors wish to thank the following individuals, who all provided
helpful comments on various versions of this document: Mehmet Ersue,
Joel Halpern, Leif Johansson, Ladislav Lhotka, Gerhard Muenz, Tom
Petch, Randy Preshun, David Reid, Bert Wijnen.

18. References

17.1.

18.1. Normative References

[IEEE.754]
Institute of Electrical and Electronics Engineers,
"Standard for Binary Floating-Point Arithmetic",
IEEE Standard 754, August 1985.

[ISO.10646]
International Organization for Standardization,
"Information Technology - Universal Multiple-octet coded
Character Set (UCS) - Part 1: Architecture and Basic
Multilingual Plane", ISO Standard 10646-1, May 1993.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.

[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.

[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.

[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006.

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.

[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.

[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", RFC 5277, July 2008.

[XML-NAMES]
Tobin, R., Bray, T., Hollander, D., and A. Layman,
"Namespaces in XML 1.0 (Second Edition)", World Wide Web
Consortium Recommendation REC-xml-names-20060816,
August 2006,
<http://www.w3.org/TR/2006/REC-xml-names-20060816>.

[XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath)
Version 1.0", World Wide Web Consortium
Recommendation REC-xpath-19991116, November 1999,
<http://www.w3.org/TR/1999/REC-xpath-19991116>.

[XSD-TYPES]
Biron, P V. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", W3C REC REC-xmlschema-2-20041028,
October 2004.

[XSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0", World
Wide Web Consortium Recommendation REC-xslt-19991116,
November 1999,
<http://www.w3.org/TR/1999/REC-xslt-19991116>.

17.2.

18.2. Non-Normative References

[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.

[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2",
STD 58, RFC 2579, April 1999.

[RFC3780] Strauss, F. and J. Schoenwaelder, "SMIng - Next Generation
Structure of Management Information", RFC 3780, May 2004.

Appendix A. ChangeLog

A.1. Version -05

o Replaced the data types "float32" and "float64" with "decimal64".

o Specified that the elements in the XML encoding of configuration
data can occur in any order.

o Clarified that "augement" cannot add multiple nodes with the same
name.

o Clarified what "when" means in RPC input / output.

o Wrote the IANA Considerations section.

A.2. Version -04

o Using "revision-date" substatement to "import" and "include".

o Corrected grammar and text for instance-identifier.

o Fixed bugs in some examples.

o Rewrote the YIN description to use a declarative style.

o Added two error codes in Section 13.

o Clarified that YANG uses the same XPath data model as XSLT.

o Specified which errors are generated in Section 8.3.1.

o Corrected grammar for key-arg; now allowing optional prefix on
each leaf identifier.

o Clarified that "unique" constraints only check instances with
values for all referenced leafs.

o Clarified how mandatory and min-elements constraints are enforced.

o Editorial fixes.

A.2.

A.3. Version -03

o Added import by revision (yang-00413)

o Changed type "keyref" to "leafref", and added the statement
"require-instance" (yang-01253)
o Clarified that data sent from the server must be in the canonical
form.

o Clarified when and how constraints in the models are enforced.

o Many editorial fixes

o Added more strict grammar for the "deviate" statement.

A.3.

A.4. Version -02

o Added module update rules. (yang-00000)

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 "when" on all data defintion statements. (yang-00088)

o Added section "Constraints" and clarified when constraints are
enforced. (yang-00172)

o Added "feature" and "if-feature" statements. (yang-00750)

o Added "prefix" as a substatement to "belongs-to". (yang-00755)

o Added section on Conformance. (yang-01281)

o Added "deviation" statement. (yang-01281)

o Added "identity" statement and "identityref" type. (yang-01339)

o Aligned grammar for "enum" with text.

A.4.

A.5. Version -01

o Removed "Appendix A. Derived YANG Types".

o Removed "Appendix C. XML Schema Considerations".

o Removed "Appendix F. Why We Need a New Modeling Language".

o Moved "Appendix B. YIN" to its own section.

o Moved "Appendix D. YANG ABNF Grammar" to its own section.

o Moved "Appendix E. Error Responses for YANG Related Errors" into
its own section.

o The "input" and "output" nodes are now implicitly created by the
"rpc" statement, in order for augmentation of these nodes to work
correctly.

o Allow "config" in "choice".

o Added reference to XPath 1.0.

o Using an XPath function "current()" instead of the variable
"$this".

o Clarified that a "must" expression in a configuration node must
not reference non-configuration nodes.

o Added XML encoding rules and usage examples for rpc and
notification.

o Removed requirement that refinements are specified in the same
order as in the original grouping's definition.

o Fixed whitespace issues in the ABNF grammar.

o Added the term "mandatory node", and refer to it in the
description of augment (see Section 7.15), and choice (see
Section 7.9.3).

o Added support for multiple "pattern" statements in "type".

o Several clarifications and fixed typos.

A.5.

A.6. Version -00

Changes from draft-bjorklund-netconf-yang-02.txt

o Fixed bug in grammar for bit-stmt

o Fixed bugs in example XPath expressions

o Added keyword 'presence' to the YIN mapping table

Author's Address

Martin Bjorklund (editor)
Tail-f Systems

Email: [email-masked]

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 09 Apr 2009 18:15:45 +0200 (CEST)

> 05-to-be.  Please check that my edits are correct!

No, one edit is not correct.  The description of decimal64 contains
some weird characters.  Here's the description for decimal64:

  The decimal64 type represents a subset of the real numbers, which
  can be represented by decimal numerals.  The value space of
  decimal64 is the set of numbers that can be obtained by multiplying
  a 64 bit signed integer by a negative power of ten, i.e. expressible
  as "i x 10^-n" where i is an integer64 and n is an integer between 1
  and 18, inclusively.

/martin