NETMOD L. Lhotka
Internet-Draft CESNET
Intended status: Standards Track R. Mahy
Expires: August 15, 2009 Plantronics
S. Chisholm
Nortel
February 11, 2009
Mapping YANG to Document Schema Definition Languages and Validating
NETCONF Content
draft-ietf-netmod-dsdl-map-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 15, 2009.
Copyright Notice
Copyright (c) 2009 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.
Lhotka, et al. Expires August 15, 2009 [Page 1]
Internet-Draft Mapping YANG to DSDL February 2009
Abstract
This draft describes the mapping rules for translating YANG data
models into XML schemas using Document Schema Definition Languages
(DSDL).
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Objectives and Motivation . . . . . . . . . . . . . . . . . . 8
3. DSDL Schema Languages . . . . . . . . . . . . . . . . . . . . 10
3.1. RELAX NG . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Schematron . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Document Schema Renaming Language (DSRL) . . . . . . . . 12
4. Additional Annotations . . . . . . . . . . . . . . . . . . . . 13
4.1. Dublin Core Metadata Elements . . . . . . . . . . . . . . 13
4.2. RELAX NG DTD Compatibility Annotations . . . . . . . . . 13
4.3. NETMOD-specific Annotations . . . . . . . . . . . . . . . 14
5. Overview of the Mapping . . . . . . . . . . . . . . . . . . . 16
6. Design Considerations . . . . . . . . . . . . . . . . . . . . 19
6.1. Conceptual Data Tree . . . . . . . . . . . . . . . . . . 19
6.2. Modularity . . . . . . . . . . . . . . . . . . . . . . . 21
6.3. Granularity . . . . . . . . . . . . . . . . . . . . . . . 22
7. Mapping Data Model Structure to the Conceptual Tree Schema . . 23
7.1. Optional and Mandatory Content . . . . . . . . . . . . . 23
7.2. Mapping YANG Groupings and Typedefs . . . . . . . . . . . 23
7.2.1. YANG Refinements and Augments . . . . . . . . . . . 26
7.2.2. Type derivation chains . . . . . . . . . . . . . . . 29
7.3. Translation of XPath Expressions . . . . . . . . . . . . 30
7.4. YANG Language Extensions . . . . . . . . . . . . . . . . 31
7.5. RPC Signatures and Notifications . . . . . . . . . . . . 32
8. Mapping Conceptual Tree Schema to DSDL . . . . . . . . . . . . 33
8.1. Mapping Semantic Constraints to Schematron . . . . . . . 33
8.1.1. Library of Schema-independent Schematron Patterns . 33
8.2. Mapping Default Values to DSRL . . . . . . . . . . . . . 33
9. NETCONF Content Validation . . . . . . . . . . . . . . . . . . 34
9.1. Validation Phases . . . . . . . . . . . . . . . . . . . . 34
10. Mapping YANG Statements to Annotated RELAX NG . . . . . . . . 36
10.1. The anyxml Statement . . . . . . . . . . . . . . . . . . 36
10.2. The argument Statement . . . . . . . . . . . . . . . . . 37
10.3. The augment Statement . . . . . . . . . . . . . . . . . . 37
10.4. The base Statement . . . . . . . . . . . . . . . . . . . 38
10.5. The belongs-to Statement . . . . . . . . . . . . . . . . 38
10.6. The bit Statement . . . . . . . . . . . . . . . . . . . . 38
10.7. The case Statement . . . . . . . . . . . . . . . . . . . 38
10.8. The choice Statement . . . . . . . . . . . . . . . . . . 38
10.9. The config Statement . . . . . . . . . . . . . . . . . . 38
Lhotka, et al. Expires August 15, 2009 [Page 2]
Internet-Draft Mapping YANG to DSDL February 2009
10.10. The contact Statement . . . . . . . . . . . . . . . . . . 38
10.11. The container Statement . . . . . . . . . . . . . . . . . 38
10.12. The default Statement . . . . . . . . . . . . . . . . . . 39
10.13. The description Statement . . . . . . . . . . . . . . . . 39
10.14. The enum Statement . . . . . . . . . . . . . . . . . . . 40
10.15. The error-app-tag Statement . . . . . . . . . . . . . . . 40
10.16. The error-message Statement . . . . . . . . . . . . . . . 40
10.17. The extension Statement . . . . . . . . . . . . . . . . . 40
10.18. The grouping Statement . . . . . . . . . . . . . . . . . 40
10.19. The identity Statement . . . . . . . . . . . . . . . . . 41
10.20. The import Statement . . . . . . . . . . . . . . . . . . 41
10.21. The include Statement . . . . . . . . . . . . . . . . . . 41
10.22. The input Statement . . . . . . . . . . . . . . . . . . . 41
10.23. The key Statement . . . . . . . . . . . . . . . . . . . . 41
10.24. The leaf Statement . . . . . . . . . . . . . . . . . . . 41
10.25. The leaf-list Statement . . . . . . . . . . . . . . . . . 42
10.26. The length Statement . . . . . . . . . . . . . . . . . . 42
10.27. The list Statement . . . . . . . . . . . . . . . . . . . 42
10.28. The mandatory Statement . . . . . . . . . . . . . . . . . 43
10.29. The max-elements Statement . . . . . . . . . . . . . . . 43
10.30. The min-elements Statement . . . . . . . . . . . . . . . 43
10.31. The module Statement . . . . . . . . . . . . . . . . . . 43
10.32. The must Statement . . . . . . . . . . . . . . . . . . . 43
10.33. The namespace Statement . . . . . . . . . . . . . . . . . 44
10.34. The notification Statement . . . . . . . . . . . . . . . 45
10.35. The ordered-by Statement . . . . . . . . . . . . . . . . 45
10.36. The organization Statement . . . . . . . . . . . . . . . 45
10.37. The output Statement . . . . . . . . . . . . . . . . . . 46
10.38. The path Statement . . . . . . . . . . . . . . . . . . . 46
10.39. The pattern Statement . . . . . . . . . . . . . . . . . . 46
10.40. The position Statement . . . . . . . . . . . . . . . . . 46
10.41. The prefix Statement . . . . . . . . . . . . . . . . . . 46
10.42. The presence Statement . . . . . . . . . . . . . . . . . 46
10.43. The range Statement . . . . . . . . . . . . . . . . . . . 46
10.44. The reference Statement . . . . . . . . . . . . . . . . . 46
10.45. The require-instance Statement . . . . . . . . . . . . . 46
10.46. The revision Statement . . . . . . . . . . . . . . . . . 47
10.47. The rpc Statement . . . . . . . . . . . . . . . . . . . . 47
10.48. The status Statement . . . . . . . . . . . . . . . . . . 47
10.49. The submodule Statement . . . . . . . . . . . . . . . . . 47
10.50. The type Statement . . . . . . . . . . . . . . . . . . . 47
10.50.1. The empty Type . . . . . . . . . . . . . . . . . . . 48
10.50.2. The boolean and binary Types . . . . . . . . . . . . 48
10.50.3. The bits Type . . . . . . . . . . . . . . . . . . . 49
10.50.4. The enumeration and union Types . . . . . . . . . . 49
10.50.5. The identityref Type . . . . . . . . . . . . . . . . 49
10.50.6. The instance-identifier Type . . . . . . . . . . . . 51
10.50.7. The leafref Type . . . . . . . . . . . . . . . . . . 51
Lhotka, et al. Expires August 15, 2009 [Page 3]
Internet-Draft Mapping YANG to DSDL February 2009
10.50.8. The numeric Types . . . . . . . . . . . . . . . . . 51
10.50.9. The string Type . . . . . . . . . . . . . . . . . . 52
10.50.10. Derived Types . . . . . . . . . . . . . . . . . . . 53
10.51. The typedef Statement . . . . . . . . . . . . . . . . . . 53
10.52. The unique Statement . . . . . . . . . . . . . . . . . . 54
10.53. The units Statement . . . . . . . . . . . . . . . . . . . 54
10.54. The uses Statement . . . . . . . . . . . . . . . . . . . 54
10.55. The value Statement . . . . . . . . . . . . . . . . . . . 54
10.56. The when Statement . . . . . . . . . . . . . . . . . . . 54
10.57. The yang-version Statement . . . . . . . . . . . . . . . 54
10.58. The yin-element Statement . . . . . . . . . . . . . . . . 54
11. Mapping NETMOD-specific annotations to Schematron and DSRL . . 55
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Appendix A. RELAX NG Schema for NETMOD-specific Annotations . . . 59
A.1. XML Syntax . . . . . . . . . . . . . . . . . . . . . . . 59
A.2. Compact Syntax . . . . . . . . . . . . . . . . . . . . . 62
Appendix B. Schematron Library . . . . . . . . . . . . . . . . . 63
Appendix C. Translation of the DHCP Data Model . . . . . . . . . 64
C.1. XML Syntax . . . . . . . . . . . . . . . . . . . . . . . 64
C.2. Compact Syntax . . . . . . . . . . . . . . . . . . . . . 68
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 72
Lhotka, et al. Expires August 15, 2009 [Page 4]
Internet-Draft Mapping YANG to DSDL February 2009
1. Introduction
The NETCONF Working Group has completed a base protocol used for
configuration management [1]. This base specification defines
protocol bindings and an XML container syntax for configuration and
management operations, but does not include a modeling language or
accompanying rules for how to model configuration and status
information (in XML syntax) carried by NETCONF. The IETF Operations
Area has a long tradition of defining data for SNMP Management
Information Bases (MIBs) [2] using the SMI language [3] to model its
data. While this specific modeling approach has a number of well-
understood problems, most of the data modeling features provided by
SMI are still considered extremely important. Simply modeling the
valid syntax rather than additional semantic relationships has caused
significant interoperability problems in the past.
The NETCONF community concluded that a data modeling framework is
needed to support ongoing development of IETF and vendor-defined
management information modules. The NETMOD Working Group was
chartered to address this problem, by defining a new human-friendly
modeling language based on SMIng [4] and called YANG [5].
Since NETCONF uses XML for encoding its protocol data units (PDU), it
is natural to express the constraints on NETCONF content using
standard XML schema languages. For this purpose, the NETMOD WG
selected the Document Schema Definition Languages (DSDL) that is
being standardized as ISO/IEC 19757 [6]. The DSDL framework
comprises a set of XML schema languages that address grammar rules,
semantic constraints and other data modeling aspects but also, and
more importantly, do it in a coordinated and consistent way. While
it is true that some DSDL parts have not been standardized yet and
are still work in progress, the three parts that the YANG-to-DSDL
mapping relies upon - RELAX NG, Schematron and DSRL - already have
the status of an ISO/IEC International Standard and are supported in
a number of software tools.
This document contains the specification of a mapping that translates
YANG data models to XML schemas utilizing a subset of the DSDL schema
languages. The mapping procedure is divided into two steps: In the
first step, the structure of the data tree, RPC signatures and
notifications is expressed as a single RELAX NG grammar with simple
annotations representing additional data model information (metadata,
documentation, semantic constraints, default values etc.). The
second step then generates a coordinated set of DSDL schemas that can
validate specific XML documents such as client requests, server
responses or notifications, perhaps also taking into account
additional context such as active capabilities.
Lhotka, et al. Expires August 15, 2009 [Page 5]
Internet-Draft Mapping YANG to DSDL February 2009
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 [7].
In the text, we also use the following typographic conventions:
o YANG statement keywords are delimited by single quotes.
o Literal values are delimited by double quotes.
o XML element names are delimited by "<" and ">" characters.
o Names of XML attributes are prefixed by the "@" character.
XML elements names are always written with explicit namespace
prefixes corresponding to the following XML vocabularies:
a DTD compatibility annotations [8]
dc Dublin Core metadata elements
nc NETCONF protocol [1]
nma NETMOD-specific schema annotations
nmt Conceptual tree
dsrl Document Schema Renaming Language[9]
rng RELAX NG[10]
sch ISO Schematron[11]
xsd W3C XML Schema[12]
The following table shows the mapping of these prefixes to namespace
URIs.
Lhotka, et al. Expires August 15, 2009 [Page 6]
Internet-Draft Mapping YANG to DSDL February 2009
+--------+-----------------------------------------------------+
| Prefix | Namespace URI |
+--------+-----------------------------------------------------+
| a | http://relaxng.org/ns/compatibility/annotations/1.0 |
| | |
| dc | http://purl.org/dc/terms |
| | |
| nc | urn:ietf:params:xml:ns:netconf:base:1.0 |
| | |
| nma | urn:ietf:params:xml:ns:netmod:dsdl-annotations:1 |
| | |
| nmt | urn:ietf:params:xml:ns:netmod:conceptual-tree:1 |
| | |
| dsrl | http://purl.oclc.org/dsdl/dsrl |
| | |
| rng | http://relaxng.org/ns/structure/1.0 |
| | |
| sch | http://purl.oclc.org/dsdl/schematron |
| | |
| xsd | http://www.w3.org/2001/XMLSchema |
+--------+-----------------------------------------------------+
Table 1: Used namespace prefixes and corresponding URIs
Lhotka, et al. Expires August 15, 2009 [Page 7]
Internet-Draft Mapping YANG to DSDL February 2009
2. Objectives and Motivation
The main objective of this work is to complement YANG as a data
modeling language by validation capabilities of DSDL schema
languages, primarily RELAX NG and Schematron. This document
describes the correspondence between grammatical, semantic and data
type constraints expressed in YANG and equivalent DSDL constructs.
The ultimate goal is to be able to capture all substantial
information contained in YANG modules and express it in DSDL schemas.
While the mapping from YANG to DSDL described in this document is in
principle invertible, the inverse mapping from DSDL to YANG is not in
its scope.
XML-encoded data appear in several different forms in various phases
of the NETCONF workflow - configuration datastore contents, RPC
requests and replies, and notifications. Moreover, RPC methods are
characterized by an inherent diversity resulting from selective
availability of capabilities and features. YANG modules can also
define new RPC methods. The mapping should be able to accommodate
this variability and generate schemas that are specifically tailored
to a particular situation and thus considerably more efficient than
generic all-encompassing schemas.
In order to cope with this variability, we assume that the schemas
can be generated on demand from the available collection of YANG
modules and their lifetime will be relatively short. In other words,
we don't envision that any collection of DSDL schemas will be created
and maintained over extended periods of time in parallel to YANG
modules.
The generated schemas are primarily intended as input to the existing
XML schema validators and other off-the-shelf tools. However, the
schemas may also be perused by developers and users as a formal
representation of constraints on a particular XML-encoded data
object. Consequently, our secondary goal is to keep the schemas as
readable as possible. To this end, the complexity of the mapping is
distributed into two steps:
1. The first step maps one or more YANG modules to a single RELAX NG
schema of the so-called "conceptual tree", which contains
grammatical constraints for the main data tree as well as RPCs
and notifications. In order to record additional constraints
that appear in the YANG modules but cannot be expressed in RELAX
NG, the schema is augmented by simple annotations. The resulting
schema should thus be considered a reasonably readable equivalent
of the input YANG modules.
Lhotka, et al. Expires August 15, 2009 [Page 8]
Internet-Draft Mapping YANG to DSDL February 2009
2. In the second step, the annotated RELAX NG schema from step 1 is
transformed further to a coordinated set of DSDL schemas
containing constraints for a particular data object and a
specific situation. The DSDL schemas are intended mainly for
machine validation using off-the-shelf tools.
Lhotka, et al. Expires August 15, 2009 [Page 9]
Internet-Draft Mapping YANG to DSDL February 2009
3. DSDL Schema Languages
The mapping described in this document uses three of the DSDL schema
languages, namely RELAX NG, Schematron and DSRL.
3.1. RELAX NG
RELAX NG (pronounced "relaxing") is an XML schema language for
grammar-based validation and Part 2 of the ISO/IEC DSDL family of
standards [10]. Like the W3C XML Schema language [12], it is able to
describe constraints on the structure and contents of XML documents.
However, unlike the DTD [13] and XSD schema languages, RELAX NG
intentionally avoids any infoset augmentation such as defining
default values. In the DSDL architecture, the particular task of
defining and applying default values is delegated to another schema
language, DSRL (see Section 3.3).
As its base datatype library, RELAX NG uses the W3C XML Schema
Datatype Library [14], but unlike XSD, other datatype libraries may
be used along with it or even replace it if necessary.
RELAX NG is very liberal in accepting annotations from other
namespaces. With few exceptions, such annotations may be placed
anywhere in the schema and need no encapsulating element such as
<xsd:annotation> in XSD.
RELAX NG schema can be represented using two equivalent syntaxes: XML
and compact. The compact syntax is described in Annex C of the RELAX
NG specification [15], which was added to the standard in 2006
(Amendment 1). Automatic bidirectional conversions between the two
syntaxes can be accomplished using for example Trang [22].
For its terseness and readability, the compact syntax is often the
preferred form for publishing RELAX NG schemas whereas validators and
other software tools generally require the XML syntax. However, the
compact syntax has two drawbacks:
o External annotations make the compact syntax schema considerably
less readable. While in the XML syntax the annotating elements
and attributes are represented in a simple and uniform way (XML
elements and attributes from foreign namespaces), the compact
syntax uses four different syntactic constructs: documentation,
grammar, initial and following annotations. Therefore, the impact
on readability that results from adding annotations is often much
stronger for the compact syntax than for the XML syntax.
o It is more difficult to programmatically generate compact syntax
than XML syntax. While a number of software libraries exist that
Lhotka, et al. Expires August 15, 2009 [Page 10]
Internet-Draft Mapping YANG to DSDL February 2009
make it easy to create an XML tree in memory and serialize it, no
such aid is available for compact syntax.
For these reasons, the mapping specification in this document use
exclusively the XML syntax. Where appropriate, though, the schemas
resulting from the translation may be presented in the equivalent
compact syntax.
RELAX NG elements are qualified with the namespace URI
"http://relaxng.org/ns/structure/1.0". The namespace of the W3C
Schema Datatype Library is
"http://www.w3.org/2001/XMLSchema-datatypes".
3.2. Schematron
Schematron is Part 3 of DSDL that reached the status of a full ISO/
IEC standard in 2006 [11]. In contrast to the traditional schema
languages such as DTD, XSD or RELAX NG, which are based on the
concept of a formal grammar, Schematron utilizes a rule-based
approach. Its rules may specify arbitrary conditions involving data
from different parts of an XML document. Each rule consists of three
essential parts:
o Context - an XPath expression that defines the set of locations
where the rule is to be applied,
o Assert or report condition - another XPath expression that is
evaluated relative to the location matched by the context
expression.
o Human-readable message that is displayed when the assert condition
is false or report condition is true.
The difference between the assert and report condition is that the
former is positive in that it states a condition that a valid
document has to satisfy, whereas the latter specifies an error
condition. The mapping described in this document uses exclusively
the positive (assert) form.
Schematron draws most of its expressive power from XPath [16] and
XSLT [17]. ISO Schematron allows for dynamic query language binding
so that the following XML query languages can be used: STX, XSLT 1.0,
XSLT 1.1, EXSLT, XSLT 2.0, XPath 1.0, XPath 2.0 and XQuery 1.0 (this
list may be extended in future).
The human-readable error messages are another feature that
distinguishes Schematron from other schema languages such as RELAX NG
or XSD. The messages may even contain XPath expressions that are
Lhotka, et al. Expires August 15, 2009 [Page 11]
Internet-Draft Mapping YANG to DSDL February 2009
evaluated in the actual context and thus refer to existing XML
document nodes and their content.
ISO Schematron introduced the concept of _abstract patterns_ whose
purpose is similar to functions in programming languages. The
mapping described in this document uses a library of abstract
patterns for specifying generic constraints such as uniqueness of
certain leaf values in list items.
The rules defined by a Schematron schema may be divided into several
subsets known as _phases_. Validations may then be set up to include
only selected phases. In the context of NETCONF data validation,
this is useful for relaxing constraints that may not always apply.
For example, the reference integrity may not be enforced for a
candidate configuration.
Schematron elements are qualified with namespace URI
"http://purl.oclc.org/dsdl/schematron".
3.3. Document Schema Renaming Language (DSRL)
DSRL (pronounced "disrule") is Part 8 of DSDL that reached the status
of a full ISO/IEC standard in 2008 [9]. Unlike RELAX NG and
Schematron, it is specifically designed to modify XML information set
of the validated document. The primary application for DSRL is
renaming XML elements and attributes. DSRL can also define default
values for XML attributes and elements so that elements or attributes
with these default values are inserted if they are missing in the
validated documents. The latter feature is used by the YANG-to-DSDL
mapping for representing YANG defaults for leaf nodes.
DSRL elements are qualified with namespace URI
"http://purl.oclc.org/dsdl/dsrl".
Lhotka, et al. Expires August 15, 2009 [Page 12]
Internet-Draft Mapping YANG to DSDL February 2009
4. Additional Annotations
In addition to the DSDL schema languages, the mapping uses three sets
of annotations that are added as foreign-namespace elements and
attributes to RELAX NG schemas. Two of the annotation sets - Dublin
Core elements and DTD compatibility annotations - are standard
vocabularies for representing metadata and documentation,
respectively. While these data model items may not be used for
formal validation, they quite often carry important information.
Therefore, they SHOULD be included in the conceptual tree schema and
MAY also appear in the final validation schemas.
The third set are NETMOD-specific annotations conveying semantic
constraints and other information that cannot be expressed natively
in RELAX NG. These annotations are only used in the first step of
the mapping, i.e., in the conceptual tree schema. In the second
mapping step, these annotations are converted to Schematron and DSRL
rules.
4.1. Dublin Core Metadata Elements
Dublin Core [23] is a system of metadata elements that was originally
created for describing metadata of World Wide Web resources in order
to facilitate their automated lookup. Later it was accepted as a
standard for describing metadata of arbitrary resources. This
specification uses the definition found in [18].
Dublin Core elements are qualified with namespace URI
"http://purl.org/dc/terms".
4.2. RELAX NG DTD Compatibility Annotations
DTD compatibility annotations are part of the RELAX NG DTD
Compatibility specification [8]. The YANG-to-DSDL mapping uses only
the <a:documentation> annotation for representing YANG 'description'
and 'reference' texts.
Note that there is no intention to make the resulting schemas DTD-
compatible, the main reason for using these annotations is technical:
it is well supported and adequately interpreted by several RELAX NG
tools.
DTD compatibility annotations are qualified with namespace URI
"http://relaxng.org/ns/compatibility/annotations/1.0".
Lhotka, et al. Expires August 15, 2009 [Page 13]
Internet-Draft Mapping YANG to DSDL February 2009
4.3. NETMOD-specific Annotations
NETMOD-specific annotations are XML elements and attributes qualified
with the namespace URI
"urn:ietf:params:xml:ns:netmod:dsdl-annotations:1" that appear in
various locations in the conceptual tree schema. YANG statements are
mapped to these annotations in a very straightforward way. In
particular, the annotation attributes and elements always have the
same name as the corresponding YANG statement.
Table 2 lists alphabetically the names of NETMOD-specific annotation
elements (in angle brackets) and attributes (prefixed with "@") along
with a reference to the section where their use is described.
Appendix A then contains the RELAX NG schema of this annotation
vocabulary.
Lhotka, et al. Expires August 15, 2009 [Page 14]
Internet-Draft Mapping YANG to DSDL February 2009
+---------------------------+---------+------+
| annotation | section | note |
+---------------------------+---------+------+
| @nma:config | 10.9 | |
| | | |
| @nma:default | 10.12 | |
| | | |
| @nma:default-case | 10.7 | |
| | | |
| <nma:error-app-tag> | 10.15 | 1 |
| | | |
| <nma:error-message> | 10.16 | 1 |
| | | |
| <nma:instance-identifier> | 10.50.6 | 2 |
| | | |
| @nma:key | 10.23 | |
| | | |
| <nma:leafref> | 10.50.7 | 2 |
| | | |
| @nma:min-elements | 10.25 | |
| | | |
| @nma:max-elements | 10.25 | |
| | | |
| <nma:must> | 10.32 | 3 |
| | | |
| @nma:ordered-by | 10.35 | |
| | | |
| @nma:status | 10.48 | |
| | | |
| @nma:unique | 10.48 | |
| | | |
| @nma:units | 10.48 | |
| | | |
| @nma:when | 10.56 | |
+---------------------------+---------+------+
Table 2: NETMOD-specific annotations
Notes:
1. Appears only as subelement of <nma:must>.
2. Has an optional attribute @require-instance.
3. Has a mandatory attribute @assert and two optional subelements
<nma:error-app-tag> and <nma:error-message>.
Lhotka, et al. Expires August 15, 2009 [Page 15]
Internet-Draft Mapping YANG to DSDL February 2009
5. Overview of the Mapping
This section gives an overview of the YANG-to-DSDL mapping, its
inputs and outputs. Figure 1 presents an overall structure of the
mapping:
+----------------+
| YANG module(s) |
+----------------+
|
|T
|
+---------------------------------+
| DSDL schema for conceptual tree |
+---------------------------------+
/ | | \ +-------+
/ | | \ |library|
Td/ Ts| |Tc \ +-------+
/ | | \
+---------+ +------+ +------+ +------+
|datastore| |server| |client| | .... |
+---------+ +------+ +------+ +------+
Figure 1: Structure of the mapping
The mapping procedure is divided into two steps:
1. Transformation T in the first step maps one or more YANG modules
to a single RELAX NG schema for the conceptual tree (see
Section 6.1). Constraints that cannot be expressed directly in
RELAX NG (list key definitions, 'must' statements etc.) and
various documentation texts are recorded in the schema as simple
annotations belonging to special namespaces.
2. In the second step, the conceptual tree schema may be transformed
in multiple ways to a coordinated set of DSDL schemas that can be
used for validating a particular data object in a specific
context. Figure 1 shows just three simplest possibilities as
examples. In the process, appropriate parts of the conceptual
tree schema are extracted and specific annotations transformed to
equivalent, but usually more complex, Schematron patterns, <dsrl:
default-content> elements etc.
3. As indicated in Figure 1, the second step of the mapping also
uses a schema-independent library that contains mainly Schematron
abstract patterns corresponding to common YANG concepts such as
the uniqueness constraint for list keys.
Lhotka, et al. Expires August 15, 2009 [Page 16]
Internet-Draft Mapping YANG to DSDL February 2009
An implementation of the mapping algorithm accepts one or more valid
YANG modules as its input. It is important to be able to process
multiple YANG modules together since multiple modules may be
negotiated for a NETCONF session and the contents of the
configuration datastore is then obtained as the union of data trees
specified by the individual modules, perhaps with multiple root
nodes. In addition, the input modules may be further coupled by the
'augment' statement in which one module augments the data tree of
another module.
It is also assumed that the algorithm has access, perhaps on demand,
to all YANG modules that the module(s) imports (transitively).
The output of the first mapping step is an annotated RELAX NG schema
for the conceptual tree, which represents a virtual XML document
containing, in its different subtrees, the entire datastore, all RPC
requests and replies, and notifications defined by the input YANG
modules. By "virtual" we mean that such an XML document need not
correspond to the actual layout of the configuration database in a
NETCONF agent, and will certainly never appear on the wire as the
content of a NETCONF PDU. Hence, the RELAX NG schema for the
conceptual tree is not intended for any direct validations but rather
as a representation of a particular data model expressed in RELAX NG
and the common starting point for subsequent transformations that
will typically produce validation schemas. The conceptual tree is
further described in Section 6.1.
Other information contained in input YANG modules, such as semantic
constraints or default values, are recorded as annotations - XML
elements or attributes qualified with namespace URI
"urn:ietf:params:xml:ns:netmod:dsdl-annotations:1". Metadata
describing the YANG modules are mapped to annotations utilizing
Dublin Core elements (Section 4.1). Finally, documentation strings
are mapped to the <a:documentation> element belonging to the DTD
compatibility vocabulary (Section 4.2).
The output from the second step is is a coordinated set of three DSDL
schemas corresponding to a specific data object and context:
o RELAX NG schema describing the grammatical and datatype
constraints;
o Schematron schema expressing other constraints such as uniqueness
of list keys or user-specified semantic rules;
o DSRL schema containing a specification of default values.
An implementation SHOULD allow for selecting a subset of schema
Lhotka, et al. Expires August 15, 2009 [Page 17]
Internet-Draft Mapping YANG to DSDL February 2009
languages and annotation types to be used for output. For example, a
user might want to select pure RELAX NG without any annotations.
Lhotka, et al. Expires August 15, 2009 [Page 18]
Internet-Draft Mapping YANG to DSDL February 2009
6. Design Considerations
YANG modules could be mapped to DSDL schemas in a number of ways.
The mapping procedure described in this document uses several
specific design decisions that are discussed in the following
subsections.
6.1. Conceptual Data Tree
DSDL schemas generated from YANG modules using the procedure
described in this document are intended to be used for validating
XML-encoded NETCONF data in various forms (full datastore and several
types of PDUs): every YANG-based model represents the contents of a
full datastore but also implies an array of schemas for all types of
NETCONF PDUs. For a reasonably strict validation of a given data
object, the schemas have to be quite specific. To begin with,
effective validation of NETCONF PDU content requires separation of
client and server schemas. However, the decision about proper
structuring of all PDU-validating schemas is beyond the scope of this
document. However, the mapping procedure described in this document
is designed to accommodate any foreseeable validation needs.
An essential part of the YANG-to-DSDL mapping procedure is
nonetheless common to all validation approaches: the schemas for the
datastore, RPCs and notifications expressed by one or more YANG
modules have to be translated to RELAX NG. In order to be able to
separate this common step, we introduce the notion of _conceptual
data tree_: it is a virtual XML tree that contains full datastore,
RPC requests with corresponding replies and notifications. The
schema for the conceptual tree - a single RELAX NG schema with
annotations - therefore has a quite similar logic as the input YANG
module(s), the only major difference being the RELAX NG schema
language.
The conceptual data tree may be schematically represented as follows:
Lhotka, et al. Expires August 15, 2009 [Page 19]
Internet-Draft Mapping YANG to DSDL February 2009
<nmt:netmod-tree
xmlns:nmt="urn:ietf:params:xml:ns:netmod:conceptual-tree:1">
<nmt:main>
... configuration and status data ...
</nmt:main>
<nmt:rpc-methods>
<nmt:rpc-method name="...">
<nmt:input>
...
</nmt:input>
<nmt:output>
...
</nmt:output>
</nmt:rpc-method>
...
</nmt:rpcs>
<nmt:notifications>
<nmt:notification name="...">
...
</nmt:notification>
...
</nmt:notifications>
</nmt:netmod>
The namespace URI "urn:ietf:params:xml:ns:netmod:tree:1" identifies a
simple vocabulary consisting of a few elements that encapsulate and
separate the various parts of the conceptual data tree.
The conceptual tree schema is not intended for direct validation but
rather serves as a well-defined starting point for subsequent
transformations that generate various validation schemas. Such
transformations should be relatively simple, they will typically
extract one or several subtrees from the conceptual tree schema,
modify them as necessary and add encapsulating elements such as those
from the NETCONF RPC layer.
Additional information contained in the source YANG module(s), such
as semantic constraints and default values, is represented in the
form of _interim annotations_ that are included as foreign-namespace
elements or attributes in the RELAX NG schema for the conceptual
tree. In the second phase of the mapping, the interim annotations
are extracted and translated to equivalent Schematron and DSRL rules.
As a useful side effect, by introducing the conceptual data tree we
are also able to resolve the difficulties stemming from the fact that
a single configuration repository may consist of multiple parallel
data hierarchies defined in one or more YANG modules, which cannot be
mapped to a valid XML document. In the conceptual data tree, such
Lhotka, et al. Expires August 15, 2009 [Page 20]
Internet-Draft Mapping YANG to DSDL February 2009
multiple hierarchies appear under the single <nmt:main> element.
6.2. Modularity
Both YANG and RELAX NG offer means for modularity, i.e., for
splitting the contents into separate modules (schemas) and combining
or reusing them in various ways. However, the approaches taken by
YANG and RELAX NG differ. Modularity in RELAX NG is suitable for ad
hoc combinations of a small number of schemas whereas YANG assumes a
large set of modules similar to SNMP MIBs. The following differences
are important:
o In YANG, whenever module A imports module B, it gets access to the
definitions (groupings and typedefs) appearing at the top level of
module B. However, no part of module B's data tree is imported
along with it. In contrast, the <rng:include> pattern in RELAX NG
imports both definitions of named patterns and the entire schema
tree from the included schema.
o The names of imported YANG groupings and typedefs are qualified
with the namespace of the imported module. On the other hand, the
data nodes contained inside the imported groupings, when used
within the importing module, become part of the importing
namespace. In RELAX NG, the names of patterns are unqualified and
so named patterns defined in both the importing and imported
module share the same flat namespace. The contents of RELAX NG
named patterns may either keep the namespace of the schema where
they are defined or inherit the namespace of the importing module,
analogically to YANG. However, in order to achieve the latter
behavior, the imported module must be prepared in a special way as
a library module that cannot be used as a stand-alone schema.
So the conclusion is that the modularity mechanisms of YANG and RELAX
NG, albeit similar, are not directly compatible. Therefore, the
corresponding design decision for the mapping algorithm is to collect
all information in a single schema for the conceptual tree, even if
it comes from multiple YANG modules or submodules. In other words,
translations of imported groupings and typedefs are installed in the
translation of importing module - but only if they are really used
there.
NOTE: The 'include' statement that is used in YANG for including
submodules has in fact the same semantics as the <rng:include>
pattern. However, since we don't map the modular structure for YANG
modules, it seems to have little sense to do it for submodules.
Consequently, the contents of submodules appear directly in the
conceptual tree schema, too.
Lhotka, et al. Expires August 15, 2009 [Page 21]
Internet-Draft Mapping YANG to DSDL February 2009
6.3. Granularity
RELAX NG supports different styles of schema structuring: One
extreme, often called "Russian Doll", specifies the structure of an
XML instance document in a single hierarchy. The other extreme, the
flat style, uses a similar approach as the Data Type Definition (DTD)
schema language - every XML element is introduced inside a new named
pattern. In practice, some compromise between the two extremes is
usually chosen.
YANG supports both styles in principle, too, but in most cases the
modules are organized in a way that's closer to the "Russian Doll"
style, which provides a better insight into the structure of the
configuration data. Groupings are usually defined only for contents
that are prepared for reuse in multiple places via the 'uses'
statement. In contrast, RELAX NG schemas tend to be much flatter,
because finer granularity is also needed in RELAX NG for
extensibility of the schemas - it is only possible to replace or
modify schema fragments that are factored out as named patterns. For
YANG this is not an issue since its 'augment' and 'refine' statements
can delve, by using path expressions, into arbitrary depths of
existing structures.
In general, it not feasible to map YANG extension mechanisms to those
of RELAX NG. For this reason, the mapping essentially keeps the
granularity of the original YANG data model: definitions of named
patterns in the resulting RELAX NG schema usually have direct
counterparts in YANG groupings and definitions of derived types.
Lhotka, et al. Expires August 15, 2009 [Page 22]
Internet-Draft Mapping YANG to DSDL February 2009
7. Mapping Data Model Structure to the Conceptual Tree Schema
This section explains the main principles underlying the first step
of the mapping. Details about mapping individual YANG statements are
contained in Section 10.
7.1. Optional and Mandatory Content
In YANG, all leaf nodes are optional unless they contain substatement
mandatory true;
or unless they are declared as list keys.
Lists or leaf-lists are optional unless they contain 'min-elements'
substatement with argument value greater than zero.
A slightly more complicated situation arises for YANG containers.
First, containers with the 'presence' substatement are always
optional since their presence or absence carries specific
information. On the other hand, non-presence containers may be
omitted if they are empty. For the purposes of the YANG-to-DSDL
mapping, we declare a non-presence container as optional if and only
if the following two conditions hold:
1. none of its descendant leaf nodes is mandatory or, if such a leaf
exists, it is enclosed in an intervening container with presence;
2. none of its descendant list or leaf-list nodes has 'min-elements'
substatement with argument value greater than zero or, if such a
list or leaf-list exists, it is enclosed in an intervening
container with presence.
In RELAX NG, all elements that are optional must be explicitly
wrapped in the <rng:optional> element. The mapping algorithm thus
uses the above rules to determine whether a YANG node is optional and
if so, insert the <rng:optional> element in the RELAX NG schema.
7.2. Mapping YANG Groupings and Typedefs
YANG groupings and typedefs are generally mapped to RELAX NG named
patterns. There are, however, several caveats that the mapping has
to take into account.
First of all, YANG typedefs and groupings may appear at all levels of
the module hierarchy and are subject to lexical scoping, see [5],
Section 5.5. Moreover, top-level symbols from external modules are
imported as qualified names represented using the external module
Lhotka, et al. Expires August 15, 2009 [Page 23]
Internet-Draft Mapping YANG to DSDL February 2009
namespace prefix and the name of the symbol. In contrast, named
patterns in RELAX NG (both local and imported via the <rng:include>
pattern) share the same namespace and within a grammar they are
always global - their definitions may only appear at the top level as
children of the <rng:grammar> element. Consequently, whenever YANG
groupings and typedefs are mapped to RELAX NG named pattern
definitions, their names MUST be disambiguated in order to avoid
naming conflicts. The mapping uses the following procedure for
mangling the names of groupings and type definitions:
o Names of groupings and typedefs appearing at the _top level_ of
the YANG module hierarchy are prefixed with the module name and
two underscore characters ("__").
o Names of other groupings and typedefs, i.e., those that do not
appear at the top level of a YANG module, are prefixed with the
module name, double underscore, and then the names of all ancestor
data nodes separated by double underscore.
For example, consider the following YANG module which imports the
standard module "inet-types" [19]:
Lhotka, et al. Expires August 15, 2009 [Page 24]
Internet-Draft Mapping YANG to DSDL February 2009
module example1 {
namespace "http://example.com/ns/example1";
prefix "ex1";
import "inet-types" {
prefix "inet";
}
typedef vowels {
type string {
pattern "[aeiouy]*";
}
}
grouping "grp1" {
leaf "void" {
type "empty";
}
}
container "cont" {
grouping "grp2" {
leaf "address" {
type "inet:ip-address";
}
}
leaf foo {
type vowels;
}
uses "grp1";
uses "grp2";
}
}
The resulting RELAX NG schema will then contain the following named
pattern definitions (long regular expression patterns for IPv4 and
IPv6 addresses are not shown):
Lhotka, et al. Expires August 15, 2009 [Page 25]
Internet-Draft Mapping YANG to DSDL February 2009
<rng:define name="example1__vowels">
<rng:data type="string">
<rng:param name="pattern">[aeiouy]*</param>
</rng:data>
</rng:define>
<rng:define name="example1__grp1">
<rng:optional>
<rng:element name="t:void">
<rng:empty/>
</rng:element>
</rng:optional>
</rng:define>
<rng:define name="example1__cont__grp2">
<rng:optional>
<rng:element name="t:address">
<rng:ref name="inet-types__ip-address"/>
</rng:element>
</rng:optional>
</rng:define>
<rng:define name="inet-types__ip-address">
<rng:choice>
<rng:ref name="inet-types__ipv4-address"/>
<rng:ref name="inet-types__ipv6-address"/>
</rng:choice>
</rng:define>
<rng:define name="inet-types__ipv4-address">
<rng:data type="string">
<rng:param name="pattern">... removed ...</param>
</rng:data>
</rng:define>
<rng:define name="inet-types__ipv6-address">
<rng:data type="string">
<rng:param name="pattern">... removed ...</param>
</rng:data>
</rng:define>
7.2.1. YANG Refinements and Augments
YANG groupings represent a similar concept as named pattern
definitions in RELAX NG and both languages also offer mechanisms for
their subsequent modification. However, in RELAX NG the definitions
themselves are modified whereas YANG allows for modifying
_expansions_ of groupings. Specifically, YANG provides two
Lhotka, et al. Expires August 15, 2009 [Page 26]
Internet-Draft Mapping YANG to DSDL February 2009
statements for this purpose that may appear as substatements of
'uses':
o 'refine' statement allows for changing parameters of a schema node
inside the grouping referenced by the parent 'uses' statement;
o 'augment' statement can be used for adding new schema nodes to the
grouping content.
Both 'refine' and 'augment' statements are quite powerful in that
they can address, using a subset of XPath 1.0 expressions as
arguments, schema nodes that are arbitrarily deep inside the grouping
content. In contrast, definitions of named patterns in RELAX NG
operate exclusively at the topmost level of the named pattern
content. In order to achieve a modifiability of named patterns
comparable to YANG, the RELAX NG schema would have to be extremely
flat (cf. Section 6.3) and very difficult to read.
Since the goal of the mapping described in this document is to
generate ad hoc DSDL schemas, we decided to avoid these complications
and instead expand the grouping and refine and/or augment it "in
place". In other words, every 'uses' statement which has 'refine'
and/or 'augment' substatements is virtually replaced by the content
of the corresponding grouping, the changes specified in the 'refine'
and 'augment' statements are applied and the resulting YANG schema
fragment is mapped as if the 'uses'/'grouping' indirection wasn't
there.
If there are further 'uses' statements inside the grouping content,
they may require expansion, too: it is necessary if the contained
'uses'/'grouping' pair lies on the "modification path" specified in
the argument of a 'refine' or 'augment' statement.
EXAMPLE. Consider the following YANG module:
Lhotka, et al. Expires August 15, 2009 [Page 27]
Internet-Draft Mapping YANG to DSDL February 2009
module example2 {
namespace "http://example.com/ns/example2";
prefix ex2;
grouping leaves {
uses fr;
uses es;
}
grouping fr {
leaf feuille {
type string;
}
}
grouping es {
leaf hoja {
type string;
}
}
uses leaves;
}
The resulting conceptual tree schema contains three named pattern
definitions corresponding to the three groupings, namely
<rng:define name="example2__leaves">
<rng:ref name="example2__fr"/>
<rng:ref name="example2__es"/>
</rng:define>
<rng:define name="example2__fr">
<rng:optional>
<rng:element name="feuille">
<rng:data type="string"/>
</rng:element>
</rng:optional>
</rng:define>
<rng:define name="example2__es">
<rng:optional>
<rng:element name="hoja">
<rng:data type="string"/>
</rng:element>
</rng:optional>
</rng:define>
and the configuration data part of the conceptual tree schema will be
a single named pattern reference:
Lhotka, et al. Expires August 15, 2009 [Page 28]
Internet-Draft Mapping YANG to DSDL February 2009
<rng:ref name="example2__leaves"/>
Now assume that the "leave" expansion is refined:
uses leaves {
refine "hoja" {
default "alamo";
}
}
The resulting conceptual tree schema now contains just one named
pattern definition - "example__fr". The other two groupings "leaves"
and "es" have to be expanded because they both lie on the
"modification path", i.e., contain the leaf "hoja" that is being
refined. The configuration data part of the conceptual tree now
looks like this:
<rng:ref name="example2__fr"/>
<rng:optional>
<rng:element name="hoja" nma:default="alamo">
<rng:data type="string"/>
</rng:element>
</rng:optional>
7.2.2. Type derivation chains
RELAX NG has no equivalent of the type derivation mechanism in YANG,
where a base built-in type may be modified (in multiple steps) by
adding new restrictions. Therefore, when mapping YANG derived types
with restrictions, the derived types MUST be "unwound" all the way
back to the base built-in type. At the same time, all restrictions
found along the type derivation chain MUST be combined and their
intersection used as facets restricting the corresponding type in
RELAX NG.
When a derived YANG type is used without restrictions, the 'type'
statement is mapped simply to the <rng:ref> element, i.e., a named
pattern reference. However, if restrictions are specified as
substatements of the 'type' statement, the type MUST be expanded at
that point so that only the built-in type appears in the output
schema, restricted with facets that again correspond to the
combination of all restrictions found along the type derivation chain
and also in the 'type' statement.
EXAMPLE. Consider this YANG module:
Lhotka, et al. Expires August 15, 2009 [Page 29]
Internet-Draft Mapping YANG to DSDL February 2009
module example3 {
namespace "http://example.com/ns/example3";
prefix ex3;
typedef dozen {
type uint8 {
range 1..12;
}
}
leaf month {
type dozen;
}
The 'type' statement in "leaf month" is mapped simply to the
reference <rng:ref name="example__dozen"/> and the corresponding
named pattern is defined as follows:
<rng:define name="example3__dozen">
<rng:data type="unsignedByte">
<rng:param name="minInclusive">1</param>
<rng:param name="maxInclusive">12</param>
</rng:data>
</rng:define>
Assume now that the definition of leaf "month" is changed to
leaf month {
type dozen {
range 7..max;
}
}
The output RELAX NG schema then won't contain any named pattern
definition and leaf "month" will be mapped directly to
<rng:element name="month">
<rng:data type="unsignedByte">
<rng:param name="minInclusive">7</param>
<rng:param name="maxInclusive">12</param>
</rng:data>
</rng:element>
7.3. Translation of XPath Expressions
YANG uses full XPath 1.0 syntax [16] for the arguments of 'must' and
'when' statements and a subset thereof in several other statements.
However, since the names of data nodes defined by YANG modules are
always namespace qualified, YANG adopted a simplification similar to
the concept of _default namespace_ in XPath 2.0: node names needn't
Lhotka, et al. Expires August 15, 2009 [Page 30]
Internet-Draft Mapping YANG to DSDL February 2009
carry a namespace prefix inside the module where they are defined, in
which case the module's namespace is assumed.
If an XPath expression is carried over to a NETMOD-specific
annotation in the first mapping step, it MUST be translated into a
fully conformant XPath 1.0 expression that also reflects the
hierarchy of the conceptual data tree:
1. Each unprefixed node name MUST be prepended with the local
module's namespace prefix declared by the 'prefix' statement.
2. Absolute XPath expressions, i.e., those starting with a slash,
MUST be prepended with appropriate path in the conceptual tree,
according to the YANG specification of context for XPath
expressions, see [16], sections 7.5.3 and 7.19.5.
Translation rule 2 means that absolute XPath expressions appearing in
the main configuration data tree always start with "nmt:netmod-tree/
nmt:main/", those appearing in "my-notif" notification always start
with "nmt:netmod-tree/nmt:notifications/
nmt:notification[@name='my-notif']/", etc.
EXAMPLE. YANG XPath expression "/dhcp/max-lease-time" appearing in
the main configuration data will be translated to "nmt:netmod-tree/
nmt:main/dhcp:dhcp/dhcp:max-lease-time".
[Editor's note: We may want to introduce "$root" variable that always
contains the appropriate partial path in conceptual tree. The
translated XPath in the example would then become "$root/dhcp:dhcp/
dhcp:max-lease-time".]
7.4. YANG Language Extensions
YANG allows for extending its own language in-line by adding new
statements with keywords from special namespaces. Such extensions
first have to be declared using the 'extension' statement and then
can be used as the native statements, only with a namespace prefix
qualifying the extension keyword. RELAX NG has a similar extension
mechanism - XML elements and attributes with names from foreign
namespaces may be inserted at almost every place of a RELAX NG
schema.
YANG language extensions may or may not have a meaning in the context
of DSDL schemas. Therefore, an implementation MAY ignore any or all
of the extensions. However, an extension that is not ignored MUST be
mapped to XML element(s) and/or attribute(s) that exactly match the
YIN form of the extension.
Lhotka, et al. Expires August 15, 2009 [Page 31]
Internet-Draft Mapping YANG to DSDL February 2009
EXAMPLE. Consider the following extension defined by the "acme"
module:
extension documentation-flag {
argument number;
}
This extension can then be used in the same or another module, for
instance like this:
leaf folio {
acme:documentation-flag 42;
type string;
}
If this extension is honored by the mapping, it will be mapped to
<rng:element name="folio">
<acme:documentation-flag number="42"/>
<rng:data type="string"/>
</rng:element>
Note that the 'extension' statement itself is not mapped in any way.
7.5. RPC Signatures and Notifications
In the conceptual tree schema, YANG definitions of RPC methods are
mapped to the subtree under "/nmt:netmod-tree/nmt:rpc-methods". Each
RPC method corresponds to one subelement of <nmt:rpc-methods>, namely
<nmt:rpc-method name="..."> where the value of the @name attribute is
set to the name of the method. In turn, the <nmt:rpc-method> element
has two subelements, <nmt:input> and <nmt:output> (both are optional)
that contain input and input parameters of the given RPC method,
respectively.
Analogically, the content of each notification is mapped inside the
element <nmt:notification name="...">, which is a subelement of
"/nmt:netmod-tree/nmt:notifications".
Lhotka, et al. Expires August 15, 2009 [Page 32]
Internet-Draft Mapping YANG to DSDL February 2009
8. Mapping Conceptual Tree Schema to DSDL
[Editor's note: This section is not finished yet. We need to write a
mapping specification for each of the NETMOD-specific annotations.]
8.1. Mapping Semantic Constraints to Schematron
TBD
8.1.1. Library of Schema-independent Schematron Patterns
This section outlines the schema-independent library of Schematron
patterns.
TBD
8.2. Mapping Default Values to DSRL
TBD
Lhotka, et al. Expires August 15, 2009 [Page 33]
Internet-Draft Mapping YANG to DSDL February 2009
9. NETCONF Content Validation
[Editor's note: This section is not finished yet. We have to figure
out what are the NETCONF objects we want to validate, and also the
validation contexts and modes. The concept of validation phases
outlined below is just one part of the problem. However, these
questions are not DSDL-specific and should be addressed by the WG.
One issue is DSDL-specific though: we have to find a way for
validating compound documents using both NETCONF and NETMOD schemas.
NVDL is a good candidate.]
9.1. Validation Phases
Validation of a configuration datastore or NETCONF PDUs may occur in
different logical phases, adding more tests with each phase. We use
three levels or phases for validating an instance document. There is
a level of validation which is appropriate even for loose XML
document fragments which still maintain their hierarchy (_fragment
phase_), another level of validation is appropriate for a cohesive
XML document which may however not be able to validate relational
integrity checks against some operational state (_standard phase_),
and finally there is validation which cover everything including all
relational integrity checks (_full validation phase_). For example,
in NETCONF an edit-config operation can cause the replacement a small
fragment of XML. A candidate configuration may be waiting for
application but can't check the readiness of a piece of hardware that
the configuration refers to.
From the NETCONF perspective, these three phases can be considered to
have the following scope:
1. the fragment phase: This can be run against individual NETCONF
operations.
2. the standard phase: This can be run against the candidate
configuration, but won't always pass.
3. the full validation phase: This can be run against a running
configuration.
During the Fragment phase validation it is verified that the content
is well-formed and appropriate to the operation.
During Standard phase validation (all rules except for leafref
checking):
o Verify that mandatory nodes are present.
Lhotka, et al. Expires August 15, 2009 [Page 34]
Internet-Draft Mapping YANG to DSDL February 2009
o Check the uniqueness for unique and key annotations.
o Print a warning if any manual validation rules are present.
During Full phase validation: add leafref checks.
The mechanism how the phase specification is passed to the Schematron
validator is outside the scope of this document. For example, it can
be accomplished via command line parameters.
<sch:phase id="fragment">
<sch:active pattern="lease-time"/>
<sch:active pattern="nonconfig"/>
</sch:phase>
<sch:phase id="std">
<sch:active pattern="lease-time"/>
<sch:active pattern="nonconfig"/>
<sch:active pattern="key"/>
</sch:phase>
<sch:phase id="full">
<sch:active pattern="lease-time"/>
<sch:active pattern="nonconfig"/>
<sch:active pattern="key"/>
<sch:active pattern="keyref"/>
</sch:phase>
Lhotka, et al. Expires August 15, 2009 [Page 35]
Internet-Draft Mapping YANG to DSDL February 2009
10. Mapping YANG Statements to Annotated RELAX NG
Each subsection in this section is devoted to one YANG statement and
describes how the statement is mapped to the annotated RELAX NG
schema of the conceptual tree. This is the first step of the mapping
procedure, see Section 5. The subsections are sorted alphabetically
by the statement keyword.
Each YANG statement is mapped to an XML fragment, typically a single
element or attribute but it may also be a larger structure. The
mapping algorithm is inherently recursive, which means that after
finishing a statement the mapping continues with its substatements,
if there are any, and a certain element of the resulting fragment
becomes the parent of other fragments resulting from the mapping of
substatements. We use the following notation:
o The argument of the statement being mapped is denoted by ARGUMENT.
o The element in the RELAX NG schema that becomes the parent of the
resulting XML fragment is denoted by PARENT.
10.1. The anyxml Statement
This statement is mapped to <rng:element> element and ARGUMENT
becomes the value of its @name attribute. The content of <rng:
element> is
<rng:ref name="__anyxml__"/>
Substatements of the 'anyxml' statement are mapped to additional
children of the RELAX NG element definition.
If the 'anyxml' statement occurs in any of the input YANG modules,
the following pattern definition MUST be added exactly once to the
RELAX NG schema as a child of the <rng:grammar> element (cf. [20], p.
172):
Lhotka, et al. Expires August 15, 2009 [Page 36]
Internet-Draft Mapping YANG to DSDL February 2009
<rng:define name="__anyxml__">
<rng:zeroOrMore>
<rng:choice>
<rng:attribute>
<rng:anyName/>
</rng:attribute>
<rng:element>
<rng:anyName/>
<rng:ref name="__anyxml__"/>
</rng:element>
<rng:text/>
</rng:choice>
</rng:zeroOrMore>
</rng:define>
EXAMPLE: YANG statement
anyxml data {
description "Any XML content allowed here.";
}
maps to the following fragment:
<rng:element name="data">
<a:documentation>Any XML content allowed here</a:documentation>
<rng:ref name="__anyxml__"/>
</rng:element>
10.2. The argument Statement
This statement is not mapped to the output schema, but see the rules
for extension handling in Section 7.4.
10.3. The augment Statement
As a substatement of 'uses', this statement is handled as a part of
'uses' mapping, see Section 10.54.
At the top level of a module or submodule, the 'augment' statement is
used for augmenting the schema tree of another YANG module. If the
latter module is not processed within the same mapping session, the
top-level 'augment' statement MUST be ignored. Otherwise, the
contents of the statement are added to the foreign module with the
namespace of the module where the 'augment' statement appears.
Lhotka, et al. Expires August 15, 2009 [Page 37]
Internet-Draft Mapping YANG to DSDL February 2009
10.4. The base Statement
This statement is ignored as a substatement of 'identity' and handled
within the 'identityref' type if it appears as a substatement of that
type definition, see Section 10.50.5.
10.5. The belongs-to Statement
This statement is not used since processing of submodules is always
initiated from the main module, see Section 10.21.
10.6. The bit Statement
Handled within the "bits" type, see Section 10.50.3.
10.7. The case Statement
This statement is mapped to <rng:group> element. If the argument of
a sibling 'default' statement equals to ARGUMENT, @nma:default-case
attribute with the value of "true" is added to that <rng:group>
element.
10.8. The choice Statement
This statement is mapped to <rng:choice> element.
Unless 'choice' has the 'mandatory' substatement with the value of
"true", the <rng:choice> element MUST be wrapped in <rng:optional>.
10.9. The config Statement
This statement is mapped to @nma:config attribute and ARGUMENT
becomes its value.
10.10. The contact Statement
This statement is not used by the mapping since the output RELAX NG
schema may result from multiple YANG modules created by different
authors. The schema contains references to all input modules in the
Dublin Core elements <dc:source>, see Section 10.31. The original
modules are the authoritative sources of the authorship information.
10.11. The container Statement
Using the procedure outlined in Section 7.1, the mapping algorithm
MUST determine whether the statement defines an optional container,
and if so, insert the <rng:optional> element and make it the new
PARENT.
Lhotka, et al. Expires August 15, 2009 [Page 38]
Internet-Draft Mapping YANG to DSDL February 2009
The container defined by this statement is then mapped to the <rng:
element> element, which becomes a child of PARENT and uses ARGUMENT
as the value of its @name attribute.
10.12. The default Statement
If this statement is a substatement of 'typedef' or 'leaf', it is
mapped to the @nma:default attribute of PARENT and ARGUMENT becomes
its value.
As a substatement of 'choice', the 'default' statement identifies the
default case and is handled within the 'case' statement, see
Section 10.7. If the default case uses the shorthand notation where
the 'case' statement is omitted, an extra <rng:group> element MUST be
inserted with @nma:default-case attribute set to "true". The net
result is then the same as if the 'case' statement wasn't omitted for
the default case.
EXAMPLE. The following 'choice' statement
choice leaves {
default feuille;
leaf feuille { type empty; }
leaf hoja { type empty; }
}
is mapped to
<rng:choice>
<rng:group nma:default="true">
<rng:element name="feuille">
<rng:empty/>
</rng:element>
</rng:group>
<rng:element name="hoja">
<rng:empty/>
</rng:element/>
</rng:choice>
10.13. The description Statement
This statement is ignored if it appears at the top level of each
input YANG module. The description can be found in the source module
that is referred to by Dublin Core element <dc:source> and use
ARGUMENT as its content.
Otherwise, this statement is mapped to the DTD compatibility element
<a:documentation> and ARGUMENT becomes its text.
Lhotka, et al. Expires August 15, 2009 [Page 39]
Internet-Draft Mapping YANG to DSDL February 2009
In order to get properly formatted in the RELAX NG compact syntax,
this element SHOULD be inserted as the first child of PARENT.
10.14. The enum Statement
This statement is mapped to <rng:value> element and ARGUMENT becomes
its text. All substatements except 'status' are ignored because the
<rng:value> element cannot contain annotations, see [10], Section 6.
10.15. The error-app-tag Statement
This statement is ignored unless it is a substatement of 'must'. In
the latter case it is mapped to the <nma:error-app-tag> element. See
also Section 10.32.
10.16. The error-message Statement
This statement is ignored unless it is a substatement of 'must'. In
the latter case it is mapped to the <nma:error-message> element. See
also Section 10.32.
10.17. The extension Statement
This statement is ignored. However, extensions to the YANG language
MAY be mapped as described in Section 7.4.
10.18. The grouping Statement
This statement is mapped to a RELAX NG named pattern definition <rng:
define>, but only if the grouping defined by this statement is used
_without refinements and augments_ in at least one of the input
modules. In this case, the named pattern definition becomes a child
of the <rng:grammar> element and its name is ARGUMENT mangled
according to the rules specified in Section 7.2.
Whenever a grouping is used with additional refinements and/or
augments, the grouping is expanded so that the refinements and
augments may be applied directly to the prescribed schema nodes. See
Section 7.2.1 for further details and an example.
An implementation MAY offer the option of recording all 'grouping'
statements as named patterns in the output RELAX NG schema even if
they are not referenced. This is useful for mapping YANG "library"
modules containing only 'typedef' and/or 'grouping' statements.
Lhotka, et al. Expires August 15, 2009 [Page 40]
Internet-Draft Mapping YANG to DSDL February 2009
10.19. The identity Statement
This statement is not specifically mapped. However, if the identity
defined by this statement is used as the base for an "identityref"
type in any of the input modules, ARGUMENT will appear as the text of
one of the <rng:value> elements in the mapping of that "identityref"
type. See Section 10.50.5 for more details and an example.
10.20. The import Statement
This statement is not specifically mapped. The module whose name is
in ARGUMENT has to be parsed so that the importing module be able to
use its top-level groupings and typedefs and also augment the data
tree of the imported module.
If the 'import' statement has the 'revision' substatement, the
corresponding revision of the imported module MUST be used. The
mechanism for finding a given module revision is outside the scope of
this document.
10.21. The include Statement
This statement is not specifically mapped. The submodule whose name
is in ARGUMENT has to be parsed and its contents mapped exactly as if
the submodule text was a subset of the main module text.
If the 'include' statement has the 'revision' substatement, the
corresponding revision of the submodule MUST be used. The mechanism
for finding a given submodule revision is outside the scope of this
document.
10.22. The input Statement
This statement is mapped to <rng:element> and its @name attribute is
set to "nmt:input".
10.23. The key Statement
This statement is mapped to @nma:key attribute and ARGUMENT becomes
the value of this attribute.
10.24. The leaf Statement
This statement is mapped to the <rng:element> element and ARGUMENT
becomes the value of its @name attribute.
The leaf is optional if there is no "mandatory true;" substatement
and if the leaf is not declared among the keys of an enclosing list.
Lhotka, et al. Expires August 15, 2009 [Page 41]
Internet-Draft Mapping YANG to DSDL February 2009
In this case, the <rng:element> element MUST be wrapped in <rng:
optional>.
10.25. The leaf-list Statement
This statement is mapped to a block enclosed by either <rng:
zeroOrMore> or <rng:oneOrMore> element depending on whether the
argument of 'min-elements' substatement is "0" or positive,
respectively (it is zero by default). This <rng:zeroOrMore> or <rng:
oneOrMore> element becomes the PARENT.
Further, if the argument of 'min-elements' is greater than one,
attribute @nma:min-elements is attached to PARENT and the argument of
'min-elements' becomes the value of this attribute.
If there is the 'max-elements' substatement, attribute @nma:max-
elements is attached to PARENT and the argument of 'max-elements'
becomes the value of this attribute.
Then <rng:element> is added as a child element of PARENT and ARGUMENT
becomes the value of its @name attribute.
EXAMPLE. YANG leaf-list
leaf-list foliage {
min-elements 3;
max-elements 6378;
ordered-by user;
type string;
}
is mapped to the following RELAX NG fragment:
<rng:oneOrMore nma:max-elements="6378"
nma:min-elements="3">
<rng:element name="foliage" nma:ordered-by="user">
<rng:data type="string"/>
</rng:element>
</rng:oneOrMore>
10.26. The length Statement
Handled within the "string" type, see Section 10.50.9.
10.27. The list Statement
This statement is mapped exactly as the 'leaf-list' statement, see
Section 10.25.
Lhotka, et al. Expires August 15, 2009 [Page 42]
Internet-Draft Mapping YANG to DSDL February 2009
10.28. The mandatory Statement
This statement may appear as a substatement of 'leaf', 'choice' or
'anyxml' statement. If ARGUMENT is "true", the parent data node is
mapped as mandatory, see Section 7.1.
10.29. The max-elements Statement
This statement is handled within 'leaf-list' or 'list' statements,
see Section 10.25.
10.30. The min-elements Statement
This statement is handled within 'leaf-list' or 'list' statements,
see Section 10.25.
10.31. The module Statement
This statement is not specifically mapped except that a <dc:source>
element SHOULD be created as a child of <rng:grammar> and contain
ARGUMENT as a reference to the input YANG module. See also
Section 10.46.
With respect to the conceptual tree schema, substatements of 'module'
MUST be mapped so that
o top level data elements be defined as children of the <nmt:top>
element;
o elements mapped from 'rpc' statements be defined as children of
the <nmt:rpc-methods> element;
o elements mapped from 'notification' statements be defined as
children of the <nmt:notifications> element.
10.32. The must Statement
This statement is mapped to the <nma:must> element. It has one
mandatory attribute @assert (with no namespace), which contains
ARGUMENT transformed into a valid XPath expression (see Section 7.3).
The <nma:must> element may get other subelements resulting from
mapping 'error-app-tag' and 'error-message' substatements. Other
substatements of 'must', i.e., 'description' and 'reference', are
ignored.
EXAMPLE. YANG statement
Lhotka, et al. Expires August 15, 2009 [Page 43]
Internet-Draft Mapping YANG to DSDL February 2009
must 'current() <= ../max-lease-time' {
error-message
"The default-lease-time must be less than max-lease-time";
}
is mapped to
<nma:must assert="current()<=../dhcp:max-lease-time">
<nma:error-message>
The default-lease-time must be less than max-lease-time
</nma:error-message>
</nma:must>
10.33. The namespace Statement
ARGUMENT of this statement - namespace URI of the input module - is
mapped to an XML attribute of the <rng:grammar> element (the root of
the RELAX NG schema) in the following way:
1. For one of the input modules, its namespace URI MAY become the
value of the @ns attribute.
2. For the remaining input modules, the namespace URI becomes the
value of the @xmlns:xxx attribute where "xxx" is a unique prefix,
which SHOULD be set to the argument of the 'prefix' statement in
the same module (see Section 10.41).
In case 2, names of all data nodes appearing as values of the @name
attribute of the <rng:element> elements in the RELAX NG schema MUST
use the given prefix whereas in case 1 the values have no prefix.
Namespace URI of all input modules MAY be mapped using the method in
2. The advantage of this approach is that the recommended prefixes
are recorded in the output RELAX NG schema for all input modules.
EXAMPLE: Assume we have the following two YANG modules as input:
module foo-module {
namespace "http://example.com/ns/foo";
prefix foo;
...
}
and
Lhotka, et al. Expires August 15, 2009 [Page 44]
Internet-Draft Mapping YANG to DSDL February 2009
module bar-module {
namespace "http://example.com/ns/bar";
prefix bar;
...
}
The <rng:grammar> element in the output schema may then be either
<rng:grammar xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:foo="http://example.com/ns/foo"
xmlns:bar="http://example.com/ns/bar"
...
>
...
</rng:grammar>
or
<rng:grammar xmlns="http://relaxng.org/ns/structure/1.0"
ns="http://example.com/ns/foo"
xmlns:bar="http://example.com/ns/bar"
...
>
...
</rng:grammar>
The third possibility is analogical to the previous one, only with
the roles of "foo" and "bar" exchanged.
10.34. The notification Statement
This element is mapped to <rng:element> and its @name attribute is
set to "nmt:notification" element. This element is defined as a
child of the <nmt:notifications> element in the conceptual tree.
10.35. The ordered-by Statement
This statement is mapped to @nma:ordered-by attribute and ARGUMENT
becomes the value of this attribute. See Section 10.25 for an
example.
10.36. The organization Statement
This statement is not used by the mapping since the output RELAX NG
schema may result from multiple YANG modules authored by different
parties. The schema contains references to all input modules in the
Dublin Core elements <dc:source>, see Section 10.31. The original
modules are the authoritative sources of the authorship information.
Lhotka, et al. Expires August 15, 2009 [Page 45]
Internet-Draft Mapping YANG to DSDL February 2009
10.37. The output Statement
This statement is mapped to <rng:element> and its @name attribute is
set to "nmt:output".
10.38. The path Statement
Handled within "leafref" type, see Section 10.50.7.
10.39. The pattern Statement
Handled within "string" type, see Section 10.50.9.
10.40. The position Statement
This statement is ignored.
10.41. The prefix Statement
ARGUMENT of this statement - the recommended namespace prefix for the
input module - MAY be mapped to a namespace prefix declared using the
@xmlns:xxx attribute of the <rng:grammar> element in the output
schema, where "xxx" is replaced by ARGUMENT. For multiple input
modules, the mapping of prefixes depends on how their namespace URIs
are used, see Section 10.33.
10.42. The presence Statement
This statement influences the mapping of 'container' (Section 10.11):
it makes the parent container optional, regardless of its content.
See also Section 7.1.
10.43. The range Statement
Handled within numeric types, see Section 10.50.8.
10.44. The reference Statement
This statement is ignored if it appears at the top level of a module
or submodule.
Otherwise, this statement is mapped to <a:documentation> element and
its text is set to ARGUMENT prefixed with "See: ".
10.45. The require-instance Statement
Handled within the types "leafref" (Section 10.50.7) and "instance-
identifier" (Section 10.50.6).
Lhotka, et al. Expires August 15, 2009 [Page 46]
Internet-Draft Mapping YANG to DSDL February 2009
10.46. The revision Statement
The mapping uses only the most recent instance of the 'revision'
statement, i.e., one with the latest date in ARGUMENT, which
specifies the current revision of the input YANG module [5]. This
date SHOULD be recorded, together with the name of the YANG module,
in the corresponding Dublin Core element <dc:source> (see
Section 10.31), for example in this form:
<dc:source>YANG module 'foo', revision 2009-01-19</dc:source>
The 'description' substatement of 'revision' is not used.
10.47. The rpc Statement
This element is mapped to <rng:element> and its @name attribute is
set to "nmt:rpc-method" element. This element is defined as a child
of the <nmt:rpc-methods> element in the conceptual tree.
10.48. The status Statement
This statement is mapped to @nma:status attribute and ARGUMENT
becomes its value.
10.49. The submodule Statement
This statement is not specifically mapped. Its substatements are
mapped as if they appeared directly in the module the submodule
belongs to.
10.50. The type Statement
Most YANG built-in types have an equivalent in the XSD datatype
library [14] as shown in Table 3.
Lhotka, et al. Expires August 15, 2009 [Page 47]
Internet-Draft Mapping YANG to DSDL February 2009
+-----------+---------------+----------------------------------+
| YANG type | XSD type | Meaning |
+-----------+---------------+----------------------------------+
| int8 | byte | 8-bit integer value |
| | | |
| int16 | short | 16-bit integer value |
| | | |
| int32 | int | 32-bit integer value |
| | | |
| int64 | long | 64-bit integer value |
| | | |
| uint8 | unsignedByte | 8-bit unsigned integer value |
| | | |
| uint16 | unsignedShort | 16-bit unsigned integer value |
| | | |
| uint32 | unsignedInt | 32-bit unsigned integer value |
| | | |
| uint64 | unsignedLong | 64-bit unsigned integer value |
| | | |
| float32 | float | 32-bit IEEE floating-point value |
| | | |
| float64 | double | 64-bit IEEE floating-point value |
| | | |
| string | string | character string |
| | | |
| boolean | boolean | "true" or "false" |
| | | |
| binary | base64Binary | binary data in base64 encoding |
+-----------+---------------+----------------------------------+
Table 3: Selected datatypes from the W3C XML Schema Type Library
Details about the mapping of individual YANG built-in types are given
in the following subsections.
10.50.1. The empty Type
This type is mapped to <rng:empty/>.
10.50.2. The boolean and binary Types
These two built-in types do not allow any restrictions and are mapped
simply by inserting <rng:data> element whose @type attribute is set
to ARGUMENT mapped according to Table 3.
Lhotka, et al. Expires August 15, 2009 [Page 48]
Internet-Draft Mapping YANG to DSDL February 2009
10.50.3. The bits Type
This type is mapped to <rng:list> and for each 'bit' substatement the
following XML fragment is inserted as a child of <rng:list>:
<rng:optional>
<rng:value>bit_name</rng:value>
</rng:optional>
where bit_name is the name of the bit as found in the argument of the
corresponding 'bit' statement.
10.50.4. The enumeration and union Types
These types are mapped to <rng:choice> element.
10.50.5. The identityref Type
This type is mapped to <rng:choice> element with one or more <rng:
value> subelements. Each of the <rng:value> subelements MUST have a
@type attribute and its value set to "QName". One <rng:value>
subelement with argument of the 'base' substatement as its text MUST
always be present. In addition, one <rng:value> substatement MUST be
added for each identity declared locally or in an imported module
that has the argument of the 'base' substatement as its base
identity.
All namespace prefixes that are used for identities from imported
modules MUST be appropriately defined.
EXAMPLE (taken from [5], Section 7.6.13). Consider the following two
YANG modules:
Lhotka, et al. Expires August 15, 2009 [Page 49]
Internet-Draft Mapping YANG to DSDL February 2009
module crypto-base {
namespace "http://example.com/crypto-base";
prefix "crypto";
identity crypto-alg {
description
"Base identity from which all crypto algorithms
are derived.";
}
}
module des {
namespace "http://example.com/des";
prefix "des";
import "crypto-base" {
prefix "crypto";
}
identity des {
base "crypto:crypto-alg";
description "DES crypto algorithm";
}
identity des3 {
base "crypto:crypto-alg";
description "Triple DES crypto algorithm";
}
}
If these two modules are imported to another module, leaf definition
leaf crypto {
type identityref {
base "crypto:crypto-alg";
}
}
is mapped to
<rng:element name="crypto">
<rng:choice>
<rng:value type="QName">crypto:crypto-alg</value>
<rng:value type="QName">des:des</value>
<rng:value type="QName">des:des3</value>
</rng:choice>
</rng:element>
Lhotka, et al. Expires August 15, 2009 [Page 50]
Internet-Draft Mapping YANG to DSDL February 2009
The "crypto" and "des" prefixes will by typically defined via
attributes of the <rng:grammar> element.
10.50.6. The instance-identifier Type
This type is mapped to <rng:data> element with @type attribute set to
"string". In addition, empty <nma:instance-identifier> element MUST
be inserted as a child of PARENT.
The 'require-instance' substatement, if it exists, is mapped to the
@require-instance attribute of <nma:instance-identifier>.
10.50.7. The leafref Type
This type is mapped to <rng:data> element with @type attribute set to
the type of the leaf given in the argument of 'path' substatement.
In addition, <nma:leafref> element MUST be inserted as a child of
PARENT. The argument value of the 'path' substatement is set as the
text of this element.
The 'require-instance' substatement, if it exists, is mapped to the
@require-instance attribute of <nma:leafref>.
10.50.8. The numeric Types
YANG built-in numeric types are "int8", "int16", "int32", "int64",
"uint8", "uint16", "uint32", "uint64", "float32" and "float64". They
are mapped to <rng:data> element with @type attribute set to ARGUMENT
mapped according to Table 3.
All numeric types support the 'range' restriction, which is handled
in the following way:
o If the range expression consists of a single range part, insert
the pair of RELAX NG facets
<rng:param name="minInclusive">...</rng:param>
and
<rng:param name="maxInclusive">...</rng:param>
Their contents are the lower and upper bound of the range part,
respectively. If the range part consists of a single number, both
"minInclusive" and "maxInclusive" facets use this value as their
content. If the lower bound is "min", the "minInclusive" facet is
omitted and if the upper bound is "max", the "maxInclusive" facet
is omitted.
Lhotka, et al. Expires August 15, 2009 [Page 51]
Internet-Draft Mapping YANG to DSDL February 2009
o If the range expression has multiple parts separated by "|", then
repeat the <rng:data> element once for every range part and wrap
them all in <rng:choice> element. Each <rng:data> element
contains the "minInclusive" and "maxInclusive" facets for one part
of the range expression as described in the previous item.
For example, the 'typedef' statement
typedef rt {
type int32 {
range "-6378..0|42|100..max";
}
}
appearing at the top level of the "example" module is mapped to the
following RELAX NG fragment:
<rng:define name="example__rt">
<rng:choice>
<rng:data type="int">
<rng:param name="minInclusive">-6378</rng:param>
<rng:param name="maxInclusive">0</rng:param>
</rng:data>
<rng:data type="int">
<rng:param name="minInclusive">42</rng:param>
<rng:param name="maxInclusive">42</rng:param>
</rng:data>
<rng:data type="int">
<rng:param name="minInclusive">100</rng:param>
</rng:data>
</rng:choice>
</rng:define>
10.50.9. The string Type
This type is mapped to <rng:data> element with the @type attribute
set to "string".
For the 'pattern' restriction, insert <rng:param> element with @name
attribute set to "pattern". The argument of the 'pattern' statement
(regular expression) becomes the content of this element.
The 'length' restriction is handled in the same way as the 'range'
restriction for the numeric types, with the additional twist that if
the length expression has multiple parts, the "pattern" facet
<rng:param name="pattern">...</rng:param>
Lhotka, et al. Expires August 15, 2009 [Page 52]
Internet-Draft Mapping YANG to DSDL February 2009
if there is any, must be repeated inside each copy of the <rng:data>
element, i.e., for each length part.
10.50.10. Derived Types
If the 'type' statement refers to a derived type, it is mapped in one
of the following ways depending on whether it contains any
restrictions as its substatements:
1. Without restrictions, the 'type' statement is mapped simply to
the <rng:ref> element, i.e., a reference to a named pattern. If
the RELAX NG definition of this named pattern has not been added
to the output schema yet, the corresponding 'typedef' must be
found and its mapping installed as a subelement of <rng:grammar>,
see Section 10.51. Even if a given derived type is used more
than once in the input YANG modules, the mapping of the
corresponding 'typedef' MUST be installed only once.
2. If any restrictions are present, the base type for the given
derived type must be determined and the mapping of this base type
is used. Restrictions appearing at all stages of the derivation
chain must be taken into account and their conjunction added to
the <rng:data> element which defines the basic type.
See Section 7.2.2 for more details and an example.
10.51. The typedef Statement
This statement is mapped to a RELAX NG named pattern definition <rng:
define>, but only if the type defined by this statement is used
_without restrictions_ in at least one of the input modules. In this
case, the named pattern definition becomes a child of the <rng:
grammar> element and its name is ARGUMENT mangled according to the
rules specified in Section 7.2.
Whenever a derived type is used with additional restrictions, the the
base type for the derived type is used instead with restrictions
(facets) that are a combination of all restrictions specified along
the type derivation chain. See Section 10.50.10 for further details
and an example.
An implementation MAY offer the option of recording all 'typedef'
statements as named patterns in the output RELAX NG schema even if
they are not referenced. This is useful for mapping YANG "library"
modules containing only 'typedef' and/or 'grouping' statements.
Lhotka, et al. Expires August 15, 2009 [Page 53]
Internet-Draft Mapping YANG to DSDL February 2009
10.52. The unique Statement
This statement is mapped to @nma:unique attribute and ARGUMENT
becomes its value.
10.53. The units Statement
This statement is mapped to @nma:units attribute and ARGUMENT becomes
its value.
10.54. The uses Statement
If this statement has neither 'refine' nor 'augment' substatements,
it is mapped to <rng:ref> element and the value of its @name
attribute is set to ARGUMENT mangled according to Section 7.2
If there are any 'refine' or 'augment' substatements, the
corresponding grouping must be looked up and its contents is inserted
as children of PARENT. See Section 7.2.1 for further details and an
example.
10.55. The value Statement
This statement is ignored.
10.56. The when Statement
This statement is mapped to @nma:when attribute and ARGUMENT becomes
it value.
10.57. The yang-version Statement
This statement is not mapped to the output schema. However, an
implementation SHOULD check that it is compatible with the YANG
version declared by the statement (currently version 1).
10.58. The yin-element Statement
This statement is not mapped to the output schema, but see the rules
for extension handling in Section 7.4.
Lhotka, et al. Expires August 15, 2009 [Page 54]
Internet-Draft Mapping YANG to DSDL February 2009
11. Mapping NETMOD-specific annotations to Schematron and DSRL
TBD
Lhotka, et al. Expires August 15, 2009 [Page 55]
Internet-Draft Mapping YANG to DSDL February 2009
12. IANA Considerations
This document registers two namespace URIs in the IETF XML registry
[21]:
URI: urn:ietf:params:xml:ns:netmod:dsdl-annotations:1
URI: urn:ietf:params:xml:ns:netmod:conceptual-tree:1
Lhotka, et al. Expires August 15, 2009 [Page 56]
Internet-Draft Mapping YANG to DSDL February 2009
13. References
[1] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006.
[2] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Network Management Protocol (SNMP)", STD 15, RFC 1157,
May 1990.
[3] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder,
Ed., "Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
[4] Elliott, C., Harrington, D., Jason, J., Schoenwaelder, J.,
Strauss, F., and W. Weiss, "SMIng Objectives", RFC 3216,
December 2001.
[5] Bjorklund, M., Ed., "YANG - A data modeling language for
NETCONF", draft-ietf-netmod-yang-03 (work in progress),
January 2009.
[6] ISO/IEC, "Document Schema Definition Languages (DSDL) - Part 1:
Overview", ISO/IEC 19757-1, 11 2004.
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[8] Clark, J., Ed. and M. Murata, Ed., "RELAX NG DTD
Compatibility", OASIS Committee Specification 3 December 2001,
December 2001.
[9] ISO/IEC, "Information Technology - Document Schema Definition
Languages (DSDL) - Part 8: Document Semantics Renaming Language
- DSRL", ISO/IEC 19757-8:2008(E), 12 2008.
[10] ISO/IEC, "Information Technology - Document Schema Definition
Languages (DSDL) - Part 2: Regular-Grammar-Based Validation -
RELAX NG. Second Edition.", ISO/IEC 19757-2:2008(E), 12 2008.
[11] ISO/IEC, "Information Technology - Document Schema Definition
Languages (DSDL) - Part 3: Rule-Based Validation - Schematron",
ISO/IEC 19757-3:2006(E), 6 2006.
[12] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML
Schema Part 1: Structures Second Edition", World Wide Web
Consortium Recommendation REC-xmlschema-1-20041028,
October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
Lhotka, et al. Expires August 15, 2009 [Page 57]
Internet-Draft Mapping YANG to DSDL February 2009
[13] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F.
Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth
Edition)", World Wide Web Consortium Recommendation REC-xml-
20060816, August 2006,
<http://www.w3.org/TR/2006/REC-xml-20060816>.
[14] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second
Edition", World Wide Web Consortium Recommendation REC-
xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[15] ISO/IEC, "Information Technology - Document Schema Definition
Languages (DSDL) - Part 2: Regular-Grammar-Based Validation -
RELAX NG. AMENDMENT 1: Compact Syntax", ISO/IEC 19757-2:2003/
Amd. 1:2006(E), 1 2006.
[16] Clark, J. and S. DeRose, "XML Path Language (XPath) Version
1.0", World Wide Web Consortium Recommendation REC-xpath-
19991116, November 1999,
<http://www.w3.org/TR/1999/REC-xpath-19991116>.
[17] Clark, J., "XSL Transformations (XSLT) Version 1.0", World Wide
Web Consortium Recommendation REC-xslt-19991116, November 1999.
[18] Kunze, J., "The Dublin Core Metadata Element Set", RFC 5013,
August 2007.
[19] Schoenwaelder, J., Ed., "Common YANG Data Types",
draft-ietf-netmod-yang-types-01 (work in progress),
November 2008.
[20] van der Vlist, E., "RELAX NG", O'Reilly , 2004.
[21] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[22] <http://www.thaiopensource.com/relaxng/trang.html>
[23] <http://dublincore.org/>
[24] <http://www.yang-central.org/twiki/bin/view/Main/DhcpTutorial>
[25] <http://thaiopensource.com/relaxng/trang.html>
Lhotka, et al. Expires August 15, 2009 [Page 58]
Internet-Draft Mapping YANG to DSDL February 2009
Appendix A. RELAX NG Schema for NETMOD-specific Annotations
This appendix contains the RELAX NG schema for the NETMOD-specific
annotations in both XML and compact syntax.
[Editor's note: It is currently only a set of named pattern
definitions as templates for the annotation elements and attributes.
We should find a way how to connect this to the schema for RELAX NG,
which these annotations extend. One option may be NVDL or it can
also be done as in the spec for DTD compatibility annotations.]
A.1. XML Syntax
<?xml version="1.0" encoding="UTF-8"?>
<grammar xmlns="http://relaxng.org/ns/structure/1.0"
ns="urn:ietf:params:xml:ns:netmod:dsdl-annotations:1"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<define name="config-attribute">
<attribute name="config">
<data type="boolean"/>
</attribute>
</define>
<define name="default-attribute">
<attribute name="default"/>
</define>
<define name="default-case-attribute">
<attribute name="default-case">
<data type="boolean"/>
</attribute>
</define>
<define name="error-app-tag-element">
<optional>
<element name="error-app-tag">
<text/>
</element>
</optional>
</define>
<define name="error-message-element">
<optional>
<element name="error-message">
<text/>
</element>
</optional>
Lhotka, et al. Expires August 15, 2009 [Page 59]
Internet-Draft Mapping YANG to DSDL February 2009
</define>
<define name="instance-identifier-element">
<element name="instance-identifier">
<optional>
<attribute name="require-instance">
<data type="boolean"/>
</attribute>
</optional>
</element>
</define>
<define name="key-attribute">
<attribute name="key">
<list>
<data type="QName"/>
</list>
</attribute>
</define>
<define name="leafref-element">
<element name="leafref">
<optional>
<attribute name="require-instance">
<data type="boolean"/>
</attribute>
</optional>
<data type="string"/>
</element>
</define>
<define name="min-elements-attribute">
<attribute name="min-elements">
<data type="integer"/>
</attribute>
</define>
<define name="max-elements-attribute">
<attribute name="max-elements">
<data type="integer"/>
</attribute>
</define>
<define name="must-element">
<element name="must">
<attribute name="assert">
<data type="string"/>
</attribute>
Lhotka, et al. Expires August 15, 2009 [Page 60]
Internet-Draft Mapping YANG to DSDL February 2009
<interleave>
<ref name="err-app-tag-element"/>
<ref name="err-message-element"/>
</interleave>
</element>
</define>
<define name="ordered-by-attribute">
<attribute name="ordered-by">
<choice>
<value>user</value>
<value>system</value>
</choice>
</attribute>
</define>
<define name="status-attribute">
<attribute name="status">
<choice>
<value>current</value>
<value>deprecated</value>
<value>obsolete</value>
</choice>
</attribute>
</define>
<define name="unique-attribute">
<attribute name="unique">
<list>
<data type="string"/>
</list>
</attribute>
</define>
<define name="units-attribute">
<attribute name="units">
<data type="string"/>
</attribute>
</define>
<define name="when-attribute">
<attribute name="when">
<data type="string"/>
</attribute>
</define>
</grammar>
Lhotka, et al. Expires August 15, 2009 [Page 61]
Internet-Draft Mapping YANG to DSDL February 2009
A.2. Compact Syntax
default namespace =
"urn:ietf:params:xml:ns:netmod:dsdl-annotations:1"
config-attribute = attribute config { xsd:boolean }
default-attribute = attribute default { text }
default-case-attribute = attribute default-case { xsd:boolean }
error-app-tag-element = element error-app-tag { text }?
error-message-element = element error-message { text }?
instance-identifier-element =
element instance-identifier {
attribute require-instance { xsd:boolean }?
}
key-attribute =
attribute key {
list { xsd:QName }
}
leafref-element =
element leafref {
attribute require-instance { xsd:boolean }?,
xsd:string
}
min-elements-attribute = attribute min-elements { xsd:integer }
max-elements-attribute = attribute max-elements { xsd:integer }
must-element =
element must {
attribute assert { xsd:string },
(err-app-tag-element & err-message-element)
}
ordered-by-attribute = attribute ordered-by { "user" | "system" }
status-attribute =
attribute status { "current" | "deprecated" | "obsolete" }
unique-attribute =
attribute unique {
list { xsd:string }
}
units-attribute = attribute units { xsd:string }
when-attribute = attribute when { xsd:string }
Lhotka, et al. Expires August 15, 2009 [Page 62]
Internet-Draft Mapping YANG to DSDL February 2009
Appendix B. Schematron Library
This appendix contains the schema-independent library of Schematron
abstract patterns.
[Editor's note: It is incomplete.]
<!-- Uniqueness of list keys -->
<sch:pattern abstract="true" id="key">
<sch:rule context="$context">
<sch:assert test="count($context[$key=current()/$key])=1">
The key "<value-of select="$key"/>" needs to be unique
within the list at: <value-of select="$context"/>.
</sch:assert>
</sch:rule>
</sch:pattern>
<!-- Check of listref target -->
<sch:pattern abstract="true" id="keyref">
<sch:rule context="$keyref-context">
<sch:assert test="$key-context[$key=current()]">
The contents of "<value-of select="$keyref-context"/>"
must be a '</name>' with the key
"<value-of select="$key"/>" in this context:
<value-of select="$key-context"/>.
</sch:assert>
</sch:rule>
</sch:pattern>
Lhotka, et al. Expires August 15, 2009 [Page 63]
Internet-Draft Mapping YANG to DSDL February 2009
Appendix C. Translation of the DHCP Data Model
This appendix demonstrates output of the YANG->DSDL mapping algorithm
applied to the "canonical" DHCP tutorial [24] data model.
Appendix C.1 shows the result of the mapping algorithm in the RELAX
NG XML syntax and Appendix C.2 the same in the compact syntax, which
was obtained using the Trang tool [25].
The long regular expressions for IP addresses etc. that would exceed
the limit of 72 characters per line were trimmed. Other than that,
the results of the automatic translations were not changed.
C.1. XML Syntax
<?xml version="1.0" encoding="UTF-8"?>
<grammar
xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
xmlns:dc="http://purl.org/dc/terms"
xmlns:dhcp="http://example.com/ns/dhcp"
xmlns:nma="urn:ietf:params:xml:ns:netmod:rng-annot:1"
xmlns:nmt="urn:ietf:params:xml:ns:netmod:tree:1"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<dc:creator>Pyang 0.9.3, RELAX NG plugin</dc:creator>
<dc:source>YANG module 'dhcp'</dc:source>
<start>
<element name="nmt:netmod-tree">
<element name="nmt:top">
<interleave>
<optional>
<element name="dhcp:dhcp">
<a:documentation>configuration and operational
parameters for a DHCP server.</a:documentation>
<optional>
<element name="dhcp:max-lease-time"
nma:default="7200"
nma:units="seconds">
<data type="unsignedInt"/>
</element>
</optional>
<optional>
<element name="dhcp:default-lease-time"
nma:default="600"
nma:units="seconds">
<data type="unsignedInt"/>
<nma:must
assert="current() <= ../max-lease-time">
Lhotka, et al. Expires August 15, 2009 [Page 64]
Internet-Draft Mapping YANG to DSDL February 2009
<nma:error-message>The default-lease-time must be
less than max-lease-time</nma:error-message>
</nma:must>
</element>
</optional>
<ref name="dhcp__subnet-list"/>
<optional>
<element name="dhcp:shared-networks">
<zeroOrMore>
<element name="dhcp:shared-network"
nma:key="name">
<element name="dhcp:name">
<data type="string"/>
</element>
<ref name="dhcp__subnet-list"/>
</element>
</zeroOrMore>
</element>
</optional>
<optional>
<element name="dhcp:status"
nma:config="false">
<zeroOrMore>
<element name="dhcp:leases"
nma:key="address">
<element name="dhcp:address">
<ref name="inet-types__ip-address"/>
</element>
<optional>
<element name="dhcp:starts">
<ref name="yang-types__date-and-time"/>
</element>
</optional>
<optional>
<element name="dhcp:ends">
<ref name="yang-types__date-and-time"/>
</element>
</optional>
<optional>
<element name="dhcp:hardware">
<optional>
<element name="dhcp:type">
<choice>
<value>ethernet</value>
<value>token-ring</value>
<value>fddi</value>
</choice>
</element>
Lhotka, et al. Expires August 15, 2009 [Page 65]
Internet-Draft Mapping YANG to DSDL February 2009
</optional>
<optional>
<element name="dhcp:address">
<ref name="yang-types__phys-address"/>
</element>
</optional>
</element>
</optional>
</element>
</zeroOrMore>
</element>
</optional>
</element>
</optional>
</interleave>
</element>
<element name="nmt:rpc-methods">
<empty/>
</element>
<element name="nmt:notifications">
<empty/>
</element>
</element>
</start>
<define name="dhcp__subnet-list">
<a:documentation>A reusable list of subnets</a:documentation>
<zeroOrMore>
<element name="dhcp:subnet" nma:key="net">
<element name="dhcp:net">
<ref name="inet-types__ip-prefix"/>
</element>
<optional>
<element name="dhcp:range">
<optional>
<element name="dhcp:dynamic-bootp">
<a:documentation>Allows BOOTP clients to get addresses
in this range</a:documentation>
<empty/>
</element>
</optional>
<element name="dhcp:low">
<ref name="inet-types__ip-address"/>
</element>
<element name="dhcp:high">
<ref name="inet-types__ip-address"/>
</element>
</element>
</optional>
Lhotka, et al. Expires August 15, 2009 [Page 66]
Internet-Draft Mapping YANG to DSDL February 2009
<optional>
<element name="dhcp:dhcp-options">
<a:documentation>Options in the DHCP
protocol</a:documentation>
<zeroOrMore>
<element name="dhcp:router"
nma:ordered-by="user">
<ref name="inet-types__host"/>
<a:documentation>See: RFC 2132,
sec. 3.8</a:documentation>
</element>
</zeroOrMore>
<optional>
<element name="dhcp:domain-name">
<ref name="inet-types__domain-name"/>
<a:documentation>See: RFC 2132,
sec. 3.17</a:documentation>
</element>
</optional>
</element>
</optional>
<optional>
<element name="dhcp:max-lease-time"
nma:default="7200"
nma:units="seconds">
<data type="unsignedInt"/>
</element>
</optional>
</element>
</zeroOrMore>
</define>
<define name="inet-types__ip-prefix">
<choice>
<ref name="inet-types__ipv4-prefix"/>
<ref name="inet-types__ipv6-prefix"/>
</choice>
</define>
<define name="inet-types__ipv4-prefix">
<data type="string">
<param name="pattern">... removed ...</param>
</data>
</define>
<define name="inet-types__ipv6-prefix">
<data type="string">
<param name="pattern">... removed ...</param>
</data>
</define>
<define name="inet-types__ip-address">
Lhotka, et al. Expires August 15, 2009 [Page 67]
Internet-Draft Mapping YANG to DSDL February 2009
<choice>
<ref name="inet-types__ipv4-address"/>
<ref name="inet-types__ipv6-address"/>
</choice>
</define>
<define name="inet-types__ipv4-address">
<data type="string">
<param name="pattern">... removed ...</param>
</data>
</define>
<define name="inet-types__ipv6-address">
<data type="string">
<param name="pattern">... removed ...</param>
</data>
</define>
<define name="inet-types__host">
<choice>
<ref name="inet-types__ip-address"/>
<ref name="inet-types__domain-name"/>
</choice>
</define>
<define name="inet-types__domain-name">
<data type="string">
<param name="pattern">... removed ...</param>
</data>
</define>
<define name="yang-types__date-and-time">
<data type="string">
<param name="pattern">... removed ...</param>
</data>
</define>
<define name="yang-types__phys-address">
<data type="string">
<param name="pattern">... removed ...</param>
</data>
</define>
</grammar>
C.2. Compact Syntax
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
namespace dc = "http://purl.org/dc/terms"
namespace dhcp = "http://example.com/ns/dhcp"
namespace nma = "urn:ietf:params:xml:ns:netmod:rng-annot:1"
namespace nmt = "urn:ietf:params:xml:ns:netmod:tree:1"
dc:creator [ "Pyang 0.9.3, RELAX NG plugin" ]
dc:source [ "YANG module 'dhcp'" ]
Lhotka, et al. Expires August 15, 2009 [Page 68]
Internet-Draft Mapping YANG to DSDL February 2009
start =
element nmt:netmod-tree {
element nmt:top {
## configuration and operational parameters for a DHCP server.
element dhcp:dhcp {
[ nma:default = "7200" nma:units = "seconds" ]
element dhcp:max-lease-time { xsd:unsignedInt }?,
[ nma:default = "600" nma:units = "seconds" ]
element dhcp:default-lease-time {
xsd:unsignedInt
>> nma:must [
assert = "current() <= ../max-lease-time"
nma:error-message [
"The default-lease-time must be less
than max-lease-time"
]
]
}?,
dhcp__subnet-list,
element dhcp:shared-networks {
[ nma:key = "name" ]
element dhcp:shared-network {
element dhcp:name { xsd:string },
dhcp__subnet-list
}*
}?,
[ nma:config = "false" ]
element dhcp:status {
[ nma:key = "address" ]
element dhcp:leases {
element dhcp:address { inet-types__ip-address },
element dhcp:starts { yang-types__date-and-time }?,
element dhcp:ends { yang-types__date-and-time }?,
element dhcp:hardware {
element dhcp:type { "ethernet" | "token-ring" | "fddi" }?,
element dhcp:address { yang-types__phys-address }?
}?
}*
}?
}?
},
element nmt:rpc-methods { empty },
element nmt:notifications { empty }
}
## A reusable list of subnets
dhcp__subnet-list =
Lhotka, et al. Expires August 15, 2009 [Page 69]
Internet-Draft Mapping YANG to DSDL February 2009
[ nma:key = "net" ]
element dhcp:subnet {
element dhcp:net { inet-types__ip-prefix },
element dhcp:range {
## Allows BOOTP clients to get addresses in this range
element dhcp:dynamic-bootp { empty }?,
element dhcp:low { inet-types__ip-address },
element dhcp:high { inet-types__ip-address }
}?,
## Options in the DHCP protocol
element dhcp:dhcp-options {
[ nma:ordered-by = "user" ]
element dhcp:router {
inet-types__host
>> a:documentation [ "See: RFC 2132, sec. 3.8" ]
}*,
element dhcp:domain-name {
inet-types__domain-name
>> a:documentation [ "See: RFC 2132, sec. 3.17" ]
}?
}?,
[ nma:default = "7200" nma:units = "seconds" ]
element dhcp:max-lease-time { xsd:unsignedInt }?
}*
inet-types__ip-prefix =
inet-types__ipv4-prefix | inet-types__ipv6-prefix
inet-types__ipv4-prefix =
xsd:string {
pattern = "... removed ..."
}
inet-types__ipv6-prefix =
xsd:string {
pattern = "... removed ..."
}
inet-types__ip-address =
inet-types__ipv4-address | inet-types__ipv6-address
inet-types__ipv4-address =
xsd:string {
pattern = "... removed ..."
}
inet-types__ipv6-address =
xsd:string {
pattern = "... removed ..."
}
inet-types__host = inet-types__ip-address | inet-types__domain-name
inet-types__domain-name =
Lhotka, et al. Expires August 15, 2009 [Page 70]
Internet-Draft Mapping YANG to DSDL February 2009
xsd:string {
pattern = "... removed ..."
}
yang-types__date-and-time =
xsd:string {
pattern = "... removed ..."
}
yang-types__phys-address =
xsd:string {
pattern = "([0-9a0-fA-F]{2}(:[0-9a0-fA-F]{2})*)?"
}
Lhotka, et al. Expires August 15, 2009 [Page 71]
Internet-Draft Mapping YANG to DSDL February 2009
Authors' Addresses
Ladislav Lhotka
CESNET
Email: lhotka@cesnet.cz
Rohan Mahy
Plantronics
Email: rohan@ekabal.com
Sharon Chisholm
Nortel
Email: schishol@nortel.com
Lhotka, et al. Expires August 15, 2009 [Page 72]
