idnits 2.17.1
draft-ietf-opsawg-smi-datatypes-in-xsd-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1 on line 16.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 532.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 543.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 550.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 556.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust Copyright Line does not match the
current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (February 11, 2008) is 5917 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'TODO' is mentioned on line 490, but not defined
== Missing Reference: 'DISCUSS' is mentioned on line 491, but not defined
== Missing Reference: '0-9' is mentioned on line 248, but not defined
== Missing Reference: '0-4' is mentioned on line 241, but not defined
== Missing Reference: '0-5' is mentioned on line 241, but not defined
== Missing Reference: '6-9' is mentioned on line 241, but not defined
== Missing Reference: '3-9' is mentioned on line 241, but not defined
== Missing Reference: '0-2' is mentioned on line 396, but not defined
== Missing Reference: '1-3' is mentioned on line 248, but not defined
== Missing Reference: '1-9' is mentioned on line 248, but not defined
== Missing Reference: '0-39' is mentioned on line 396, but not defined
Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 7 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group B. Natale, Ed.
3 Internet-Draft MITRE
4 Intended status: Standards Track Y. Li, Ed.
5 Expires: August 14, 2008 Huawei Technologies
6 February 11, 2008
8 Expressing SNMP SMI Datatypes in XML Schema Definition Language
9 draft-ietf-opsawg-smi-datatypes-in-xsd-00.txt
11 Status of This Memo
13 By submitting this Internet-Draft, each author represents that any
14 applicable patent or other IPR claims of which he or she is aware
15 have been or will be disclosed, and any of which he or she becomes
16 aware will be disclosed, in accordance with Section 6 of BCP 79.
18 Internet-Drafts are working documents of the Internet Engineering
19 Task Force (IETF), its areas, and its working groups. Note that
20 other groups may also distribute working documents as Internet-
21 Drafts.
23 Internet-Drafts are draft documents valid for a maximum of six months
24 and may be updated, replaced, or obsoleted by other documents at any
25 time. It is inappropriate to use Internet-Drafts as reference
26 material or to cite them other than as "work in progress."
28 The list of current Internet-Drafts can be accessed at
29 http://www.ietf.org/ietf/1id-abstracts.txt.
31 The list of Internet-Draft Shadow Directories can be accessed at
32 http://www.ietf.org/shadow.html.
34 This Internet-Draft will expire on August 14, 2008.
36 Copyright Notice
38 Copyright (C) The IETF Trust (2008).
40 Abstract
42 This memo defines the IETF standard expression of Simple Network
43 Management Protocol (SNMP) Structure of Management Information (SMI)
44 datatypes in eXtensible Markup Language (XML) Schema Definition (XSD)
45 language. The primary objective of this memo is to enable production
46 of XML documents that are as faithful to the SMI as possible, using
47 XSD as the validation mechanism.
49 Table of Contents
51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
52 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
53 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
54 4. XSD for SMI Datatypes . . . . . . . . . . . . . . . . . . . . 5
55 5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 7
56 5.1. Numeric Datatypes . . . . . . . . . . . . . . . . . . . . 7
57 5.2. OctetString . . . . . . . . . . . . . . . . . . . . . . . 8
58 5.3. Opaque . . . . . . . . . . . . . . . . . . . . . . . . . . 8
59 5.4. IpAddress . . . . . . . . . . . . . . . . . . . . . . . . 9
60 5.5. ObjectIdentifier . . . . . . . . . . . . . . . . . . . . . 9
61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
63 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
64 9. Normative References . . . . . . . . . . . . . . . . . . . . . 11
65 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 11
66 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 12
68 1. Introduction
70 Numerous uses exist -- both within and outside the traditional IETF
71 network management industry -- for the expression of management
72 information described in and accessible via SNMP Management
73 Information Bases (MIBs) as XML documents [ref.XML]. For example,
74 XML-based management applications which want to incorporate SNMP MIBs
75 as data models and/or to access SNMP MIB instrumentation via gateways
76 to SNMP agents will benefit from an IETF standard mapping of MIB
77 datatypes and structures to XML documents via XSD.
79 MIB data models are described using SMIv2 [RFC2578] and, for legacy
80 MIBs, SMIv1 [RFC1155]. MIB data is conveyed via SNMP using the
81 datatypes defined in the SMI. The SMI allows for creation of
82 derivative datatypes, termed "textual conventions" ("TCs"), each of
83 which has a unique name, a syntax based on a core SMI datatype, and
84 relatively precise application-level semantics. TCs are used
85 principally to facilitate correct application-level handling of MIB
86 data and for the convenience of humans reading MIB modules and
87 appropriately rendered MIB data output.
89 Various independent schemes have been devised for expressing the SMI
90 datatypes and textual conventions in XSD [ref.XMLSchema]. These
91 schemes have exhibited a degree of commonality (especially concerning
92 the numeric SMI datatypes), but also sufficient differences
93 (especially concerning the non-numeric SMI datatypes) to preclude
94 general interoperability.
96 The primary purpose of this memo is to define a standard expression
97 of SMI datatypes in XSD to ensure uniformity and general
98 interoperability in this respect. Internet operators, management
99 tool developers, and users will benefit from the wider selection of
100 management tools and the greater degree of unified management -- with
101 attendant improvements in timeliness and accuracy of management
102 information -- which such a standard will facilitate.
104 This memo is the first in a set of three related and (logically)
105 ordered specifications:
107 1. SNMP SMI Datatypes [RFC2578] in XSD
108 2. SNMP MIB Structure [RFC2578] in XSD
109 3. SNMP Textual Conventions [RFC2579] in XSD
111 As a set, these documents define the XSD equivalent of SMIv2 to
112 encourage XML-based protocols to carry, and XML-based applications to
113 use, the information modeled in the SMIv2-compliant Management
114 Information Base ("The MIB").
116 This work will define XSD equivalents of the datatypes and data
117 structures [RFC2578]" and the textual conventions [RFC2579] defined
118 in the SMIv2 standard (STD58) to encourage efficient reuse of
119 existing (including future) MIB modules and instrumentation by XML-
120 based management protocols and applications.
122 The goal of fidelity to the SMIv2 standard (STD58), as specified in
123 the "Requirements" section below, is crucial to this effort to
124 leverage the established "rough consensus" for the precise data
125 modeling used in MIB modules, and to leverage existing "running code"
126 for implemented SMIv2 data models. This effort does not include
127 redesign of SMIv2 datatypes or data structures or textual conventions
128 to overcome known limitations -- that work can be pursued in other
129 efforts.
131 2. Conventions
133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
135 document are to be interpreted as described in RFC 2119 [RFC2119].
137 Sections requiring further editing are identified by [TODO] markers
138 in the text. Points requiring further WG research and discussion are
139 identified by [DISCUSS] markers in the text.
141 3. Requirements
143 R1. All SMI datatypes MUST have a corresponding XSD datatype.
144 R2. SMIv2 is the normative SMI for this document -- SMIv1 modules,
145 if encountered, MUST be converted (at least logically) in
146 accordance with Section 2.1, inclusive, of the "Coexistence" RFC
147 [RFC3584].
148 R3. The XSD datatype specified for a given SMI datatype MUST be able
149 to represent all valid values for that SMI datatype, and only
150 those values.
151 R4. The XSD datatype specified for a given SMI datatype MUST
152 represent any special encoding rules associated with that SMI
153 datatype.
154 R5. The XSD datatype specified for a given SMI datatype MUST include
155 any restrictions on values associated with the SMI datatype.
156 R6. The XSD datatype specified for a given SMI datatype MUST be the
157 most direct XSD datatype, with the most parsimonious
158 restrictions, which matches the foregoing requirements.
159 R7. The XML output produced as a result of meeting the foregoing
160 requirements SHOULD be the most direct from the perspective of
161 readability by humans.
163 [DISCUSS} Should any requirements be added, deleted, re-worded?
165 4. XSD for SMI Datatypes
167 This document concerns the SMI datatypes that are carried "on-the-
168 wire" -- i.e., have tag values defined in the SMI carried in varbinds
169 in SNMP PDUs -- between SNMP management applications and SNMP agents:
171 o INTEGER
172 o Integer32
173 o Unsigned32
174 o Counter32
175 o Gauge32
176 o TimeTicks
177 o Counter64
178 o OctetString
179 o Opague
180 o IpAddress
181 o ObjectIdentifier
183 The following should be considered a "notional" XSD file for now,
184 pending agreement on the actual datatype specifications. An
185 appropriate (official) targetNamespace must be designated (and
186 approved) and agreement must be reached on whether any additional XSD
187 content must be included (e.g., whether non-default values for
188 elementFormDefault or attributeFormDefault or schemaLocation, etc.,
189 need to be specified).
191
192
194
195
196 Mapping of SMIv2 datatypes from RFC 2578.
197
198
200
201
202
204
205
206
208
209
210
211
212
213
215
216
217
219
220
221
223
224
225
227
228
229
230
231
233
234
235
237
238
239
242
243
245
246
247
249
250
252
254 [TODO]Decisions needed on namespace issues [RFC3688]. One reviewer
255 suggested (until we have an RFC):
257 o "urn:ietf:params:xml:ns:opsawg:smi:v1.0" and
258 o "urn:ietf:params:xml:schema:draft-ietf-opsawg-smi-datatypes-in-
259 xsd-00.txt"
261 [DISCUSS] The "BITS" pseudo-type is treated as a Textual Convention
262 for the purpose of this document and, therefore, will be defined in
263 the associated "SNMP Textual Conventions in XSD" document.
265 [DISCUSS] Should we include value and pattern restriction language
266 from the SMI specifications in the XSD as either "documentation" or
267 "appInfo" "annotations" -- or keep the XSD as simple as possible and
268 merely refer the reader to the relevant sections of those
269 specifications?
271 5. Rationale
273 The XSD datatypes, including any specified restrictions, were chosen
274 based on fit with the requirements specified earlier in this
275 document, and with attention to simplicity while maintaining fidelity
276 to the SMI. Also, the "canonical representations" (i.e., refinements
277 of the "lexical representations") documented in the W3C XSD
278 specifications are assumed.
280 [DISCUSS] The use of "canonical representations" in the XSD specs
281 might merit review by others. This author's (Natale) understanding
282 might not be complete or correct.
284 5.1. Numeric Datatypes
286 All of the numeric XSD datatypes specified in the previous section --
287 INTEGER, Integer32, Unsigned32, Counter32, Counter, Gauge32, Gauge,
288 TimeTicks, and Counter64 -- comply with the relevant requirements:
290 o They cover all valid values for the corresponding SMI datatypes.
291 o They comply with the standard encoding rules associated with the
292 corresponding SMI datatypes.
293 o They inherently match the range restrictions associated with the
294 corresponding SMI datatypes.
295 o They are the most direct XSD datatype which exhibit the foregoing
296 characteristics relative to the corresponding SMI datatypes (which
297 is why no "restriction" statements are required in the XSD).
298 o The XML output produced from the canonical representation of these
299 XSD datatypes is also the most direct from the perspective of
300 readability by humans (i.e., no leading "+" sign and no leading
301 zeros).
303 5.2. OctetString
305 This XSD datatype corresponds to the SMI "OCTET STRING" datatype.
307 Several independent schemes for mapping SMI datatypes to XSD have
308 used the XSD "string" type to represent "OCTET STRING", but this
309 mapping does not conform to the requirements specified in this
310 document. Most notably, "string" cannot faithfully represent all
311 valid values (0 thru 255) that each octet in an "OCTET STRING" can
312 have -- or at least cannot do so in a way that provides for ready
313 human readability of the resulting XML output.
315 Consequently, the XSD datatype "hexBinary" is specified as the
316 standard mapping of the SMI "OCTET STRING" datatype. In hexBinary,
317 each octet is encoded as two hexadecimal digits; the canonical
318 representation limits the set of allowed hexadecimal digits to 0-9
319 and uppercase A-F.
321 The hexBinary representation of OCTET STRING complies with the
322 relevant requirements:
324 o It covers all valid values for the corresponding SMI datatype.
325 o It complies with the standard encoding rules associated with the
326 corresponding SMI datatype.
327 o With the "maxLength" restriction to 65535 octets, the XSD datatype
328 specification matches the restrictions associated with the
329 corresponding SMI datatype.
330 o It is the most direct XSD datatype which exhibits the foregoing
331 characteristics relative to the corresponding SMI datatype (which
332 must allow for any valid binary octet value).
333 o The XML output produced from the canonical representation of this
334 XSD datatype is not optimal with respect to readability by humans;
335 however, that is a consequence of the SMI datatype itself. Where
336 human readability is more of a concern, it is likely that the
337 actual MIB objects in question will be represented by textual
338 conventions which limit the set of values that will be included in
339 the OctetStrings and will, thus, bypass the hexBinary typing.
341 5.3. Opaque
343 The "hexBinary" XSD datatype is specified as the representation of
344 the SMI "Opague" datatype generally for the same reasons as
345 "hexBinary" is specified for the "OctetString" datatype.
347 o It covers all valid values for the corresponding SMI datatype.
348 o It complies with the standard encoding rules associated with the
349 corresponding SMI datatype.
351 o There are no restriction issues associated with using "hexBinary"
352 for "Opague".
353 o It is the most direct XSD datatype which exhibits the foregoing
354 characteristics relative to the corresponding SMI datatype (which
355 must allow for any valid binary octet value).
356 o The XML output produced from the canonical representation of this
357 XSD datatype is not optimal with respect to readability by humans;
358 however, that is a consequence of the SMI datatype itself.
359 Unmediated "Opague" data is intended for consumption by
360 applications, not humans.
362 [DISCUSS] Does the "Double-wrapping" aspect of "Opague" in the SMI
363 need to be accommodated in the XSD syntax?
365 5.4. IpAddress
367 The XSD "string" datatype is the natural choice to represent an
368 IpAddress as XML output. The "pattern" restriction applied in this
369 case results in a "dotted-decimal string of four values between "0"
370 and "255" separated by a period (".") character. This pattern also
371 precludes leading zeros.
373 [DISCUSS] Is the leading-zeros restriction appropriate? It is
374 specified here for the following reasons: Enhances human readability,
375 conforms to the most common way of representing IpAddress values, and
376 conforms to other selections in this document to avoid leading-zeros
377 on numerical output values.
379 [DISCUSS] Irrespective of the previous discussion topic, can the
380 pattern for IpAddress be simplified further (while still satisfying
381 the core requirements for allowable value sequences)?
383 5.5. ObjectIdentifier
385 This XSD datatype corresponds to the SMI "OBJECT IDENTIFIER"
386 datatype.
388 The XSD "string" datatype is also the natural choice to represent an
389 ObjectIdentifier as XML output, for the same reasons as for the
390 IpAddress choice. The "pattern" restriction applied in this case
391 results in a dotted- decimal string of up to 128 elements (referred
392 to as "sub-ids"), holding "Unsigned32" integer values.
394 Note that, while not mentioned in Sec. 7.1.3 of RFC 2578, due to
395 encoding rules the first two sub-ids of an "OBJECT IDENTIFIER" have
396 limited value ranges ([0-2] and [0-39], respectively), and the
397 minimum length of an "OBJECT IDENTIFIER" is two sub-ids (with a zero-
398 valued "OBJECT IDENTIFIER" represented as "0.0"). No explicit
399 "minLength" restriction (which would be "3" to allow for the minimum
400 of two sub-ids) is required, since the pattern itself enforces this
401 restriction.
403 [DISCUSS] The pattern specified for ObjectIdentifier attempts to
404 faithfully capture the restrictions mentioned above. Does it do so
405 correctly and is there a more efficient way of doing so?
407 6. Security Considerations
409 Security considerations for any given MIB are likely to be relevant
410 to any XSD/XML mapping of that MIB.
412 If and when proxies or gateways are developed to convey SNMP
413 management information from SNMP agents to XML-based management
414 applications via XSD/XML mapping of MIBs based on this specification
415 and its planned siblings, special care will need to be taken to
416 ensure that any SNMPv3 security mechanisms are supported in an
417 appropriate manner yet to be determined.
419 7. IANA Considerations
421 [DISCUSS] We will likely need namespace and location resources from
422 IANA...?.
424 8. Acknowledgements
426 Dave Harrington provided strategic and technical leadership to the
427 team which developed this particular specification. Yan Li did much
428 of the research into existing approaches that was used as a baseline
429 for the recommendations in this particular specification.
431 This document owes much to draft-romascanu-netconf-datatypes-xx and
432 to many other sources (including libsmi and group discussions on the
433 NETCONF mailing lists) developed by those who have researched and
434 published candidate mappings of SMI datatypes and textual conventions
435 to XSD.
437 [TODO] Add an "Informational References" section documenting prior
438 developmental publications and implementations.
440 Individuals who participated in earlier discussions of this topic at
441 IETF meetings and on IETF mailing lists include: Sharon Chisholm,
442 David Harrington, Ray Atarashi, Yoshifumi Atarashi, Bert Wijnen, Andy
443 Bierman, Randy Presuhn, Chris Lonvick, Eliot Lear, Avri Doria,
444 Juergen Schoenwaelder, Rob Ennes, Faye Ly and Andre Westerinen.
446 [TODO] Expand list of participants as appropriate.
448 9. Normative References
450 [RFC1155] Rose, M. and K. McCloghrie, "Structure and
451 identification of management information for TCP/
452 IP-based internets", STD 16, RFC 1155, May 1990.
454 [RFC2119] Bradner, s., "Key words for use in RFCs to
455 Indicate Requirement Levels", BCP 14, RFC 2119,
456 March 1997.
458 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
459 Schoenwaelder, Ed., "Structure of Management
460 Information Version 2 (SMIv2)", STD 58, RFC 2578,
461 April 1999.
463 [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
464 "Textual Conventions for SMIv2", STD 58, RFC 2579,
465 April 1999.
467 [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen,
468 "Coexistence between Version 1, Version 2, and
469 Version 3 of the Internet-standard Network
470 Management Framework", BCP 74, RFC 3584,
471 August 2003.
473 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81,
474 RFC 3688, January 2004.
476 [ref.XML] World Wide Web Consortium, "Extensible Markup
477 Language (XML) 1.0", W3C XML, February 1998,
478 .
480 [ref.XMLSchema] World Wide Web Consortium, "XML Schema Part 1:
481 Structures Second Edition", W3C XML Schema,
482 October 2004, .
484 [ref.XSDDatatype] World Wide Web Consortium, "XML Schema Part 2:
485 Datatypes Second Edition", W3C XML Schema,
486 October 2004, .
488 Appendix A. Open Issues
490 o Resolve all [TODO] items.
491 o Resolve all [DISCUSS] items.
493 Appendix B. Change Log
495 -00 Initial version
497 Authors' Addresses
499 Bob Natale (editor)
500 MITRE
501 7515 Colshire Dr
502 MS H405
503 McLean, VA 22102
504 USA
506 Phone: +1 703-983-2505
507 EMail: rnatale@mitre.org
509 Yan Li (editor)
510 Huawei Technologies
511 No.3 Xinxi Road, Shangdi Information Industry Base
512 Beijing, HaiDian District 100085
513 P.R.China
515 Phone: +86 10 8288 2008
516 EMail: liyan_77@huawei.com
518 Full Copyright Statement
520 Copyright (C) The IETF Trust (2008).
522 This document is subject to the rights, licenses and restrictions
523 contained in BCP 78, and except as set forth therein, the authors
524 retain all their rights.
526 This document and the information contained herein are provided on an
527 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
528 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
529 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
530 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
531 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
532 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
534 Intellectual Property
536 The IETF takes no position regarding the validity or scope of any
537 Intellectual Property Rights or other rights that might be claimed to
538 pertain to the implementation or use of the technology described in
539 this document or the extent to which any license under such rights
540 might or might not be available; nor does it represent that it has
541 made any independent effort to identify any such rights. Information
542 on the procedures with respect to rights in RFC documents can be
543 found in BCP 78 and BCP 79.
545 Copies of IPR disclosures made to the IETF Secretariat and any
546 assurances of licenses to be made available, or the result of an
547 attempt made to obtain a general license or permission for the use of
548 such proprietary rights by implementers or users of this
549 specification can be obtained from the IETF on-line IPR repository at
550 http://www.ietf.org/ipr.
552 The IETF invites any interested party to bring to its attention any
553 copyrights, patents or patent applications, or other proprietary
554 rights that may cover technology that may be required to implement
555 this standard. Please address the information to the IETF at
556 ietf-ipr@ietf.org.
558 Acknowledgement
560 Funding for the RFC Editor function is provided by the IETF
561 Administrative Support Activity (IASA).