idnits 2.17.1 draft-ietf-mpls-ldp-capabilities-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 25. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 547. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 517. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 524. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 530. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 (May 2007) is 6188 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) ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Bob Thomas 3 Internet Draft Cisco Systems, Inc. 4 Expiration Date: November 2007 5 S. Aggarwal 6 Juniper Networks 8 R. Aggarwal 9 Juniper Networks 11 J.L. Le Roux 12 France Telecom 14 May 2007 16 LDP Capabilities 18 draft-ietf-mpls-ldp-capabilities-00.txt 20 Status of this Memo 22 By submitting this Internet-Draft, each author represents that any 23 applicable patent or other IPR claims of which he or she is aware 24 have been or will be disclosed, and any of which he or she becomes 25 aware will be disclosed, in accordance with Section 6 of BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 Copyright Notice 45 Copyright (C) The IETF TRUST (2007). 47 Abstract 49 A number of enhancements to the Label Distribution Protocol (LDP) 50 have been proposed. Some have been implemented, and some are 51 advancing toward standardization. It is likely that additional 52 enhancements will be proposed in the future. At present LDP has no 53 guidelines for advertising such enhancements at LDP session 54 initialization time. There is also no mechanism to enable and 55 disable enhancements after the session is established. This document 56 provides guidelines for advertising LDP enhancements at session 57 initialization time. It also defines a mechanism to enable and 58 disable enhancements after LDP session establishment. 60 Table of Contents 62 1 Introduction .................................................. 3 63 2 Specification Language ........................................ 3 64 3 The LDP Capability Mechanism .................................. 3 65 4 Specifying Capabilities in LDP Messages ....................... 5 66 5 Capability Message ............................................ 6 67 6 Note on Terminology ........................................... 7 68 7 Procedures for Capability Parameters in Initialization Messages 7 69 8 Procedures for Capability Parameters in Capability Messages ... 8 70 9 Extensions to Error Handling .................................. 8 71 10 Dynamic Capability Announcement TLV ........................... 9 72 11 Backward Compatibility ........................................ 10 73 12 Security Considerations ....................................... 10 74 13 IANA Considerations ........................................... 10 75 14 Acknowledgements .............................................. 11 76 15 References .................................................... 11 77 16 Author Information ............................................ 12 78 17 Intellectual Property Statement ............................... 12 79 18 Full Copyright Statement ...................................... 13 81 1. Introduction 83 A number of enhancements to LDP as specified in [RFC3036] have been 84 proposed. These include LDP Graceful Restart [RFC3478], Fault 85 Tolerant LDP [RFC3479], multicast extensions [MLDP], signaling for 86 layer 2 circuits [RFC4447], a method for learning labels advertised 87 by next next hop routers in support of fast reroute node protection 88 [NNHOP], upstream label allocation [UPSTREAM_LDP], and extensions for 89 signaling inter-area LSPs [IALDP]. Some have been implemented, and 90 some are advancing toward standardization. It is likely that 91 additional enhancements will be proposed in the future. 93 At present LDP has no guidelines for advertising such enhancements at 94 LDP session initialization time. There is also no mechanism to 95 enable and disable enhancements after the session is established. 97 This document provides guidelines for advertising LDP enhancements at 98 session initialization time. It also defines a mechanism to enable 99 and disable enhancements after LDP session establishment. 101 LDP capability advertisement provides means for an LDP speaker to 102 announce what it can receive and process. It also provides means for 103 a speaker to inform peers of deviations from behavior specified by 104 [RFC3036]. An example of such a deviation is LDP graceful restart 105 where a speaker retains MPLS forwarding state for LDP-signaled LSPs 106 when its LDP control plane goes down. It is important to point out 107 that not all LDP enhancements require capability advertisement. For 108 example, upstream label allocation does but inbound label filtering, 109 where a speaker installs forwarding state for only certain FECs, does 110 not. 112 2. Specification Language 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 3. The LDP Capability Mechanism 120 Enhancements are likely to be announced during LDP session 121 establishment as each LDP speaker advertises capabilities 122 corresponding to the enhancements it desires. 124 Beyond that, capability advertisements may be used to dynamically 125 modify the characteristics of the session to suit changing 126 conditions. For example, an LSR capable of a particular enhancement 127 in support of some "feature" may not have advertised the 128 corresponding capability to its peers at session establishment time 129 because the feature was disabled at that time. Later an operator may 130 enable the feature, at which time the LSR would react by advertising 131 the corresponding capability to its peers. Similarly, when an 132 operator disables a feature associated with a capability the LSR 133 reacts by withdrawing the capability advertisement from its peers. 135 The LDP capability advertisement mechanism operates as follows: 137 - Each LDP speaker is assumed to implement a set of enhancements 138 each of which has an associated capability. At any time a 139 speaker may have none, one or more of those enhancements 140 "enabled". When an enhancement is enabled the speaker advertises 141 the associated capability to its peers. By advertising the 142 capability to a peer the speaker asserts that it shall perform 143 the protocol actions specified for the associated enhancement. 144 For example, the actions may involve receiving and processing 145 messages from a peer that the enhancement requires. Unless the 146 capability has been advertised the speaker will not perform 147 protocol actions specified for the corresponding enhancement. 149 - At session establishment time an LDP speaker MAY advertise a 150 particular capability by including an optional parameter 151 associated with the capability in its Initialization message. 153 - There is a well-known capability called Dynamic Capability 154 Announcement which an LDP speaker MAY advertise in its 155 Initialization message to indicate that it is capable of 156 processing capability announcements following session 157 establishment. 159 If a peer had advertised the Dynamic Capability Announcement 160 capability in its Initialization message then at any time 161 following session establishment an LDP speaker MAY announce 162 changes in its advertised capabilities to that peer. To do this 163 the LDP speaker sends the peer a Capability message that 164 specifies the capabilities being advertised or withdrawn. 166 When the capability advertisement mechanism is in place an LDP 167 enhancement requiring LDP capability advertisement will be specified 168 by a document that: 170 - Describes the motivation for the enhancement; 171 - Specifies the behavior of LDP when the enhancement is enabled. 172 This includes the procedures, parameters, messages, and TLVs 173 required by the enhancement; 175 - Includes an IANA considerations section that notes that an IANA- 176 assigned code point for the optional parameter corresponding to 177 the enhancement is required. 179 4. Specifying Capabilities in LDP Messages 181 This document uses the term "Capability Parameter" to refer to an 182 optional parameter that may be included in Initialization and 183 Capability messages to advertise a capability. 185 The format of a TLV that is a Capability Parameter is: 187 0 1 2 3 188 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 |U|F| TLV Code Point | Length | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 |S| Reserved | | 193 +-+-+-+-+-+-+-+-+ Capability Data | 194 | +-+-+-+-+-+-+-+-+ 195 | | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 where: 199 U and F bits: 200 As specified in [RFC3036]. 202 TLV Code Point: 203 The TLV type which identifies a specific capability. The "IANA 204 Considerations" section of [RFC3036] specifies the assignment of 205 code points for LDP TLVs. 207 S-bit: 208 The State Bit indicates whether the sender is advertising or 209 withdrawing the capability corresponding to the TLV Code Point. 210 The State bit is used as follows: 212 1 - The TLV is advertising the capability specified by the 213 TLV Code Point. 214 0 - The TLV is withdrawing the capability specified by the 215 TLV Code Point. 217 Capability Data: 219 Information, if any, about the capability in addition to the TLV 220 Code Point required to fully specify the capability. 222 An LDP speaker MAY include more than one instance of a Capability 223 Parameter (as identified by the TLV Code Point) with different non- 224 empty Capability Data in an Initialization or Capability message. 225 The method for processing such Capability Parameters is specific to 226 the TLV Code Point and MUST be described in the document specifying 227 the capability. 229 To ensure backward compatibility with existing implementations the 230 following TLVs play the role of a Capability Parameter when included 231 in Initialization messages: 233 - FT Session TLV [RFC3479] 235 This document refers to such TLVs as Backward Compatibility TLVs. 237 5. Capability Message 239 The LDP Capability message is used by an LDP speaker subsequent to 240 session establishment to announce changes in the state for one or 241 more of its capabilities. 243 The format of the Capability message is: 245 0 1 2 3 246 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 |0| Capability (IANA) | Length | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Message ID | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | TLV_1 | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | . . . | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | TLV_N | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 where TLV_1 through TLV_N are Capability Parameters. The S-bit of 260 each of the TLVs specifies the new state for the corresponding 261 capability. 263 Note that Backward Compatibility TLVs (see Section 4) MUST NOT be 264 included in Capability messages. 266 6. Note on Terminology 268 The sections that follow talk of enabling and disabling capabilities. 269 The terminology "enabling (or disabling) a capability" is short hand 270 for "advertising (or withdrawing) a capability associated with an 271 enhancement". Bear in mind that it is an LDP enhancement that is 272 enabled or disabled and that it is the corresponding capability that 273 is advertisted or withdrawn. 275 7. Procedures for Capability Parameters in Initialization Messages 277 An LDP speaker SHOULD NOT include more than one instance of a 278 Capability Parameter with the same type and value in an 279 Initialization message. Note, however, that processing multiple 280 instances of such a parameter does not require special handling, as 281 additional instances do not change the meaning of an announced 282 capability. 284 The S-bit of a Capability Parameter in an Initialization message MUST 285 be 1 and SHOULD be ignored on receipt. This ensures that any 286 Capability Parameter in an Initialization message enables the 287 corresponding capability. 289 An LDP speaker determines the capabilities enabled by a peer by 290 examining the set of of Capability Parameters present in the 291 Initialization message received from the peer. 293 An LDP speaker MAY use a particular capability with its peer after 294 the speaker determines that the peer has enabled that capability. 296 These procedures enable an LDP speaker A that advertises a specific 297 LDP capability C to establish an LDP session with speaker B that does 298 not advertise C. In this situation whether or not capability C may 299 be used for the session depends on the semantics of the enhancement 300 associated with C. If the semantics do not require both A and B 301 advertise C to one another then B could use it; that is, A's 302 advertisement of C permits B to send messages to A used by the 303 enhancement. 305 It is the responsibility of the capability designer to specify the 306 behavior of an LDP speaker that has enabled a certain enhancement, 307 advertised its capability and determines that its peer has not 308 advertised the corresponding capability. The document specifying 309 procedures for the capability MUST describe the behavior in this 310 situation. If the specified procedure is to terminate the session 311 the LDP speaker SHOULD send a Notification message to the peer before 312 terminating the session. The Status Code in the Status TLV of the 313 Notification message SHOULD be Unsupported Capability, and the 314 message SHOULD contain the unsupported capabilities (see Section 9 315 for more details). In this case the session SHOULD NOT be re- 316 established automatically. How the session is re-established is 317 beyond the scope of this document. It depends on the LDP capability 318 and MUST be specified along with the procedures specifying the 319 capability. 321 An LDP speaker that supports capability advertisement and includes a 322 Capability Parameter in its Initialization message SHOULD set the TLV 323 U bit to 1. This ensures that an [RFC3036] compliant peer that does 324 not support the capability mechanism will ignore the Capability 325 Parameter and allow the session to be established. 327 8. Procedures for Capability Parameters in Capability Messages 329 An LDP speaker MUST NOT send a Capability message to a peer unless 330 its peer had advertised the Dynamic Capability Announcement 331 capability in its session Initialization message (see Section 10). 333 An LDP speaker MAY send a Capability message to a peer if its peer 334 had advertised the Dynamic Capability Announcement capability in its 335 session Initialization message (see Section 10). 337 An LDP speaker determines the capabilities enabled by a peer by 338 determining the set of capabilities enabled at session initialization 339 (as specified in Section 7) and tracking changes to that set made by 340 Capability messages from the peer. 342 An LDP speaker that has enabled a particular capability MAY use the 343 enhancement corresponding to the capability with a peer after the 344 speaker determines that the peer has enabled the capability. 346 9. Extensions to Error Handling 348 This document defines a new LDP status code named Unsupported 349 Capability. The E bit of the Status TLV carried in a Notification 350 message that includes this status code SHOULD be set to 0. 352 In addition, this document defines a new LDP TLV named Returned TLVs 353 TLV that MAY be carried in a Notification message. The U-bit setting 354 for a Returned TLVs TLV in a Notification message SHOULD be 1 and the 355 F-bit setting SHOULD be 0. 357 When the Status Code in a Notification message is Unsupported 358 Capability the message SHOULD specify the capabilities that are 359 unsupported. When the Notification message specifies the unsupported 360 capabilities it MUST include a Returned TLVs TLV which includes each 361 unsupported Capability Parameter. The Returned TLVs TLV MUST include 362 only the Capability Parameters for unsupported capabilities. In 363 addition, the Capability Parameter for each such capability SHOULD be 364 encoded as received from the peer. 366 When the Status Code in a Notification Message is Unknown TLV the 367 message SHOULD specify the TLV that was unknown. When the 368 Notification message specifies the TLV that was unknown it MUST 369 include the unknown TLV in a Returned TLVs TLV. 371 10. Dynamic Capability Announcement TLV 373 The Dynamic Capability Announcement TLV is a Capability Parameter. 374 Its format is: 376 0 1 2 3 377 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 |0|0| DynCap Announcement (IANA)| Length | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 |S| Reserved | 382 +-+-+-+-+-+-+-+-+ 384 The Dynamic Capability Announcement Parameter MAY be included by an 385 LDP speaker in an Initialization message to signal its peer that the 386 speaker is capable of processing Capability messages. 388 An LDP speaker MUST NOT include the Dynamic Capability Announcement 389 Parameter in Capability messages sent to its peers. Once enabled 390 during session initialization the Dynamic Capability Announcement 391 capability cannot be disabled. 393 An LDP speaker that receives a Capability message from a peer that 394 includes the Dynamic Capability Announcement Parameter SHOULD 395 silently ignore the parameter and process any other Capability 396 Parameters in the message. 398 11. Backward Compatibility 400 From the point of view of the LDP capability advertisement mechanism 401 an [RFC3036] compliant peer has label distribution for IPv4 enabled 402 by default. To ensure compatibility with an [RFC3036] compliant peer 403 LDP implementations that support capability advertisement have label 404 distribution for IPv4 enabled until it is explicitly disabled and 405 MUST assume that their peers do as well. 407 Section 3 identifies a set of Backward Compatibility TLVs that may 408 appear in Initialization messages in the role of a Capability 409 Parameter. This permits existing LDP enhancements that use an ad hoc 410 mechanism for enabling capabilities at sesssion initialization time 411 to continue to do so. 413 12. Security Considerations 415 The security considerations described in [RFC3036] that apply to the 416 base LDP specification apply to the capability mechanism described in 417 this document. 419 13. IANA Considerations 421 This document specifies the following which require code points 422 assigned by IANA: 424 - LDP message code point for the Capability message. The authors 425 request message type 0x0202 for the Capability message. 427 - LDP TLV code point for the Dynamic Capability Announcemnt TLV. 428 The authors request TLV type code 0x0506. 430 - LDP TLV code point for the Returned TLVs TLV. The authors 431 request TLV type 0x304. 433 - LDP Status Code code point for the Unsupported Capability 434 Status Code. The authors request Status Code 0x0000002C. 436 14. Acknowledgements 438 The authors wish to thank Enke Chen, Vanson Lim, Ina Minei, Bin Mo, 439 Yakov Rekhter, and Eric Rosen for their comments. 441 15. References 443 Normative References 445 [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and 446 Thomas, B., "LDP Specification", RFC 3036, January 2001. 448 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 449 Requirement Levels", BCP 14, RFC2119, March 1997. 451 [RFC3479] Farrel, A., Editor, "Fault Tolerance for the Label 452 Distribution Protocol (LDP)", RFC 3479, February 2003. 454 Informative References 456 [IALDP] Decraene, B., Le Roux, JL., Minei, I, "LDP Extensions for 457 Inter-Area LSPs", draft-decraene-mpls-ldp-interarea-04.txt, Work in 458 Progress, March 2007 460 [MLDP] Minei, I., Wijnamds, I., Editors, "Label Distribution Protocol 461 Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label 462 Switched Paths", draft-minei-wijnands-mpls-ldp-p2mp-00.txt, Work in 463 Progress, September 2005 465 [NNHOP] Shen, N., Chen, E., Tian, A. "Discovery LDP Next-Nexthop 466 Labels", draft-shen-mpls-ldp-nnhop-label-02.txt, Work in Progress, 467 May 2005 469 [RFC4447] L. Martini, Editor, E. Rosen, El-Aawar, T. Smith, G. Heron, 470 "Pseudowire Setup and Maintenance using the Label Distribution 471 Protocol", RFC 4447, April 2006. 473 [RFC3478] Leelanivas, M., Rekhter, Y, Aggarwal, R., "Graceful Restart 474 Mechanism for Label Distribution Protocol (LDP)", RFC 3478, February 475 2003. 477 [UPSTREAM_LDP] Aggarwal R., Le Roux, J.L., "MPLS Upstream Label 478 Assignment for LDP" draft-ietf-mpls-ldp-upstream-00.txt, Work in 479 Progress, February 2006. 481 16. Author Information 483 Shivani Aggarwal 484 Juniper Networks 485 1194 North Mathilda Ave. 486 Sunnyvale, CA 94089 487 Email: shivani@juniper.net 489 Rahul Aggarwal 490 Juniper Networks 491 1194 North Mathilda Ave. 492 Sunnyvale, CA 94089 493 Email: rahul@juniper.net 495 Jean-Louis Le Roux 496 France Telecom 497 2, avenue Pierre-Marzin 498 22307 Lannion Cedex 499 France 500 E-mail: jeanlouis.leroux@orange_ftgroup.com 502 Bob Thomas 503 Cisco Systems, Inc. 504 1414 Massachusetts Ave. 505 Boxborough MA 01719 506 E-mail: rhthomas@cisco.com 508 17. Intellectual Property Statement 510 The IETF takes no position regarding the validity or scope of any 511 Intellectual Property Rights or other rights that might be claimed to 512 pertain to the implementation or use of the technology described in 513 this document or the extent to which any license under such rights 514 might or might not be available; nor does it represent that it has 515 made any independent effort to identify any such rights. Information 516 on the procedures with respect to rights in RFC documents can be 517 found in BCP 78 and BCP 79. 519 Copies of IPR disclosures made to the IETF Secretariat and any 520 assurances of licenses to be made available, or the result of an 521 attempt made to obtain a general license or permission for the use of 522 such proprietary rights by implementers or users of this 523 specification can be obtained from the IETF on-line IPR repository at 524 http://www.ietf.org/ipr. 526 The IETF invites any interested party to bring to its attention any 527 copyrights, patents or patent applications, or other proprietary 528 rights that may cover technology that may be required to implement 529 this standard. Please address the information to the IETF at ietf- 530 ipr@ietf.org. 532 18. Full Copyright Statement 534 Copyright (C) The IETF Trust (2007). 536 This document is subject to the rights, licenses and restrictions 537 contained in BCP 78, and except as set forth therein, the authors 538 retain all their rights. 540 This document and the information contained herein are provided on an 541 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 542 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 543 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 544 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 545 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 546 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 547 PURPOSE.