draft-ietf-netmod-yang-metadata.xml

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM ".tools/schema/rfc2629.dtd" [
<!ENTITY % COMMON SYSTEM ".tools/bplate/common.ent">
%COMMON;
<!ENTITY % WG SYSTEM ".tools/bplate/ietf-wg.ent">
%WG;
<!ENTITY % stdrefs SYSTEM "stdrefs.ent">
%stdrefs;
<!ENTITY % figures SYSTEM "figures.ent">
%figures;
<!ENTITY % yang SYSTEM "yang.ent">
%yang;
]>

<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<rfc category="std" updates="6110">
  <front>
    <title abbrev="YANG Metadata">Defining and Using Metadata with YANG</title>
    <author fullname="Ladislav Lhotka" initials="L." surname="Lhotka">
      <organization>CZ.NIC</organization>
      <address>
        <email>lhotka@nic.cz</email>
      </address>
    </author>
    <date year="YYYY-MM-DD"/>
    <area>ops</area>
    &netmod-wg;

    <abstract>
      <t>This document defines a YANG extension statement that allows
      for defining metadata annotations in YANG modules. The document
      also specifies XML and JSON encoding of annotations and other
      rules for annotating instances of YANG data nodes.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>There is a need to be able to annotate instances of
      YANG <xref target="I-D.ietf-netmod-rfc6020bis"/> data nodes with metadata. Typical
      use cases are:
      <list style="symbols">
        <t>Complementing regular data model information with
        instance-specific metadata, comments etc.</t>
        <t>Providing information about data rendering in user
        interfaces.</t>
        <t>Deactivating a subtree in a configuration datastore while
        keeping the data in place.</t>
        <t>Network management protocols often use metadata annotations
        for various purposes in both operation requests and
        responses. For example, the &lt;edit-config&gt; operation in
        the NETCONF protocol (see section 7.2 of <xref
        target="RFC6241"/>) uses annotations in the form of XML
        attributes for identifying the location in a configuration
        datastore and the type of the operation.</t>
      </list></t>
      <t>However, metadata annotations could potentially lead to
      interoperability problems if they are used in an ad hoc fashion
      by different parties and/or without proper documentation. A
      sound metadata framework for YANG should therefore satisfy these
      requirements:
      <list style="numbers">
        <t>The set of annotations must be extensible in a
        decentralised manner so as to allow for defining new
        annotations without running into the risk of collisions with
        annotations defined and used by others.</t>
        <t>Syntax and semantics of annotations must be documented and
        the documentation must be easily accessible.</t>
        <t>Clients of network management protocols such as
        NETCONF <xref target="RFC6241"/> or RESTCONF <xref
        target="I-D.ietf-netconf-restconf"/> must be able to discover
        all annotations supported by a given server and identify each
        of them correctly.</t>
        <t>Annotations sent by a server should not break clients that
        don't support them.</t>
      </list></t>
      <t>This document proposes a systematic way for defining metadata
      annotations. For this purpose, YANG extension statement
      "annotation" is defined in the module "ietf-yang-metadata"
      (<xref target="ietf-yang-metadata"/>). Other YANG modules
      importing this module can use the "annotation" statement for
      defining one or more annotations.</t>
      <t>The benefits of defining the metadata annotations in a YANG
      module are the following:
      <list style="symbols">
        <t>Each annotation is bound to a YANG module name and
        namespace URI. This makes its encoding in instance documents
        (both XML and JSON) straightforward and consistent with the
        encoding of YANG data node instances.</t>
        <t>Annotations defined in IETF standard-track documents are
        indirectly registered through IANA in the "YANG Module Names"
        registry <xref target="RFC6020"/>.</t>
        <t>Annotations are included in the data model. YANG compilers
        and tools supporting a certain annotation can thus take them
        into account and modify their behavior accordingly.</t>
        <t>Semantics of an annotation are defined in the "description"
        and "reference" statements.</t>
        <t>An annotation can be declared as conditional by using the
        "if-feature" statement.</t>
        <t>The type of each annotation is explicitly specified; any
        YANG built-in or derived type that is available for leaf or
        leaf-list data nodes may be specified for annotations as
        well.</t>
      </list></t>
      <t>In the XML encoding, XML attributes are a natural instrument
      for attaching annotations to data node instances. This document
      deliberately adopts some restrictions in order to remain
      compatible with the XML encoding of YANG data node instances and
      limitations of XML attributes. Specifically,
      <list style="symbols">
        <t>annotations can only be scalar values;</t>
        <t>annotations cannot be attached to a whole list or leaf-list
        instance, only to individual list or leaf-list entries.</t>
      </list></t>
      <t>Due to the rules for YANG extensions (see sec. 6.3.1 in <xref
      target="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.</t>
    </section>

    <section anchor="terminology" title="Terminology">

      <section anchor="keywords" title="Keywords">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
        "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
        "OPTIONAL" in this document are to be interpreted as described
        in <xref target="RFC2119"/>.</t>
      </section>

      <section anchor="adopted-terms"
               title="Terms Defined in Other Documents">
        <t>The following terms are defined in <xref target="RFC6241"/>:
        <list style="symbols">
          <t>capability,</t>
          <t>client,</t>
          <t>datastore,</t>
          <t>message,</t>
          <t>protocol operation,</t>
          <t>server.</t>
        </list></t>

        <t>The following terms are defined in <xref target="I-D.ietf-netmod-rfc6020bis"/>:
        <list style="symbols">
          <t>action,</t>
          <t>anydata,</t>
          <t>anyxml,</t>
          <t>built-in type,</t>
          <t>container,</t>
          <t>data model,</t>
          <t>data node,</t>
          <t>data tree,</t>
	  <t>derived type,</t>
          <t>extension,</t>
          <t>leaf,</t>
          <t>leaf-list,</t>
          <t>list,</t>
          <t>module,</t>
          <t>RPC input and output.</t>
        </list></t>

        <t>The following terms are defined in <xref
        target="W3C.REC-xml-infoset-20040204"/>:
        <list style="symbols">
          <t>attribute,</t>
          <t>document,</t>
          <t>element.</t>
        </list></t>

        <t>The following terms are defined in <xref
        target="W3C.REC-xml-names11-20060816"/>:
        <list style="symbols">
          <t>local name,</t>
          <t>namespace name,</t>
          <t>prefix,</t>
          <t>qualified name.</t>
        </list></t>

        <t>The following terms are defined in <xref target="RFC7159"/>:
        <list style="symbols">
          <t>array,</t>
          <t>member,</t>
          <t>object,</t>
          <t>primitive type.</t>
        </list></t>
      </section>

      <section anchor="ns-pref" title="Namespaces and Prefixes">
        <t>In the following text, XML element names and YANG extension
        statements are always written with explicit namespace prefixes
        that are assumed to be bound to URI references as shown in <xref
        target="tab.ns"/>.</t>
        <texttable
            anchor="tab.ns"
            title="Used namespace prefixes and corresponding URI references">
          <ttcol>Prefix</ttcol>
          <ttcol>URI Reference</ttcol>
          <c>elm</c>
          <c>http://example.org/example-last-modified</c>
          <c>md</c>
          <c>urn:ietf:params:xml:ns:yang:ietf-yang-metadata</c>
          <c>rng</c>
          <c>http://relaxng.org/ns/structure/1.0</c>
        </texttable>
      </section>

      <section anchor="new-terms" title="Definitions of New Terms">
        <t><list style="symbols">
          <t>annotation: a single item of metadata that is attached to
          YANG data node instances.</t>
          <t>metadata: additional information that complements a data
          tree.</t>
          <t>metadata object: an object in JSON encoding that contains
          all annotations attached to a given data node instance.</t>
        </list></t>
      </section>

    </section>

    <section anchor="annotdef" title="Defining Annotations in YANG">
      <t>Metadata annotations are defined by YANG extension statement
      "md:annotation". This YANG language extension is defined in the
      module "ietf-yang-metadata" (<xref
      target="ietf-yang-metadata"/>).</t>
      <t>Substatements of "md:annotation" are shown in <xref
      target="tab.annsub"/>. They are all core YANG statements, and
      the numbers in the second column refer to the corresponding
      section in <xref target="I-D.ietf-netmod-rfc6020bis"/> where each
      statement is described.</t>
      <texttable anchor="tab.annsub"
                 title='Substatements of "md:annotation".'>
        <ttcol>substatement</ttcol>
        <ttcol>RFC 6020bis section</ttcol>
        <ttcol>cardinality</ttcol>
        <c>description</c><c>7.21.3</c><c>0..1</c>
        <c>if-feature</c><c>7.20.2</c><c>0..n</c>
        <c>reference</c><c>7.21.4</c><c>0..1</c>
        <c>status</c><c>7.21.2</c><c>0..1</c>
        <c>type</c><c>7.6.3</c><c>1</c>
        <c>units</c><c>7.3.3</c><c>0..1</c>
      </texttable>
      <t>An annotation carries a single value. The type substatement,
      which MUST be present, takes as an argument the name of an
      existing built-in or derived type, and the value of the
      annotation MUST match this type. See Section 7.4 of <xref
      target="I-D.ietf-netmod-rfc6020bis"/> for details.</t>
      <t>An annotation can be made conditional by using one or more
      "if-feature" statements; the annotation is then supported only
      by servers that advertise the corresponding feature.</t>
      <t>The semantics and usage rules for an annotation SHOULD be
      fully specified in "description", "reference" and "units"
      statements.</t>
      <t>An annotation MUST NOT change the data tree semantics defined
      by YANG. For example, it is illegal to define and use an
      annotation that allows for overriding uniqueness of leaf-list
      entries.</t>
      <t>The "status" statement can be used exactly as for YANG data
      nodes.</t>
      <t>A YANG module containing one or more "md:annotation"
      extension statements SHOULD NOT be used for defining data nodes
      or groupings. Also, derived types, identities and features
      SHOULD NOT be defined in such a module unless they are used by
      the definitions of annotations in that module.</t>
      <section anchor="ex-module" title="Example Definition">
        <t>The following module defines the "last-modified"
        annotation:</t>
        <figure>
          &example-last-modified.yang;
        </figure>
      </section>
    </section>
    <section anchor="usage" title="Using Annotations">
      <t>By advertising a YANG module in which a metadata annotation
      is defined using the "md:annotation" statement, a server
      indicates that it is prepared to handle that annotation
      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.</t>
      <t>Depending on its semantics, an annotation may have an effect
      only in certain data trees and/or on instances of specific data
      nodes types.</t>
      <t>A client MUST NOT add a specific annotation to data node
      instances if the server didn't advertise it.</t>
      <t>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:
      <list style="symbols">
        <t>An annotation is an integral part of a built-in or
        negotiated protocol capability.</t>
        <t>An annotation contains auxiliary information that is not
        critical for protocol operation.</t>
        <t>The client explicitly asks the server, e.g., via a
        parameter of a protocol operation request, for including an
        annotation in the response.</t>
      </list></t>
    </section>

    <section anchor="encoding" title="The Encoding of Annotations">
      <t>XML attributes are a natural choice for encoding metadata in
      XML instance documents. For JSON <xref target="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 <xref target="I-D.ietf-netmod-yang-json"/>.</t>

      <section anchor="enc-xml" title="XML Encoding">
        <t>Metadata annotations are added to XML-encoded instances of
        YANG data nodes as XML attributes according to these rules:
        <list style="symbols">
          <t>The local name of the attribute SHALL be the same as the
          name of the annotation specified in the argument of the
          corresponding "md:annotation" statement.</t>
          <t>The namespace of the attribute SHALL be identified by the
          URI that appears as the argument of the "namespace"
          statement in the YANG module where the annotation is
          defined. It is RECOMMENDED that the prefix specified by the
          "prefix" statement in the same module is used in the
          qualified name of the attribute.</t>
          <t>The attribute value SHALL be encoded in the same way as
          the value of a YANG leaf instance having the same type,
          see <xref target="I-D.ietf-netmod-rfc6020bis"/>, sec. 9.</t>
        </list></t>
        <t>For example, the "last-modified" annotation defined in <xref
        target="ex-module"/> may be encoded as follows:</t>
        <figure>
          <artwork>
<![CDATA[<foo xmlns:elm="http://example.org/example-last-modified"
     elm:last-modified="2015-09-16T10:27:35+02:00">
  ...
</foo>]]></artwork>
        </figure>
      </section>

      <section anchor="enc-json" title="JSON Encoding">
        <t>The JSON metadata encoding defined in this section has the
        following properties:
        <list style="numbers">
          <t>The encoding of YANG data node instances as defined in
          <xref target="I-D.ietf-netmod-yang-json"/> does not change.</t>
          <t>Namespaces of metadata annotations are encoded in the same
          way as namespaces of YANG data node instances, see <xref
          target="I-D.ietf-netmod-yang-json"/>.</t>
        </list></t>

        <section anchor="met-obj" title="Metadata Object and Annotations">

          <t>All metadata annotations assigned to a YANG data node
          instance are encoded as members (name/value pairs) of a
          single JSON object, henceforth denoted as the metadata
          object. The placement and name of this object depends on the
          type of the data node as specified in the following
          subsections.</t>
          <t>The name of a metadata annotation (as a member of the
          metadata object) has the following ABNF syntax <xref
          target="RFC5234"/>, where the production for "identifier" is
          defined in sec. 13 of <xref
          target="I-D.ietf-netmod-rfc6020bis"/>
          <figure>
            <artwork>annotation-name = identifier ":" identifier</artwork>
          </figure>
          where the left identifier is the name of the YANG module in
          which the annotation is defined, and the identifier on the
          right is the name of the annotation specified in the
          argument of the corresponding "md:annotation" statement.</t>
          <t>Note that unlike member names of YANG data node instances
          in JSON encoding (see sec. 4 in <xref
          target="I-D.ietf-netmod-yang-json"/>), for annotations the
          explicit namespace identifier (module name) must always be
          present.</t>
          <t>The value of a metadata annotation SHALL be encoded in
          exactly the same way as the value of a YANG leaf node having
          the same type as the annotation, see <xref
          target="I-D.ietf-netmod-yang-json"/>, sec. 6.</t>
        </section>

        <section
            anchor="enc-cal"
            title="Adding Annotations to Anydata, Container and List Entries">

          <t>For a data node instance that is encoded as a JSON object
          (i.e., a container, list entry, or anydata node), the
          metadata object is added as a new member of that object with
          the name "@".</t>
          <t>Examples:
          <list style="symbols">
            <t>"cask" is a container or anydata node:
            <figure>
              <artwork>
"cask": {
  "@": {
    "example-last-modified:last-modified":
      "2015-09-16T10:27:35+02:00"
  },
  ...
}</artwork>
            </figure></t>
            <t>"seq" is a list whose key is "name", annotation
            "last-modified" is added only to the first entry:
            <figure>
              <artwork>
"seq": [
  {
    "@": {
      "example-last-modified:last-modified":
          "2015-09-16T10:27:35+02:00"
    },
    "name": "one",
    ...
  },
  {
    "name": "two",
    ...
  }
]</artwork>
            </figure></t>
          </list></t>

        </section>

        <section
            anchor="enc-l"
            title="Adding Annotations to Anyxml and Leaf Instances">

          <t>For an anyxml or leaf instance, the metadata object is
          added as a sibling name/value pair whose name is the symbol
          "@" concatenated with the name of the leaf or anyxml member
          that is being annotated. The namespace part (module name) is
          included if and only if it is in the name of the annotated
          member.</t>
          <t>Examples:
          <list style="symbols">
            <t>"flag" is a leaf node of the "boolean" type defined in
            module "foo", and we assume the namespace name has to be
            expressed in its JSON encoding:
            <figure>
              <artwork>
"foo:flag": true,
"@foo:flag": {
  "example-last-modified:last-modified":
    "2015-09-16T10:27:35+02:00"
}</artwork>
            </figure></t>
            <t>"stuff" is an anyxml node:
            <figure>
              <artwork>
"stuff": [1, null, "three"],
"@stuff": {
  "example-last-modified:last-modified":
    "2015-09-16T10:27:35+02:00"
}</artwork>
            </figure></t>
          </list></t>
        </section>

        <section
            anchor="enc-ll"
            title="Adding Annotations to Leaf-list Entries">

          <t>For a leaf-list entry, which is represented as a JSON
          array with values of a primitive type, annotations may be
          assigned to one or more entries by adding a name/array pair
          as a sibling of the leaf-list entry, where the name is
          symbol "@" concatenated with the name of the leaf-list that
          is being annotated, and the value is a JSON array whose i-th
          element is the metadata object with annotations assigned to
          the i-th entry of the leaf-list entry, or null if the i-th
          entry has no annotations.</t>
          <t>Trailing null values in that array, i.e., those following
          the last non-null metadata object, MAY be omitted.</t>
          <t>For example, in the following leaf-list instance with
          four entries, the "last-modified" annotation is added to the
          second and third entry in the following way:
          <figure>
            <artwork>
"bibliomod:folio": [6, 3, 7, 8],
"@bibliomod:folio": [
  null,
  { "example-last-modified:last-modified":
      "2015-06-18T17:01:14+02:00"
  },
  { "example-last-modified:last-modified":
      "2015-09-16T10:27:35+02:00"
  }
]</artwork>
          </figure></t>
        </section>
      </section>
    </section>

    <section anchor="dsdl" title="Representing Annotations in DSDL Schemas">
      <t><xref target="RFC6110"/> defines the standard mapping of YANG
      data models to Document Schema Definition Languages (DSDL) <xref
      target="ISO.19757-1"/>. This section specifies the mapping for
      the extension statement "md:annotation" (<xref
      target="ietf-yang-metadata"/>), which enables validation of XML
      instance documents containing metadata annotations.</t>
      <t>The first step of the DSDL mapping procedure, i.e., the
      transformation of the YANG data model to the hybrid schema (see
      sec. 6 in <xref target="RFC6110"/>), is modified as follows:
      <list style="numbers">
        <t anchor="it.npdef">If the data model contains at least one
        "md:annotation" statement, then a RELAX NG named pattern
        definition MUST be added as a child of the root
        &lt;rng:grammar&gt; element in the hybrid schema. It is
        RECOMMENDED to use the name "__yang_metadata__" for this named
        pattern.</t> <t anchor="it.npref">A reference to the named
        pattern described in item <xref target="it.npdef"
        format="counter"/> MUST be included as a child of every
        &lt;rng:element&gt; pattern that corresponds to an anydata,
        container, leaf, leaf-list or list data node.</t>
        <t>Every metadata annotation definition in the form
        <figure>
          <artwork>
    md:annotation ARGUMENT {
      ...
    }</artwork>
        </figure>
        is mapped to the following RELAX NG pattern:
        <figure>
          <artwork>
    <![CDATA[<rng:optional>
      <rng:attribute name="PREFIX:ARGUMENT">
        ...
      </rng:attribute>
    </rng:optional>]]></artwork>
        </figure>
        where PREFIX is the prefix bound to the namespace URI of the
        YANG module that contains the "md:annotation" statement. The
        above pattern SHALL be inserted as a child of the named
        pattern described in item <xref target="it.npdef"
        format="counter"/>.</t>
        <t>Substatements of "md:annotation" SHALL be mapped to
        children of the "rng:attribute" pattern exactly as described
        in sec. 10 of <xref target="RFC6110"/>.</t>
      </list></t>
      <t>For example, the named pattern (item <xref target="it.npdef"
      format="counter"/>), when constructed only for the
      "last-modified" annotation, will have the following
      definition:</t>
      <figure>
        <artwork>
<![CDATA[<rng:define name="__yang_metadata__">
  <rng:optional>
    <rng:attribute name="elm:last-modified">
      <rng:ref name="ietf-yang-types__date-and-time"/>
    </rng:attribute>
  </rng:optional>
</rng:define>]]></artwork>
      </figure>
      <t>Every "rng:element" pattern that corresponds to an anydata,
      container, leaf, list or leaf-list data node will then contain a
      reference to the above named pattern, for example</t>
      <figure>
        <artwork>
<![CDATA[<rng:element name="foo:bar">
  <rng:ref name="__yang_metadata__"/>
  ...
</rng:element>]]></artwork>
      </figure>
      <t>Note that it is not necessary to use such a reference for
      "rng:element" patterns corresponding to anyxml data nodes
      because they already permit any XML attributes to be attached to
      their instances.</t>
      <t>The second step of the DSDL mapping procedure, i.e., the
      transformation of the hybrid schema to RELAX NG, Schematron and
      DSRL schemas, is unaffected by the inclusion of
      "md:annotation".</t>
    </section> 

    <section anchor="ietf-yang-metadata" title="Metadata YANG Module">

      &ed-hint-fill-in;

      <t>RFC Editor: Also please replace all occurrences of
      'RFC 6020bis' with the actual RFC number that will be assigned
      to <xref target="I-D.ietf-netmod-rfc6020bis"/>.</t>
      <figure>
        &ietf-yang-metadata.yang;
      </figure>

    </section>

    <section anchor="iana" title="IANA Considerations">

      &ed-hint-fill-in;

      <t>This document registers a URI in the "IETF XML registry"
      <xref target="RFC3688"/>. Following the format in RFC 3688, the
      following registration has been made.</t>
      <figure>
        <artwork>
---------------------------------------------------------------------
URI: urn:ietf:params:xml:ns:yang:ietf-yang-metadata

Registrant Contact: The NETMOD WG of the IETF.

XML: N/A, the requested URI is an XML namespace.
---------------------------------------------------------------------
        </artwork>
      </figure>

      <t>This document registers a YANG module in the "YANG Module
      Names" registry <xref target="RFC6020"/>.</t>

      <figure>
        <artwork>
---------------------------------------------------------------------
name:         ietf-yang-metadata
namespace:    urn:ietf:params:xml:ns:yang:ietf-yang-metadata
prefix:       md
reference:    RFC XXXX
---------------------------------------------------------------------
        </artwork>
      </figure>

    </section>

    <section anchor="security" title="Security Considerations">

      <t>This document introduces a mechanism for defining metadata
      annotations in YANG modules and attaching them to instances of
      YANG data nodes. By itself, this mechanism represents no
      security threat. Security implications of a particular
      annotation defined using this mechanism MUST be duly
      considered and documented in the the annotation's
      definition.</t>
      <t>An annotation SHOULD be subject to the same or stricter
      access control rules as the data node instance to which the
      annotation is attached.</t>

    </section>

    <section anchor="sec.ack" title="Acknowledgments">
      <t>The author wishes to thank Andy Bierman, Martin Bjorklund,
      Benoit Claise, Juergen Schoenwaelder, and Kent Watsen for their
      helpful comments and suggestions.</t>
    </section>

  </middle>

  <back>
    <references title="Normative References">
      &I-D.ietf-netmod-rfc6020bis;
      &I-D.ietf-netmod-yang-json;
      &RFC2119;
      &RFC3688;
      &RFC5234;
      &RFC6020;
      &RFC6110;
      &RFC7159;
      &W3C.REC-xml-infoset-20040204;
      &W3C.REC-xml-names11-20060816;
    </references>

    <references title="Informative References">
      <reference anchor="ISO.19757-1">
        <front>
          <title>
            Document Schema Definition Languages (DSDL) - Part 1: Overview
          </title>
          <author>
            <organization>International Organization for Standardization</organization>
          </author>
          <date day="14" month="November" year="2004"/>
        </front>
        <seriesInfo name="ISO/IEC" value="19757-1"/>
        <format type="PDF" target="http://www.dsdl.org/0567.pdf"/>
      </reference>
      &I-D.ietf-netconf-restconf;
      &RFC6241;
    </references>

    <section title="Change Log">

      &ed-hint-remove-sec;

      <section title="Changes Between Revisions -05 and -06">
        <t>
          <list style="symbols">
	    <t>Added explanation of why a YANG extension is used
	    rather than a built-in statement.</t>
	  </list>
	</t>
      </section>

      <section title="Changes Between Revisions -04 and -05">
        <t>
          <list style="symbols">
	    <t>Clarification regarding the type of an annotation.</t>
	  </list>
	</t>
      </section>

      <section title="Changes Between Revisions -03 and -04">
        <t>
          <list style="symbols">
	    <t>Added explanation of what "top level of a module"
	    means.</t>
	  </list>
	</t>
      </section>

      <section title="Changes Between Revisions -02 and -03">
        <t>
          <list style="symbols">
            <t><xref target="usage"/> was considerably simplified,
            also because member names starting with "@" are now
            permitted by <xref
            target="I-D.ietf-netmod-yang-json"/>.</t>
          </list>
        </t>
      </section>

      <section title="Changes Between Revisions -01 and -02">
        <t>
          <list style="symbols">
            <t>The "type" statement became mandatory.</t>
            <t>Terminology section was extended.</t>
            <t>The annotation "inactive" defined in the
            example module was replaced with "last-modified"
            that is supposedly less controversial.</t>
            <t>Introduction now states limitation due to XML attribute
            properties.</t>
            <t>A recommendation was added to define annotations in a
            module by themselves.</t>
            <t>Section "Using Annotations" was added.</t>
            <t>An example for "anyxml" was added.</t>
            <t>RFC 6241 was moved to informative references.</t>
          </list>
        </t>
      </section>

      <section title="Changes Between Revisions -00 and -01">
        <t>
          <list style="symbols">
            <t>Define JSON encoding for annotations attached to 'anydata' nodes.</t>
          </list>
        </t>
      </section>
      <section title="Changes Between draft-lhotka-netmod-yang-metadata-01 and draft-ietf-netmod-yang-metadata-00">
        <t>
          <list style="symbols">
            <t>References to RFC 6020 were changed to the 6020bis
            I-D.</t>
            <t>Text about RFC 2119 key words was added to
            "ietf-yang-metadata" module description.</t>
          </list>
        </t>
      </section>

      <section title="Changes Between draft-lhotka-netmod-yang-metadata-00 and -01">
        <t>
          <list style="symbols">
            <t>Encoding of annotations for anyxml nodes was changed to
            be the same as for leafs. This was necessary because
            anyxml value now needn't be an object.</t>
            <t>It is stated that "md:annotation" statement defines
            only the syntax of an annotation.</t>
            <t>Allowed "if-feature" as a substatement of
            "md:annotation".</t>
          </list>
        </t>
      </section>

    </section>

  </back>
</rfc>