idnits 2.17.1 draft-ietf-isis-gmpls-extensions-19.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 401 has weird spacing: '...k Group n ...' == Line 410 has weird spacing: '...ability vari...' == Line 492 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 (October 2003) is 7470 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-gmpls-routing-08 ** Obsolete normative reference: RFC 3373 (ref. 'ISIS-3way') (Obsoleted by RFC 5303) == Outdated reference: A later version (-05) exists of draft-ietf-isis-restart-04 Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Kompella, Editor 2 Internet Draft Y. Rekhter, Editor 3 Category: Informational Juniper Networks 4 Updates: October 2003 5 Expires: April 2004 7 IS-IS Extensions in Support of Generalized 8 Multi-Protocol Label Switching 10 draft-ietf-isis-gmpls-extensions-19.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 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 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This document specifies encoding of extensions to the IS-IS routing 40 protocol in support of Generalized Multi-Protocol Label Switching. 42 Specification of Requirements 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC 2119 [RFC2119]. 48 Changes since last revision 50 (RFC Editor: remove this section before publication.) 52 Incorporated IESG comments: updated Security Considerations and IANA 53 Considerations. 55 1. Introduction 57 This document specifies extensions to the IS-IS routing protocol in 58 support of carrying link state information for Generalized 59 Multi-Protocol Label Switching (GMPLS). The set of required 60 enhancements to IS-IS are outlined in [GMPLS-ROUTING]. Support for 61 unnumbered interfaces assumes support for the "Point-to-Point 62 Three-Way Adjacency" IS-IS Option type [ISIS-3way]. 64 In this section we define the enhancements to the Traffic Engineering 65 (TE) properties of GMPLS TE links that can be announced in IS-IS Link 66 State Protocol Data Units. 68 In this document, we enhance the sub-TLVs for the extended IS 69 reachability TLV (see [ISIS-TE]) in support of GMPLS. Specifically, 70 we add the following sub-TLVs: 72 Sub-TLV Type Length Name 73 4 8 Link Local/Remote Identifiers 74 20 2 Link Protection Type 75 21 variable Interface Switching Capability 76 Descriptor 78 We further add one new TLV to the TE TLVs: 80 TLV Type Length Name 81 138 variable Shared Risk Link Group 83 1.1. Link Local/Remote Identifiers 85 A Link Local Interface Identifiers is a sub-TLV of the extended IS 86 reachability TLV. The type of this sub-TLV is 4, and length is eight 87 octets. The value field of this sub-TLV contains four octets of Link 88 Local Identifier followed by four octets of Link Remote Idenfier (see 89 Section "Support for unnumbered links" of [GMPLS-ROUTING]). If the 90 Link Remote Identifier is unknown, it is set to 0. 92 The following illustrates encoding of the Value field of the Link 93 Local/Remote Identifiers sub-TLV. 95 0 1 2 3 96 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 97 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 98 | Link Local Identifier | 99 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 | Link Remote Identifier | 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 The Link Local/Remote Identifiers sub-TLV MUST NOT occur more than 104 once within the extended IS reachability TLV. If the Link 105 Local/Remote Idenfitiers sub-TLV occurs more than once within the 106 extended IS reachability TLV, the receiver SHOULD ignore all these 107 sub-TLVs. 109 1.2. Link Protection Type 111 The Link Protection Type is is a sub-TLV (of type 20) of the 112 extended IS reachability TLV, with length two octets. 114 The following illustrates encoding of the Value field of the Link 115 Protection Type sub-TLV. 117 0 1 118 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 |Protection Cap | Reserved | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 The first octet is a bit vector describing the protection 124 capabilities of the link (see Section "Link Protection Type" of 125 [GMPLS-ROUTING]). They are: 127 0x01 Extra Traffic 129 0x02 Unprotected 130 0x04 Shared 132 0x08 Dedicated 1:1 134 0x10 Dedicated 1+1 136 0x20 Enhanced 138 0x40 Reserved 140 0x80 Reserved 142 The second octet SHOULD be set to zero by the sender, and SHOULD be 143 ignored by the receiver. 145 The Link Protection Type sub-TLV MUST NOT occur more than once within 146 the extended IS reachability TLV. If the Link Protection Type 147 sub-TLV occurs more than once within the extended IS reachability 148 TLV, the receiver SHOULD ignore all these sub-TLVs. 150 1.3. Interface Switching Capability Descriptor 152 The Interface Switching Capability Descriptor is a sub-TLV (of type 153 21) of the extended IS reachability TLV. The length is the length of 154 value field in octets. The following illustrates encoding of the 155 Value field of the Interface Switching Capability Descriptor sub-TLV. 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Switching Cap | Encoding | Reserved | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Max LSP Bandwidth at priority 0 | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Max LSP Bandwidth at priority 1 | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Max LSP Bandwidth at priority 2 | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Max LSP Bandwidth at priority 3 | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Max LSP Bandwidth at priority 4 | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Max LSP Bandwidth at priority 5 | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Max LSP Bandwidth at priority 6 | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Max LSP Bandwidth at priority 7 | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Switching Capability-specific information | 179 | (variable) | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 The Switching Capability (Switching Cap) field contains one of the 183 following values: 185 1 Packet-Switch Capable-1 (PSC-1) 186 2 Packet-Switch Capable-2 (PSC-2) 187 3 Packet-Switch Capable-3 (PSC-3) 188 4 Packet-Switch Capable-4 (PSC-4) 189 51 Layer-2 Switch Capable (L2SC) 190 100 Time-Division-Multiplex Capable (TDM) 191 150 Lambda-Switch Capable (LSC) 192 200 Fiber-Switch Capable (FSC) 194 The Encoding field contains one of the values specified in Section 195 3.1.1 of [GMPLS-SIG]. 197 Maximum LSP Bandwidth is encoded as a list of eight 4 octet fields in 198 the IEEE floating point format [IEEE], with priority 0 first and 199 priority 7 last. The units are bytes (not bits!) per second. 201 The content of the Switching Capability specific information field 202 depends on the value of the Switching Capability field. 204 When the Switching Capability field is PSC-1, PSC-2, PSC-3, or PSC-4, 205 the Switching Capability specific information field includes Minimum 206 LSP Bandwidth and Interface MTU. 208 0 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Minimum LSP Bandwidth | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Interface MTU | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 The Minimum LSP Bandwidth is is encoded in a 4 octets field in the 217 IEEE floating point format. The units are bytes (not bits!) per 218 second. The Interface MTU is encoded as a 2 octets integer, and 219 carries the MTU value in the units of bytes. 221 When the Switching Capability field is L2SC, there is no Switching 222 Capability specific information field present. 224 When the Switching Capability field is TDM, the Switching Capability 225 specific information field includes Minimum LSP Bandwidth and an 226 indication whether the interface supports Standard or Arbitrary 227 SONET/SDH. 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Minimum LSP Bandwidth | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Indication | 235 +-+-+-+-+-+-+-+-+ 237 The Minimum LSP Bandwidth is encoded in a 4 octets field in the IEEE 238 floating point format. The units are bytes (not bits!) per second. 239 The indication whether the interface supports Standard or Arbitrary 240 SONET/SDH is encoded as 1 octet. The value of this octet is 0 if the 241 interface supports Standard SONET/SDH, and 1 if the interface 242 supports Arbitrary SONET/SDH. 244 When the Switching Capability field is LSC, there is no Switching 245 Capability specific information field present. 247 To support interfaces that have more than one Interface Switching 248 Capability Descriptor (see Section "Interface Switching Capability 249 Descriptor" of [GMPLS-ROUTING]) the Interface Switching Capability 250 Descriptor sub-TLV MAY occur more than once within the extended IS 251 reachability TLV. 253 1.4. Shared Risk Link Group TLV 255 The SRLG TLV (of type 138 TBD) contains a data structure consisting 256 of: 258 6 octets of System ID 259 1 octet of Pseudonode Number 260 1 octet Flag 261 4 octets of IPv4 interface address or 4 octets of a Link Local 262 Identifier 263 4 octets of IPv4 neighbor address or 4 octets of a Link Remote 264 Identifier 265 (variable) list of SRLG values, where each element in the list 266 has 4 octets. 268 The following illustrates encoding of the Value field of the SRLG 269 TLV. 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | System ID | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | System ID (cont.) | Pseudonode num| Flags | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | IPv4 interface address/Link Local Identifier | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | IPv4 neighbors address/Link Remote Identifier | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Shared Risk Link Group Value | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | ............ | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Shared Risk Link Group Value | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 The neighbor is identified by its System Id (6-octets), plus one 290 octet to indicate the pseudonode number if the neighbor is on a LAN 291 interface. 293 The Least Significant Bit of the Flag octet indicates whether the 294 interface is numbered (set to 1), or unnumbered (set to 0). All 295 other bits are reserved and should be set to 0. 297 The length of this TLV is 16 + 4 * (number of SRLG values). 299 This TLV carries the Shared Risk Link Group information (see Section 300 "Shared Risk Link Group Information" of [GMPLS-ROUTING]). 302 The SRLG TLV MAY occur more than once within the IS-IS Link State 303 Protocol Data Units. 305 1.5. Link Identifier for Unnumbered Interfaces 307 Link Identifiers are exchanged in the Extended Local Circuit ID field 308 of the "Point-to-Point Three-Way Adjacency" IS-IS Option type 309 [ISIS-3way]. 311 2. Implications on Graceful Restart 313 The restarting node SHOULD follow the ISIS restart procedures 314 [ISIS-RESTART], and the RSVP-TE restart procedures [GMPLS-RSVP]. 316 When the restarting node is going to originate its IS-IS Link State 317 Protocol data units for TE links, these Link State Protocol data 318 units SHOULD be originated with 0 unreserved bandwidth, Traffic 319 Engineering Default metric set to 0xffffff, and if the link has LSC 320 or FSC as its Switching Capability then also with 0 as Max LSP 321 Bandwidth, until the node is able to determine the amount of 322 unreserved resources taking into account the resources reserved by 323 the already established LSPs that have been preserved across the 324 restart. Once the restarting node determines the amount of 325 unreserved resources, taking into account the resources reserved by 326 the already established LSPs that have been preserved across the 327 restart, the node SHOULD advertise these resources in its Link State 328 Protocol data units. 330 In addition in the case of a planned restart prior to restarting, the 331 restarting node SHOULD originate the IS-IS Link State Protocol data 332 units for TE links with 0 as unreserved bandwidth, and if the link 333 has LSC or FSC as its Switching Capability then also with 0 as Max 334 LSP Bandwidth. This would discourage new LSP establishment through 335 the restarting router. 337 Neighbors of the restarting node SHOULD continue advertise the actual 338 unreserved bandwidth on the TE links from the neighbors to that node. 340 3. Contributors 342 Ayan Banerjee 343 Calient Networks 344 5853 Rue Ferrari 345 San Jose, CA 95138 346 Phone: +1 408 972 3645 347 EMail: abanerjee@calient.net 349 John Drake 350 Calient Networks 351 5853 Rue Ferrari 352 San Jose, CA 95138 353 Phone: +1 408 972 3720 354 EMail: jdrake@calient.net 355 Greg Bernstein 356 Grotto Networking 357 EMail: gregb@grotto-networking.com 359 Don Fedyk 360 Nortel Networks Corp. 361 600 Technology Park Drive 362 Billerica, MA 01821 363 Phone: +1 978 288 4506 364 EMail: dwfedyk@nortelnetworks.com 366 Eric Mannie 367 Independent Consultant 368 E-mail: eric_mannie@hotmail.com 369 Debanjan Saha 370 Tellium Optical Systems 371 2 Crescent Place 372 P.O. Box 901 373 Ocean Port, NJ 07757 374 Phone: +1 732 923 4264 375 EMail: dsaha@tellium.com 377 Vishal Sharma 378 EMail: v.sharma@ieee.org 380 4. Acknowledgements 382 The authors would like to thank Jim Gibson, Suresh Katukam, Jonathan 383 Lang and Quaizar Vohra for their comments on the draft. 385 5. Security Considerations 387 This document specifies the contents of GMPLS TE TLVs in ISIS. As 388 these TLVs are not used for SPF computation or normal routing, the 389 extensions specified here have no direct effect on IP routing. 390 Tampering with GMPLS TE TLVs may have an effect on the underlying 391 transport (optical and/or SONET-SDH) network. Mechanisms to secure 392 ISIS Link State PDUs and/or the TE TLVs can be used to secure the 393 GMPLS TE TLVs as well. 395 6. IANA Considerations 397 This document defines the following new ISIS TLV type that needs to 398 be reflected in the ISIS TLV code-point registry: 399 Type Description IIH LSP SNP 400 ---- ---------------------- --- --- --- 401 138 Shared Risk Link Group n y n 403 This document also defines the following new sub-TLV types of 404 top-level TLV 22 that need to be reflected in the ISIS sub-TLV 405 registry for TLV 22: 406 Type Description Length 407 ---- ------------------------------ -------- 408 4 Link Local/Remote Identifiers 8 409 20 Link Protection Type 2 410 21 Interface Switching Capability variable 411 Descriptor 413 Normative References 415 [GMPLS-ROUTING] Kompella, K., and Rekhter, Y. (Editors), "Routing 416 Extensions in Support of Generalized Multi-Protocol Label 417 Switching", (work in progress) [draft-ietf-ccamp-gmpls- 418 routing-08.txt] 420 [GMPLS-RSVP] Berger, L., (Editor), "Generalized Multi-Protocol Label 421 Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic 422 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003 424 [GMPLS-SIG] Berger, L. (Editor), "Generalized Multi-Protocol Label 425 Switching (GMPLS) Signaling Functional Description", RFC 3471, 426 January 2003 428 [IEEE] IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", 429 Standard 754-1985, 1985 (ISBN 1-5593-7653-8) 431 [ISIS-3way] Katz, D., and Saluja, R., "Three-Way Handshake for 432 Intermediate System to Intermediate System (IS-IS) Point-to-Point 433 Adjacencies", RFC 3373, September 2002 435 [ISIS-RESTART] Shand, M. and L. Ginsburg, "Restart signaling for 436 ISIS", (work in progress) [draft-ietf-isis-restart-04.txt] 438 [ISIS-TE] Smit, H., Li, T., "IS-IS Extensions for Traffic 439 Engineering", (work in progress) [draft-ietf-isis-traffic-05.txt] 441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", BCP 14, RFC 2119, March 1997. 444 Authors' Information 446 Kireeti Kompella 447 Juniper Networks, Inc. 448 1194 N. Mathilda Ave 449 Sunnyvale, CA 94089 450 EMail: kireeti@juniper.net 452 Yakov Rekhter 453 Juniper Networks, Inc. 454 1194 N. Mathilda Ave 455 Sunnyvale, CA 94089 456 EMail: yakov@juniper.net 458 Intellectual Property Rights Notices 460 The IETF takes no position regarding the validity or scope of any 461 intellectual property or other rights that might be claimed to 462 pertain to the implementation or use of the technology described in 463 this document or the extent to which any license under such rights 464 might or might not be available; neither does it represent that it 465 has made any effort to identify any such rights. Information on the 466 IETF's procedures with respect to rights in standards-track and 467 standards-related documentation can be found in BCP-11. Copies of 468 claims of rights made available for publication and any assurances of 469 licenses to be made available, or the result of an attempt made to 470 obtain a general license or permission for the use of such 471 proprietary rights by implementors or users of this specification can 472 be obtained from the IETF Secretariat. 474 The IETF invites any interested party to bring to its attention any 475 copyrights, patents or patent applications, or other proprietary 476 rights which may cover technology that may be required to practice 477 this standard. Please address the information to the IETF Executive 478 Director. 480 Full Copyright Statement 482 Copyright (C) The Internet Society (2003). All Rights Reserved. 484 This document and translations of it may be copied and furnished to 485 others, and derivative works that comment on or otherwise explain it 486 or assist in its implementation may be prepared, copied, published 487 and distributed, in whole or in part, without restriction of any 488 kind, provided that the above copyright notice and this paragraph are 489 included on all such copies and derivative works. However, this 490 document itself may not be modified in any way, such as by removing 491 the copyright notice or references to the Internet Society or other 492 Internet organizations, except as needed for the purpose of 493 developing Internet standards in which case the procedures for 494 copyrights defined in the Internet Standards process must be 495 followed, or as required to translate it into languages other than 496 English. 498 The limited permissions granted above are perpetual and will not be 499 revoked by the Internet Society or its successors or assignees. 501 This document and the information contained herein is provided on an 502 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 503 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 504 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 505 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 506 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 508 Acknowledgement 510 Funding for the RFC Editor function is currently provided by the 511 Internet Society.