draft-ietf-netmod-yang-types-02.txt   draft-ietf-netmod-yang-types-03.txt 
Network Working Group J. Schoenwaelder, Ed. Network Working Group J. Schoenwaelder, Ed.
Internet-Draft Jacobs University Internet-Draft Jacobs University
Intended status: Standards Track March 9, 2009 Intended status: Standards Track May 13, 2009
Expires: September 10, 2009 Expires: November 14, 2009
Common YANG Data Types Common YANG Data Types
draft-ietf-netmod-yang-types-02 draft-ietf-netmod-yang-types-03
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 10, 2009. This Internet-Draft will expire on November 14, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This document introduces a collection of common data types to be used This document introduces a collection of common data types to be used
with the YANG data modeling language. with the YANG data modeling language.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Core YANG Derived Types . . . . . . . . . . . . . . . . . . . 5 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Internet Specific Derived Types . . . . . . . . . . . . . . . 13 3. Core YANG Derived Types . . . . . . . . . . . . . . . . . . . 7
4. IEEE Specific Derived Types . . . . . . . . . . . . . . . . . 22 4. Internet Specific Derived Types . . . . . . . . . . . . . . . 16
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . . 28 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.2. Informative References . . . . . . . . . . . . . . . . . . 28 9.1. Normative References . . . . . . . . . . . . . . . . . . . 30
Appendix A. XSD Translations . . . . . . . . . . . . . . . . . . 31 9.2. Informative References . . . . . . . . . . . . . . . . . . 30
A.1. XSD of Core YANG Derived Types . . . . . . . . . . . . . . 31 Appendix A. XSD Translations . . . . . . . . . . . . . . . . . . 33
A.2. XSD of Internet Specific Derived Types . . . . . . . . . . 38 A.1. XSD of Core YANG Derived Types . . . . . . . . . . . . . . 33
A.3. XSD of IEEE Specific Derived Types . . . . . . . . . . . . 46 A.2. XSD of Internet Specific Derived Types . . . . . . . . . . 41
Appendix B. RelaxNG Translations . . . . . . . . . . . . . . . . 49 Appendix B. RelaxNG Translations . . . . . . . . . . . . . . . . 52
B.1. RelaxNG of Core YANG Derived Types . . . . . . . . . . . . 49 B.1. RelaxNG of Core YANG Derived Types . . . . . . . . . . . . 52
B.2. RelaxNG of Internet Specific Derived Types . . . . . . . . 55 B.2. RelaxNG of Internet Specific Derived Types . . . . . . . . 59
B.3. RelaxNG of IEEE Specific Derived Types . . . . . . . . . . 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 68
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 64
1. Introduction 1. Introduction
YANG [YANG] is a data modeling language used to model configuration YANG [YANG] is a data modeling language used to model configuration
and state data manipulated by the NETCONF [RFC4741] protocol. The and state data manipulated by the NETCONF [RFC4741] protocol. The
YANG language supports a small set of built-in data types and YANG language supports a small set of built-in data types and
provides mechanisms to derive other types from the built-in types. provides mechanisms to derive other types from the built-in types.
This document introduces a collection of common data types derived This document introduces a collection of common data types derived
from the built-in YANG data types. The definitions are organized in from the built-in YANG data types. The definitions are organized in
several YANG modules. The "ietf-yang-types" module contains several YANG modules. The "ietf-yang-types" module contains
generally useful data types. The "ietf-inet-types" module contains generally useful data types. The "ietf-inet-types" module contains
definitions that are relevant for the Internet protocol suite while definitions that are relevant for the Internet protocol suite.
the "ietf-ieee-types" module contains definitions that are relevant
for IEEE 802 protocols.
Their derived types are generally designed to be applicable for The derived types are generally designed to be applicable for
modeling all areas of management information. modeling all areas of management information.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14, [RFC2119]. 14, [RFC2119].
2. Core YANG Derived Types 2. Overview
This section provides a short overview over the types defined in
subsequent sections and their equivalent SMIv2 data types. Table 1
list the types defined in the ietf-yang-types YANG module and the
corresponding SMIv2 types (if any).
ietf-yang-types
+-----------------------+--------------------------------+
| Yang type | Equivalent SMIv2 type (module) |
+-----------------------+--------------------------------+
| counter32 | Counter32 (SNMPv2-SMI) |
| zero-based-counter32 | ZeroBasedCounter32 (RMON2-MIB) |
| counter64 | Counter64 (SNMPv2-SMI) |
| zero-based-counter64 | ZeroBasedCounter64 (HCNUM-TC) |
| gauge32 | Gauge32 (SNMPv2-SMI) |
| gauge64 | CounterBasedGauge64 (HCNUM-TC) |
| object-identifier | - |
| object-identifier-128 | OBJECT IDENTIFIER |
| date-and-time | - |
| timeticks | TimeTicks (SNMPv2-SMI) |
| timestamp | TimeStamp (SNMPv2-TC) |
| phys-address | PhysAddress (SNMPv2-TC) |
| mac-address | MacAddress (SNMPv2-TC) |
| xpath1.0 | - |
+-----------------------+--------------------------------+
Table 1
Table 2 list the types defined in the ietf-inet-types YANG module and
the corresponding SMIv2 types (if any).
inet-yang-types
+-----------------+-----------------------------------------------+
| Yang type | Equivalent SMIv2 type (module) |
+-----------------+-----------------------------------------------+
| ip-version | - |
| dscp | Dscp (DIFFSERV-DSCP-TC) |
| ipv6-flow-label | IPv6FlowLabel (IPV6-FLOW-LABEL-MIB) |
| port-number | InetPortNumber (INET-ADDRESS-MIB) |
| as-number | InetAutonomousSystemNumber (INET-ADDRESS-MIB) |
| ip-address | - |
| ipv4-address | - |
| ipv6-address | - |
| ip-prefix | - |
| ipv4-prefix | - |
| ipv6-prefix | - |
| domain-name | - |
| host | - |
| uri | Uri (URI-TC-MIB) |
+-----------------+-----------------------------------------------+
Table 2
3. Core YANG Derived Types
module ietf-yang-types { module ietf-yang-types {
namespace "urn:ietf:params:xml:ns:yang:yang-types"; namespace "urn:ietf:params:xml:ns:yang:yang-types";
prefix "yang"; prefix "yang";
organization organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group"; "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
contact contact
skipping to change at page 5, line 32 skipping to change at page 7, line 32
WG Chair: David Kessens WG Chair: David Kessens
<mailto: david.kessens@nsn.com> <mailto: david.kessens@nsn.com>
Editor: Juergen Schoenwaelder Editor: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de>"; <mailto:j.schoenwaelder@jacobs-university.de>";
description description
"This module contains a collection of generally useful derived "This module contains a collection of generally useful derived
YANG data types. YANG data types.
Copyright (C) 2009 The IETF Trust and the persons identified as Copyright (c) 2009 IETF Trust and the persons identified as
the document authors. This version of this YANG module is part the document authors. All rights reserved.
of RFC XXXX; see the RFC itself for full legal notices.";
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the
following conditions are met:
- Redistributions of source code must retain the above
copyright notice, this list of conditions and the
following disclaimer.
- Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the
following disclaimer in the documentation and/or other
materials provided with the distribution.
- Neither the name of Internet Society, IETF or IETF
Trust, nor the names of specific contributors, may be
used to endorse or promote products derived from this
software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
// RFC Ed.: replace XXXX with actual RFC number and remove this note // RFC Ed.: replace XXXX with actual RFC number and remove this note
revision 2009-03-09 { revision 2009-05-13 {
description description
"Initial revision, published as RFC XXXX."; "Initial revision, published as RFC XXXX.";
} }
// RFC Ed.: replace XXXX with actual RFC number and remove this note // RFC Ed.: replace XXXX with actual RFC number and remove this note
/*** collection of counter and gauge types ***/ /*** collection of counter and gauge types ***/
typedef counter32 { typedef counter32 {
type uint32; type uint32;
description description
skipping to change at page 12, line 21 skipping to change at page 15, line 9
"Represents media- or physical-level addresses represented "Represents media- or physical-level addresses represented
as a sequence octets, each octet represented by two hexadecimal as a sequence octets, each octet represented by two hexadecimal
numbers. Octets are separated by colons. numbers. Octets are separated by colons.
This type is in the value set and its semantics equivalent This type is in the value set and its semantics equivalent
to the PhysAddress textual convention of the SMIv2."; to the PhysAddress textual convention of the SMIv2.";
reference reference
"RFC 2579: Textual Conventions for SMIv2"; "RFC 2579: Textual Conventions for SMIv2";
} }
typedef mac-address {
type string {
pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}';
}
description
"The mac-address type represents an 802 MAC address represented
in the `canonical' order defined by IEEE 802.1a, i.e., as if it
were transmitted least significant bit first, even though 802.5
(in contrast to other 802.x protocols) requires MAC addresses
to be transmitted most significant bit first.
This type is in the value set and its semantics equivalent to
the MacAddress textual convention of the SMIv2.";
reference
"RFC 2579: Textual Conventions for SMIv2";
}
/*** collection of XML specific types ***/ /*** collection of XML specific types ***/
typedef xpath { // [TODO] call this xpath1-0? typedef xpath1.0 {
type string; type string;
description description
"This type represents an XPATH 1.0 expression."; "This type represents an XPATH 1.0 expression.";
// [TODO] Normalization needed due to abbreviated syntax and the
// unabbreviated syntax? Whitespace stuff to take care of?
reference reference
"W3C REC-xpath-19991116: XML Path Language (XPath) Version 1.0"; "W3C REC-xpath-19991116: XML Path Language (XPath) Version 1.0";
} }
} }
3. Internet Specific Derived Types 4. Internet Specific Derived Types
module ietf-inet-types { module ietf-inet-types {
namespace "urn:ietf:params:xml:ns:yang:inet-types"; namespace "urn:ietf:params:xml:ns:yang:inet-types";
prefix "inet"; prefix "inet";
organization organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group"; "IETF NETMOD (NETCONF Data Modeling Language) Working Group";
contact contact
skipping to change at page 13, line 32 skipping to change at page 16, line 32
WG Chair: David Kessens WG Chair: David Kessens
<mailto:david.kessens@nsn.com> <mailto:david.kessens@nsn.com>
Editor: Juergen Schoenwaelder Editor: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de>"; <mailto:j.schoenwaelder@jacobs-university.de>";
description description
"This module contains a collection of generally useful derived "This module contains a collection of generally useful derived
YANG data types for Internet addresses and related things. YANG data types for Internet addresses and related things.
Copyright (C) 2009 The IETF Trust and the persons identified as Copyright (c) 2009 IETF Trust and the persons identified as
the document authors. This version of this YANG module is part the document authors. All rights reserved.
of RFC XXXX; see the RFC itself for full legal notices.";
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the
following conditions are met:
- Redistributions of source code must retain the above
copyright notice, this list of conditions and the
following disclaimer.
- Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the
following disclaimer in the documentation and/or other
materials provided with the distribution.
- Neither the name of Internet Society, IETF or IETF
Trust, nor the names of specific contributors, may be
used to endorse or promote products derived from this
software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.";
// RFC Ed.: replace XXXX with actual RFC number and remove this note // RFC Ed.: replace XXXX with actual RFC number and remove this note
revision 2009-03-09 { revision 2009-05-13 {
description description
"Initial revision, published as RFC XXXX."; "Initial revision, published as RFC XXXX.";
} }
// RFC Ed.: replace XXXX with actual RFC number and remove this note // RFC Ed.: replace XXXX with actual RFC number and remove this note
/*** collection of protocol field related types ***/ /*** collection of protocol field related types ***/
typedef ip-version { typedef ip-version {
type enumeration { type enumeration {
enum unknown { enum unknown {
skipping to change at page 14, line 46 skipping to change at page 18, line 34
to the Dscp textual convention of the SMIv2."; to the Dscp textual convention of the SMIv2.";
reference reference
"RFC 3289: Management Information Base for the Differentiated "RFC 3289: Management Information Base for the Differentiated
Services Architecture Services Architecture
RFC 2474: Definition of the Differentiated Services Field RFC 2474: Definition of the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers (DS Field) in the IPv4 and IPv6 Headers
RFC 2780: IANA Allocation Guidelines For Values In RFC 2780: IANA Allocation Guidelines For Values In
the Internet Protocol and Related Headers"; the Internet Protocol and Related Headers";
} }
typedef flow-label { typedef ipv6-flow-label {
type uint32 { type uint32 {
range "0..1048575"; range "0..1048575";
} }
description description
"The flow-label type represents flow identifier or Flow Label "The flow-label type represents flow identifier or Flow Label
in an IPv6 packet header that may be used to discriminate in an IPv6 packet header that may be used to discriminate
traffic flows. traffic flows.
This type is in the value set and its semantics equivalent This type is in the value set and its semantics equivalent
to the IPv6FlowLabel textual convention of the SMIv2."; to the IPv6FlowLabel textual convention of the SMIv2.";
skipping to change at page 17, line 17 skipping to change at page 21, line 4
typically be the interface index number or the name of an typically be the interface index number or the name of an
interface. If the zone index is not present, the default interface. If the zone index is not present, the default
zone of the device will be used. zone of the device will be used.
The canonical format for the zone index is the numerical The canonical format for the zone index is the numerical
format"; format";
} }
typedef ipv6-address { typedef ipv6-address {
type string { type string {
pattern pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'
/* full */ + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
'((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})' + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
+ '(%[\p{N}\p{L}]+)?)' + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'
/* mixed */ + '(%[\p{N}\p{L}]+)?';
+ '|((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\.' pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|'
+ '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))' + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
+ '(%[\p{N}\p{L}]+)?)' + '(%.+)?';
/* shortened */
+ '|((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)'
+ '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*'
+ '(%[\p{N}\p{L}]+)?)'
/* shortened mixed */
+ '|((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)'
+ '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*'
+ '(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))'
+ '(%[\p{N}\p{L}]+)?)';
} }
description description
"The ipv6-address type represents an IPv6 address in full, "The ipv6-address type represents an IPv6 address in full,
mixed, shortened and shortened mixed notation. The IPv6 mixed, shortened and shortened mixed notation. The IPv6
address may include a zone index, separated by a % sign. address may include a zone index, separated by a % sign.
The zone index is used to disambiguate identical address The zone index is used to disambiguate identical address
values. For link-local addresses, the zone index will values. For link-local addresses, the zone index will
typically be the interface index number or the name of an typically be the interface index number or the name of an
interface. If the zone index is not present, the default interface. If the zone index is not present, the default
zone of the device will be used. zone of the device will be used.
The canonical format of IPv6 addresses must match the The canonical format of IPv6 addresses uses the compressed
pattern '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})' format described in RFC 4291 section 2.2 item 2 with the
with leading zeros suppressed as described in RFC 4291 following additional rules: The :: substitution must be
section 2.2 item 1. The canonical format for the zone applied to the longest sequence of all-zero 16-bit chunks
index is the numerical format as described in RFC 4007 in an IPv6 address. If there is a tie, the first sequence
section 11.2."; of all-zero 16-bit chunks is replaced by ::. Single
all-zero 16-bit chunks are not compressed. The normalized
format uses lower-case characters and leading zeros are
not allowed. The canonical format for the zone index is
the numerical format as described in RFC 4007 section
11.2.";
reference reference
"RFC 4291: IP Version 6 Addressing Architecture "RFC 4291: IP Version 6 Addressing Architecture
RFC 4007: IPv6 Scoped Address Architecture"; RFC 4007: IPv6 Scoped Address Architecture";
} }
// [TODO] The pattern needs to be checked; once YANG supports
// multiple pattern, we can perhaps be more precise.
typedef ip-prefix { typedef ip-prefix {
type union { type union {
type inet:ipv4-prefix; type inet:ipv4-prefix;
type inet:ipv6-prefix; type inet:ipv6-prefix;
} }
description description
"The ip-prefix type represents an IP prefix and is IP "The ip-prefix type represents an IP prefix and is IP
version neutral. The format of the textual representations version neutral. The format of the textual representations
implies the IP version."; implies the IP version.";
} }
typedef ipv4-prefix { typedef ipv4-prefix {
type string { type string {
pattern '(([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}' pattern '(([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}'
+ '([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])' + '([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])'
+ '/\d+'; + '/(([0-9])|([1-2][0-9])|(3[0-2]))';
} }
description description
"The ipv4-prefix type represents an IPv4 address prefix. "The ipv4-prefix type represents an IPv4 address prefix.
The prefix length is given by the number following the The prefix length is given by the number following the
slash character and must be less than or equal to 32. slash character and must be less than or equal to 32.
A prefix length value of n corresponds to an IP address A prefix length value of n corresponds to an IP address
mask which has n contiguous 1-bits from the most mask which has n contiguous 1-bits from the most
significant bit (MSB) and all other bits set to 0. significant bit (MSB) and all other bits set to 0.
The canonical format of an IPv4 prefix has all bits of The canonical format of an IPv4 prefix has all bits of
the IPv4 address set to zero that are not part of the the IPv4 address set to zero that are not part of the
IPv4 prefix."; IPv4 prefix.";
} }
typedef ipv6-prefix { typedef ipv6-prefix {
type string { type string {
pattern pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'
/* full */ + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
'((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})' + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
+ '/\d+)' + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'
/* mixed */ + '(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-8])))';
+ '|((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\.' pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|'
+ '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))' + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
+ '/\d+)' + '(/.+)';
/* shortened */
+ '|((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)'
+ '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*'
+ '/\d+)'
/* shortened mixed */
+ '|((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)'
+ '(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*'
+ '(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))'
+ '/\d+)';
} }
description description
"The ipv6-prefix type represents an IPv6 address prefix. "The ipv6-prefix type represents an IPv6 address prefix.
The prefix length is given by the number following the The prefix length is given by the number following the
slash character and must be less than or equal 128. slash character and must be less than or equal 128.
A prefix length value of n corresponds to an IP address A prefix length value of n corresponds to an IP address
mask which has n contiguous 1-bits from the most mask which has n contiguous 1-bits from the most
significant bit (MSB) and all other bits set to 0. significant bit (MSB) and all other bits set to 0.
The IPv6 address should have all bits that do not belong The IPv6 address should have all bits that do not belong
to the prefix set to zero. to the prefix set to zero.
The canonical format of an IPv6 prefix has all bits of The canonical format of an IPv6 prefix has all bits of
the IPv6 address set to zero that are not part of the the IPv6 address set to zero that are not part of the
IPv6 prefix. Furthermore, the IPv6 address must match the IPv6 prefix. Furthermore, IPv6 address is represented
pattern '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})' in the compressed format described in RFC 4291 section
with leading zeros suppressed as described in RFC 4291 2.2 item 2 with the following additional rules: The ::
section 2.2 item 1."; substitution must be applied to the longest sequence of
all-zero 16-bit chunks in an IPv6 address. If there is
a tie, the first sequence of all-zero 16-bit chunks is
replaced by ::. Single all-zero 16-bit chunks are not
compressed. The normalized format uses lower-case
characters and leading zeros are not allowed.";
reference reference
"RFC 4291: IP Version 6 Addressing Architecture"; "RFC 4291: IP Version 6 Addressing Architecture";
} }
// [TODO] The pattern needs to be checked; once YANG supports
// multiple pattern, we can perhaps be more precise.
/*** collection of domain name and URI types ***/ /*** collection of domain name and URI types ***/
typedef domain-name { typedef domain-name {
type string { type string {
pattern '([a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9]\.)*' pattern '((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)*'
+ '[a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9]'; + '([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)'
+ '|\.';
length "1..253";
} }
description description
"The domain-name type represents a DNS domain name. The "The domain-name type represents a DNS domain name. The
name SHOULD be fully qualified whenever possible. name SHOULD be fully qualified whenever possible.
Internet domain names are only loosely specified. Section
3.5 of RFC 1034 recommends a syntax (modified in section
2.1 of RFC 1123). The pattern above is intended to allow
for current practise in domain name use, and some possible
future expansion. It is designed to hold various types of
domain names, including names used for A or AAAA records
(host names) and other records, such as SRV records. Note
that Internet host names have a stricter syntax (described
in RFC 952) than the DNS recommendations in RFCs 1034 and
1123, and that systems that want to store host names in
objects using the domain-name type are recommended to adhere
to this stricter standard to ensure interoperability.
The encoding of DNS names in the DNS protocol is limited
to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL
byte, only 253 characters can appear in the textual dotted
notation.
The description clause of objects using the domain-name The description clause of objects using the domain-name
type MUST describe how (and when) these names are type MUST describe how (and when) these names are
resolved to IP addresses. resolved to IP addresses. Note that the resolution of a
domain-name value may require to query multiple DNS records
Note that the resolution of a domain-name value may (e.g., A for IPv4 and AAAA for IPv6). The order of the
require to query multiple DNS records (e.g., A for IPv4 resolution process and which DNS record takes precedence
and AAAA for IPv6). The order of the resolution process depends on the configuration of the resolver.
and which DNS record takes precedence depends on the
configuration of the resolver.
The canonical format for domain-name values uses the US-ASCII The canonical format for domain-name values uses the
encoding and case-insensitive characters are set to lowercase."; US-ASCII encoding and case-insensitive characters are set
to lowercase.";
reference reference
"RFC 1034: Domain Names - Concepts and Facilities "RFC 952: DoD Internet Host Table Specification
RFC 1034: Domain Names - Concepts and Facilities
RFC 1123: Requirements for Internet Hosts -- Application RFC 1123: Requirements for Internet Hosts -- Application
and Support"; and Support
RFC 3490: Internationalizing Domain Names in Applications
(IDNA)";
} }
// [TODO] RFC 2181 says there are no restrictions on DNS
// labels. Need to check whether the pattern above is too
// restrictive. We probably need advice from DNS experts.
typedef host { typedef host {
type union { type union {
type inet:ip-address; type inet:ip-address;
type inet:domain-name; type inet:domain-name;
} }
description description
"The host type represents either an IP address or a DNS "The host type represents either an IP address or a DNS
domain name."; domain name.";
} }
typedef uri { typedef uri {
type string; // [TODO] add the regex from RFC 3986 here? type string;
description description
"The uri type represents a Uniform Resource Identifier "The uri type represents a Uniform Resource Identifier
(URI) as defined by STD 66. (URI) as defined by STD 66.
Objects using the uri type must be in US-ASCII encoding, Objects using the uri type must be in US-ASCII encoding,
and MUST be normalized as described by RFC 3986 Sections and MUST be normalized as described by RFC 3986 Sections
6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary
percent-encoding is removed, and all case-insensitive percent-encoding is removed, and all case-insensitive
characters are set to lowercase except for hexadecimal characters are set to lowercase except for hexadecimal
digits, which are normalized to uppercase as described in digits, which are normalized to uppercase as described in
skipping to change at page 21, line 12 skipping to change at page 25, line 4
sufficient to provide uniqueness. Two URIs that are sufficient to provide uniqueness. Two URIs that are
textually distinct after this normalization may still be textually distinct after this normalization may still be
equivalent. equivalent.
Objects using the uri type may restrict the schemes that Objects using the uri type may restrict the schemes that
they permit. For example, 'data:' and 'urn:' schemes they permit. For example, 'data:' and 'urn:' schemes
might not be appropriate. might not be appropriate.
A zero-length URI is not a valid URI. This can be used to A zero-length URI is not a valid URI. This can be used to
express 'URI absent' where required express 'URI absent' where required
This type is in the value set and its semantics equivalent This type is in the value set and its semantics equivalent
to the Uri textual convention of the SMIv2."; to the Uri SMIv2 textual convention defined in RFC 5017.";
reference reference
"RFC 3986: Uniform Resource Identifier (URI): Generic Syntax "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax
RFC 3305: Report from the Joint W3C/IETF URI Planning Interest RFC 3305: Report from the Joint W3C/IETF URI Planning Interest
Group: Uniform Resource Identifiers (URIs), URLs, Group: Uniform Resource Identifiers (URIs), URLs,
and Uniform Resource Names (URNs): Clarifications and Uniform Resource Names (URNs): Clarifications
and Recommendations and Recommendations
RFC 5017: MIB Textual Conventions for Uniform Resource RFC 5017: MIB Textual Conventions for Uniform Resource
Identifiers (URIs)"; Identifiers (URIs)";
} }
} }
4. IEEE Specific Derived Types
module ietf-ieee-types {
namespace "urn:ietf:params:xml:ns:yang:ieee-types";
prefix "ieee";
organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group";
contact
"WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
WG Chair: David Partain
<mailto:david.partain@ericsson.com>
WG Chair: David Kessens
<mailto:david.kessens@nsn.com>
Editor: Juergen Schoenwaelder
<mailto:j.schoenwaelder@jacobs-university.de>";
description
"This module contains a collection of generally useful derived
YANG data types for IEEE 802 addresses and related things.
Copyright (C) 2009 The IETF Trust and the persons identified as
the document authors. This version of this YANG module is part
of RFC XXXX; see the RFC itself for full legal notices.";
// RFC Ed.: replace XXXX with actual RFC number and remove this note
revision 2009-03-09 {
description
"Initial revision, published as RFC XXXX";
}
// RFC Ed.: replace XXXX with actual RFC number and remove this note
/*** collection of IEEE address type definitions ***/
typedef mac-address {
type string {
pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}';
}
description
"The mac-address type represents an 802 MAC address represented
in the `canonical' order defined by IEEE 802.1a, i.e., as if it
were transmitted least significant bit first, even though 802.5
(in contrast to other 802.x protocols) requires MAC addresses
to be transmitted most significant bit first.
This type is in the value set and its semantics equivalent to
the MacAddress textual convention of the SMIv2.";
reference
"RFC 2579: Textual Conventions for SMIv2";
}
/*** collection of IEEE 802 related identifier types ***/
typedef bridgeid {
type string {
pattern '[0-9a-fA-F]{4}(:[0-9a-fA-F]{2}){6}';
}
description
"The bridgeid type represents identifiers that uniquely
identify a bridge. Its first four hexadecimal digits
contain a priority value followed by a colon. The
remaining characters contain the MAC address used to
refer to a bridge in a unique fashion (typically, the
numerically smallest MAC address of all ports on the
bridge).
This type is in the value set and its semantics equivalent
to the BridgeId textual convention of the SMIv2. However,
since the BridgeId textual convention does not prescribe
a lexical representation, the appearance might be different.";
reference
"RFC 4188: Definitions of Managed Objects for Bridges";
}
typedef vlanid {
type uint16 {
range "1..4094";
}
description
"The vlanid type uniquely identifies a VLAN. This is the
12-bit VLAN-ID used in the VLAN Tag header. The range is
defined by the referenced specification.
This type is in the value set and its semantics equivalent to
the VlanId textual convention of the SMIv2.";
reference
"IEEE Std 802.1Q 2003 Edition: Virtual Bridged Local
Area Networks
RFC 4363: Definitions of Managed Objects for Bridges with
Traffic Classes, Multicast Filtering, and Virtual
LAN Extensions";
}
}
5. IANA Considerations 5. IANA Considerations
A registry for standard YANG modules shall be set up. The name of A registry for standard YANG modules shall be set up. The name of
the registry is "IETF YANG Modules" and the registry shall record for the registry is "IETF YANG Modules" and the registry shall record for
each entry the unique name of a YANG module, the assigned XML each entry the unique name of a YANG module, the assigned XML
namespace from the YANG URI Scheme, and a reference to the module's namespace from the YANG URI Scheme, and a reference to the module's
documentation (typically and RFC). Allocations require IETF Review documentation (typically and RFC). Allocations require IETF Review
as defined in [RFC5226]. The initial assignments are: as defined in [RFC5226]. The initial assignments are:
YANG Module XML namespace Reference YANG Module XML namespace Reference
----------- -------------------------------------- --------- ----------- -------------------------------------- ---------
yang-types urn:ietf:params:xml:ns:yang:yang-types RFC XXXX ietf-yang-types urn:ietf:params:xml:ns:yang:yang-types RFC XXXX
inet-types urn:ietf:params:xml:ns:yang:inet-types RFC XXXX ietf-inet-types urn:ietf:params:xml:ns:yang:inet-types RFC XXXX
ieee-types urn:ietf:params:xml:ns:yang:ieee-types RFC XXXX
RFC Ed.: replace XXXX with actual RFC number and remove this note RFC Ed.: replace XXXX with actual RFC number and remove this note
This document registers three URIs in the IETF XML registry This document registers three URIs in the IETF XML registry
[RFC3688]. Following the format in RFC 3688, the following [RFC3688]. Following the format in RFC 3688, the following
registration is requested. registration is requested.
URI: urn:ietf:params:xml:ns:yang:yang-types URI: urn:ietf:params:xml:ns:yang:yang-types
URI: urn:ietf:params:xml:ns:yang:inet-types URI: urn:ietf:params:xml:ns:yang:inet-types
URI: urn:ietf:params:xml:ns:yang:ieee-types
Registrant Contact: The NETMOD WG of the IETF. Registrant Contact: The NETMOD WG of the IETF.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
6. Security Considerations 6. Security Considerations
This document defines common data types using the YANG data modeling This document defines common data types using the YANG data modeling
language. The definitions themselves have no security impact on the language. The definitions themselves have no security impact on the
Internet but the usage of these definitions in concrete YANG modules Internet but the usage of these definitions in concrete YANG modules
skipping to change at page 28, line 5 skipping to change at page 29, line 5
The following people all contributed significantly to the initial The following people all contributed significantly to the initial
version of this draft: version of this draft:
- Andy Bierman (andybierman.com) - Andy Bierman (andybierman.com)
- Martin Bjorklund (Tail-f Systems) - Martin Bjorklund (Tail-f Systems)
- Balazs Lengyel (Ericsson) - Balazs Lengyel (Ericsson)
- David Partain (Ericsson) - David Partain (Ericsson)
- Phil Shafer (Juniper Networks) - Phil Shafer (Juniper Networks)
8. References 8. Acknowledgments
8.1. Normative References The editor wishes to thank the following individuals for providing
helpful comments on various versions of this document: Ladislav
Lhotka, Lars-Johan Liman.
9. References
9.1. Normative References
[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.
[YANG] Bjorklund, M., Ed., "YANG - A data modeling language for [YANG] Bjorklund, M., Ed., "YANG - A data modeling language for
NETCONF", draft-ietf-netmod-yang-04 (work in progress). NETCONF", draft-ietf-netmod-yang-05 (work in progress).
8.2. Informative References
[802.1Q] ANSI/IEEE Standard 802.1Q, "IEEE Standards for Local and 9.2. Informative References
Metropolitan Area Networks: Virtual Bridged Local Area
Networks", 2003.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
host table specification", RFC 952, October 1985.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation,
selection, and registration of an Autonomous System (AS)", selection, and registration of an Autonomous System (AS)",
BCP 6, RFC 1930, March 1996. BCP 6, RFC 1930, March 1996.
skipping to change at page 29, line 40 skipping to change at page 31, line 39
[RFC3305] Mealling, M. and R. Denenberg, "Report from the Joint W3C/ [RFC3305] Mealling, M. and R. Denenberg, "Report from the Joint W3C/
IETF URI Planning Interest Group: Uniform Resource IETF URI Planning Interest Group: Uniform Resource
Identifiers (URIs), URLs, and Uniform Resource Names Identifiers (URIs), URLs, and Uniform Resource Names
(URNs): Clarifications and Recommendations", RFC 3305, (URNs): Clarifications and Recommendations", RFC 3305,
August 2002. August 2002.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002. Internet: Timestamps", RFC 3339, July 2002.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC3595] Wijnen, B., "Textual Conventions for IPv6 Flow Label", [RFC3595] Wijnen, B., "Textual Conventions for IPv6 Flow Label",
RFC 3595, September 2003. RFC 3595, September 2003.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet Network Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 4001, February 2005. Addresses", RFC 4001, February 2005.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
March 2005. March 2005.
[RFC4188] Norseth, K. and E. Bell, "Definitions of Managed Objects
for Bridges", RFC 4188, September 2005.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006. Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
skipping to change at page 31, line 19 skipping to change at page 33, line 19
normative. normative.
A.1. XSD of Core YANG Derived Types A.1. XSD of Core YANG Derived Types
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:yang:yang-types" targetNamespace="urn:ietf:params:xml:ns:yang:yang-types"
xmlns="urn:ietf:params:xml:ns:yang:yang-types" xmlns="urn:ietf:params:xml:ns:yang:yang-types"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified" attributeFormDefault="unqualified"
version="2009-03-09" version="2009-05-13"
xml:lang="en" xml:lang="en"
xmlns:yang="urn:ietf:params:xml:ns:yang:yang-types"> xmlns:yang="urn:ietf:params:xml:ns:yang:yang-types">
<xs:annotation> <xs:annotation>
<xs:documentation> <xs:documentation>
This module contains a collection of generally useful derived This module contains a collection of generally useful derived
YANG data types. YANG data types.
Copyright (C) 2009 The IETF Trust and the persons identified as Copyright (c) 2009 IETF Trust and the persons identified as
the document authors. This version of this YANG module is part the document authors. All rights reserved.
of RFC XXXX; see the RFC itself for full legal notices.
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the
following conditions are met:
- Redistributions of source code must retain the above
copyright notice, this list of conditions and the
following disclaimer.
- Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the
following disclaimer in the documentation and/or other
materials provided with the distribution.
- Neither the name of Internet Society, IETF or IETF
Trust, nor the names of specific contributors, may be
used to endorse or promote products derived from this
software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<!-- YANG typedefs --> <!-- YANG typedefs -->
<xs:simpleType name="counter32"> <xs:simpleType name="counter32">
<xs:annotation> <xs:annotation>
<xs:documentation> <xs:documentation>
The counter32 type represents a non-negative integer The counter32 type represents a non-negative integer
which monotonically increases until it reaches a which monotonically increases until it reaches a
skipping to change at page 38, line 27 skipping to change at page 41, line 15
This type is in the value set and its semantics equivalent This type is in the value set and its semantics equivalent
to the PhysAddress textual convention of the SMIv2. to the PhysAddress textual convention of the SMIv2.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:pattern value="([0-9a0-fA-F]{2}(:[0-9a0-fA-F]{2})*)?"/> <xs:pattern value="([0-9a0-fA-F]{2}(:[0-9a0-fA-F]{2})*)?"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="xpath"> <xs:simpleType name="mac-address">
<xs:annotation>
<xs:documentation>
The mac-address type represents an 802 MAC address represented
in the `canonical' order defined by IEEE 802.1a, i.e., as if it
were transmitted least significant bit first, even though 802.5
(in contrast to other 802.x protocols) requires MAC addresses
to be transmitted most significant bit first.
This type is in the value set and its semantics equivalent to
the MacAddress textual convention of the SMIv2.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:pattern value="[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="xpath1.0">
<xs:annotation> <xs:annotation>
<xs:documentation> <xs:documentation>
This type represents an XPATH 1.0 expression. This type represents an XPATH 1.0 expression.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
A.2. XSD of Internet Specific Derived Types A.2. XSD of Internet Specific Derived Types
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:yang:inet-types" targetNamespace="urn:ietf:params:xml:ns:yang:inet-types"
xmlns="urn:ietf:params:xml:ns:yang:inet-types" xmlns="urn:ietf:params:xml:ns:yang:inet-types"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified" attributeFormDefault="unqualified"
version="2009-03-09" version="2009-05-13"
xml:lang="en" xml:lang="en"
xmlns:inet="urn:ietf:params:xml:ns:yang:inet-types"> xmlns:inet="urn:ietf:params:xml:ns:yang:inet-types">
<xs:annotation> <xs:annotation>
<xs:documentation> <xs:documentation>
This module contains a collection of generally useful derived This module contains a collection of generally useful derived
YANG data types for Internet addresses and related things. YANG data types for Internet addresses and related things.
Copyright (C) 2009 The IETF Trust and the persons identified as Copyright (c) 2009 IETF Trust and the persons identified as
the document authors. This version of this YANG module is part the document authors. All rights reserved.
of RFC XXXX; see the RFC itself for full legal notices.
Redistribution and use in source and binary forms, with or
without modification, are permitted provided that the
following conditions are met:
- Redistributions of source code must retain the above
copyright notice, this list of conditions and the
following disclaimer.
- Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the
following disclaimer in the documentation and/or other
materials provided with the distribution.
- Neither the name of Internet Society, IETF or IETF
Trust, nor the names of specific contributors, may be
used to endorse or promote products derived from this
software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<!-- YANG typedefs --> <!-- YANG typedefs -->
<xs:simpleType name="ip-version"> <xs:simpleType name="ip-version">
<xs:annotation> <xs:annotation>
<xs:documentation> <xs:documentation>
This value represents the version of the IP protocol. This value represents the version of the IP protocol.
skipping to change at page 40, line 4 skipping to change at page 43, line 47
This type is in the value set and its semantics equivalent This type is in the value set and its semantics equivalent
to the Dscp textual convention of the SMIv2. to the Dscp textual convention of the SMIv2.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:restriction base="xs:unsignedByte"> <xs:restriction base="xs:unsignedByte">
<xs:minInclusive value="0"/> <xs:minInclusive value="0"/>
<xs:maxInclusive value="63"/> <xs:maxInclusive value="63"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="flow-label">
<xs:simpleType name="ipv6-flow-label">
<xs:annotation> <xs:annotation>
<xs:documentation> <xs:documentation>
The flow-label type represents flow identifier or Flow Label The flow-label type represents flow identifier or Flow Label
in an IPv6 packet header that may be used to discriminate in an IPv6 packet header that may be used to discriminate
traffic flows. traffic flows.
This type is in the value set and its semantics equivalent This type is in the value set and its semantics equivalent
to the IPv6FlowLabel textual convention of the SMIv2. to the IPv6FlowLabel textual convention of the SMIv2.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
skipping to change at page 42, line 37 skipping to change at page 46, line 32
The ipv6-address type represents an IPv6 address in full, The ipv6-address type represents an IPv6 address in full,
mixed, shortened and shortened mixed notation. The IPv6 mixed, shortened and shortened mixed notation. The IPv6
address may include a zone index, separated by a % sign. address may include a zone index, separated by a % sign.
The zone index is used to disambiguate identical address The zone index is used to disambiguate identical address
values. For link-local addresses, the zone index will values. For link-local addresses, the zone index will
typically be the interface index number or the name of an typically be the interface index number or the name of an
interface. If the zone index is not present, the default interface. If the zone index is not present, the default
zone of the device will be used. zone of the device will be used.
The canonical format of IPv6 addresses must match the The canonical format of IPv6 addresses uses the compressed
pattern '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})' format described in RFC 4291 section 2.2 item 2 with the
with leading zeros suppressed as described in RFC 4291 following additional rules: The :: substitution must be
section 2.2 item 1. The canonical format for the zone applied to the longest sequence of all-zero 16-bit chunks
index is the numerical format as described in RFC 4007 in an IPv6 address. If there is a tie, the first sequence
section 11.2. of all-zero 16-bit chunks is replaced by ::. Single
all-zero 16-bit chunks are not compressed. The normalized
format uses lower-case characters and leading zeros are
not allowed. The canonical format for the zone index is
the numerical format as described in RFC 4007 section
11.2.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:restriction>
<xs:simpleType>
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:pattern value="((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4}) <xs:pattern value="(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|(
(%[\p{N}\p{L}]+)?)|((([0-9a-fA-F]{1,4}:){6}) (([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)(%.
(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{ +)?"/>
1,3}))(%[\p{N}\p{L}]+)?)|((([0-9a-fA-F]{1,4} </xs:restriction>
:)*([0-9a-fA-F]{1,4}))*(::)(([0-9a-fA-F]{1,4 </xs:simpleType>
}:)*([0-9a-fA-F]{1,4}))*(%[\p{N}\p{L}]+)?)|( <xs:pattern value="((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){
(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(:: 0,5}((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4
)(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(( }))|(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])
[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1, \.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])
3}))(%[\p{N}\p{L}]+)?)"/> ))(%[\p{N}\p{L}]+)?"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="ip-prefix"> <xs:simpleType name="ip-prefix">
<xs:annotation> <xs:annotation>
<xs:documentation> <xs:documentation>
The ip-prefix type represents an IP prefix and is IP The ip-prefix type represents an IP prefix and is IP
version neutral. The format of the textual representations version neutral. The format of the textual representations
implies the IP version. implies the IP version.
</xs:documentation> </xs:documentation>
skipping to change at page 43, line 48 skipping to change at page 48, line 4
A prefix length value of n corresponds to an IP address A prefix length value of n corresponds to an IP address
mask which has n contiguous 1-bits from the most mask which has n contiguous 1-bits from the most
significant bit (MSB) and all other bits set to 0. significant bit (MSB) and all other bits set to 0.
The canonical format of an IPv4 prefix has all bits of The canonical format of an IPv4 prefix has all bits of
the IPv4 address set to zero that are not part of the the IPv4 address set to zero that are not part of the
IPv4 prefix. IPv4 prefix.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:pattern value="(([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.) <xs:pattern value="(([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.)
{3}([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])/\ {3}([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])/(
d+"/> ([0-9])|([1-2][0-9])|(3[0-2]))"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="ipv6-prefix"> <xs:simpleType name="ipv6-prefix">
<xs:annotation> <xs:annotation>
<xs:documentation> <xs:documentation>
The ipv6-prefix type represents an IPv6 address prefix. The ipv6-prefix type represents an IPv6 address prefix.
The prefix length is given by the number following the The prefix length is given by the number following the
slash character and must be less than or equal 128. slash character and must be less than or equal 128.
A prefix length value of n corresponds to an IP address A prefix length value of n corresponds to an IP address
mask which has n contiguous 1-bits from the most mask which has n contiguous 1-bits from the most
significant bit (MSB) and all other bits set to 0. significant bit (MSB) and all other bits set to 0.
The IPv6 address should have all bits that do not belong The IPv6 address should have all bits that do not belong
to the prefix set to zero. to the prefix set to zero.
The canonical format of an IPv6 prefix has all bits of The canonical format of an IPv6 prefix has all bits of
the IPv6 address set to zero that are not part of the the IPv6 address set to zero that are not part of the
IPv6 prefix. Furthermore, the IPv6 address must match the IPv6 prefix. Furthermore, IPv6 address is represented
pattern '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})' in the compressed format described in RFC 4291 section
with leading zeros suppressed as described in RFC 4291 2.2 item 2 with the following additional rules: The ::
section 2.2 item 1. substitution must be applied to the longest sequence of
all-zero 16-bit chunks in an IPv6 address. If there is
a tie, the first sequence of all-zero 16-bit chunks is
replaced by ::. Single all-zero 16-bit chunks are not
compressed. The normalized format uses lower-case
characters and leading zeros are not allowed.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:restriction>
<xs:simpleType>
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:pattern value="((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4}) <xs:pattern value="(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|(
/\d+)|((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\ (([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)(/.
.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))/\d+)|( +)"/>
(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(:: </xs:restriction>
)(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*/\ </xs:simpleType>
d+)|((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}) <xs:pattern value="((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){
)*(::)(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4} 0,5}((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4
))*(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0- }))|(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])
9]{1,3}))/\d+)"/> \.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])
))(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-
8])))"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="domain-name"> <xs:simpleType name="domain-name">
<xs:annotation> <xs:annotation>
<xs:documentation> <xs:documentation>
The domain-name type represents a DNS domain name. The The domain-name type represents a DNS domain name. The
name SHOULD be fully qualified whenever possible. name SHOULD be fully qualified whenever possible.
Internet domain names are only loosely specified. Section
3.5 of RFC 1034 recommends a syntax (modified in section
2.1 of RFC 1123). The pattern above is intended to allow
for current practise in domain name use, and some possible
future expansion. It is designed to hold various types of
domain names, including names used for A or AAAA records
(host names) and other records, such as SRV records. Note
that Internet host names have a stricter syntax (described
in RFC 952) than the DNS recommendations in RFCs 1034 and
1123, and that systems that want to store host names in
objects using the domain-name type are recommended to adhere
to this stricter standard to ensure interoperability.
The encoding of DNS names in the DNS protocol is limited
to 255 characters. Since the encoding consists of labels
prefixed by a length bytes and there is a trailing NULL
byte, only 253 characters can appear in the textual dotted
notation.
The description clause of objects using the domain-name The description clause of objects using the domain-name
type MUST describe how (and when) these names are type MUST describe how (and when) these names are
resolved to IP addresses. resolved to IP addresses. Note that the resolution of a
domain-name value may require to query multiple DNS records
Note that the resolution of a domain-name value may (e.g., A for IPv4 and AAAA for IPv6). The order of the
require to query multiple DNS records (e.g., A for IPv4 resolution process and which DNS record takes precedence
and AAAA for IPv6). The order of the resolution process depends on the configuration of the resolver.
and which DNS record takes precedence depends on the
configuration of the resolver.
The canonical format for domain-name values uses the US-ASCII The canonical format for domain-name values uses the
encoding and case-insensitive characters are set to lowercase. US-ASCII encoding and case-insensitive characters are set
to lowercase.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:restriction base="xs:string"> <xs:restriction base="t0">
<xs:pattern value="([a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9]\.)*[a <xs:minLength value="1"/>
-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9]"/> <xs:maxLength value="253"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="host"> <xs:simpleType name="host">
<xs:annotation> <xs:annotation>
<xs:documentation> <xs:documentation>
The host type represents either an IP address or a DNS The host type represents either an IP address or a DNS
domain name. domain name.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:union> <xs:union>
<xs:simpleType> <xs:simpleType>
skipping to change at page 46, line 23 skipping to change at page 51, line 4
equivalent. equivalent.
Objects using the uri type may restrict the schemes that Objects using the uri type may restrict the schemes that
they permit. For example, 'data:' and 'urn:' schemes they permit. For example, 'data:' and 'urn:' schemes
might not be appropriate. might not be appropriate.
A zero-length URI is not a valid URI. This can be used to A zero-length URI is not a valid URI. This can be used to
express 'URI absent' where required express 'URI absent' where required
This type is in the value set and its semantics equivalent This type is in the value set and its semantics equivalent
to the Uri textual convention of the SMIv2. to the Uri SMIv2 textual convention defined in RFC 5017.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
</xs:restriction>
</xs:simpleType>
</xs:schema>
A.3. XSD of IEEE Specific Derived Types
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:yang:ieee-types"
xmlns="urn:ietf:params:xml:ns:yang:ieee-types"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
version="2009-03-09"
xml:lang="en"
xmlns:ieee="urn:ietf:params:xml:ns:yang:ieee-types">
<xs:annotation>
<xs:documentation>
This module contains a collection of generally useful derived
YANG data types for IEEE 802 addresses and related things.
Copyright (C) 2009 The IETF Trust and the persons identified as
the document authors. This version of this YANG module is part
of RFC XXXX; see the RFC itself for full legal notices.
</xs:documentation>
</xs:annotation>
<!-- YANG typedefs -->
<xs:simpleType name="mac-address">
<xs:annotation>
<xs:documentation>
The mac-address type represents an 802 MAC address represented
in the `canonical' order defined by IEEE 802.1a, i.e., as if it
were transmitted least significant bit first, even though 802.5
(in contrast to other 802.x protocols) requires MAC addresses
to be transmitted most significant bit first.
This type is in the value set and its semantics equivalent to
the MacAddress textual convention of the SMIv2.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:pattern value="[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="bridgeid"> <!-- locally generated simpleType helpers -->
<xs:annotation>
<xs:documentation>
The bridgeid type represents identifiers that uniquely
identify a bridge. Its first four hexadecimal digits
contain a priority value followed by a colon. The
remaining characters contain the MAC address used to
refer to a bridge in a unique fashion (typically, the
numerically smallest MAC address of all ports on the
bridge).
This type is in the value set and its semantics equivalent
to the BridgeId textual convention of the SMIv2. However,
since the BridgeId textual convention does not prescribe
a lexical representation, the appearance might be different.
</xs:documentation>
</xs:annotation>
<xs:simpleType name="t0">
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:pattern value="[0-9a-fA-F]{4}(:[0-9a-fA-F]{2}){6}"/> <xs:pattern value="((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-z
</xs:restriction> A-Z0-9]\.)*([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,6
</xs:simpleType> 1})?[a-zA-Z0-9]\.?)|\."/>
<xs:simpleType name="vlanid">
<xs:annotation>
<xs:documentation>
The vlanid type uniquely identifies a VLAN. This is the
12-bit VLAN-ID used in the VLAN Tag header. The range is
defined by the referenced specification.
This type is in the value set and its semantics equivalent to
the VlanId textual convention of the SMIv2.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:unsignedShort">
<xs:minInclusive value="1"/>
<xs:maxInclusive value="4094"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
Appendix B. RelaxNG Translations Appendix B. RelaxNG Translations
This appendix provides RelaxNG translations of the types defined in This appendix provides RelaxNG translations of the types defined in
this document. This appendix is informative and not normative. this document. This appendix is informative and not normative.
skipping to change at page 49, line 26 skipping to change at page 52, line 26
namespace sch = "http://purl.oclc.org/dsdl/schematron" namespace sch = "http://purl.oclc.org/dsdl/schematron"
namespace yang = "urn:ietf:params:xml:ns:yang:yang-types" namespace yang = "urn:ietf:params:xml:ns:yang:yang-types"
dc:creator [ dc:creator [
"IETF NETMOD (NETCONF Data Modeling Language) Working Group" "IETF NETMOD (NETCONF Data Modeling Language) Working Group"
] ]
dc:description [ dc:description [
"This module contains a collection of generally useful derived\x{a}" ~ "This module contains a collection of generally useful derived\x{a}" ~
"YANG data types.\x{a}" ~ "YANG data types.\x{a}" ~
"\x{a}" ~ "\x{a}" ~
"Copyright (C) 2009 The IETF Trust and the persons identif" "Copyright (c) 2009 IETF Trust and the persons identified as\x{a}" ~
~ "ied as\x{a}" ~ "the document authors. All rights reserved.\x{a}" ~
"the document authors. This version of this YANG module i" "\x{a}" ~
~ "s part\x{a}" ~ "Redistribution and use in source and binary forms, with or\x{a}" ~
"of RFC XXXX; see the RFC itself for full legal notices." "without modification, are permitted provided that the\x{a}" ~
"following conditions are met:\x{a}" ~
"\x{a}" ~
"- Redistributions of source code must retain the above\x{a}" ~
" copyright notice, this list of conditions and the\x{a}" ~
" following disclaimer.\x{a}" ~
"\x{a}" ~
"- Redistributions in binary form must reproduce the above\x{a}" ~
" copyright notice, this list of conditions and the\x{a}" ~
" following disclaimer in the documentation and/or other\x{a}" ~
" materials provided with the distribution.\x{a}" ~
"\x{a}" ~
"- Neither the name of Internet Society, IETF or IETF\x{a}" ~
" Trust, nor the names of specific contributors, may be\x{a}" ~
" used to endorse or promote products derived from this\x{a}" ~
" software without specific prior written permission.\x{a}" ~
"\x{a}" ~
"THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND\x{a}" ~
"CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED\x{a}" ~
"WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED\x{a}" ~
"WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR\x{a}" ~
"PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT\x{a}" ~
"OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,\x{a}" ~
"INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES\x{a}" ~
"(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE\x{a}" ~
"GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR\x{a}" ~
"BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF\x{a}" ~
"LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT\x{a}" ~
"(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT\x{a}" ~
"OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE\x{a}" ~
"POSSIBILITY OF SUCH DAMAGE.\x{a}" ~
"\x{a}" ~
"This version of this YANG module is part of RFC XXXX; see\x{a}" ~
"the RFC itself for full legal notices."
] ]
dc:issued [ "2009-03-09" ] dc:issued [ "2009-05-13" ]
dc:source [ "YANG module 'ietf-yang-types' (automatic translation)" ] dc:source [ "YANG module 'ietf-yang-types' (automatic translation)" ]
dc:contributor [ dc:contributor [
"WG Web: <http://tools.ietf.org/wg/netmod/>\x{a}" ~ "WG Web: <http://tools.ietf.org/wg/netmod/>\x{a}" ~
"WG List: <mailto:netmod@ietf.org>\x{a}" ~ "WG List: <mailto:netmod@ietf.org>\x{a}" ~
"\x{a}" ~ "\x{a}" ~
"WG Chair: David Partain\x{a}" ~ "WG Chair: David Partain\x{a}" ~
" <mailto:david.partain@ericsson.com>\x{a}" ~ " <mailto:david.partain@ericsson.com>\x{a}" ~
"\x{a}" ~ "\x{a}" ~
"WG Chair: David Kessens\x{a}" ~ "WG Chair: David Kessens\x{a}" ~
" <mailto: david.kessens@nsn.com>\x{a}" ~ " <mailto: david.kessens@nsn.com>\x{a}" ~
skipping to change at page 55, line 21 skipping to change at page 59, line 4
## ##
## This type is in the value set and its semantics equivalent ## This type is in the value set and its semantics equivalent
## to the TimeStamp textual convention of the SMIv2. ## to the TimeStamp textual convention of the SMIv2.
## See: RFC 2579: Textual Conventions for SMIv2 ## See: RFC 2579: Textual Conventions for SMIv2
timestamp = timeticks timestamp = timeticks
## Represents media- or physical-level addresses represented ## Represents media- or physical-level addresses represented
## as a sequence octets, each octet represented by two hexadecimal ## as a sequence octets, each octet represented by two hexadecimal
## numbers. Octets are separated by colons. ## numbers. Octets are separated by colons.
## ##
## This type is in the value set and its semantics equivalent ## This type is in the value set and its semantics equivalent
## to the PhysAddress textual convention of the SMIv2. ## to the PhysAddress textual convention of the SMIv2.
## See: RFC 2579: Textual Conventions for SMIv2 ## See: RFC 2579: Textual Conventions for SMIv2
phys-address = phys-address =
xsd:string { pattern = "([0-9a0-fA-F]{2}(:[0-9a0-fA-F]{2})*)?" } xsd:string { pattern = "([0-9a0-fA-F]{2}(:[0-9a0-fA-F]{2})*)?" }
## The mac-address type represents an 802 MAC address represented
## in the `canonical' order defined by IEEE 802.1a, i.e., as if it
## were transmitted least significant bit first, even though 802.5
## (in contrast to other 802.x protocols) requires MAC addresses
## to be transmitted most significant bit first.
##
## This type is in the value set and its semantics equivalent to
## the MacAddress textual convention of the SMIv2.
## See: RFC 2579: Textual Conventions for SMIv2
mac-address =
xsd:string { pattern = "[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}" }
## This type represents an XPATH 1.0 expression. ## This type represents an XPATH 1.0 expression.
## See: W3C REC-xpath-19991116: XML Path Language (XPath) Version 1.0 ## See: W3C REC-xpath-19991116: XML Path Language (XPath) Version 1.0
xpath = xsd:string xpath1.0 = xsd:string
B.2. RelaxNG of Internet Specific Derived Types B.2. RelaxNG of Internet Specific Derived Types
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
namespace dc = "http://purl.org/dc/terms" namespace dc = "http://purl.org/dc/terms"
namespace dsrl = "http://purl.oclc.org/dsdl/dsrl" namespace dsrl = "http://purl.oclc.org/dsdl/dsrl"
namespace inet = "urn:ietf:params:xml:ns:yang:inet-types" namespace inet = "urn:ietf:params:xml:ns:yang:inet-types"
namespace nm = "urn:ietf:params:xml:ns:netmod:dsdl-attrib:1" namespace nm = "urn:ietf:params:xml:ns:netmod:dsdl-attrib:1"
namespace sch = "http://purl.oclc.org/dsdl/schematron" namespace sch = "http://purl.oclc.org/dsdl/schematron"
dc:creator [ dc:creator [
"IETF NETMOD (NETCONF Data Modeling Language) Working Group" "IETF NETMOD (NETCONF Data Modeling Language) Working Group"
] ]
dc:description [ dc:description [
"This module contains a collection of generally useful derived\x{a}" ~ "This module contains a collection of generally useful derived\x{a}" ~
"YANG data types for Internet addresses and related things.\x{a}" ~ "YANG data types for Internet addresses and related things.\x{a}" ~
"\x{a}" ~ "\x{a}" ~
"Copyright (C) 2009 The IETF Trust and the persons identif" "Copyright (c) 2009 IETF Trust and the persons identified as\x{a}" ~
~ "ied as\x{a}" ~ "the document authors. All rights reserved.\x{a}" ~
"the document authors. This version of this YANG module i" "\x{a}" ~
~ "s part\x{a}" ~ "Redistribution and use in source and binary forms, with or\x{a}" ~
"of RFC XXXX; see the RFC itself for full legal notices." "without modification, are permitted provided that the\x{a}" ~
"following conditions are met:\x{a}" ~
"\x{a}" ~
"- Redistributions of source code must retain the above\x{a}" ~
" copyright notice, this list of conditions and the\x{a}" ~
" following disclaimer.\x{a}" ~
"\x{a}" ~
"- Redistributions in binary form must reproduce the above\x{a}" ~
" copyright notice, this list of conditions and the\x{a}" ~
" following disclaimer in the documentation and/or other\x{a}" ~
" materials provided with the distribution.\x{a}" ~
"\x{a}" ~
"- Neither the name of Internet Society, IETF or IETF\x{a}" ~
" Trust, nor the names of specific contributors, may be\x{a}" ~
" used to endorse or promote products derived from this\x{a}" ~
" software without specific prior written permission.\x{a}" ~
"\x{a}" ~
"THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND\x{a}" ~
"CONTRIBUTORS 'AS IS' AND ANY EXPRESS OR IMPLIED\x{a}" ~
"WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED\x{a}" ~
"WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR\x{a}" ~
"PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT\x{a}" ~
"OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,\x{a}" ~
"INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES\x{a}" ~
"(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE\x{a}" ~
"GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR\x{a}" ~
"BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF\x{a}" ~
"LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT\x{a}" ~
"(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT\x{a}" ~
"OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE\x{a}" ~
"POSSIBILITY OF SUCH DAMAGE.\x{a}" ~
"\x{a}" ~
"This version of this YANG module is part of RFC XXXX; see \x{a}" ~
"the RFC itself for full legal notices."
] ]
dc:issued [ "2009-03-09" ] dc:issued [ "2009-05-13" ]
dc:source [ "YANG module 'ietf-inet-types' (automatic translation)" ] dc:source [ "YANG module 'ietf-inet-types' (automatic translation)" ]
dc:contributor [ dc:contributor [
"WG Web: <http://tools.ietf.org/wg/netmod/>\x{a}" ~ "WG Web: <http://tools.ietf.org/wg/netmod/>\x{a}" ~
"WG List: <mailto:netmod@ietf.org>\x{a}" ~ "WG List: <mailto:netmod@ietf.org>\x{a}" ~
"\x{a}" ~ "\x{a}" ~
"WG Chair: David Partain\x{a}" ~ "WG Chair: David Partain\x{a}" ~
" <mailto:david.partain@ericsson.com>\x{a}" ~ " <mailto:david.partain@ericsson.com>\x{a}" ~
"\x{a}" ~ "\x{a}" ~
"WG Chair: David Kessens\x{a}" ~ "WG Chair: David Kessens\x{a}" ~
" <mailto:david.kessens@nsn.com>\x{a}" ~ " <mailto:david.kessens@nsn.com>\x{a}" ~
skipping to change at page 57, line 4 skipping to change at page 61, line 34
## Services Architecture ## Services Architecture
## RFC 2474: Definition of the Differentiated Services Field ## RFC 2474: Definition of the Differentiated Services Field
## (DS Field) in the IPv4 and IPv6 Headers ## (DS Field) in the IPv4 and IPv6 Headers
## RFC 2780: IANA Allocation Guidelines For Values In ## RFC 2780: IANA Allocation Guidelines For Values In
## the Internet Protocol and Related Headers ## the Internet Protocol and Related Headers
dscp = xsd:unsignedByte { minInclusive = "0" maxInclusive = "63" } dscp = xsd:unsignedByte { minInclusive = "0" maxInclusive = "63" }
## The flow-label type represents flow identifier or Flow Label ## The flow-label type represents flow identifier or Flow Label
## in an IPv6 packet header that may be used to discriminate ## in an IPv6 packet header that may be used to discriminate
## traffic flows. ## traffic flows.
## ##
## This type is in the value set and its semantics equivalent ## This type is in the value set and its semantics equivalent
## to the IPv6FlowLabel textual convention of the SMIv2. ## to the IPv6FlowLabel textual convention of the SMIv2.
## See: RFC 3595: Textual Conventions for IPv6 Flow Label ## See: RFC 3595: Textual Conventions for IPv6 Flow Label
## RFC 2460: Internet Protocol, Version 6 (IPv6) Specification ## RFC 2460: Internet Protocol, Version 6 (IPv6) Specification
flow-label = ipv6-flow-label =
xsd:unsignedInt { minInclusive = "0" maxInclusive = "1048575" } xsd:unsignedInt { minInclusive = "0" maxInclusive = "1048575" }
## The port-number type represents a 16-bit port number of an ## The port-number type represents a 16-bit port number of an
## Internet transport layer protocol such as UDP, TCP, DCCP or ## Internet transport layer protocol such as UDP, TCP, DCCP or
## SCTP. Port numbers are assigned by IANA. A current list of ## SCTP. Port numbers are assigned by IANA. A current list of
## all assignments is available from <http://www.iana.org/>. ## all assignments is available from <http://www.iana.org/>.
## ##
## Note that the value zero is not a valid port number. A union ## Note that the value zero is not a valid port number. A union
## type might be used in situations where the value zero is ## type might be used in situations where the value zero is
## meaningful. ## meaningful.
skipping to change at page 58, line 47 skipping to change at page 63, line 28
## The ipv6-address type represents an IPv6 address in full, ## The ipv6-address type represents an IPv6 address in full,
## mixed, shortened and shortened mixed notation. The IPv6 ## mixed, shortened and shortened mixed notation. The IPv6
## address may include a zone index, separated by a % sign. ## address may include a zone index, separated by a % sign.
## ##
## The zone index is used to disambiguate identical address ## The zone index is used to disambiguate identical address
## values. For link-local addresses, the zone index will ## values. For link-local addresses, the zone index will
## typically be the interface index number or the name of an ## typically be the interface index number or the name of an
## interface. If the zone index is not present, the default ## interface. If the zone index is not present, the default
## zone of the device will be used. ## zone of the device will be used.
## ##
## The canonical format of IPv6 addresses must match the ## The canonical format of IPv6 addresses uses the compressed
## pattern '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})' ## format described in RFC 4291 section 2.2 item 2 with the
## with leading zeros suppressed as described in RFC 4291 ## following additional rules: The :: substitution must be
## section 2.2 item 1. The canonical format for the zone ## applied to the longest sequence of all-zero 16-bit chunks
## index is the numerical format as described in RFC 4007 ## in an IPv6 address. If there is a tie, the first sequence
## section 11.2. ## of all-zero 16-bit chunks is replaced by ::. Single
## all-zero 16-bit chunks are not compressed. The normalized
## format uses lower-case characters and leading zeros are
## not allowed. The canonical format for the zone index is
## the numerical format as described in RFC 4007 section
## 11.2.
## See: RFC 4291: IP Version 6 Addressing Architecture ## See: RFC 4291: IP Version 6 Addressing Architecture
## RFC 4007: IPv6 Scoped Address Architecture ## RFC 4007: IPv6 Scoped Address Architecture
ipv6-address = ipv6-address =
xsd:string { xsd:string {
pattern = pattern =
"((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})(%[\p{N}\p" "((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}((([0-"
~ "{L}]+)?)|((([0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\.[0-9]{1,3}\." ~ "9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|(((25[0-5]|2[0-4][0-9]"
~ "[0-9]{1,3}\.[0-9]{1,3}))(%[\p{N}\p{L}]+)?)|((([0-9a-fA-F]{1," ~ "|[01]?[0-9]?[0-9])\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9"
~ "4}:)*([0-9a-fA-F]{1,4}))*(::)(([0-9a-fA-F]{1,4}:)*([0-9a-fA-" ~ "])))(%[\p{N}\p{L}]+)?"
~ "F]{1,4}))*(%[\p{N}\p{L}]+)?)|((([0-9a-fA-F]{1,4}:)*([0-9a-fA" pattern =
~ "-F]{1,4}))*(::)(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(([0" "(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|((([^:]+:)*[^:]"
~ "-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))(%[\p{N}\p{L}]" ~ "+)?::(([^:]+:)*[^:]+)?)(%.+)?"
~ "+)?)"
} }
## The ip-prefix type represents an IP prefix and is IP ## The ip-prefix type represents an IP prefix and is IP
## version neutral. The format of the textual representations ## version neutral. The format of the textual representations
## implies the IP version. ## implies the IP version.
ip-prefix = ipv4-prefix | ipv6-prefix ip-prefix = ipv4-prefix | ipv6-prefix
## The ipv4-prefix type represents an IPv4 address prefix. ## The ipv4-prefix type represents an IPv4 address prefix.
## The prefix length is given by the number following the ## The prefix length is given by the number following the
## slash character and must be less than or equal to 32. ## slash character and must be less than or equal to 32.
skipping to change at page 59, line 40 skipping to change at page 64, line 25
## mask which has n contiguous 1-bits from the most ## mask which has n contiguous 1-bits from the most
## significant bit (MSB) and all other bits set to 0. ## significant bit (MSB) and all other bits set to 0.
## ##
## The canonical format of an IPv4 prefix has all bits of ## The canonical format of an IPv4 prefix has all bits of
## the IPv4 address set to zero that are not part of the ## the IPv4 address set to zero that are not part of the
## IPv4 prefix. ## IPv4 prefix.
ipv4-prefix = ipv4-prefix =
xsd:string { xsd:string {
pattern = pattern =
"(([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}([0-1]?" "(([0-1]?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}([0-1]?"
~ "[0-9]?[0-9]|2[0-4][0-9]|25[0-5])/\d+" ~ "[0-9]?[0-9]|2[0-4][0-9]|25[0-5])/(([0-9])|([1-2][0-9])|(3[0-"
~ "2]))"
} }
## The ipv6-prefix type represents an IPv6 address prefix. ## The ipv6-prefix type represents an IPv6 address prefix.
## The prefix length is given by the number following the ## The prefix length is given by the number following the
## slash character and must be less than or equal 128. ## slash character and must be less than or equal 128.
## ##
## A prefix length value of n corresponds to an IP address ## A prefix length value of n corresponds to an IP address
## mask which has n contiguous 1-bits from the most ## mask which has n contiguous 1-bits from the most
## significant bit (MSB) and all other bits set to 0. ## significant bit (MSB) and all other bits set to 0.
## ##
skipping to change at page 60, line 4 skipping to change at page 64, line 39
## The ipv6-prefix type represents an IPv6 address prefix. ## The ipv6-prefix type represents an IPv6 address prefix.
## The prefix length is given by the number following the ## The prefix length is given by the number following the
## slash character and must be less than or equal 128. ## slash character and must be less than or equal 128.
## ##
## A prefix length value of n corresponds to an IP address ## A prefix length value of n corresponds to an IP address
## mask which has n contiguous 1-bits from the most ## mask which has n contiguous 1-bits from the most
## significant bit (MSB) and all other bits set to 0. ## significant bit (MSB) and all other bits set to 0.
## ##
## The IPv6 address should have all bits that do not belong ## The IPv6 address should have all bits that do not belong
## to the prefix set to zero. ## to the prefix set to zero.
## ##
## The canonical format of an IPv6 prefix has all bits of ## The canonical format of an IPv6 prefix has all bits of
## the IPv6 address set to zero that are not part of the ## the IPv6 address set to zero that are not part of the
## IPv6 prefix. Furthermore, the IPv6 address must match the ## IPv6 prefix. Furthermore, IPv6 address is represented
## pattern '((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})' ## in the compressed format described in RFC 4291 section
## with leading zeros suppressed as described in RFC 4291 ## 2.2 item 2 with the following additional rules: The ::
## section 2.2 item 1. ## substitution must be applied to the longest sequence of
## all-zero 16-bit chunks in an IPv6 address. If there is
## a tie, the first sequence of all-zero 16-bit chunks is
## replaced by ::. Single all-zero 16-bit chunks are not
## compressed. The normalized format uses lower-case
## characters and leading zeros are not allowed.
## See: RFC 4291: IP Version 6 Addressing Architecture ## See: RFC 4291: IP Version 6 Addressing Architecture
ipv6-prefix = ipv6-prefix =
xsd:string { xsd:string {
pattern = pattern =
"((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})/\d+)|((([" "((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}((([0-"
~ "0-9a-fA-F]{1,4}:){6})(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[" ~ "9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|(((25[0-5]|2[0-4][0-9]"
~ "0-9]{1,3}))/\d+)|((([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(" ~ "|[01]?[0-9]?[0-9])\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9"
~ "::)(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*/\d+)|((([0-9a-f" ~ "])))(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-8])))"
~ "A-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)(([0-9a-fA-F]{1,4}:)*([0" pattern =
~ "-9a-fA-F]{1,4}))*(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]" "(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|((([^:]+:)*[^:]"
~ "{1,3}))/\d+)" ~ "+)?::(([^:]+:)*[^:]+)?)(/.+)"
} }
## The domain-name type represents a DNS domain name. The ## The domain-name type represents a DNS domain name. The
## name SHOULD be fully qualified whenever possible. ## name SHOULD be fully qualified whenever possible.
## ##
## Internet domain names are only loosely specified. Section
## 3.5 of RFC 1034 recommends a syntax (modified in section
## 2.1 of RFC 1123). The pattern above is intended to allow
## for current practise in domain name use, and some possible
## future expansion. It is designed to hold various types of
## domain names, including names used for A or AAAA records
## (host names) and other records, such as SRV records. Note
## that Internet host names have a stricter syntax (described
## in RFC 952) than the DNS recommendations in RFCs 1034 and
## 1123, and that systems that want to store host names in
## objects using the domain-name type are recommended to adhere
## to this stricter standard to ensure interoperability.
##
## The encoding of DNS names in the DNS protocol is limited
## to 255 characters. Since the encoding consists of labels
## prefixed by a length bytes and there is a trailing NULL
## byte, only 253 characters can appear in the textual dotted
## notation.
##
## The description clause of objects using the domain-name ## The description clause of objects using the domain-name
## type MUST describe how (and when) these names are ## type MUST describe how (and when) these names are
## resolved to IP addresses. ## resolved to IP addresses. Note that the resolution of a
## ## domain-name value may require to query multiple DNS records
## Note that the resolution of a domain-name value may ## (e.g., A for IPv4 and AAAA for IPv6). The order of the
## require to query multiple DNS records (e.g., A for IPv4 ## resolution process and which DNS record takes precedence
## and AAAA for IPv6). The order of the resolution process ## depends on the configuration of the resolver.
## and which DNS record takes precedence depends on the
## configuration of the resolver.
## ##
## The canonical format for domain-name values uses the US-ASCII ## The canonical format for domain-name values uses the
## encoding and case-insensitive characters are set to lowercase. ## US-ASCII encoding and case-insensitive characters are set
## to lowercase.
## See: RFC 952: DoD Internet Host Table Specification
## RFC 1034: Domain Names - Concepts and Facilities
## See: RFC 1034: Domain Names - Concepts and Facilities
## RFC 1123: Requirements for Internet Hosts -- Application ## RFC 1123: Requirements for Internet Hosts -- Application
## and Support ## and Support
## RFC 3490: Internationalizing Domain Names in Applications
## (IDNA)
domain-name = domain-name =
xsd:string { xsd:string {
pattern = pattern =
"([a-zA-Z0-9][a-zA-Z0-9\-]*[a-zA-Z0-9]\.)*[a-zA-Z0-9][" "((([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.)"
~ "a-zA-Z0-9\-]*[a-zA-Z0-9]" ~ "*([a-zA-Z0-9_]([a-zA-Z0-9\-_]){0,61})?[a-zA-Z0-9]\.?)|\."
minLength = "1"
maxLength = "253"
} }
## The host type represents either an IP address or a DNS ## The host type represents either an IP address or a DNS
## domain name. ## domain name.
host = ip-address | domain-name host = ip-address | domain-name
## The uri type represents a Uniform Resource Identifier ## The uri type represents a Uniform Resource Identifier
## (URI) as defined by STD 66. ## (URI) as defined by STD 66.
## ##
## Objects using the uri type must be in US-ASCII encoding, ## Objects using the uri type must be in US-ASCII encoding,
## and MUST be normalized as described by RFC 3986 Sections ## and MUST be normalized as described by RFC 3986 Sections
## 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary ## 6.2.1, 6.2.2.1, and 6.2.2.2. All unnecessary
## percent-encoding is removed, and all case-insensitive ## percent-encoding is removed, and all case-insensitive
skipping to change at page 61, line 33 skipping to change at page 66, line 47
## equivalent. ## equivalent.
## ##
## Objects using the uri type may restrict the schemes that ## Objects using the uri type may restrict the schemes that
## they permit. For example, 'data:' and 'urn:' schemes ## they permit. For example, 'data:' and 'urn:' schemes
## might not be appropriate. ## might not be appropriate.
## ##
## A zero-length URI is not a valid URI. This can be used to ## A zero-length URI is not a valid URI. This can be used to
## express 'URI absent' where required ## express 'URI absent' where required
## ##
## This type is in the value set and its semantics equivalent ## This type is in the value set and its semantics equivalent
## to the Uri textual convention of the SMIv2. ## to the Uri SMIv2 textual convention defined in RFC 5017.
## See: RFC 3986: Uniform Resource Identifier (URI): Generic Syntax ## See: RFC 3986: Uniform Resource Identifier (URI): Generic Syntax
## RFC 3305: Report from the Joint W3C/IETF URI Planning Interest ## RFC 3305: Report from the Joint W3C/IETF URI Planning Interest
## Group: Uniform Resource Identifiers (URIs), URLs, ## Group: Uniform Resource Identifiers (URIs), URLs,
## and Uniform Resource Names (URNs): Clarifications ## and Uniform Resource Names (URNs): Clarifications
## and Recommendations ## and Recommendations
## RFC 5017: MIB Textual Conventions for Uniform Resource ## RFC 5017: MIB Textual Conventions for Uniform Resource
## Identifiers (URIs) ## Identifiers (URIs)
uri = xsd:string uri = xsd:string
B.3. RelaxNG of IEEE Specific Derived Types
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
namespace dc = "http://purl.org/dc/terms"
namespace dsrl = "http://purl.oclc.org/dsdl/dsrl"
namespace ieee = "urn:ietf:params:xml:ns:yang:ieee-types"
namespace nm = "urn:ietf:params:xml:ns:netmod:dsdl-attrib:1"
namespace sch = "http://purl.oclc.org/dsdl/schematron"
dc:creator [
"IETF NETMOD (NETCONF Data Modeling Language) Working Group"
]
dc:description [
"This module contains a collection of generally useful derived\x{a}" ~
"YANG data types for IEEE 802 addresses and related things.\x{a}" ~
"\x{a}" ~
"Copyright (C) 2009 The IETF Trust and the persons identif"
~ "ied as\x{a}" ~
"the document authors. This version of this YANG module i"
~ "s part\x{a}" ~
"of RFC XXXX; see the RFC itself for full legal notices."
]
dc:issued [ "2009-03-09" ]
dc:source [ "YANG module 'ietf-ieee-types' (automatic translation)" ]
dc:contributor [
"WG Web: <http://tools.ietf.org/wg/netmod/>\x{a}" ~
"WG List: <mailto:netmod@ietf.org>\x{a}" ~
"\x{a}" ~
"WG Chair: David Partain\x{a}" ~
" <mailto:david.partain@ericsson.com>\x{a}" ~
"\x{a}" ~
"WG Chair: David Kessens\x{a}" ~
" <mailto:david.kessens@nsn.com>\x{a}" ~
"\x{a}" ~
"Editor: Juergen Schoenwaelder\x{a}" ~
" <mailto:j.schoenwaelder@jacobs-university.de>"
]
## The mac-address type represents an 802 MAC address represented
## in the `canonical' order defined by IEEE 802.1a, i.e., as if it
## were transmitted least significant bit first, even though 802.5
## (in contrast to other 802.x protocols) requires MAC addresses
## to be transmitted most significant bit first.
##
## This type is in the value set and its semantics equivalent to
## the MacAddress textual convention of the SMIv2.
## See: RFC 2579: Textual Conventions for SMIv2
mac-address =
xsd:string { pattern = "[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}" }
## The bridgeid type represents identifiers that uniquely
## identify a bridge. Its first four hexadecimal digits
## contain a priority value followed by a colon. The
## remaining characters contain the MAC address used to
## refer to a bridge in a unique fashion (typically, the
## numerically smallest MAC address of all ports on the
## bridge).
##
## This type is in the value set and its semantics equivalent
## to the BridgeId textual convention of the SMIv2. However,
## since the BridgeId textual convention does not prescribe
## a lexical representation, the appearance might be different.
## See: RFC 4188: Definitions of Managed Objects for Bridges
bridgeid = xsd:string { pattern = "[0-9a-fA-F]{4}(:[0-9a-fA-F]{2}){6}" }
## The vlanid type uniquely identifies a VLAN. This is the
## 12-bit VLAN-ID used in the VLAN Tag header. The range is
## defined by the referenced specification.
##
## This type is in the value set and its semantics equivalent to
## the VlanId textual convention of the SMIv2.
## See: IEEE Std 802.1Q 2003 Edition: Virtual Bridged Local
## Area Networks
## RFC 4363: Definitions of Managed Objects for Bridges with
## Traffic Classes, Multicast Filtering, and Virtual
## LAN Extensions
vlanid = xsd:unsignedShort { minInclusive = "1" maxInclusive = "4094" }
Author's Address Author's Address
Juergen Schoenwaelder (editor) Juergen Schoenwaelder (editor)
Jacobs University Jacobs University
Email: j.schoenwaelder@jacobs-university.de Email: j.schoenwaelder@jacobs-university.de
 End of changes. 94 change blocks. 
502 lines changed or deleted 625 lines changed or added

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