draft-ietf-opsawg-smi-datatypes-in-xsd-03.txt		draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt
	Network Working Group B. Natale, Ed.		Network Working Group B. Natale
	Internet-Draft MITRE		Internet-Draft MITRE
	Intended status: Standards Track Y. Li, Ed.		Intended status: Standards Track October 29, 2008
	Expires: January 29, 2009 Huawei Technologies		Expires: May 2, 2009
	July 28, 2008
	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-03.txt		draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		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.		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
	skipping to change at page 1, line 35		skipping to change at page 1, line 34
	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 January 29, 2009.		This Internet-Draft will expire on May 2, 2009.
	Abstract		Abstract
	This memo (when approved as a standards-track RFC) defines the IETF		This memo (when approved as a standards-track RFC) defines the IETF
	standard expression of Structure of Management Information (SMI) base		standard expression of Structure of Management Information (SMI) base
	datatypes in Extensible Markup Language (XML) Schema Definition (XSD)		datatypes in Extensible Markup Language (XML) Schema Definition (XSD)
	language. The primary objective of this memo is to enable the		language. The primary objective of this memo is to enable the
	production of XML documents that are as faithful to the SMI as		production of XML documents that are as faithful to the SMI as
	possible, using XSD as the validation mechanism.		possible, using XSD as the validation mechanism.
	skipping to change at page 2, line 36		skipping to change at page 2, line 36
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 14		6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	7.1. SMI Base Datatypes Namespace Registration . . . . . . . . 15		7.1. SMI Base Datatypes Namespace Registration . . . . . . . . 15
	7.2. SMI Base Datatypes Schema Registration . . . . . . . . . . 15		7.2. SMI Base Datatypes Schema Registration . . . . . . . . . . 15
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 17		9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
	9.2. Informational References . . . . . . . . . . . . . . . . . 17		9.2. Informational References . . . . . . . . . . . . . . . . . 17
	Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 18		Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 18
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 19		Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
	Intellectual Property and Copyright Statements . . . . . . . . . . 21		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 [ref.XML]. For
	example, XML-based management applications which want to incorporate		example, XML-based management applications which want to incorporate
	MIB modules as data models and/or to access MIB module		MIB modules as data models and/or to access MIB module
	instrumentation via gateways to SNMP agents will benefit from an IETF		instrumentation via gateways to SNMP agents will benefit from an IETF
	standard mapping of SMI datatypes and structures to XML documents via		standard mapping of SMI datatypes and structures 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 via SNMP using the base		MIBs, SMIv1 [RFC1155]. MIB data is conveyed in variable bindings
	datatypes defined in the SMI. The SMI allows for creation of		("varbinds") within protocol data units (PDUs) within SNMP messages
	derivative datatypes, termed "textual conventions" ("TCs"), each of		using the base/primitive datatypes defined in the SMI.
	which has a unique name, a syntax based on a core SMI datatype, and
	relatively precise application-level semantics. TCs are used		The SMI allows for creation of derivative datatypes, termed "textual
	principally to facilitate correct application-level handling of MIB		conventions" ("TCs"), each of which has a unique name, a syntax which
	data and for the convenience of humans reading MIB modules and		is or refines a primitive SMI datatype, and relatively precise
	appropriately rendered MIB data output.		application-level semantics. TCs are used principally to facilitate
			correct application-level handling of MIB data and for the
			convenience of humans reading MIB modules and appropriately rendered
			MIB data output. Values in varbinds corresponding to MIB objects
			with TC syntaxes are always encoded as the primitive SMI datatype
			underlying the TC syntax. Thus, the XSD mappings defined in this
			memo will support MIB objects with TC syntax as well as those with
			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 and TCs in XSD [ref.XMLSchema]. These schemes have
	exhibited a degree of commonality (especially concerning the numeric		exhibited a degree of commonality (especially concerning the numeric
	SMI datatypes), but also sufficient differences (especially		SMI datatypes), but also sufficient differences (especially
	concerning the non-numeric SMI datatypes) to preclude general		concerning the non-numeric SMI datatypes) to preclude 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 uniformity and general
	skipping to change at page 6, line 9		skipping to change at page 6, line 9
	2. Conventions		2. Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	3. Requirements		3. Requirements
	The following set of requirements is intended to produce XML		The following set of requirements is intended to produce XML
	documents which can be validated via the XSD defined in this		documents which can be validated via the XSD defined in this
	specification to faithfully represnt values carried "on-the-wire" in		specification to faithfully represent values carried "on-the-wire" in
	SNMP PDUs as defined by the SMI:		SNMP PDUs as defined by the SMI:
	R1. All SMI base datatypes MUST have a corresponding XSD datatype.		R1. All SMI base datatypes MUST have a corresponding XSD datatype.
	R2. SMIv2 is the normative SMI for this document -- SMIv1 modules,		R2. SMIv2 is the normative SMI for this document -- SMIv1 modules,
	if encountered, MUST be converted (at least logically) in		if encountered, MUST be converted (at least logically) in
	accordance with Section 2.1, inclusive, of the "Coexistence" RFC		accordance with Section 2.1, inclusive, of the "Coexistence" RFC
	[RFC3584].		[RFC3584].
	R3. The XSD datatype specified for a given SMI datatype MUST be able		R3. The XSD datatype specified for a given SMI datatype MUST be able
	skipping to change at page 8, line 45		skipping to change at page 8, line 45
	</xs:restriction>		</xs:restriction>
	</xs:simpleType>		</xs:simpleType>
	<xs:simpleType name="Opaque">		<xs:simpleType name="Opaque">
	<xs:restriction base="xs:hexBinary"/>		<xs:restriction base="xs:hexBinary"/>
	</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}|2([0-4][0-9]?|5[0-5]?|[6-9])?|[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])?|[3-9][0-9]?)"/>		(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))|
			([3-9][0-9]?))\.){3}
			(0|(1[0-9]{0,2})|
			(2(([0-4][0-9]?)|(5[0-5]?)|([6-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]))|(2.(0|([1-9]\d*)))		"(([0-1](\.[1-3]?[0-9]))|
			(2\.(0|([1-9]\d*))))
	(\.(0|([1-9]\d*))){0,126}"/>		(\.(0|([1-9]\d*))){0,126}"/>
	</xs:restriction>		</xs:restriction>
	</xs:simpleType>		</xs:simpleType>
	</xs:schema>		</xs:schema>
	END		END
	5. Rationale		5. Rationale
	The XSD datatypes, including any specified restrictions, were chosen		The XSD datatypes, including any specified restrictions, were chosen
	skipping to change at page 10, line 28		skipping to change at page 10, line 28
	Counter64 -- comply with the relevant requirements		Counter64 -- comply with the relevant requirements
	o They cover all valid values for the corresponding SMI datatypes.		o They cover all valid values for the corresponding SMI datatypes.
	o They comply with the standard encoding rules associated with the		o They comply with the standard encoding rules associated with the
	corresponding SMI datatypes.		corresponding SMI datatypes.
	o They inherently match the range restrictions associated with the		o They inherently match the range restrictions associated with the
	corresponding SMI datatypes.		corresponding SMI datatypes.
	o They are the most direct XSD datatype which exhibit the foregoing		o They are the most direct XSD datatypes which exhibit the foregoing
	characteristics relative to the corresponding SMI datatypes (which		characteristics relative to the corresponding SMI datatypes (which
	is why no "restriction" statements -- other than the "base" XSD		is why no "restriction" statements -- other than the "base" XSD
	type -- are required in the XSD).		type -- are required in the XSD).
	o The XML output produced from the canonical representation of these		o The XML output produced from the canonical representation of these
	XSD datatypes is also the most direct from the perspective of		XSD datatypes is also the most direct from the perspective of
	readability by humans (i.e., no leading "+" sign and no leading		readability by humans (i.e., no leading "+" sign and no leading
	zeros).		zeros).
	Special note to application developers: Compliance with this schema		Special note to application developers: Compliance with this schema
	in an otherwise correct translation from raw ("on-the-wire"		in an otherwise correct translation from raw ("on-the-wire"
	representation) SNMP MIB data produces values that are faithful to		representation) SNMP MIB data produces values that are faithful to
	the original. However, the Gauge32 and Counter32 datatypes have		the original. However, the Gauge32, Counter32, Counter64, and
	special application semantics that must be considered when using		TimeTicks datatypes have special application semantics that must be
	their raw values for anything other than display, printing, storage,		considered when using their raw values for anything other than
	or transmission of the literal value. This is particularly important		display, printing, storage, or transmission of the literal value.
	for Counter32 values. RFC 2578 provides the necessary details.		RFC 2578 provides the necessary details.
	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
	skipping to change at page 12, line 35		skipping to change at page 12, line 35
	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"), holding "Unsigned32" integer values.		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
	subidentifier 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 object identifier value being encoded,
	using the formula: (X*40) + Y, where X is the value of the first		using the formula: (X*40) + Y, where X is the value of the first
	object identifier component and Y is the value of the second object		object identifier component and Y is the value of the second object
	identifier component. This packing of the first two object		identifier component. This packing of the first two object
	identifier components recognizes that only three values are allocated		identifier components recognizes that only three values are allocated
	from the root node, and at most 39 subsequent values from nodes		from the root node, and at most 39 subsequent values from nodes
	reached by X = 0 and X = 1. The minimum length of an "OBJECT		reached by X = 0 and X = 1. The minimum length of an "OBJECT
	IDENTIFIER" is two sub-ids (with a zero-valued "OBJECT IDENTIFIER"		IDENTIFIER" is two sub-ids (with a zero-valued "OBJECT IDENTIFIER"
	represented as "0.0"). No explicit "minLength" restriction (which		represented as "0.0"). No explicit "minLength" restriction (which
	would be "3" to allow for the minimum of two sub-ids and a single		would be "3" to allow for the minimum of two sub-ids and a single
	skipping to change at page 16, line 21		skipping to change at page 16, line 21
	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 and textual conventions
	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, Eliot Lear, Chris Lonvick, Faye		Ellison, Rob Ennes, David Harrington, Alfred HInes, Eliot Lear, Chris
	Ly, Randy Presuhn, Juergen Schoenwaelder, Andre Westerinen, and Bert		Lonvick, Faye Ly, Randy Presuhn, Juergen Schoenwaelder, Andre
	Wijnen. (Others who have been inadvertently omitted from this list		Westerinen, and Bert Wijnen.
	should notify the editors.)
			(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
	skipping to change at page 19, line 41		skipping to change at page 19, line 41
	* The IANA Considerations section completed--will need		* The IANA Considerations section completed--will need
	adjustment.		adjustment.
	* Acknowledgments entries expanded and alphabetized		* Acknowledgments entries expanded and alphabetized
	o -03 version:		o -03 version:
	* Corrected "ten" to "eleven" in opening sentence of "XSD for SMI		* Corrected "ten" to "eleven" in opening sentence of "XSD for SMI
	Datatypes" section.		Datatypes" section.
	* Temoved conditional wording that previously prefaced the XSD		* Removed conditional wording that previously prefaced the XSD
	itself.		itself.
	Authors' Addresses		o -04 version:
	Bob Natale (editor)		* 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
			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
	Yan Li (editor)
	Huawei Technologies
	No.3 Xinxi Road, Shangdi Information Industry Base
	Beijing, HaiDian District 100085
	P.R.China
	Phone: +86 10 8288 2008
	Email: liyan_77@huawei.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
End of changes. 18 change blocks.
	43 lines changed or deleted		53 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/