idnits 2.17.1 draft-ietf-eos-snmpxproto-mib-02.txt: 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 the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 529 has weird spacing: '...for the purpo...' -- 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 2002) is 8104 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: 'RFC 2571' is mentioned on line 112, but not defined ** Obsolete undefined reference: RFC 2571 (Obsoleted by RFC 3411) == Missing Reference: 'RFC1902' is mentioned on line 186, but not defined ** Obsolete undefined reference: RFC 1902 (Obsoleted by RFC 2578) == Unused Reference: 'RFC2021' is defined on line 494, but no explicit reference was found in the text == Unused Reference: 'RFC2274' is defined on line 498, but no explicit reference was found in the text == Unused Reference: 'RFC2275' is defined on line 502, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 506, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2571 (Obsoleted by RFC 3411) ** Downref: Normative reference to an Informational RFC: RFC 1215 ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2572 (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2574 (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2573 (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2575 (Obsoleted by RFC 3415) ** Obsolete normative reference: RFC 2570 (Obsoleted by RFC 3410) ** Obsolete normative reference: RFC 2021 (Obsoleted by RFC 4502) ** Obsolete normative reference: RFC 2274 (Obsoleted by RFC 2574) ** Obsolete normative reference: RFC 2275 (Obsoleted by RFC 2575) ** Obsolete normative reference: RFC 2262 (Obsoleted by RFC 2272) Summary: 20 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EOS Working Group S. Chisholm 3 Internet Draft Nortel Networks 4 Document: draft-ietf-eos-snmpxproto-mib-02.txt 5 Category: Standards Track 6 Expiration Date: August 2002 February 2002 8 SNMP Extended Protocol MIB 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance 13 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as 24 "work in progress." 26 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 Abstract 35 This memo defines a portion of the Management Information Base (MIB) 36 for use with network management protocols in the Internet community. 37 In particular, it describes SNMP protocol operations supported by 38 an SNMP entity. 40 Table of Contents 42 1. The SNMP Management Framework 43 2. Introduction 44 3. Extended Protocol Management 45 3.1. SNMP Extensions 46 3.2. Interoperability 47 3.3. Relation to MAX-ACCESS clause 48 3.4. Relation to Agent Capabilities 49 4. MIB Overview 50 5. IANA Considerations 51 6. Definitions 52 7. Security Considerations 53 8. Author's Address 54 9. Acknowledgements 55 10. References 56 11. Full Copyright Statement 57 1. The SNMP Management Framework 59 The SNMP Management Framework presently consists of five major 60 components: 62 o An overall architecture, described in RFC 2571 [RFC2571]. 64 o Mechanisms for describing and naming objects and events for the 65 purpose of management. The first version of this Structure of 66 Management Information (SMI) is called SMIv1 and described in 67 STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 68 1215 [RFC1215]. The second version, called SMIv2, is described 69 in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and 70 STD 58, RFC 2580 [RFC2580]. 72 o Message protocols for transferring management information. The 73 first version of the SNMP message protocol is called SNMPv1 and 74 described in STD 15, RFC 1157 [RFC1157]. A second version of 75 the SNMP message protocol, which is not an Internet standards 76 track protocol, is called SNMPv2c and described in RFC 1901 77 [RFC1901] and RFC 1906 [RFC1906]. The third version of the 78 message protocol is called SNMPv3 and described in RFC 1906 79 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. 81 o Protocol operations for accessing management information. The 82 first set of protocol operations and associated PDU formats is 83 described in STD 15, RFC 1157 [RFC1157]. A second set of 84 protocol operations and associated PDU formats is described in 85 RFC 1905 [RFC1905]. 87 o A set of fundamental applications described in RFC 2573 88 [RFC2573] and the view-based access control mechanism described 89 in RFC 2575 [RFC2575]. 91 A more detailed introduction to the current SNMP Management Framework 92 can be found in RFC 2570 [RFC2570]. 94 Managed objects are accessed via a virtual information store, termed 95 the Management Information Base or MIB. Objects in the MIB are 96 defined using the mechanisms defined in the SMI. 98 This memo specifies a MIB module that is compliant to the SMIv2. A 99 MIB conforming to the SMIv1 can be produced through the appropriate 100 translations. The resulting translated MIB must be semantically 101 equivalent, except where objects or events are omitted because no 102 translation is possible (use of Counter64). Some machine readable 103 information in SMIv2 will be converted into textual descriptions in 104 SMIv1 during the translation process. However, this loss of machine 105 readable information is not considered to change the semantics of the 106 MIB. 108 2. Introduction 110 Traditionally, features have been added to SNMP by developing a new 111 version of the protocol that supports these new features. Currently, 112 SNMP entities that conform to [RFC 2571] are expected to implement 113 all the protocol functionality defined by the standards. 115 The idea, moving forward, is to add features to SNMP in a more 116 modular fashion and without necessarily increasing the version 117 number. Since the protocol version number is no longer sufficient 118 information to determine which protocol features an SNMP entity 119 supports, another method is required. This memo defines a MIB to be 120 used to determine the SNMP capabilities of an SNMP entity, 121 independent of its protocol version. 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119. 127 3. Extended Protocol Management 129 3.1 SNMP Extensions 131 SNMP extensions are those standard protocol extensions that are 132 developed within the IETF and published in standards track RFCs. 134 3.2 Interoperability 135 +------------+ 136 |Command | 137 +--------+Generator |-----------+ 138 | |Extended | | 139 | |Protocol | | 140 | +------------+ | 141 | | 142 | | 143 | +--------+------------+ 144 +------+-----+ |Command Responder | 145 |Command | | | 146 |Responder | | Extended Protocol | 147 |Protocol | +--------+------------+ 148 |Operations | | 149 |v2 | | 150 +-----+------+ | 151 | +------------+ | 152 | |Command | | 153 | |Generator +--------+ 154 +------------+Protocol | 155 |Operations | 156 |v2 | 157 +------------+ 159 An SNMP entity that supports version 2 of the protocol operations 160 [RFC1905] MUST be able to communicate with an SNMP entity supporting 161 extended protocol operations. This communication MUST be in a manner 162 consistent with communicating with an SNMP entity that supports 163 version 2 of the protocol operations. Similarly, an SNMP entity that 164 supports extended protocol operations MUST be able to communicate 165 with SNMP entities which support version 2 of the protocol 166 operations. 168 An SNMP entity that supports the extended protocol operations SHOULD 169 support protocol operations as defined in version 2 of the protocol 170 operations [RFC1905]. The get-request operation MUST be supported. 172 A command generator SHOULD query a command responder before issuing 173 an extended protocol operation to determine if the command responder 174 supports the operation. 176 An SNMP entity MUST only issue a response using an extended protocol 177 feature if it received the request using the extended protocol 178 feature. 180 If an SNMP entity receives an extended protocol feature it does not 181 understand, it MUST follow the unknown PDU response mechanism as 182 defined in [RFC2262] section 4.2.2.1 184 3.3 Relation to MAX-ACCESS Clause 186 MAX-ACCESS, as defined in [RFC1902], indicates whether it makes 187 "protocol sense" to read, write and/or create an instance of the 188 object, or to include its value in a notification. It is useful for 189 this discussion to term read, write, create and accessible for 190 notify as different classes of access to MIB objects. In the case of 191 the protocol operations defined in [RFC1905], the get-request, 192 get-next-request, get-bulk-request would all belong to the read 193 class. The set-request would belong to the write class and the 194 create class. The inform-request and the snmpV2-trap would both 195 belong to the accessible for notify class. The protocol capabilities 196 identified using this memo indicate which specific protocol 197 operations are supported on the object if the appropriate class of 198 access is allowed. 200 If a protocol operation is not supported on a given object, it only 201 affects the protocol capabilities statement, if its access class is 202 supported for that object. For example, if an object is read-only 203 and therefore does not support the write class, the system can still 204 claim support of the set-request operation so long as all objects 205 that do support the write class support the set-request. However, if 206 the object does not support the get-bulk-request, the system cannot 207 claim support of this protocol operation as this object supports the 208 read class. 210 3.4 Relation to Agent Capabilities 212 Agent capability statements are used when describing capabilities of 213 agents with respect to object definitions. The extended protocol 214 MIB is used when describing the capabilities of agents with respect 215 to protocol operations. 217 4. MIB Overview 219 The snmpXProtoSystem object indicates which protocol operations are 220 supported by the entire SNMP entity. snmpXProtoSubTreeTable 221 indicates additional protocol operations supported on particular MIB 222 sub trees. 224 5. IANA Considerations 226 IANASnmpProtocol is a bitmap that indicates which standard SNMP 227 operations an SNMP entity supports. New values for this bitmap may 228 be given out for SNMP protocol extensions published as standards 229 track RFCs. 231 The following shall be used as the initial values, but the latest 232 values for these textual conventions should be obtained from IANA: 234 IANA-SNMP-PROTOCOL-TC DEFINITIONS ::= BEGIN 235 IMPORTS 236 MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI 237 TEXTUAL-CONVENTION FROM SNMPv2-TC; 239 ianaSnmpProtoNumbers MODULE-IDENTITY 240 LAST-UPDATED "200202200000Z" 241 ORGANIZATION "IANA" 242 CONTACT-INFO 243 "Postal: Internet Assigned Numbers Authority 244 Internet Corporation for Assigned Names 245 and Numbers 246 4676 Admiralty Way, Suite 330 247 Marina del Rey, CA 90292-6601 248 USA 250 Tel: +1 310-823-9358 251 E-Mail: iana@iana.org" 252 DESCRIPTION 253 "The MIB module defines textual conventions for use 254 in identifying SNMP protocol operations." 255 ::= { mib-2 xx } 257 -- IANA IANASnmpProtocol ::= TEXTUAL-CONVENTION 258 STATUS current 259 DESCRIPTION 260 "Standard SNMP protocol operations." 261 SYNTAX BITS 262 { 263 getRequest (0), 264 getNextRequest (1), 265 getBulkRequest (2), 266 response (3), 267 setRequest (4), 268 informRequest (5), 269 snmpV2Trap (6), 270 report (7) 271 } END 273 6. Definitions 275 SNMP-EXTENDED-PROTOCOL-MIB DEFINITIONS ::= BEGIN 277 IMPORTS 278 MODULE-IDENTITY, OBJECT-TYPE, 279 Unsigned32, mib-2 FROM SNMPv2-SMI 280 IANASnmpProtocol FROM IANA-SNMP-PROTOCOL-TC 281 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF; 283 snmpXProtoMIB MODULE-IDENTITY 284 LAST-UPDATED "200202200000Z" 285 ORGANIZATION "IETF Evolution of SNMP Working Group" 286 CONTACT-INFO 287 " Sharon Chisholm 288 Nortel Networks 289 PO Box 3511 Station C 290 Ottawa, Ont. K1Y 4H7 291 Canada 292 schishol@nortelnetworks.com" 293 DESCRIPTION 294 "The MIB module describes the SNMP protocol 295 operations supported by this SNMP entity." 296 REVISION "200202200000Z" 297 DESCRIPTION 298 "Initial version, published as RFC XXXX." 300 ::= { mib-2 xx } 302 snmpXProtoObjects OBJECT IDENTIFIER ::= { snmpXProtoMIB 1 } 304 snmpXProtoConformance OBJECT IDENTIFIER ::= { snmpXProtoMIB 3 } 306 snmpXProtoCompliances OBJECT IDENTIFIER 307 ::= { snmpXProtoConformance 1 } 309 snmpXProtoSystem OBJECT-TYPE 310 SYNTAX IANASnmpProtocol 311 MAX-ACCESS read-only 312 STATUS current 313 DESCRIPTION 314 "The standard SNMP protocol operations supported 315 by this SNMP entity on all objects with appropriate 316 access permissions. For example, SNMP sets may be 317 included in this list, even if the MAX-ACCESS of 318 some objects is read-only." 319 ::= { snmpXProtoObjects 1 } 321 -- Extra Protocol Support per SubTree 323 snmpXProtoSubTreeTable OBJECT-TYPE 324 SYNTAX SEQUENCE OF SnmpXProtoSubTreeEntry 325 MAX-ACCESS not-accessible 326 STATUS current 327 DESCRIPTION "A table of additional SNMP protocol operations 328 supported on objects in the specific subTrees." 329 ::= { snmpXProtoObjects 2 } 331 snmpXProtoSubTreeEntry OBJECT-TYPE 332 SYNTAX SnmpXProtoSubTreeEntry 333 MAX-ACCESS not-accessible 334 STATUS current 335 DESCRIPTION "A MIB subtree that supports additional 336 protocol operations above that specified 337 in snmpXProtoSystem." 338 INDEX { snmpXProtoSubTreeIndex } 339 ::= { snmpXProtoSubTreeTable 1 } 341 SnmpXProtoSubTreeEntry ::= SEQUENCE { 342 snmpXProtoSubTreeIndex Unsigned32, 343 snmpXProtoSubTreeBranch OBJECT IDENTIFIER, 344 snmpXProtoSubTreeFeature IANASnmpProtocol 345 } 347 snmpXProtoSubTreeIndex OBJECT-TYPE 348 SYNTAX Unsigned32(1..4294967295) 349 MAX-ACCESS not-accessible 350 STATUS current 351 DESCRIPTION "An arbitrary index into this table." 352 ::= { snmpXProtoSubTreeEntry 1 } 354 snmpXProtoSubTreeBranch OBJECT-TYPE 355 SYNTAX OBJECT IDENTIFIER 356 MAX-ACCESS read-only 357 STATUS current 358 DESCRIPTION 359 "The OID that identifies this MIB SubTree." 360 ::= { snmpXProtoSubTreeEntry 2 } 362 snmpXProtoSubTreeFeature OBJECT-TYPE 363 SYNTAX IANASnmpProtocol 364 MAX-ACCESS read-only 365 STATUS current 366 DESCRIPTION 367 "The standard SNMP protocol operations supported 368 by this subTree above and beyond protocol 369 support as indicated by snmpXProtoSystem." 370 ::= { snmpXProtoSubTreeEntry 3 } 372 snmpXProtoCompliance MODULE-COMPLIANCE 373 STATUS current 374 DESCRIPTION 375 "The compliance statement for systems supporting 376 the snmpXProto MIB." 377 MODULE -- this module 378 MANDATORY-GROUPS { 379 snmpXProtoGroup 380 } 381 ::= { snmpXProtoCompliances 1 } 383 snmpXProtoGroups OBJECT IDENTIFIER ::= { snmpXProtoConformance 2 } 385 snmpXProtoGroup OBJECT-GROUP 386 OBJECTS { 387 snmpXProtoSystem 388 } 389 STATUS current 390 DESCRIPTION 391 "Standard snmpXProto group." 392 ::= { snmpXProtoGroups 1} 394 snmpXProtoSubTreeGroup OBJECT-GROUP 395 OBJECTS { 396 snmpXProtoSubTreeFeature, 397 snmpXProtoSubTreeBranch 398 } 399 STATUS current 400 DESCRIPTION 401 "SubTree specific snmpXProto group." 402 ::= { snmpXProtoGroups 2} 404 END 406 7. Security Considerations 408 There are no management objects defined in this MIB that have a 409 MAX-ACCESS clause of read-write and/or read-create. So, if this MIB 410 is implemented correctly, then there is no risk that an intruder can 411 alter or create any management objects of this MIB via direct SNMP 412 SET operations. 414 8. Author's Address 416 Sharon Chisholm 417 Nortel Networks 418 PO Box 3511, Station C 419 Ottawa, Ontario, K1Y 4H7 420 Canada 421 Email: schishol@nortelnetworks.com 423 9. Acknowledgments 425 This document is a product of the Evolution of SNMP Working Group. 426 ... 428 10. References 430 [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An 431 Architecture for Describing SNMP Management Frameworks", 432 RFC 2571, April 41999. 434 [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification 435 of Management Information for TCP/IP-based Internets", STD 436 16, RFC 1155, May 1990. 438 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", 439 STD 16, RFC 1212, March 1991. 441 [RFC1215] M. Rose, "A Convention for Defining Traps for use with the 442 SNMP", RFC 1215, March 1991. 444 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 445 Rose, M., and S. Waldbusser, "Structure of Management 446 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 447 1999. 449 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 450 Rose, M., and S. Waldbusser, "Textual Conventions for 451 SMIv2", STD 58, RFC 2579, April 1999. 453 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 454 Rose, M., and S. Waldbusser, "Conformance Statements for 455 SMIv2", STD 58, RFC 2580, April 1999. 457 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 458 "Simple Network Management Protocol", STD 15, RFC 1157, 459 May 1990. 461 [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 462 "Introduction to Community-based SNMPv2", RFC 1901, 463 January 464 1996. 466 [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 467 "Transport Mappings for Version 2 of the Simple Network 468 Management Protocol (SNMPv2)", RFC 1906, January 1996. 470 [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, 471 "Message Processing and Dispatching for the Simple 472 Network Management Protocol (SNMP)", RFC 2572, April 473 1999. 475 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model 476 (USM) for version 3 of the Simple Network Management 477 Protocol (SNMPv3)", RFC 2574, April 1999. 479 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 480 "Protocol Operations for Version 2 of the Simple Network 481 Management Protocol (SNMPv2)", RFC 1905, January 1996. 483 [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 484 Applications", RFC 2573, April 1999. 486 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 487 Access Control Model (VACM) for the Simple Network 488 Management Protocol (SNMP)", RFC 2575, April 1999. 490 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, 491 "Introduction to Version 3 of the Internet-standard 492 Network Management Framework", RFC 2570, April 1999. 494 [RFC2021] Waldbusser, S. "Remote Network Monitoring Management 495 Information Base Version 2 using SMIv2", RFC 2021, 496 January 1997 498 [RFC2274] Blumenthal, U. and B. Wijnen, "User-based Security 499 Model (USM) for version 3 of the Simple Network Management 500 Protocol (SNMPv3)", RFC 2274, January 1998. 502 [RFC2275] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based 503 Access Control Model (VACM) for the Simple Network 504 Management Protocol (SNMP)", RFC 2275, January 1998. 506 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 507 Requirement Levels", BCP 14, RFC 2119, March 1997. 509 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 510 "Protocol Operations for SNMPv2", RFC 1905, January 1996 512 [RFC2262] Case, J., Harrington, D, Presuhn, R., Wijnen, B., 513 "Message Processing and Dispatching for the 514 Simple Network Management Protocol (SNMP)", RFC 2262, 515 January 1998 517 11. Full Copyright Statement 519 Copyright (C) The Internet Society (2002). All Rights Reserved. 521 This document and translations of it may be copied and furnished to 522 others, and derivative works that comment on or otherwise explain it 523 or assist in its implementation may be prepared, copied, published 524 and distributed, in whole or in part, without restriction of any kind, 525 provided that the above copyright notice and this paragraph are 526 included on all such copies and derivative works. However, this 527 document itself may not be modified in any way, such as by removing 528 the copyright notice or references to the Internet Society or other 529 Internet organizations, except as needed for the purpose of 530 developing Internet standards in which case the procedures for 531 copyrights defined in the Internet Standards process must be followed, 532 or as required to translate it into languages other than English. 534 The limited permissions granted above are perpetual and will not be 535 revoked by the Internet Society or its successors or assigns. 537 This document and the information contained herein is provided on an 538 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 539 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 540 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 541 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 542 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.