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.