Defining and Using Metadata with YANG
draft-ietf-netmod-yang-metadata-00

NETMOD Working Group                                           L. Lhotka
Internet-Draft                                                    CZ.NIC
Intended status: Standards Track                          April 16, 2015
Expires: October 18, 2015

                 Defining and Using Metadata with YANG
                   draft-ietf-netmod-yang-metadata-00

Abstract

   This document defines a YANG extension statement that allows for
   defining syntax of metadata annotions in YANG modules.  The document
   also specifies XML and JSON encoding of annotations and other rules
   for annotating instances of YANG data nodes.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 18, 2015.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Lhotka                  Expires October 18, 2015                [Page 1]
Internet-Draft                YANG Metadata                   April 2015

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Defining Annotations in YANG  . . . . . . . . . . . . . . . .   5
   4.  The Encoding of Annotations . . . . . . . . . . . . . . . . .   7
     4.1.  XML Encoding  . . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  JSON Encoding . . . . . . . . . . . . . . . . . . . . . .   7
       4.2.1.  Metadata Object and Annotations . . . . . . . . . . .   8
       4.2.2.  Adding Annotations to Container and List Instances  .   8
       4.2.3.  Adding Annotations to Anyxml and Leaf Instances . . .   9
       4.2.4.  Adding Annotations to Leaf-list Instances . . . . . .   9
   5.  Representing Annotations in DSDL Schemas  . . . . . . . . . .  10
   6.  Metadata YANG Module  . . . . . . . . . . . . . . . . . . . .  11
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  14
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     10.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  15
     A.1.  Changes Between draft-lhotka-netmod-yang-metadata-01 and
           draft-ietf-netmod-yang-metadata-00  . . . . . . . . . . .  15
     A.2.  Changes Between draft-lhotka-netmod-yang-metadata-00 and
           -01 . . . . . . . . . . . . . . . . . . . . . . . . . . .  16
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   There is a need to be able to annotate instances of
   YANG [I-D.ietf-netmod-rfc6020bis] data nodes with metadata.  Typical
   use cases are:

   o  Deactivating a subtree in a configuration datastore while keeping
      the data in place.

   o  Complementing data model information with instance-specific data.

   o  RPC operations may use metadata annotations for various purposes
      in both requests and responses.  For example, the <edit-config>
      operation in the NETCONF protocol (see section 7.2 of [RFC6241])
      uses annotations in the form of XML attributes for identifying the
      point in the configuration and type of the operation.

   However, metadata annotations could potentially lead to
   interoperability problems if they are used in an ad hoc fashion by
   different organizations and/or without proper documentation.  A sound

Lhotka                  Expires October 18, 2015                [Page 2]
Internet-Draft                YANG Metadata                   April 2015

   metadata framework for YANG should therefore satisfy these
   requirements:

   1.  The set of annotations must be extensible in a distributed manner
       so as to allow for defining new annotations without running into
       the risk of collisions with annotations defined and used by
       others.

   2.  Syntax and semantics of annotations must be documented and the
       documentation must be easily accessible.

   3.  Clients of network management protocols such as NETCONF [RFC6241]
       or RESTCONF [I-D.ietf-netconf-restconf] must be able to learn all
       annotations supported by a given server and identify each of them
       correctly.

   This document proposes a systematic way for defining the syntax of
   metadata annotations.  For this purpose, YANG extension statement
   "annotation" is defined in the module "ietf-yang-metadata"
   (Section 6).  Other YANG modules importing this module can use the
   "annotation" statement for defining the syntax of one or more
   annotations.

   The benefits of defining the syntax of metadata annotations in a YANG
   module are the following:

   o  Each annotation is bound to a YANG module name, namespace URI and
      prefix.  This makes its encoding in instance documents (both XML
      and JSON) straightforward and consistent with the encoding of YANG
      data node instances.

   o  Annotations are indirectly registered through IANA YANG module
      registration.

   o  Annotations are included in the data model.  YANG compilers and
      tools supporting a certain annotation can thus take them into
      account and modify their behaviour accordingly.

   o  An annotation can be declared as conditional by using the "if-
      feature" statement.

   o  Values of annotations are not limited to strings; any YANG built-
      in or derived type may be used for them.

Lhotka                  Expires October 18, 2015                [Page 3]
Internet-Draft                YANG Metadata                   April 2015

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   The following terms are defined in [RFC6241]:

   o  client,

   o  datastore,

   o  message,

   o  operation,

   o  server.

   The following terms are defined in [I-D.ietf-netmod-rfc6020bis]:

   o  anyxml,

   o  built-in type,

   o  derived type,

   o  container,

   o  data model,

   o  data node,

   o  derived type,

   o  extension,

   o  leaf-list,

   o  list,

   o  module,

   o  RPC operation,

   o  submodule,

   o  type.

Lhotka                  Expires October 18, 2015                [Page 4]
Internet-Draft                YANG Metadata                   April 2015

   The following terms are defined in [W3C.REC-xml-infoset-20040204]:

   o  attribute,

   o  document,

   o  element,

   o  namespace,

   o  prefix.

   The following terms are defined in [RFC7159]:

   o  array,

   o  member,

   o  object,

   o  primitive type.

   In the following text, XML element names and YANG extension
   statements are always written with explicit namespace prefixes that
   are assumed to be bound to URI references as shown in Table 1.

        +--------+------------------------------------------------+
        | Prefix | URI Reference                                  |
        +--------+------------------------------------------------+
        | rng    | http://relaxng.org/ns/structure/1.0            |
        | md     | urn:ietf:params:xml:ns:yang:ietf-yang-metadata |
        | ein    | http://example.org/example-inactive            |
        +--------+------------------------------------------------+

     Table 1: Used namespace prefixes and corresponding URI references

3.  Defining Annotations in YANG

   Metadata annotations are defined by YANG extension statement
   "md:annotation".  This YANG language extension is defined in the
   module "ietf-yang-metadata" (Section 6).

   Substatements of "md:annotation" are shown in Table 2.  They are all
   core YANG statements, and the numbers in the second column refer to
   the corresponding sections in [I-D.ietf-netmod-rfc6020bis] where each
   statement is described.

Lhotka                  Expires October 18, 2015                [Page 5]
Internet-Draft                YANG Metadata                   April 2015

           +--------------+---------------------+-------------+
           | substatement | RFC 6020bis section | cardinality |
           +--------------+---------------------+-------------+
           | description  | 7.20.3              | 0..1        |
           | if-feature   | 7.19.2              | 0..n        |
           | reference    | 7.20.4              | 0..1        |
           | status       | 7.20.2              | 0..1        |
           | type         | 7.6.3               | 0..1        |
           | units        | 7.3.3               | 0..1        |
           +--------------+---------------------+-------------+

                Table 2: Substatements of "md:annotation".

   Using the "type" statement, a type may be specified for the
   annotation value according to the same rules as for YANG leaf or
   leaf-list types.  However, the "type" statement is optional as a
   substatement of "md:annotation" statement.  If it is not present, the
   built-in "string" type is the default.

   The "if-feature" statement, if present, makes the annotation
   conditional: it is supported only by servers that advertise the
   corresponding feature.

   For example, the following module defines the "inactive" annotation:

   module example-inactive {
     namespace "http://example.org/example-inactive";
     prefix "ein";
     import ietf-yang-metadata {
       prefix "md";
     }
     md:annotation inactive {
       type boolean;
       description
         "If this annotation is attached to a configuration data node,
          then the data subtree rooted at this node is deactivated.";
     }
   }

   By advertising a YANG module in which metadata annotation A is
   defined using the "md:annotation" statement, a server specifies
   support for the syntax of annotation A.  This means that
   configuration or state data, RPC messages and notifications will be
   considered syntactically valid if annotation A is attached to any
   data node instance, provided that all rules stated in this document
   are observed.

Lhotka                  Expires October 18, 2015                [Page 6]
Internet-Draft                YANG Metadata                   April 2015

   However, the semantics of an annotation, usage rules, and expected
   behavior of clients and servers MUST be specified separately by other
   means that are outside the scope of this document.

4.  The Encoding of Annotations

   XML attributes are a natural choice for encoding metadata in XML
   instance documents.  For JSON [RFC7159], there is no generally
   established method for encoding metadata.  This document thus
   introduces a special encoding method that is consistent with the JSON
   encoding of YANG data node instances as defined
   in [I-D.ietf-netmod-yang-json].

4.1.  XML Encoding

   Metadata annotations are added to XML-encoded instances of YANG data
   nodes as XML attributes according to these rules:

   o  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.

   o  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.

   o  The attribute value SHALL be encoded in the same way as the value
      of a YANG leaf instance having the same type,
      see [I-D.ietf-netmod-rfc6020bis], sec. 9.

   For example, the "inactive" annotation defined in Section 3 may be
   encoded as follows:

   <foo xmlns:ein="http://example.org/example-inactive"
        ein:inactive="true">
     ...
   </foo>

4.2.  JSON Encoding

   The JSON metadata encoding defined in this section has the following
   properties:

   1.  The encoding of YANG data node instances as defined in
       [I-D.ietf-netmod-yang-json] does not change.

Lhotka                  Expires October 18, 2015                [Page 7]
Internet-Draft                YANG Metadata                   April 2015

   2.  Namespaces of metadata annotations are encoded in the same way as
       namespaces of YANG data node instances, see
       [I-D.ietf-netmod-yang-json].

4.2.1.  Metadata Object and Annotations

   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.

   The name of a metadata annotation (as a member of the metadata
   object) SHALL be of the following form:

   MODULE_NAME:LOCAL_NAME

   where MODULE_NAME is the name of the YANG module in which the
   annotation is defined, and LOCAL_NAME is the name of the annotation
   specified in the argument of the corresponding "md:annotation"
   statement.

   Note that unlike YANG data node instances, for annotations the
   explicit namespace identifier (MODULE_NAME) must always be used.

   The value of a metadata annotation SHALL be encoded in exactly the
   same way as the value of a YANG leaf node having the same type as the
   annotation, see [I-D.ietf-netmod-yang-json], sec. 6.

4.2.2.  Adding Annotations to Container and List Instances

   For an instance that is encoded as a JSON object (i.e., a container
   or list entry), the metadata object is added as a new member of that
   object with the name "@".

   Examples:

   o  "cask" is a container node:

   "cask": {
     "@": {
       "example-inactive:inactive": true
     },
     ...
   }

   o  "seq" is a list whose key is "name", annotation "inactive" is
      added only to the first entry:

Lhotka                  Expires October 18, 2015                [Page 8]
Internet-Draft                YANG Metadata                   April 2015

   "seq": [
     {
       "@": {
         "example-inactive:inactive": true
       },
       "name": "one",
       ...
     },
     {
       "name": "two",
       ...
     }
   ]

4.2.3.  Adding Annotations to Anyxml and Leaf Instances

   For an anyxml or leaf instance, the metadata object is added as a
   sibling name/value pair whose the name is the symbol "@" concatenated
   with the name of the leaf or anyxml member that is being annotated.

   For example, if "flag" is a leaf node of the "boolean" type:

   "flag": true,
   "@flag": {
     "example-inactive:inactive": true
   }

4.2.4.  Adding Annotations to Leaf-list Instances

   For a leaf-list instance, 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 instance, 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 instance, or null if the
   i-th entry has no annotations.

   Trailing null values in that array, i.e., those following the last
   non-null metadata object, MAY be omitted.

   For example, in the following leaf-list instance with four entries,
   the "inactive" annotation is added to the second and third entry in
   the following way:

Lhotka                  Expires October 18, 2015                [Page 9]
Internet-Draft                YANG Metadata                   April 2015

   "bibliomod:folio": [6, 3, 7, 8],
   "@bibliomod:folio": [
     null,
     {"example-inactive:inactive": true},
     {"example-inactive:inactive": true}
   ]

5.  Representing Annotations in DSDL Schemas

   [RFC6110] defines the standard mapping of YANG data models to
   Document Schema Definition Languages (DSDL) [ISO.19757-1].  This
   section specifies the mapping for the extension statement
   "md:annotation" (Section 6), which enables validation of XML instance
   documents containing metadata annotations.

   The first step of the DSDL mapping procedure, i.e., the
   transformation of the YANG data model to the hybrid schema (see
   sec. 6 in [RFC6110]), is modified as follows:

   1.  If the data model contains at least one "md:annotation"
       statement, then a RELAX NG named pattern definition MUST be added
       as a child of the root <rng:grammar> element in the hybrid
       schema.  It is RECOMMENDED to use the name "__yang_metadata__"
       for this named pattern.

   2.  A reference to the named pattern described in item 1 MUST be
       included as a child of every <rng:element> pattern that
       corresponds to a container, leaf, list or leaf-list data node.

   3.  Every metadata annotation definition in the form

       md:annotation ARGUMENT;

       or

       md:annotation ARGUMENT {
         ...
       }

       is mapped to the following RELAX NG pattern:

       <rng:attribute name="PREFIX:ARGUMENT">
         ...
       </rng:attribute>

       where PREFIX is the namespace prefix bound to the namespace URI
       of the YANG module that contains the "md:annotation" statement.
       Each "rng:attribute" pattern SHALL be wrapped in the

Lhotka                  Expires October 18, 2015               [Page 10]
Internet-Draft                YANG Metadata                   April 2015

       <rng:optional> pattern, and this SHALL be inserted as a child of
       the named pattern definition described in item 1.

   4.  Substatements of "md:annotation", if there are any, SHALL be
       mapped to children of the "rng:attribute" pattern exactly as
       described in sec. 10 of [RFC6110].

   For example, the named pattern definition (item 1), when constructed
   only for the "inactive" annotation, will have the following form:

   <rng:define name="__yang_metadata__">
     <rng:optional>
       <rng:attribute name="ein:inactive">
         <rng:choice>
           <rng:value>true</rng:value>
           <rng:value>false</rng:value>
         </rng:choice>
       </rng:attribute>
     </rng:optional>
   </rng:define>

   Every "rng:element" pattern that corresponds to a container, leaf,
   list or leaf-list data node will then contain a reference to the
   above named pattern, for example

   <rng:element name="foo:bar">
     <rng:ref name="__yang_metadata__"/>
     ...
   </rng:element>

   Note that it is not necessary to use such a reference for
   "rng:element" patterns corresponding to anyxml data nodes because
   they already permit any XML attributes to be attached to their
   instances.

   The second step of the DSDL mapping procedure, i.e., the
   transformation of the hybrid schema to RELAX NG, Schematron and DSRL
   schemas, is unaffected by the inclusion of "md:annotation".

6.  Metadata YANG Module

   RFC Editor: In this section, replace all occurrences of 'XXXX' with
   the actual RFC number and all occurrences of the revision date below
   with the date of RFC publication (and remove this note).

   <CODE BEGINS> file "ietf-yang-metadata@2015-04-16.yang"

   module ietf-yang-metadata {

Lhotka                  Expires October 18, 2015               [Page 11]
Internet-Draft                YANG Metadata                   April 2015

     namespace "urn:ietf:params:xml:ns:yang:ietf-yang-metadata";

     prefix "md";

     organization
       "IETF NETMOD (NETCONF Data Modeling Language) Working Group";

     contact
       "WG Web:   <http://tools.ietf.org/wg/netmod/>
        WG List:  <mailto:netmod@ietf.org>

        WG Chair: Thomas Nadeau
                  <mailto:tnadeau@lucidvision.com>

        WG Chair: Juergen Schoenwaelder
                  <mailto:j.schoenwaelder@jacobs-university.de>

        Editor:   Ladislav Lhotka
                  <mailto:lhotka@nic.cz>";

     description
       "This YANG module defines an extension statement that allows for
        defining metadata annotations.

        Copyright (c) 2014 IETF Trust and the persons identified as
        authors of the code. All rights reserved.

        Redistribution and use in source and binary forms, with or
        without modification, is permitted pursuant to, and subject to
        the license terms contained in, the Simplified BSD License set
        forth in Section 4.c of the IETF Trust's Legal Provisions
        Relating to IETF Documents
        (http://trustee.ietf.org/license-info).

        The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
        NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and
        'OPTIONAL' in the module text are to be interpreted as described
        in RFC 2119 (http://tools.ietf.org/html/rfc2119).

        This version of this YANG module is part of RFC XXXX
        (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for
        full legal notices.";

     revision 2015-04-16 {
       description
         "Initial revision.";
       reference
         "RFC XXXX: Defining and Using Metadata with YANG";

Lhotka                  Expires October 18, 2015               [Page 12]
Internet-Draft                YANG Metadata                   April 2015

     }

     extension annotation {
       argument name;
       description
         "This extension allows for defining metadata annotations in
          YANG modules. The 'md:annotation' statement can appear only at
          the top level of a YANG module.

          An annotation defined with this extension statement inherits
          the namespace and other context from the YANG module in which
          it is defined.

          Other properties of the annotation and documentation are
          specified using the following standard YANG substatements (all
          are optional): 'description', 'if-feature', 'reference',
          'status', 'type' and 'units'. If the 'type' statement is not
          present, the built-in 'string' type is used by default.

          A server announces syntactic support for a particular
          annotation by including the module in which the annotation is
          defined among the advertised YANG modules (e.g., in NETCONF
          hello message).

          Semantics and usage rules for an annotation MUST be specified
          separately. The 'description' and/or 'reference' statements
          SHOULD provide corresponding links.

          XML and JSON encoding of annotations is defined in
          RFC XXXX.";
     }
   }

   <CODE ENDS>

7.  IANA Considerations

   RFC Editor: In this section, replace all occurrences of 'XXXX' with
   the actual RFC number and all occurrences of the revision date below
   with the date of RFC publication (and remove this note).

   This document registers the following namespace URI in the IETF XML
   registry [RFC3688]:

Lhotka                  Expires October 18, 2015               [Page 13]
Internet-Draft                YANG Metadata                   April 2015

   ---------------------------------------------------------------------
   URI: urn:ietf:params:xml:ns:yang:ietf-yang-metadata

   Registrant Contact: The IESG.

   XML: N/A, the requested URI is an XML namespace.
   ---------------------------------------------------------------------

   This document registers the following YANG module in the YANG Module
   Names registry [I-D.ietf-netmod-rfc6020bis]:

   ---------------------------------------------------------------------
   name:         ietf-yang-metadata
   namespace:    urn:ietf:params:xml:ns:yang:ietf-yang-metadata
   prefix:       md
   reference:    RFC XXXX
   ---------------------------------------------------------------------

8.  Security Considerations

   This document introduces a mechanism for defining the syntax of
   metadata annotations in YANG modules and using them with instances of
   YANG data nodes.  By itself, this mechanism represents no security
   threat.  Security implications of a particular annotation defined
   using this mechanism have to be duly considered and documented in the
   specification of the annotation's semantics.

9.  Acknowledgments

   The author wishes to thank Andy Bierman, Martin Bjorklund and Kent
   Watsen for their helpful comments and suggestions.

10.  References

10.1.  Normative References

   [I-D.ietf-netmod-rfc6020bis]
              Bjorklund, M., "YANG - A Data Modeling Language for the
              Network Configuration Protocol (NETCONF)", draft-ietf-
              netmod-rfc6020bis-04 (work in progress), March 2015.

   [I-D.ietf-netmod-yang-json]
              Lhotka, L., "JSON Encoding of Data Modeled with YANG",
              draft-ietf-netmod-yang-json-03 (work in progress),
              February 2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Lhotka                  Expires October 18, 2015               [Page 14]
Internet-Draft                YANG Metadata                   April 2015

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

   [RFC6110]  Lhotka, L., "Mapping YANG to Document Schema Definition
              Languages and Validating NETCONF Content", RFC 6110,
              February 2011.

   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
              Bierman, "Network Configuration Protocol (NETCONF)", RFC
              6241, June 2011.

   [RFC7159]  Bray, T., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, March 2014.

   [W3C.REC-xml-infoset-20040204]
              Cowan, J. and R. Tobin, "XML Information Set (Second
              Edition)", World Wide Web Consortium Recommendation REC-
              xml-infoset-20040204, February 2004,
              <http://www.w3.org/TR/2004/REC-xml-infoset-20040204>.

10.2.  Informative References

   [I-D.ietf-netconf-restconf]
              Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", draft-ietf-netconf-restconf-04 (work in
              progress), January 2015.

   [ISO.19757-1]
              International Organization for Standardization, "Document
              Schema Definition Languages (DSDL) - Part 1: Overview",
              ISO/IEC 19757-1, November 2004.

Appendix A.  Change Log

   RFC Editor: Remove this section upon publication as an RFC.

A.1.  Changes Between draft-lhotka-netmod-yang-metadata-01 and draft-
      ietf-netmod-yang-metadata-00

   o  References to RFC 6020 were changed to the 6021bis I-D.

   o  Text about RFC 2119 key words was added to "ietf-yang-metadata"
      module description.

Lhotka                  Expires October 18, 2015               [Page 15]
Internet-Draft                YANG Metadata                   April 2015

A.2.  Changes Between draft-lhotka-netmod-yang-metadata-00 and -01

   o  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.

   o  It is stated that "md:annotation" statement defines only the
      syntax of an annotation.

   o  Allowed "if-feature" as a substatement of "md:annotation".

Author's Address

   Ladislav Lhotka
   CZ.NIC

   Email: lhotka@nic.cz

Lhotka                  Expires October 18, 2015               [Page 16]