idnits 2.17.1 draft-ietf-opes-architecture-01.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 18 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 371: '... in-band annotation MAY require header...' RFC 2119 keyword, line 374: '... response flow SHALL NOT interfere w...' RFC 2119 keyword, line 376: '...content consumer MAY use OPES extensio...' RFC 2119 keyword, line 377: '...these extensions SHALL NOT be required...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 141 has weird spacing: '...ntation stack...' == Line 227 has weird spacing: '...ll data filte...' == Line 230 has weird spacing: '...ehavior the O...' == Line 277 has weird spacing: '...sulated appli...' == Line 278 has weird spacing: '...CP must incor...' == (2 more instances...) -- 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 (June 11, 2002) is 7989 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) == Unused Reference: '3' is defined on line 522, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 531, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Informational RFC: RFC 3238 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 3198 (ref. '3') ** Obsolete normative reference: RFC 2616 (ref. '4') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Abbie. Barbir 3 Internet-Draft Nortel Networks 4 Expires: December 10, 2002 R. Chen 5 AT&T Labs 6 M. Hofmann 7 Bell Labs/Lucent Technologies 8 H. Orman 9 The Purple Streak Development 10 R. Penno 11 Nortel Networks 12 G. Tomlinson 13 Cacheflow 14 June 11, 2002 16 An Architecture for Open Pluggable Edge Services (OPES) 17 draft-ietf-opes-architecture-01 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at http:// 35 www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on December 10, 2002. 42 Copyright Notice 44 Copyright (C) The Internet Society (2002). All Rights Reserved. 46 Abstract 48 This memo defines an architecture for a cooperative application 49 service in which a data provider, a data consumer, and zero or more 50 application entities cooperatively realize a data stream service. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. The Architecture . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1 OPES Entities . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2 OPES Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.3 OPES Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 2.4 Callout Servers . . . . . . . . . . . . . . . . . . . . . . . 7 60 2.5 Policy Enforcement . . . . . . . . . . . . . . . . . . . . . . 8 61 2.6 Tracing Facility . . . . . . . . . . . . . . . . . . . . . . . 9 62 3. Security and Privacy Considerations . . . . . . . . . . . . . 11 63 3.1 Trust Domains . . . . . . . . . . . . . . . . . . . . . . . . 11 64 3.2 Callout protocol . . . . . . . . . . . . . . . . . . . . . . . 12 65 3.3 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 3.4 Establishing trust . . . . . . . . . . . . . . . . . . . . . . 12 67 3.5 End-to-end Integrity . . . . . . . . . . . . . . . . . . . . . 13 68 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 71 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 72 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18 74 1. Introduction 76 When realizing a data stream service between a provider and a 77 consumer, the need may arise to provision the use of other 78 application entities, in addition to the provider and consumer. For 79 example, some party may wish to customize a data stream as a service 80 to a consumer, e.g., a service might customize the data based on the 81 customer's geographical locality (e.g., language) or resource 82 availability (e.g., display capabilities). 84 In some cases in may be beneficial to provide a customization service 85 at network location instead of deploying it at either the provider or 86 the consumer host. For certain services performed on end-user behalf 87 this may be the only option of service deployment. In this case, one 88 or more additional application entities may participate in the data 89 stream service. There are many possible provisioning scenarios which 90 make a data stream service attractive. The reader is referred to [1] 91 for a description of several scenarios. 93 The document presents the architectural components of Open Pluggable 94 Edge Services (OPES) that are needed in order to perform a data 95 stream service. The architecture addresses the IAB considerations 96 described in [2]. These considerations are covered in the various 97 parts of the document, specifically with respect to tracing (Section 98 2.6) and security considerations (Section 3). 100 The document is organized as follows: Section 2 introduces the OPES 101 architecture. Section 3 discusses security considerations. Section 102 4 provides a summary of the architecture and the requirements for 103 interoperability. 105 2. The Architecture 107 The architecture of Open Pluggable Edge Services (OPES) can be 108 described in terms of three interrelated concepts, mainly: 110 o OPES entities: processes operating in the network; 112 o OPES flows: data flows that are cooperatively realized by the 113 OPES entities; and, 115 o OPES rules: these determine how a given data flow is modified by 116 an OPES entity. 118 2.1 OPES Entities 120 An OPES entity is an application that operates on a data flow between 121 a data provider application and a data consumer application. OPES 122 entities can be one of the following: 124 o an OPES service application, which analyzes and possibly 125 transforms messages exchanged between the data provider 126 application and the data consumer application; or, 128 o a data dispatcher, which invokes an OPES service application based 129 on OPES ruleset and application-specific knowledge. 131 In the network, OPES entities reside inside OPES processors. The 132 cooperative behavior of OPES entities introduces additional 133 functionality for each data flow provided that it matches the OPES 134 rules. 136 In the current work, the data provider and data consumer applications 137 are not considered as OPES entities. The OPES architecture is 138 largely independent of the protocol that is used by the OPES entities 139 to exchange data. However, this document selects HTTP [4] as the 140 example protocol to be used for realizing a data flow. In this 141 regard, the logical implementation stack of an OPES entity is 142 summarized in Figure 1. 144 --------------------------------------------------------------------- 146 +-------------+ 147 |OPES service | 148 | Application | 149 | | 150 +-------------+ 151 | Data | 152 | Dispatcher | 153 | | 154 +-------------+ 155 | | 156 | HTTP | 157 | | 158 +-------------+ 159 | TCP/IP | 160 +-------------+ 161 | ... | 162 +-------------+ 164 Figure 1: OPES Logical Implementation 166 --------------------------------------------------------------------- 168 Figure 1 depicts a "minimal" stack for OPES. However, other 169 protocols may be present, depending on the functions that are 170 performed by the application. 172 2.2 OPES Flows 174 An OPES flow is a cooperative undertaking between a data provider 175 application, a data consumer application, zero or more OPES service 176 applications, and zero or more data dispatchers. 178 In order to understand the trust relationships between OPES entities, 179 each is labeled as residing in an administrative domain. Entities 180 associated with a given OPES flow may reside in one or more 181 administrative domains. 183 For example, Figure 2 depicts a data flow (also known as an "OPES 184 flow"), that spans two administrative domains. 186 --------------------------------------------------------------------- 188 consumer administrative domain provider administrative domain 189 +------------------------------+ +------------------------------+ 190 | | | | 191 | data OPES | | OPES data | 192 | consumer processor | | processor provider | 193 | | | | 194 | +----------+ +--------+ | | +--------+ +----------+ | 195 | | data | | OPES | | | | OPES | | data | | 196 | | consumer | |service | | | |service | | provider | | 197 | | appl | | appl | | | | appl | | appl | | 198 | +----------+ +--------+ | | +--------+ +----------+ | 199 | | | | | | | | | | | | 200 | | HTTP | | HTTP | | | | HTTP | | HTTP | | 201 | | | | | | | | | | | | 202 | +----------+ +--------+ | | +--------+ +----------+ | 203 | | TCP/IP | | TCP/IP | | | | TCP/IP | | TCP/IP | | 204 | +----------+ +--------+ | | +--------+ +----------+ | 205 | || || || | | || || || | 206 | ============= ================= ============= | 207 | | | | 208 +------------------------------+ +------------------------------+ 209 | <----------------- OPES flow -----------------> | 211 Figure 2: An OPES flow 213 --------------------------------------------------------------------- 215 Figure 2 depicts two data dispatchers that are present in the OPES 216 flow. However, the architecture allows for zero or more data 217 dispatchers to be present in any flow. 219 2.3 OPES Rules 221 OPES policy regarding services and the data provided to them is 222 determined by a ruleset consisting of OPES rules. The rules consist 223 of a set of conditions and related actions. The ruleset is the 224 superset of all OPES rules on the processor. The OPES ruleset 225 determines which service applications will operate on a data stream. 226 The communication of data stream elements to an application is 227 performed by data dispatchers. In this model, all data filters are 228 invoked for all data. 230 In order to ensure predictable behavior the OPES architecture 231 requires the use of a standardized schema for the purpose of defining 232 and interpreting the ruleset. The OPES architecture does not require 233 a mechanism for configuring a ruleset into a data dispatcher. This 234 is treated as a local matter for each implementation (e.g., through 235 the use of a text editor, secure upload protocol, and so on). Future 236 revisions of the architecture may introduce such a requirement. 238 2.4 Callout Servers 240 The evaluation of OPES ruleset determines which service applications 241 will operate on a data stream. How the ruleset is evaluated is not 242 the subject of the architecture, except to note that it must result 243 in the same unambiguous result in all implementations. 245 In some cases it may be useful for the OPES processor to distribute 246 the responsibility of service evaluation by communicating with one or 247 more callout servers (cf., [7]). The situation is illustrated in 248 Figure 3, which shows a data dispatcher communicating with multiple 249 callout servers as it processes an OPES flow. 251 --------------------------------------------------------------------- 253 data callout callout callout 254 dispatcher server server server 256 +----------+ +---------+ +---------+ +---------+ 257 | | | | | | | | 258 | OCP | | OCP | | OCP | ... | OCP | 259 | | | | | | | | 260 +----------+ +---------+ +---------+ +---------+ 261 | TCP/IP | | TCP/IP | | TCP/IP | | TCP/IP | 262 +----------+ +---------+ +---------+ +---------+ 263 || || || || 264 ||================ || ... || 265 || || || 266 ||============================== || 267 || || 268 ================================================ 270 Figure 3: An OPES flow with Callout servers 272 --------------------------------------------------------------------- 274 In Figure 3, a data dispatcher invokes the services of a callout 275 server by using the OPES callout protocol (OCP). The requirements 276 for the OCP are given in [7]. The OCP is application-agnostic, being 277 unaware of the semantics of the encapsulated application protocol 278 (e.g., HTTP). However, the OCP must incorporate a service aware 279 vectoring capability that parses the data flow according to the 280 ruleset and delivers the data to the OPES service application that 281 can be local or remote. 283 In this model, OPES applications may be executed either on the same 284 processor (or even in the same application environment) with the 285 dispatcher or on a different OPES processor through OCP. The general 286 interaction situation is depicted in Figure 4, which illustrates the 287 positions and interaction of different components of OPES 288 architecture. 290 --------------------------------------------------------------------- 292 +--------------------------+ 293 | +----------+ | 294 | | OPES | | 295 | | service | | +----------------+ 296 | | appl | | | Callout Server | 297 | +----------+ | | | 298 | || | | +--------+ | 299 | +----------------------+ | | | OPES | | 300 | | data dispatcher | | | | Service| | 301 | +----------------------+ | | | App2 | | 302 | | HTTP | OCP | | | +--------+ | 303 | +------------| |==========| OCP | | 304 | | |---------+ | | +--------+ | 305 | | TCP/IP | | +----------------+ 306 =========| |=============== OPES Data Flow ==== 307 | +------------+ | 308 +--------------------------+ 310 Figure 4: Interaction of OPES Entities 312 --------------------------------------------------------------------- 314 2.5 Policy Enforcement 316 Data dispatchers include a ruleset that can be compiled from several 317 sources and must resolve into an unambiguous result. The compiled 318 ruleset enables an OPES processor to determain which service 319 applications to invoke for which data flow. Accordingly, the data 320 dispatcher constitutes an enhanced Policy Enforcement Point (PEP), 321 where policy rules are evaluated, service-specific data handlers and 322 state information are maintained, as depicted in Figure 5. 324 --------------------------------------------------------------------- 326 +----------+ 327 | callout | 328 | server | 329 +----------+ 330 || 331 || 332 || 333 || 334 +---------------------------+ 335 | +----------+ || | 336 | | OPES | || | 337 | | service | || | 338 | | appl | || | 339 | +----------+ || | 340 | +----------------------+ | 341 OPES flow <---->| | data dispatcher/PEP | | <----> OPES flow 342 | +----------------------+ | 343 | OPES | 344 | processor | 345 +--------------------------+ 347 Figure 5: Data Dispatchers and Policy Enforcement Point 349 --------------------------------------------------------------------- 351 The architecture allows more than one PEP to be present on an OPES 352 flow. 354 2.6 Tracing Facility 356 The architecture makes no requirements as to how an OPES flow is 357 negotiated, provided that it is consistent with the security policy 358 (Section 3) of each administrative domain that hosts the OPES 359 entities that are associated with the flow. 361 The OPES architecture requires that each data dispatcher provides 362 tracing facilities that allow the appropriate verification of its 363 operation. The OPES architecture requires that tracing be feasible 364 on the OPES flow per OPES processor using in-band annotation. One 365 of those annotations could be a URL with more detailed information on 366 the transformation that occurred to the data on the OPES flow. 368 Future revisions of the architecture may provide for a tracing 369 facility to be used for subsequent out-of-band analysis. 371 Providing the ability for in-band annotation MAY require header 372 extensions on the application protocol that is used (e.g., HTTP). 373 However, the presence of an OPES processor in the data request/ 374 response flow SHALL NOT interfere with the operations of non-OPES 375 aware clients and servers. OPES processors, content server and 376 content consumer MAY use OPES extensions to the base protocol (HTTP), 377 but support of these extensions SHALL NOT be required. 379 OPES processors must obey tracing, reporting and notification 380 requirements set by the center of authority in the trust domain to 381 which OPES processor belongs. As part of these requirements OPES 382 processor may be instructed to reject or ignore such requirements 383 that originate from other trust domains. 385 3. Security and Privacy Considerations 387 Each data flow must be secured in accordance with several policies. 388 The primary stakeholders are the data consumer and the data provider. 389 The secondary stakeholders are the entities to which they may have 390 delegated their trust. The other stakeholders are the owners of the 391 callout servers. Any of these parties may be participants in the 392 OPES architecture. 394 These parties must have a model, explicit or implicit, describing 395 their trust policy; which of the other parties are trusted to operate 396 on data, and what security enhancements are required for 397 communication. The trust might be delegated for all data, or it 398 might be restricted to granularity as small as an application data 399 unit. 401 All parties that are involved in enforcing policies must communicate 402 the policies to the parties that are involved. These parties are 403 trusted to adhere to the communicated policies. 405 In order to delegate fine-grained trust, the parties must convey 406 policy information by implicit contract, by a setup protocol, by a 407 dynamic negotiation protocol, or in-line with application data 408 headers. 410 3.1 Trust Domains 412 The delegation of authority starts at either a data consumer or data 413 provider and moves to more distant entities in a "stepwise" fashion. 414 Stepwise means A delegates to B and B delegates to C and so forth. 415 The entities thus "colored" by the delegation are said to form a 416 trust domain with respect to the original delegating party. Here, 417 "Colored" means that if the first step in the chain is the data 418 provider, then the stepwise delegation "colors" the chain with that 419 data "provider" color. The only colors that are defined are the data 420 "provider" and the data "consumer". Delegation of authority 421 (coloring) propagates from the content producer start of authority or 422 from the content consumer start of authority, that may be different 423 from the end points in the data flow. 425 An OPES processor may be in several trust domains at any time. There 426 is no restriction on whether the OPES processors are authorized by 427 data consumers and/or data providers. The original party has the 428 option of forbidding or limiting redelegation. 430 An OPES processor must have a representation of its trust domain 431 memberships that it can report in whole or in part for tracing 432 purposes. It must include the name of the party which delegated each 433 privilege to it. 435 3.2 Callout protocol 437 The determination of whether or not OPES processors will use the 438 measures that are described in the previous section during their 439 communication with callout servers depends on the details of how the 440 primary parties delegated trust to the OPES processors and the trust 441 relationship between the OPES processors and the callout server. If 442 the OPES processors are in a single administrative domain with strong 443 confidentiality guarantees, then encryption may be optional. In 444 other cases, encryption and strong authentication would be at least 445 strongly recommended. 447 If the delegation mechanism names the trusted parties and their 448 privileges in some way that permits authentication, then the OPES 449 processors will be responsible for enforcing the policy and for using 450 authentication as part of that enforcement. 452 The callout servers must be aware of the policy governing the 453 communication path. They must not, for example, communicate 454 confidential information to auxiliary servers outside the trust 455 domain. 457 A separate security association must be used for each channel 458 established between an OPES processor and a callout server. The 459 channels must be separate for different primary parties. 461 3.3 Privacy 463 Some data from data consumers is considered "private" or "sensitive", 464 and OPES processors must both advise the primary parties of the their 465 privacy policy and respect the policies of the primary parties. The 466 privacy information must be conveyed on a per-flow basis. 468 The callout servers must also participate in handling of private 469 data, and they must be prepared to announce their own capabilities 470 and to enforce the policy required by the primary parties. 472 3.4 Establishing trust 474 The OPES processor will have configuration policy specifying what 475 privileges the callout servers have and how they are to be 476 identified. This is especially critical for third-party (fourth- 477 party, etc.) callout servers. OPES uses standard protocols for 478 authenticating and otherwise security communication with callout 479 servers. 481 An OPES processor will have a trusted method for receiving 482 configuration information such as rules for the data dispatcher, 483 trusted callout servers, primary parties that opt-in or opt-out of 484 individual services, etc. 486 3.5 End-to-end Integrity 488 Digital signature techniques can be used to mark data changes in such 489 a way that a third-party can verify that the changes are or are not 490 consistent with the originating party's policy. This requires an 491 inline manner of specifying policy and its binding to data, a trace 492 of changes and the party making the changes, and strong identities 493 and authentication methods. 495 Strong end-to-end integrity can fulfill some of the functions 496 required by "tracing". 498 4. Summary 500 Although the architecture supports a wide range of cooperative 501 transformation services, it has few requirements for 502 interoperability. 504 The necessary and sufficient elements are specified in the following 505 documents: 507 o the OPES ruleset schema [6] which defines the syntax and semantics 508 of the rules interpreted by a data dispatcher; and, 510 o the OPES callout protocol (OCP) [7] which defines the protocol 511 between a data dispatcher and a callout server. 513 References 515 [1] McHenry, S., et. al, "OPES Scenarios and Use Cases", Internet- 516 Draft TBD, May 2002. 518 [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy 519 Considerations for Open Pluggable Edge Services", RFC 3238, 520 January 2002. 522 [3] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., 523 Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. 524 Waldbusser, "Terminology for Policy-Based Management", RFC 3198, 525 November 2001. 527 [4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 528 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 529 HTTP/1.1", RFC 2616, June 1999. 531 [5] OPES working group, "OPES Service Authorization and Enforcement 532 Requirements", Internet-Draft TBD, May 2002. 534 [6] OPES working group, "OPES Ruleset Schema", Internet-Draft TBD, 535 May 2002. 537 [7] OPES working group, "OPES Callout Protocol and Tracing Protocol 538 Requirements", Internet-Draft TBD, May 2002. 540 Authors' Addresses 542 Abbie Barbir 543 Nortel Networks 544 3500 Carling Avenue 545 Nepean, Ontario K2H 8E9 546 Canada 548 Phone: +1 613 763 5229 549 EMail: abbieb@nortelnetworks.com 551 Robin Chen 552 AT&T Labs 553 Room E219, 180 Park Avenue 554 Florham Park, NJ 07932 555 US 557 Phone: +1 973 360 8653 558 EMail: chen@research.att.com 559 Markus Hofmann 560 Bell Labs/Lucent Technologies 561 Room 4F-513 562 101 Crawfords Corner Road 563 Holmdel, NJ 07733 564 US 566 Phone: +1 732 332 5983 567 EMail: hofmann@bell-labs.com 569 Hilarie Orman 570 The Purple Streak Development 572 EMail: ho@alum.mit.edu 574 Reinaldo Penno 575 Nortel Networks 576 2305 Mission College Boulevard 577 San Jose, CA 95134 578 US 580 EMail: rpenno@nortelnetworks.com 582 Gary Tomlinson 583 Cacheflow 585 EMail: gary@tomlinsongroup.net 587 Appendix A. Acknowledgements 589 The authors gratefully acknowledge the contributions of: Marshall T. 590 Rose, John Morris, Oskar Batuner, Mark Baker and Ian Cooper. 592 Full Copyright Statement 594 Copyright (C) The Internet Society (2002). All Rights Reserved. 596 This document and translations of it may be copied and furnished to 597 others, and derivative works that comment on or otherwise explain it 598 or assist in its implementation may be prepared, copied, published 599 and distributed, in whole or in part, without restriction of any 600 kind, provided that the above copyright notice and this paragraph are 601 included on all such copies and derivative works. However, this 602 document itself may not be modified in any way, such as by removing 603 the copyright notice or references to the Internet Society or other 604 Internet organizations, except as needed for the purpose of 605 developing Internet standards in which case the procedures for 606 copyrights defined in the Internet Standards process must be 607 followed, or as required to translate it into languages other than 608 English. 610 The limited permissions granted above are perpetual and will not be 611 revoked by the Internet Society or its successors or assigns. 613 This document and the information contained herein is provided on an 614 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 615 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 616 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 617 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 618 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 620 Acknowledgement 622 Funding for the RFC Editor function is currently provided by the 623 Internet Society.