draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt		draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt
	Network Working Group B. Natale		Network Working Group B. Natale
	Internet-Draft MITRE		Internet-Draft MITRE
	Intended status: Standards Track October 29, 2008		Intended status: Standards Track March 27, 2009
	Expires: May 2, 2009		Expires: September 27, 2009
	Expressing SNMP SMI Datatypes in XML Schema Definition Language		Expressing SNMP SMI Datatypes in XML Schema Definition Language
	draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt		draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with the
	applicable patent or other IPR claims of which he or she is aware		provisions of BCP 78 and BCP 79.
	have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	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 May 2, 2009.		This Internet-Draft will expire on September 27, 2009.
			Copyright Notice
			Copyright (c) 2009 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents in effect on the date of
			publication of this document (http://trustee.ietf.org/license-info).
			Please review these documents carefully, as they describe your rights
			and restrictions with respect to this document.
	Abstract		Abstract
	This memo (when approved as a standards-track RFC) defines the IETF		This memo defines the IETF standard expression of Structure of
	standard expression of Structure of Management Information (SMI) base		Management Information (SMI) base datatypes in Extensible Markup
	datatypes in Extensible Markup Language (XML) Schema Definition (XSD)		Language (XML) Schema Definition (XSD) language. The primary
	language. The primary objective of this memo is to enable the		objective of this memo is to enable the production of XML documents
	production of XML documents that are as faithful to the SMI as		that are as faithful to the SMI as possible, using XSD as the
	possible, using XSD as the validation mechanism.		validation mechanism.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. XSD for SMI Base Datatypes . . . . . . . . . . . . . . . . . . 7		4. XSD for SMI Base Datatypes . . . . . . . . . . . . . . . . . . 7
	5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 10		5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.1. Numeric Datatypes . . . . . . . . . . . . . . . . . . . . 10		5.1. Numeric Datatypes . . . . . . . . . . . . . . . . . . . . 10
	5.2. OctetString . . . . . . . . . . . . . . . . . . . . . . . 10		5.2. OctetString . . . . . . . . . . . . . . . . . . . . . . . 10
	5.3. Opaque . . . . . . . . . . . . . . . . . . . . . . . . . . 11		5.3. Opaque . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.4. IpAddress . . . . . . . . . . . . . . . . . . . . . . . . 12		5.4. IpAddress . . . . . . . . . . . . . . . . . . . . . . . . 12
	5.5. ObjectIdentifier . . . . . . . . . . . . . . . . . . . . . 12		5.5. ObjectIdentifier . . . . . . . . . . . . . . . . . . . . . 12
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 14		6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	7.1. SMI Base Datatypes Namespace Registration . . . . . . . . 15		7.1. SMI Base Datatypes Namespace Registration . . . . . . . . 14
	7.2. SMI Base Datatypes Schema Registration . . . . . . . . . . 15		7.2. SMI Base Datatypes Schema Registration . . . . . . . . . . 14
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 17		9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
	9.2. Informational References . . . . . . . . . . . . . . . . . 17		9.2. Informational References . . . . . . . . . . . . . . . . . 16
	Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 18		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 19
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
	Intellectual Property and Copyright Statements . . . . . . . . . . 21
	1. Introduction		1. Introduction
	Numerous uses exist -- both within and outside the traditional IETF		Numerous uses exist -- both within and outside the traditional IETF
	network management community -- for the expression of management		network management community -- for the expression of management
	information described in and accessible via SMI Management		information described in and accessible via SMI Management
	Information Base (MIB) modules as XML documents [ref.XML]. For		Information Base (MIB) modules as XML documents [XML]. For example,
	example, XML-based management applications which want to incorporate		XML-based management applications which want to incorporate MIB
	MIB modules as data models and/or to access MIB module		modules as data models and/or to access MIB module instrumentation
	instrumentation via gateways to SNMP agents will benefit from an IETF		via gateways to SNMP agents will benefit from an IETF standard
	standard mapping of SMI datatypes and structures to XML documents via		mapping of SMI datatypes to XML documents via XSD.
	XSD.
	MIB data models are described using SMIv2 [RFC2578] and, for legacy		MIB data models are described using SMIv2 [RFC2578] and, for legacy
	MIBs, SMIv1 [RFC1155]. MIB data is conveyed in variable bindings		MIBs, SMIv1 [RFC1155]. MIB data is conveyed in variable bindings
	("varbinds") within protocol data units (PDUs) within SNMP messages		("varbinds") within protocol data units (PDUs) within SNMP messages
	using the base/primitive datatypes defined in the SMI.		using the base/primitive datatypes defined in the SMI.
	The SMI allows for creation of derivative datatypes, termed "textual		The SMI allows for creation of derivative datatypes, termed "textual
	conventions" ("TCs"), each of which has a unique name, a syntax which		conventions" ("TCs"), each of which has a unique name, a syntax which
	is or refines a primitive SMI datatype, and relatively precise		is or refines a primitive SMI datatype, and relatively precise
	application-level semantics. TCs are used principally to facilitate		application-level semantics. TCs are used principally to facilitate
	correct application-level handling of MIB data and for the		correct application-level handling of MIB data and for the
	convenience of humans reading MIB modules and appropriately rendered		convenience of humans reading MIB modules and appropriately rendered
	MIB data output. Values in varbinds corresponding to MIB objects		MIB data output. Values in varbinds corresponding to MIB objects
	with TC syntaxes are always encoded as the primitive SMI datatype		with TC syntaxes are always encoded as the primitive SMI datatype
	underlying the TC syntax. Thus, the XSD mappings defined in this		underlying the TC syntax. Thus, the XSD mappings defined in this
	memo will support MIB objects with TC syntax as well as those with		memo will support MIB objects with TC syntax as well as those with
	base SMI syntax.		base SMI syntax.
	Various independent schemes have been devised for expressing the SMI		Various independent schemes have been devised for expressing the SMI
	datatypes and TCs in XSD [ref.XMLSchema]. These schemes have		datatypes in XSD [XMLSchema]. These schemes have exhibited a degree
	exhibited a degree of commonality (especially concerning the numeric		of commonality (especially concerning the numeric SMI datatypes), but
	SMI datatypes), but also sufficient differences (especially		also sufficient differences (especially concerning the non-numeric
	concerning the non-numeric SMI datatypes) to preclude general		SMI datatypes) to preclude uniformity and general interoperability.
	interoperability.
	The primary purpose of this memo is to define a standard expression		The primary purpose of this memo is to define a standard expression
	of SMI base datatypes in XSD to ensure uniformity and general		of SMI base datatypes in XSD to ensure fidelity, consistency, and
	interoperability in this respect. Internet operators, management		general interoperability in this respect. Internet operators,
	tool developers, and users will benefit from the wider selection of		management tool developers, and users will benefit from the wider
	management tools and the greater degree of unified management -- with		selection of management tools and the greater degree of unified
	attendant improvements in timeliness and accuracy of management		management -- with attendant improvements in timeliness and accuracy
	information -- which such a standard will facilitate.		of management information -- which such a standard facilitates.
	This memo is the first in a set of three related and (logically)
	ordered specifications:
	1. SMI Base Datatypes [RFC2578] in XSD
	2. SMI MIB Structure [RFC2578] in XSD		On its own, this memo specifies the IETF standard way to render SMI
			data values carried in SNMP messages as XML in a faithful,
			consistent, and interoperable way.
	3. SNMP Textual Conventions [RFC2579] in XSD		Certain XML-based applications will find this specification
			sufficient for their purposes. Other XML applications may need to
			make more complete reuse of existing MIB modules, requiring standard
			XSDs for TCs [RFC2579] and MIB structure [RFC2578]. Documents
			supporting those requirements are planned, but have not been produced
			at the time of this writing.
	As a set, these documents define the XSD equivalent of SMIv2 to		The objective of this memo, and of any future related specifications
	encourage XML-based protocols to carry, and XML-based applications to		that might be produced, is to define the XSD equivalent
	use, the information modeled in SMIv2-compliant MIB modules.		[XSDDatatypes] of SMIv2 (STD58) to encourage XML-based protocols to
			carry, and XML-based applications to use, the information modeled in
			SMIv2-compliant MIB modules.
	This work defines XSD equivalents of the datatypes and data		Having such a standard mapping of SMIv2 to XML via XSD validation
	structures [RFC2578] and the textual conventions [RFC2579] defined in		will enable and promote efficient reuse of existing (including
	the SMIv2 standard (STD58) to encourage efficient reuse of existing		future) MIB modules and instrumentation by XML-based management
	(including future) MIB modules and instrumentation by XML-based		protocols and applications.
	management protocols and applications.
	The goal of fidelity to the SMIv2 standard (STD58), as specified in		The goal of fidelity to the SMIv2 standard (STD58), as specified in
	the "Requirements" section below, is crucial to this effort to		the "Requirements" section below, is crucial to this effort to
	leverage the established "rough consensus" for the precise data		leverage the established "rough consensus" for the precise data
	modeling used in MIB modules, and to leverage existing "running code"		modeling used in MIB modules, and to leverage existing "running code"
	for implemented SMIv2 data models. This effort does not include		for implemented SMIv2 data models. This effort does not include
	redesign of SMIv2 datatypes or data structures or textual conventions		redesign of SMIv2 datatypes or data structures or textual conventions
	to overcome known limitations -- that work can be pursued in other		to overcome known limitations -- that work can be pursued in other
	efforts.		efforts.
	skipping to change at page 7, line 7		skipping to change at page 7, line 7
	most direct XSD datatype, with the most parsimonious		most direct XSD datatype, with the most parsimonious
	restrictions, which matches the foregoing requirements.		restrictions, which matches the foregoing requirements.
	R7. The XML output produced as a result of meeting the foregoing		R7. The XML output produced as a result of meeting the foregoing
	requirements SHOULD be the most direct (i.e., avoiding		requirements SHOULD be the most direct (i.e., avoiding
	superfluous "decoration") from the perspective of readability by		superfluous "decoration") from the perspective of readability by
	humans.		humans.
	4. XSD for SMI Base Datatypes		4. XSD for SMI Base Datatypes
	This document concerns only the SMI base datatypes -- i.e., the		This document provides XSD datatype mappings for the SMIv2 base
	eleven "ObjectSyntax" datatypes defined in RFC2578. These datatypes		datatypes only -- i.e., the eleven "ObjectSyntax" datatypes defined
	-- via tag values defined in the SMI to identify them in varbinds --		in RFC 2578. These datatypes -- via tag values defined in the SMIv2
	constrain values carried "on-the-wire" in SNMP PDUs between SNMP		to identify them in varbinds -- constrain values carried "on-the-
	management applications and SNMP agents:		wire" in SNMP PDUs between SNMP management applications and SNMP
			agents:
	o INTEGER, Integer32		o INTEGER, Integer32
	o Unsigned32, Gauge32		o Unsigned32, Gauge32
	o Counter32		o Counter32
	o TimeTicks		o TimeTicks
	o Counter64		o Counter64
	o OctetString		o OCTET STRING
	o Opague		o Opaque
	o IpAddress		o IpAddress
	o ObjectIdentifier		o OBJECT IDENTIFIER
	The "BITS" pseudo-type (also referred to as a "construct" in RFC2578)		The "BITS" pseudo-type (also referred to as a "construct" in RFC
	is treated as a Textual Convention for the purpose of this document		2578) is treated as a Textual Convention, not a base datatype, for
	and, therefore, will be defined in the "SNMP Textual Conventions in		the purpose of this document.
	XSD" document.
	BEGIN		BEGIN
	<?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"
	xmlns="urn:ietf:params:xml:ns:opsawg:smi:base:1.0"		xmlns="urn:ietf:params:xml:ns:opsawg:smi:base:1.0"
	targetNamespace="urn:ietf:params:xml:ns:opsawg:smi:base:1.0"		targetNamespace="urn:ietf:params:xml:ns:opsawg:smi:base:1.0"
	elementFormDefault="qualified"		elementFormDefault="qualified"
	attributeFormDefault="unqualified"		attributeFormDefault="unqualified"
	xml:lang="en">		xml:lang="en">
	<xs:annotation>		<xs:annotation>
	<xs:documentation>		<xs:documentation>
	Mapping of SMIv2 base datatypes from RFC 2578.		Mapping of SMIv2 base datatypes from RFC 2578
			Contact: Bob Natale
			Organization: MITRE
			Address: 7515 Colshire Drive
			McLean VA 22102
			USA
			Telephone: +1 703-983-2505
			E-Mail: rnatale@mitre.org
			Last Updated: 200903090000Z
	</xs:documentation>		</xs:documentation>
	</xs:annotation>		</xs:annotation>
	<xs:simpleType name="INTEGER">		<xs:simpleType name="INTEGER">
	<xs:restriction base="xs:int"/>		<xs:restriction base="xs:int"/>
	</xs:simpleType>		</xs:simpleType>
	<xs:simpleType name="Integer32">		<xs:simpleType name="Integer32">
	<xs:restriction base="xs:int"/>		<xs:restriction base="xs:int"/>
	</xs:simpleType>		</xs:simpleType>
	<xs:simpleType name="Unsigned32">		<xs:simpleType name="Unsigned32">
	<xs:restriction base="xs:unsignedInt"/>		<xs:restriction base="xs:unsignedInt"/>
	skipping to change at page 8, line 50		skipping to change at page 9, line 26
	</xs:simpleType>		</xs:simpleType>
	<xs:simpleType name="IpAddress">		<xs:simpleType name="IpAddress">
	<xs:restriction base="xs:string">		<xs:restriction base="xs:string">
	<xs:pattern value=		<xs:pattern value=
	"((0|(1[0-9]{0,2})|		"((0|(1[0-9]{0,2})|
	(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))|		(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))|
	([3-9][0-9]?))\.){3}		([3-9][0-9]?))\.){3}
	(0|(1[0-9]{0,2})|		(0|(1[0-9]{0,2})|
	(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))|		(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))|
	([3-9][0-9]?))"		([3-9][0-9]?))"/>
	</xs:restriction>		</xs:restriction>
	</xs:simpleType>		</xs:simpleType>
	<xs:simpleType name="ObjectIdentifier">		<xs:simpleType name="ObjectIdentifier">
	<xs:restriction base="xs:string">		<xs:restriction base="xs:string">
	<xs:pattern value=		<xs:pattern value=
	"(([0-1](\.[1-3]?[0-9]))|		"(([0-1](\.[1-3]?[0-9]))|
	(2\.(0|([1-9]\d*))))		(2\.(0|([1-9]\d*))))
	(\.(0|([1-9]\d*))){0,126}"/>		(\.(0|([1-9]\d*))){0,126}"/>
	</xs:restriction>		</xs:restriction>
	skipping to change at page 11, line 7		skipping to change at page 11, line 7
	5.2. OctetString		5.2. OctetString
	This XSD datatype corresponds to the SMI "OCTET STRING" datatype.		This XSD datatype corresponds to the SMI "OCTET STRING" datatype.
	Several independent schemes for mapping SMI datatypes to XSD have		Several independent schemes for mapping SMI datatypes to XSD have
	used the XSD "string" type to represent "OCTET STRING", but this		used the XSD "string" type to represent "OCTET STRING", but this
	mapping does not conform to the requirements specified in this		mapping does not conform to the requirements specified in this
	document. Most notably, "string" cannot faithfully represent all		document. Most notably, "string" cannot faithfully represent all
	valid values (0 thru 255) that each octet in an "OCTET STRING" can		valid values (0 thru 255) that each octet in an "OCTET STRING" can
	have -- or at least cannot do so in a way that provides for ready		have -- or at least cannot do so in a way that provides for easy
	human readability of the resulting XML output.		human readability of the resulting XML output.
	Consequently, the XSD datatype "hexBinary" is specified as the		Consequently, the XSD datatype "hexBinary" is specified as the
	standard mapping of the SMI "OCTET STRING" datatype. In hexBinary,		standard mapping of the SMI "OCTET STRING" datatype. In hexBinary,
	each octet is encoded as two hexadecimal digits; the canonical		each octet is encoded as two hexadecimal digits; the canonical
	representation limits the set of allowed hexadecimal digits to 0-9		representation limits the set of allowed hexadecimal digits to 0-9
	and uppercase A-F.		and uppercase A-F.
	The hexBinary representation of OCTET STRING complies with the		The hexBinary representation of "OCTET STRING" complies with the
	relevant requirements:		relevant requirements:
	o It covers all valid values for the corresponding SMI datatype.		o It covers all valid values for the corresponding SMI datatype.
	o It complies with the standard encoding rules associated with the		o It complies with the standard encoding rules associated with the
	corresponding SMI datatype.		corresponding SMI datatype.
	o With the "maxLength" restriction to 65535 octets, the XSD datatype		o With the "maxLength" restriction to 65535 octets, the XSD datatype
	specification matches the restrictions associated with the		specification matches the restrictions associated with the
	corresponding SMI datatype.		corresponding SMI datatype.
	skipping to change at page 11, line 43		skipping to change at page 11, line 43
	XSD datatype is not optimal with respect to readability by humans;		XSD datatype is not optimal with respect to readability by humans;
	however, that is a consequence of the SMI datatype itself. Where		however, that is a consequence of the SMI datatype itself. Where
	human readability is more of a concern, it is likely that the		human readability is more of a concern, it is likely that the
	actual MIB objects in question will be represented by textual		actual MIB objects in question will be represented by textual
	conventions which limit the set of values that will be included in		conventions which limit the set of values that will be included in
	the OctetStrings and will, thus, bypass the hexBinary typing.		the OctetStrings and will, thus, bypass the hexBinary typing.
	5.3. Opaque		5.3. Opaque
	The "hexBinary" XSD datatype is specified as the representation of		The "hexBinary" XSD datatype is specified as the representation of
	the SMI "Opague" datatype generally for the same reasons as		the SMI "Opaque" datatype generally for the same reasons as
	"hexBinary" is specified for the "OctetString" datatype:		"hexBinary" is specified for the "OctetString" datatype:
	o It covers all valid values for the corresponding SMI datatype.		o It covers all valid values for the corresponding SMI datatype.
	o It complies with the standard encoding rules associated with the		o It complies with the standard encoding rules associated with the
	corresponding SMI datatype.		corresponding SMI datatype.
	o There are no restriction issues associated with using "hexBinary"		o There are no restriction issues associated with using "hexBinary"
	for "Opague".		for "Opaque".
	o It is the most direct XSD datatype which exhibits the foregoing		o It is the most direct XSD datatype which exhibits the foregoing
	characteristics relative to the corresponding SMI datatype (which		characteristics relative to the corresponding SMI datatype (which
	must allow for any valid binary octet value).		must allow for any valid binary octet value).
	o The XML output produced from the canonical representation of this		o The XML output produced from the canonical representation of this
	XSD datatype is not optimal with respect to readability by humans;		XSD datatype is not optimal with respect to readability by humans;
	however, that is a consequence of the SMI datatype itself.		however, that is a consequence of the SMI datatype itself.
	Unmediated "Opague" data is intended for consumption by		Unmediated "Opaque" data is intended for consumption by
	applications, not humans.		applications, not humans.
	5.4. IpAddress		5.4. IpAddress
	The XSD "string" datatype is the natural choice to represent an		The XSD "string" datatype is the natural choice to represent an
	IpAddress as XML output. The "pattern" restriction applied in this		IpAddress as XML output. The "pattern" restriction applied in this
	case results in a "dotted-decimal string of four values between "0"		case results in a dotted-decimal string of four values between "0"
	and "255" separated by a period (".") character. This pattern also		and "255" separated by a period (".") character. This pattern also
	precludes leading zeros.		precludes leading zeros.
	5.5. ObjectIdentifier		5.5. ObjectIdentifier
	This XSD datatype corresponds to the SMI "OBJECT IDENTIFIER"		This XSD datatype corresponds to the SMI "OBJECT IDENTIFIER"
	datatype.		datatype.
	The XSD "string" datatype is also the natural choice to represent an		The XSD "string" datatype is also the natural choice to represent an
	ObjectIdentifier as XML output, for the same reasons as for the		ObjectIdentifier as XML output, for the same reasons as for the
	IpAddress choice. The "pattern" restriction applied in this case		IpAddress choice. The "pattern" restriction applied in this case
	results in a dotted-decimal string of up to 128 elements (referred to		results in a dotted-decimal string of up to 128 elements (referred to
	as "sub-ids"), each holding an "Unsigned32" integer value.		as "sub-ids"), each holding an "Unsigned32" integer value.
	Note that, while not mentioned in Sec. 7.1.3 of RFC 2578, due to the		Note that, while not mentioned in Sec. 7.1.3 of RFC 2578, due to the
	use of Abstract Syntax Notation One (ASN.1) Basic Encoding Rules		use of Abstract Syntax Notation One (ASN.1) Basic Encoding Rules
	(BER) the first two components of an "OBJECT IDENTIFIER" have limited		(BER) the first two components of an "OBJECT IDENTIFIER" have limited
	value ranges and are encoded into a single sub-id value [Steedman].		value ranges and are encoded into a single sub-id value [Steedman].
	The ASN.1/BER standards specify that the numerical value of the first		The ASN.1/BER standards specify that the numerical value of the first
	sub-identifier is derived from the values of the first two object		sub-identifier is derived from the values of the first two "OBJECT
	identifier components in the object identifier value being encoded,		IDENTIFIER" components in the value being encoded, using the formula:
	using the formula: (X*40) + Y, where X is the value of the first		(X*40) + Y, where X is the value of the first component and Y is the
	object identifier component and Y is the value of the second object		value of the second component. This packing of the first two
	identifier component. This packing of the first two object		components recognizes that only three values are allocated from the
	identifier components recognizes that only three values are allocated		root node, and at most 39 subsequent values from nodes reached by X =
	from the root node, and at most 39 subsequent values from nodes		0 and X = 1. The minimum length of an "OBJECT IDENTIFIER" is two
	reached by X = 0 and X = 1. The minimum length of an "OBJECT		sub-ids (with a zero-valued "OBJECT IDENTIFIER" represented as
	IDENTIFIER" is two sub-ids (with a zero-valued "OBJECT IDENTIFIER"		"0.0"). No explicit "minLength" restriction (which would be "3" to
	represented as "0.0"). No explicit "minLength" restriction (which		allow for the minimum of two sub-ids and a single separating dot) is
	would be "3" to allow for the minimum of two sub-ids and a single		required, since the pattern itself enforces this restriction.
	separating dot) is required, since the pattern itself enforces this
	restriction.
	6. Security Considerations		6. Security Considerations
	Security considerations for any given SMI MIB module are likely to be		Security considerations for any given SMI MIB module are likely to be
	relevant to any XSD/XML mapping of that MIB module; however, the		relevant to any XSD/XML mapping of that MIB module; however, the
	mapping defined in this document does not itself introduce any new		mapping defined in this document does not itself introduce any new
	security considerations.		security considerations.
	If and when proxies or gateways are developed to convey SNMP		If and when proxies or gateways are developed to convey SNMP
	management information from SNMP agents to XML-based management		management information from SNMP agents to XML-based management
	applications via XSD/XML mapping of MIB modules based on this		applications via XSD/XML mapping of MIB modules based on this
	specification and its planned siblings, special care will need to be		specification and its planned siblings, special care will need to be
	taken to ensure that all applicable SNMP security mechanisms are		taken to ensure that all applicable SNMP security mechanisms are
	supported in an appropriate manner yet to be determined.		supported in an appropriate manner yet to be determined.
	7. IANA Considerations		7. IANA Considerations
	In accordance with RFC 3688, we will register namespaces and schemas		In accordance with RFC 3688 [RFC3688], we request the following
	for all three documents in this set with the IANA XML Registry.		namespace and schema registrations associated with this document in
	These entries -- corresponding to this base datatypes document and		the IANA XML Registry:
	the future textual conventions and MIB structure documents -- will be
	as follows:
	o urn:ietf:params:xml:ns:opsawg:smi:base:[version_id]		o urn:ietf:params:xml:ns:opsawg:smi:base:[version_id]
	o urn:ietf:params:xml:schema:opsawg:smi:base:[version_id]		o urn:ietf:params:xml:schema:opsawg:smi:base:[version_id]
	o urn:ietf:params:xml:ns:opsawg:smi:tc:[version_id]
	o urn:ietf:params:xml:schema:opsawg:smi:tc:[version_id]
	o urn:ietf:params:xml:ns:opsawg:smi:structure:[version_id]
	o urn:ietf:params:xml:schema:opsawg:smi:structure:[version_id]
	The following sub-sections refer to the present document only.
	7.1. SMI Base Datatypes Namespace Registration		7.1. SMI Base Datatypes Namespace Registration
	This document registers a URI for the SMI Base Datatypes XML		This document registers a URI for the SMI Base Datatypes XML
	namespace in the IETF XML registry. Following the format in RFC		namespace in the IETF XML registry. Following the format in RFC
	3688, IANA has made the following registration:		3688, IANA has made the following registration:
	URI: urn:ietf:params:xml:ns:opsawg:smi:base:1.0		URI: urn:ietf:params:xml:ns:opsawg:smi:base:1.0
	Registration Contact: The IESG.		Registration Contact: The IESG.
	skipping to change at page 16, line 15		skipping to change at page 15, line 15
	8. Acknowledgements		8. Acknowledgements
	Dave Harrington provided strategic and technical leadership to the		Dave Harrington provided strategic and technical leadership to the
	team which developed this particular specification. Yan Li did much		team which developed this particular specification. Yan Li did much
	of the research into existing approaches that was used as a baseline		of the research into existing approaches that was used as a baseline
	for the recommendations in this particular specification.		for the recommendations in this particular specification.
	This document owes much to draft-romascanu-netconf-datatypes-xx and		This document owes much to draft-romascanu-netconf-datatypes-xx and
	to many other sources (including libsmi and group discussions on the		to many other sources (including libsmi and group discussions on the
	NETCONF mailing lists) developed by those who have researched and		NETCONF mailing lists) developed by those who have researched and
	published candidate mappings of SMI datatypes and textual conventions		published candidate mappings of SMI datatypes to XSD.
	to XSD.
	Individuals who participated in various discussions of this topic at		Individuals who participated in various discussions of this topic at
	IETF meetings and on IETF mailing lists include: Ray Atarashi,		IETF meetings and on IETF mailing lists include: Ray Atarashi,
	Yoshifumi Atarashi, Andy Bierman, Sharon Chisholm, Avri Doria, Mark		Yoshifumi Atarashi, Andy Bierman, Sharon Chisholm, Avri Doria, Mark
	Ellison, Rob Ennes, David Harrington, Alfred HInes, Eliot Lear, Chris		Ellison, Rob Ennes, Mehmet Ersue, David Harrington, Alfred Hines,
	Lonvick, Faye Ly, Randy Presuhn, Juergen Schoenwaelder, Andre		Eliot Lear, Chris Lonvick, Faye Ly, Randy Presuhn, Juergen
	Westerinen, and Bert Wijnen.		Schoenwaelder, Andre Westerinen, and Bert Wijnen.
	(Others who have been inadvertently omitted from this list should
	notify the editor.)
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC1155] Rose, M. and K. McCloghrie, "Structure and identification		[RFC1155] Rose, M. and K. McCloghrie, "Structure and identification
	of management information for TCP/IP-based internets",		of management information for TCP/IP-based internets",
	STD 16, RFC 1155, May 1990.		STD 16, RFC 1155, May 1990.
	[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.
	[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.		[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
	Schoenwaelder, Ed., "Structure of Management Information		Schoenwaelder, Ed., "Structure of Management Information
	Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.		Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
	[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
	"Textual Conventions for SMIv2", STD 58, RFC 2579,
	April 1999.
	9.2. Informational References
	[RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen,		[RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen,
	"Coexistence between Version 1, Version 2, and Version 3		"Coexistence between Version 1, Version 2, and Version 3
	of the Internet-standard Network Management Framework",		of the Internet-standard Network Management Framework",
	BCP 74, RFC 3584, August 2003.		BCP 74, RFC 3584, August 2003.
			9.2. Informational References
			[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
			"Textual Conventions for SMIv2", STD 58, RFC 2579,
			April 1999.
	[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.
	[Steedman]		[Steedman]
	Steedman, D., "ASN.1: The Tutorial and Reference".		Steedman, D., "ASN.1: The Tutorial and Reference".
	[ref.XML] World Wide Web Consortium, "Extensible Markup Language		[XML] World Wide Web Consortium, "Extensible Markup Language
	(XML) 1.0", W3C XML, February 1998,		(XML) 1.0", W3C XML, February 1998,
	<http://www.w3.org/TR/1998/REC-xml-19980210>.		<http://www.w3.org/TR/1998/REC-xml-19980210>.
	[ref.XMLSchema]		[XMLSchema]
	World Wide Web Consortium, "XML Schema Part 1: Structures		World Wide Web Consortium, "XML Schema Part 1: Structures
	Second Edition", W3C XML Schema, October 2004,		Second Edition", W3C XML Schema, October 2004,
	<http://www.w3.org/TR/xmlschema-1/>.		<http://www.w3.org/TR/xmlschema-1/>.
	[ref.XSDDatatype]		[XSDDatatypes]
	World Wide Web Consortium, "XML Schema Part 2: Datatypes		World Wide Web Consortium, "XML Schema Part 2: Datatypes
	Second Edition", W3C XML Schema, October 2004,		Second Edition", W3C XML Schema, October 2004,
	<http://www.w3.org/TR/xmlschema-2/>.		<http://www.w3.org/TR/xmlschema-2/>.
	Appendix A. Open Issues
	o Confirm IANA XML registration values and process.
	Appendix B. Change Log
	o -01 version:
	* Incorporated mailing list comments on -00 version from Juergen
	Schoenwaelder
	* Incorporated mailing list comments on -00 version from David
	Harrington
	o -02 version:
	* Fixed ObjectIdentifier pattern per correction from Juergen
	Schoenwaelder, and text in sec. 5.5 adjusted accordingly.
	* Moved non-normative references to Informational section per
	David Harrington
	* Tightened wording in to "XSD for SMI Datatypes" section per
	Mark Ellison
	* Added a note about Gauge32 and Counter32 application semantics
	to the "Rationale" section per Mark Ellison
	* Security section wording tightened per David Harrington
	* The IANA Considerations section completed--will need
	adjustment.
	* Acknowledgments entries expanded and alphabetized
	o -03 version:
	* Corrected "ten" to "eleven" in opening sentence of "XSD for SMI
	Datatypes" section.
	* Removed conditional wording that previously prefaced the XSD
	itself.
	o -04 version:
	* Relatively minor text fix-ups in various places, mainly in
	response to comments on the -03 version from Mark Ellison,
	Alfred HInes, Juergen Schoenwaelder, and David Harrington.
	Author's Address		Author's Address
	Bob Natale		Bob Natale
	MITRE		MITRE
	7515 Colshire Dr		7515 Colshire Dr
	MS H405		MS H405
	McLean, VA 22102		McLean, VA 22102
	USA		USA
	Phone: +1 703-983-2505		Phone: +1 703-983-2505
	Email: rnatale@mitre.org		Email: rnatale@mitre.org
	Full Copyright Statement
	Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property
	The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.
End of changes. 39 change blocks.
	172 lines changed or deleted		122 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/