| NETMOD Working Group | L. Lhotka |
| Internet-Draft | CZ.NIC |
| Updates: 6110 (if approved) | March 10, 2016 |
| Intended status: Standards Track | |
| Expires: September 11, 2016 |
Defining and Using Metadata with YANG
draft-ietf-netmod-yang-metadata-05
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 11, 2016.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
There is a need to be able to annotate instances of YANG [I-D.ietf-netmod-rfc6020bis] data nodes with metadata. Typical use cases are:
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:
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" (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:
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,
Due to the rules for YANG extensions (see sec. 6.3.1 in [I-D.ietf-netmod-rfc6020bis]), annotation definitions posit relatively weak conformance requirements. The alternative of introducing a new built-in YANG statement for defining annotations was considered, but it was seen as a major change to the language that is inappropriate for YANG 1.1, which was chartered as a maintenance revision. After evaluating real-life usage of metadata annotations, it is conceivable that such a new built-in statement might be added in a future revision of YANG.
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 [RFC2119].
The following terms are defined in [RFC6241]:
The following terms are defined in [I-D.ietf-netmod-rfc6020bis]:
The following terms are defined in [W3C.REC-xml-infoset-20040204]:
The following terms are defined in [W3C.REC-xml-names11-20060816]:
The following terms are defined in [RFC7159]:
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 Table 1.
| Prefix | URI Reference |
|---|---|
| elm | http://example.org/example-last-modified |
| md | urn:ietf:params:xml:ns:yang:ietf-yang-metadata |
| rng | http://relaxng.org/ns/structure/1.0 |
Metadata annotations are defined by YANG extension statement "md:annotation". This YANG language extension is defined in the module "ietf-yang-metadata" (Section 7).
Substatements of "md:annotation" are shown in Table 2. They are all core YANG statements, and the numbers in the second column refer to the corresponding section in [I-D.ietf-netmod-rfc6020bis] where each statement is described.
| substatement | RFC 6020bis section | cardinality |
|---|---|---|
| description | 7.21.3 | 0..1 |
| if-feature | 7.20.2 | 0..n |
| reference | 7.21.4 | 0..1 |
| status | 7.21.2 | 0..1 |
| type | 7.6.3 | 1 |
| units | 7.3.3 | 0..1 |
Using the "type" statement, a type is specified for the annotation value according to the same rules as for YANG "leaf" type.
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.
The semantics and usage rules for an annotation SHOULD be fully specified in "description", "reference" and "units" statements.
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.
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.
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 {
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).";
}
}
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 according to the annotation's definition. That is, an annotation advertised by the server may be attached to an instance of a data node defined in any YANG module that is implemented by the server.
Depending on its semantics, an annotation may have an effect only in certain data trees and/or on instances of specific data nodes types.
A client MUST NOT add a specific annotation to data node instances if the server didn't advertise it.
Due care has to be exercised when introducing annotations in network management systems in order to avoid interoperability problems and software failures caused by a client that does not understand the annotations' semantics. Generally, it is safe for a server to use annotations in the following cases:
XML attributes are a natural choice for encoding metadata in XML instance documents. For JSON [RFC7159], 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 [I-D.ietf-netmod-yang-json].
Metadata annotations are added to XML-encoded instances of YANG data nodes as XML attributes according to these rules:
For example, the "last-modified" annotation defined in Section 3.1 may be encoded as follows:
<foo xmlns:elm="http://example.org/example-last-modified"
elm:last-modified="2015-09-16T10:27:35+02:00">
...
</foo>
The JSON metadata encoding defined in this section has the following properties:
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.
annotation-name = identifier ":" identifier
The name of a metadata annotation (as a member of the metadata object) has the following ABNF syntax [RFC5234], where the production for "identifier" is defined in sec. 13 of [I-D.ietf-netmod-rfc6020bis]
Note that unlike member names of YANG data node instances in JSON 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 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.
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 "@".
"cask": {
"@": {
"example-last-modified:last-modified":
"2015-09-16T10:27:35+02:00"
},
...
}
"seq": [
{
"@": {
"example-last-modified:last-modified":
"2015-09-16T10:27:35+02:00"
},
"name": "one",
...
},
{
"name": "two",
...
}
]
Examples:
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.
"foo:flag": true,
"@foo:flag": {
"example-last-modified:last-modified":
"2015-09-16T10:27:35+02:00"
}
"stuff": [1, null, "three"],
"@stuff": {
"example-last-modified:last-modified":
"2015-09-16T10:27:35+02:00"
}
Examples:
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.
Trailing null values in that array, i.e., those following the last non-null metadata object, MAY be omitted.
"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"
}
]
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:
[RFC6110] defines the standard mapping of YANG data models to Document Schema Definition Languages (DSDL) [ISO.19757-1]. This section specifies the mapping for the extension statement "md:annotation" (Section 7), which enables validation of XML instance documents containing metadata annotations.
md:annotation ARGUMENT {
...
}
<rng:optional>
<rng:attribute name="PREFIX:ARGUMENT">
...
</rng:attribute>
</rng:optional>
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 [RFC6110]), is modified as follows:
For example, the named pattern (item 1), when constructed only for the "last-modified" annotation, will have the following definition:
<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>
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
<rng:element name="foo:bar"> <rng:ref name="__yang_metadata__"/> ... </rng:element>
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.
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".
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).
RFC Editor: Also please replace all occurrences of 'RFC 6020bis' with the actual RFC number that will be assigned to [I-D.ietf-netmod-rfc6020bis].
<CODE BEGINS> file "ietf-yang-metadata@2016-03-10.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: Lou Berger
<mailto:lberger@labn.net>
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) 2016 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).
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 2016-03-10 {
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 or submodule, i.e. it becomes a
new alternative in the ABNF production rule for 'body-stmts'
(sec. 14 in RFC 6020bis).
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>
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).
This document registers a URI in the "IETF XML registry" [RFC3688]. Following the format in RFC 3688, the following registration has been made.
---------------------------------------------------------------------
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.
---------------------------------------------------------------------
This document registers a YANG module in the "YANG Module Names" registry [RFC6020].
---------------------------------------------------------------------
name: ietf-yang-metadata
namespace: urn:ietf:params:xml:ns:yang:ietf-yang-metadata
prefix: md
reference: RFC XXXX
---------------------------------------------------------------------
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.
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, Benoit Claise, Juergen Schoenwaelder, and Kent Watsen for their helpful comments and suggestions.
| [I-D.ietf-netmod-rfc6020bis] | Bjorklund, M., "The YANG 1.1 Data Modeling Language", Internet-Draft draft-ietf-netmod-rfc6020bis-11, February 2016. |
| [I-D.ietf-netmod-yang-json] | Lhotka, L., "JSON Encoding of Data Modeled with YANG", Internet-Draft draft-ietf-netmod-yang-json-09, March 2016. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC3688] | Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004. |
| [RFC5234] | Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008. |
| [RFC6020] | Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010. |
| [RFC6110] | Lhotka, L., "Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content", RFC 6110, DOI 10.17487/RFC6110, February 2011. |
| [RFC7159] | Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014. |
| [W3C.REC-xml-infoset-20040204] | Cowan, J. and R. Tobin, "XML Information Set (Second Edition)", World Wide Web Consortium Recommendation REC-xml-infoset-20040204, February 2004. |
| [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. |
| [I-D.ietf-netconf-restconf] | Bierman, A., Bjorklund, M. and K. Watsen, "RESTCONF Protocol", Internet-Draft draft-ietf-netconf-restconf-09, December 2015. |
| [ISO.19757-1] | International Organization for Standardization, "Document Schema Definition Languages (DSDL) - Part 1: Overview", ISO/IEC 19757-1, November 2004. |
| [RFC6241] | Enns, R., Bjorklund, M., Schoenwaelder, J. and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011. |
RFC Editor: Remove this section upon publication as an RFC.