draft-ietf-netmod-yang-metadata-01.txt   draft-ietf-netmod-yang-metadata-02.txt 
NETMOD Working Group L. Lhotka NETMOD Working Group L. Lhotka
Internet-Draft CZ.NIC Internet-Draft CZ.NIC
Intended status: Standards Track June 10, 2015 Intended status: Standards Track September 17, 2015
Expires: December 12, 2015 Expires: March 20, 2016
Defining and Using Metadata with YANG Defining and Using Metadata with YANG
draft-ietf-netmod-yang-metadata-01 draft-ietf-netmod-yang-metadata-02
Abstract Abstract
This document defines a YANG extension statement that allows for This document defines a YANG extension statement that allows for
defining syntax of metadata annotions in YANG modules. The document defining metadata annotations in YANG modules. The document also
also specifies XML and JSON encoding of annotations and other rules specifies XML and JSON encoding of annotations and other rules for
for annotating instances of YANG data nodes. annotating instances of YANG data nodes.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted 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). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 12, 2015. This Internet-Draft will expire on March 20, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Defining Annotations in YANG . . . . . . . . . . . . . . . . 5 2.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 4
4. The Encoding of Annotations . . . . . . . . . . . . . . . . . 7 2.2. Terms Defined in Other Documents . . . . . . . . . . . . 4
4.1. XML Encoding . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Namespaces and Prefixes . . . . . . . . . . . . . . . . . 6
4.2. JSON Encoding . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Definitions of New Terms . . . . . . . . . . . . . . . . 6
4.2.1. Metadata Object and Annotations . . . . . . . . . . . 8 3. Defining Annotations in YANG . . . . . . . . . . . . . . . . 6
4.2.2. Adding Annotations to Anydata, Container and List 3.1. Example Definition . . . . . . . . . . . . . . . . . . . 7
Instances . . . . . . . . . . . . . . . . . . . . . . 8 4. Using Annotations . . . . . . . . . . . . . . . . . . . . . . 8
4.2.3. Adding Annotations to Anyxml and Leaf Instances . . . 9 5. The Encoding of Annotations . . . . . . . . . . . . . . . . . 9
4.2.4. Adding Annotations to Leaf-list Instances . . . . . . 9 5.1. XML Encoding . . . . . . . . . . . . . . . . . . . . . . 9
5. Representing Annotations in DSDL Schemas . . . . . . . . . . 10 5.2. JSON Encoding . . . . . . . . . . . . . . . . . . . . . . 10
6. Metadata YANG Module . . . . . . . . . . . . . . . . . . . . 11 5.2.1. Metadata Object and Annotations . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5.2.2. Adding Annotations to Anydata, Container and List
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 Entries . . . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 5.2.3. Adding Annotations to Anyxml and Leaf Instances . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2.4. Adding Annotations to Leaf-list Entries . . . . . . . 12
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 6. Representing Annotations in DSDL Schemas . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 15 7. Metadata YANG Module . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
A.1. Changes Between Revisions -00 and -01 . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
A.2. Changes Between draft-lhotka-netmod-yang-metadata-01 and 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
draft-ietf-netmod-yang-metadata-00 . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
A.3. Changes Between draft-lhotka-netmod-yang-metadata-00 and 11.1. Normative References . . . . . . . . . . . . . . . . . . 17
-01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19
A.1. Changes Between Revisions -01 and -02 . . . . . . . . . . 19
A.2. Changes Between Revisions -00 and -01 . . . . . . . . . . 19
A.3. Changes Between draft-lhotka-netmod-yang-metadata-01 and
draft-ietf-netmod-yang-metadata-00 . . . . . . . . . . . 19
A.4. Changes Between draft-lhotka-netmod-yang-metadata-00 and
-01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
There is a need to be able to annotate instances of There is a need to be able to annotate instances of
YANG [I-D.ietf-netmod-rfc6020bis] data nodes with metadata. Typical YANG [I-D.ietf-netmod-rfc6020bis] data nodes with metadata. Typical
use cases are: use cases are:
o Complementing regular data model information with instance-
specific metadata, comments etc.
o Providing information about data rendering in user interfaces.
o Deactivating a subtree in a configuration datastore while keeping o Deactivating a subtree in a configuration datastore while keeping
the data in place. the data in place.
o Complementing data model information with instance-specific data. o Network management protocols often use metadata annotations for
various purposes in both operation requests and responses. For
o RPC operations may use metadata annotations for various purposes example, the <edit-config> operation in the NETCONF protocol (see
in both requests and responses. For example, the <edit-config> section 7.2 of [RFC6241]) uses annotations in the form of XML
operation in the NETCONF protocol (see section 7.2 of [RFC6241]) attributes for identifying the location in a configuration
uses annotations in the form of XML attributes for identifying the datastore and the type of the operation.
point in the configuration and type of the operation.
However, metadata annotations could potentially lead to However, metadata annotations could potentially lead to
interoperability problems if they are used in an ad hoc fashion by interoperability problems if they are used in an ad hoc fashion by
different organizations and/or without proper documentation. A sound different parties and/or without proper documentation. A sound
metadata framework for YANG should therefore satisfy these metadata framework for YANG should therefore satisfy these
requirements: requirements:
1. The set of annotations must be extensible in a distributed manner 1. The set of annotations must be extensible in a decentralised
so as to allow for defining new annotations without running into manner so as to allow for defining new annotations without
the risk of collisions with annotations defined and used by running into the risk of collisions with annotations defined and
others. used by others.
2. Syntax and semantics of annotations must be documented and the 2. Syntax and semantics of annotations must be documented and the
documentation must be easily accessible. documentation must be easily accessible.
3. Clients of network management protocols such as NETCONF [RFC6241] 3. Clients of network management protocols such as NETCONF [RFC6241]
or RESTCONF [I-D.ietf-netconf-restconf] must be able to learn all or RESTCONF [I-D.ietf-netconf-restconf] must be able to discover
annotations supported by a given server and identify each of them all annotations supported by a given server and identify each of
correctly. them correctly.
This document proposes a systematic way for defining the syntax of 4. Annotations sent by a server should not break clients that don't
metadata annotations. For this purpose, YANG extension statement support them.
"annotation" is defined in the module "ietf-yang-metadata"
(Section 6). Other YANG modules importing this module can use the
"annotation" statement for defining the syntax of one or more
annotations.
The benefits of defining the syntax of metadata annotations in a YANG This document proposes a systematic way for defining metadata
module are the following: annotations. For this purpose, YANG extension statement "annotation"
is defined in the module "ietf-yang-metadata" (Section 7). Other
YANG modules importing this module can use the "annotation" statement
for defining one or more annotations.
The benefits of defining the metadata annotations in a YANG module
are the following:
o Each annotation is bound to a YANG module name, namespace URI and o Each annotation is bound to a YANG module name, namespace URI and
prefix. This makes its encoding in instance documents (both XML prefix. This makes its encoding in instance documents (both XML
and JSON) straightforward and consistent with the encoding of YANG and JSON) straightforward and consistent with the encoding of YANG
data node instances. data node instances.
o Annotations are indirectly registered through IANA YANG module o Annotations are indirectly registered through IANA in the "YANG
registration. Module Names" registry [RFC6020].
o Annotations are included in the data model. YANG compilers and o Annotations are included in the data model. YANG compilers and
tools supporting a certain annotation can thus take them into tools supporting a certain annotation can thus take them into
account and modify their behaviour accordingly. account and modify their behavior accordingly.
o Semantics of an annotation are defined in the "description" and
"reference" statements.
o An annotation can be declared as conditional by using the "if- o An annotation can be declared as conditional by using the "if-
feature" statement. feature" statement.
o Values of annotations are not limited to strings; any YANG built- o Values of annotations are not limited to strings; any YANG built-
in or derived type may be used for them. in or derived type may be used for them.
In the XML encoding, XML attributes are a natural instrument for
attaching annotations to data node instances. This document
deliberately adopts some restrictions in order to remain compatible
with the XML encoding of YANG data node instances and limitations of
XML attributes. Specifically,
o annotations are scalar values and cannot be further structured;
o annotations cannot be attached to a whole list or leaf-list
instance, only to individual list of leaf-list entries.
2. Terminology 2. Terminology
2.1. Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2.2. Terms Defined in Other Documents
The following terms are defined in [RFC6241]: The following terms are defined in [RFC6241]:
o capability,
o client, o client,
o datastore, o datastore,
o message, o message,
o operation, o protocol operation,
o server. o server.
The following terms are defined in [I-D.ietf-netmod-rfc6020bis]: The following terms are defined in [I-D.ietf-netmod-rfc6020bis]:
o action,
o anydata, o anydata,
o anyxml, o anyxml,
o built-in type, o data type,
o derived type,
o container, o container,
o data model, o data model,
o data node, o data node,
o derived type, o data tree,
o extension, o extension,
o leaf,
o leaf-list, o leaf-list,
o list, o list,
o module, o module,
o RPC operation, o RPC input and output.
o submodule,
o type.
The following terms are defined in [W3C.REC-xml-infoset-20040204]: The following terms are defined in [W3C.REC-xml-infoset-20040204]:
o attribute, o attribute,
o document, o document,
o element, o element.
o namespace, The following terms are defined in [W3C.REC-xml-names11-20060816]:
o prefix. o local name,
o namespace name,
o prefix,
o qualified name.
The following terms are defined in [RFC7159]: The following terms are defined in [RFC7159]:
o array, o array,
o member, o member,
o object, o object,
o primitive type. o primitive type.
2.3. Namespaces and Prefixes
In the following text, XML element names and YANG extension In the following text, XML element names and YANG extension
statements are always written with explicit namespace prefixes that statements are always written with explicit namespace prefixes that
are assumed to be bound to URI references as shown in Table 1. are assumed to be bound to URI references as shown in Table 1.
+--------+------------------------------------------------+ +--------+------------------------------------------------+
| Prefix | URI Reference | | Prefix | URI Reference |
+--------+------------------------------------------------+ +--------+------------------------------------------------+
| rng | http://relaxng.org/ns/structure/1.0 | | elm | http://example.org/example-last-modified |
| md | urn:ietf:params:xml:ns:yang:ietf-yang-metadata | | md | urn:ietf:params:xml:ns:yang:ietf-yang-metadata |
| ein | http://example.org/example-inactive | | rng | http://relaxng.org/ns/structure/1.0 |
+--------+------------------------------------------------+ +--------+------------------------------------------------+
Table 1: Used namespace prefixes and corresponding URI references Table 1: Used namespace prefixes and corresponding URI references
2.4. Definitions of New Terms
o annotation: a single item of metadata that is attached to YANG
data node instances.
o metadata: additional information that complements a data tree.
o metadata object: an object in JSON encoding that contains all
annotations attached to a given data node instance.
3. Defining Annotations in YANG 3. Defining Annotations in YANG
Metadata annotations are defined by YANG extension statement Metadata annotations are defined by YANG extension statement
"md:annotation". This YANG language extension is defined in the "md:annotation". This YANG language extension is defined in the
module "ietf-yang-metadata" (Section 6). module "ietf-yang-metadata" (Section 7).
Substatements of "md:annotation" are shown in Table 2. They are all Substatements of "md:annotation" are shown in Table 2. They are all
core YANG statements, and the numbers in the second column refer to core YANG statements, and the numbers in the second column refer to
the corresponding sections in [I-D.ietf-netmod-rfc6020bis] where each the corresponding section in [I-D.ietf-netmod-rfc6020bis] where each
statement is described. statement is described.
+--------------+---------------------+-------------+ +--------------+---------------------+-------------+
| substatement | RFC 6020bis section | cardinality | | substatement | RFC 6020bis section | cardinality |
+--------------+---------------------+-------------+ +--------------+---------------------+-------------+
| description | 7.20.3 | 0..1 | | description | 7.21.3 | 0..1 |
| if-feature | 7.19.2 | 0..n | | if-feature | 7.20.2 | 0..n |
| reference | 7.20.4 | 0..1 | | reference | 7.21.4 | 0..1 |
| status | 7.20.2 | 0..1 | | status | 7.21.2 | 0..1 |
| type | 7.6.3 | 0..1 | | type | 7.6.3 | 1 |
| units | 7.3.3 | 0..1 | | units | 7.3.3 | 0..1 |
+--------------+---------------------+-------------+ +--------------+---------------------+-------------+
Table 2: Substatements of "md:annotation". Table 2: Substatements of "md:annotation".
Using the "type" statement, a type may be specified for the Using the "type" statement, a type is specified for the annotation
annotation value according to the same rules as for YANG leaf or value according to the same rules as for YANG "leaf" type.
leaf-list types. However, the "type" statement is optional as a
substatement of "md:annotation" statement. If it is not present, the
built-in "string" type is the default.
The "if-feature" statement, if present, makes the annotation An annotation can be made conditional by using one or more "if-
conditional: it is supported only by servers that advertise the feature" statements; the annotation is then supported only by servers
corresponding feature. that advertise the corresponding feature.
For example, the following module defines the "inactive" annotation: The semantics and usage rules for an annotation SHOULD be fully
specified in "description", "reference" and "units" statements.
module example-inactive { An annotation MUST NOT change the data tree semantics defined by
namespace "http://example.org/example-inactive"; YANG. For example, it is illegal to define and use an annotation
prefix "ein"; that allows for overriding uniqueness of leaf-list entries.
The "status" statement can be used exactly as for YANG data nodes.
A YANG module containing one or more "md:annotation" extension
statements SHOULD NOT be used for defining data nodes or groupings.
Also, derived types, identities and features SHOULD NOT be defined in
such a module unless they are used by the definitions of annotations
in that module.
3.1. Example Definition
The following module defines the "last-modified" annotation:
module example-last-modified {
namespace "http://example.org/example-last-modified";
prefix "elm";
import ietf-yang-types {
prefix "yang";
}
import ietf-yang-metadata { import ietf-yang-metadata {
prefix "md"; prefix "md";
} }
md:annotation inactive { md:annotation last-modified {
type boolean; type yang:date-and-time;
description description
"If this annotation is attached to a configuration data node, "This annotation contains date and time when the
then the data subtree rooted at this node is deactivated."; annotated instance was last modified (or created).";
} }
} }
By advertising a YANG module in which metadata annotation A is 4. Using Annotations
defined using the "md:annotation" statement, a server specifies
support for the syntax of annotation A. This means that
configuration or state data, RPC messages and notifications will be
considered syntactically valid if annotation A is attached to any
data node instance, provided that all rules stated in this document
are observed.
However, the semantics of an annotation, usage rules, and expected By advertising a YANG module in which a metadata annotation is
behavior of clients and servers MUST be specified separately by other defined using the "md:annotation" statement, a server indicates that
means that are outside the scope of this document. it is prepared to handle that annotation anywhere in any data tree
that is a part of the server's data model (configuration, state data,
RPC operation/action input or output). That is, an annotation
advertised by the server may be attached to any instance of a data
node defined in any YANG module that is also advertised by the
server.
4. The Encoding of Annotations Depending on its semantics, an annotation may have an effect only in
certain data trees and/or on instances of specific data nodes types.
If such an annotation appears elsewhere, it is syntactically valid
but the annotation is ignored.
A client MUST NOT use an annotation in protocol operations if the
server didn't advertise it.
Annotations modify the schema of datastores and/or management
protocol messages, and may also change their semantics. Therefore,
due care has to be exercised when introducing annotations in network
management systems in order to avoid interoperability problems and
software failures. The following aspects should be taken into
account:
o A client may not not be able to parse or validate protocol
messages containing annotations.
o A client may not understand semantics of an annotation set by the
server or other clients.
Generally, it is safe for a server to use annotations in the
following cases, provided that the client is able to parse them and
discard those that it doesn't understand or support:
o An annotation is an integral part of a built-in or negotiated
protocol capability.
o An annotation contains optional information that is not critical
for protocol operation.
o The client explicitly asks the server, e.g., via a parameter of a
protocol operation request, for including an annotation in the
response.
5. The Encoding of Annotations
XML attributes are a natural choice for encoding metadata in XML XML attributes are a natural choice for encoding metadata in XML
instance documents. For JSON [RFC7159], there is no generally instance documents. For JSON [RFC7159], there is no generally
established method for encoding metadata. This document thus established method for encoding metadata. This document thus
introduces a special encoding method that is consistent with the JSON introduces a special encoding method that is consistent with the JSON
encoding of YANG data node instances as defined encoding of YANG data node instances as defined
in [I-D.ietf-netmod-yang-json]. in [I-D.ietf-netmod-yang-json].
4.1. XML Encoding 5.1. XML Encoding
Metadata annotations are added to XML-encoded instances of YANG data Metadata annotations are added to XML-encoded instances of YANG data
nodes as XML attributes according to these rules: nodes as XML attributes according to these rules:
o The local name of the attribute SHALL be the same as the name of o The local name of the attribute SHALL be the same as the name of
the annotation specified in the argument of the corresponding the annotation specified in the argument of the corresponding
"md:annotation" statement. "md:annotation" statement.
o The namespace of the attribute SHALL be identified by the URI that o The namespace of the attribute SHALL be identified by the URI that
appears as the argument of the "namespace" statement in the YANG appears as the argument of the "namespace" statement in the YANG
module where the annotation is defined. It is RECOMMENDED that module where the annotation is defined. It is RECOMMENDED that
the prefix specified by the "prefix" statement in the same module the prefix specified by the "prefix" statement in the same module
is used in the qualified name of the attribute. is used in the qualified name of the attribute.
o The attribute value SHALL be encoded in the same way as the value o The attribute value SHALL be encoded in the same way as the value
of a YANG leaf instance having the same type, of a YANG leaf instance having the same type,
see [I-D.ietf-netmod-rfc6020bis], sec. 9. see [I-D.ietf-netmod-rfc6020bis], sec. 9.
For example, the "inactive" annotation defined in Section 3 may be For example, the "last-modified" annotation defined in Section 3.1
encoded as follows: may be encoded as follows:
<foo xmlns:ein="http://example.org/example-inactive" <foo xmlns:elm="http://example.org/example-last-modified"
ein:inactive="true"> elm:last-modified="2015-09-16T10:27:35+02:00">
... ...
</foo> </foo>
4.2. JSON Encoding 5.2. JSON Encoding
The JSON metadata encoding defined in this section has the following The JSON metadata encoding defined in this section has the following
properties: properties:
1. The encoding of YANG data node instances as defined in 1. The encoding of YANG data node instances as defined in
[I-D.ietf-netmod-yang-json] does not change. [I-D.ietf-netmod-yang-json] does not change.
2. Namespaces of metadata annotations are encoded in the same way as 2. Namespaces of metadata annotations are encoded in the same way as
namespaces of YANG data node instances, see namespaces of YANG data node instances, see
[I-D.ietf-netmod-yang-json]. [I-D.ietf-netmod-yang-json].
4.2.1. Metadata Object and Annotations 5.2.1. Metadata Object and Annotations
All metadata annotations assigned to a YANG data node instance are All metadata annotations assigned to a YANG data node instance are
encoded as members (name/value pairs) of a single JSON object, encoded as members (name/value pairs) of a single JSON object,
henceforth denoted as the metadata object. The placement and name of henceforth denoted as the metadata object. The placement and name of
this object depends on the type of the data node as specified in the this object depends on the type of the data node as specified in the
following subsections. following subsections.
The name of a metadata annotation (as a member of the metadata The name of a metadata annotation (as a member of the metadata
object) SHALL be of the following form: object) has the following ABNF syntax [RFC5234], where the production
for "identifier" is defined in sec. 13 of
[I-D.ietf-netmod-rfc6020bis]
MODULE_NAME:LOCAL_NAME annotation-name = identifier ":" identifier
where MODULE_NAME is the name of the YANG module in which the where the left identifier is the name of the YANG module in which the
annotation is defined, and LOCAL_NAME is the name of the annotation annotation is defined, and the identifier on the right is the name of
specified in the argument of the corresponding "md:annotation" the annotation specified in the argument of the corresponding
statement. "md:annotation" statement.
Note that unlike YANG data node instances, for annotations the Note that unlike member names of YANG data node instances in JSON
explicit namespace identifier (MODULE_NAME) must always be used. encoding (see sec. 4 in [I-D.ietf-netmod-yang-json]), for annotations
the explicit namespace identifier (module name) must always be
present.
The value of a metadata annotation SHALL be encoded in exactly the The value of a metadata annotation SHALL be encoded in exactly the
same way as the value of a YANG leaf node having the same type as the same way as the value of a YANG leaf node having the same type as the
annotation, see [I-D.ietf-netmod-yang-json], sec. 6. annotation, see [I-D.ietf-netmod-yang-json], sec. 6.
4.2.2. Adding Annotations to Anydata, Container and List Instances 5.2.2. Adding Annotations to Anydata, Container and List Entries
For an instance that is encoded as a JSON object (i.e., a container, For a data node instance that is encoded as a JSON object (i.e., a
a list entry, or anydata node), the metadata object is added as a new container, list entry, or anydata node), the metadata object is added
member of that object with the name "@". as a new member of that object with the name "@".
Examples: Examples:
o "cask" is a container node: o "cask" is a container or anydata node:
"cask": { "cask": {
"@": { "@": {
"example-inactive:inactive": true "example-last-modified:last-modified":
"2015-09-16T10:27:35+02:00"
}, },
... ...
} }
o "seq" is a list whose key is "name", annotation "inactive" is o "seq" is a list whose key is "name", annotation "last-modified" is
added only to the first entry: added only to the first entry:
"seq": [ "seq": [
{ {
"@": { "@": {
"example-inactive:inactive": true "example-last-modified:last-modified":
"2015-09-16T10:27:35+02:00"
}, },
"name": "one", "name": "one",
... ...
}, },
{ {
"name": "two", "name": "two",
... ...
} }
] ]
4.2.3. Adding Annotations to Anyxml and Leaf Instances 5.2.3. Adding Annotations to Anyxml and Leaf Instances
For an anyxml or leaf instance, the metadata object is added as a For an anyxml or leaf instance, the metadata object is added as a
sibling name/value pair whose the name is the symbol "@" concatenated sibling name/value pair whose name is the symbol "@" concatenated
with the name of the leaf or anyxml member that is being annotated. with the name of the leaf or anyxml member that is being annotated.
The namespace part (module name) is included if and only if it is in
the name of the annotated member.
For example, if "flag" is a leaf node of the "boolean" type: Examples:
"flag": true, o "flag" is a leaf node of the "boolean" type defined in module
"@flag": { "foo", and we assume the namespace name has to be expressed in its
"example-inactive:inactive": true JSON encoding:
"foo:flag": true,
"@foo:flag": {
"example-last-modified:last-modified":
"2015-09-16T10:27:35+02:00"
} }
4.2.4. Adding Annotations to Leaf-list Instances o "stuff" is an anyxml node:
For a leaf-list instance, which is represented as a JSON array with "stuff": [1, null, "three"],
"@stuff": {
"example-last-modified:last-modified":
"2015-09-16T10:27:35+02:00"
}
5.2.4. Adding Annotations to Leaf-list Entries
For a leaf-list entry, which is represented as a JSON array with
values of a primitive type, annotations may be assigned to one or values of a primitive type, annotations may be assigned to one or
more entries by adding a name/array pair as a sibling of the leaf- more entries by adding a name/array pair as a sibling of the leaf-
list instance, where the name is symbol "@" concatenated with the list entry, where the name is symbol "@" concatenated with the name
name of the leaf-list that is being annotated, and the value is a of the leaf-list that is being annotated, and the value is a JSON
JSON array whose i-th element is the metadata object with annotations array whose i-th element is the metadata object with annotations
assigned to the i-th entry of the leaf-list instance, or null if the assigned to the i-th entry of the leaf-list entry, or null if the
i-th entry has no annotations. i-th entry has no annotations.
Trailing null values in that array, i.e., those following the last Trailing null values in that array, i.e., those following the last
non-null metadata object, MAY be omitted. non-null metadata object, MAY be omitted.
For example, in the following leaf-list instance with four entries, For example, in the following leaf-list instance with four entries,
the "inactive" annotation is added to the second and third entry in the "last-modified" annotation is added to the second and third entry
the following way: in the following way:
"bibliomod:folio": [6, 3, 7, 8], "bibliomod:folio": [6, 3, 7, 8],
"@bibliomod:folio": [ "@bibliomod:folio": [
null, null,
{"example-inactive:inactive": true}, { "example-last-modified:last-modified":
{"example-inactive:inactive": true} "2015-06-18T17:01:14+02:00"
},
{ "example-last-modified:last-modified":
"2015-09-16T10:27:35+02:00"
}
] ]
5. Representing Annotations in DSDL Schemas 6. Representing Annotations in DSDL Schemas
[RFC6110] defines the standard mapping of YANG data models to [RFC6110] defines the standard mapping of YANG data models to
Document Schema Definition Languages (DSDL) [ISO.19757-1]. This Document Schema Definition Languages (DSDL) [ISO.19757-1]. This
section specifies the mapping for the extension statement section specifies the mapping for the extension statement
"md:annotation" (Section 6), which enables validation of XML instance "md:annotation" (Section 7), which enables validation of XML instance
documents containing metadata annotations. documents containing metadata annotations.
The first step of the DSDL mapping procedure, i.e., the The first step of the DSDL mapping procedure, i.e., the
transformation of the YANG data model to the hybrid schema (see transformation of the YANG data model to the hybrid schema (see
sec. 6 in [RFC6110]), is modified as follows: sec. 6 in [RFC6110]), is modified as follows:
1. If the data model contains at least one "md:annotation" 1. If the data model contains at least one "md:annotation"
statement, then a RELAX NG named pattern definition MUST be added statement, then a RELAX NG named pattern definition MUST be added
as a child of the root <rng:grammar> element in the hybrid as a child of the root <rng:grammar> element in the hybrid
schema. It is RECOMMENDED to use the name "__yang_metadata__" schema. It is RECOMMENDED to use the name "__yang_metadata__"
for this named pattern. for this named pattern.
2. A reference to the named pattern described in item 1 MUST be 2. A reference to the named pattern described in item 1 MUST be
included as a child of every <rng:element> pattern that included as a child of every <rng:element> pattern that
corresponds to a container, leaf, list or leaf-list data node. corresponds to an anydata, container, leaf, leaf-list or list
data node.
3. Every metadata annotation definition in the form 3. Every metadata annotation definition in the form
md:annotation ARGUMENT;
or
md:annotation ARGUMENT { md:annotation ARGUMENT {
... ...
} }
is mapped to the following RELAX NG pattern: is mapped to the following RELAX NG pattern:
<rng:attribute name="PREFIX:ARGUMENT"> <rng:optional>
... <rng:attribute name="PREFIX:ARGUMENT">
</rng:attribute> ...
</rng:attribute>
</rng:optional>
where PREFIX is the namespace prefix bound to the namespace URI where PREFIX is the prefix bound to the namespace URI of the YANG
of the YANG module that contains the "md:annotation" statement. module that contains the "md:annotation" statement. The above
Each "rng:attribute" pattern SHALL be wrapped in the pattern SHALL be inserted as a child of the named pattern
<rng:optional> pattern, and this SHALL be inserted as a child of described in item 1.
the named pattern definition described in item 1.
4. Substatements of "md:annotation", if there are any, SHALL be 4. Substatements of "md:annotation" SHALL be mapped to children of
mapped to children of the "rng:attribute" pattern exactly as the "rng:attribute" pattern exactly as described in sec. 10 of
described in sec. 10 of [RFC6110]. [RFC6110].
For example, the named pattern definition (item 1), when constructed For example, the named pattern (item 1), when constructed only for
only for the "inactive" annotation, will have the following form: the "last-modified" annotation, will have the following definition:
<rng:define name="__yang_metadata__"> <rng:define name="__yang_metadata__">
<rng:optional> <rng:optional>
<rng:attribute name="ein:inactive"> <rng:attribute name="elm:last-modified">
<rng:choice> <rng:ref name="ietf-yang-types__date-and-time"/>
<rng:value>true</rng:value>
<rng:value>false</rng:value>
</rng:choice>
</rng:attribute> </rng:attribute>
</rng:optional> </rng:optional>
</rng:define> </rng:define>
Every "rng:element" pattern that corresponds to a container, leaf, Every "rng:element" pattern that corresponds to an anydata,
list or leaf-list data node will then contain a reference to the container, leaf, list or leaf-list data node will then contain a
above named pattern, for example reference to the above named pattern, for example
<rng:element name="foo:bar"> <rng:element name="foo:bar">
<rng:ref name="__yang_metadata__"/> <rng:ref name="__yang_metadata__"/>
... ...
</rng:element> </rng:element>
Note that it is not necessary to use such a reference for Note that it is not necessary to use such a reference for
"rng:element" patterns corresponding to anyxml data nodes because "rng:element" patterns corresponding to anyxml data nodes because
they already permit any XML attributes to be attached to their they already permit any XML attributes to be attached to their
instances. instances.
The second step of the DSDL mapping procedure, i.e., the The second step of the DSDL mapping procedure, i.e., the
transformation of the hybrid schema to RELAX NG, Schematron and DSRL transformation of the hybrid schema to RELAX NG, Schematron and DSRL
schemas, is unaffected by the inclusion of "md:annotation". schemas, is unaffected by the inclusion of "md:annotation".
6. Metadata YANG Module 7. Metadata YANG Module
RFC Editor: In this section, replace all occurrences of 'XXXX' with RFC Editor: In this section, replace all occurrences of 'XXXX' with
the actual RFC number and all occurrences of the revision date below the actual RFC number and all occurrences of the revision date below
with the date of RFC publication (and remove this note). with the date of RFC publication (and remove this note).
<CODE BEGINS> file "ietf-yang-metadata@2015-06-09.yang" <CODE BEGINS> file "ietf-yang-metadata@2015-09-17.yang"
module ietf-yang-metadata { module ietf-yang-metadata {
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-metadata"; namespace "urn:ietf:params:xml:ns:yang:ietf-yang-metadata";
prefix "md"; prefix "md";
organization organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group"; "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
contact contact
"WG Web: <http://tools.ietf.org/wg/netmod/> "WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org> WG List: <mailto:netmod@ietf.org>
skipping to change at page 12, line 21 skipping to change at page 15, line 9
contact contact
"WG Web: <http://tools.ietf.org/wg/netmod/> "WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org> WG List: <mailto:netmod@ietf.org>
WG Chair: Thomas Nadeau WG Chair: Thomas Nadeau
<mailto:tnadeau@lucidvision.com> <mailto:tnadeau@lucidvision.com>
WG Chair: Juergen Schoenwaelder WG Chair: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de> <mailto:j.schoenwaelder@jacobs-university.de>
WG Chair: Kent Watsen
<mailto:kwatsen@juniper.net>
Editor: Ladislav Lhotka Editor: Ladislav Lhotka
<mailto:lhotka@nic.cz>"; <mailto:lhotka@nic.cz>";
description description
"This YANG module defines an extension statement that allows for "This YANG module defines an extension statement that allows for
defining metadata annotations. defining metadata annotations.
Copyright (c) 2014 IETF Trust and the persons identified as Copyright (c) 2015 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and
'OPTIONAL' in the module text are to be interpreted as described 'OPTIONAL' in the module text are to be interpreted as described
in RFC 2119 (http://tools.ietf.org/html/rfc2119). in RFC 2119 (http://tools.ietf.org/html/rfc2119).
This version of this YANG module is part of RFC XXXX This version of this YANG module is part of RFC XXXX
(http://tools.ietf.org/html/rfcXXXX); see the RFC itself for (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for
full legal notices."; full legal notices.";
revision 2015-06-09 { revision 2015-09-17 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Defining and Using Metadata with YANG"; "RFC XXXX: Defining and Using Metadata with YANG";
} }
extension annotation { extension annotation {
argument name; argument name;
description description
"This extension allows for defining metadata annotations in "This extension allows for defining metadata annotations in
YANG modules. The 'md:annotation' statement can appear only at YANG modules. The 'md:annotation' statement can appear only at
the top level of a YANG module. the top level of a YANG module.
The argument of the 'md:annotation' statement defines the name
of the annotation. Syntactically it is a YANG identifier as
defined in RFC 6020bis, sec. 6.2.
An annotation defined with this extension statement inherits An annotation defined with this extension statement inherits
the namespace and other context from the YANG module in which the namespace and other context from the YANG module in which
it is defined. it is defined.
Other properties of the annotation and documentation are Data type of the annotation value is specified in the same way
as for a leaf data node using the 'type' statement.
Semantics of the annotation and other documentation can be
specified using the following standard YANG substatements (all specified using the following standard YANG substatements (all
are optional): 'description', 'if-feature', 'reference', are optional): 'description', 'if-feature', 'reference',
'status', 'type' and 'units'. If the 'type' statement is not 'status', and 'units'.
present, the built-in 'string' type is used by default.
A server announces syntactic support for a particular
annotation by including the module in which the annotation is
defined among the advertised YANG modules (e.g., in NETCONF
hello message).
Semantics and usage rules for an annotation MUST be specified A server announces support for a particular annotation by
separately. The 'description' and/or 'reference' statements including the module in which the annotation is defined among
SHOULD provide corresponding links. the advertised YANG modules (e.g., in NETCONF hello message or
yang-library). The annotation then can be attached to any
instance of data node defined in any YANG module that is
advertised by the server.
XML and JSON encoding of annotations is defined in XML and JSON encoding of annotations is defined in
RFC XXXX."; RFC XXXX.";
} }
} }
<CODE ENDS> <CODE ENDS>
7. IANA Considerations 8. IANA Considerations
RFC Editor: In this section, replace all occurrences of 'XXXX' with RFC Editor: In this section, replace all occurrences of 'XXXX' with
the actual RFC number and all occurrences of the revision date below the actual RFC number and all occurrences of the revision date below
with the date of RFC publication (and remove this note). with the date of RFC publication (and remove this note).
This document registers the following namespace URI in the IETF XML This document registers a URI in the "IETF XML registry" [RFC3688].
registry [RFC3688]: Following the format in RFC 3688, the following registration has been
made.
--------------------------------------------------------------------- ---------------------------------------------------------------------
URI: urn:ietf:params:xml:ns:yang:ietf-yang-metadata URI: urn:ietf:params:xml:ns:yang:ietf-yang-metadata
Registrant Contact: The IESG. Registrant Contact: The NETMOD WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
--------------------------------------------------------------------- ---------------------------------------------------------------------
This document registers a YANG module in the "YANG Module Names"
This document registers the following YANG module in the YANG Module registry [RFC6020].
Names registry [I-D.ietf-netmod-rfc6020bis]:
--------------------------------------------------------------------- ---------------------------------------------------------------------
name: ietf-yang-metadata name: ietf-yang-metadata
namespace: urn:ietf:params:xml:ns:yang:ietf-yang-metadata namespace: urn:ietf:params:xml:ns:yang:ietf-yang-metadata
prefix: md prefix: md
reference: RFC XXXX reference: RFC XXXX
--------------------------------------------------------------------- ---------------------------------------------------------------------
8. Security Considerations 9. Security Considerations
This document introduces a mechanism for defining the syntax of This document introduces a mechanism for defining metadata
metadata annotations in YANG modules and using them with instances of annotations in YANG modules and attaching them to instances of YANG
YANG data nodes. By itself, this mechanism represents no security data nodes. By itself, this mechanism represents no security threat.
threat. Security implications of a particular annotation defined Security implications of a particular annotation defined using this
using this mechanism have to be duly considered and documented in the mechanism MUST be duly considered and documented in the the
specification of the annotation's semantics. annotation's definition.
9. Acknowledgments An annotation SHOULD be subject to the same or stricter access
control rules as the data node instance to which the annotation is
attached.
The author wishes to thank Andy Bierman, Martin Bjorklund and Kent 10. Acknowledgments
Watsen for their helpful comments and suggestions.
10. References The author wishes to thank Andy Bierman, Martin Bjorklund, Benoit
Claise, Juergen Schoenwaelder, and Kent Watsen for their helpful
comments and suggestions.
10.1. Normative References 11. References
11.1. Normative References
[I-D.ietf-netmod-rfc6020bis] [I-D.ietf-netmod-rfc6020bis]
Bjorklund, M., "YANG - A Data Modeling Language for the Bjorklund, M., "YANG - A Data Modeling Language for the
Network Configuration Protocol (NETCONF)", draft-ietf- Network Configuration Protocol (NETCONF)", draft-ietf-
netmod-rfc6020bis-05 (work in progress), May 2015. netmod-rfc6020bis-06 (work in progress), July 2015.
[I-D.ietf-netmod-yang-json] [I-D.ietf-netmod-yang-json]
Lhotka, L., "JSON Encoding of Data Modeled with YANG", Lhotka, L., "JSON Encoding of Data Modeled with YANG",
draft-ietf-netmod-yang-json-03 (work in progress), draft-ietf-netmod-yang-json-05 (work in progress),
February 2015. September 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>.
[RFC6110] Lhotka, L., "Mapping YANG to Document Schema Definition [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Languages and Validating NETCONF Content", RFC 6110, Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
February 2011. RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
Bierman, "Network Configuration Protocol (NETCONF)", RFC the Network Configuration Protocol (NETCONF)", RFC 6020,
6241, June 2011. DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data [RFC6110] Lhotka, L., Ed., "Mapping YANG to Document Schema
Interchange Format", RFC 7159, March 2014. Definition Languages and Validating NETCONF Content", RFC
6110, DOI 10.17487/RFC6110, February 2011,
<http://www.rfc-editor.org/info/rfc6110>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <http://www.rfc-editor.org/info/rfc7159>.
[W3C.REC-xml-infoset-20040204] [W3C.REC-xml-infoset-20040204]
Cowan, J. and R. Tobin, "XML Information Set (Second Cowan, J. and R. Tobin, "XML Information Set (Second
Edition)", World Wide Web Consortium Recommendation REC- Edition)", World Wide Web Consortium Recommendation REC-
xml-infoset-20040204, February 2004, xml-infoset-20040204, February 2004,
<http://www.w3.org/TR/2004/REC-xml-infoset-20040204>. <http://www.w3.org/TR/2004/REC-xml-infoset-20040204>.
10.2. Informative References [W3C.REC-xml-names11-20060816]
Bray, T., Hollander, D., Layman, A., and R. Tobin,
"Namespaces in XML 1.1 (Second Edition)", World Wide Web
Consortium Recommendation REC-xml-names11-20060816, August
2006,
<http://www.w3.org/TR/2006/REC-xml-names11-20060816>.
11.2. Informative References
[I-D.ietf-netconf-restconf] [I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-05 (work in Protocol", draft-ietf-netconf-restconf-07 (work in
progress), June 2015. progress), July 2015.
[ISO.19757-1] [ISO.19757-1]
International Organization for Standardization, "Document International Organization for Standardization, "Document
Schema Definition Languages (DSDL) - Part 1: Overview", Schema Definition Languages (DSDL) - Part 1: Overview",
ISO/IEC 19757-1, November 2004. ISO/IEC 19757-1, November 2004.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>.
Appendix A. Change Log Appendix A. Change Log
RFC Editor: Remove this section upon publication as an RFC. RFC Editor: Remove this section upon publication as an RFC.
A.1. Changes Between Revisions -00 and -01 A.1. Changes Between Revisions -01 and -02
o The "type" statement became mandatory.
o Terminology section was extended.
o The annotation "inactive" defined in the example module was
replaced with "last-modified" that is supposedly less
controversial.
o Introduction now states limitation due to XML attribute
porperties.
o A recommendation was added to define annotations in a module by
themselves.
o Section "Using Annotations" was added.
o An example for "anyxml" was added.
o RFC 6241 was moved to informative references.
A.2. Changes Between Revisions -00 and -01
o Define JSON encoding for annotations attached to 'anydata' nodes. o Define JSON encoding for annotations attached to 'anydata' nodes.
A.2. Changes Between draft-lhotka-netmod-yang-metadata-01 and draft- A.3. Changes Between draft-lhotka-netmod-yang-metadata-01 and draft-
ietf-netmod-yang-metadata-00 ietf-netmod-yang-metadata-00
o References to RFC 6020 were changed to the 6021bis I-D. o References to RFC 6020 were changed to the 6020bis I-D.
o Text about RFC 2119 key words was added to "ietf-yang-metadata" o Text about RFC 2119 key words was added to "ietf-yang-metadata"
module description. module description.
A.3. Changes Between draft-lhotka-netmod-yang-metadata-00 and -01 A.4. Changes Between draft-lhotka-netmod-yang-metadata-00 and -01
o Encoding of annotations for anyxml nodes was changed to be the o Encoding of annotations for anyxml nodes was changed to be the
same as for leafs. This was necessary because anyxml value now same as for leafs. This was necessary because anyxml value now
needn't be an object. needn't be an object.
o It is stated that "md:annotation" statement defines only the o It is stated that "md:annotation" statement defines only the
syntax of an annotation. syntax of an annotation.
o Allowed "if-feature" as a substatement of "md:annotation". o Allowed "if-feature" as a substatement of "md:annotation".
 End of changes. 113 change blocks. 
227 lines changed or deleted 405 lines changed or added

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