draft-ietf-netmod-dsdl-map-07.txt   draft-ietf-netmod-dsdl-map-08.txt 
NETMOD L. Lhotka NETMOD L. Lhotka, Ed.
Internet-Draft CESNET Internet-Draft CESNET
Intended status: Standards Track R. Mahy Intended status: Standards Track September 28, 2010
Expires: February 24, 2011 Plantronics Expires: April 1, 2011
S. Chisholm
Nortel
August 23, 2010
Mapping YANG to Document Schema Definition Languages and Validating Mapping YANG to Document Schema Definition Languages and Validating
NETCONF Content NETCONF Content
draft-ietf-netmod-dsdl-map-07 draft-ietf-netmod-dsdl-map-08
Abstract Abstract
This draft specifies the mapping rules for translating YANG data This document specifies the mapping rules for translating YANG data
models into Document Schema Definition Languages (DSDL), a models into Document Schema Definition Languages (DSDL), a
coordinated set of XML schema languages standardized as ISO/IEC coordinated set of XML schema languages standardized as ISO/IEC
19757. The following DSDL schema languages are addressed by the 19757. The following DSDL schema languages are addressed by the
mapping: RELAX NG, Schematron and Document Schema Renaming Language mapping: RELAX NG, Schematron and DSRL. The mapping takes one or
(DSRL). The mapping takes one or more YANG modules and produces a more YANG modules and produces a set of DSDL schemas for a selected
set of DSDL schemas for a selected target document type - datastore target document type - datastore content, NETCONF message etc.
content, NETCONF message etc. Procedures for schema-based validation Procedures for schema-based validation of such documents are also
of such documents are also discussed. discussed.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 24, 2011. This Internet-Draft will expire on April 1, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 31 skipping to change at page 2, line 28
4.2. Schematron . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Schematron . . . . . . . . . . . . . . . . . . . . . . . 15
4.3. Document Semantics Renaming Language (DSRL) . . . . . . 16 4.3. Document Semantics Renaming Language (DSRL) . . . . . . 16
5. Additional Annotations . . . . . . . . . . . . . . . . . . . 17 5. Additional Annotations . . . . . . . . . . . . . . . . . . . 17
5.1. Dublin Core Metadata Elements . . . . . . . . . . . . . 17 5.1. Dublin Core Metadata Elements . . . . . . . . . . . . . 17
5.2. RELAX NG DTD Compatibility Annotations . . . . . . . . . 17 5.2. RELAX NG DTD Compatibility Annotations . . . . . . . . . 17
5.3. NETMOD-Specific Annotations . . . . . . . . . . . . . . 18 5.3. NETMOD-Specific Annotations . . . . . . . . . . . . . . 18
6. Overview of the Mapping . . . . . . . . . . . . . . . . . . . 20 6. Overview of the Mapping . . . . . . . . . . . . . . . . . . . 20
7. NETCONF Content Validation . . . . . . . . . . . . . . . . . 22 7. NETCONF Content Validation . . . . . . . . . . . . . . . . . 22
8. Design Considerations . . . . . . . . . . . . . . . . . . . . 23 8. Design Considerations . . . . . . . . . . . . . . . . . . . . 23
8.1. Hybrid Schema . . . . . . . . . . . . . . . . . . . . . 23 8.1. Hybrid Schema . . . . . . . . . . . . . . . . . . . . . 23
8.2. Modularity . . . . . . . . . . . . . . . . . . . . . . . 26 8.2. Modularity . . . . . . . . . . . . . . . . . . . . . . . 25
8.3. Granularity . . . . . . . . . . . . . . . . . . . . . . 27 8.3. Granularity . . . . . . . . . . . . . . . . . . . . . . 27
8.4. Handling of XML Namespaces . . . . . . . . . . . . . . . 28 8.4. Handling of XML Namespaces . . . . . . . . . . . . . . . 27
9. Mapping YANG Data Models to the Hybrid Schema . . . . . . . . 29 9. Mapping YANG Data Models to the Hybrid Schema . . . . . . . . 29
9.1. Occurrence Rules for Data Nodes . . . . . . . . . . . . 29 9.1. Occurrence Rules for Data Nodes . . . . . . . . . . . . 29
9.1.1. Optional and Mandatory Nodes . . . . . . . . . . . 30 9.1.1. Optional and Mandatory Nodes . . . . . . . . . . . 30
9.1.2. Implicit Nodes . . . . . . . . . . . . . . . . . . 31 9.1.2. Implicit Nodes . . . . . . . . . . . . . . . . . . 31
9.2. Mapping YANG Groupings and Typedefs . . . . . . . . . . 32 9.2. Mapping YANG Groupings and Typedefs . . . . . . . . . . 32
9.2.1. YANG Refinements and Augments . . . . . . . . . . . 33 9.2.1. YANG Refinements and Augments . . . . . . . . . . . 33
9.2.2. Type Derivation Chains . . . . . . . . . . . . . . 36 9.2.2. Type Derivation Chains . . . . . . . . . . . . . . 36
9.3. Translation of XPath Expressions . . . . . . . . . . . . 38 9.3. Translation of XPath Expressions . . . . . . . . . . . . 38
9.4. YANG Language Extensions . . . . . . . . . . . . . . . . 39 9.4. YANG Language Extensions . . . . . . . . . . . . . . . . 39
10. Mapping YANG Statements to the Hybrid Schema . . . . . . . . 41 10. Mapping YANG Statements to the Hybrid Schema . . . . . . . . 41
skipping to change at page 4, line 46 skipping to change at page 4, line 43
12.10. The @nma:leafref Annotation . . . . . . . . . . . . . . 78 12.10. The @nma:leafref Annotation . . . . . . . . . . . . . . 78
12.11. The @nma:min-elements Annotation . . . . . . . . . . . . 78 12.11. The @nma:min-elements Annotation . . . . . . . . . . . . 78
12.12. The @nma:max-elements Annotation . . . . . . . . . . . . 78 12.12. The @nma:max-elements Annotation . . . . . . . . . . . . 78
12.13. The <nma:must> Annotation . . . . . . . . . . . . . . . 78 12.13. The <nma:must> Annotation . . . . . . . . . . . . . . . 78
12.14. The <nma:ordered-by> Annotation . . . . . . . . . . . . 79 12.14. The <nma:ordered-by> Annotation . . . . . . . . . . . . 79
12.15. The <nma:status> Annotation . . . . . . . . . . . . . . 79 12.15. The <nma:status> Annotation . . . . . . . . . . . . . . 79
12.16. The @nma:unique Annotation . . . . . . . . . . . . . . . 79 12.16. The @nma:unique Annotation . . . . . . . . . . . . . . . 79
12.17. The @nma:when Annotation . . . . . . . . . . . . . . . . 79 12.17. The @nma:when Annotation . . . . . . . . . . . . . . . . 79
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80
14. Security Considerations . . . . . . . . . . . . . . . . . . . 81 14. Security Considerations . . . . . . . . . . . . . . . . . . . 81
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 82 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 82
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 83 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 83
16.1. Normative References . . . . . . . . . . . . . . . . . . 83 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 84
16.2. Informative References . . . . . . . . . . . . . . . . . 84 17.1. Normative References . . . . . . . . . . . . . . . . . . 84
Appendix A. RELAX NG Schema for NETMOD-Specific Annotations . . 86 17.2. Informative References . . . . . . . . . . . . . . . . . 85
Appendix B. Schema-Independent Library . . . . . . . . . . . . . 91 Appendix A. RELAX NG Schema for NETMOD-Specific Annotations . . 87
Appendix C. Mapping DHCP Data Model - A Complete Example . . . . 92 Appendix B. Schema-Independent Library . . . . . . . . . . . . . 92
C.1. Input YANG Module . . . . . . . . . . . . . . . . . . . 92 Appendix C. Mapping DHCP Data Model - A Complete Example . . . . 93
C.2. Hybrid Schema . . . . . . . . . . . . . . . . . . . . . 94 C.1. Input YANG Module . . . . . . . . . . . . . . . . . . . 93
C.3. Final DSDL Schemas . . . . . . . . . . . . . . . . . . . 99 C.2. Hybrid Schema . . . . . . . . . . . . . . . . . . . . . 95
C.3.1. Main RELAX NG Schema for <nc:get> Reply . . . . . . 100 C.3. Final DSDL Schemas . . . . . . . . . . . . . . . . . . . 100
C.3.1. Main RELAX NG Schema for <nc:get> Reply . . . . . . 101
C.3.2. RELAX NG Schema - Global Named Pattern C.3.2. RELAX NG Schema - Global Named Pattern
Definitions . . . . . . . . . . . . . . . . . . . . 102 Definitions . . . . . . . . . . . . . . . . . . . . 103
C.3.3. Schematron Schema for <nc:get> Reply . . . . . . . 104 C.3.3. Schematron Schema for <nc:get> Reply . . . . . . . 105
C.3.4. DSRL Schema for <nc:get> Reply . . . . . . . . . . 106 C.3.4. DSRL Schema for <nc:get> Reply . . . . . . . . . . 107
Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 107 Appendix D. Change Log . . . . . . . . . . . . . . . . . . . . . 108
D.1. Changes Between Versions -06 and -07 . . . . . . . . . . 107 D.1. Changes Between Versions -07 and -08 . . . . . . . . . . 108
D.2. Changes Between Versions -05 and -06 . . . . . . . . . . 107 D.2. Changes Between Versions -06 and -07 . . . . . . . . . . 108
D.3. Changes Between Versions -04 and -05 . . . . . . . . . . 108 D.3. Changes Between Versions -05 and -06 . . . . . . . . . . 108
D.4. Changes Between Versions -03 and -04 . . . . . . . . . . 108 D.4. Changes Between Versions -04 and -05 . . . . . . . . . . 109
D.5. Changes Between Versions -02 and -03 . . . . . . . . . . 109 D.5. Changes Between Versions -03 and -04 . . . . . . . . . . 109
D.6. Changes Between Versions -01 and -02 . . . . . . . . . . 109 D.6. Changes Between Versions -02 and -03 . . . . . . . . . . 110
D.7. Changes Between Versions -00 and -01 . . . . . . . . . . 110 D.7. Changes Between Versions -01 and -02 . . . . . . . . . . 111
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 111 D.8. Changes Between Versions -00 and -01 . . . . . . . . . . 111
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 113
1. Introduction 1. Introduction
The NETCONF Working Group has completed a base protocol used for The NETCONF Working Group has completed a base protocol used for
configuration management [RFC4741]. This base specification defines configuration management [RFC4741]. This base specification defines
protocol bindings and an XML container syntax for configuration and protocol bindings and an XML container syntax for configuration and
management operations, but does not include a data modeling language management operations, but does not include a data modeling language
or accompanying rules for how to model configuration and state or accompanying rules for how to model configuration and state
information carried by NETCONF. The IETF Operations Area has a long information carried by NETCONF. The IETF Operations Area has a long
tradition of defining data for SNMP Management Information Bases tradition of defining data for SNMP Management Information Bases
skipping to change at page 6, line 28 skipping to change at page 6, line 28
extremely important. Simply modeling the valid syntax without the extremely important. Simply modeling the valid syntax without the
additional semantic relationships has caused significant additional semantic relationships has caused significant
interoperability problems in the past. interoperability problems in the past.
The NETCONF community concluded that a data modeling framework is The NETCONF community concluded that a data modeling framework is
needed to support ongoing development of IETF and vendor-defined needed to support ongoing development of IETF and vendor-defined
management information modules. The NETMOD Working Group was management information modules. The NETMOD Working Group was
chartered to design a modeling language defining the semantics of chartered to design a modeling language defining the semantics of
operational data, configuration data, event notifications and operational data, configuration data, event notifications and
operations, with focus on "human-friendliness", i.e., readability and operations, with focus on "human-friendliness", i.e., readability and
ease of use. The result is the YANG data modeling language [YANG], ease of use. The result is the YANG data modeling language
which now serves for the normative description of NETCONF data [RFC6020], which now serves for the normative description of NETCONF
models. data models.
Since NETCONF uses XML for encoding its messages, it is natural to Since NETCONF uses XML for encoding its messages, it is natural to
express the constraints on NETCONF content using standard XML schema express the constraints on NETCONF content using standard XML schema
languages. For this purpose, the NETMOD WG selected the Document languages. For this purpose, the NETMOD WG selected the Document
Schema Definition Languages (DSDL) that is being standardized as ISO/ Schema Definition Languages (DSDL) that is being standardized as ISO/
IEC 19757 [DSDL]. The DSDL framework comprises a set of XML schema IEC 19757 [DSDL]. The DSDL framework comprises a set of XML schema
languages that address grammar rules, semantic constraints and other languages that address grammar rules, semantic constraints and other
data modeling aspects, but also, and more importantly, do it in a data modeling aspects, but also, and more importantly, do it in a
coordinated and consistent way. While it is true that some DSDL coordinated and consistent way. While it is true that some DSDL
parts have not been standardized yet and are still work in progress, 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, the three parts that the YANG-to-DSDL mapping relies upon - Regular
Schematron and Document Schema Renaming Language (DSRL) - already Language for XML Next Generation (RELAX NG), Schematron and Document
have the status of an ISO/IEC International Standard and are Schema Renaming Language (DSRL) - already have the status of an ISO/
supported in a number of software tools. IEC International Standard and are supported in a number of software
tools.
This document contains a specification of a mapping that translates This document contains a specification of a mapping that translates
YANG data models to XML schemas utilizing a subset of the DSDL schema YANG data models to XML schemas utilizing a subset of the DSDL schema
languages. The mapping procedure is divided into two steps: In the languages. The mapping procedure is divided into two steps: In the
first step, the structure of the data tree, signatures of remote first step, the structure of the data tree, signatures of remote
procedure call (RPC) operations and notifications is expressed as the procedure call (RPC) operations and notifications is expressed as the
so-called "hybrid schema" - a single RELAX NG schema with annotations so-called "hybrid schema" - a single RELAX NG schema with annotations
representing additional data model information (metadata, representing additional data model information (metadata,
documentation, semantic constraints, default values etc.). The documentation, semantic constraints, default values etc.). The
second step then generates a coordinated set of DSDL schemas that can second step then generates a coordinated set of DSDL schemas that can
skipping to change at page 8, line 23 skipping to change at page 8, line 23
o client o client
o datastore o datastore
o message o message
o operation o operation
o server o server
The following terms are defined in [YANG]: The following terms are defined in [RFC6020]:
o augment o augment
o base type o base type
o built-in type o built-in type
o configuration data o configuration data
o container o container
skipping to change at page 11, line 43 skipping to change at page 11, line 43
o ancestor datatype: Any datatype a given datatype is (transitively) o ancestor datatype: Any datatype a given datatype is (transitively)
derived from. derived from.
o ancestor built-in datatype: The built-in datatype that is at the o ancestor built-in datatype: The built-in datatype that is at the
start of the type derivation chain for a given datatype. start of the type derivation chain for a given datatype.
o hybrid schema: A RELAX NG schema with annotations, which embodies o hybrid schema: A RELAX NG schema with annotations, which embodies
the same information as the source YANG module(s). See the same information as the source YANG module(s). See
Section 8.1 for details. Section 8.1 for details.
o implicit node: A node that, if missing, may be added to the o implicit node: A data node that, if it is not instantiated in a
information set of an XML document (configuration, RPC input or data tree, may be added to the information set of that data tree
output, notification) without changing the meaning of that XML (configuration, RPC input or output, notification) without
document. changing the semantics of the data tree.
3. Objectives and Motivation 3. Objectives and Motivation
The main objective of this work is to complement YANG as a data The main objective of this work is to complement YANG as a data
modeling language by validation capabilities of DSDL schema modeling language with validation capabilities of DSDL schema
languages, namely RELAX NG, Schematron and DSRL. This document languages, namely RELAX NG, Schematron and DSRL. This document
describes the correspondence between grammatical, semantic and data describes the correspondence between grammatical, semantic and data
type constraints expressed in YANG and equivalent DSDL patterns and type constraints expressed in YANG and equivalent DSDL patterns and
rules. The ultimate goal is to be able to capture all substantial rules. The ultimate goal is to be able to capture all substantial
information contained in YANG modules and express it in DSDL schemas. information contained in YANG modules and express it in DSDL schemas.
While the mapping from YANG to DSDL described in this document may in While the mapping from YANG to DSDL described in this document may in
principle be invertible, the inverse mapping from DSDL to YANG is principle be invertible, the inverse mapping from DSDL to YANG is
beyond the scope of this document. beyond the scope of this document.
XML-based information models and XML-encoded data appear in several XML-based information models and XML-encoded data appear in several
skipping to change at page 16, line 7 skipping to change at page 16, line 7
o human-readable message that is displayed when the assert condition o human-readable message that is displayed when the assert condition
is false or report condition is true. is false or report condition is true.
The difference between the assert and report condition is that the The difference between the assert and report condition is that the
former is positive in that it states a condition that a valid former is positive in that it states a condition that a valid
document has to satisfy, whereas the latter specifies an error document has to satisfy, whereas the latter specifies an error
condition. condition.
Schematron draws most of its expressive power from XPath [XPath] and Schematron draws most of its expressive power from XPath [XPath] and
XSLT [XSLT]. ISO Schematron allows for dynamic query language Extensible Stylesheet Language Transformations (XSLT) [XSLT]. ISO
binding so that the following XML query languages can be used: STX, Schematron allows for dynamic query language binding so that the
XSLT 1.0, XSLT 1.1, EXSLT, XSLT 2.0, XPath 1.0, XPath 2.0 and following XML query languages can be used: STX, XSLT 1.0, XSLT 1.1,
XQuery 1.0 (this list may be extended in the future). EXSLT, XSLT 2.0, XPath 1.0, XPath 2.0 and XQuery 1.0 (this list may
be extended in the future).
Human-readable error messages are another feature that sets Human-readable error messages are another feature that sets
Schematron apart from other common schema languages. The messages Schematron apart from other common schema languages. The messages
may even contain XPath expressions that are evaluated in the actual may even contain XPath expressions that are evaluated in the actual
context and thus refer to information items in the XML document being context and thus refer to information items in the XML document being
validated. validated.
Another feature of Schematron that is used by the mapping are Another feature of Schematron that is used by the mapping are
abstract patterns. These work essentially as macros and may also abstract patterns. These work essentially as macros and may also
contain parameters which are supplied when the abstract pattern is contain parameters which are supplied when the abstract pattern is
skipping to change at page 22, line 21 skipping to change at page 22, line 21
The validation proceeds in the following steps, which are also The validation proceeds in the following steps, which are also
illustrated in Figure 2: illustrated in Figure 2:
1. The XML instance document is checked for grammatical and data 1. The XML instance document is checked for grammatical and data
type validity using the RELAX NG schema. type validity using the RELAX NG schema.
2. Default values for leaf nodes have to be applied and their 2. Default values for leaf nodes have to be applied and their
ancestor containers added where necessary. It is important to ancestor containers added where necessary. It is important to
add the implicit nodes before the next validation step because add the implicit nodes before the next validation step because
YANG specification [YANG] requires that the data tree against YANG specification [RFC6020] requires that the data tree against
which XPath expressions are evaluated already has all defaults which XPath expressions are evaluated already has all defaults
filled-in. Note that this step modifies the information set of filled-in. Note that this step modifies the information set of
the validated XML document. the validated XML document.
3. The semantic constraints are checked using the Schematron schema. 3. The semantic constraints are checked using the Schematron schema.
+----------+ +----------+ +----------+ +----------+
| | | XML | | | | XML |
| XML | | document | | XML | | document |
| document |-----------o----------->| with | | document |-----------o----------->| with |
skipping to change at page 25, line 39 skipping to change at page 25, line 18
</nma:rpcs> </nma:rpcs>
<nma:notifications> <nma:notifications>
<nma:notification> <nma:notification>
<element name="exa:mynotif"> <element name="exa:mynotif">
... ...
</element> </element>
</nma:notification> </nma:notification>
... ...
</nma:notifications> </nma:notifications>
</start> </start>
...local named pattern definitions of example-a...
</grammar> </grammar>
<grammar nma:module="example-b" <grammar nma:module="example-b"
ns="http://example.com/ns/example-a"> ns="http://example.com/ns/example-a">
<start> <start>
<nma:data> <nma:data>
...configuration and state data defined in "example-b"... ...configuration and state data defined in "example-b"...
</nma:data> </nma:data>
<nma:rpcs/> <nma:rpcs/>
<nma:notifications/> <nma:notifications/>
</start> </start>
...local named pattern definitions of example-b...
</grammar> </grammar>
</start> </start>
...global named pattern definitions...
</grammar> </grammar>
A complete hybrid schema for the data model of a DHCP server is given A complete hybrid schema for the data model of a DHCP server is given
in Appendix C.2. in Appendix C.2.
8.2. Modularity 8.2. Modularity
Both YANG and RELAX NG offer means for modularity, i.e., for Both YANG and RELAX NG offer means for modularity, i.e., for
splitting the contents of a full schema into separate modules and splitting the contents of a full schema into separate modules and
combining or reusing them in various ways. However, the approaches combining or reusing them in various ways. However, the approaches
taken by YANG and RELAX NG differ. Modularity in RELAX NG is taken by YANG and RELAX NG differ. Modularity in RELAX NG is
suitable for ad hoc combinations of a small number of schemas whereas suitable for ad hoc combinations of a small number of schemas whereas
skipping to change at page 29, line 38 skipping to change at page 29, line 38
Therefore, one of the goals of the first mapping step is to infer the Therefore, one of the goals of the first mapping step is to infer the
occurrence constraints for all data nodes and mark accordingly the occurrence constraints for all data nodes and mark accordingly the
corresponding <rng:element> patterns in the hybrid schema so that any corresponding <rng:element> patterns in the hybrid schema so that any
transformation procedure in the second mapping step can simply use transformation procedure in the second mapping step can simply use
this information and need not examine the subtree again. this information and need not examine the subtree again.
First, it has to be decided whether a given data node must always be First, it has to be decided whether a given data node must always be
present in a valid configuration. If so, such a node is called present in a valid configuration. If so, such a node is called
mandatory, otherwise it is called optional. This constraint is mandatory, otherwise it is called optional. This constraint is
closely related to the notion of mandatory nodes in Section 3.1 in closely related to the notion of mandatory nodes in Section 3.1 in
[YANG]. The only difference is that this document also considers [RFC6020]. The only difference is that this document also considers
list keys to be mandatory. list keys to be mandatory.
The other occurrence constraint has to do with the semantics of the The other occurrence constraint has to do with the semantics of the
'default' statement and the possibility of removing empty non- 'default' statement and the possibility of removing empty non-
presence containers. As a result, the information set of a valid presence containers. As a result, the information set of a valid
configuration may be modified by adding or removing certain leaf or configuration may be modified by adding or removing certain leaf or
container elements without changing the meaning of the configuration. container elements without changing the meaning of the configuration.
In this document, such elements are called implicit. In the hybrid In this document, such elements are called implicit. In the hybrid
schema, they can be identified as RELAX NG patterns having either schema, they can be identified as RELAX NG patterns having either
@nma:default or @nma:implicit attribute. @nma:default or @nma:implicit attribute.
skipping to change at page 31, line 15 skipping to change at page 31, line 15
o In addition, a leaf node is mandatory if it is declared as a list o In addition, a leaf node is mandatory if it is declared as a list
key. key.
o A list or leaf-list node is mandatory if it contains the 'min- o A list or leaf-list node is mandatory if it contains the 'min-
elements' substatement with an argument value greater than zero. elements' substatement with an argument value greater than zero.
o A container node is mandatory if its definition does not contain o A container node is mandatory if its definition does not contain
the 'presence' substatement and at least one of its child nodes is the 'presence' substatement and at least one of its child nodes is
mandatory. mandatory.
A node is optional if and only if it is not mandatory. A node which is not mandatory is said to be optional.
In RELAX NG, definitions of nodes that are optional must be In RELAX NG, definitions of nodes that are optional must be
explicitly wrapped in the <rng:optional> element. The mapping MUST explicitly wrapped in the <rng:optional> element. The mapping MUST
use the above rules to determine whether a YANG node is optional and use the above rules to determine whether a YANG node is optional and
if so, insert the <rng:optional> element in the hybrid schema. if so, insert the <rng:optional> element in the hybrid schema.
However, alternatives in <rng:choice> MUST NOT be defined as optional However, alternatives in <rng:choice> MUST NOT be defined as optional
in the hybrid schema. If a choice in YANG is not mandatory, <rng: in the hybrid schema. If a choice in YANG is not mandatory, <rng:
optional> MUST be used to wrap the entire <rng:choice> pattern. optional> MUST be used to wrap the entire <rng:choice> pattern.
9.1.2. Implicit Nodes 9.1.2. Implicit Nodes
The following rules are used to determine whether a given node is The following rules are used to determine whether a given data node
implicit: is implicit:
o List, leaf-list and anyxml nodes are never implicit. o List, leaf-list and anyxml nodes are never implicit.
o A leaf node is implicit if and only if it has a default value, o A leaf node is implicit if and only if it has a default value,
defined either directly or via its datatype. defined either directly or via its datatype.
o A container node is implicit if and only if it does not have the o A container node is implicit if and only if it does not have the
'presence' substatement, none of its children are mandatory and at 'presence' substatement, none of its children are mandatory and at
least one child is implicit. least one child is implicit.
In the hybrid schema, all implicit containers, as well as leafs that In the hybrid schema, all implicit containers, as well as leafs that
obtain their default value from a typedef and don't have the @nma: obtain their default value from a typedef and don't have the @nma:
default attribute, MUST be marked with @nma:implicit attribute having default attribute, MUST be marked with @nma:implicit attribute having
the value of "true". the value of "true".
Note that Section 7.9.3 in [YANG] specifies other rules that must be Note that Section 7.9.3 in [RFC6020] specifies other rules that must
taken into account when deciding whether a given container or leaf be taken into account when deciding whether a given container or leaf
appearing inside a case of a choice is ultimately implicit or not. appearing inside a case of a choice is ultimately implicit or not.
Specifically, a leaf or container under a case can be implicit only Specifically, a leaf or container under a case can be implicit only
if the case appears in the argument of the choice's 'default' if the case appears in the argument of the choice's 'default'
statement. However, this is not sufficient by itself but also statement. However, this is not sufficient by itself but also
depends on the particular instance XML document, namely on the depends on the particular instance XML document, namely on the
presence or absence of nodes from other (non-default) cases. The presence or absence of nodes from other (non-default) cases. The
details are explained in Section 11.3. details are explained in Section 11.3.
9.2. Mapping YANG Groupings and Typedefs 9.2. Mapping YANG Groupings and Typedefs
YANG groupings and typedefs are generally mapped to RELAX NG named YANG groupings and typedefs are generally mapped to RELAX NG named
patterns. There are, however, several caveats that the mapping has patterns. There are, however, several caveats that the mapping has
to take into account. to take into account.
First of all, YANG typedefs and groupings may appear at all levels of First of all, YANG typedefs and groupings may appear at all levels of
the module hierarchy and are subject to lexical scoping, see Section the module hierarchy and are subject to lexical scoping, see Section
5.5 in [YANG]. Second, top-level symbols from external modules may 5.5 in [RFC6020]. Second, top-level symbols from external modules
be imported as qualified names represented using the external module may be imported as qualified names represented using the external
namespace prefix and the name of the symbol. In contrast, named module namespace prefix and the name of the symbol. In contrast,
patterns in RELAX NG (both local and imported via the <rng:include> named patterns in RELAX NG (both local and imported via the <rng:
pattern) share the same namespace and within a grammar they are include> pattern) share the same namespace and within a grammar they
always global - their definitions may only appear at the top level as are always global - their definitions may only appear at the top
children of the <rng:grammar> element. Consequently, whenever YANG level as children of the <rng:grammar> element. Consequently,
groupings and typedefs are mapped to RELAX NG named pattern whenever YANG groupings and typedefs are mapped to RELAX NG named
definitions, their names MUST be disambiguated in order to avoid pattern definitions, their names MUST be disambiguated in order to
naming conflicts. The mapping uses the following procedure for avoid naming conflicts. The mapping uses the following procedure for
mangling the names of groupings and type definitions: mangling the names of groupings and type definitions:
o Names of groupings and typedefs appearing at the top level of the o Names of groupings and typedefs appearing at the top level of the
YANG module hierarchy are prefixed with the module name and two YANG module hierarchy are prefixed with the module name and two
underscore characters ("__"). underscore characters ("__").
o Names of other groupings and typedefs, i.e., those that do not 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 appear at the top level of a YANG module, are prefixed with the
module name, double underscore, and then the names of all ancestor module name, double underscore, and then the names of all ancestor
data nodes separated by double underscore. data nodes separated by double underscore.
o Finally, since the names of groupings and typedefs in YANG have o Finally, since the names of groupings and typedefs in YANG have
different namespaces, an additional underscore character is added different namespaces, an additional underscore character is added
to the beginning of the mangled names of all groupings. to the beginning of the mangled names of all groupings.
An additional complication is caused by the YANG rules for subelement An additional complication is caused by the YANG rules for subelement
ordering (see, e.g., Section 7.5.7 in [YANG]): In RPC input and ordering (see, e.g., Section 7.5.7 in [RFC6020]): In RPC input and
output parameters, subelements must follow the order specified in the output parameters, subelements must follow the order specified in the
data model, otherwise the order is arbitrary. Consequently, if a data model, otherwise the order is arbitrary. Consequently, if a
grouping is used both in RPC input/output parameters and elsewhere, grouping is used both in RPC input/output parameters and elsewhere,
it MUST be mapped to two different named pattern definitions - one it MUST be mapped to two different named pattern definitions - one
with fixed order and the other with arbitrary order. To distinguish with fixed order and the other with arbitrary order. To distinguish
them, the "__rpc" suffix MUST be appended to the version with fixed them, the "__rpc" suffix MUST be appended to the version with fixed
order. order.
EXAMPLE. Consider the following YANG module which imports the EXAMPLE. Consider the following YANG module which imports the
standard module "ietf-inet-types" [Ytypes]: standard module "ietf-inet-types" [RFC6021]:
module example1 { module example1 {
namespace "http://example.com/ns/example1"; namespace "http://example.com/ns/example1";
prefix ex1; prefix ex1;
typedef vowels { typedef vowels {
type string { type string {
pattern "[aeiouy]*"; pattern "[aeiouy]*";
} }
} }
grouping "grp1" { grouping "grp1" {
skipping to change at page 39, line 31 skipping to change at page 39, line 31
For example, XPath expression "/dhcp/max-lease-time" appearing in a For example, XPath expression "/dhcp/max-lease-time" appearing in a
YANG module with the "dhcp" prefix will be translated to YANG module with the "dhcp" prefix will be translated to
o "$pref:dhcp/$pref:max-lease-time", if the expression is inside a o "$pref:dhcp/$pref:max-lease-time", if the expression is inside a
top-level grouping; top-level grouping;
o "dhcp:dhcp/dhcp:max-lease-time", otherwise. o "dhcp:dhcp/dhcp:max-lease-time", otherwise.
YANG also uses other XPath-like expressions, namely key identifiers YANG also uses other XPath-like expressions, namely key identifiers
and "descendant schema node identifiers" (see the ABNF production for and "descendant schema node identifiers" (see the ABNF production for
and "descendant-schema-nodeid" in Section 12 of [YANG]). These and "descendant-schema-nodeid" in Section 12 of [RFC6020]). These
expressions MUST be translated by adding local module prefixes as expressions MUST be translated by adding local module prefixes as
well. well.
9.4. YANG Language Extensions 9.4. YANG Language Extensions
YANG allows for extending its own language in-line by adding new YANG allows for extending its own language in-line by adding new
statements with keywords from special namespaces. Such extensions statements with keywords from special namespaces. Such extensions
first have to be declared using the 'extension' statement and then first have to be declared using the 'extension' statement and then
they can be used as the standard YANG statements, from which they are they can be used as the standard YANG statements, from which they are
distinguished by a namespace prefix qualifying the extension keyword. distinguished by a namespace prefix qualifying the extension keyword.
RELAX NG has a similar extension mechanism - XML elements and RELAX NG has a similar extension mechanism - XML elements and
attributes with names from foreign namespaces may be inserted at attributes with names from foreign namespaces may be inserted at
almost any place of a RELAX NG schema. almost any place of a RELAX NG schema.
YANG language extensions may or may not have a meaning in the context 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 DSDL schemas. Therefore, an implementation MAY ignore any or all
of the extensions. However, an extension that is not ignored MUST be 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 mapped to XML element(s) and/or attribute(s) that exactly match the
YIN form of the extension, see Section 11.1 in [YANG]. YIN form of the extension, see Section 11.1 in [RFC6020].
EXAMPLE. Consider the following extension defined by the "acme" EXAMPLE. Consider the following extension defined by the "acme"
module: module:
extension documentation-flag { extension documentation-flag {
argument number; argument number;
} }
This extension can then be used in the same or another module, for This extension can then be used in the same or another module, for
instance like this: instance like this:
skipping to change at page 43, line 41 skipping to change at page 43, line 41
Section 10.53.3. Section 10.53.3.
10.7. The 'case' Statement 10.7. The 'case' Statement
This statement is mapped to <rng:group> or <rng:interleave> element, This statement is mapped to <rng:group> or <rng:interleave> element,
depending on whether the statement belongs to an definition of an RPC depending on whether the statement belongs to an definition of an RPC
operation or not. If the argument of a sibling 'default' statement operation or not. If the argument of a sibling 'default' statement
equals to ARGUMENT, @nma:implicit attribute with the value of "true" equals to ARGUMENT, @nma:implicit attribute with the value of "true"
MUST be added to that <rng:group> or <rng:interleave> element. The MUST be added to that <rng:group> or <rng:interleave> element. The
@nma:implicit attribute MUST NOT be used for nodes at the top-level @nma:implicit attribute MUST NOT be used for nodes at the top-level
of a non-default case (see Section 7.9.3 in [YANG]). of a non-default case (see Section 7.9.3 in [RFC6020]).
10.8. The 'choice' Statement 10.8. The 'choice' Statement
This statement is mapped to <rng:choice> element. This statement is mapped to <rng:choice> element.
If 'choice' has the 'mandatory' substatement with the value of If 'choice' has the 'mandatory' substatement with the value of
"true", the attribute @nma:mandatory MUST be added to the <rng: "true", the attribute @nma:mandatory MUST be added to the <rng:
choice> element with the value of ARGUMENT. This case may require choice> element with the value of ARGUMENT. This case may require
additional handling, see Section 11.2.1. Otherwise, if "mandatory additional handling, see Section 11.2.1. Otherwise, if "mandatory
true;" is not present, the <rng:choice> element MUST be wrapped in true;" is not present, the <rng:choice> element MUST be wrapped in
skipping to change at page 47, line 49 skipping to change at page 47, line 49
where where
PREFIX is the prefix used in the hybrid schema for the namespace PREFIX is the prefix used in the hybrid schema for the namespace
of the module where the current identity is defined. of the module where the current identity is defined.
IDENTITY1 is the name of of the named pattern corresponding to an IDENTITY1 is the name of of the named pattern corresponding to an
identity which is derived from the current identity. Exactly one identity which is derived from the current identity. Exactly one
<rng:ref> element MUST be present for every such identity. <rng:ref> element MUST be present for every such identity.
EXAMPLE ([YANG], Section 7.16.3). The identities in the input YANG EXAMPLE ([RFC6020], Section 7.16.3). The identities in the input
modules YANG modules
module crypto-base { module crypto-base {
namespace "http://example.com/crypto-base"; namespace "http://example.com/crypto-base";
prefix "crypto"; prefix "crypto";
identity crypto-alg { identity crypto-alg {
description description
"Base identity from which all crypto algorithms "Base identity from which all crypto algorithms
are derived."; are derived.";
} }
} }
skipping to change at page 51, line 15 skipping to change at page 51, line 15
10.30. The 'list' Statement 10.30. The 'list' Statement
This statement is mapped exactly as the 'leaf-list' statement, see This statement is mapped exactly as the 'leaf-list' statement, see
Section 10.28. The only difference is that the @nma:leaf-list Section 10.28. The only difference is that the @nma:leaf-list
annotation either MUST NOT be present or MUST have the value of annotation either MUST NOT be present or MUST have the value of
"false". "false".
When mapping the substatements of 'list', the order of children of When mapping the substatements of 'list', the order of children of
the list element MUST be specified so that list keys, if there are the list element MUST be specified so that list keys, if there are
any, always appear in the same order as they are defined in the 'key' any, always appear in the same order as they are defined in the 'key'
substatement and before other children, see [YANG], Section 7.8.5. substatement and before other children, see [RFC6020], Section 7.8.5.
In particular, if a list key is defined in a grouping but the list In particular, if a list key is defined in a grouping but the list
node itself is not a part of the same grouping, and the position of node itself is not a part of the same grouping, and the position of
the 'uses' statement would violate the above ordering requirement, the 'uses' statement would violate the above ordering requirement,
the grouping MUST be expanded, i.e., the 'uses' statement replaced by the grouping MUST be expanded, i.e., the 'uses' statement replaced by
the grouping contents. the grouping contents.
For example, consider the following YANG fragment of a module with For example, consider the following YANG fragment of a module with
the prefix "yam": the prefix "yam":
grouping keygrp { grouping keygrp {
skipping to change at page 55, line 40 skipping to change at page 55, line 40
10.48. The 'require-instance' Statement 10.48. The 'require-instance' Statement
This statement is handled within "instance-identifier" type This statement is handled within "instance-identifier" type
(Section 10.53.6). (Section 10.53.6).
10.49. The 'revision' Statement 10.49. The 'revision' Statement
The mapping uses only the most recent instance of the 'revision' The mapping uses only the most recent instance of the 'revision'
statement, i.e., one with the latest date in ARGUMENT, which statement, i.e., one with the latest date in ARGUMENT, which
specifies the current revision of the input YANG module [YANG]. This specifies the current revision of the input YANG module [RFC6020].
date SHOULD be recorded, together with the name of the YANG module, This date SHOULD be recorded, together with the name of the YANG
in the corresponding Dublin Core <dc:source> element (see module, in the corresponding Dublin Core <dc:source> element (see
Section 10.34), for example in this form: Section 10.34), for example in this form:
<dc:source>YANG module 'foo', revision 2010-03-02</dc:source> <dc:source>YANG module 'foo', revision 2010-03-02</dc:source>
The 'description' substatement of 'revision' is ignored. The 'description' substatement of 'revision' is ignored.
10.50. The 'rpc' Statement 10.50. The 'rpc' Statement
This statement is mapped to the following subtree in the RELAX NG This statement is mapped to the following subtree in the RELAX NG
schema (where PREFIX is the prefix of the local YANG module): schema (where PREFIX is the prefix of the local YANG module):
skipping to change at page 57, line 36 skipping to change at page 57, line 36
| boolean | boolean | "true" or "false" | | boolean | boolean | "true" or "false" |
| | | | | | | |
| binary | base64Binary | binary data in base64 encoding | | binary | base64Binary | binary data in base64 encoding |
+-----------+---------------+--------------------------------+ +-----------+---------------+--------------------------------+
Table 4: YANG built-in datatypes with equivalents in the W3C XML Table 4: YANG built-in datatypes with equivalents in the W3C XML
Schema Type Library Schema Type Library
Two important datatypes of the XSD datatype library - "dateTime" and Two important datatypes of the XSD datatype library - "dateTime" and
"anyURI" - are not built-in types in YANG but instead are defined as "anyURI" - are not built-in types in YANG but instead are defined as
derived types in the standard modules [Ytypes]: "date-and-time" in derived types in the standard modules [RFC6021]: "date-and-time" in
the "ietf-yang-types" module and "uri" in the "ietf-inet-types" the "ietf-yang-types" module and "uri" in the "ietf-inet-types"
module. However, the formal restrictions in the YANG type module. However, the formal restrictions in the YANG type
definitions are rather weak. Therefore, implementations of the YANG- definitions are rather weak. Therefore, implementations of the YANG-
to-DSDL mapping SHOULD detect these derived types in source YANG to-DSDL mapping SHOULD detect these derived types in source YANG
modules and map them to "dateType" and "anyURI", respectively. modules and map them to "dateType" and "anyURI", respectively.
Details about the mapping of individual YANG built-in types are given Details about the mapping of individual YANG built-in types are given
in the following subsections. in the following subsections.
10.53.1. The "empty" Type 10.53.1. The "empty" Type
skipping to change at page 77, line 22 skipping to change at page 77, line 22
If this annotation element has the @require-instance attribute with If this annotation element has the @require-instance attribute with
the value of "false", it is ignored. Otherwise it is mapped to the the value of "false", it is ignored. Otherwise it is mapped to the
following Schematron assert: following Schematron assert:
<sch:assert test="nmf:evaluate(.)"> <sch:assert test="nmf:evaluate(.)">
The element pointed to by "CONTELEM" must exist. The element pointed to by "CONTELEM" must exist.
</sch:assert> </sch:assert>
The nmf:evaluate() function is an XSLT extension function (see The nmf:evaluate() function is an XSLT extension function (see
Extension Functions in [XSLT]) that evaluates an XPath expression at Extension Functions in [XSLT]) that evaluates an XPath expression at
run time. Such an extension function is provided by some XSLT run time. Such an extension function is available in Extended XSLT
processors, for example Saxon [Saxon]. (EXSLT) or provided as a proprietary extension by some XSLT
processors, for example Saxon.
12.8. The @nma:key Annotation 12.8. The @nma:key Annotation
Assume this annotation attribute contains "k_1 k_2 ... k_n", i.e., Assume this annotation attribute contains "k_1 k_2 ... k_n", i.e.,
specifies n children of CONTELEM as list keys. The annotation is specifies n children of CONTELEM as list keys. The annotation is
then mapped to the following Schematron report: then mapped to the following Schematron report:
<sch:report test="CONDITION"> <sch:report test="CONDITION">
Duplicate key of list "CONTELEM" Duplicate key of list "CONTELEM"
</sch:report> </sch:report>
skipping to change at page 80, line 7 skipping to change at page 80, line 7
This annotation is mapped to the following Schematron assert: This annotation is mapped to the following Schematron assert:
<sch:assert test="EXPRESSION"> <sch:assert test="EXPRESSION">
Node "CONTELEM" is only valid when "EXPRESSION" is true. Node "CONTELEM" is only valid when "EXPRESSION" is true.
</sch:assert> </sch:assert>
where EXPRESSION is the value of @nma:when. where EXPRESSION is the value of @nma:when.
13. IANA Considerations 13. IANA Considerations
This document registers two namespace URIs in the IETF XML registry This document requests the following two registrations of namespace
[RFC3688]: URIs in the IETF XML registry [RFC3688]:
-----------------------------------------------------
URI: urn:ietf:params:xml:ns:netmod:dsdl-annotations:1 URI: urn:ietf:params:xml:ns:netmod:dsdl-annotations:1
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
-----------------------------------------------------
-----------------------------------------------------
URI: urn:ietf:params:xml:ns:netmod:xpath-extensions:1 URI: urn:ietf:params:xml:ns:netmod:xpath-extensions:1
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
-----------------------------------------------------
14. Security Considerations 14. Security Considerations
This document defines a procedure that maps data models expressed in This document defines a procedure that maps data models expressed in
the YANG language to a coordinated set of DSDL schemas. The the YANG language to a coordinated set of DSDL schemas. The
procedure itself has no security impact on the Internet. procedure itself has no security impact on the Internet.
DSDL schemas obtained by the mapping procedure may be used for DSDL schemas obtained by the mapping procedure may be used for
validating the contents of NETCONF messages or entire datastores and validating the contents of NETCONF messages or entire datastores and
thus provide additional validity checks above those performed by thus provide additional validity checks above those performed by
NETCONF server and client implementations supporting YANG data NETCONF server and client implementations supporting YANG data
models. The strictness of this validation is directly derived from models. The strictness of this validation is directly derived from
the source YANG modules that the validated XML data adhere to. the source YANG modules that the validated XML data adhere to.
15. Acknowledgments 15. Contributors
The authors wish to thank the following individuals who provided The following people contributed significantly to the initial version
of this document:
o Rohan Mahy
o Sharon Chisholm (Ciena)
16. Acknowledgments
The editor wishes to thank the following individuals who provided
helpful suggestions and/or comments on various versions of this helpful suggestions and/or comments on various versions of this
document: Andy Bierman, Martin Bjorklund, Jirka Kosek, Juergen document: Andy Bierman, Martin Bjorklund, Jirka Kosek, Juergen
Schoenwaelder and Phil Shafer. Schoenwaelder and Phil Shafer.
16. References 17. References
16.1. Normative References 17.1. Normative References
[DSDL] ISO/IEC, "Document Schema Definition Languages (DSDL) - [DSDL] ISO/IEC, "Document Schema Definition Languages (DSDL) -
Part 1: Overview", ISO/IEC 19757-1, November 2004. Part 1: Overview", ISO/IEC 19757-1, November 2004.
[DSRL] ISO/IEC, "Information Technology - Document Schema [DSRL] ISO/IEC, "Information Technology - Document Schema
Definition Languages (DSDL) - Part 8: Document Semantics Definition Languages (DSDL) - Part 8: Document Semantics
Renaming Language - DSRL", ISO/IEC 19757-8:2008(E), Renaming Language - DSRL", ISO/IEC 19757-8:2008(E),
December 2008. December 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006. December 2006.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
Network Configuration Protocol (NETCONF)", RFC 6020,
September 2010.
[RFC6021] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6021, September 2010.
[RNG] ISO/IEC, "Information Technology - Document Schema [RNG] ISO/IEC, "Information Technology - Document Schema
Definition Languages (DSDL) - Part 2: Regular-Grammar- Definition Languages (DSDL) - Part 2: Regular-Grammar-
Based Validation - RELAX NG. Second Edition.", ISO/ Based Validation - RELAX NG. Second Edition.", ISO/
IEC 19757-2:2008(E), December 2008. IEC 19757-2:2008(E), December 2008.
[RNG-CS] ISO/IEC, "Information Technology - Document Schema [RNG-CS] ISO/IEC, "Information Technology - Document Schema
Definition Languages (DSDL) - Part 2: Regular-Grammar- Definition Languages (DSDL) - Part 2: Regular-Grammar-
Based Validation - RELAX NG. AMENDMENT 1: Compact Syntax", Based Validation - RELAX NG. AMENDMENT 1: Compact Syntax",
ISO/IEC 19757-2:2003/Amd. 1:2006(E), January 2006. ISO/IEC 19757-2:2003/Amd. 1:2006(E), January 2006.
skipping to change at page 84, line 23 skipping to change at page 85, line 31
[XSD-D] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes [XSD-D] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium Second Edition", World Wide Web Consortium
Recommendation REC-xmlschema-2-20041028, October 2004, Recommendation REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[XSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0", World [XSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0", World
Wide Web Consortium Recommendation REC-xslt-19991116, Wide Web Consortium Recommendation REC-xslt-19991116,
November 1999. November 1999.
[YANG] Bjorklund, M., Ed., "YANG - A data modeling language for 17.2. Informative References
NETCONF", draft-ietf-netmod-yang-13 (work in progress),
June 2010.
[Ytypes] Schoenwaelder, J., Ed., "Common YANG Data Types",
draft-ietf-netmod-yang-types-09 (work in progress),
April 2010.
16.2. Informative References
[DHCPtut] Bjorklund, M., "DHCP Tutorial", November 2007, <http:// [DHCPtut] Bjorklund, M., "DHCP Tutorial", November 2007, <http://
www.yang-central.org/twiki/bin/view/Main/DhcpTutorial>. www.yang-central.org/twiki/bin/view/Main/DhcpTutorial>.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
"Simple Network Management Protocol (SNMP)", STD 15, "Simple Network Management Protocol (SNMP)", STD 15,
RFC 1157, May 1990. RFC 1157, May 1990.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC5013] Kunze, J., "The Dublin Core Metadata Element Set", [RFC5013] Kunze, J., "The Dublin Core Metadata Element Set",
RFC 5013, August 2007. RFC 5013, August 2007.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", RFC 5277, July 2008. Notifications", RFC 5277, July 2008.
[Saxon] Saxonica, Ltd., "Saxon Extensions", March 2004,
<http://saxon.sourceforge.net/saxon7.9.1/extensions.html>.
[Trang] Clark, J., "Trang: Multiformat schema converter based on [Trang] Clark, J., "Trang: Multiformat schema converter based on
RELAX NG", 2008, RELAX NG", 2008,
<http://www.thaiopensource.com/relaxng/trang.html>. <http://www.thaiopensource.com/relaxng/trang.html>.
[Vli04] van der Vlist, E., "RELAX NG", O'Reilly , 2004. [Vli04] van der Vlist, E., "RELAX NG", O'Reilly , 2004.
[XSD] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, [XSD] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
"XML Schema Part 1: Structures Second Edition", World Wide "XML Schema Part 1: Structures Second Edition", World Wide
Web Consortium Recommendation REC-xmlschema-1-20041028, Web Consortium Recommendation REC-xmlschema-1-20041028,
October 2004, October 2004,
skipping to change at page 107, line 9 skipping to change at page 108, line 9
</dsrl:parent> </dsrl:parent>
<dsrl:name>dhcp:max-lease-time</dsrl:name> <dsrl:name>dhcp:max-lease-time</dsrl:name>
<dsrl:default-content>7200</dsrl:default-content> <dsrl:default-content>7200</dsrl:default-content>
</dsrl:element-map> </dsrl:element-map>
</dsrl:maps> </dsrl:maps>
Appendix D. Change Log Appendix D. Change Log
RFC Editor: remove this section upon publication as an RFC. RFC Editor: remove this section upon publication as an RFC.
D.1. Changes Between Versions -06 and -07 D.1. Changes Between Versions -07 and -08
o Edits based on Gen-ART review.
o Added formal templates in Section 13.
o Created the "Contributors" section and moved the former co-authors
there.
o Indicated the location of both global and local named pattern
definitions in the example hybrid schema in Section 8.1.
o Added reference to EXSLT "evaluate" function.
D.2. Changes Between Versions -06 and -07
o Mapping of 'description', 'reference' and 'units' to the hybrid o Mapping of 'description', 'reference' and 'units' to the hybrid
schema is now mandatory. schema is now mandatory.
o Improvements and fixes of the text based on the AD review o Improvements and fixes of the text based on the AD review
D.2. Changes Between Versions -05 and -06 D.3. Changes Between Versions -05 and -06
o Terminology change: "conceptual tree schema" -> "hybrid schema". o Terminology change: "conceptual tree schema" -> "hybrid schema".
o Changed sectioning markers in the hybrid schema into plain NETMOD- o Changed sectioning markers in the hybrid schema into plain NETMOD-
specific annotations. Hence the former "nmt" namespace is not specific annotations. Hence the former "nmt" namespace is not
used at all. used at all.
o Added the following NETMOD-specific annotations: @nma:if-feature, o Added the following NETMOD-specific annotations: @nma:if-feature,
@nma:leaf-list, @nma:mandatory, @nma:module, removed @nma: @nma:leaf-list, @nma:mandatory, @nma:module, removed @nma:
presence. presence.
skipping to change at page 108, line 5 skipping to change at page 109, line 15
o DHCP example: All RNG schemas are only in the XML syntax. Added o DHCP example: All RNG schemas are only in the XML syntax. Added
RNG with global definitions. RNG with global definitions.
o Added [XML-INFOSET] to normative references. o Added [XML-INFOSET] to normative references.
o Listed the terms that are defined in other documents. o Listed the terms that are defined in other documents.
o The schema for NETMOD-specific annotation is now given only as RNG o The schema for NETMOD-specific annotation is now given only as RNG
named pattern definitions, no more in NVDL. named pattern definitions, no more in NVDL.
D.3. Changes Between Versions -04 and -05 D.4. Changes Between Versions -04 and -05
o Leafs that take their default value from a typedef and are not o Leafs that take their default value from a typedef and are not
annotated with @nma:default must have @nma:implicit="true". annotated with @nma:default must have @nma:implicit="true".
o Changed code markers CODE BEGINS/ENDS to the form agreed by the o Changed code markers CODE BEGINS/ENDS to the form agreed by the
WG. WG.
o Derived types "date-and-time" and "uri" SHOULD be mapped to XSD o Derived types "date-and-time" and "uri" SHOULD be mapped to XSD
"dateTime" and "anyURI" types, respectively. "dateTime" and "anyURI" types, respectively.
o Clarified the notion of implicit nodes under under 'case' in o Clarified the notion of implicit nodes under under 'case' in
Section 9.1.2. Section 9.1.2.
o Moved draft-ietf-netmod-yang-types-06 to normative references. o Moved draft-ietf-netmod-yang-types-06 to normative references.
o An extra <rng:group> is no more required for the default case of a o An extra <rng:group> is no more required for the default case of a
choice in the shorthand notation. choice in the shorthand notation.
D.4. Changes Between Versions -03 and -04 D.5. Changes Between Versions -03 and -04
o Implemented ordering rules for list children - keys must go first o Implemented ordering rules for list children - keys must go first
and appear in the same order as in the input YANG module. and appear in the same order as in the input YANG module.
o The 'case' statement is now mapped to either <rng:group> (inside o The 'case' statement is now mapped to either <rng:group> (inside
RPC operations) or <rng:interleave> (otherwise). RPC operations) or <rng:interleave> (otherwise).
o A nma:default annotation coming from a datatype which the mapping o A nma:default annotation coming from a datatype which the mapping
expands is attached to the <rng:element> pattern where the expands is attached to the <rng:element> pattern where the
expansion occurs. Added an example. expansion occurs. Added an example.
skipping to change at page 109, line 9 skipping to change at page 110, line 19
o Added CODE BEGINS/ENDS markers. o Added CODE BEGINS/ENDS markers.
o Separated normative and informative references. o Separated normative and informative references.
o Added URL for XPath extensions namespace. o Added URL for XPath extensions namespace.
o Added Section 2 (Terminology and Notation). o Added Section 2 (Terminology and Notation).
o Added Section 14 (Security Considerations). o Added Section 14 (Security Considerations).
o Added Section 15 (Acknowledgments). o Added Section 16 (Acknowledgments).
o Removed compact syntax schema from Appendix B. o Removed compact syntax schema from Appendix B.
o Editorial changes: symbolic citation labels. o Editorial changes: symbolic citation labels.
D.5. Changes Between Versions -02 and -03 D.6. Changes Between Versions -02 and -03
o Changed @nma:default-case to @nma:implicit. o Changed @nma:default-case to @nma:implicit.
o Changed nma:leafref annotation from element to attribute. o Changed nma:leafref annotation from element to attribute.
o Added skeleton rule to Section 11.2. o Added skeleton rule to Section 11.2.
o Reworked Section 11.3, added skeleton element maps,corrected the o Reworked Section 11.3, added skeleton element maps,corrected the
example. example.
skipping to change at page 109, line 46 skipping to change at page 111, line 9
o Removed "float32" and "float64" types and added mapping of o Removed "float32" and "float64" types and added mapping of
"decimal64" with example. "decimal64" with example.
o Removed mapping of 'require-instance' for "leafref" type. o Removed mapping of 'require-instance' for "leafref" type.
o Updated RELAX NG schema for NETMOD-specific annotations. o Updated RELAX NG schema for NETMOD-specific annotations.
o Updated the DHCP example. o Updated the DHCP example.
D.6. Changes Between Versions -01 and -02 D.7. Changes Between Versions -01 and -02
o Moved Section 7 "NETCONF Content Validation" after Section 6. o Moved Section 7 "NETCONF Content Validation" after Section 6.
o New text about mapping defaults to DSRL, especially in Section 7 o New text about mapping defaults to DSRL, especially in Section 7
and Section 11.3. and Section 11.3.
o Finished the DHCP example by adding the DSRL schema to Appendix C. o Finished the DHCP example by adding the DSRL schema to Appendix C.
o New @nma:presence annotation was added - it is needed for proper o New @nma:presence annotation was added - it is needed for proper
handling of default contents. handling of default contents.
skipping to change at page 110, line 22 skipping to change at page 111, line 33
Schematron. Schematron.
o Fixed the schema for NETMOD-specific annotations by adding o Fixed the schema for NETMOD-specific annotations by adding
explicit prefix to all defined elements and attributes. explicit prefix to all defined elements and attributes.
Previously, the attributes had no namespace. Previously, the attributes had no namespace.
o Handling of 'feature', 'if-feature' and 'deviation' added. o Handling of 'feature', 'if-feature' and 'deviation' added.
o Handling of nma:instance-identifier via XSLT extension function. o Handling of nma:instance-identifier via XSLT extension function.
D.7. Changes Between Versions -00 and -01 D.8. Changes Between Versions -00 and -01
o Attributes @nma:min-elements and @nma:max-elements are attached to o Attributes @nma:min-elements and @nma:max-elements are attached to
<rng:element> (list entry) and not to <rng:zeroOrMore> or <rng: <rng:element> (list entry) and not to <rng:zeroOrMore> or <rng:
oneOrMore>. oneOrMore>.
o Keys and all node identifiers in 'key' and 'unique' statements are o Keys and all node identifiers in 'key' and 'unique' statements are
prefixed. prefixed.
o Fixed the mapping of 'rpc' and 'notification'. o Fixed the mapping of 'rpc' and 'notification'.
skipping to change at page 111, line 5 skipping to change at page 113, line 5
o Mandated the use of @xmlns:xxx as the only method for declaring o Mandated the use of @xmlns:xxx as the only method for declaring
the target namespace. the target namespace.
o Added section "Handling of XML Namespaces" to explain the previous o Added section "Handling of XML Namespaces" to explain the previous
item. item.
o Completed DHCP example in Appendix C. o Completed DHCP example in Appendix C.
o Almost all text about the second mapping step is new. o Almost all text about the second mapping step is new.
Authors' Addresses Author's Address
Ladislav Lhotka Ladislav Lhotka (editor)
CESNET CESNET
Email: lhotka@cesnet.cz Email: lhotka@cesnet.cz
Rohan Mahy
Plantronics
Email: rohan@ekabal.com
Sharon Chisholm
Nortel
Email: schishol@nortel.com
 End of changes. 57 change blocks. 
115 lines changed or deleted 154 lines changed or added

This html diff was produced by rfcdiff 1.39. The latest version is available from http://tools.ietf.org/tools/rfcdiff/