One document matched: draft-ietf-netmod-yang-metadata-02.xml
<?xml version="1.0"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc docName="draft-ietf-netmod-yang-metadata-02" ipr="trust200902" category="std" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="YANG Metadata">Defining and Using Metadata with YANG</title>
<author fullname="Ladislav Lhotka" initials="L." surname="Lhotka">
<organization>CZ.NIC</organization>
<address>
<email>lhotka@nic.cz</email>
</address>
</author>
<date day="17" month="September" year="2015"/>
<area>ops</area>
<area>Operations and Management</area>
<workgroup>NETMOD Working Group</workgroup>
<abstract>
<t>This document defines a YANG extension statement that allows
for defining metadata annotations in YANG modules. The document
also specifies XML and JSON encoding of annotations and other
rules for annotating instances of YANG data nodes.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction" toc="default">
<t>There is a need to be able to annotate instances of
YANG <xref target="I-D.ietf-netmod-rfc6020bis" pageno="false" format="default"/> data nodes with metadata. Typical
use cases are:
<list style="symbols">
<t>Complementing regular data model information with
instance-specific metadata, comments etc.</t>
<t>Providing information about data rendering in user
interfaces.</t>
<t>Deactivating a subtree in a configuration datastore while
keeping the data in place.</t>
<t>Network management protocols often use metadata annotations
for various purposes in both operation requests and
responses. For example, the <edit-config> operation in
the NETCONF protocol (see section 7.2 of <xref target="RFC6241" pageno="false" format="default"/>) uses annotations in the form of XML
attributes for identifying the location in a configuration
datastore and the type of the operation.</t>
</list></t>
<t>However, metadata annotations could potentially lead to
interoperability problems if they are used in an ad hoc fashion
by different parties and/or without proper documentation. A
sound metadata framework for YANG should therefore satisfy these
requirements:
<list style="numbers">
<t>The set of annotations must be extensible in a
decentralised manner so as to allow for defining new
annotations without running into the risk of collisions with
annotations defined and used by others.</t>
<t>Syntax and semantics of annotations must be documented and
the documentation must be easily accessible.</t>
<t>Clients of network management protocols such as
NETCONF <xref target="RFC6241" pageno="false" format="default"/> or RESTCONF <xref target="I-D.ietf-netconf-restconf" pageno="false" format="default"/> must be able to discover
all annotations supported by a given server and identify each
of them correctly.</t>
<t>Annotations sent by a server should not break clients that
don't support them.</t>
</list></t>
<t>This document proposes a systematic way for defining metadata
annotations. For this purpose, YANG extension statement
"annotation" is defined in the module "ietf-yang-metadata"
(<xref target="ietf-yang-metadata" pageno="false" format="default"/>). Other YANG modules
importing this module can use the "annotation" statement for
defining one or more annotations.</t>
<t>The benefits of defining the metadata annotations in a YANG
module are the following:
<list style="symbols">
<t>Each annotation is bound to a YANG module name, namespace
URI and prefix. This makes its encoding in instance documents
(both XML and JSON) straightforward and consistent with the
encoding of YANG data node instances.</t>
<t>Annotations are indirectly registered through IANA in the
"YANG Module Names" registry <xref target="RFC6020" pageno="false" format="default"/>.</t>
<t>Annotations are included in the data model. YANG compilers
and tools supporting a certain annotation can thus take them
into account and modify their behavior accordingly.</t>
<t>Semantics of an annotation are defined in the "description"
and "reference" statements.</t>
<t>An annotation can be declared as conditional by using the
"if-feature" statement.</t>
<t>Values of annotations are not limited to strings; any YANG
built-in or derived type may be used for them.</t>
</list></t>
<t>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,
<list style="symbols">
<t>annotations are scalar values and cannot be further structured;</t>
<t>annotations cannot be attached to a whole list or leaf-list
instance, only to individual list of leaf-list entries.</t>
</list></t>
</section>
<section anchor="terminology" title="Terminology" toc="default">
<section anchor="keywords" title="Keywords" toc="default">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in <xref target="RFC2119" pageno="false" format="default"/>.</t>
</section>
<section anchor="adopted-terms" title="Terms Defined in Other Documents" toc="default">
<t>The following terms are defined in <xref target="RFC6241" pageno="false" format="default"/>:
<list style="symbols">
<t>capability,</t>
<t>client,</t>
<t>datastore,</t>
<t>message,</t>
<t>protocol operation,</t>
<t>server.</t>
</list></t>
<t>The following terms are defined in <xref target="I-D.ietf-netmod-rfc6020bis" pageno="false" format="default"/>:
<list style="symbols">
<t>action,</t>
<t>anydata,</t>
<t>anyxml,</t>
<t>data type,</t>
<t>container,</t>
<t>data model,</t>
<t>data node,</t>
<t>data tree,</t>
<t>extension,</t>
<t>leaf,</t>
<t>leaf-list,</t>
<t>list,</t>
<t>module,</t>
<t>RPC input and output.</t>
</list></t>
<t>The following terms are defined in <xref target="W3C.REC-xml-infoset-20040204" pageno="false" format="default"/>:
<list style="symbols">
<t>attribute,</t>
<t>document,</t>
<t>element.</t>
</list></t>
<t>The following terms are defined in <xref target="W3C.REC-xml-names11-20060816" pageno="false" format="default"/>:
<list style="symbols">
<t>local name,</t>
<t>namespace name,</t>
<t>prefix,</t>
<t>qualified name.</t>
</list></t>
<t>The following terms are defined in <xref target="RFC7159" pageno="false" format="default"/>:
<list style="symbols">
<t>array,</t>
<t>member,</t>
<t>object,</t>
<t>primitive type.</t>
</list></t>
</section>
<section anchor="ns-pref" title="Namespaces and Prefixes" toc="default">
<t>In the following text, XML element names and YANG extension
statements are always written with explicit namespace prefixes
that are assumed to be bound to URI references as shown in <xref target="tab.ns" pageno="false" format="default"/>.</t>
<texttable anchor="tab.ns" title="Used namespace prefixes and corresponding URI references" suppress-title="false" align="center" style="full">
<ttcol align="left">Prefix</ttcol>
<ttcol align="left">URI Reference</ttcol>
<c>elm</c>
<c>http://example.org/example-last-modified</c>
<c>md</c>
<c>urn:ietf:params:xml:ns:yang:ietf-yang-metadata</c>
<c>rng</c>
<c>http://relaxng.org/ns/structure/1.0</c>
</texttable>
</section>
<section anchor="new-terms" title="Definitions of New Terms" toc="default">
<t><list style="symbols">
<t>annotation: a single item of metadata that is attached to
YANG data node instances.</t>
<t>metadata: additional information that complements a data
tree.</t>
<t>metadata object: an object in JSON encoding that contains
all annotations attached to a given data node instance.</t>
</list></t>
</section>
</section>
<section anchor="annotdef" title="Defining Annotations in YANG" toc="default">
<t>Metadata annotations are defined by YANG extension statement
"md:annotation". This YANG language extension is defined in the
module "ietf-yang-metadata" (<xref target="ietf-yang-metadata" pageno="false" format="default"/>).</t>
<t>Substatements of "md:annotation" are shown in <xref target="tab.annsub" pageno="false" format="default"/>. They are all core YANG statements, and
the numbers in the second column refer to the corresponding
section in <xref target="I-D.ietf-netmod-rfc6020bis" pageno="false" format="default"/> where each
statement is described.</t>
<texttable anchor="tab.annsub" title="Substatements of "md:annotation"." suppress-title="false" align="center" style="full">
<ttcol align="left">substatement</ttcol>
<ttcol align="left">RFC 6020bis section</ttcol>
<ttcol align="left">cardinality</ttcol>
<c>description</c><c>7.21.3</c><c>0..1</c>
<c>if-feature</c><c>7.20.2</c><c>0..n</c>
<c>reference</c><c>7.21.4</c><c>0..1</c>
<c>status</c><c>7.21.2</c><c>0..1</c>
<c>type</c><c>7.6.3</c><c>1</c>
<c>units</c><c>7.3.3</c><c>0..1</c>
</texttable>
<t>Using the "type" statement, a type is specified for the
annotation value according to the same rules as for YANG "leaf"
type.</t>
<t>An annotation can be made conditional by using one or more
"if-feature" statements; the annotation is then supported only
by servers that advertise the corresponding feature.</t>
<t>The semantics and usage rules for an annotation SHOULD be
fully specified in "description", "reference" and "units"
statements.</t>
<t>An annotation MUST NOT change the data tree semantics defined
by YANG. For example, it is illegal to define and use an
annotation that allows for overriding uniqueness of leaf-list
entries.</t>
<t>The "status" statement can be used exactly as for YANG data
nodes.</t>
<t>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.</t>
<section anchor="ex-module" title="Example Definition" toc="default">
<t>The following module defines the "last-modified"
annotation:</t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
module example-last-modified {
namespace "http://example.org/example-last-modified";
prefix "elm";
import ietf-yang-types {
prefix "yang";
}
import ietf-yang-metadata {
prefix "md";
}
md:annotation last-modified {
type yang:date-and-time;
description
"This annotation contains date and time when the
annotated instance was last modified (or created).";
}
}
</artwork>
</figure>
</section>
</section>
<section anchor="usage" title="Using Annotations" toc="default">
<t>By advertising a YANG module in which a metadata annotation
is defined using the "md:annotation" statement, a server
indicates that 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.</t>
<t>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.</t>
<t>A client MUST NOT use an annotation in protocol operations if
the server didn't advertise it.</t>
<t>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:
<list style="symbols">
<t>A client may not not be able to parse or validate protocol
messages containing annotations.</t>
<t>A client may not understand semantics of an annotation set
by the server or other clients.</t>
</list></t>
<t>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:
<list style="symbols">
<t>An annotation is an integral part of a built-in or
negotiated protocol capability.</t>
<t>An annotation contains optional information that is not
critical for protocol operation.</t>
<t>The client explicitly asks the server, e.g., via a
parameter of a protocol operation request, for including an
annotation in the response.</t>
</list></t>
</section>
<section anchor="encoding" title="The Encoding of Annotations" toc="default">
<t>XML attributes are a natural choice for encoding metadata in
XML instance documents. For JSON <xref target="RFC7159" pageno="false" format="default"/>, there
is no generally established method for encoding metadata. This
document thus introduces a special encoding method that is
consistent with the JSON encoding of YANG data node instances as
defined in <xref target="I-D.ietf-netmod-yang-json" pageno="false" format="default"/>.</t>
<section anchor="enc-xml" title="XML Encoding" toc="default">
<t>Metadata annotations are added to XML-encoded instances of
YANG data nodes as XML attributes according to these rules:
<list style="symbols">
<t>The local name of the attribute SHALL be the same as the
name of the annotation specified in the argument of the
corresponding "md:annotation" statement.</t>
<t>The namespace of the attribute SHALL be identified by the
URI that appears as the argument of the "namespace"
statement in the YANG module where the annotation is
defined. It is RECOMMENDED that the prefix specified by the
"prefix" statement in the same module is used in the
qualified name of the attribute.</t>
<t>The attribute value SHALL be encoded in the same way as
the value of a YANG leaf instance having the same type,
see <xref target="I-D.ietf-netmod-rfc6020bis" pageno="false" format="default"/>, sec. 9.</t>
</list></t>
<t>For example, the "last-modified" annotation defined in <xref target="ex-module" pageno="false" format="default"/> may be encoded as follows:</t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
<foo xmlns:elm="http://example.org/example-last-modified"
elm:last-modified="2015-09-16T10:27:35+02:00">
...
</foo></artwork>
</figure>
</section>
<section anchor="enc-json" title="JSON Encoding" toc="default">
<t>The JSON metadata encoding defined in this section has the
following properties:
<list style="numbers">
<t>The encoding of YANG data node instances as defined in
<xref target="I-D.ietf-netmod-yang-json" pageno="false" format="default"/> does not change.</t>
<t>Namespaces of metadata annotations are encoded in the same
way as namespaces of YANG data node instances, see <xref target="I-D.ietf-netmod-yang-json" pageno="false" format="default"/>.</t>
</list></t>
<section anchor="met-obj" title="Metadata Object and Annotations" toc="default">
<t>All metadata annotations assigned to a YANG data node
instance are encoded as members (name/value pairs) of a
single JSON object, 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 following
subsections.</t>
<t>The name of a metadata annotation (as a member of the
metadata object) has the following ABNF syntax <xref target="RFC5234" pageno="false" format="default"/>, where the production for "identifier" is
defined in sec. 13 of <xref target="I-D.ietf-netmod-rfc6020bis" pageno="false" format="default"/>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">annotation-name = identifier ":" identifier</artwork>
</figure>
where the left identifier is the name of the YANG module in
which the annotation is defined, and the identifier on the
right is the name of the annotation specified in the
argument of the corresponding "md:annotation" statement.</t>
<t>Note that unlike member names of YANG data node instances
in JSON encoding (see sec. 4 in <xref target="I-D.ietf-netmod-yang-json" pageno="false" format="default"/>), for annotations the
explicit namespace identifier (module name) must always be
present.</t>
<t>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 annotation, see <xref target="I-D.ietf-netmod-yang-json" pageno="false" format="default"/>, sec. 6.</t>
</section>
<section anchor="enc-cal" title="Adding Annotations to Anydata, Container and List Entries" toc="default">
<t>For a data node instance that is encoded as a JSON object
(i.e., a container, list entry, or anydata node), the
metadata object is added as a new member of that object with
the name "@".</t>
<t>Examples:
<list style="symbols">
<t>"cask" is a container or anydata node:
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
"cask": {
"@": {
"example-last-modified:last-modified":
"2015-09-16T10:27:35+02:00"
},
...
}</artwork>
</figure></t>
<t>"seq" is a list whose key is "name", annotation
"last-modified" is added only to the first entry:
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
"seq": [
{
"@": {
"example-last-modified:last-modified":
"2015-09-16T10:27:35+02:00"
},
"name": "one",
...
},
{
"name": "two",
...
}
]</artwork>
</figure></t>
</list></t>
</section>
<section anchor="enc-l" title="Adding Annotations to Anyxml and Leaf Instances" toc="default">
<t>For an anyxml or leaf instance, the metadata object is
added as a sibling name/value pair whose name is the symbol
"@" concatenated 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.</t>
<t>Examples:
<list style="symbols">
<t>"flag" is a leaf node of the "boolean" type defined in
module "foo", and we assume the namespace name has to be
expressed in its JSON encoding:
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
"foo:flag": true,
"@foo:flag": {
"example-last-modified:last-modified":
"2015-09-16T10:27:35+02:00"
}</artwork>
</figure></t>
<t>"stuff" is an anyxml node:
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
"stuff": [1, null, "three"],
"@stuff": {
"example-last-modified:last-modified":
"2015-09-16T10:27:35+02:00"
}</artwork>
</figure></t>
</list></t>
</section>
<section anchor="enc-ll" title="Adding Annotations to Leaf-list Entries" toc="default">
<t>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 more entries by adding a name/array pair
as a sibling of the leaf-list entry, where the name is
symbol "@" concatenated with the name of the leaf-list that
is being annotated, and the value is a JSON array whose i-th
element is the metadata object with annotations assigned to
the i-th entry of the leaf-list entry, or null if the i-th
entry has no annotations.</t>
<t>Trailing null values in that array, i.e., those following
the last non-null metadata object, MAY be omitted.</t>
<t>For example, in the following leaf-list instance with
four entries, the "last-modified" annotation is added to the
second and third entry in the following way:
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
"bibliomod:folio": [6, 3, 7, 8],
"@bibliomod:folio": [
null,
{ "example-last-modified:last-modified":
"2015-06-18T17:01:14+02:00"
},
{ "example-last-modified:last-modified":
"2015-09-16T10:27:35+02:00"
}
]</artwork>
</figure></t>
</section>
</section>
</section>
<section anchor="dsdl" title="Representing Annotations in DSDL Schemas" toc="default">
<t><xref target="RFC6110" pageno="false" format="default"/> defines the standard mapping of YANG
data models to Document Schema Definition Languages (DSDL) <xref target="ISO.19757-1" pageno="false" format="default"/>. This section specifies the mapping for
the extension statement "md:annotation" (<xref target="ietf-yang-metadata" pageno="false" format="default"/>), which enables validation of XML
instance documents containing metadata annotations.</t>
<t>The first step of the DSDL mapping procedure, i.e., the
transformation of the YANG data model to the hybrid schema (see
sec. 6 in <xref target="RFC6110" pageno="false" format="default"/>), is modified as follows:
<list style="numbers">
<t anchor="it.npdef">If the data model contains at least one
"md:annotation" statement, then a RELAX NG named pattern
definition MUST be added as a child of the root
<rng:grammar> element in the hybrid schema. It is
RECOMMENDED to use the name "__yang_metadata__" for this named
pattern.</t> <t anchor="it.npref">A reference to the named
pattern described in item <xref target="it.npdef" format="counter" pageno="false"/> MUST be included as a child of every
<rng:element> pattern that corresponds to an anydata,
container, leaf, leaf-list or list data node.</t>
<t>Every metadata annotation definition in the form
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
md:annotation ARGUMENT {
...
}</artwork>
</figure>
is mapped to the following RELAX NG pattern:
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
<rng:optional>
<rng:attribute name="PREFIX:ARGUMENT">
...
</rng:attribute>
</rng:optional></artwork>
</figure>
where PREFIX is the prefix bound to the namespace URI of the
YANG module that contains the "md:annotation" statement. The
above pattern SHALL be inserted as a child of the named
pattern described in item <xref target="it.npdef" format="counter" pageno="false"/>.</t>
<t>Substatements of "md:annotation" SHALL be mapped to
children of the "rng:attribute" pattern exactly as described
in sec. 10 of <xref target="RFC6110" pageno="false" format="default"/>.</t>
</list></t>
<t>For example, the named pattern (item <xref target="it.npdef" format="counter" pageno="false"/>), when constructed only for the
"last-modified" annotation, will have the following
definition:</t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
<rng:define name="__yang_metadata__">
<rng:optional>
<rng:attribute name="elm:last-modified">
<rng:ref name="ietf-yang-types__date-and-time"/>
</rng:attribute>
</rng:optional>
</rng:define></artwork>
</figure>
<t>Every "rng:element" pattern that corresponds to an anydata,
container, leaf, list or leaf-list data node will then contain a
reference to the above named pattern, for example</t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
<rng:element name="foo:bar">
<rng:ref name="__yang_metadata__"/>
...
</rng:element></artwork>
</figure>
<t>Note that it is not necessary to use such a reference for
"rng:element" patterns corresponding to anyxml data nodes
because they already permit any XML attributes to be attached to
their instances.</t>
<t>The second step of the DSDL mapping procedure, i.e., the
transformation of the hybrid schema to RELAX NG, Schematron and
DSRL schemas, is unaffected by the inclusion of
"md:annotation".</t>
</section>
<section anchor="ietf-yang-metadata" title="Metadata YANG Module" toc="default">
<t>RFC Editor: In this section, replace all occurrences of 'XXXX'
with the actual RFC number and all occurrences of the revision date
below with the date of RFC publication (and remove this note).</t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
<CODE BEGINS> file "ietf-yang-metadata@2015-09-17.yang"
module ietf-yang-metadata {
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-metadata";
prefix "md";
organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
WG Chair: Thomas Nadeau
<mailto:tnadeau@lucidvision.com>
WG Chair: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de>
WG Chair: Kent Watsen
<mailto:kwatsen@juniper.net>
Editor: Ladislav Lhotka
<mailto:lhotka@nic.cz>";
description
"This YANG module defines an extension statement that allows for
defining metadata annotations.
Copyright (c) 2015 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and
'OPTIONAL' in the module text are to be interpreted as described
in RFC 2119 (http://tools.ietf.org/html/rfc2119).
This version of this YANG module is part of RFC XXXX
(http://tools.ietf.org/html/rfcXXXX); see the RFC itself for
full legal notices.";
revision 2015-09-17 {
description
"Initial revision.";
reference
"RFC XXXX: Defining and Using Metadata with YANG";
}
extension annotation {
argument name;
description
"This extension allows for defining metadata annotations in
YANG modules. The 'md:annotation' statement can appear only at
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
the namespace and other context from the YANG module in which
it is defined.
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
are optional): 'description', 'if-feature', 'reference',
'status', and 'units'.
A server announces 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 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
RFC XXXX.";
}
}
<CODE ENDS></artwork>
</figure>
</section>
<section anchor="iana" title="IANA Considerations" toc="default">
<t>RFC Editor: In this section, replace all occurrences of 'XXXX'
with the actual RFC number and all occurrences of the revision date
below with the date of RFC publication (and remove this note).</t>
<t>This document registers a URI in the "IETF XML registry"
<xref target="RFC3688" pageno="false" format="default"/>. Following the format in RFC 3688, the
following registration has been made.</t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
---------------------------------------------------------------------
URI: urn:ietf:params:xml:ns:yang:ietf-yang-metadata
Registrant Contact: The NETMOD WG of the IETF.
XML: N/A, the requested URI is an XML namespace.
---------------------------------------------------------------------
</artwork>
</figure>
<t>This document registers a YANG module in the "YANG Module
Names" registry <xref target="RFC6020" pageno="false" format="default"/>.</t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
---------------------------------------------------------------------
name: ietf-yang-metadata
namespace: urn:ietf:params:xml:ns:yang:ietf-yang-metadata
prefix: md
reference: RFC XXXX
---------------------------------------------------------------------
</artwork>
</figure>
</section>
<section anchor="security" title="Security Considerations" toc="default">
<t>This document introduces a mechanism for defining metadata
annotations in YANG modules and attaching them to instances of
YANG data nodes. By itself, this mechanism represents no
security threat. Security implications of a particular
annotation defined using this mechanism MUST be duly
considered and documented in the the annotation's
definition.</t>
<t>An annotation SHOULD be subject to the same or stricter
access control rules as the data node instance to which the
annotation is attached.</t>
</section>
<section anchor="sec.ack" title="Acknowledgments" toc="default">
<t>The author wishes to thank Andy Bierman, Martin Bjorklund,
Benoit Claise, Juergen Schoenwaelder, and Kent Watsen for their
helpful comments and suggestions.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="I-D.ietf-netmod-rfc6020bis">
<front>
<title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
<author initials="M" surname="Bjorklund" fullname="Martin Bjorklund">
<organization/>
</author>
<date month="July" day="6" year="2015"/>
<abstract><t>YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. This document obsoletes RFC 6020.</t></abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-netmod-rfc6020bis-06"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-netmod-rfc6020bis-06.txt"/>
</reference>
<reference anchor="I-D.ietf-netmod-yang-json">
<front>
<title>JSON Encoding of Data Modeled with YANG</title>
<author initials="L" surname="Lhotka" fullname="Ladislav Lhotka">
<organization/>
</author>
<date month="September" day="10" year="2015"/>
<abstract><t>This document defines encoding rules for representing configuration, state data, RPC operation or action input and output parameters, and notifications defined using YANG as JavaScript Object Notation (JSON) text.</t></abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-netmod-yang-json-05"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-json-05.txt"/>
</reference>
<reference anchor="RFC2119" target="http://www.rfc-editor.org/info/rfc2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="S. Bradner"><organization/></author>
<date year="1997" month="March"/>
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC3688" target="http://www.rfc-editor.org/info/rfc3688">
<front>
<title>The IETF XML Registry</title>
<author initials="M." surname="Mealling" fullname="M. Mealling"><organization/></author>
<date year="2004" month="January"/>
<abstract><t>This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.</t></abstract>
</front>
<seriesInfo name="BCP" value="81"/>
<seriesInfo name="RFC" value="3688"/>
<seriesInfo name="DOI" value="10.17487/RFC3688"/>
</reference>
<reference anchor="RFC5234" target="http://www.rfc-editor.org/info/rfc5234">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author initials="D." surname="Crocker" fullname="D. Crocker" role="editor"><organization/></author>
<author initials="P." surname="Overell" fullname="P. Overell"><organization/></author>
<date year="2008" month="January"/>
<abstract><t>Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name="STD" value="68"/>
<seriesInfo name="RFC" value="5234"/>
<seriesInfo name="DOI" value="10.17487/RFC5234"/>
</reference>
<reference anchor="RFC6020" target="http://www.rfc-editor.org/info/rfc6020">
<front>
<title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor"><organization/></author>
<date year="2010" month="October"/>
<abstract><t>YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name="RFC" value="6020"/>
<seriesInfo name="DOI" value="10.17487/RFC6020"/>
</reference>
<reference anchor="RFC6110" target="http://www.rfc-editor.org/info/rfc6110">
<front>
<title>Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content</title>
<author initials="L." surname="Lhotka" fullname="L. Lhotka" role="editor"><organization/></author>
<date year="2011" month="February"/>
<abstract><t>This document specifies the mapping rules for translating YANG data models into Document Schema Definition Languages (DSDL), a coordinated set of XML schema languages standardized as ISO/IEC 19757. The following DSDL schema languages are addressed by the mapping: Regular Language for XML Next Generation (RELAX NG), Schematron, and Schematron and Document Schema Renaming Language (DSRL). The mapping takes one or more YANG modules and produces a set of DSDL schemas for a selected target document type -- datastore content, Network Configuration Protocol (NETCONF) messages, etc. Procedures for schema-based validation of such documents are also discussed. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name="RFC" value="6110"/>
<seriesInfo name="DOI" value="10.17487/RFC6110"/>
</reference>
<reference anchor="RFC7159" target="http://www.rfc-editor.org/info/rfc7159">
<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
<author initials="T." surname="Bray" fullname="T. Bray" role="editor"><organization/></author>
<date year="2014" month="March"/>
<abstract><t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</t><t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t></abstract>
</front>
<seriesInfo name="RFC" value="7159"/>
<seriesInfo name="DOI" value="10.17487/RFC7159"/>
</reference>
<reference anchor="W3C.REC-xml-infoset-20040204" target="http://www.w3.org/TR/2004/REC-xml-infoset-20040204">
<front>
<title>XML Information Set (Second Edition)</title>
<author initials="J." surname="Cowan" fullname="John Cowan">
<organization/>
</author>
<author initials="R." surname="Tobin" fullname="Richard Tobin">
<organization/>
</author>
<date month="February" day="4" year="2004"/>
</front>
<seriesInfo name="World Wide Web Consortium Recommendation" value="REC-xml-infoset-20040204"/>
<format type="HTML" target="http://www.w3.org/TR/2004/REC-xml-infoset-20040204"/>
</reference>
<reference anchor="W3C.REC-xml-names11-20060816" target="http://www.w3.org/TR/2006/REC-xml-names11-20060816">
<front>
<title>Namespaces in XML 1.1 (Second Edition)</title>
<author initials="T." surname="Bray" fullname="Tim Bray">
<organization/>
</author>
<author initials="D." surname="Hollander" fullname="Dave Hollander">
<organization/>
</author>
<author initials="A." surname="Layman" fullname="Andrew Layman">
<organization/>
</author>
<author initials="R." surname="Tobin" fullname="Richard Tobin">
<organization/>
</author>
<date month="August" day="16" year="2006"/>
</front>
<seriesInfo name="World Wide Web Consortium Recommendation" value="REC-xml-names11-20060816"/>
<format type="HTML" target="http://www.w3.org/TR/2006/REC-xml-names11-20060816"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="ISO.19757-1">
<front>
<title>
Document Schema Definition Languages (DSDL) - Part 1: Overview
</title>
<author>
<organization>International Organization for Standardization</organization>
</author>
<date day="14" month="November" year="2004"/>
</front>
<seriesInfo name="ISO/IEC" value="19757-1"/>
<format type="PDF" target="http://www.dsdl.org/0567.pdf"/>
</reference>
<reference anchor="I-D.ietf-netconf-restconf">
<front>
<title>RESTCONF Protocol</title>
<author initials="A" surname="Bierman" fullname="Andy Bierman">
<organization/>
</author>
<author initials="M" surname="Bjorklund" fullname="Martin Bjorklund">
<organization/>
</author>
<author initials="K" surname="Watsen" fullname="Kent Watsen">
<organization/>
</author>
<date month="July" day="6" year="2015"/>
<abstract><t>This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastores defined in NETCONF.</t></abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-netconf-restconf-07"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-netconf-restconf-07.txt"/>
</reference>
<reference anchor="RFC6241" target="http://www.rfc-editor.org/info/rfc6241">
<front>
<title>Network Configuration Protocol (NETCONF)</title>
<author initials="R." surname="Enns" fullname="R. Enns" role="editor"><organization/></author>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor"><organization/></author>
<author initials="J." surname="Schoenwaelder" fullname="J. Schoenwaelder" role="editor"><organization/></author>
<author initials="A." surname="Bierman" fullname="A. Bierman" role="editor"><organization/></author>
<date year="2011" month="June"/>
<abstract><t>The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name="RFC" value="6241"/>
<seriesInfo name="DOI" value="10.17487/RFC6241"/>
</reference>
</references>
<section title="Change Log" toc="default">
<t>RFC Editor: Remove this section upon publication as an RFC.</t>
<section title="Changes Between Revisions -01 and -02" toc="default">
<t>
<list style="symbols">
<t>The "type" statement became mandatory.</t>
<t>Terminology section was extended.</t>
<t>The annotation "inactive" defined in the
example module was replaced with "last-modified"
that is supposedly less controversial.</t>
<t>Introduction now states limitation due to XML attribute
porperties.</t>
<t>A recommendation was added to define annotations in a
module by themselves.</t>
<t>Section "Using Annotations" was added.</t>
<t>An example for "anyxml" was added.</t>
<t>RFC 6241 was moved to informative references.</t>
</list>
</t>
</section>
<section title="Changes Between Revisions -00 and -01" toc="default">
<t>
<list style="symbols">
<t>Define JSON encoding for annotations attached to 'anydata' nodes.</t>
</list>
</t>
</section>
<section title="Changes Between draft-lhotka-netmod-yang-metadata-01 and draft-ietf-netmod-yang-metadata-00" toc="default">
<t>
<list style="symbols">
<t>References to RFC 6020 were changed to the 6020bis
I-D.</t>
<t>Text about RFC 2119 key words was added to
"ietf-yang-metadata" module description.</t>
</list>
</t>
</section>
<section title="Changes Between draft-lhotka-netmod-yang-metadata-00 and -01" toc="default">
<t>
<list style="symbols">
<t>Encoding of annotations for anyxml nodes was changed to
be the same as for leafs. This was necessary because
anyxml value now needn't be an object.</t>
<t>It is stated that "md:annotation" statement defines
only the syntax of an annotation.</t>
<t>Allowed "if-feature" as a substatement of
"md:annotation".</t>
</list>
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:34:58 |