draft-ietf-opsawg-smi-datatypes-in-xsd-05.txt   draft-ietf-opsawg-smi-datatypes-in-xsd-06.txt 
Network Working Group B. Natale Network Working Group M. Ellison
Internet-Draft MITRE Internet-Draft Ellison Software Consulting
Intended status: Standards Track March 27, 2009 Intended status: Standards Track B. Natale
Expires: September 27, 2009 Expires: September 2, 2010 MITRE
March 1, 2010
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-05.txt draft-ietf-opsawg-smi-datatypes-in-xsd-06.txt
Abstract
This memo defines the IETF standard expression of Structure of
Management Information (SMI) base datatypes in Extensible Markup
Language (XML) Schema Definition (XSD) language. The primary
objective of this memo is to enable the production of XML documents
that are as faithful to the SMI as possible, using XSD as the
validation mechanism.
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. provisions of BCP 78 and 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.
skipping to change at page 1, line 32 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 27, 2009. This Internet-Draft will expire on September 2, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This memo defines the IETF standard expression of Structure of described in the BSD License.
Management Information (SMI) base datatypes in Extensible Markup
Language (XML) Schema Definition (XSD) language. The primary
objective of this memo is to enable the production of XML documents
that are as faithful to the SMI as possible, using XSD as the
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Numeric Datatypes . . . . . . . . . . . . . . . . . . . . 10 5.1. Numeric Datatypes . . . . . . . . . . . . . . . . . . . . 11
5.2. OctetString . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. OctetString . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Opaque . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.3. Opaque . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.4. IpAddress . . . . . . . . . . . . . . . . . . . . . . . . 12 5.4. IpAddress . . . . . . . . . . . . . . . . . . . . . . . . 13
5.5. ObjectIdentifier . . . . . . . . . . . . . . . . . . . . . 12 5.5. ObjectIdentifier . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7.1. SMI Base Datatypes Namespace Registration . . . . . . . . 14 7.1. SMI Base Datatypes Namespace Registration . . . . . . . . 16
7.2. SMI Base Datatypes Schema Registration . . . . . . . . . . 14 7.2. SMI Base Datatypes Schema Registration . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
9.2. Informational References . . . . . . . . . . . . . . . . . 16 9.2. Informational References . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Numerous uses exist -- both within and outside the traditional IETF Numerous use cases exist for expressing the management information
network management community -- for the expression of management described by SMI Management Information Base (MIB) modules in XML
information described in and accessible via SMI Management [XML]. Potential use cases reside both outside and within the
Information Base (MIB) modules as XML documents [XML]. For example, traditional IETF network management community. For example,
XML-based management applications which want to incorporate MIB developers of some XML-based management applications may want to
modules as data models and/or to access MIB module instrumentation incorporate the rich set of data models provided by MIB modules.
via gateways to SNMP agents will benefit from an IETF standard Developers of other XML-based management applications may want to
mapping of SMI datatypes to XML documents via XSD. access MIB module instrumentation via gateways to SNMP agents. Such
applications benefit from the IETF standard mapping of SMI datatypes
to XML datatypes via XSD [XMLSchema], [XSDDatatypes].
MIB data models are described using SMIv2 [RFC2578] and, for legacy MIB modules use SMIv2 [RFC2578] to describe data models. For legacy
MIBs, SMIv1 [RFC1155]. MIB data is conveyed in variable bindings MIB modules, SMIv1 [RFC1155] was used. MIB data conveyed in variable
("varbinds") within protocol data units (PDUs) within SNMP messages bindings ("varbinds") within protocol data units (PDUs) of SNMP
using the base/primitive datatypes defined in the SMI. messages use the primitive, base datatypes defined by the SMI.
The SMI allows for creation of derivative datatypes, termed "textual The SMI allows for the creation of derivative datatypes, "textual
conventions" ("TCs"), each of which has a unique name, a syntax which conventions" ("TCs") [RFC2579]. A TC has a unique name, has a syntax
is or refines a primitive SMI datatype, and relatively precise that either refines or is a base SMI datatype and has relatively
application-level semantics. TCs are used principally to facilitate precise application-level semantics. TCs facilitate correct
correct application-level handling of MIB data and for the application-level handling of MIB data, improve readability of MIB
convenience of humans reading MIB modules and appropriately rendered modules by humans and support appropriate renderings of MIB data.
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 Values in varbinds corresponding to MIB objects defined with TC
datatypes in XSD [XMLSchema]. These schemes have exhibited a degree syntax are always encoded as the base SMI datatype underlying the TC
of commonality (especially concerning the numeric SMI datatypes), but syntax. Thus, the XSD mappings defined in this memo provide support
also sufficient differences (especially concerning the non-numeric for values of MIB objects defined with TC syntax as well as for
SMI datatypes) to preclude uniformity and general interoperability. values of MIB objects defined with base SMI syntax.
The primary purpose of this memo is to define a standard expression Various independent schemes have been devised for expressing SMI
of SMI base datatypes in XSD to ensure fidelity, consistency, and datatypes in XSD. These schemes exhibit a degree of commonality,
general interoperability in this respect. Internet operators, especially concerning numeric SMI datatypes, but these schemes also
management tool developers, and users will benefit from the wider exhibit sufficient differences, especially concerning the non-numeric
selection of management tools and the greater degree of unified SMI datatypes, precluding uniformity of expression and general
management -- with attendant improvements in timeliness and accuracy interoperability.
of management information -- which such a standard facilitates.
On its own, this memo specifies the IETF standard way to render SMI Throughout this memo, the term "fidelity" refers to the quality of an
data values carried in SNMP messages as XML in a faithful, accurate, consistent representation of SMI data values and the term
consistent, and interoperable way. "faithful" refers to the quality of reliably reflecting the semantics
of SMI data values. Thus defined, the characteristics of fidelity
and being faithful are essential to uniformity of expression and
general interoperability in the XML representation of SMI data
values.
Certain XML-based applications will find this specification The primary purpose of this memo is to define the standard expression
sufficient for their purposes. Other XML applications may need to of SMI base datatypes in XML documents that is both uniform and
make more complete reuse of existing MIB modules, requiring standard interoperable. This standard expression enables Internet operators,
XSDs for TCs [RFC2579] and MIB structure [RFC2578]. Documents management application developers, and users to benefit from a wider
supporting those requirements are planned, but have not been produced range of management tools and to benefit from a greater degree of
at the time of this writing. unified management. Thus, standard expression enables and
facilitates improvements to the timeliness, accuracy and utility of
management information.
The objective of this memo, and of any future related specifications The overall objective of this memo, and of any related future memos
that might be produced, is to define the XSD equivalent as may be published, is to define the XSD equivalent [XSDDatatypes]
[XSDDatatypes] of SMIv2 (STD58) to encourage XML-based protocols to of SMIv2 (STD58) and to encourage XML-based protocols to carry, and
carry, and XML-based applications to use, the information modeled in XML-based applications to use, the management information defined in
SMIv2-compliant MIB modules. SMIv2-compliant MIB modules. The use of a standard mapping from
SMIv2 to XML via XSD validation enables and promotes the efficient
reuse of existing and future MIB modules and instrumentation by XML-
based protocols and management applications.
Having such a standard mapping of SMIv2 to XML via XSD validation Developers of certain XML-based management applications will find
will enable and promote efficient reuse of existing (including this specification sufficient for their purposes. Developers of
future) MIB modules and instrumentation by XML-based management other XML-based management applications may need to make more
protocols and applications. complete reuse of existing MIB modules, requiring standard XSD
documents for TCs [RFC2579] and MIB structure [RFC2578]. Memos
supporting such requirements are planned, but have not been produced
at the time of this writing.
The goal of fidelity to the SMIv2 standard (STD58), as specified in Finally, it is worthwhile to note that the goal of fidelity to the
the "Requirements" section below, is crucial to this effort to SMIv2 standard (STD58), as specified in the "Requirements" section
leverage the established "rough consensus" for the precise data below, is crucial to this effort. Fidelity leverages the established
modeling used in MIB modules, and to leverage existing "running code" "rough consensus" of the precise SMIv2 data models contained in MIB
for implemented SMIv2 data models. This effort does not include modules, and leverages existing instrumentation, the "running code"
redesign of SMIv2 datatypes or data structures or textual conventions implementing SMIv2 data models. This effort does not include any
to overcome known limitations -- that work can be pursued in other redesign of SMIv2 datatypes, data structures or textual conventions
efforts. in order to overcome known limitations. Such work can be pursued by
other efforts.
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 represent 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. Prior to mapping
if encountered, MUST be converted (at least logically) in datatypes into XSD, legacy SMIv1 modules MUST be converted (at
accordance with Section 2.1, inclusive, of the "Coexistence" RFC least logically) in accordance with Section 2.1, inclusive, of
[RFC3584]. the "Coexistence" RFC [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. to represent all valid values for that SMI datatype.
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 logical XSD datatype, with the fewest necessary
restrictions, which matches the foregoing requirements. restrictions on its set of values, consistent with 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 coherent and succinct
superfluous "decoration") from the perspective of readability by representation (i.e., avoiding superfluous "decoration") from
humans. the perspective of readability by humans.
4. XSD for SMI Base Datatypes 4. XSD for SMI Base Datatypes
This document provides XSD datatype mappings for the SMIv2 base This document provides XSD datatype mappings for the SMIv2 base
datatypes only -- i.e., the eleven "ObjectSyntax" datatypes defined datatypes only -- i.e., the eleven "ObjectSyntax" datatypes defined
in RFC 2578. These datatypes -- via tag values defined in the SMIv2 in RFC 2578. These datatypes -- via tag values defined in the SMIv2
to identify them in varbinds -- constrain values carried "on-the- to identify them in varbinds -- constrain values carried "on-the-
wire" in SNMP PDUs between SNMP management applications and SNMP wire" in SNMP PDUs between SNMP management applications and SNMP
agents: agents:
skipping to change at page 8, line 19 skipping to change at page 8, line 19
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: Mark Ellison
Organization: Ellison Software Consulting
Address: 38 Salem Road
Atkinson, NH 03811
USA
Telephone: +1 603-362-9270
E-Mail: ietf@EllisonSoftware.com
Contact: Bob Natale Contact: Bob Natale
Organization: MITRE Organization: MITRE
Address: 7515 Colshire Drive Address: 300 Sentinel Drive
McLean VA 22102 6th Floor
Annapolis Junction MD 20701
USA USA
Telephone: +1 703-983-2505 Telephone: +1 301-617-3008
E-Mail: rnatale@mitre.org E-Mail: rnatale@mitre.org
Last Updated: 200903090000Z
Last Updated: 201002260000Z
Copyright (c) 2010 IETF Trust and the persons
identified as the document authors. All rights
reserved.
Redistribution and use in source and binary forms,
with or without modification, is permitted pursuant
to, and subject to the license terms contained in,
the Simplified BSD License set forth in Section
4.c of the IETF Trust's Legal Provisions Relating to
IETF Documents (http://trustee.ietf.org/license-info).
This version of this XML Schema Definition (XSD)
document is part of RFC XXXX; see the RFC itself for
full legal notices."
RFC Editor - please replace XXXX with the value allocated
for publication as an RFC.
</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>
skipping to change at page 10, line 12 skipping to change at page 11, line 12
</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
based on fit with the requirements specified earlier in this based on fit with the requirements specified earlier in this
document, and with attention to simplicity while maintaining fidelity document, and with attention to simplicity while maintaining fidelity
to the SMI. Also, the "canonical representations" (i.e., refinements to the SMI. Also, the "canonical representations" (i.e., refinements
of the "lexical representations") documented in the W3C XSD of the "lexical representations") documented in the W3C XSD
specifications are assumed. specification [XMLSchema], [XSDDatatypes] are assumed.
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, Gauge32, Counter32, TimeTicks, and INTEGER, Integer32, Unsigned32, Gauge32, Counter32, 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
skipping to change at page 12, line 26 skipping to change at page 13, line 26
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.
Note that the SMI relies upon Textual Conventions (TCs) to specify an
IPv6 address. As such, the representation of an IPv6 address as an
XSD datatype is beyond the scope of this document.
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 the first two components of an "OBJECT IDENTIFIER" each
use of Abstract Syntax Notation One (ASN.1) Basic Encoding Rules have a limited range of values as indicated in the XSD pattern
(BER) the first two components of an "OBJECT IDENTIFIER" have limited restriction and as described in The ASN1.1/BER standard [ASN.1].
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 There are three values allocated for the root node, and at most 39
sub-identifier is derived from the values of the first two "OBJECT values for nodes subordinate to a root node value of 0 or 1.
IDENTIFIER" components in the value being encoded, using the formula:
(X*40) + Y, where X is the value of the first component and Y is the The minimum length of an "OBJECT IDENTIFIER" is two sub-ids and the
value of the second component. This packing of the first two representation of a zero-valued "OBJECT IDENTIFIER" is "0.0".
components recognizes that only three values are allocated from the
root node, and at most 39 subsequent values from nodes reached by X = Note that no explicit "minLength" restriction, which would be "3" to
0 and X = 1. The minimum length of an "OBJECT IDENTIFIER" is two allow for the minimum of two sub-ids and a single separating dot, is
sub-ids (with a zero-valued "OBJECT IDENTIFIER" represented as required since the pattern itself enforces this restriction.
"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.
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
skipping to change at page 15, line 19 skipping to change at page 17, line 19
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 to XSD. published candidate mappings of SMI datatypes 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, Rob
Ellison, Rob Ennes, Mehmet Ersue, David Harrington, Alfred Hines, Ennes, Mehmet Ersue, David Harrington, Alfred Hines, Eliot Lear,
Eliot Lear, Chris Lonvick, Faye Ly, Randy Presuhn, Juergen Chris Lonvick, Faye Ly, Randy Presuhn, Juergen Schoenwaelder, Andre
Schoenwaelder, Andre Westerinen, and Bert Wijnen. Westerinen, and Bert Wijnen.
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 16, line 25 skipping to change at page 18, line 25
[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.
[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,
January 2004.
[Steedman]
Steedman, D., "ASN.1: The Tutorial and Reference".
[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>.
[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/>.
[XSDDatatypes] [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/>.
Author's Address 9.2. Informational References
[ASN.1] International Organization for Standardization,
"Information processing systems - Open Systems
Interconnection - Specification of Basic Encoding Rules
for Abstract Syntax Notation One (ASN.1)", International
Standard 8825, December 1987.
[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,
January 2004.
Authors' Addresses
Mark Ellison
Ellison Software Consulting
38 Salem Road
Atkinson, NH 03811
USA
Phone: +1 603-362-9270
Email: ietf@ellisonsoftware.com
Bob Natale Bob Natale
MITRE MITRE
7515 Colshire Dr 300 Sentinel Drive
MS H405 6th Floor
McLean, VA 22102 Annapolis Junction, MD 20701
USA USA
Phone: +1 703-983-2505 Phone: +1 301-617-3008
Email: rnatale@mitre.org Email: rnatale@mitre.org
 End of changes. 31 change blocks. 
147 lines changed or deleted 203 lines changed or added

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