draft-ietf-opsawg-smi-datatypes-in-xsd-06.txt   rfc5935.txt 
Network Working Group M. Ellison Internet Engineering Task Force (IETF) M. Ellison
Internet-Draft Ellison Software Consulting Request for Comments: 5935 Ellison Software Consulting
Intended status: Standards Track B. Natale Category: Standards Track B. Natale
Expires: September 2, 2010 MITRE ISSN: 2070-1721 MITRE
March 1, 2010 August 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-06.txt
Abstract Abstract
This memo defines the IETF standard expression of Structure of This memo defines the IETF standard expression of Structure of
Management Information (SMI) base datatypes in Extensible Markup Management Information (SMI) base datatypes in XML Schema Definition
Language (XML) Schema Definition (XSD) language. The primary (XSD) 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.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on September 2, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5935.
Copyright Notice Copyright Notice
Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions .....................................................4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Requirements ....................................................4
4. XSD for SMI Base Datatypes . . . . . . . . . . . . . . . . . . 7 4. XSD for SMI Base Datatypes ......................................5
5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Rationale .......................................................8
5.1. Numeric Datatypes . . . . . . . . . . . . . . . . . . . . 11 5.1. Numeric Datatypes ..........................................8
5.2. OctetString . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. OctetString ................................................9
5.3. Opaque . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.3. Opaque ....................................................10
5.4. IpAddress . . . . . . . . . . . . . . . . . . . . . . . . 13 5.4. IpAddress .................................................10
5.5. ObjectIdentifier . . . . . . . . . . . . . . . . . . . . . 13 5.5. ObjectIdentifier ..........................................10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations ........................................11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations ............................................11
7.1. SMI Base Datatypes Namespace Registration . . . . . . . . 16 7.1. SMI Base Datatypes Namespace Registration .................12
7.2. SMI Base Datatypes Schema Registration . . . . . . . . . . 16 7.2. SMI Base Datatypes Schema Registration ....................12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgements ...............................................12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. References .....................................................13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References ......................................13
9.2. Informational References . . . . . . . . . . . . . . . . . 18 9.2. Informative References ....................................13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Numerous use cases exist for expressing the management information Numerous use cases exist for expressing the management information
described by SMI Management Information Base (MIB) modules in XML described by SMI Management Information Base (MIB) modules in XML
[XML]. Potential use cases reside both outside and within the [XML]. Potential use cases reside both outside and within the
traditional IETF network management community. For example, traditional IETF network management community. For example,
developers of some XML-based management applications may want to developers of some XML-based management applications may want to
incorporate the rich set of data models provided by MIB modules. incorporate the rich set of data models provided by MIB modules.
Developers of other XML-based management applications may want to Developers of other XML-based management applications may want to
skipping to change at page 3, line 25 skipping to change at page 2, line 46
applications benefit from the IETF standard mapping of SMI datatypes applications benefit from the IETF standard mapping of SMI datatypes
to XML datatypes via XSD [XMLSchema], [XSDDatatypes]. to XML datatypes via XSD [XMLSchema], [XSDDatatypes].
MIB modules use SMIv2 [RFC2578] to describe data models. For legacy MIB modules use SMIv2 [RFC2578] to describe data models. For legacy
MIB modules, SMIv1 [RFC1155] was used. MIB data conveyed in variable MIB modules, SMIv1 [RFC1155] was used. MIB data conveyed in variable
bindings ("varbinds") within protocol data units (PDUs) of SNMP bindings ("varbinds") within protocol data units (PDUs) of SNMP
messages use the primitive, base datatypes defined by the SMI. messages use the primitive, base datatypes defined by the SMI.
The SMI allows for the creation of derivative datatypes, "textual The SMI allows for the creation of derivative datatypes, "textual
conventions" ("TCs") [RFC2579]. A TC has a unique name, has a syntax conventions" ("TCs") [RFC2579]. A TC has a unique name, has a syntax
that either refines or is a base SMI datatype and has relatively that either refines or is a base SMI datatype, and has relatively
precise application-level semantics. TCs facilitate correct precise application-level semantics. TCs facilitate correct
application-level handling of MIB data, improve readability of MIB application-level handling of MIB data, improve readability of MIB
modules by humans and support appropriate renderings of MIB data. modules by humans, and support appropriate renderings of MIB data.
Values in varbinds corresponding to MIB objects defined with TC Values in varbinds corresponding to MIB objects defined with TC
syntax are always encoded as the base SMI datatype underlying the TC syntax are always encoded as the base SMI datatype underlying the TC
syntax. Thus, the XSD mappings defined in this memo provide support syntax. Thus, the XSD mappings defined in this memo provide support
for values of MIB objects defined with TC syntax as well as for for values of MIB objects defined with TC syntax as well as for
values of MIB objects defined with base SMI syntax. values of MIB objects defined with base SMI syntax. Using the
translation of TC into base SMI datatypes any MIB module that uses
TCs can be mapped into XSD using the mappings defined in this memo.
For example, for IP addresses (both IPv4 and IPv6), MIB objects
defined using the InetAddress TC (as per [RFC4001]) are encoded using
the base SMI datatype underlying the InetAddress TC syntax rather
than the IpAddress base datatype.
Various independent schemes have been devised for expressing SMI Various independent schemes have been devised for expressing SMI
datatypes in XSD. These schemes exhibit a degree of commonality, datatypes in XSD. These schemes exhibit a degree of commonality,
especially concerning numeric SMI datatypes, but these schemes also especially concerning numeric SMI datatypes, but these schemes also
exhibit sufficient differences, especially concerning the non-numeric exhibit sufficient differences, especially concerning the non-numeric
SMI datatypes, precluding uniformity of expression and general SMI datatypes, precluding uniformity of expression and general
interoperability. interoperability.
Throughout this memo, the term "fidelity" refers to the quality of an Throughout this memo, the term "fidelity" refers to the quality of an
accurate, consistent representation of SMI data values and the term accurate, consistent representation of SMI data values and the term
skipping to change at page 4, line 8 skipping to change at page 3, line 38
and being faithful are essential to uniformity of expression and and being faithful are essential to uniformity of expression and
general interoperability in the XML representation of SMI data general interoperability in the XML representation of SMI data
values. values.
The primary purpose of this memo is to define the standard expression The primary purpose of this memo is to define the standard expression
of SMI base datatypes in XML documents that is both uniform and of SMI base datatypes in XML documents that is both uniform and
interoperable. This standard expression enables Internet operators, interoperable. This standard expression enables Internet operators,
management application developers, and users to benefit from a wider management application developers, and users to benefit from a wider
range of management tools and to benefit from a greater degree of range of management tools and to benefit from a greater degree of
unified management. Thus, standard expression enables and unified management. Thus, standard expression enables and
facilitates improvements to the timeliness, accuracy and utility of facilitates improvements to the timeliness, accuracy, and utility of
management information. management information.
The overall objective of this memo, and of any related future memos The overall objective of this memo, and of any related future memos
as may be published, is to define the XSD equivalent [XSDDatatypes] as may be published, is to define the XSD equivalent [XSDDatatypes]
of SMIv2 (STD58) and to encourage XML-based protocols to carry, and of SMIv2 (STD 58) and to encourage XML-based protocols to carry, and
XML-based applications to use, the management information defined in XML-based applications to use, the management information defined in
SMIv2-compliant MIB modules. The use of a standard mapping from SMIv2-compliant MIB modules. The use of a standard mapping from
SMIv2 to XML via XSD validation enables and promotes the efficient SMIv2 to XML via XSD validation enables and promotes the efficient
reuse of existing and future MIB modules and instrumentation by XML- reuse of existing and future MIB modules and instrumentation by XML-
based protocols and management applications. based protocols and management applications.
Developers of certain XML-based management applications will find Developers of certain XML-based management applications will find
this specification sufficient for their purposes. Developers of this specification sufficient for their purposes. Developers of
other XML-based management applications may need to make more other XML-based management applications may need to make more
complete reuse of existing MIB modules, requiring standard XSD complete reuse of existing MIB modules, requiring standard XSD
documents for TCs [RFC2579] and MIB structure [RFC2578]. Memos documents for TCs [RFC2579] and MIB structure [RFC2578]. Memos
supporting such requirements are planned, but have not been produced supporting such requirements are planned, but have not been produced
at the time of this writing. at the time of this writing.
Finally, it is worthwhile to note that the goal of fidelity to the Finally, it is worthwhile to note that the goal of fidelity to the
SMIv2 standard (STD58), as specified in the "Requirements" section SMIv2 standard (STD 58), as specified in the "Requirements" section
below, is crucial to this effort. Fidelity leverages the established below, is crucial to this effort. Fidelity leverages the established
"rough consensus" of the precise SMIv2 data models contained in MIB "rough consensus" of the precise SMIv2 data models contained in MIB
modules, and leverages existing instrumentation, the "running code" modules, and leverages existing instrumentation, the "running code"
implementing SMIv2 data models. This effort does not include any implementing SMIv2 data models. This effort does not include any
redesign of SMIv2 datatypes, data structures or textual conventions redesign of SMIv2 datatypes, data structures or textual conventions
in order to overcome known limitations. Such work can be pursued by in order to overcome known limitations. Such work can be pursued by
other efforts. 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 that 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. Prior to mapping R2. SMIv2 is the normative SMI for this document. Prior to mapping
datatypes into XSD, legacy SMIv1 modules MUST be converted (at datatypes into XSD, legacy SMIv1 modules MUST be converted (at
least logically) in accordance with Section 2.1, inclusive, of least logically) in accordance with Section 2.1, inclusive, of
the "Coexistence" RFC [RFC3584]. the "Coexistence" RFC [RFC3584].
skipping to change at page 8, line 9 skipping to change at page 6, line 9
o OBJECT IDENTIFIER o OBJECT IDENTIFIER
The "BITS" pseudo-type (also referred to as a "construct" in RFC The "BITS" pseudo-type (also referred to as a "construct" in RFC
2578) is treated as a Textual Convention, not a base datatype, for 2578) is treated as a Textual Convention, not a base datatype, for
the purpose of this document. the purpose of this 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:smi:base:1.0"
targetNamespace="urn:ietf:params:xml:ns:opsawg:smi:base:1.0" targetNamespace="urn:ietf:params:xml:ns: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 Contact: Mark Ellison
Organization: Ellison Software Consulting Organization: Ellison Software Consulting
Address: 38 Salem Road Address: 38 Salem Road
Atkinson, NH 03811 Atkinson, NH 03811
USA USA
Telephone: +1 603-362-9270 Telephone: +1 603-362-9270
E-Mail: ietf@EllisonSoftware.com E-Mail: ietf@EllisonSoftware.com
Contact: Bob Natale Contact: Bob Natale
Organization: MITRE Organization: MITRE
Address: 300 Sentinel Drive Address: 300 Sentinel Drive
6th Floor 6th Floor
Annapolis Junction MD 20701 Annapolis Junction, MD 20701
USA USA
Telephone: +1 301-617-3008 Telephone: +1 301-617-3008
E-Mail: rnatale@mitre.org E-Mail: rnatale@mitre.org
Last Updated: 201002260000Z Last Updated: 201002260000Z
Copyright (c) 2010 IETF Trust and the persons Copyright (c) 2010 IETF Trust and the persons identified as
identified as the document authors. All rights authors of the code. All rights reserved.
reserved.
Redistribution and use in source and binary forms, Redistribution and use in source and binary forms, with or
with or without modification, is permitted pursuant without modification, is permitted pursuant to, and subject
to, and subject to the license terms contained in, to the license terms contained in, the Simplified BSD License
the Simplified BSD License set forth in Section set forth in Section 4.c of the IETF Trust's Legal Provisions
4.c of the IETF Trust's Legal Provisions Relating to Relating to IETF Documents
IETF Documents (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this XML Schema Definition (XSD) This version of this XML Schema Definition (XSD)
document is part of RFC XXXX; see the RFC itself for document is part of RFC 5935; see the RFC itself for
full legal notices." 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 9, line 48 skipping to change at page 7, line 46
<xs:restriction base="xs:hexBinary"> <xs:restriction base="xs:hexBinary">
<xs:maxLength value="65535"/> <xs:maxLength value="65535"/>
</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})| "(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}
(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))| ([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])"/>
([3-9][0-9]?))\.){3} </xs:restriction>
(0|(1[0-9]{0,2})|
(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))|
([3-9][0-9]?))"/>
</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>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
skipping to change at page 11, line 28 skipping to change at page 8, line 39
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 datatypes which exhibit the foregoing o They are the most direct XSD datatypes that 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, Counter32, Counter64, and the original. However, the Gauge32, Counter32, Counter64, and
TimeTicks datatypes have special application semantics that must be TimeTicks datatypes have special application semantics that must be
considered when using their raw values for anything other than considered when using their raw values for anything other than
display, printing, storage, or transmission of the literal value. display, printing, storage, or transmission of the literal value.
RFC 2578 provides the necessary details. RFC 2578 provides the necessary details.
5.2. OctetString 5.2. OctetString
skipping to change at page 12, line 28 skipping to change at page 9, line 44
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.
o It is the most direct XSD datatype which exhibits the foregoing o It is the most direct XSD datatype that 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. 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 that 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 "Opaque" 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 "Opaque". for "Opaque".
o It is the most direct XSD datatype which exhibits the foregoing o It is the most direct XSD datatype that 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 "Opaque" 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
skipping to change at page 13, line 43 skipping to change at page 11, line 13
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 the first two components of an "OBJECT IDENTIFIER" each Note that the first two components of an "OBJECT IDENTIFIER" each
have a limited range of values as indicated in the XSD pattern have a limited range of values as indicated in the XSD pattern
restriction and as described in The ASN1.1/BER standard [ASN.1]. restriction and as described in the ASN1.1/BER standard [ASN.1].
There are three values allocated for the root node, and at most 39 There are three values allocated for the root node, and at most 39
values for nodes subordinate to a root node value of 0 or 1. values for nodes subordinate to a root node value of 0 or 1.
The minimum length of an "OBJECT IDENTIFIER" is two sub-ids and the The minimum length of an "OBJECT IDENTIFIER" is two sub-ids and the
representation of a zero-valued "OBJECT IDENTIFIER" is "0.0". representation of a zero-valued "OBJECT IDENTIFIER" is "0.0".
Note that no explicit "minLength" restriction, which would be "3" to Note that no explicit "minLength" restriction, which would be "3" to
allow for the minimum of two sub-ids and a single separating dot, is allow for the minimum of two sub-ids and a single separating dot, is
required since the pattern itself enforces this restriction. 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 will be relevant
relevant to any XSD/XML mapping of that MIB module; however, the to any XSD/XML mapping of that MIB module; however, the mapping
mapping defined in this document does not itself introduce any new defined in this document does not itself introduce any new security
security considerations. 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 [RFC3688], we request the following In accordance with RFC 3688 [RFC3688], the IANA XML registry has been
namespace and schema registrations associated with this document in updated with the following namespace and schema registrations
the IANA XML Registry: associated with this document:
o urn:ietf:params:xml:ns:opsawg:smi:base:[version_id] o urn:ietf:params:xml:ns:smi:base:1.0
o urn:ietf:params:xml:schema:opsawg:smi:base:[version_id] o urn:ietf:params:xml:schema:base:1.0
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:smi:base:1.0
Registration Contact: The IESG. Registration Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
7.2. SMI Base Datatypes Schema Registration 7.2. SMI Base Datatypes Schema Registration
This document registers a URI for the SMI Base Datatypes XML schema This document registers a URI for the SMI Base Datatypes XML schema
in the IETF XML registry. Following the format in RFC 3688, IANA has in the IETF XML registry. Following the format in RFC 3688, IANA has
made the following registration: made the following registration:
URI: urn:ietf:params:xml:schema:opsawg:smi:base:1.0 URI: urn:ietf:params:xml:schema:smi:base:1.0
Registration Contact: The IESG. Registration Contact: The IESG.
XML: Section 4 of this document. XML: Section 4 of this document.
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 that 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 "Datatypes for Netconf Data Models"
to many other sources (including libsmi and group discussions on the [NETCONF-DATATYPES] and to many other sources (including libsmi and
NETCONF mailing lists) developed by those who have researched and group discussions on the NETCONF mailing lists) developed by those
published candidate mappings of SMI datatypes to XSD. who have researched and 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, Rob Yoshifumi Atarashi, Andy Bierman, Sharon Chisholm, Avri Doria, Rob
Ennes, Mehmet Ersue, David Harrington, Alfred Hines, Eliot Lear, Ennes, Mehmet Ersue, David Harrington, Alfred Hines, Eliot Lear,
Chris Lonvick, Faye Ly, Randy Presuhn, Juergen Schoenwaelder, Andre Chris Lonvick, Faye Ly, Randy Presuhn, Juergen Schoenwaelder, Andrea
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
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.
[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.
skipping to change at page 18, line 39 skipping to change at page 13, line 39
[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/>.
9.2. Informational References 9.2. Informative References
[ASN.1] International Organization for Standardization, [ASN.1] International Organization for Standardization,
"Information processing systems - Open Systems "Information processing systems - Open Systems
Interconnection - Specification of Basic Encoding Rules Interconnection - Specification of Basic Encoding Rules
for Abstract Syntax Notation One (ASN.1)", International for Abstract Syntax Notation One (ASN.1)", International
Standard 8825, December 1987. Standard 8825, December 1987.
[NETCONF-DATATYPES]
Romascanu, D., "Datatypes for Netconf Data Models", Work
in Progress, May 2007.
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Textual Conventions for SMIv2", STD 58, RFC 2579, "Textual Conventions for SMIv2", STD 58, RFC 2579,
April 1999. 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.
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 4001, February 2005.
Authors' Addresses Authors' Addresses
Mark Ellison Mark Ellison
Ellison Software Consulting Ellison Software Consulting
38 Salem Road 38 Salem Road
Atkinson, NH 03811 Atkinson, NH 03811
USA USA
Phone: +1 603-362-9270 Phone: +1 603-362-9270
Email: ietf@ellisonsoftware.com EMail: ietf@ellisonsoftware.com
Bob Natale Bob Natale
MITRE MITRE
300 Sentinel Drive 300 Sentinel Drive
6th Floor 6th Floor
Annapolis Junction, MD 20701 Annapolis Junction, MD 20701
USA USA
Phone: +1 301-617-3008 Phone: +1 301-617-3008
Email: rnatale@mitre.org EMail: rnatale@mitre.org
 End of changes. 45 change blocks. 
109 lines changed or deleted 105 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/