draft-ietf-netmod-yang-metadata-07.txt		rfc7952.txt
	NETMOD Working Group L. Lhotka		Internet Engineering Task Force (IETF) L. Lhotka
	Internet-Draft CZ.NIC		Request for Comments: 7952 CZ.NIC
	Updates: 6110 (if approved) March 21, 2016		Updates: 6110 August 2016
	Intended status: Standards Track		Category: Standards Track
	Expires: September 22, 2016		ISSN: 2070-1721
	Defining and Using Metadata with YANG		Defining and Using Metadata with YANG
	draft-ietf-netmod-yang-metadata-07
	Abstract		Abstract
	This document defines a YANG extension statement that allows for		This document defines a YANG extension that allows for defining
	defining metadata annotations in YANG modules. The document also		metadata annotations in YANG modules. The document also specifies
	specifies XML and JSON encoding of annotations and other rules for		XML and JSON encoding of annotations and other rules for annotating
	annotating instances of YANG data nodes.		instances of YANG data nodes.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	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		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on September 22, 2016.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			http://www.rfc-editor.org/info/rfc7952.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 5		2.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.2. Terms Defined in Other Documents . . . . . . . . . . . . 5		2.2. Terms Defined in Other Documents . . . . . . . . . . . . 5
	2.3. Namespaces and Prefixes . . . . . . . . . . . . . . . . . 6		2.3. Namespaces and Prefixes . . . . . . . . . . . . . . . . . 7
	2.4. Definitions of New Terms . . . . . . . . . . . . . . . . 7		2.4. Definitions of New Terms . . . . . . . . . . . . . . . . 7
	3. Defining Annotations in YANG . . . . . . . . . . . . . . . . 7		3. Defining Annotations in YANG . . . . . . . . . . . . . . . . 8
	3.1. Example Definition . . . . . . . . . . . . . . . . . . . 8		3.1. Example Definition . . . . . . . . . . . . . . . . . . . 9
	4. Using Annotations . . . . . . . . . . . . . . . . . . . . . . 8		4. Using Annotations . . . . . . . . . . . . . . . . . . . . . . 9
	5. The Encoding of Annotations . . . . . . . . . . . . . . . . . 9		5. The Encoding of Annotations . . . . . . . . . . . . . . . . . 10
	5.1. XML Encoding . . . . . . . . . . . . . . . . . . . . . . 9		5.1. XML Encoding . . . . . . . . . . . . . . . . . . . . . . 10
	5.2. JSON Encoding . . . . . . . . . . . . . . . . . . . . . . 10		5.2. JSON Encoding . . . . . . . . . . . . . . . . . . . . . . 11
	5.2.1. Metadata Object and Annotations . . . . . . . . . . . 10		5.2.1. Metadata Object and Annotations . . . . . . . . . . . 11
	5.2.2. Adding Annotations to Anydata, Container and List		5.2.2. Adding Annotations to anydata, container, and list
	Entries . . . . . . . . . . . . . . . . . . . . . . . 11		Entries . . . . . . . . . . . . . . . . . . . . . . . 12
	5.2.3. Adding Annotations to Anyxml and Leaf Instances . . . 11		5.2.3. Adding Annotations to anyxml and leaf Instances . . . 12
	5.2.4. Adding Annotations to Leaf-list Entries . . . . . . . 12		5.2.4. Adding Annotations to leaf-list Entries . . . . . . . 13
	6. Representing Annotations in DSDL Schemas . . . . . . . . . . 13		6. Representing Annotations in DSDL Schemas . . . . . . . . . . 14
	7. Metadata YANG Module . . . . . . . . . . . . . . . . . . . . 14		7. Metadata YANG Module . . . . . . . . . . . . . . . . . . . . 16
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 17		9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		10.1. Normative References . . . . . . . . . . . . . . . . . . 19
	11.1. Normative References . . . . . . . . . . . . . . . . . . 17		10.2. Informative References . . . . . . . . . . . . . . . . . 20
	11.2. Informative References . . . . . . . . . . . . . . . . . 18		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
	Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
	A.1. Changes Between Revisions -06 and -07 . . . . . . . . . . 19
	A.2. Changes Between Revisions -05 and -06 . . . . . . . . . . 19
	A.3. Changes Between Revisions -04 and -05 . . . . . . . . . . 19
	A.4. Changes Between Revisions -03 and -04 . . . . . . . . . . 19
	A.5. Changes Between Revisions -02 and -03 . . . . . . . . . . 19
	A.6. Changes Between Revisions -01 and -02 . . . . . . . . . . 19
	A.7. Changes Between Revisions -00 and -01 . . . . . . . . . . 20
	A.8. Changes Between draft-lhotka-netmod-yang-metadata-01 and
	draft-ietf-netmod-yang-metadata-00 . . . . . . . . . . . 20
	A.9. Changes Between draft-lhotka-netmod-yang-metadata-00 and
	-01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	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 [RFC7950]
	YANG [I-D.ietf-netmod-rfc6020bis] data nodes with metadata. Typical		data nodes with metadata. Typical use cases are as follows:
	use cases are:
	o Complementing regular data model information with instance-		o Complementing regular data model information with
	specific metadata, comments etc.		instance-specific metadata, comments, etc.
	o Providing information about data rendering in user interfaces.		o Providing information about the rendering of data 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 Network management protocols often use metadata annotations for		o Network management protocols often use metadata annotations for
	various purposes in both operation requests and responses. For		various purposes in both operation requests and responses. For
	example, the <edit-config> operation in the NETCONF protocol (see		example, the <edit-config> operation in the Network Configuration
	section 7.2 of [RFC6241]) uses annotations in the form of XML		Protocol (NETCONF) (see Section 7.2 of [RFC6241]) uses annotations
	attributes for identifying the location in a configuration		in the form of XML attributes for identifying the location in a
	datastore and the type of the operation.		configuration datastore and the 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 parties 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 decentralised		1. The set of annotations must be extensible in a decentralized
	manner so as to allow for defining new annotations without		manner so as to allow for defining new annotations without
	running into the risk of collisions with annotations defined and		running the risk of collisions with annotations defined and used
	used by others.		by others.
	2. Syntax and semantics of annotations must be documented and the		2. The syntax and semantics of annotations must be documented, and
	documentation must be easily accessible.		the 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 discover		or RESTCONF [RESTCONF] must be able to discover all annotations
	all annotations supported by a given server and identify each of		supported by a given server and identify each of them correctly.
	them correctly.
	4. Annotations sent by a server should not break clients that don't		4. Annotations sent by a server should not break clients that don't
	support them.		support them.
	This document proposes a systematic way for defining metadata		This document proposes a systematic way to define metadata
	annotations. For this purpose, YANG extension statement "annotation"		annotations. For this purpose, the YANG extension "annotation" is
	is defined in the module "ietf-yang-metadata" (Section 7). Other		defined in the module "ietf-yang-metadata" (Section 7). Other YANG
	YANG modules importing this module can use the "annotation" statement		modules importing this module can use the "annotation" statement for
	for defining one or more annotations.		defining one or more annotations.
	The benefits of defining the metadata annotations in a YANG module		The benefits of defining the metadata annotations in a YANG module
	are the following:		are the following:
	o Each annotation is bound to a YANG module name and namespace URI.		o Each annotation is bound to a YANG module name and namespace URI.
	This makes its encoding in instance documents (both XML and JSON)		This makes its encoding in instance documents (both XML and JSON)
	straightforward and consistent with the encoding of YANG data node		straightforward and consistent with the encoding of YANG data node
	instances.		instances.
	o Annotations defined in IETF standard-track documents are		o Annotations defined in IETF Standards Track documents are
	indirectly registered through IANA in the "YANG Module Names"		indirectly registered through IANA in the "YANG Module Names"
	registry [RFC6020].		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 behavior accordingly.		account and modify their behavior accordingly.
	o Semantics of an annotation are defined in the "description" and		o The semantics of an annotation are defined in the "description"
	"reference" statements.		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
	feature" statement.		"if-feature" statement.
	o The type of each annotation is explicitly specified; any YANG		o The type of each annotation is explicitly specified; any YANG
	built-in or derived type that is available for leaf or leaf-list		built-in or derived type that is available for leaf or leaf-list
	data nodes may be specified for annotations as well.		data nodes may be specified for annotations as well.
	In the XML encoding, XML attributes are a natural instrument for		In the XML encoding, XML attributes are a natural instrument for
	attaching annotations to data node instances. This document		attaching annotations to data node instances. This document
	deliberately adopts some restrictions in order to remain compatible		deliberately adopts some restrictions in order to remain compatible
	with the XML encoding of YANG data node instances and limitations of		with the XML encoding of YANG data node instances and limitations of
	XML attributes. Specifically,		XML attributes. Specifically,
	o annotations can only be scalar values;		o annotations can only be scalar values.
	o annotations cannot be attached to a whole list or leaf-list		o annotations cannot be attached to a whole list or leaf-list
	instance, only to individual list or leaf-list entries.		instance, only to individual list or leaf-list entries.
	Due to the rules for YANG extensions (see sec. 6.3.1 in		Due to the rules for YANG extensions (see Section 6.3.1 in
	[I-D.ietf-netmod-rfc6020bis]), annotation definitions posit		[RFC7950]), annotation definitions posit relatively weak conformance
	relatively weak conformance requirements. The alternative of		requirements. The alternative of introducing a new built-in YANG
	introducing a new built-in YANG statement for defining annotations		statement for defining annotations was considered, but it was seen as
	was considered, but it was seen as a major change to the language		a major change to the language that is inappropriate for YANG 1.1,
	that is inappropriate for YANG 1.1, which was chartered as a		which was chartered as a maintenance revision. After evaluating
	maintenance revision. After evaluating real-life usage of metadata		real-life usage of metadata annotations, it is conceivable that such
	annotations, it is conceivable that such a new built-in statement		a new built-in statement might be added in a future revision of YANG.
	might be added in a future revision of YANG.
	2. Terminology		2. Terminology
	2.1. Keywords
			2.1. Key Words
	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		2.2. Terms Defined in Other Documents
	The following terms are defined in [RFC6241]:		The following terms are defined in [RFC6241]:
	o capability,		o capability
	o client,		o client
	o datastore,		o datastore
	o message,		o message
	o protocol 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 [RFC7950]:
	o action,		o action
	o anydata,		o anydata
	o anyxml,		o anyxml
	o built-in type,		o built-in type
	o container,		o container
	o data model,		o data model
	o data node,		o data node
	o data tree,		o data tree
	o derived type,		o derived type
	o extension,		o extension
	o leaf,		o leaf
			o leaf-list
	o leaf-list,		o list
	o list,
	o module,		o module
	o RPC input and output.		o Remote Procedure Call (RPC) input and output
	The following terms are defined in [W3C.REC-xml-infoset-20040204]:		The following terms are defined in [XML-INFOSET]:
	o attribute,		o attribute
	o document,		o document
	o element.		o element
	The following terms are defined in [W3C.REC-xml-names11-20060816]:		The following terms are defined in [XML-NAMES]:
	o local name,		o local name
	o namespace name,		o namespace name
	o prefix,		o prefix
	o qualified name.		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		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 |
	+--------+------------------------------------------------+		+--------+------------------------------------------------+
	| elm | http://example.org/example-last-modified |		| 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 |
	| rng | http://relaxng.org/ns/structure/1.0 |		| 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		2.4. Definitions of New Terms
	o annotation: a single item of metadata that is attached to YANG		o annotation: a single item of metadata that is attached to YANG
	data node instances.		data node instances.
	o metadata: additional information that complements a data tree.		o metadata: additional information that complements a data tree.
	o metadata object: an object in JSON encoding that contains all		o metadata object: an object in JSON encoding that contains all
	annotations attached to a given data node instance.		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 the YANG extension
	"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 7).		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 section in [I-D.ietf-netmod-rfc6020bis] where each		the corresponding section in [RFC7950] where each statement is
	statement is described.		described.
	+--------------+---------------------+-------------+		+--------------+---------------------+-------------+
	| substatement | RFC 6020bis section | cardinality |		| substatement | section in RFC 7950 | cardinality |
	+--------------+---------------------+-------------+		+--------------+---------------------+-------------+
	| description | 7.21.3 | 0..1 |		| description | 7.21.3 | 0..1 |
	| if-feature | 7.20.2 | 0..n |		| if-feature | 7.20.2 | 0..n |
	| reference | 7.21.4 | 0..1 |		| reference | 7.21.4 | 0..1 |
	| status | 7.21.2 | 0..1 |		| status | 7.21.2 | 0..1 |
	| type | 7.6.3 | 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"
	An annotation carries a single value. The type substatement, which		An annotation carries a single value. The "type" substatement, which
	MUST be present, takes as an argument the name of an existing built-		MUST be present, takes as an argument the name of an existing
	in or derived type, and the value of the annotation MUST match this		built-in or derived type, and the value of the annotation MUST match
	type. See Section 7.4 of [I-D.ietf-netmod-rfc6020bis] for details.		this type. See Section 7.4 of [RFC7950] for details.
	An annotation can be made conditional by using one or more "if-		An annotation can be made conditional by using one or more
	feature" statements; the annotation is then supported only by servers		"if-feature" statements; the annotation is then supported only by
	that advertise the corresponding feature.		servers that advertise the corresponding feature.
	The semantics and usage rules for an annotation SHOULD be fully		The semantics and usage rules for an annotation SHOULD be fully
	specified in "description", "reference" and "units" statements.		specified in "description", "reference", and "units" statements.
	An annotation MUST NOT change the data tree semantics defined by		An annotation MUST NOT change the data tree semantics defined by
	YANG. For example, it is illegal to define and use an annotation		YANG. For example, it is illegal to define and use an annotation
	that allows for overriding uniqueness of leaf-list entries.		that allows for overriding uniqueness of leaf-list entries.
	The "status" statement can be used exactly as for YANG data nodes.		The "status" statement can be used exactly as it is used for YANG
			data nodes.
	A YANG module containing one or more "md:annotation" extension		A YANG module containing one or more "md:annotation" statements
	statements SHOULD NOT be used for defining data nodes or groupings.		SHOULD NOT be used for defining data nodes or groupings. Also,
	Also, derived types, identities and features SHOULD NOT be defined in		derived types, identities, and features SHOULD NOT be defined in such
	such a module unless they are used by the definitions of annotations		a module unless they are used by the definitions of annotations in
	in that module.		that module.
	3.1. Example Definition		3.1. Example Definition
	The following module defines the "last-modified" annotation:		The following module defines the "last-modified" annotation:
	module example-last-modified {		module example-last-modified {
	namespace "http://example.org/example-last-modified";		namespace "http://example.org/example-last-modified";
	prefix "elm";		prefix "elm";
	import ietf-yang-types {		import ietf-yang-types {
	prefix "yang";		prefix "yang";
	}		}
	import ietf-yang-metadata {		import ietf-yang-metadata {
	prefix "md";		prefix "md";
	}		}
	md:annotation last-modified {		md:annotation last-modified {
	type yang:date-and-time;		type yang:date-and-time;
	description		description
	"This annotation contains date and time when the		"This annotation contains the date and time when the
	annotated instance was last modified (or created).";		annotated instance was last modified (or created).";
	}		}
	}		}
	4. Using Annotations		4. Using Annotations
	By advertising a YANG module in which a metadata annotation is		By advertising a YANG module in which a metadata annotation is
	defined using the "md:annotation" statement, a server indicates that		defined using the "md:annotation" statement, a server indicates that
	it is prepared to handle that annotation according to the		it is prepared to handle that annotation according to the
	annotation's definition. That is, an annotation advertised by 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		server may be attached to an instance of a data node defined in any
	YANG module that is implemented by the server.		YANG module that is implemented by the server.
	Depending on its semantics, an annotation may have an effect only in		Depending on its semantics, an annotation may have an effect only in
	certain data trees and/or on instances of specific data nodes types.		certain data trees and/or on instances of specific types of data
			nodes.
	A client MUST NOT add a specific annotation to data node instances if		A client MUST NOT add a specific annotation to data node instances if
	the server didn't advertise it.		the server didn't advertise it.
	Due care has to be exercised when introducing annotations in network		Due care has to be exercised when introducing annotations in network
	management systems in order to avoid interoperability problems and		management systems in order to avoid interoperability problems and
	software failures caused by a client that does not understand the		software failures caused by a client that does not understand the
	annotations' semantics. Generally, it is safe for a server to use		annotations' semantics. Generally, it is safe for a server to use
	annotations in the following cases:		annotations in the following cases:
	o An annotation is an integral part of a built-in or negotiated		o An annotation is an integral part of a built-in or negotiated
	protocol capability.		protocol capability.
	o An annotation contains auxiliary information that is not critical		o An annotation contains auxiliary information that is not critical
	for protocol operation.		for protocol operation.
	o The client explicitly asks the server, e.g., via a parameter of a		o The client explicitly asks the server, e.g., via a parameter of a
	protocol operation request, for including an annotation in the		protocol operation request, to include an annotation in the
	response.		response.
	5. The Encoding of Annotations		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 [RFC7951].
	in [I-D.ietf-netmod-yang-json].
	5.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.		be 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 Section 9 of
	see [I-D.ietf-netmod-rfc6020bis], sec. 9.		[RFC7950].
	For example, the "last-modified" annotation defined in Section 3.1		For example, the "last-modified" annotation defined in Section 3.1
	may be encoded as follows:		may be encoded as follows:
	<foo xmlns:elm="http://example.org/example-last-modified"		<foo xmlns:elm="http://example.org/example-last-modified"
	elm:last-modified="2015-09-16T10:27:35+02:00">		elm:last-modified="2015-09-16T10:27:35+02:00">
	...		...
	</foo>		</foo>
	5.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 [RFC7951]
	[I-D.ietf-netmod-yang-json] does not change.		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 [RFC7951].
	[I-D.ietf-netmod-yang-json].
	5.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 depend 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) has the following ABNF syntax [RFC5234], where the production		object) has the following ABNF syntax [RFC5234], where the production
	for "identifier" is defined in sec. 13 of		for "identifier" is defined in Section 14 of [RFC7950]:
	[I-D.ietf-netmod-rfc6020bis]
	annotation-name = identifier ":" identifier		annotation-name = identifier ":" identifier
	where the left identifier 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 the identifier on the right is the name of		annotation is defined and the identifier on the right is 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.
	Note that unlike member names of YANG data node instances in JSON		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		encoding (see Section 4 in [RFC7951]), for annotations the explicit
	the explicit namespace identifier (module name) must always be		namespace identifier (module name) must always be present.
	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 Section 6 of [RFC7951].
	5.2.2. Adding Annotations to Anydata, Container and List Entries		5.2.2. Adding Annotations to anydata, container, and list Entries
	For a data node instance that is encoded as a JSON object (i.e., a		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		container, list entry, or anydata node), the metadata object is added
	as a new member of that object with the name "@".		as a new member of that object with the name "@".
	Examples:		Examples:
	o "cask" is a container or anydata node:		o "cask" is a container or anydata node:
	"cask": {		"cask": {
	"@": {		"@": {
	"example-last-modified:last-modified":		"example-last-modified:last-modified":
	"2015-09-16T10:27:35+02:00"		"2015-09-16T10:27:35+02:00"
	},		},
	...		...
	}		}
	o "seq" is a list whose key is "name", annotation "last-modified" 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-last-modified:last-modified":		"example-last-modified:last-modified":
	"2015-09-16T10:27:35+02:00"		"2015-09-16T10:27:35+02:00"
	},		},
	"name": "one",		"name": "one",
	...		...
	},		},
	{		{
	"name": "two",		"name": "two",
	...		...
	}		}
	]		]
	5.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 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 namespace part (module name) is included if and only if it is in
	the name of the annotated member.		the name of the annotated member.
	Examples:		Examples:
	o "flag" is a leaf node of the "boolean" type defined in module		o "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		"foo", and we assume that the namespace name has to be expressed
	JSON encoding:		in its JSON encoding:
	"foo:flag": true,		"foo:flag": true,
	"@foo:flag": {		"@foo:flag": {
	"example-last-modified:last-modified":		"example-last-modified:last-modified":
	"2015-09-16T10:27:35+02:00"		"2015-09-16T10:27:35+02:00"
	}		}
	o "stuff" is an anyxml node:		o "stuff" is an anyxml node:
	"stuff": [1, null, "three"],		"stuff": [1, null, "three"],
	"@stuff": {		"@stuff": {
	"example-last-modified:last-modified":		"example-last-modified:last-modified":
	"2015-09-16T10:27:35+02:00"		"2015-09-16T10:27:35+02:00"
	}		}
	5.2.4. Adding Annotations to Leaf-list Entries		5.2.4. Adding Annotations to leaf-list Entries
	For a leaf-list entry, which is represented as a JSON array with		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
	list entry, where the name is symbol "@" concatenated with the name		leaf-list entry, where the name is the symbol "@" concatenated with
	of the leaf-list that is being annotated, and the value is a JSON		the name of the leaf-list that is being annotated, and the value is a
	array whose i-th element is the metadata object with annotations		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		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 "last-modified" annotation is added to the second and third entry		the "last-modified" annotation is added to the second and third
	in the following way:		entries in the following way:
	"bibliomod:folio": [6, 3, 7, 8],		"bibliomod:folio": [6, 3, 7, 8],
	"@bibliomod:folio": [		"@bibliomod:folio": [
	null,		null,
	{ "example-last-modified:last-modified":		{ "example-last-modified:last-modified":
	"2015-06-18T17:01:14+02:00"		"2015-06-18T17:01:14+02:00"
	},		},
	{ "example-last-modified:last-modified":		{ "example-last-modified:last-modified":
	"2015-09-16T10:27:35+02:00"		"2015-09-16T10:27:35+02:00"
	}		}
	skipping to change at page 13, line 15 ¶		skipping to change at page 14, line 15 ¶
	6. 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 7), 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:		Section 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 [ISO.19757-2] named pattern definition
	as a child of the root <rng:grammar> element in the hybrid		MUST be added as a child of the root <rng:grammar> element in the
	schema. It is RECOMMENDED to use the name "__yang_metadata__"		hybrid schema. It is RECOMMENDED to use the name
	for this named pattern.		"__yang_metadata__" 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 an anydata, container, leaf, leaf-list or list		corresponds to an anydata, container, leaf, leaf-list, or list
	data node.		data node.
	3. Every metadata annotation definition in the form		3. Every metadata annotation definition in the form
	md:annotation ARGUMENT {		md:annotation ARGUMENT {
	...		...
	}		}
	is mapped to the following RELAX NG pattern:		is mapped to the following RELAX NG [ISO.19757-2] pattern:
	<rng:optional>		<rng:optional>
	<rng:attribute name="PREFIX:ARGUMENT">		<rng:attribute name="PREFIX:ARGUMENT">
	...		...
	</rng:attribute>		</rng:attribute>
	</rng:optional>		</rng:optional>
	where PREFIX is the prefix bound to the namespace URI of the YANG		where PREFIX is the prefix bound to the namespace URI of the YANG
	module that contains the "md:annotation" statement. The above		module that contains the "md:annotation" statement. The above
	pattern SHALL be inserted as a child of the named pattern		pattern SHALL be inserted as a child of the named pattern
	described in item 1.		described in item 1.
	4. Substatements of "md:annotation" SHALL be mapped to children of		4. Substatements of "md:annotation" SHALL be mapped to children of
	the "rng:attribute" pattern exactly as described in sec. 10 of		the "rng:attribute" pattern exactly as described in Section 10 of
	[RFC6110].		[RFC6110].
	For example, the named pattern (item 1), when constructed only for		For example, the named pattern (item 1), when constructed only for
	the "last-modified" annotation, will have the following definition:		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="elm:last-modified">		<rng:attribute name="elm:last-modified">
	<rng:ref name="ietf-yang-types__date-and-time"/>		<rng:ref name="ietf-yang-types__date-and-time"/>
	</rng:attribute>		</rng:attribute>
	</rng:optional>		</rng:optional>
	</rng:define>		</rng:define>
	Every "rng:element" pattern that corresponds to an anydata,		Every "rng:element" pattern that corresponds to an anydata,
	container, leaf, list or leaf-list data node will then contain a		container, leaf, list, or leaf-list data node will then contain a
	reference to the 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 [ISO.19757-2],
	schemas, is unaffected by the inclusion of "md:annotation".		Schematron [ISO.19757-3], and Document Semantics Renaming Language
			(DSRL) [ISO.19757-8] schemas, is unaffected by the inclusion of
			"md:annotation".
	7. Metadata YANG Module		7. Metadata YANG Module
	RFC Editor: In this section, replace all occurrences of 'XXXX' with		<CODE BEGINS> file "ietf-yang-metadata@2016-08-05.yang"
	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-21.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: <https://datatracker.ietf.org/wg/netmod/>
	WG List: <mailto:netmod@ietf.org>		WG List: <mailto:netmod@ietf.org>
	WG Chair: Lou Berger		WG Chair: Lou Berger
	<mailto:lberger@labn.net>		<mailto:lberger@labn.net>
	WG Chair: Juergen Schoenwaelder
	<mailto:j.schoenwaelder@jacobs-university.de>
	WG Chair: Kent Watsen		WG Chair: Kent Watsen
	<mailto:kwatsen@juniper.net>		<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
	defining metadata annotations.		for defining metadata annotations.
	Copyright (c) 2016 IETF Trust and the persons identified as		Copyright (c) 2016 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).
	This version of this YANG module is part of RFC XXXX		This version of this YANG module is part of RFC 7952
	(http://tools.ietf.org/html/rfcXXXX); see the RFC itself for		(http://www.rfc-editor.org/info/rfc7952); see the RFC itself
	full legal notices.";		for full legal notices.";
	revision 2016-03-21 {		revision 2016-08-05 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC XXXX: Defining and Using Metadata with YANG";		"RFC 7952: 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
	the top level of a YANG module or submodule, i.e. it becomes a		at the top level of a YANG module or submodule, i.e., it
	new alternative in the ABNF production rule for 'body-stmts'		becomes a new alternative in the ABNF production rule for
	(sec. 14 in RFC 6020bis).		'body-stmts' (Section 14 in RFC 7950).
	The argument of the 'md:annotation' statement defines the name		The argument of the 'md:annotation' statement defines the name
	of the annotation. Syntactically it is a YANG identifier as		of the annotation. Syntactically, it is a YANG identifier as
	defined in RFC 6020bis, sec. 6.2.		defined in Section 6.2 of RFC 7950.
	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.
	Data type of the annotation value is specified in the same way		The data type of the annotation value is specified in the same
	as for a leaf data node using the 'type' statement.		way as for a leaf data node using the 'type' statement.
	Semantics of the annotation and other documentation can be		The 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', and 'units'.		'status', and 'units'.
	A server announces support for a particular annotation by		A server announces support for a particular annotation by
	including the module in which the annotation is defined among		including the module in which the annotation is defined among
	the advertised YANG modules (e.g., in NETCONF hello message or		the advertised YANG modules, e.g., in a NETCONF <hello>
	yang-library). The annotation then can be attached to any		message or in the YANG library (RFC 7950). The annotation can
	instance of data node defined in any YANG module that is		then be attached to any instance of a data node defined in any
	advertised by the server.		YANG module that is advertised by the server.
	XML and JSON encoding of annotations is defined in		XML encoding and JSON encoding of annotations are defined in
	RFC XXXX.";		RFC 7952.";
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	8. IANA Considerations		8. IANA Considerations
	RFC Editor: In this section, replace all occurrences of 'XXXX' with		This document registers a URI in the "IETF XML Registry" [RFC3688].
	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		Following the format in RFC 3688, the following registration has been
	made.		made.
	---------------------------------------------------------------------		---------------------------------------------------------------------
	URI: urn:ietf:params:xml:ns:yang:ietf-yang-metadata		URI: urn:ietf:params:xml:ns:yang:ietf-yang-metadata
	Registrant Contact: The NETMOD WG of the IETF.		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.
	---------------------------------------------------------------------		---------------------------------------------------------------------
	skipping to change at page 17, line 4 ¶		skipping to change at page 18, line 18 ¶
	Following the format in RFC 3688, the following registration has been		Following the format in RFC 3688, the following registration has been
	made.		made.
	---------------------------------------------------------------------		---------------------------------------------------------------------
	URI: urn:ietf:params:xml:ns:yang:ietf-yang-metadata		URI: urn:ietf:params:xml:ns:yang:ietf-yang-metadata
	Registrant Contact: The NETMOD WG of the IETF.		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 a YANG module in the "YANG Module Names"
	registry [RFC6020].		registry [RFC6020].
	---------------------------------------------------------------------		---------------------------------------------------------------------
	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 7952
	---------------------------------------------------------------------		---------------------------------------------------------------------
	9. Security Considerations		9. Security Considerations
	This document introduces a mechanism for defining metadata		This document introduces a mechanism for defining metadata
	annotations in YANG modules and attaching them to instances of YANG		annotations in YANG modules and attaching them to instances of YANG
	data nodes. By itself, this mechanism represents no security threat.		data nodes. By itself, this mechanism represents no security threat.
	Security implications of a particular annotation defined using this		Security implications of a particular annotation defined using this
	mechanism MUST be duly considered and documented in the the		mechanism MUST be duly considered and documented in the annotation's
	annotation's definition.		definition.
	An annotation SHOULD be subject to the same or stricter access		An annotation SHOULD be subject to the same or stricter access
	control rules as the data node instance to which the annotation is		control rules as the data node instance to which the annotation is
	attached. It is RECOMMENDED that security-sensitive or privacy-		attached. It is RECOMMENDED that security-sensitive or privacy-
	sensitive data be modeled as regular YANG data nodes rather than		sensitive data be modeled as regular YANG data nodes rather than
	annotations.		annotations.
	10. Acknowledgments		10. References
	The author wishes to thank Andy Bierman, Martin Bjorklund, Benoit
	Claise, Juergen Schoenwaelder, and Kent Watsen for their helpful
	comments and suggestions.
	11. References
	11.1. Normative References
	[I-D.ietf-netmod-rfc6020bis]
	Bjorklund, M., "The YANG 1.1 Data Modeling Language",
	draft-ietf-netmod-rfc6020bis-11 (work in progress),
	February 2016.
	[I-D.ietf-netmod-yang-json]		10.1. Normative References
	Lhotka, L., "JSON Encoding of Data Modeled with YANG",
	draft-ietf-netmod-yang-json-09 (work in progress), March
	2016.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<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,
	DOI 10.17487/RFC3688, January 2004,		DOI 10.17487/RFC3688, January 2004,
	<http://www.rfc-editor.org/info/rfc3688>.		<http://www.rfc-editor.org/info/rfc3688>.
	skipping to change at page 18, line 33 ¶		skipping to change at page 19, line 37 ¶
	[RFC6110] Lhotka, L., Ed., "Mapping YANG to Document Schema		[RFC6110] Lhotka, L., Ed., "Mapping YANG to Document Schema
	Definition Languages and Validating NETCONF Content",		Definition Languages and Validating NETCONF Content",
	RFC 6110, DOI 10.17487/RFC6110, February 2011,		RFC 6110, DOI 10.17487/RFC6110, February 2011,
	<http://www.rfc-editor.org/info/rfc6110>.		<http://www.rfc-editor.org/info/rfc6110>.
	[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data		[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
	Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March		Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
	2014, <http://www.rfc-editor.org/info/rfc7159>.		2014, <http://www.rfc-editor.org/info/rfc7159>.
	[W3C.REC-xml-infoset-20040204]		[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
			RFC 7950, DOI 10.17487/RFC7950, August 2016,
			<http://www.rfc-editor.org/info/rfc7950>.
			[RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
			RFC 7951, DOI 10.17487/RFC7951, August 2016,
			<http://www.rfc-editor.org/info/rfc7951>.
			[XML-INFOSET]
	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
	xml-infoset-20040204, February 2004,		REC-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>.
	[W3C.REC-xml-names11-20060816]		[XML-NAMES]
	Bray, T., Hollander, D., Layman, A., and R. Tobin,		Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
	"Namespaces in XML 1.1 (Second Edition)", World Wide Web		Thompson, "Namespaces in XML 1.0 (Third Edition)", World
	Consortium Recommendation REC-xml-names11-20060816, August		Wide Web Consortium Recommendation REC-xml-names-20091208,
	2006,		December 2009,
	<http://www.w3.org/TR/2006/REC-xml-names11-20060816>.		<http://www.w3.org/TR/2009/REC-xml-names-20091208>.
	11.2. Informative References
	[I-D.ietf-netconf-restconf]		10.2. Informative References
	Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
	Protocol", draft-ietf-netconf-restconf-10 (work in
	progress), March 2016.
	[ISO.19757-1]		[ISO.19757-1]
	International Organization for Standardization, "Document		International Organization for Standardization,
	Schema Definition Languages (DSDL) - Part 1: Overview",		"Information Technology - Document Schema Definition
	ISO/IEC 19757-1, November 2004.		Languages (DSDL) - Part 1: Overview", ISO/IEC 19757-1,
			September 2008.
	[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
	RFC Editor: Remove this section upon publication as an RFC.
	A.1. Changes Between Revisions -06 and -07
	o Added sentence in Sec. 9 (Stephen Farrell's suggestion).
	A.2. Changes Between Revisions -05 and -06
	o Added explanation of why a YANG extension is used rather than a
	built-in statement.
	A.3. Changes Between Revisions -04 and -05
	o Clarification regarding the type of an annotation.
	A.4. Changes Between Revisions -03 and -04
	o Added explanation of what "top level of a module" means.
	A.5. Changes Between Revisions -02 and -03
	o Section 4 was considerably simplified, also because member names
	starting with "@" are now permitted by
	[I-D.ietf-netmod-yang-json].
	A.6. 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
	properties.
	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.7. Changes Between Revisions -00 and -01
	o Define JSON encoding for annotations attached to 'anydata' nodes.
	A.8. Changes Between draft-lhotka-netmod-yang-metadata-01 and draft-		[ISO.19757-2]
	ietf-netmod-yang-metadata-00		International Organization for Standardization,
			"Information technology -- Document Schema Definition
			Language (DSDL) -- Part 2: Regular-grammar-based
			validation -- RELAX NG", ISO/IEC 19757-2:2008, December
			2008.
	o References to RFC 6020 were changed to the 6020bis I-D.		[ISO.19757-3]
			International Organization for Standardization,
			"Information technology -- Document Schema Definition
			Languages (DSDL) -- Part 3: Rule-based validation --
			Schematron", ISO/IEC 19757-3:2016, January 2016.
	o Text about RFC 2119 key words was added to "ietf-yang-metadata"		[ISO.19757-8]
	module description.		International Organization for Standardization,
			"Information Technology - Document Schema Definition
			Languages (DSDL) - Part 8: Document Semantics Renaming
			Language - DSRL", ISO/IEC 19757-8:2008(E), December 2008.
	A.9. Changes Between draft-lhotka-netmod-yang-metadata-00 and -01		[RESTCONF] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
			Protocol", Work in Progress,
			draft-ietf-netconf-restconf-16, August 2016.
	o Encoding of annotations for anyxml nodes was changed to be the		[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
	same as for leafs. This was necessary because anyxml value now		and A. Bierman, Ed., "Network Configuration Protocol
	needn't be an object.		(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
			<http://www.rfc-editor.org/info/rfc6241>.
	o It is stated that "md:annotation" statement defines only the		Acknowledgements
	syntax of an annotation.
	o Allowed "if-feature" as a substatement of "md:annotation".		The author wishes to thank Andy Bierman, Martin Bjorklund, Benoit
			Claise, Juergen Schoenwaelder, and Kent Watsen for their helpful
			comments and suggestions.
	Author's Address		Author's Address
	Ladislav Lhotka		Ladislav Lhotka
	CZ.NIC		CZ.NIC
	Email: lhotka@nic.cz		Email: lhotka@nic.cz
End of changes. 128 change blocks.
	350 lines changed or deleted		265 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/