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).