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/