One document matched: draft-lhotka-netmod-yang-metadata-00.xml
<?xml version="1.0"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="no"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc docName="draft-lhotka-netmod-yang-metadata-00" ipr="trust200902" category="std" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<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 day="11" month="September" year="2014"/>
<area>ops</area>
<workgroup>NETMOD Working Group</workgroup>
<abstract>
<t>This document defines a YANG extension statement that allows
for defining metadata annotions in YANG modules. The document
also specifies the encoding of annotations and rules for
annotating instances of YANG data nodes.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction" toc="default">
<t>There is a need to be able to annotate instances of
YANG <xref target="RFC6020" pageno="false" format="default"/> data nodes with various
metadata. Typical use cases are:
<list style="symbols">
<t>Deactivating a subtree in a configuration datastore while
keeping the data in place.</t>
<t>Qualifying the data model information with
instance-specific data. For example, an annotation may be
attached to an instance of a leaf with the "union" type to
indicate the member type to which the instance belongs.</t>
<t>RPC operations may use metadata annotations for different
purposes in both requests and responses. For example, the
<edit-config> operation in the NETCONF protocol (see
section 7.2 of <xref target="RFC6241" pageno="false" format="default"/>) uses annotations in
the form of XML attributes for identifying the point in the
configuration and 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 way by
different organizations 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 distributed
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" pageno="false" format="default"/> or RESTCONF <xref target="I-D.ietf-netconf-restconf" pageno="false" format="default"/> must be able to learn all
annotations supported by a given server and identify each of
them correctly.</t>
</list></t>
<t>This document proposes a systematic way for defining and
using metadata annotations that satisfies the above
requirements. For this purpose, YANG extension statement
"annotation" is defined in the module "ietf-yang-metadata"
(<xref target="ietf-yang-metadata" pageno="false" format="default"/>). Other YANG modules
importing this module can use the "annotation" statement for
defining one or more annotations.</t>
<t>The benefits of defining metadata annotations in a YANG
module are as follows:
<list style="symbols">
<t>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.</t>
<t>Annotations are indirectly registered through IANA YANG
module registration.</t>
<t>Annotations are included in the data model. Specifically,
servers indicate support for certain annotations using
standard module advertisement methods, such as the
<hello> message in NETCONF.</t>
<t>Values of annotations need not be strings; any YANG
built-in or derived type may be used for them.</t>
</list></t>
</section>
<section anchor="terminology" title="Terminology" toc="default">
<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" pageno="false" format="default"/>.</t>
<t>The following terms are defined in <xref target="RFC6241" pageno="false" format="default"/>:
<list style="symbols">
<t>client,</t>
<t>datastore,</t>
<t>message,</t>
<t>operation,</t>
<t>server.</t>
</list></t>
<t>The following terms are defined in <xref target="RFC6020" pageno="false" format="default"/>:
<list style="symbols">
<t>anyxml,</t>
<t>built-in type,</t>
<t>derived type,</t>
<t>container,</t>
<t>data model,</t>
<t>data node,</t>
<t>derived type,</t>
<t>extension,</t>
<t>leaf-list,</t>
<t>list,</t>
<t>module,</t>
<t>RPC operation,</t>
<t>submodule,</t>
<t>type.</t>
</list></t>
<t>The following terms are defined in <xref target="W3C.REC-xml-infoset-20040204" pageno="false" format="default"/>:
<list style="symbols">
<t>attribute,</t>
<t>document,</t>
<t>element,</t>
<t>namespace,</t>
<t>prefix.</t>
</list></t>
<t>The following terms are defined in <xref target="RFC7159" pageno="false" format="default"/>:
<list style="symbols">
<t>array,</t>
<t>member,</t>
<t>object,</t>
<t>primitive type.</t>
</list></t>
<t>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" pageno="false" format="default"/>.</t>
<texttable anchor="tab.ns" title="Used namespace prefixes and corresponding URI references" suppress-title="false" align="center" style="full">
<ttcol align="left">Prefix</ttcol>
<ttcol align="left">URI Reference</ttcol>
<c>rng</c>
<c>http://relaxng.org/ns/structure/1.0</c>
<c>md</c>
<c>urn:ietf:params:xml:ns:yang:ietf-yang-metadata</c>
<c>ein</c>
<c>http://example.org/example-inactive</c>
</texttable>
</section>
<section anchor="annotdef" title="Defining Annotations in YANG" toc="default">
<t>Metadata annotations are defined with YANG extension
statement "md:annotation". This YANG language extension is
defined in the module "ietf-yang-metadata" (<xref target="ietf-yang-metadata" pageno="false" format="default"/>).</t>
<t>Substatements of "md:annotation" are shown in <xref target="tab.annsub" pageno="false" format="default"/>. They are all core YANG statements, and
the numbers in the second column refer to the corresponding
sections in RFC 6020 <xref target="RFC6020" pageno="false" format="default"/> where each
statement is described.</t>
<texttable anchor="tab.annsub" title="Substatements of "md:annotation"." suppress-title="false" align="center" style="full">
<ttcol align="left">substatement</ttcol>
<ttcol align="left">RFC 6020 section</ttcol>
<ttcol align="left">cardinality</ttcol>
<c>description</c><c>7.19.3</c><c>0..1</c>
<c>reference</c><c>7.19.4</c><c>0..1</c>
<c>status</c><c>7.19.2</c><c>0..1</c>
<c>type</c><c>7.6.3</c><c>0..1</c>
<c>units</c><c>7.3.3</c><c>0..1</c>
</texttable>
<t>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.</t>
<t>For example, the following module defines the "inactive"
annotation:</t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
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,
and its value is 'true', then the server MUST behave
as if the data subtree rooted at this node was not
present.";
}
}
</artwork>
</figure>
<t>Metadata annotations defined with the "md:annotation"
statement may be attached to any valid instance of a data node,
i.e., container, leaf, list, leaf-list or anyxml, throughout the
data model. Metadata annotations are always optional.</t>
</section>
<section anchor="encoding" title="The Encoding of Annotations" toc="default">
<t>XML attributes are a natural choice for encoding metadata in
XML instance documents. For JSON <xref target="RFC7159" pageno="false" format="default"/>, 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" pageno="false" format="default"/>.</t>
<section anchor="enc-xml" title="XML Encoding" toc="default">
<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.</t>
</list></t>
<t>For example, the "inactive" annotation as defined in <xref target="annotdef" pageno="false" format="default"/> may be encoded as follows:</t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
<foo xmlns:ein="http://example.org/example-inactive"
ein:inactive="true">
...
</foo>
</artwork>
</figure>
</section>
<section anchor="enc-json" title="JSON Encoding" toc="default">
<t>The 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" pageno="false" format="default"/> 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" pageno="false" format="default"/>.</t>
</list></t>
<section anchor="met-obj" title="Metadata Object and Annotations" toc="default">
<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 (member of the metadata
object) SHALL be of the following form:
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
MODULE_NAME:LOCAL_NAME
</artwork>
</figure>
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.</t>
<t>Note that unlike YANG data node instances, for
annotations the explicit namespace identifier (MODULE_NAME)
must always be used.</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.</t>
</section>
<section anchor="enc-cal" title="Adding Annotations to Container, Anyxml and List Instances" toc="default">
<t>For an instance that is translated to a JSON object
(i.e., a container, anyxml or list entry), 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 anyxml node:
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
"cask": {
"@": {
"example-inactive:inactive": true
},
...
}
</artwork>
</figure></t>
<t>"seq" is a list whose key is "name", annotation "inactive" is
added only to the first entry:
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
"seq": [
{
"@": {
"example-inactive:inactive": true
},
"name": "one",
...
},
{
"name": "two",
...
}
]
</artwork>
</figure></t>
</list></t>
</section>
<section anchor="enc-l" title="Adding Annotations to Leaf Instances" toc="default">
<t>For a leaf instance, the metadata object is added as a
sibling name/value pair whose the name is the symbol "@"
concatenated with the identifier of the leaf.</t>
<t>For example, if "flag" is a leaf node:
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
"flag": true,
"@flag": {
"example-inactive:inactive": true
}
</artwork>
</figure>
</t>
</section>
<section anchor="enc-ll" title="Adding Annotations to Leaf-list Instances" toc="default">
<t>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 the leaf-list instance, where the name is the
symbol "@" concatenated with the identifier of the
leaf-list, 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.</t>
<t>Trailing null values in the 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 "inactive" annotation is added to the second and
third entry in the following way:
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
"folio": [6, 3, 7, 8],
"@folio": [
null,
{"example-inactive:inactive": true},
{"example-inactive:inactive": true}
]
</artwork>
</figure></t>
</section>
</section>
</section>
<section anchor="dsdl" title="Representing Annotations in DSDL Schemas" toc="default">
<t>RFC 6110 <xref target="RFC6110" pageno="false" format="default"/> defines a
standard mapping of YANG data models to Document Schema
Definition Languages (DSDL) <xref target="ISO.19757-1" pageno="false" format="default"/>. This
section specifies the mapping for the extension statement
"md:annotation" (<xref target="ietf-yang-metadata" pageno="false" format="default"/>), 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" pageno="false" format="default"/>), 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 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.</t> <t anchor="it.npref">A reference to the named
pattern described in item <xref target="it.npdef" format="counter" pageno="false"/> MUST be included as a child of every
<rng:element> pattern that corresponds to a container,
leaf, list or leaf-list data node.</t>
<t>Every metadata annotation definition in the form
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
md:annotation ARGUMENT;
</artwork>
</figure>
or
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
md:annotation ARGUMENT {
...
}
</artwork>
</figure>
is mapped to the following RELAX NG pattern:
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
<rng:attribute name="PREFIX:ARGUMENT">
...
</rng:attribute>
</artwork>
</figure>
where PREFIX is the namespace prefix bound to the namespace
URI of the YANG module that contains the "md:annotation"
statement. The "rng:attribute" pattern SHALL be inserted as a
child of the named pattern definition described in item <xref target="it.npdef" format="counter" pageno="false"/>.</t>
<t>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 <xref target="RFC6110" pageno="false" format="default"/>.</t>
</list></t>
<t>For example, the named pattern definition (item <xref target="it.npdef" format="counter" pageno="false"/>), when constructed only for
the "inactive" annotation, will have the following form:</t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
<rng:define name="__yang_metadata__">
<rng:attribute name="ein:inactive">
<rng:choice>
<rng:value>true</rng:value>
<rng:value>false</rng:value>
</rng:choice>
</rng:attribute>
</rng:define>
</artwork>
</figure>
<t>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</t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
<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" toc="default">
<t>RFC Ed.: 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).</t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
<CODE BEGINS> file "yang-metadata@2014-09-11.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
"Editor: Ladislav Lhotka
<mailto:lhotka@nic.cz>";
description
"This YANG module defines an extension statement that allows for
defining metadata annotations.";
revision 2014-09-11 {
description
"Initial revision.";
reference
"RFC XXXX: 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.
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 may be
specified using the following standard YANG substatements (all
are optional and may appear only once): 'type', 'description',
'reference', 'status' and 'units'. If the 'type' statement is
not present, the built-in 'string' type is used by default.
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 NETCONF hello message).
Depending on the prescribed usage patterns, the annotation
then may be attached by the server and/or client to any valid
instance of a data node defined by the server's data model.
XML and JSON encoding of annotations is defined in
RFC XXXX.";
}
}
<CODE ENDS></artwork>
</figure>
</section>
<section anchor="iana" title="IANA Considerations" toc="default">
<t>RFC Ed.: In this section, replace all occurrences of 'XXXX' with
the actual RFC number (and remove this note).</t>
<t>This document registers the following namespace URI in the
IETF XML registry <xref target="RFC3688" pageno="false" format="default"/>:</t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
----------------------------------------------------------
URI: urn:ietf:params:xml:ns:yang:ietf-yang-metadata
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
----------------------------------------------------------
</artwork>
</figure>
<t>This document registers the following YANG module in the YANG
Module Names registry <xref target="RFC6020" pageno="false" format="default"/>:</t>
<figure title="" suppress-title="false" align="left" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" align="left" alt="" width="" height="">
-------------------------------------------------------------------
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" toc="default">
<t>This document introduces a mechanism for defining 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.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year="1997" month="March"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<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
RFC 2119.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<format type="TXT" octets="4723" target="http://www.rfc-editor.org/rfc/rfc2119.txt"/>
<format type="HTML" octets="17970" target="http://xml.resource.org/public/rfc/html/rfc2119.html"/>
<format type="XML" octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"/>
</reference>
<reference anchor="RFC3688">
<front>
<title>The IETF XML Registry</title>
<author initials="M." surname="Mealling" fullname="M. Mealling">
<organization/></author>
<date year="2004" month="January"/>
<abstract>
<t>This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.</t></abstract></front>
<seriesInfo name="BCP" value="81"/>
<seriesInfo name="RFC" value="3688"/>
<format type="TXT" octets="17325" target="http://www.rfc-editor.org/rfc/rfc3688.txt"/>
</reference>
<reference anchor="RFC6020">
<front>
<title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
<organization/></author>
<date year="2010" month="October"/>
<abstract>
<t>YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name="RFC" value="6020"/>
<format type="TXT" octets="324178" target="http://www.rfc-editor.org/rfc/rfc6020.txt"/>
</reference>
<reference anchor="RFC6110">
<front>
<title>Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content</title>
<author initials="L." surname="Lhotka" fullname="L. Lhotka">
<organization/></author>
<date year="2011" month="February"/>
<abstract>
<t>This document specifies the mapping rules for translating YANG data models into Document Schema Definition Languages (DSDL), a coordinated set of XML schema languages standardized as ISO/IEC 19757. The following DSDL schema languages are addressed by the mapping: Regular Language for XML Next Generation (RELAX NG), Schematron, and Schematron and Document Schema Renaming Language (DSRL). The mapping takes one or more YANG modules and produces a set of DSDL schemas for a selected target document type -- datastore content, Network Configuration Protocol (NETCONF) messages, etc. Procedures for schema-based validation of such documents are also discussed. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name="RFC" value="6110"/>
<format type="TXT" octets="192547" target="http://www.rfc-editor.org/rfc/rfc6110.txt"/>
</reference>
<reference anchor="RFC6241">
<front>
<title>Network Configuration Protocol (NETCONF)</title>
<author initials="R." surname="Enns" fullname="R. Enns">
<organization/></author>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
<organization/></author>
<author initials="J." surname="Schoenwaelder" fullname="J. Schoenwaelder">
<organization/></author>
<author initials="A." surname="Bierman" fullname="A. Bierman">
<organization/></author>
<date year="2011" month="June"/>
<abstract>
<t>The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name="RFC" value="6241"/>
<format type="TXT" octets="209465" target="http://www.rfc-editor.org/rfc/rfc6241.txt"/>
</reference>
<reference anchor="RFC7159">
<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
<author initials="T." surname="Bray" fullname="T. Bray">
<organization/></author>
<date year="2014" month="March"/>
<abstract>
<t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.</t><t> This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t></abstract></front>
<seriesInfo name="RFC" value="7159"/>
<format type="TXT" octets="27451" target="http://www.rfc-editor.org/rfc/rfc7159.txt"/>
</reference>
<reference anchor="I-D.ietf-netmod-yang-json">
<front>
<title>JSON Encoding of Data Modeled with YANG</title>
<author initials="L" surname="Lhotka" fullname="Ladislav Lhotka">
<organization/>
</author>
<date month="April" day="22" year="2014"/>
<abstract><t>This document defines rules for representing configuration and state data defined using YANG as JSON text. It does so by specifying a procedure for translating the subset of YANG-compatible XML documents to JSON text, and vice versa. A JSON encoding of XML attributes is also defined so as to allow for including metadata in JSON documents.</t></abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-netmod-yang-json-00"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-json-00.txt"/>
</reference>
<reference anchor="W3C.REC-xml-infoset-20040204" target="http://www.w3.org/TR/2004/REC-xml-infoset-20040204">
<front>
<title>XML Information Set (Second Edition)</title>
<author initials="J." surname="Cowan" fullname="John Cowan">
<organization/>
</author>
<author initials="R." surname="Tobin" fullname="Richard Tobin">
<organization/>
</author>
<date month="February" day="4" year="2004"/>
</front>
<seriesInfo name="World Wide Web Consortium Recommendation" value="REC-xml-infoset-20040204"/>
<format type="HTML" target="http://www.w3.org/TR/2004/REC-xml-infoset-20040204"/>
</reference>
</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>
<reference anchor="I-D.ietf-netconf-restconf">
<front>
<title>RESTCONF Protocol</title>
<author initials="A" surname="Bierman" fullname="Andy Bierman">
<organization/>
</author>
<author initials="M" surname="Bjorklund" fullname="Martin Bjorklund">
<organization/>
</author>
<author initials="K" surname="Watsen" fullname="Kent Watsen">
<organization/>
</author>
<author initials="R" surname="Fernando" fullname="Rex Fernando">
<organization/>
</author>
<date month="July" day="3" year="2014"/>
<abstract><t>This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastores defined in NETCONF.</t></abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-netconf-restconf-01"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-netconf-restconf-01.txt"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:13:05 |