draft-ietf-netmod-yang-metadata-02.txt   draft-ietf-netmod-yang-metadata-03.txt 
NETMOD Working Group L. Lhotka NETMOD Working Group L. Lhotka
Internet-Draft CZ.NIC Internet-Draft CZ.NIC
Intended status: Standards Track September 17, 2015 Intended status: Standards Track January 28, 2016
Expires: March 20, 2016 Expires: July 31, 2016
Defining and Using Metadata with YANG Defining and Using Metadata with YANG
draft-ietf-netmod-yang-metadata-02 draft-ietf-netmod-yang-metadata-03
Abstract Abstract
This document defines a YANG extension statement that allows for This document defines a YANG extension statement that allows for
defining metadata annotations in YANG modules. The document also defining metadata annotations in YANG modules. The document also
specifies XML and JSON encoding of annotations and other rules for specifies XML and JSON encoding of annotations and other rules for
annotating instances of YANG data nodes. annotating instances of YANG data nodes.
Status of This Memo Status of This Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 20, 2016. This Internet-Draft will expire on July 31, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Terms Defined in Other Documents . . . . . . . . . . . . 4 2.2. Terms Defined in Other Documents . . . . . . . . . . . . 4
2.3. Namespaces and Prefixes . . . . . . . . . . . . . . . . . 6 2.3. Namespaces and Prefixes . . . . . . . . . . . . . . . . . 6
2.4. Definitions of New Terms . . . . . . . . . . . . . . . . 6 2.4. Definitions of New Terms . . . . . . . . . . . . . . . . 6
3. Defining Annotations in YANG . . . . . . . . . . . . . . . . 6 3. Defining Annotations in YANG . . . . . . . . . . . . . . . . 6
3.1. Example Definition . . . . . . . . . . . . . . . . . . . 7 3.1. Example Definition . . . . . . . . . . . . . . . . . . . 7
4. Using Annotations . . . . . . . . . . . . . . . . . . . . . . 8 4. Using Annotations . . . . . . . . . . . . . . . . . . . . . . 8
5. The Encoding of Annotations . . . . . . . . . . . . . . . . . 9 5. The Encoding of Annotations . . . . . . . . . . . . . . . . . 9
5.1. XML Encoding . . . . . . . . . . . . . . . . . . . . . . 9 5.1. XML Encoding . . . . . . . . . . . . . . . . . . . . . . 9
5.2. JSON Encoding . . . . . . . . . . . . . . . . . . . . . . 10 5.2. JSON Encoding . . . . . . . . . . . . . . . . . . . . . . 9
5.2.1. Metadata Object and Annotations . . . . . . . . . . . 10 5.2.1. Metadata Object and Annotations . . . . . . . . . . . 10
5.2.2. Adding Annotations to Anydata, Container and List 5.2.2. Adding Annotations to Anydata, Container and List
Entries . . . . . . . . . . . . . . . . . . . . . . . 11 Entries . . . . . . . . . . . . . . . . . . . . . . . 10
5.2.3. Adding Annotations to Anyxml and Leaf Instances . . . 11 5.2.3. Adding Annotations to Anyxml and Leaf Instances . . . 11
5.2.4. Adding Annotations to Leaf-list Entries . . . . . . . 12 5.2.4. Adding Annotations to Leaf-list Entries . . . . . . . 12
6. Representing Annotations in DSDL Schemas . . . . . . . . . . 13 6. Representing Annotations in DSDL Schemas . . . . . . . . . . 12
7. Metadata YANG Module . . . . . . . . . . . . . . . . . . . . 14 7. Metadata YANG Module . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 18
A.1. Changes Between Revisions -01 and -02 . . . . . . . . . . 19 A.1. Changes Between Revisions -01 and -02 . . . . . . . . . . 18
A.2. Changes Between Revisions -00 and -01 . . . . . . . . . . 19 A.2. Changes Between Revisions -01 and -02 . . . . . . . . . . 19
A.3. Changes Between draft-lhotka-netmod-yang-metadata-01 and A.3. Changes Between Revisions -00 and -01 . . . . . . . . . . 19
A.4. Changes Between draft-lhotka-netmod-yang-metadata-01 and
draft-ietf-netmod-yang-metadata-00 . . . . . . . . . . . 19 draft-ietf-netmod-yang-metadata-00 . . . . . . . . . . . 19
A.4. Changes Between draft-lhotka-netmod-yang-metadata-00 and A.5. Changes Between draft-lhotka-netmod-yang-metadata-00 and
-01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 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 [I-D.ietf-netmod-rfc6020bis] data nodes with metadata. Typical YANG [I-D.ietf-netmod-rfc6020bis] data nodes with metadata. Typical
use cases are: use cases are:
o Complementing regular data model information with instance- o Complementing regular data model information with instance-
skipping to change at page 3, line 46 skipping to change at page 3, line 46
This document proposes a systematic way for defining metadata This document proposes a systematic way for defining metadata
annotations. For this purpose, YANG extension statement "annotation" annotations. For this purpose, YANG extension statement "annotation"
is defined in the module "ietf-yang-metadata" (Section 7). Other is defined in the module "ietf-yang-metadata" (Section 7). Other
YANG modules importing this module can use the "annotation" statement YANG modules importing this module can use the "annotation" statement
for defining one or more annotations. for 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, namespace URI and o Each annotation is bound to a YANG module name and namespace URI.
prefix. This makes its encoding in instance documents (both XML This makes its encoding in instance documents (both XML and JSON)
and JSON) straightforward and consistent with the encoding of YANG straightforward and consistent with the encoding of YANG data node
data node instances. instances.
o Annotations are indirectly registered through IANA in the "YANG o Annotations defined in IETF standard-track documents are
Module Names" registry [RFC6020]. indirectly registered through IANA in the "YANG Module Names"
registry [RFC6020].
o Annotations are included in the data model. YANG compilers and o Annotations are included in the data model. YANG compilers and
tools supporting a certain annotation can thus take them into tools supporting a certain annotation can thus take them into
account and modify their behavior accordingly. account and modify their behavior accordingly.
o Semantics of an annotation are defined in the "description" and o Semantics of an annotation are defined in the "description" and
"reference" statements. "reference" statements.
o An annotation can be declared as conditional by using the "if- o An annotation can be declared as conditional by using the "if-
feature" statement. feature" statement.
skipping to change at page 4, line 27 skipping to change at page 4, line 31
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 are scalar values and cannot be further structured; o annotations are scalar values and cannot be further structured;
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 of leaf-list entries. instance, only to individual list or leaf-list entries.
2. Terminology 2. Terminology
2.1. Keywords 2.1. Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2.2. Terms Defined in Other Documents 2.2. Terms Defined in Other Documents
skipping to change at page 8, line 26 skipping to change at page 8, line 26
description description
"This annotation contains date and time when the "This annotation contains 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 anywhere in any data tree it is prepared to handle that annotation according to the
that is a part of the server's data model (configuration, state data, annotation's definition. That is, an annotation advertised by the
RPC operation/action input or output). That is, an annotation server may be attached to an instance of a data node defined in any
advertised by the server may be attached to any instance of a data YANG module that is implemented by the server.
node defined in any YANG module that is also advertised 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 data nodes types.
If such an annotation appears elsewhere, it is syntactically valid
but the annotation is ignored.
A client MUST NOT use an annotation in protocol operations if the A client MUST NOT add a specific annotation to data node instances if
server didn't advertise it. the server didn't advertise it.
Annotations modify the schema of datastores and/or management Due care has to be exercised when introducing annotations in network
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 management systems in order to avoid interoperability problems and
software failures. The following aspects should be taken into software failures caused by a client that does not understand the
account: annotations' semantics. Generally, it is safe for a server to use
annotations in the following cases:
o A client may not not be able to parse or validate protocol
messages containing annotations.
o A client may not understand semantics of an annotation set by the
server or other clients.
Generally, it is safe for a server to use annotations in the
following cases, provided that the client is able to parse them and
discard those that it doesn't understand or support:
o An annotation is an integral part of a built-in or negotiated o An annotation is an integral part of a built-in or negotiated
protocol capability. protocol capability.
o An annotation contains optional 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, for including 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
skipping to change at page 14, line 37 skipping to change at page 14, line 19
The second step of the DSDL mapping procedure, i.e., the The second step of the DSDL mapping procedure, i.e., the
transformation of the hybrid schema to RELAX NG, Schematron and DSRL transformation of the hybrid schema to RELAX NG, Schematron and DSRL
schemas, is unaffected by the inclusion of "md:annotation". schemas, is unaffected by the inclusion of "md:annotation".
7. Metadata YANG Module 7. Metadata YANG Module
RFC Editor: In this section, replace all occurrences of 'XXXX' with RFC Editor: In this section, replace all occurrences of 'XXXX' with
the actual RFC number and all occurrences of the revision date below the actual RFC number and all occurrences of the revision date below
with the date of RFC publication (and remove this note). with the date of RFC publication (and remove this note).
<CODE BEGINS> file "ietf-yang-metadata@2015-09-17.yang" <CODE BEGINS> file "ietf-yang-metadata@2016-01-28.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";
skipping to change at page 15, line 38 skipping to change at page 15, line 21
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and
'OPTIONAL' in the module text are to be interpreted as described 'OPTIONAL' in the module text are to be interpreted as described
in RFC 2119 (http://tools.ietf.org/html/rfc2119). in RFC 2119 (http://tools.ietf.org/html/rfc2119).
This version of this YANG module is part of RFC XXXX This version of this YANG module is part of RFC XXXX
(http://tools.ietf.org/html/rfcXXXX); see the RFC itself for (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for
full legal notices."; full legal notices.";
revision 2015-09-17 { revision 2016-01-28 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Defining and Using Metadata with YANG"; "RFC XXXX: Defining and Using Metadata with YANG";
} }
extension annotation { extension annotation {
argument name; argument name;
description description
"This extension allows for defining metadata annotations in "This extension allows for defining metadata annotations in
skipping to change at page 17, line 38 skipping to change at page 17, line 20
The author wishes to thank Andy Bierman, Martin Bjorklund, Benoit The author wishes to thank Andy Bierman, Martin Bjorklund, Benoit
Claise, Juergen Schoenwaelder, and Kent Watsen for their helpful Claise, Juergen Schoenwaelder, and Kent Watsen for their helpful
comments and suggestions. comments and suggestions.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-netmod-rfc6020bis] [I-D.ietf-netmod-rfc6020bis]
Bjorklund, M., "YANG - A Data Modeling Language for the Bjorklund, M., "The YANG 1.1 Data Modeling Language",
Network Configuration Protocol (NETCONF)", draft-ietf- draft-ietf-netmod-rfc6020bis-09 (work in progress),
netmod-rfc6020bis-06 (work in progress), July 2015. December 2015.
[I-D.ietf-netmod-yang-json] [I-D.ietf-netmod-yang-json]
Lhotka, L., "JSON Encoding of Data Modeled with YANG", Lhotka, L., "JSON Encoding of Data Modeled with YANG",
draft-ietf-netmod-yang-json-05 (work in progress), draft-ietf-netmod-yang-json-06 (work in progress), October
September 2015. 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
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>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ Specifications: ABNF", STD 68, RFC 5234,
RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <http://www.rfc-editor.org/info/rfc5234>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>. <http://www.rfc-editor.org/info/rfc6020>.
[RFC6110] Lhotka, L., Ed., "Mapping YANG to Document Schema [RFC6110] Lhotka, L., Ed., "Mapping YANG to Document Schema
Definition Languages and Validating NETCONF Content", RFC Definition Languages and Validating NETCONF Content",
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] [W3C.REC-xml-infoset-20040204]
Cowan, J. and R. Tobin, "XML Information Set (Second Cowan, J. and R. Tobin, "XML Information Set (Second
Edition)", World Wide Web Consortium Recommendation REC- Edition)", World Wide Web Consortium Recommendation REC-
xml-infoset-20040204, February 2004, xml-infoset-20040204, February 2004,
skipping to change at page 18, line 45 skipping to change at page 18, line 26
Bray, T., Hollander, D., Layman, A., and R. Tobin, Bray, T., Hollander, D., Layman, A., and R. Tobin,
"Namespaces in XML 1.1 (Second Edition)", World Wide Web "Namespaces in XML 1.1 (Second Edition)", World Wide Web
Consortium Recommendation REC-xml-names11-20060816, August Consortium Recommendation REC-xml-names11-20060816, August
2006, 2006,
<http://www.w3.org/TR/2006/REC-xml-names11-20060816>. <http://www.w3.org/TR/2006/REC-xml-names11-20060816>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-netconf-restconf] [I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-07 (work in Protocol", draft-ietf-netconf-restconf-09 (work in
progress), July 2015. progress), December 2015.
[ISO.19757-1] [ISO.19757-1]
International Organization for Standardization, "Document International Organization for Standardization, "Document
Schema Definition Languages (DSDL) - Part 1: Overview", Schema Definition Languages (DSDL) - Part 1: Overview",
ISO/IEC 19757-1, November 2004. ISO/IEC 19757-1, November 2004.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>. <http://www.rfc-editor.org/info/rfc6241>.
Appendix A. Change Log Appendix A. Change Log
RFC Editor: Remove this section upon publication as an RFC. RFC Editor: Remove this section upon publication as an RFC.
A.1. Changes Between Revisions -01 and -02 A.1. Changes Between Revisions -01 and -02
o Section 4 was considerably simplified, also because member names
starting with "@" are now permitted by
[I-D.ietf-netmod-yang-json].
A.2. Changes Between Revisions -01 and -02
o The "type" statement became mandatory. o The "type" statement became mandatory.
o Terminology section was extended. o Terminology section was extended.
o The annotation "inactive" defined in the example module was o The annotation "inactive" defined in the example module was
replaced with "last-modified" that is supposedly less replaced with "last-modified" that is supposedly less
controversial. controversial.
o Introduction now states limitation due to XML attribute o Introduction now states limitation due to XML attribute
porperties. properties.
o A recommendation was added to define annotations in a module by o A recommendation was added to define annotations in a module by
themselves. themselves.
o Section "Using Annotations" was added. o Section "Using Annotations" was added.
o An example for "anyxml" was added. o An example for "anyxml" was added.
o RFC 6241 was moved to informative references. o RFC 6241 was moved to informative references.
A.2. Changes Between Revisions -00 and -01 A.3. Changes Between Revisions -00 and -01
o Define JSON encoding for annotations attached to 'anydata' nodes. o Define JSON encoding for annotations attached to 'anydata' nodes.
A.3. Changes Between draft-lhotka-netmod-yang-metadata-01 and draft- A.4. Changes Between draft-lhotka-netmod-yang-metadata-01 and draft-
ietf-netmod-yang-metadata-00 ietf-netmod-yang-metadata-00
o References to RFC 6020 were changed to the 6020bis I-D. o References to RFC 6020 were changed to the 6020bis I-D.
o Text about RFC 2119 key words was added to "ietf-yang-metadata" o Text about RFC 2119 key words was added to "ietf-yang-metadata"
module description. module description.
A.4. Changes Between draft-lhotka-netmod-yang-metadata-00 and -01 A.5. Changes Between draft-lhotka-netmod-yang-metadata-00 and -01
o Encoding of annotations for anyxml nodes was changed to be the o Encoding of annotations for anyxml nodes was changed to be the
same as for leafs. This was necessary because anyxml value now same as for leafs. This was necessary because anyxml value now
needn't be an object. needn't be an object.
o It is stated that "md:annotation" statement defines only the o It is stated that "md:annotation" statement defines only the
syntax of an annotation. syntax of an annotation.
o Allowed "if-feature" as a substatement of "md:annotation". o Allowed "if-feature" as a substatement of "md:annotation".
 End of changes. 32 change blocks. 
66 lines changed or deleted 59 lines changed or added

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