One document matched: draft-lhotka-netmod-ysdl-00.xml
<?xml version="1.0"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc docName="draft-lhotka-netmod-ysdl-00" ipr="trust200902" category="std">
<front>
<title abbrev="i-d-abbrev">YANG Schema Dispatching Language</title>
<author fullname="Ladislav Lhotka" initials="L." surname="Lhotka">
<organization>CZ.NIC</organization>
<address>
<email>lhotka@nic.cz</email>
</address>
</author>
<date day="30" month="November" year="2015"/>
<area/>
<area>Operations and Management</area>
<workgroup>NETMOD Working Group</workgroup>
<abstract>
<t>This document defines YANG Schema Dispatching Language
(YSDL). It is a meta-schema language that allows for combining
YANG modules into any number of schemas, and arranging these
schemas in a hierarchical structure.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>YANG data modelling language <xref target="I-D.ietf-netmod-rfc6020bis"/> assumes that data trees
(configuration and state data) defined in YANG modules start at
the common global root. This means that the global path of every
dara node is fixed as soon as the data node is defined (for a
node defined in a grouping, the path is fixed when the grouping
is used).</t>
<t>Recent data modeling efforts, such as <xref target="I-D.rtgyangdt-rtgwg-device-model"/> indicate that this
arrangement may be too restrictive. A typical use case is a data
model that was designed for a stand-alone device but later needs
to be reused for logical or virtual devices, and the original
data model has to be grafted as a submodel in a top-level schema
describing the organization of logical/virtual devices.</t>
<t>This document proposes a new minilanguage named YANG Schema
Dispatching Language (YSDL) as a solution to this problem. It is
a meta-schema language that allows for defining multiple schemas
comprising one or more YANG modules, and arrange the schemas in
a hierarchical structure.</t>
<t>As a useful side-effect, it is also possible to use YSDL
schemas to specify a data model for an "anydata" node at run
time.</t>
</section>
<section anchor="termnot" title="Terminology and Notation">
<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>
<t>The following terms are defined in <xref target="I-D.ietf-netmod-rfc6020bis"/>:
<list style="symbols">
<t>action,</t>
<t>anydata,</t>
<t>augment,</t>
<t>container,</t>
<t>data node,</t>
<t>data tree,</t>
<t>identity,</t>
<t>instance identifier,</t>
<t>leaf,</t>
<t>leaf-list,</t>
<t>list,</t>
<t>module,</t>
<t>notification,</t>
<t>RPC operation,</t>
<t>schema node.</t>
</list></t>
<t>The term "server" denotes a server of a network management
protocol such as NETCONF <xref target="RFC6241"/> or
RESTCONF <xref target="I-D.ietf-netconf-restconf"/>.</t>
<t>A simplified graphical representation of the data model is
used in this document. The meaning of the symbols in these
diagrams is as follows:</t>
<t><list style="symbols">
<t>Brackets "[" and "]" enclose list keys.</t>
<t>Curly braces "{" and "}" contain names of optional features that
make the corresponding node conditional.</t>
<t>Abbreviations before data node names: "rw" means configuration
(read-write), "ro" state data (read-only), "-x" RPC operations, and
"-n" notifications.</t>
<t>Symbols after data node names: "?" means an optional node, "!" a
container with presence, and "*" denotes a "list" or "leaf-list".</t>
<t>Parentheses enclose choice and case nodes, and case nodes are
also marked with a colon (":").</t>
<t>Ellipsis ("...") stands for contents of subtrees that are not
shown.</t>
</list></t>
</section>
<section anchor="ysdl" title="YANG Schema Dispatching Language">
<t>The YSDL syntax is defined in <xref target="yang"/> using
YANG in the role of a schema language. YSDL meta-schemas can be
serialized in any encoding supported by YANG, such as XML <xref target="I-D.ietf-netmod-rfc6020bis"/> or JSON <xref target="I-D.ietf-netmod-yang-json"/>.</t>
<t>YSDL meta-schemas are intended to be used in conjunction with
YANG Library <xref target="I-D.ietf-netconf-yang-library"/>:
names and revisions of YANG modules appearing in a meta-schema
SHALL be resolved from YANG Library data, and YANG Library
specifications of supported features and deviations MUST also be
taken into account.</t>
<t>A YSDL meta-schema only affects the main data tree
(configuration and state data), including actions. RPC
operations and notifications are handled exactly as specified in
<xref target="I-D.ietf-netmod-rfc6020bis"/>.</t>
<t>YANG tree diagram for a YSDL meta-schema is as follows:</t>
<figure>
<artwork>
module: ietf-ysdl
+--rw schemas
+--rw top-schema? schema-ref
+--rw schema* [name]
+--rw name string
+--rw yang-modules* yang:yang-identifier
+--rw subschema* [root]
+--rw root schema-node-path
+--rw schemas* schema-ref
</artwork>
</figure>
<section anchor="schemas" title="YSDL Schemas">
<t>A YSDL meta-schema defines one or more schemas, each
comprising one or more YANG modules and zero or more
subschemas. The same YANG module can be part of multiple
schemas.</t>
<t>Exactly one of the schemas MUST be the top-level schema which
is identified by the "top-schema" leaf. The top-level schema
defines the uppermost structure of the entire data model, and
its root always coincides with the global root.</t>
<t>Any schema can define other schemas as its subschema. For
each subschema, the root node has to be specified. Any
"container", "list", "case" or "anydata" schema node contained
in one of the parent schema modules can act as the root
node.</t>
<t>Note that the traditional arrangement of YANG modules in a
data model can be achieved with a YSDL meta-schema in which all
modules are listed in the top-level schema, and no subschemas
are defined.</t>
</section>
<section anchor="validation" title="Validating Data with YSDL and YANG">
<t>The schema tree of a subschema is conceptually attached to
the parent schema tree as a subtree of the root node. In other
words, the first data node that is either the subschema root
or its ancestor coincides with the conceptual root of the
subschema data tree.</t>
<t>All paths (in leafrefs, instance-identifiers, XPath
expressions and target nodes of augments) are interpreted
within the subschema data or schema tree. Therefore, they
cannot refer to nodes in the ancestor schemas or other
subschemas.</t>
</section>
</section>
<section anchor="yang" title="YSDL YANG Module">
<t>The "ietf-ysdl" module below defines the YSDL meta-schema
language using YANG. However, it is not meant to be implemented
as datastore contents by a server.</t>
<figure>
<artwork>
<CODE BEGINS> file "ietf-ysdl@2015-11-30.yang"
module ietf-ysdl {
namespace "urn:ietf:params:xml:ns:yang:ietf-ysdl";
prefix "ysdl";
import ietf-yang-types {
prefix "yang";
}
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>
WG Chair: Kent Watsen
<mailto:kwatsen@juniper.net>
Editor: Ladislav Lhotka
<mailto:lhotka@nic.cz>";
description
"This module defines YANG Schema Dispatching Language (YSDL) – a
meta-schema language for YANG-based data models.
A YSDL schema allows for embedding a YANG schema as a subschema
in a specific location of another module.
Copyright (c) 2015 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-11-30 {
description
"Initial revision.";
reference
"RFC XXXX: YANG Schema Dispatching Language";
}
/* Typedefs */
typedef schema-node-path {
type string {
pattern "[a-zA-Z_][a-zA-Z0-9\\-_.]*:[a-zA-Z_][a-zA-Z0-9\\-_.]*"
+ "(/([a-zA-Z_][a-zA-Z0-9\\-_.]*"
+ ":)?[a-zA-Z_][a-zA-Z0-9\\-_.]*)";
}
description
"Intra-schema path to a YANG schema node.
The value is a sequence of schema node names separated by the
slash character ('/'). The first (leftmost) component is
prefixed with the name of the YANG module in which the schema
node is defined. A subsequent component has the module prefix
if and only if the preceding schema node is defined in another
module.";
}
typedef schema-ref {
type leafref {
path "/ysdl:schemas/ysdl:schema/ysdl:name";
}
description
"Reference to a schema.";
}
/* YSDL */
container schemas {
description
"Container for YSDL schemas.";
leaf top-schema {
type schema-ref;
description
"Reference to the top-level schema.";
}
list schema {
key "name";
min-elements "1";
description
"Each entry is a named schema. Exactly one entry must be the
top-level schema, other (optional) entries can be used as
subschemas.";
leaf name {
type string;
description
"Name of the schema.";
}
leaf-list yang-modules {
type yang:yang-identifier;
min-elements "1";
description
"Each entry is the name of a YANG module contributing to
the schema.";
}
list subschema {
key "root";
description
"Each entry is a subschema attached to the parent
schema.";
leaf root {
type schema-node-path;
description
"Each entry specifies the relative (intra-schema) path to
the root node where the subschema is attached. The
schema node MUST be one of: container, list, case or
anydata.
The absolute path of the root node depends on the
structure of schemas:
- For the top-level schema, the root is always '/'.
- For other schemas, the root path is formed by
concatenation of the corresponding root paths of all
ancestor schemas.";
}
leaf-list schemas {
type schema-ref;
description
"References to schemas that comprise the subschema.";
}
}
}
}
}
<CODE ENDS></artwork>
</figure>
</section>
<section anchor="example" title="Example YSDL Meta-Schema">
<t>The following YANG module will be used for the top-level
schema. It is a simplified analogy of the "network-device"
module from <xref target="I-D.rtgyangdt-rtgwg-device-model"/>.</t>
<figure>
<artwork>
module example-device {
namespace "http://www.example.net/example-device";
prefix "exdev";
container device {
container logical-NEs {
list logical-NE {
key "name";
leaf name {
type string;
}
}
}
}
}
</artwork>
</figure>
<t>The YSDL meta-schema is as follows:</t>
<figure>
<artwork>
{
"ietf-ysdl:schemas": {
"top-schema": "device",
"schema": [
{
"name": "device",
"yang-modules": [
"example-device"
],
"subschema": [
{
"root": "example-device:device",
"schemas": [
"if-ip",
"system"
]
},
{
"root": "example-device:device/logical-NEs/logical-NE",
"schemas": [
"if-ip"
]
}
]
},
{
"name": "if-ip",
"yang-modules": [
"ietf-interfaces",
"ietf-ip"
]
},
{
"name": "system",
"yang-modules": [
"ietf-system"
]
}
]
}
}
</artwork>
</figure>
<t>Apart prom the top-level schema, "device", the meta-schema
defines two other schemas:
<list style="symbols">
<t>"if-ip" schema consists of "ietf-interfaces" and "ietf-ip"
modules;</t>
<t>"system" schema consist of "ietf-system" module.</t>
</list></t>
<t>Two subschemas of the top-level schema defined with the
following root nodes:
<list style="symbols">
<t>"example-device:device",</t>
<t>"example-device:device/logical-NEs/logical-NE".</t>
</list>
The former one uses both "if-ip" and "system" schemas whereas
the latter uses only "system".</t>
<t>The entire schema tree consisting of the top-level schema and
the two subschemas is shown schematically in the following tree
diagram:</t>
<figure>
<artwork>
module: example-device
+--rw device
+--rw if:interfaces
| ...
+--ro if:interfaces-state
| ...
+--rw sys:system
| ...
+--rw sys:system-state
+--rw logical-NEs
+--rw logical-NE* [name]
+--rw name string
+--rw if:interfaces
| ...
+--ro if:interfaces-state
| ...
</artwork>
</figure>
</section>
<section anchor="iana" title="IANA Considerations">
<t>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).</t>
<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-ysdl
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-ysdl
namespace: urn:ietf:params:xml:ns:yang:ietf-ysdl
prefix: ysdl
reference: RFC XXXX
---------------------------------------------------------------------
</artwork>
</figure>
</section>
<section anchor="security" title="Security Considerations">
<t>TBD</t>
</section>
<section anchor="ack" title="Acknowledgements">
<t>YSDL was loosely inspired by Namespace-based Validation
Dispatching Language (NVDL) <xref target="ISO.19757-4"/>.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119" target="http://www.rfc-editor.org/info/rfc2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="S. Bradner"><organization/></author>
<date year="1997" month="March"/>
<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. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC3688" target="http://www.rfc-editor.org/info/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"/>
<seriesInfo name="DOI" value="10.17487/RFC3688"/>
</reference>
<reference anchor="RFC6020" target="http://www.rfc-editor.org/info/rfc6020">
<front>
<title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor"><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"/>
<seriesInfo name="DOI" value="10.17487/RFC6020"/>
</reference>
<reference anchor="I-D.ietf-netconf-yang-library">
<front>
<title>YANG Module Library</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>
<date month="October" day="18" year="2015"/>
<abstract><t>This document describes a YANG library, which provides information about all the YANG modules used by a device to represent management and protocol information. A YANG library can be shared by multiple protocols within the same device. Simple caching mechanisms are needed to allow clients to minimize retrieval of this information.</t></abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-netconf-yang-library-02"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-netconf-yang-library-02.txt"/>
</reference>
<reference anchor="I-D.ietf-netmod-rfc6020bis">
<front>
<title>The YANG 1.1 Data Modeling Language</title>
<author initials="M" surname="Bjorklund" fullname="Martin Bjorklund">
<organization/>
</author>
<date month="October" day="19" year="2015"/>
<abstract><t>YANG is a data modeling language used to model configuration data, state data, remote procedure calls, and notifications for network management protocols like the Network Configuration Protocol (NETCONF).</t></abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-netmod-rfc6020bis-08"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-netmod-rfc6020bis-08.txt"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="I-D.rtgyangdt-rtgwg-device-model">
<front>
<title>Network Device YANG Organizational Model</title>
<author initials="A" surname="Lindem" fullname="Acee Lindem">
<organization/>
</author>
<author initials="L" surname="Berger" fullname="Lou Berger">
<organization/>
</author>
<author initials="D" surname="Bogdanovic" fullname="Dean Bogdanovic">
<organization/>
</author>
<author initials="C" surname="Hopps" fullname="Christian Hopps">
<organization/>
</author>
<date month="September" day="21" year="2015"/>
<abstract><t>This document presents an approach for organizing YANG models in a comprehensive structure that defines how individual models may be composed to configure and operate network infrastructure and services. The structure is itself represented as a YANG model, with all of the related component models logically organized in a way that is operationally intuitive. This document is derived from work submitted to the IETF by members of the informal OpenConfig working group of network operators and is a product of the Routing Area YANG Architecture design team.</t></abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-rtgyangdt-rtgwg-device-model-01"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-rtgyangdt-rtgwg-device-model-01.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="October" day="7" year="2015"/>
<abstract><t>This document defines encoding rules for representing configuration, state data, RPC operation or action input and output parameters, and notifications defined using YANG as JavaScript Object Notation (JSON) text.</t></abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-netmod-yang-json-06"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-json-06.txt"/>
</reference>
<reference anchor="RFC6241" target="http://www.rfc-editor.org/info/rfc6241">
<front>
<title>Network Configuration Protocol (NETCONF)</title>
<author initials="R." surname="Enns" fullname="R. Enns" role="editor"><organization/></author>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor"><organization/></author>
<author initials="J." surname="Schoenwaelder" fullname="J. Schoenwaelder" role="editor"><organization/></author>
<author initials="A." surname="Bierman" fullname="A. Bierman" role="editor"><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"/>
<seriesInfo name="DOI" value="10.17487/RFC6241"/>
</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>
<date month="October" day="18" year="2015"/>
<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-08"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-netconf-restconf-08.txt"/>
</reference>
<reference anchor="ISO.19757-4">
<front>
<title>
Document Schema Definition Languages (DSDL) – Part 4:
Namespace-based Validation Dispatching Language (NVDL)
</title>
<author>
<organization>International Organization for Standardization</organization>
</author>
<date day="1" month="June" year="2006"/>
</front>
<seriesInfo name="ISO/IEC" value="19757-4"/>
<format type="PDF" target="http://standards.iso.org/ittf/PubliclyAvailableStandards/c038615_ISO_IEC_19757-4_2006(E).zip"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:22:12 |