idnits 2.17.1 draft-ietf-opsawg-smi-datatypes-in-xsd-04.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 639. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 650. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 657. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 663. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages 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 (October 29, 2008) is 5657 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: '0-4' is mentioned on line 271, but not defined == Missing Reference: '0-9' is mentioned on line 280, but not defined == Missing Reference: '0-5' is mentioned on line 271, but not defined == Missing Reference: '6-9' is mentioned on line 271, but not defined == Missing Reference: '3-9' is mentioned on line 272, but not defined == Missing Reference: '0-1' is mentioned on line 280, but not defined == Missing Reference: '1-3' is mentioned on line 280, but not defined == Unused Reference: 'RFC3688' is defined on line 544, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Natale 3 Internet-Draft MITRE 4 Intended status: Standards Track October 29, 2008 5 Expires: May 2, 2009 7 Expressing SNMP SMI Datatypes in XML Schema Definition Language 8 draft-ietf-opsawg-smi-datatypes-in-xsd-04.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 2, 2009. 35 Abstract 37 This memo (when approved as a standards-track RFC) defines the IETF 38 standard expression of Structure of Management Information (SMI) base 39 datatypes in Extensible Markup Language (XML) Schema Definition (XSD) 40 language. The primary objective of this memo is to enable the 41 production of XML documents that are as faithful to the SMI as 42 possible, using XSD as the validation mechanism. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 48 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 49 4. XSD for SMI Base Datatypes . . . . . . . . . . . . . . . . . . 7 50 5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 10 51 5.1. Numeric Datatypes . . . . . . . . . . . . . . . . . . . . 10 52 5.2. OctetString . . . . . . . . . . . . . . . . . . . . . . . 10 53 5.3. Opaque . . . . . . . . . . . . . . . . . . . . . . . . . . 11 54 5.4. IpAddress . . . . . . . . . . . . . . . . . . . . . . . . 12 55 5.5. ObjectIdentifier . . . . . . . . . . . . . . . . . . . . . 12 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 58 7.1. SMI Base Datatypes Namespace Registration . . . . . . . . 15 59 7.2. SMI Base Datatypes Schema Registration . . . . . . . . . . 15 60 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 62 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 63 9.2. Informational References . . . . . . . . . . . . . . . . . 17 64 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 18 65 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 19 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 67 Intellectual Property and Copyright Statements . . . . . . . . . . 21 69 1. Introduction 71 Numerous uses exist -- both within and outside the traditional IETF 72 network management community -- for the expression of management 73 information described in and accessible via SMI Management 74 Information Base (MIB) modules as XML documents [ref.XML]. For 75 example, XML-based management applications which want to incorporate 76 MIB modules as data models and/or to access MIB module 77 instrumentation via gateways to SNMP agents will benefit from an IETF 78 standard mapping of SMI datatypes and structures to XML documents via 79 XSD. 81 MIB data models are described using SMIv2 [RFC2578] and, for legacy 82 MIBs, SMIv1 [RFC1155]. MIB data is conveyed in variable bindings 83 ("varbinds") within protocol data units (PDUs) within SNMP messages 84 using the base/primitive datatypes defined in the SMI. 86 The SMI allows for creation of derivative datatypes, termed "textual 87 conventions" ("TCs"), each of which has a unique name, a syntax which 88 is or refines a primitive SMI datatype, and relatively precise 89 application-level semantics. TCs are used principally to facilitate 90 correct application-level handling of MIB data and for the 91 convenience of humans reading MIB modules and appropriately rendered 92 MIB data output. Values in varbinds corresponding to MIB objects 93 with TC syntaxes are always encoded as the primitive SMI datatype 94 underlying the TC syntax. Thus, the XSD mappings defined in this 95 memo will support MIB objects with TC syntax as well as those with 96 base SMI syntax. 98 Various independent schemes have been devised for expressing the SMI 99 datatypes and TCs in XSD [ref.XMLSchema]. These schemes have 100 exhibited a degree of commonality (especially concerning the numeric 101 SMI datatypes), but also sufficient differences (especially 102 concerning the non-numeric SMI datatypes) to preclude general 103 interoperability. 105 The primary purpose of this memo is to define a standard expression 106 of SMI base datatypes in XSD to ensure uniformity and general 107 interoperability in this respect. Internet operators, management 108 tool developers, and users will benefit from the wider selection of 109 management tools and the greater degree of unified management -- with 110 attendant improvements in timeliness and accuracy of management 111 information -- which such a standard will facilitate. 113 This memo is the first in a set of three related and (logically) 114 ordered specifications: 116 1. SMI Base Datatypes [RFC2578] in XSD 118 2. SMI MIB Structure [RFC2578] in XSD 120 3. SNMP Textual Conventions [RFC2579] in XSD 122 As a set, these documents define the XSD equivalent of SMIv2 to 123 encourage XML-based protocols to carry, and XML-based applications to 124 use, the information modeled in SMIv2-compliant MIB modules. 126 This work defines XSD equivalents of the datatypes and data 127 structures [RFC2578] and the textual conventions [RFC2579] defined in 128 the SMIv2 standard (STD58) to encourage efficient reuse of existing 129 (including future) MIB modules and instrumentation by XML-based 130 management protocols and applications. 132 The goal of fidelity to the SMIv2 standard (STD58), as specified in 133 the "Requirements" section below, is crucial to this effort to 134 leverage the established "rough consensus" for the precise data 135 modeling used in MIB modules, and to leverage existing "running code" 136 for implemented SMIv2 data models. This effort does not include 137 redesign of SMIv2 datatypes or data structures or textual conventions 138 to overcome known limitations -- that work can be pursued in other 139 efforts. 141 2. Conventions 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in RFC 2119 [RFC2119]. 147 3. Requirements 149 The following set of requirements is intended to produce XML 150 documents which can be validated via the XSD defined in this 151 specification to faithfully represent values carried "on-the-wire" in 152 SNMP PDUs as defined by the SMI: 154 R1. All SMI base datatypes MUST have a corresponding XSD datatype. 156 R2. SMIv2 is the normative SMI for this document -- SMIv1 modules, 157 if encountered, MUST be converted (at least logically) in 158 accordance with Section 2.1, inclusive, of the "Coexistence" RFC 159 [RFC3584]. 161 R3. The XSD datatype specified for a given SMI datatype MUST be able 162 to represent all valid values for that SMI datatype. 164 R4. The XSD datatype specified for a given SMI datatype MUST 165 represent any special encoding rules associated with that SMI 166 datatype. 168 R5. The XSD datatype specified for a given SMI datatype MUST include 169 any restrictions on values associated with the SMI datatype. 171 R6. The XSD datatype specified for a given SMI datatype MUST be the 172 most direct XSD datatype, with the most parsimonious 173 restrictions, which matches the foregoing requirements. 175 R7. The XML output produced as a result of meeting the foregoing 176 requirements SHOULD be the most direct (i.e., avoiding 177 superfluous "decoration") from the perspective of readability by 178 humans. 180 4. XSD for SMI Base Datatypes 182 This document concerns only the SMI base datatypes -- i.e., the 183 eleven "ObjectSyntax" datatypes defined in RFC2578. These datatypes 184 -- via tag values defined in the SMI to identify them in varbinds -- 185 constrain values carried "on-the-wire" in SNMP PDUs between SNMP 186 management applications and SNMP agents: 188 o INTEGER, Integer32 190 o Unsigned32, Gauge32 192 o Counter32 194 o TimeTicks 196 o Counter64 198 o OctetString 200 o Opague 202 o IpAddress 204 o ObjectIdentifier 206 The "BITS" pseudo-type (also referred to as a "construct" in RFC2578) 207 is treated as a Textual Convention for the purpose of this document 208 and, therefore, will be defined in the "SNMP Textual Conventions in 209 XSD" document. 211 BEGIN 213 214 221 222 223 Mapping of SMIv2 base datatypes from RFC 2578. 224 225 226 227 228 230 231 232 234 235 236 238 239 240 242 243 244 246 247 248 250 251 252 254 255 256 257 258 260 261 262 264 265 266 275 277 278 279 283 284 286 287 END 289 5. Rationale 291 The XSD datatypes, including any specified restrictions, were chosen 292 based on fit with the requirements specified earlier in this 293 document, and with attention to simplicity while maintaining fidelity 294 to the SMI. Also, the "canonical representations" (i.e., refinements 295 of the "lexical representations") documented in the W3C XSD 296 specifications are assumed. 298 5.1. Numeric Datatypes 300 All of the numeric XSD datatypes specified in the previous section -- 301 INTEGER, Integer32, Unsigned32, Gauge32, Counter32, TimeTicks, and 302 Counter64 -- comply with the relevant requirements 304 o They cover all valid values for the corresponding SMI datatypes. 306 o They comply with the standard encoding rules associated with the 307 corresponding SMI datatypes. 309 o They inherently match the range restrictions associated with the 310 corresponding SMI datatypes. 312 o They are the most direct XSD datatypes which exhibit the foregoing 313 characteristics relative to the corresponding SMI datatypes (which 314 is why no "restriction" statements -- other than the "base" XSD 315 type -- are required in the XSD). 317 o The XML output produced from the canonical representation of these 318 XSD datatypes is also the most direct from the perspective of 319 readability by humans (i.e., no leading "+" sign and no leading 320 zeros). 322 Special note to application developers: Compliance with this schema 323 in an otherwise correct translation from raw ("on-the-wire" 324 representation) SNMP MIB data produces values that are faithful to 325 the original. However, the Gauge32, Counter32, Counter64, and 326 TimeTicks datatypes have special application semantics that must be 327 considered when using their raw values for anything other than 328 display, printing, storage, or transmission of the literal value. 329 RFC 2578 provides the necessary details. 331 5.2. OctetString 333 This XSD datatype corresponds to the SMI "OCTET STRING" datatype. 335 Several independent schemes for mapping SMI datatypes to XSD have 336 used the XSD "string" type to represent "OCTET STRING", but this 337 mapping does not conform to the requirements specified in this 338 document. Most notably, "string" cannot faithfully represent all 339 valid values (0 thru 255) that each octet in an "OCTET STRING" can 340 have -- or at least cannot do so in a way that provides for ready 341 human readability of the resulting XML output. 343 Consequently, the XSD datatype "hexBinary" is specified as the 344 standard mapping of the SMI "OCTET STRING" datatype. In hexBinary, 345 each octet is encoded as two hexadecimal digits; the canonical 346 representation limits the set of allowed hexadecimal digits to 0-9 347 and uppercase A-F. 349 The hexBinary representation of OCTET STRING complies with the 350 relevant requirements: 352 o It covers all valid values for the corresponding SMI datatype. 354 o It complies with the standard encoding rules associated with the 355 corresponding SMI datatype. 357 o With the "maxLength" restriction to 65535 octets, the XSD datatype 358 specification matches the restrictions associated with the 359 corresponding SMI datatype. 361 o It is the most direct XSD datatype which exhibits the foregoing 362 characteristics relative to the corresponding SMI datatype (which 363 must allow for any valid binary octet value). 365 o The XML output produced from the canonical representation of this 366 XSD datatype is not optimal with respect to readability by humans; 367 however, that is a consequence of the SMI datatype itself. Where 368 human readability is more of a concern, it is likely that the 369 actual MIB objects in question will be represented by textual 370 conventions which limit the set of values that will be included in 371 the OctetStrings and will, thus, bypass the hexBinary typing. 373 5.3. Opaque 375 The "hexBinary" XSD datatype is specified as the representation of 376 the SMI "Opague" datatype generally for the same reasons as 377 "hexBinary" is specified for the "OctetString" datatype: 379 o It covers all valid values for the corresponding SMI datatype. 381 o It complies with the standard encoding rules associated with the 382 corresponding SMI datatype. 384 o There are no restriction issues associated with using "hexBinary" 385 for "Opague". 387 o It is the most direct XSD datatype which exhibits the foregoing 388 characteristics relative to the corresponding SMI datatype (which 389 must allow for any valid binary octet value). 391 o The XML output produced from the canonical representation of this 392 XSD datatype is not optimal with respect to readability by humans; 393 however, that is a consequence of the SMI datatype itself. 394 Unmediated "Opague" data is intended for consumption by 395 applications, not humans. 397 5.4. IpAddress 399 The XSD "string" datatype is the natural choice to represent an 400 IpAddress as XML output. The "pattern" restriction applied in this 401 case results in a "dotted-decimal string of four values between "0" 402 and "255" separated by a period (".") character. This pattern also 403 precludes leading zeros. 405 5.5. ObjectIdentifier 407 This XSD datatype corresponds to the SMI "OBJECT IDENTIFIER" 408 datatype. 410 The XSD "string" datatype is also the natural choice to represent an 411 ObjectIdentifier as XML output, for the same reasons as for the 412 IpAddress choice. The "pattern" restriction applied in this case 413 results in a dotted-decimal string of up to 128 elements (referred to 414 as "sub-ids"), each holding an "Unsigned32" integer value. 416 Note that, while not mentioned in Sec. 7.1.3 of RFC 2578, due to the 417 use of Abstract Syntax Notation One (ASN.1) Basic Encoding Rules 418 (BER) the first two components of an "OBJECT IDENTIFIER" have limited 419 value ranges and are encoded into a single sub-id value [Steedman]. 420 The ASN.1/BER standards specify that the numerical value of the first 421 sub-identifier is derived from the values of the first two object 422 identifier components in the object identifier value being encoded, 423 using the formula: (X*40) + Y, where X is the value of the first 424 object identifier component and Y is the value of the second object 425 identifier component. This packing of the first two object 426 identifier components recognizes that only three values are allocated 427 from the root node, and at most 39 subsequent values from nodes 428 reached by X = 0 and X = 1. The minimum length of an "OBJECT 429 IDENTIFIER" is two sub-ids (with a zero-valued "OBJECT IDENTIFIER" 430 represented as "0.0"). No explicit "minLength" restriction (which 431 would be "3" to allow for the minimum of two sub-ids and a single 432 separating dot) is required, since the pattern itself enforces this 433 restriction. 435 6. Security Considerations 437 Security considerations for any given SMI MIB module are likely to be 438 relevant to any XSD/XML mapping of that MIB module; however, the 439 mapping defined in this document does not itself introduce any new 440 security considerations. 442 If and when proxies or gateways are developed to convey SNMP 443 management information from SNMP agents to XML-based management 444 applications via XSD/XML mapping of MIB modules based on this 445 specification and its planned siblings, special care will need to be 446 taken to ensure that all applicable SNMP security mechanisms are 447 supported in an appropriate manner yet to be determined. 449 7. IANA Considerations 451 In accordance with RFC 3688, we will register namespaces and schemas 452 for all three documents in this set with the IANA XML Registry. 453 These entries -- corresponding to this base datatypes document and 454 the future textual conventions and MIB structure documents -- will be 455 as follows: 457 o urn:ietf:params:xml:ns:opsawg:smi:base:[version_id] 459 o urn:ietf:params:xml:schema:opsawg:smi:base:[version_id] 461 o urn:ietf:params:xml:ns:opsawg:smi:tc:[version_id] 463 o urn:ietf:params:xml:schema:opsawg:smi:tc:[version_id] 465 o urn:ietf:params:xml:ns:opsawg:smi:structure:[version_id] 467 o urn:ietf:params:xml:schema:opsawg:smi:structure:[version_id] 469 The following sub-sections refer to the present document only. 471 7.1. SMI Base Datatypes Namespace Registration 473 This document registers a URI for the SMI Base Datatypes XML 474 namespace in the IETF XML registry. Following the format in RFC 475 3688, IANA has made the following registration: 477 URI: urn:ietf:params:xml:ns:opsawg:smi:base:1.0 479 Registration Contact: The IESG. 481 XML: N/A, the requested URI is an XML namespace. 483 7.2. SMI Base Datatypes Schema Registration 485 This document registers a URI for the SMI Base Datatypes XML schema 486 in the IETF XML registry. Following the format in RFC 3688, IANA has 487 made the following registration: 489 URI: urn:ietf:params:xml:schema:opsawg:smi:base:1.0 491 Registration Contact: The IESG. 493 XML: Section 4 of this document. 495 8. Acknowledgements 497 Dave Harrington provided strategic and technical leadership to the 498 team which developed this particular specification. Yan Li did much 499 of the research into existing approaches that was used as a baseline 500 for the recommendations in this particular specification. 502 This document owes much to draft-romascanu-netconf-datatypes-xx and 503 to many other sources (including libsmi and group discussions on the 504 NETCONF mailing lists) developed by those who have researched and 505 published candidate mappings of SMI datatypes and textual conventions 506 to XSD. 508 Individuals who participated in various discussions of this topic at 509 IETF meetings and on IETF mailing lists include: Ray Atarashi, 510 Yoshifumi Atarashi, Andy Bierman, Sharon Chisholm, Avri Doria, Mark 511 Ellison, Rob Ennes, David Harrington, Alfred HInes, Eliot Lear, Chris 512 Lonvick, Faye Ly, Randy Presuhn, Juergen Schoenwaelder, Andre 513 Westerinen, and Bert Wijnen. 515 (Others who have been inadvertently omitted from this list should 516 notify the editor.) 518 9. References 520 9.1. Normative References 522 [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification 523 of management information for TCP/IP-based internets", 524 STD 16, RFC 1155, May 1990. 526 [RFC2119] Bradner, s., "Key words for use in RFCs to Indicate 527 Requirement Levels", BCP 14, RFC 2119, March 1997. 529 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 530 Schoenwaelder, Ed., "Structure of Management Information 531 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 533 [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 534 "Textual Conventions for SMIv2", STD 58, RFC 2579, 535 April 1999. 537 9.2. Informational References 539 [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, 540 "Coexistence between Version 1, Version 2, and Version 3 541 of the Internet-standard Network Management Framework", 542 BCP 74, RFC 3584, August 2003. 544 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 545 January 2004. 547 [Steedman] 548 Steedman, D., "ASN.1: The Tutorial and Reference". 550 [ref.XML] World Wide Web Consortium, "Extensible Markup Language 551 (XML) 1.0", W3C XML, February 1998, 552 . 554 [ref.XMLSchema] 555 World Wide Web Consortium, "XML Schema Part 1: Structures 556 Second Edition", W3C XML Schema, October 2004, 557 . 559 [ref.XSDDatatype] 560 World Wide Web Consortium, "XML Schema Part 2: Datatypes 561 Second Edition", W3C XML Schema, October 2004, 562 . 564 Appendix A. Open Issues 566 o Confirm IANA XML registration values and process. 568 Appendix B. Change Log 570 o -01 version: 572 * Incorporated mailing list comments on -00 version from Juergen 573 Schoenwaelder 575 * Incorporated mailing list comments on -00 version from David 576 Harrington 578 o -02 version: 580 * Fixed ObjectIdentifier pattern per correction from Juergen 581 Schoenwaelder, and text in sec. 5.5 adjusted accordingly. 583 * Moved non-normative references to Informational section per 584 David Harrington 586 * Tightened wording in to "XSD for SMI Datatypes" section per 587 Mark Ellison 589 * Added a note about Gauge32 and Counter32 application semantics 590 to the "Rationale" section per Mark Ellison 592 * Security section wording tightened per David Harrington 594 * The IANA Considerations section completed--will need 595 adjustment. 597 * Acknowledgments entries expanded and alphabetized 599 o -03 version: 601 * Corrected "ten" to "eleven" in opening sentence of "XSD for SMI 602 Datatypes" section. 604 * Removed conditional wording that previously prefaced the XSD 605 itself. 607 o -04 version: 609 * Relatively minor text fix-ups in various places, mainly in 610 response to comments on the -03 version from Mark Ellison, 611 Alfred HInes, Juergen Schoenwaelder, and David Harrington. 613 Author's Address 615 Bob Natale 616 MITRE 617 7515 Colshire Dr 618 MS H405 619 McLean, VA 22102 620 USA 622 Phone: +1 703-983-2505 623 Email: rnatale@mitre.org 625 Full Copyright Statement 627 Copyright (C) The IETF Trust (2008). 629 This document is subject to the rights, licenses and restrictions 630 contained in BCP 78, and except as set forth therein, the authors 631 retain all their rights. 633 This document and the information contained herein are provided on an 634 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 635 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 636 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 637 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 638 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 639 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 641 Intellectual Property 643 The IETF takes no position regarding the validity or scope of any 644 Intellectual Property Rights or other rights that might be claimed to 645 pertain to the implementation or use of the technology described in 646 this document or the extent to which any license under such rights 647 might or might not be available; nor does it represent that it has 648 made any independent effort to identify any such rights. Information 649 on the procedures with respect to rights in RFC documents can be 650 found in BCP 78 and BCP 79. 652 Copies of IPR disclosures made to the IETF Secretariat and any 653 assurances of licenses to be made available, or the result of an 654 attempt made to obtain a general license or permission for the use of 655 such proprietary rights by implementers or users of this 656 specification can be obtained from the IETF on-line IPR repository at 657 http://www.ietf.org/ipr. 659 The IETF invites any interested party to bring to its attention any 660 copyrights, patents or patent applications, or other proprietary 661 rights that may cover technology that may be required to implement 662 this standard. Please address the information to the IETF at 663 ietf-ipr@ietf.org.