RFC 7952

Defining and Using Metadata with YANG

📅 published August 2016, from ietf

RFC 7952: Defining and Using Metadata with YANG 🎀

okay bestie, this one is all about metadata annotations for YANG data. Here's the title block tea ☕:

  • Number and title: RFC 7952, Defining and Using Metadata with YANG
  • Author: L. Lhotka, from CZ.NIC
  • Date: August 2016
  • Category: Standards Track (the real deal, not just an experiment 💅)
  • ISSN: 2070-1721
  • Updates: RFC 6110 🌸

Abstract

this doc defines a YANG extension that lets you define metadata annotations inside YANG modules ✨ it also spells out how to encode those annotations in XML and JSON, plus the rules for annotating instances of YANG data nodes. it's giving organisation 🗂️

Status of This Memo

this is an Internet Standards Track document 🔥

it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more info on Internet Standards, check Section 2 of RFC 7841 🧚

for the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7952 🦋

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

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. please actually read these, bestie, because they explain your rights and restrictions for this document 🙈 any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License ⭐

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
  2.1.  Key Words . . . . . . . . . . . . . . . . . . . . . . . .   5
  2.2.  Terms Defined in Other Documents  . . . . . . . . . . . .   5
  2.3.  Namespaces and Prefixes . . . . . . . . . . . . . . . . .   7
  2.4.  Definitions of New Terms  . . . . . . . . . . . . . . . .   7
3.  Defining Annotations in YANG  . . . . . . . . . . . . . . . .   8
  3.1.  Example Definition  . . . . . . . . . . . . . . . . . . .   9
4.  Using Annotations . . . . . . . . . . . . . . . . . . . . . .   9
5.  The Encoding of Annotations . . . . . . . . . . . . . . . . .  10
  5.1.  XML Encoding  . . . . . . . . . . . . . . . . . . . . . .  10
  5.2.  JSON Encoding . . . . . . . . . . . . . . . . . . . . . .  11
    5.2.1.  Metadata Object and Annotations . . . . . . . . . . .  11
    5.2.2.  Adding Annotations to anydata, container, and list
            Entries . . . . . . . . . . . . . . . . . . . . . . .  12
    5.2.3.  Adding Annotations to anyxml and leaf Instances . . .  12
    5.2.4.  Adding Annotations to leaf-list Entries . . . . . . .  13
6.  Representing Annotations in DSDL Schemas  . . . . . . . . . .  14
7.  Metadata YANG Module  . . . . . . . . . . . . . . . . . . . .  16
8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
9.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
  10.1.  Normative References . . . . . . . . . . . . . . . . . .  19
  10.2.  Informative References . . . . . . . . . . . . . . . . .  20
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  21
Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  21

1. Introduction ✨

there's a real need to be able to annotate instances of YANG [RFC7950] data nodes with metadata 🧁 the typical use cases look like this:

  • Complementing regular data model information with instance-specific metadata, comments, etc. 💬
  • Providing information about the rendering of data in user interfaces. 🎨
  • Deactivating a subtree in a configuration datastore while keeping the data in place. 🫧
  • Network management protocols often use metadata annotations for various purposes in both operation requests and responses. For example, the <edit-config> operation in the Network Configuration Protocol (NETCONF) (see Section 7.2 of [RFC6241]) uses annotations in the form of XML attributes to identify the location in a configuration datastore and the type of the operation 🌈

but ngl, metadata annotations could cause interoperability problems if different parties use them in an ad hoc way or without proper documentation 😭 so a solid metadata framework for YANG should meet these requirements:

  1. The set of annotations must be extensible in a decentralized manner, so that new annotations can be defined without running the risk of collisions with annotations defined and used by others. 🧩
  2. The 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 [RESTCONF] must be able to discover all annotations supported by a given server and identify each of them correctly. 🔍
  4. Annotations sent by a server should not break clients that don't support them. 🫶

this document proposes a systematic way to define metadata annotations 💅 the YANG extension "annotation" is defined in the module "ietf-yang-metadata" (Section 7), and other YANG modules that import this module can use the "annotation" statement to define one or more annotations.

defining metadata annotations in a YANG module has some major perks:

  • 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. 🎀
  • Annotations defined in IETF Standards Track documents are indirectly registered through IANA in the "YANG Module Names" registry [RFC6020]. 🗂️
  • Annotations are included in the data model. YANG compilers and tools that support a certain annotation can take them into account and modify their behavior accordingly. 🛠️
  • The semantics of an annotation are defined in the "description" and "reference" statements. 📝
  • An annotation can be declared as conditional by using the "if-feature" statement. 🎛️
  • 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. 🔢

in the XML encoding, XML attributes are a natural tool for attaching annotations to data node instances 🧚 this document deliberately adopts some restrictions so it stays compatible with the XML encoding of YANG data node instances and with the limitations of XML attributes. specifically:

  • annotations can only be scalar values. 🔹
  • annotations cannot be attached to a whole list or leaf-list instance, only to individual list or leaf-list entries. 🔸
due to the rules for YANG extensions (see Section 6.3.1 in [RFC7950]), annotation definitions carry relatively weak conformance requirements. the alternative, a new built-in YANG statement for defining annotations, was considered. it was seen as a major change to the language, which is inappropriate for YANG 1.1 since that was chartered as a maintenance revision. after evaluating real-life usage of metadata annotations, it's conceivable that such a new built-in statement might be added in a future revision of YANG 🔮

2. Terminology 🌸

2.1. Key Words

okay so 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] 🫶

2.2. Terms Defined in Other Documents

here's the glossary you need, sorted by where each term comes from 📖

the following terms are defined in [RFC6241]:

  • capability
  • client
  • datastore
  • message
  • protocol operation
  • server

the following terms are defined in [RFC7950]:

  • action
  • anydata
  • anyxml
  • built-in type
  • container
  • data model
  • data node
  • data tree
  • derived type
  • extension
  • leaf
  • leaf-list
  • list
  • module
  • Remote Procedure Call (RPC) input and output

the following terms are defined in [XML-INFOSET]:

  • attribute
  • document
  • element

the following terms are defined in [XML-NAMES]:

  • local name
  • namespace name
  • prefix
  • qualified name

the following terms are defined in [RFC7159]:

  • array
  • member
  • object
  • primitive type

2.3. Namespaces and Prefixes 🏷️

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

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

Table 1: Used Namespace Prefixes and Corresponding URI References

2.4. Definitions of New Terms 🍓

  • annotation: a single item of metadata that is attached to YANG data node instances. 🧷
  • metadata: additional information that complements a data tree. 🧠
  • metadata object: an object in JSON encoding that contains all annotations attached to a given data node instance. 🗃️

3. Defining Annotations in YANG ✨

Okay so metadata annotations get defined with the YANG extension "md:annotation" 🎀. That extension lives in the module "ietf-yang-metadata", which you'll find in Section 7.

The substatements of "md:annotation" are listed in Table 2 💅. They're all core YANG statements, and the second column tells you which section of [RFC7950] describes each one.

+--------------+---------------------+-------------+
| substatement | section in RFC 7950 | cardinality |
+--------------+---------------------+-------------+
| description  | 7.21.3              | 0..1        |
| if-feature   | 7.20.2              | 0..n        |
| reference    | 7.21.4              | 0..1        |
| status       | 7.21.2              | 0..1        |
| type         | 7.6.3               | 1           |
| units        | 7.3.3               | 0..1        |
+--------------+---------------------+-------------+

      Table 2: Substatements of "md:annotation"

An annotation carries a single value 🦋. The "type" substatement MUST be present. It takes the name of an existing built-in or derived type as its argument, and the value of the annotation MUST match that type. See Section 7.4 of [RFC7950] for details.

An annotation can be made conditional with one or more "if-feature" statements. That means only servers that advertise the matching feature will support it 🌸.

The semantics and usage rules for an annotation SHOULD be fully specified in "description", "reference", and "units" statements 💜.

An annotation MUST NOT change the data tree semantics defined by YANG 🙅. For example, it is illegal to define and use an annotation that allows for overriding uniqueness of leaf-list entries 💀.

The "status" statement works exactly the same way it does for YANG data nodes 🧚.

A YANG module that contains one or more "md:annotation" 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 🙈.

3.1. Example Definition

The following module defines the "last-modified" annotation 🌈:

module example-last-modified {
  namespace "http://example.org/example-last-modified";
  prefix "elm";
  import ietf-yang-types {
    prefix "yang";
  }
  import ietf-yang-metadata {
    prefix "md";
  }
  md:annotation last-modified {
    type yang:date-and-time;
    description
      "This annotation contains the date and time when the
       annotated instance was last modified (or created).";
  }
}

4. Using Annotations

Here's the vibe: when a server advertises a YANG module that defines a metadata annotation with "md:annotation", it's basically saying "yep, I can handle this annotation according to how it's defined" 🫶. An annotation the server advertises may be attached to an instance of a data node defined in any YANG module that the server implements.

Depending on what it means, an annotation may only have an effect in 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 the server didn't advertise it 🛑.

Be careful when you introduce annotations into network management systems 😭. You want to avoid interoperability problems and software failures caused by a client that doesn't understand what the annotations mean. In general, it's safe for a server to use annotations in these cases:

  • An annotation is an integral part of a built-in or negotiated protocol capability.
  • An annotation contains auxiliary information that is not critical for protocol operation.
  • The client explicitly asks the server, e.g., via a parameter of a protocol operation request, to include an annotation in the response.

5. The Encoding of Annotations

XML attributes are the natural pick for encoding metadata in XML instance documents 🌸. JSON [RFC7159] doesn't have a generally established way to encode metadata, though. So this document introduces a special encoding method that stays consistent with the JSON encoding of YANG data node instances defined in [RFC7951] ✨.

5.1. XML Encoding

Metadata annotations get added to XML-encoded instances of YANG data nodes as XML attributes, following these rules 💖:

  • The local name of the attribute SHALL be the same as the name of the annotation given in the argument of the corresponding "md:annotation" statement.
  • 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 be used in the qualified name of the attribute.
  • The attribute value SHALL be encoded in the same way as the value of a YANG leaf instance having the same type; see Section 9 of [RFC7950].

For example, the "last-modified" annotation from Section 3.1 may be encoded like this 🦋:

<foo xmlns:elm="http://example.org/example-last-modified"
     elm:last-modified="2015-09-16T10:27:35+02:00">
  ...
</foo>

5.2. JSON Encoding

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

  1. The encoding of YANG data node instances as defined in [RFC7951] does not change.
  2. Namespaces of metadata annotations are encoded in the same way as namespaces of YANG data node instances; see [RFC7951].

5.2.1. Metadata Object and Annotations

All the metadata annotations assigned to a YANG data node instance get encoded as members (name/value pairs) of a single JSON object, which we'll call the metadata object 🧁. Where this object goes and what it's named depends on the type of the data node, as the following subsections explain.

The name of a metadata annotation (as a member of the metadata object) follows this ABNF syntax [RFC5234], where the "identifier" production is defined in Section 14 of [RFC7950] 📐:

annotation-name = identifier ":" identifier

The left identifier is the name of the YANG module where the annotation is defined. The identifier on the right is the name of the annotation given in the argument of the corresponding "md:annotation" statement.

Note that unlike member names of YANG data node instances in JSON encoding (see Section 4 in [RFC7951]), the explicit namespace identifier (module name) must always be present for annotations 👑.

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 Section 6 of [RFC7951].

5.2.2. Adding Annotations to anydata, container, and list Entries

For a data node instance that gets encoded as a JSON object (so, a container, list entry, or anydata node), the metadata object is added as a new member of that object with the name "@" 💅.

Examples:

  • "cask" is a container or anydata node:
"cask": {
  "@": {
    "example-last-modified:last-modified":
      "2015-09-16T10:27:35+02:00"
  },
  ...
}
  • "seq" is a list whose key is "name"; the annotation "last-modified" is added only to the first entry:
"seq": [
  {
    "@": {
      "example-last-modified:last-modified":
          "2015-09-16T10:27:35+02:00"
    },
    "name": "one",
    ...
  },
  {
    "name": "two",
    ...
  }
]

5.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. Its name is the symbol "@" joined with the name of the leaf or anyxml member being annotated. The namespace part (module name) is included if and only if it appears in the name of the annotated member 🌟.

Examples:

  • "flag" is a leaf node of the "boolean" type defined in module "foo", and we're assuming the namespace name needs to be expressed in its JSON encoding:
"foo:flag": true,
"@foo:flag": {
  "example-last-modified:last-modified":
    "2015-09-16T10:27:35+02:00"
}
  • "stuff" is an anyxml node:
"stuff": [1, null, "three"],
"@stuff": {
  "example-last-modified:last-modified":
    "2015-09-16T10:27:35+02:00"
}

5.2.4. Adding Annotations to leaf-list Entries

A leaf-list entry is represented as a JSON array with values of a primitive type 📚. Annotations can be assigned to one or more entries by adding a name/array pair as a sibling of the leaf-list entry. The name is the symbol "@" joined with the name of the leaf-list being annotated. The value is a JSON array whose i-th element is the metadata object with the annotations assigned to the i-th entry of the leaf-list, or null if the i-th entry has no annotations.

Trailing null values in that array, meaning the ones after the last non-null metadata object, MAY be omitted 🙃.

For example, here's a leaf-list instance with four entries where the "last-modified" annotation gets added to the second and third entries 🍒:

"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"
  }
]

6. Representing Annotations in DSDL Schemas ✨

okay so [RFC6110] is the one that defines the standard mapping from YANG data models to Document Schema Definition Languages (DSDL) [ISO.19757-1] 🦋 this section is the bit that covers the mapping for the extension statement "md:annotation" (Section 7), which lets you validate XML instance documents that carry metadata annotations 💅

The first step of the DSDL mapping procedure is turning the YANG data model into the hybrid schema (see Section 6 in [RFC6110]). For this part, the process gets a few tweaks:

  1. If the data model has at least one "md:annotation" statement, then a RELAX NG [ISO.19757-2] named pattern definition RECOMMENDED to be named "__yang_metadata__" gets added as a child of the root <rng:grammar> element in the hybrid schema. It MUST be added, so the named pattern is always there when it's needed 🫶
  2. A reference to the named pattern from item 1 MUST be included as a child of every <rng:element> pattern that matches an anydata, container, leaf, leaf-list, or list data node. no skipping allowed, bestie 🔥
  3. Every metadata annotation definition written like the block below gets mapped to the RELAX NG [ISO.19757-2] pattern shown after it:
md:annotation ARGUMENT {
  ...
}
<rng:optional>
  <rng:attribute name="PREFIX:ARGUMENT">
    ...
  </rng:attribute>
</rng:optional>

Here PREFIX is the prefix bound to the namespace URI of the YANG module that contains the "md:annotation" statement. This pattern SHALL be inserted as a child of the named pattern from item 1 🌸

  1. Substatements of "md:annotation" SHALL be mapped to children of the "rng:attribute" pattern, done exactly as described in Section 10 of [RFC6110] 💜

For example, if you only build the named pattern (item 1) for the "last-modified" annotation, it ends up looking like this:

<rng:define name="__yang_metadata__">
  <rng:optional>
    <rng:attribute name="elm:last-modified">
      <rng:ref name="ietf-yang-types__date-and-time"/>
    </rng:attribute>
  </rng:optional>
</rng:define>

Every "rng:element" pattern that matches an anydata, container, leaf, list, or leaf-list data node then holds a reference to that named pattern. Like so:

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

Quick aside: you don't need that reference for "rng:element" patterns that match anyxml data nodes 🙈 they already allow any XML attributes on their instances, so they're covered already.

The second step of the DSDL mapping procedure is turning the hybrid schema into RELAX NG [ISO.19757-2], Schematron [ISO.19757-3], and Document Semantics Renaming Language (DSRL) [ISO.19757-8] schemas. Adding "md:annotation" doesn't change anything here at all ✨

7. Metadata YANG Module

Here's the YANG module itself, copied exactly as it is in the spec 💖

<CODE BEGINS> file "ietf-yang-metadata@2016-08-05.yang"

module ietf-yang-metadata {

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

  prefix "md";

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

  contact
    "WG Web:   <https://datatracker.ietf.org/wg/netmod/>

     WG List:  <mailto:netmod@ietf.org>

     WG Chair: Lou Berger
               <mailto:lberger@labn.net>

     WG Chair: Kent Watsen
               <mailto:kwatsen@juniper.net>

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

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

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

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

     This version of this YANG module is part of RFC 7952
     (http://www.rfc-editor.org/info/rfc7952); see the RFC itself
     for full legal notices.";

  revision 2016-08-05 {
    description
      "Initial revision.";
    reference
      "RFC 7952: Defining and Using Metadata with YANG";
  }

  extension annotation {
    argument name;
    description
      "This extension allows for defining metadata annotations in
       YANG modules.  The 'md:annotation' statement can appear only
       at the top level of a YANG module or submodule, i.e., it
       becomes a new alternative in the ABNF production rule for
       'body-stmts' (Section 14 in RFC 7950).

       The argument of the 'md:annotation' statement defines the name
       of the annotation.  Syntactically, it is a YANG identifier as
       defined in Section 6.2 of RFC 7950.

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

       The data type of the annotation value is specified in the same
       way as for a leaf data node using the 'type' statement.

       The semantics of the annotation and other documentation can be
       specified using the following standard YANG substatements (all
       are optional): 'description', 'if-feature', 'reference',
       'status', and 'units'.

       A server announces support for a particular annotation by
       including the module in which the annotation is defined among
       the advertised YANG modules, e.g., in a NETCONF <hello>
       message or in the YANG library (RFC 7950).  The annotation can
       then be attached to any instance of a data node defined in any
       YANG module that is advertised by the server.

       XML encoding and JSON encoding of annotations are defined in
       RFC 7952.";
  }
}

<CODE ENDS>

8. IANA Considerations

This doc registers a URI in the "IETF XML Registry" [RFC3688]. Following the format in RFC 3688, the registration below has been made 📝

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

Registrant Contact: The NETMOD WG of the IETF.

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

This doc also registers a YANG module in the "YANG Module Names" registry [RFC6020] 🍓

---------------------------------------------------------------------
Name:         ietf-yang-metadata
Namespace:    urn:ietf:params:xml:ns:yang:ietf-yang-metadata
Prefix:       md
Reference:    RFC 7952
---------------------------------------------------------------------

9. Security Considerations

okay this one is SERIOUS, bestie 😭🔒 This doc introduces a mechanism for defining metadata annotations in YANG modules and attaching them to instances of YANG data nodes. By itself, the mechanism represents no security threat. However, the security implications of any particular annotation defined with it MUST be duly considered and documented in that annotation's definition 💀

An annotation SHOULD be subject to the same or stricter access control rules as the data node instance it's attached to 🛡️ It is RECOMMENDED that security-sensitive or privacy-sensitive data be modeled as regular YANG data nodes rather than annotations, so keep your secrets out of the annotation lane 🔐

10. References

10.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
           DOI 10.17487/RFC3688, January 2004,
           <http://www.rfc-editor.org/info/rfc3688>.

[RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
           Specifications: ABNF", STD 68, RFC 5234,
           DOI 10.17487/RFC5234, January 2008,
           <http://www.rfc-editor.org/info/rfc5234>.

[RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
           the Network Configuration Protocol (NETCONF)", RFC 6020,
           DOI 10.17487/RFC6020, October 2010,
           <http://www.rfc-editor.org/info/rfc6020>.

[RFC6110]  Lhotka, L., Ed., "Mapping YANG to Document Schema
           Definition Languages and Validating NETCONF Content",
           RFC 6110, DOI 10.17487/RFC6110, February 2011,
           <http://www.rfc-editor.org/info/rfc6110>.

[RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
           Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
           2014, <http://www.rfc-editor.org/info/rfc7159>.

[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
           Edition)", World Wide Web Consortium Recommendation
           REC-xml-infoset-20040204, February 2004,
           <http://www.w3.org/TR/2004/REC-xml-infoset-20040204>.

[XML-NAMES]
           Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
           Thompson, "Namespaces in XML 1.0 (Third Edition)", World
           Wide Web Consortium Recommendation REC-xml-names-20091208,
           December 2009,
           <http://www.w3.org/TR/2009/REC-xml-names-20091208>.

10.2. Informative References

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

[ISO.19757-2]
           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.

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

[ISO.19757-8]
           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.

[RESTCONF] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
           Protocol", Work in Progress,
           draft-ietf-netconf-restconf-16, August 2016.

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

Acknowledgements

big thank yous 🫶 to Andy Bierman, Martin Bjorklund, Benoit Claise, Juergen Schoenwaelder, and Kent Watsen for their helpful comments and suggestions 💜

Author's Address

Ladislav Lhotka CZ.NIC

Email: lhotka@nic.cz 🎀

📦 where this page comes from