draft-ietf-opsawg-smi-datatypes-in-xsd-00.txt		draft-ietf-opsawg-smi-datatypes-in-xsd-01.txt
	Network Working Group B. Natale, Ed.		Network Working Group B. Natale, Ed.
	Internet-Draft MITRE		Internet-Draft MITRE
	Intended status: Standards Track Y. Li, Ed.		Intended status: Standards Track Y. Li, Ed.
	Expires: August 14, 2008 Huawei Technologies		Expires: August 28, 2008 Huawei Technologies
	February 11, 2008		February 25, 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-00.txt		draft-ietf-opsawg-smi-datatypes-in-xsd-01.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 35
	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 August 14, 2008.		This Internet-Draft will expire on August 28, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	This memo defines the IETF standard expression of Simple Network		This memo (when approved as a standards-track RFC) defines the IETF
	Management Protocol (SNMP) Structure of Management Information (SMI)		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 production		language. The primary objective of this memo is to enable production
	of XML documents that are as faithful to the SMI as possible, using		of XML documents that are as faithful to the SMI as possible, using
	XSD as the validation mechanism.		XSD as the validation mechanism.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. XSD for SMI Datatypes . . . . . . . . . . . . . . . . . . . . 5		4. XSD for SMI Datatypes . . . . . . . . . . . . . . . . . . . . 5
	5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 7		5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	5.1. Numeric Datatypes . . . . . . . . . . . . . . . . . . . . 7		5.1. Numeric Datatypes . . . . . . . . . . . . . . . . . . . . 7
	5.2. OctetString . . . . . . . . . . . . . . . . . . . . . . . 8		5.2. OctetString . . . . . . . . . . . . . . . . . . . . . . . 8
	5.3. Opaque . . . . . . . . . . . . . . . . . . . . . . . . . . 8		5.3. Opaque . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	5.4. IpAddress . . . . . . . . . . . . . . . . . . . . . . . . 9		5.4. IpAddress . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.5. ObjectIdentifier . . . . . . . . . . . . . . . . . . . . . 9		5.5. ObjectIdentifier . . . . . . . . . . . . . . . . . . . . . 9
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 10		6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
	9. Normative References . . . . . . . . . . . . . . . . . . . . . 11		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 11		9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
			9.2. Informational References . . . . . . . . . . . . . . . . . 11
			Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 12
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 12		Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 12
	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 industry -- for the expression of management		network management community -- for the expression of management
	information described in and accessible via SNMP Management		information described in and accessible via SMI Management
	Information Bases (MIBs) as XML documents [ref.XML]. For example,		Information Base (MIB) modules as XML documents [ref.XML]. For
	XML-based management applications which want to incorporate SNMP MIBs		example, XML-based management applications which want to incorporate
	as data models and/or to access SNMP MIB instrumentation via gateways		MIB modules as data models and/or to access MIB module
	to SNMP agents will benefit from an IETF standard mapping of MIB		instrumentation via gateways to SNMP agents will benefit from an IETF
	datatypes and structures to XML documents via XSD.		standard mapping of SMI datatypes and structures to XML documents via
			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		MIBs, SMIv1 [RFC1155]. MIB data is conveyed via SNMP using the base
	datatypes defined in the SMI. The SMI allows for creation of		datatypes defined in the SMI. The SMI allows for creation of
	derivative datatypes, termed "textual conventions" ("TCs"), each of		derivative datatypes, termed "textual conventions" ("TCs"), each of
	which has a unique name, a syntax based on a core SMI datatype, and		which has a unique name, a syntax based on a core SMI datatype, and
	relatively precise application-level semantics. TCs are used		relatively precise application-level semantics. TCs are used
	principally to facilitate correct application-level handling of MIB		principally to facilitate correct application-level handling of MIB
	data and for the convenience of humans reading MIB modules and		data and for the convenience of humans reading MIB modules and
	appropriately rendered MIB data output.		appropriately rendered MIB data output.
	Various independent schemes have been devised for expressing the SMI		Various independent schemes have been devised for expressing the SMI
	datatypes and textual conventions in XSD [ref.XMLSchema]. These		datatypes and TCs in XSD [ref.XMLSchema]. These schemes have
	schemes have exhibited a degree of commonality (especially concerning		exhibited a degree of commonality (especially concerning the numeric
	the numeric SMI datatypes), but also sufficient differences		SMI datatypes), but also sufficient differences (especially
	(especially concerning the non-numeric SMI datatypes) to preclude		concerning the non-numeric SMI datatypes) to preclude general
	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 datatypes in XSD to ensure uniformity and general		of SMI base datatypes in XSD to ensure uniformity and general
	interoperability in this respect. Internet operators, management		interoperability in this respect. Internet operators, management
	tool developers, and users will benefit from the wider selection of		tool developers, and users will benefit from the wider selection of
	management tools and the greater degree of unified management -- with		management tools and the greater degree of unified management -- with
	attendant improvements in timeliness and accuracy of management		attendant improvements in timeliness and accuracy of management
	information -- which such a standard will facilitate.		information -- which such a standard will facilitate.
	This memo is the first in a set of three related and (logically)		This memo is the first in a set of three related and (logically)
	ordered specifications:		ordered specifications:
	1. SNMP SMI Datatypes [RFC2578] in XSD		1. SMI Base Datatypes [RFC2578] in XSD
	2. SNMP MIB Structure [RFC2578] in XSD		2. SMI MIB Structure [RFC2578] in XSD
	3. SNMP Textual Conventions [RFC2579] in XSD		3. SNMP Textual Conventions [RFC2579] in XSD
	As a set, these documents define the XSD equivalent of SMIv2 to		As a set, these documents define the XSD equivalent of SMIv2 to
	encourage XML-based protocols to carry, and XML-based applications to		encourage XML-based protocols to carry, and XML-based applications to
	use, the information modeled in the SMIv2-compliant Management		use, the information modeled in SMIv2-compliant MIB modules.
	Information Base ("The MIB").
	This work will define XSD equivalents of the datatypes and data		This work defines XSD equivalents of the datatypes and data
	structures [RFC2578]" and the textual conventions [RFC2579] defined		structures [RFC2578] and the textual conventions [RFC2579] defined in
	in the SMIv2 standard (STD58) to encourage efficient reuse of		the SMIv2 standard (STD58) to encourage efficient reuse of existing
	existing (including future) MIB modules and instrumentation by XML-		(including future) MIB modules and instrumentation by XML-based
	based management 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 4, line 38		skipping to change at page 4, line 38
	identified by [DISCUSS] markers in the text.		identified by [DISCUSS] markers in the text.
	3. Requirements		3. Requirements
	R1. All SMI datatypes MUST have a corresponding XSD datatype.		R1. All SMI 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
	to represent all valid values for that SMI datatype, and only		to represent all valid values for that SMI datatype.
	those values.
	R4. The XSD datatype specified for a given SMI datatype MUST		R4. The XSD datatype specified for a given SMI datatype MUST
	represent any special encoding rules associated with that SMI		represent any special encoding rules associated with that SMI
	datatype.		datatype.
	R5. The XSD datatype specified for a given SMI datatype MUST include		R5. The XSD datatype specified for a given SMI datatype MUST include
	any restrictions on values associated with the SMI datatype.		any restrictions on values associated with the SMI datatype.
	R6. The XSD datatype specified for a given SMI datatype MUST be the		R6. The XSD datatype specified for a given SMI datatype MUST be the
	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 from the perspective of		requirements SHOULD be the most direct (i.e., avoiding
	readability by humans.		superfluous "decoration") from the perspective of readability by
			humans.
	[DISCUSS} Should any requirements be added, deleted, re-worded?		[DISCUSS} Should any requirements be added, deleted, re-worded?
	4. XSD for SMI Datatypes		4. XSD for SMI Datatypes
	This document concerns the SMI datatypes that are carried "on-the-		This document concerns the SMI base datatypes. These are carried
	wire" -- i.e., have tag values defined in the SMI carried in varbinds		"on-the-wire" (and, therefore, have tag values defined in the SMI to
	in SNMP PDUs -- between SNMP management applications and SNMP agents:		identify them in varbinds) in SNMP PDUs between SNMP management
			applications and SNMP agents:
	o INTEGER		o INTEGER, Integer32
	o Integer32		o Unsigned32, Gauge32
	o Unsigned32
	o Counter32		o Counter32
	o Gauge32
	o TimeTicks		o TimeTicks
	o Counter64		o Counter64
	o OctetString		o OctetString
	o Opague		o Opague
	o IpAddress		o IpAddress
	o ObjectIdentifier		o ObjectIdentifier
	The following should be considered a "notional" XSD file for now,		The following should be considered a "notional" XSD file for now,
	pending agreement on the actual datatype specifications. An		pending agreement on the actual datatype specifications. An
	appropriate (official) targetNamespace must be designated (and		appropriate (official) targetNamespace must be designated (and
	skipping to change at page 6, line 4		skipping to change at page 5, line 50
	<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"/>
	</xs:simpleType>		</xs:simpleType>
	<xs:simpleType name="Counter32">
			<xs:simpleType name="Gauge32">
	<xs:restriction base="xs:unsignedInt"/>		<xs:restriction base="xs:unsignedInt"/>
	</xs:simpleType>		</xs:simpleType>
	<xs:simpleType name="Gauge32">		<xs:simpleType name="Counter32">
	<xs:restriction base="xs:unsignedInt"/>		<xs:restriction base="xs:unsignedInt"/>
	</xs:simpleType>		</xs:simpleType>
	<xs:simpleType name="TimeTicks">		<xs:simpleType name="TimeTicks">
	<xs:restriction base="xs:unsignedInt"/>		<xs:restriction base="xs:unsignedInt"/>
	</xs:simpleType>		</xs:simpleType>
	<xs:simpleType name="Counter64">		<xs:simpleType name="Counter64">
	<xs:restriction base="xs:unsignedLong"/>		<xs:restriction base="xs:unsignedLong"/>
	</xs:simpleType>		</xs:simpleType>
	skipping to change at page 7, line 35		skipping to change at page 7, line 35
	of the "lexical representations") documented in the W3C XSD		of the "lexical representations") documented in the W3C XSD
	specifications are assumed.		specifications are assumed.
	[DISCUSS] The use of "canonical representations" in the XSD specs		[DISCUSS] The use of "canonical representations" in the XSD specs
	might merit review by others. This author's (Natale) understanding		might merit review by others. This author's (Natale) understanding
	might not be complete or correct.		might not be complete or correct.
	5.1. Numeric Datatypes		5.1. Numeric Datatypes
	All of the numeric XSD datatypes specified in the previous section --		All of the numeric XSD datatypes specified in the previous section --
	INTEGER, Integer32, Unsigned32, Counter32, Counter, Gauge32, Gauge,		INTEGER, Integer32, Unsigned32, Gauge32, Counter32, TimeTicks, and
	TimeTicks, and 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 datatype 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 are required in the XSD).		is why no "restriction" statements -- other than the "base" 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).
	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
	skipping to change at page 9, line 45		skipping to change at page 9, line 45
	the core requirements for allowable value sequences)?		the core requirements for allowable value sequences)?
	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		results in a dotted-decimal string of up to 128 elements (referred to
	to as "sub-ids"), holding "Unsigned32" integer values.		as "sub-ids"), holding "Unsigned32" integer values.
	Note that, while not mentioned in Sec. 7.1.3 of RFC 2578, due to		Note that, while not mentioned in Sec. 7.1.3 of RFC 2578, due to the
	encoding rules the first two sub-ids of an "OBJECT IDENTIFIER" have		use of Abstract Syntax Notation One (ASN.1) Basic Encoding Rules
	limited value ranges ([0-2] and [0-39], respectively), and the		(BER) the first two sub-ids of an "OBJECT IDENTIFIER" have limited
	minimum length of an "OBJECT IDENTIFIER" is two sub-ids (with a zero-		value ranges ([0-2] and [0-39], respectively) and are packed into a
	valued "OBJECT IDENTIFIER" represented as "0.0"). No explicit		single octet [Steedman], and the minimum length of an "OBJECT
	"minLength" restriction (which would be "3" to allow for the minimum		IDENTIFIER" is two sub-ids (with a zero-valued "OBJECT IDENTIFIER"
	of two sub-ids) is required, since the pattern itself enforces this		represented as "0.0"). No explicit "minLength" restriction (which
			would be "3" to allow for the minimum of two sub-ids and a single
			separating dot) is required, since the pattern itself enforces this
	restriction.		restriction.
	[DISCUSS] The pattern specified for ObjectIdentifier attempts to		[DISCUSS] The pattern specified for ObjectIdentifier attempts to
	faithfully capture the restrictions mentioned above. Does it do so		faithfully capture the restrictions mentioned above. Does it do so
	correctly and is there a more efficient way of doing so?		correctly and is there a more efficient way of doing so?
	6. Security Considerations		6. Security Considerations
	Security considerations for any given MIB are likely to be relevant		Security considerations for any given SMI MIB module are likely to be
	to any XSD/XML mapping of that MIB.		relevant to any XSD/XML mapping of that MIB module; however, this
			mapping itself does not introduce any new 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 MIBs based on this specification		applications via XSD/XML mapping of MIB modules based on this
	and its planned siblings, special care will need to be taken to		specification and its planned siblings, special care will need to be
	ensure that any SNMPv3 security mechanisms are supported in an		taken to ensure that all applicable SNMP security mechanisms are
	appropriate manner yet to be determined.		supported in an appropriate manner yet to be determined.
	7. IANA Considerations		7. IANA Considerations
	[DISCUSS] We will likely need namespace and location resources from		[DISCUSS] We will likely need namespace and location resources from
	IANA...?.		IANA...?.
	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 and textual conventions
	to XSD.		to XSD.
	[TODO] Add an "Informational References" section documenting prior		Individuals who participated in various discussions of this topic at
	developmental publications and implementations.
	Individuals who participated in earlier discussions of this topic at
	IETF meetings and on IETF mailing lists include: Sharon Chisholm,		IETF meetings and on IETF mailing lists include: Sharon Chisholm,
	David Harrington, Ray Atarashi, Yoshifumi Atarashi, Bert Wijnen, Andy		David Harrington, Ray Atarashi, Yoshifumi Atarashi, Bert Wijnen, Andy
	Bierman, Randy Presuhn, Chris Lonvick, Eliot Lear, Avri Doria,		Bierman, Randy Presuhn, Chris Lonvick, Eliot Lear, Avri Doria,
	Juergen Schoenwaelder, Rob Ennes, Faye Ly and Andre Westerinen.		Juergen Schoenwaelder, Rob Ennes, Faye Ly and Andre Westerinen.
	[TODO] Expand list of participants as appropriate.		[TODO] Expand list of participants as appropriate.
	9. Normative References		9. References
			9.1. Normative References
	[RFC1155] Rose, M. and K. McCloghrie, "Structure and		[RFC1155] Rose, M. and K. McCloghrie, "Structure and
	identification of management information for TCP/		identification of management information for TCP/
	IP-based internets", STD 16, RFC 1155, May 1990.		IP-based internets", STD 16, RFC 1155, May 1990.
	[RFC2119] Bradner, s., "Key words for use in RFCs to		[RFC2119] Bradner, s., "Key words for use in RFCs to
	Indicate Requirement Levels", BCP 14, RFC 2119,		Indicate Requirement Levels", BCP 14, RFC 2119,
	March 1997.		March 1997.
	[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.		[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
	skipping to change at page 11, line 45		skipping to change at page 11, line 47
	<http://www.w3.org/TR/1998/REC-xml-19980210>.		<http://www.w3.org/TR/1998/REC-xml-19980210>.
	[ref.XMLSchema] World Wide Web Consortium, "XML Schema Part 1:		[ref.XMLSchema] World Wide Web Consortium, "XML Schema Part 1:
	Structures Second Edition", W3C XML Schema,		Structures Second Edition", W3C XML Schema,
	October 2004, <http://www.w3.org/TR/xmlschema-1/>.		October 2004, <http://www.w3.org/TR/xmlschema-1/>.
	[ref.XSDDatatype] World Wide Web Consortium, "XML Schema Part 2:		[ref.XSDDatatype] World Wide Web Consortium, "XML Schema Part 2:
	Datatypes Second Edition", W3C XML Schema,		Datatypes Second Edition", W3C XML Schema,
	October 2004, <http://www.w3.org/TR/xmlschema-2/>.		October 2004, <http://www.w3.org/TR/xmlschema-2/>.
			9.2. Informational References
			[Steedman] Steedman, D., "ASN.1: The Tutorial and Reference".
	Appendix A. Open Issues		Appendix A. Open Issues
	o Resolve all [TODO] items.		o Resolve all [TODO] items.
	o Resolve all [DISCUSS] items.		o Resolve all [DISCUSS] items.
	Appendix B. Change Log		Appendix B. Change Log
	-00 Initial version		o -00 Initial version
			o -01 version:
			o
			* Incorporated mailing list comments on -00 version from Juergen
			Schoenwaelder
			* Incorporated mailing list comments on -00 version from David
			Harrington
	Authors' Addresses		Authors' Addresses
	Bob Natale (editor)		Bob Natale (editor)
	MITRE		MITRE
	7515 Colshire Dr		7515 Colshire Dr
	MS H405		MS H405
	McLean, VA 22102		McLean, VA 22102
	USA		USA
End of changes. 29 change blocks.
	69 lines changed or deleted		84 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/