idnits 2.17.1 draft-ietf-ipoib-ibmib-tc-mib-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 22 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (January 2003) is 7772 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: '23-16' is mentioned on line 339, but not defined == Missing Reference: '15-8' is mentioned on line 339, but not defined == Missing Reference: '7-0' is mentioned on line 339, but not defined == Missing Reference: '95-88' is mentioned on line 335, but not defined == Missing Reference: '87-80' is mentioned on line 335, but not defined == Missing Reference: '79-72' is mentioned on line 335, but not defined == Missing Reference: '71-64' is mentioned on line 335, but not defined == Missing Reference: '63-56' is mentioned on line 337, but not defined == Missing Reference: '55-48' is mentioned on line 337, but not defined == Missing Reference: '47-40' is mentioned on line 337, but not defined == Missing Reference: '39-32' is mentioned on line 337, but not defined == Missing Reference: '31-24' is mentioned on line 339, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'INFINIV1' ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Informational RFC: RFC 1215 ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2570 (Obsoleted by RFC 3410) ** Obsolete normative reference: RFC 2571 (Obsoleted by RFC 3411) ** Obsolete normative reference: RFC 2572 (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2573 (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2574 (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 2575 (Obsoleted by RFC 3415) Summary: 17 errors (**), 0 flaws (~~), 13 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Sean Harnedy 2 InfiniSwitch Corp. 3 Expiration Date: July 2003 January 2003 5 Definition of Textual Conventions 6 and OBJECT-IDENTITIES for 7 IP Over InfiniBand (IPOVERIB) Management 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC 2026. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Distribution of this document is unlimited. Please send comments to 31 the IP Over IB (ipoib) Working Group, ipoverib@ietf.org. 33 1. Abstract 35 This memo describes Textual Conventions and OBJECT-IDENTITIES 36 for use in definitions of management information for IP Over 37 InfiniBand (IPOVERIB) networks. 39 Table of Contents 41 2. Introduction ............................................... 2 42 3. The SNMP Management Framework .............................. 2 43 4. IPOVERIB Textual Conventions MIB Definitions ............... 3 44 5. Security Considerations .................................... 8 45 6. Acknowledgments ............................................ 8 46 7. Author's Address ........................................... 9 47 8. References ................................................. 9 48 9. Intellectual Property Notice ............................... 10 49 10. Full Copyright Statement ................................... 11 51 2. Introduction 53 This memo defines a portion of the Management Information Base (MIB) 54 for use with network management protocols in the Internet community. 55 In particular, it defines Textual Conventions used in IETF IPOVERIB 56 and IPOVERIB-related MIBs. 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in RFC 2119 [RFC2119]. 62 For an introduction to the concepts of InfiniBand, see [INFINIV1]. 64 3. The SNMP Management Framework 66 The SNMP Management Framework presently consists of five 67 major components: 69 - An overall architecture, described in RFC 2571 [RFC2571]. 71 - Mechanisms for describing and naming objects and events 72 for the purpose of management. The first version of 73 this Structure of Management Information (SMI) is 74 called SMIv1 and described in STD 16, RFC 1155 75 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 76 [RFC1215]. The second version, called SMIv2, is 77 described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 78 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 80 - Message protocols for transferring management 81 information. The first version of the SNMP message 82 protocol is called SNMPv1 and described in STD 15, RFC 83 1157 [RFC1157]. A second version of the SNMP message 84 protocol, which is not an Internet standards track 85 protocol, is called SNMPv2c and described in RFC 1901 86 [RFC1901] and RFC 1906 [RFC1906]. The third version of 87 the message protocol is called SNMPv3 and described in 88 RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 89 [RFC2574]. 91 - Protocol operations for accessing management 92 information. The first set of protocol operations and 93 associated PDU formats is described in STD 15, RFC 1157 94 [RFC1157]. A second set of protocol operations and 95 associated PDU formats is described in RFC 1905 [RFC1905]. 97 - A set of fundamental applications described in RFC 2573 98 [RFC2573] and the view-based access control mechanism 99 described in RFC 2575 [RFC2575]. 101 A more detailed introduction to the current SNMP Management 102 Framework can be found in RFC 2570 [RFC2570]. 104 Managed objects are accessed via a virtual information 105 store, termed the Management Information Base or MIB. 106 Objects in the MIB are defined using the mechanisms defined 107 in the SMI. 109 This memo specifies a MIB module that is compliant to the 110 SMIv2. A MIB conforming to the SMIv1 can be produced 111 through the appropriate translations. The resulting 112 translated MIB must be semantically equivalent, except 113 where objects or events are omitted because no translation 114 is possible (e.g., use of Counter64). Some machine readable 115 information in SMIv2 will be converted into textual 116 descriptions in SMIv1 during the translation process. 117 However, this loss of machine readable information is not 118 considered to change the semantics of the MIB. 120 4. IPOVERIB Textual Conventions MIB Definitions 122 IB-TC-MIB DEFINITIONS ::= BEGIN 124 IMPORTS 125 experimental, MODULE-IDENTITY, 126 Integer32 FROM SNMPv2-SMI 127 TEXTUAL-CONVENTION FROM SNMPv2-TC; 129 ibTcMIB MODULE-IDENTITY 130 LAST-UPDATED "200301011200Z" -- 1 January 2003 12:00:00 GMT 131 ORGANIZATION 132 "IETF IP over IB Working Group 133 Email: ipoverib@ietf.org" 134 CONTACT-INFO 135 "Sean Harnedy 136 Postal: InfiniSwitch Corporation 137 134 Flanders Road 138 Westborough, MA 01581 139 United States 140 Tel: 508 599 6300 141 Email: sharnedy@infiniswitch.com 142 " 143 DESCRIPTION 144 "This MIB contains managed object definitions and textual 145 conventions for managing InfiniBand devices that support 146 the IP Over InfiniBand (IPOIB) protocols and procedures." 148 -- Revision history. 150 REVISION 151 "200301011200Z" -- 1 January 2003 12:00:00 GMT 152 DESCRIPTION 153 "Updated for IBTA Specification Version 1.1." 155 REVISION 156 "200205101200Z" -- 10 May 2002 12:00:00 GMT 157 DESCRIPTION 158 "Deleted ibPortTC. Changed ibPhysicalPort to IbDataPort 159 and changed range to (1..254) to match IB port numbering. 160 Changed IbValidPhysicalPort to IbDataPortAndInvalid and 161 changed range to (1..255). Corrected definition of 162 IbMulticastLid to end at 65536. Added 163 IbIpoibClientIdentifier TC." 164 REVISION 165 "200111131200Z" -- 13 November 2001 12:00:00 GMT 166 DESCRIPTION 167 "Separated TCs from InfiniBand Interface MIB. Added IANA 168 experimental number for MIB. Made TC names more consistent. 169 Added Intellectual Property and Acknowledgment sections." 170 REVISION 171 "200110031200Z" -- 3 October 2001 12:00:00 GMT 172 DESCRIPTION 173 "Initial version of this MIB." 174 ::= { infinibandMIB 1 } 176 -- The IANA has defined the InfiniBand MIB on the experimental branch. 178 infinibandMIB OBJECT IDENTIFIER ::= { experimental 117 } 180 -- Textual Conventions. 182 IbDataPort ::= TEXTUAL-CONVENTION 183 DISPLAY-HINT "d" 184 STATUS current 185 DESCRIPTION 186 "Identifies a physical IB Port. The IBA defines a maximum of 254 187 physical ports numbered Port 1 to Port 254. A port is the location 188 on a Channel Adapter, IB Router, or IB Switch to which a link is 189 connected. If a device has N ports, the ports are always numbered 190 from 1 to N. Note: this definition does NOT include logical Port 0 191 that is reserved for IB management packets." 192 REFERENCE 193 "InfiniBand Architecture Release 1.1 Vol 1. [INFINIV1] 194 Section 18.2.4.1 (C18-10.a1) for switches, Section 17.2.1.3 195 (C17-7.a1) for Channel Adapters, and Section 19.2.4.2 for 196 routers." 197 SYNTAX Integer32 (1..254) 199 IbDataPortAndInvalid ::= TEXTUAL-CONVENTION 200 STATUS current 201 DESCRIPTION 202 "Identifies a physical IB port plus an invalid port number. 203 Note: this definition does NOT include logical Port 0 204 that is reserved for IB management packets." 205 REFERENCE 206 "InfiniBand Architecture Release 1.1 Vol 1. [INFINIV1] 207 Section 18.2.4.1 (C18-10.a1) for switches, Section 17.2.1.3 208 (C17-7.a1) for Channel Adapters, and Section 19.2.4.2 for 209 routers." 210 SYNTAX Integer32 (1..255) 212 IbVirtualLane ::= TEXTUAL-CONVENTION 213 DISPLAY-HINT "d" 214 STATUS current 215 DESCRIPTION 216 "Identifies a Virtual Lane (VL) instance on a given interface 217 (i.e., IB port). VLs provide a mechanism for creating multiple 218 virtual links within a physical link. IBA defines VL 0 through 219 VL 14 for data and VL 15 exclusively for Subnet Management. 220 The actual data VLs that a port uses are configured by the 221 Subnet Manager. The default data VL is always VL 0. Note: this 222 definition is +1-based." 223 REFERENCE 224 "InfiniBand Architecture Release 1.1 Vol 1. [INFINIV1] 225 Section 3.5.7." 226 SYNTAX Integer32 (1..16) 228 IbDataVirtualLane ::= TEXTUAL-CONVENTION 229 DISPLAY-HINT "d" 230 STATUS current 231 DESCRIPTION 232 "Identifies a Data Virtual Lane instance on a given interface 233 (i.e., IB port). This TC definition excludes the management 234 Virtual Lane (VL 15). The actual data VLs that a port uses 235 are configured by the Subnet Manager. The default data VL is 236 always the first VL (VL 0). Note: this definition is +1-based." 237 REFERENCE 238 "InfiniBand Architecture Release 1.1 Vol 1. [INFINIV1] 239 Section 3.5.7." 240 SYNTAX Integer32 (1..15) 242 IbDlid ::= TEXTUAL-CONVENTION 243 DISPLAY-HINT "d" 244 STATUS current 245 DESCRIPTION 246 "Identifies the Destination Local Identifier (DLID). The IBA 247 defines LID 0 as reserved and valid LID values from 1 to 65535. 248 LID 65535 is defined as a permissive DLID. 250 This value is stored in IBA defined bit order, that is, the high- 251 order bit of the Local Identifier byte 0 is positioned as the 252 high-order bit of the first byte of the integer representation. 253 Note: this definition is +1-based." 254 REFERENCE 255 "InfiniBand Architecture Release 1.1 Vol 1. [INFINIV1] 256 Section 4.1.3." 257 SYNTAX Integer32 (1..65536) 259 IbUnicastLid ::= TEXTUAL-CONVENTION 260 DISPLAY-HINT "d" 261 STATUS current 262 DESCRIPTION 263 "Identifies a Unicast LID. Value is stored in IBA defined bit 264 order, that is, the high-order bit of the Local Identifier 265 byte 0 is positioned as the high-order bit of the first byte 266 of the integer representation. 267 Note: this definition is +1-based." 268 REFERENCE 269 "InfiniBand Architecture Release 1.1 Vol 1. [INFINIV1] 270 Section 4.1.3." 271 SYNTAX Integer32 (1..49152) 273 IbMulticastLid ::= TEXTUAL-CONVENTION 274 DISPLAY-HINT "d" 275 STATUS current 276 DESCRIPTION 277 "Identifies a Multicast LID. Value is stored in IBA defined 278 bit order, that is, the high-order bit of the Local 279 Identifier byte 0 is positioned as the high-order bit of the 280 first byte of the integer representation. 281 Note: this definition is +1-based." 282 REFERENCE 283 "InfiniBand Architecture Release 1.1 Vol 1. [INFINIV1]. 284 Section 4.1.3." 285 SYNTAX Integer32 (49153..65536) 287 IbGuid ::= TEXTUAL-CONVENTION 288 DISPLAY-HINT "1x:" 289 STATUS current 290 DESCRIPTION 291 "Globally Unique Identifier (GUID) is a number that uniquely 292 identifies a IB device or component. It is a compliant EUI-64 293 identifier for channel adapters, routers, and switches. 294 This 64-bit value is created by concatenating a 24-bit 295 company ID value and a 40-bit extension. The IEEE Registration 296 Authority assigns the company ID. The extension ID is assigned 297 by the particular company. Therefore, each HCA, TCA, switch, and 298 router shall be assigned an EUI-64 GUID by the manufacturer." 299 REFERENCE 300 "InfiniBand Architecture Release 1.1 Vol 1. [INFINIV1] 301 Section 4.1." 302 SYNTAX OCTET STRING (SIZE(8)) 304 IbSmPortList ::= TEXTUAL-CONVENTION 305 STATUS current 306 DESCRIPTION 307 "Each bit mapping within this value specifies a port presence 308 within the managed IB device. This definition includes bit0 309 as IB Port 0, the logical port used exclusively for management 310 packets. Valid data port mappings are from bit1 to bit254. Bit255 311 is invalid." 312 REFERENCE 313 "InfiniBand Architecture Release 1.1 Vol 1. [INFINIV1] 314 Section 18.2.4.1 (C18-10.a1) for switches, Section 17.2.1.3 315 (C17-7.a1) for Channel Adapters, and Section 19.2.4.2 for 316 routers." 317 SYNTAX OCTET STRING (SIZE(32)) 319 IbIpoibClientIdentifier ::= TEXTUAL-CONVENTION 320 STATUS current 321 DESCRIPTION 322 "The IPOIB Client Identifier uniquely identifies an IPOIB link 323 layer address associated with the InfiniBand port. It comprises 324 three fields. 326 1. reserved 327 2. Queue Pair Number field (QPN) 328 3. Global Identifier (GID) 330 +................+................+................+...............+ 331 |20: (reserved) |19: QPN[23-16] |18: QPN[15-8] |17: QPN[7-0] | 332 +................+................+................+...............+ 333 |16: GID[127-120]|15: GID[119-112]|14: GID[111-104]|13: GID[103-96]| 334 +................+................+................+...............+ 335 |12: GID[95-88] |11: GID[87-80] |10: GID[79-72] |9 GID[71-64] | 336 +................+................+................+...............+ 337 |8: GID[63-56] |7: GID[55-48] |6: GID[47-40] |5: GID[39-32] | 338 +................+................+................+...............+ 339 |4: GID[31-24] |3: GID[23-16] |2: GID[15-8] |1: GID[7-0] | 340 +................+................+................+...............+ 342 The reserved field is octet 20. It is reserved for future use. 343 These bits MUST be set to zero. 345 The Queue Pair Number field is a 3 octet field (octets 17, 18, & 19) 346 that identifies the destination queue pair. Note: The reserved field 347 and the QPN field are collectively referred to as the interface-id. 348 If an IPOIB interface has only 1 GID associated with it, the 349 interface-id MAY contain all zeroes. 351 The Global Identifier field is a 16 octet field (octets 1 through 16) 352 that is formed by the combination of the IB subnet prefix and the 353 port's GUID. It is unique in the InfiniBand fabric. NOTE: An IPOIB 354 interface may have more than 1 GID associated with it." 355 SYNTAX OCTET STRING (SIZE(20)) 357 END 359 5. Security Considerations 361 This memo defines textual conventions and object identities for use 362 in IPOVERIB MIB modules. Security issues for these MIB modules are 363 addressed in the memos defining those modules. 365 6. Acknowledgments 367 This MIB module was updated based on the original work done by Bill 368 Anderson and Bill Strahm. 370 7. Author's Address 372 Sean Harnedy 373 InfiniSwitch Corporation 374 134 Flanders Road 375 Westborough, MA 01581 376 Phone: +1-508-599-6388 377 Email: sharnedy@infiniswitch.com 379 8. References 381 [INFINIV1] InfiniBand Architecture Specification Volume 1, 382 Release 1.1, November 6, 2002. 384 [RFC1155] Rose, M., and K. McCloghrie, "Structure and 385 Identification of Management Information for 386 TCP/IP-based Internets", STD 16, RFC 1155, 387 May 1990. 389 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. 390 Davin, "Simple Network Management Protocol", 391 STD 15, RFC 1157, May 1990. 393 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB 394 Definitions", STD 16, RFC 1212, March 1991. 396 [RFC1215] M. Rose, "A Convention for Defining Traps 397 for use with the SNMP", RFC 1215, March 398 1991. 400 [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. 401 Waldbusser, "Introduction to Community-based 402 SNMPv2", RFC 1901, January 1996. 404 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. 405 Waldbusser, "Protocol Operations for Version 406 2 of the Simple Network Management Protocol 407 (SNMPv2)", RFC 1905, January 1996. 409 [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. 410 Waldbusser, "Transport Mappings for Version 411 2 of the Simple Network Management Protocol 412 (SNMPv2)", RFC 1906, January 1996. 414 [RFC2119] Bradner, S., "Key words for use in RFCs to 415 Indicate Requirement Levels", BCP 14, RFC 416 2119, March 1997. 418 [RFC2570] Case, J., Mundy, R., Partain, D., and B. 419 Stewart, "Introduction to Version 3 of the 420 Internet-standard Network Management 421 Framework", RFC 2570, April 1999. 423 [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, 424 "An Architecture for Describing SNMP 425 Management Frameworks", RFC 2571, April 426 1999. 428 [RFC2572] Case, J., Harrington D., Presuhn R., and B. 429 Wijnen, "Message Processing and Dispatching 430 for the Simple Network Management Protocol 431 (SNMP)", RFC 2572, April 1999. 433 [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 434 Applications", RFC 2573, April 1999. 436 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based 437 Security Model (USM) for version 3 of the 438 Simple Network Management Protocol 439 (SNMPv3)", RFC 2574, April 1999. 441 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, 442 "View-based Access Control Model (VACM) for 443 the Simple Network Management Protocol 444 (SNMP)", RFC 2575, April 1999. 446 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, 447 J., Case, J., Rose, M., and S. Waldbusser, 448 "Structure of Management Information Version 449 2 (SMIv2)", STD 58, RFC 2578, April 1999. 451 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, 452 J., Case, J., Rose, M., and S. Waldbusser, 453 "Textual Conventions for SMIv2", STD 58, RFC 454 2579, April 1999. 456 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, 457 J., Case, J., Rose, M., and S. Waldbusser, 458 "Conformance Statements for SMIv2", STD 58, 459 RFC 2580, April 1999. 461 9. Intellectual Property Notice 463 The IETF takes no position regarding the validity or scope of any 464 intellectual property or other rights that might be claimed to 465 pertain to the implementation or use of the technology described in 466 this document or the extent to which any license under such rights 467 might or might not be available; neither does it represent that it 468 has made any effort to identify any such rights. Information on the 469 IETF's procedures with respect to rights in standards-track and 470 standards-related documentation can be found in BCP-11. Copies of 471 claims of rights made available for publication and any assurances of 472 licenses to be made available, or the result of an attempt made to 473 obtain a general license or permission for the use of such 474 proprietary rights by implementers or users of this specification can 475 be obtained from the IETF Secretariat. 477 The IETF invites any interested party to bring to its attention any 478 copyrights, patents or patent applications, or other proprietary 479 rights which may cover technology that may be required to practice 480 this standard. Please address the information to the IETF Executive 481 Director. 483 10. Full Copyright Statement 485 Copyright (C) The Internet Society (2002). All Rights Reserved. 487 This document and translations of it may be copied and 488 furnished to others, and derivative works that comment on 489 or otherwise explain it or assist in its implementation may 490 be prepared, copied, published and distributed, in whole or 491 in part, without restriction of any kind, provided that the 492 above copyright notice and this paragraph are included on 493 all such copies and derivative works. However, this 494 document itself may not be modified in any way, such as by 495 removing the copyright notice or references to the Internet 496 Society or other Internet organizations, except as needed 497 for the purpose of developing Internet standards in which 498 case the procedures for copyrights defined in the Internet 499 Standards process must be followed, or as required to 500 translate it into languages other than English. 502 The limited permissions granted above are perpetual and 503 will not be revoked by the Internet Society or its 504 successors or assigns. This document and the information 505 contained herein is provided on an "AS IS" basis and THE 506 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 507 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 508 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 509 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 510 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 511 PURPOSE.