idnits 2.17.1 draft-ietf-opes-architecture-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack 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 368: '... in-band annotation MAY require header...' RFC 2119 keyword, line 371: '... response flow SHALL NOT interfere w...' RFC 2119 keyword, line 373: '...content consumer MAY use OPES extensio...' RFC 2119 keyword, line 374: '...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 180 has weird spacing: '...tion is maint...' == Line 268 has weird spacing: '...ll data filte...' == Line 271 has weird spacing: '...ehavior the O...' == Line 322 has weird spacing: '...sulated appli...' == (3 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 19, 2002) is 7974 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 519, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 528, 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 (~~), 10 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 18, 2002 R. Chen 5 AT&T Labs 6 M. Hofmann 7 Bell Labs/Lucent Technologies 8 H. Orman 9 Purple Streak Development 10 R. Penno 11 Nortel Networks 12 G. Tomlinson 13 The Tomlinson Group 14 June 19, 2002 16 An Architecture for Open Pluggable Edge Services (OPES) 17 draft-ietf-opes-architecture-02 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 18, 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.1.1 Data Dispatcher . . . . . . . . . . . . . . . . . . . . . . 5 58 2.2 OPES Flows . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 2.3 OPES Rules . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 2.4 Callout Servers . . . . . . . . . . . . . . . . . . . . . . 8 61 2.5 Tracing Facility . . . . . . . . . . . . . . . . . . . . . . 10 62 3. Security and Privacy Considerations . . . . . . . . . . . . 12 63 3.1 Trust Domains . . . . . . . . . . . . . . . . . . . . . . . 12 64 3.2 Callout protocol . . . . . . . . . . . . . . . . . . . . . . 13 65 3.3 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 13 66 3.4 Establishing trust . . . . . . . . . . . . . . . . . . . . . 13 67 3.5 End-to-end Integrity . . . . . . . . . . . . . . . . . . . . 14 68 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 References . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 71 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 72 Full Copyright Statement . . . . . . . . . . . . . . . . . . 19 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. The customization step might be 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. In [1] a description of 91 several scenarios is provided. 93 This 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.5) 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 specify when and how to execute OPES 116 intermediary services. 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.1.1 Data Dispatcher 174 Data dispatchers include a ruleset that can be compiled from several 175 sources and must resolve into an unambiguous result. The compiled 176 ruleset enables an OPES processor to determine which service 177 applications to invoke for which data flow. Accordingly, the data 178 dispatcher constitutes an enhanced policy enforcement point, where 179 policy rules are evaluated, service-specific data handlers and state 180 information is maintained, as depicted in Figure 2. 182 --------------------------------------------------------------------- 184 +----------+ 185 | callout | 186 | server | 187 +----------+ 188 || 189 || 190 || 191 || 192 +--------------------------+ 193 | +----------+ || | 194 | | OPES | || | 195 | | service | || | 196 | | appl | || | 197 | +----------+ || | 198 | +----------------------+ | 199 OPES flow <---->| | data dispatcher and | |<----> OPES flow 200 | | policy enforcement | | 201 | +----------------------+ | 202 | OPES | 203 | processor | 204 +--------------------------+ 206 Figure 2: Data Dispatchers 208 --------------------------------------------------------------------- 210 The architecture allows more than one policy enforcement point to be 211 present on an OPES flow. 213 2.2 OPES Flows 215 An OPES flow is a cooperative undertaking between a data provider 216 application, a data consumer application, zero or more OPES service 217 applications, and zero or more data dispatchers. 219 In order to understand the trust relationships between OPES entities, 220 each is labeled as residing in an administrative domain. Entities 221 associated with a given OPES flow may reside in one or more 222 administrative domains. 224 For example, Figure 2 depicts a data flow (also known as an "OPES 225 flow"), that spans two administrative domains. 227 --------------------------------------------------------------------- 229 consumer administrative domain provider administrative domain 230 +------------------------------+ +------------------------------+ 231 | | | | 232 | data OPES | | OPES data | 233 | consumer processor | | processor provider | 234 | | | | 235 | +----------+ +--------+ | | +--------+ +----------+ | 236 | | data | | OPES | | | | OPES | | data | | 237 | | consumer | |service | | | |service | | provider | | 238 | | appl | | appl | | | | appl | | appl | | 239 | +----------+ +--------+ | | +--------+ +----------+ | 240 | | | | | | | | | | | | 241 | | HTTP | | HTTP | | | | HTTP | | HTTP | | 242 | | | | | | | | | | | | 243 | +----------+ +--------+ | | +--------+ +----------+ | 244 | | TCP/IP | | TCP/IP | | | | TCP/IP | | TCP/IP | | 245 | +----------+ +--------+ | | +--------+ +----------+ | 246 | || || || | | || || || | 247 | ============= ================= ============= | 248 | | | | 249 +------------------------------+ +------------------------------+ 250 | <----------------- OPES flow -----------------> | 252 Figure 3: An OPES flow 254 --------------------------------------------------------------------- 256 Figure 3 depicts two data dispatchers that are present in the OPES 257 flow. However, the architecture allows for zero or more data 258 dispatchers to be present in any flow. 260 2.3 OPES Rules 262 OPES policy regarding services and the data provided to them is 263 determined by a ruleset consisting of OPES rules. The rules consist 264 of a set of conditions and related actions. The ruleset is the 265 superset of all OPES rules on the processor. The OPES ruleset 266 determines which service applications will operate on a data stream. 267 The communication of data stream elements to an application is 268 performed by data dispatchers. In this model, all data filters are 269 invoked for all data. 271 In order to ensure predictable behavior the OPES architecture 272 requires the use of a standardized schema for the purpose of defining 273 and interpreting the ruleset. The OPES architecture does not require 274 a mechanism for configuring a ruleset into a data dispatcher. This 275 is treated as a local matter for each implementation (e.g., through 276 the use of a text editor, secure upload protocol, and so on). Future 277 revisions of the architecture may introduce such a requirement. 279 2.4 Callout Servers 281 The evaluation of OPES ruleset determines which service applications 282 will operate on a data stream. How the ruleset is evaluated is not 283 the subject of the architecture, except to note that it must result 284 in the same unambiguous result in all implementations. 286 In some cases it may be useful for the OPES processor to distribute 287 the responsibility of service evaluation by communicating with one or 288 more callout servers (cf., [7]). The situation is illustrated in 289 Figure 4, which shows a data dispatcher communicating with multiple 290 callout servers as it processes an OPES flow. 292 --------------------------------------------------------------------- 294 data callout callout callout 295 dispatcher server server server 297 +----------+ +---------+ +---------+ +---------+ 298 | | | | | | | | 299 | OCP | | OCP | | OCP | ... | OCP | 300 | | | | | | | | 301 +----------+ +---------+ +---------+ +---------+ 302 | Lower | | Lower | | Lower | | Lower | 303 | Layer | | Layer | | Layer | | Layer | 304 |Protocols | |Protocols| |Protocols| |Protocols| 305 | . | | . | | . | | . | 306 | . | | . | | . | | . | 307 +----------+ +---------+ +---------+ +---------+ 308 || || || || 309 ||================ || ... || 310 || || || 311 ||============================== || 312 || || 313 ================================================ 315 Figure 4: An OPES flow with Callout servers 317 --------------------------------------------------------------------- 319 In Figure 4, a data dispatcher invokes the services of a callout 320 server by using the OPES callout protocol (OCP). The requirements 321 for the OCP are given in [7]. The OCP is application-agnostic, being 322 unaware of the semantics of the encapsulated application protocol 323 (e.g., HTTP). However, the OCP must incorporate a service aware 324 vectoring capability that parses the data flow according to the 325 ruleset and delivers the data to the OPES service application that 326 can be local or remote. 328 In this model, OPES applications may be executed either on the same 329 processor (or even in the same application environment) with the 330 dispatcher or on a different OPES processor through OCP. The general 331 interaction situation is depicted in Figure 5, which illustrates the 332 positions and interaction of different components of OPES 333 architecture. 335 --------------------------------------------------------------------- 337 +--------------------------+ 338 | +----------+ | 339 | | OPES | | 340 | | service | | +----------------+ 341 | | appl | | | Callout Server | 342 | +----------+ | | | 343 | || | | +--------+ | 344 | +----------------------+ | | | OPES | | 345 | | data dispatcher | | | | Service| | 346 | +----------------------+ | | | App2 | | 347 | | HTTP | OCP | | | +--------+ | 348 | +------------| |==========| OCP | | 349 | | |---------+ | | +--------+ | 350 | | TCP/IP | | +----------------+ 351 =========| |=============== OPES Data Flow ==== 352 | +------------+ | 353 +--------------------------+ 355 Figure 5: Interaction of OPES Entities 357 --------------------------------------------------------------------- 359 2.5 Tracing Facility 361 The OPES architecture requires that each data dispatcher to provide 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 Providing the ability for in-band annotation MAY require header 369 extensions on the application protocol that is used (e.g., HTTP). 370 However, the presence of an OPES processor in the data request/ 371 response flow SHALL NOT interfere with the operations of non-OPES 372 aware clients and servers. OPES processors, content server and 373 content consumer MAY use OPES extensions to the base protocol (HTTP), 374 but support of these extensions SHALL NOT be required. 376 OPES processors must obey tracing, reporting and notification 377 requirements set by the center of authority in the trust domain to 378 which OPES processor belongs. As part of these requirements OPES 379 processor may be instructed to reject or ignore such requirements 380 that originate from other trust domains. 382 3. Security and Privacy Considerations 384 Each data flow must be secured in accordance with several policies. 385 The primary stakeholders are the data consumer and the data provider. 386 The secondary stakeholders are the entities to which they may have 387 delegated their trust. The other stakeholders are the owners of the 388 callout servers. Any of these parties may be participants in the 389 OPES architecture. 391 These parties must have a model, explicit or implicit, describing 392 their trust policy; which of the other parties are trusted to operate 393 on data, and what security enhancements are required for 394 communication. The trust might be delegated for all data, or it 395 might be restricted to granularity as small as an application data 396 unit. 398 All parties that are involved in enforcing policies must communicate 399 the policies to the parties that are involved. These parties are 400 trusted to adhere to the communicated policies. 402 In order to delegate fine-grained trust, the parties must convey 403 policy information by implicit contract, by a setup protocol, by a 404 dynamic negotiation protocol, or in-line with application data 405 headers. 407 3.1 Trust Domains 409 The delegation of authority starts at either a data consumer or data 410 provider and moves to more distant entities in a "stepwise" fashion. 411 Stepwise means A delegates to B and B delegates to C and so forth. 412 The entities thus "colored" by the delegation are said to form a 413 trust domain with respect to the original delegating party. Here, 414 "Colored" means that if the first step in the chain is the data 415 provider, then the stepwise delegation "colors" the chain with that 416 data "provider" color. The only colors that are defined are the data 417 "provider" and the data "consumer". Delegation of authority 418 (coloring) propagates from the content producer start of authority or 419 from the content consumer start of authority, that may be different 420 from the end points in the data flow. 422 An OPES processor may be in several trust domains at any time. There 423 is no restriction on whether the OPES processors are authorized by 424 data consumers and/or data providers. The original party has the 425 option of forbidding or limiting redelegation. 427 An OPES processor must have a representation of its trust domain 428 memberships that it can report in whole or in part for tracing 429 purposes. It must include the name of the party which delegated each 430 privilege to it. 432 3.2 Callout protocol 434 The determination of whether or not OPES processors will use the 435 measures that are described in the previous section during their 436 communication with callout servers depends on the details of how the 437 primary parties delegated trust to the OPES processors and the trust 438 relationship between the OPES processors and the callout server. If 439 the OPES processors are in a single administrative domain with strong 440 confidentiality guarantees, then encryption may be optional. In 441 other cases, encryption and strong authentication would be at least 442 strongly recommended. 444 If the delegation mechanism names the trusted parties and their 445 privileges in some way that permits authentication, then the OPES 446 processors will be responsible for enforcing the policy and for using 447 authentication as part of that enforcement. 449 The callout servers must be aware of the policy governing the 450 communication path. They must not, for example, communicate 451 confidential information to auxiliary servers outside the trust 452 domain. 454 A separate security association must be used for each channel 455 established between an OPES processor and a callout server. The 456 channels must be separate for different primary parties. 458 3.3 Privacy 460 Some data from data consumers is considered "private" or "sensitive", 461 and OPES processors must both advise the primary parties of the their 462 privacy policy and respect the policies of the primary parties. The 463 privacy information must be conveyed on a per-flow basis. 465 The callout servers must also participate in handling of private 466 data, and they must be prepared to announce their own capabilities 467 and to enforce the policy required by the primary parties. 469 3.4 Establishing trust 471 The OPES processor will have configuration policy specifying what 472 privileges the callout servers have and how they are to be 473 identified. This is especially critical for third-party (fourth- 474 party, etc.) callout servers. OPES uses standard protocols for 475 authenticating and otherwise security communication with callout 476 servers. 478 An OPES processor will have a trusted method for receiving 479 configuration information such as rules for the data dispatcher, 480 trusted callout servers, primary parties that opt-in or opt-out of 481 individual services, etc. 483 3.5 End-to-end Integrity 485 Digital signature techniques can be used to mark data changes in such 486 a way that a third-party can verify that the changes are or are not 487 consistent with the originating party's policy. This requires an 488 inline manner of specifying policy and its binding to data, a trace 489 of changes and the party making the changes, and strong identities 490 and authentication methods. 492 Strong end-to-end integrity can fulfill some of the functions 493 required by "tracing". 495 4. Summary 497 Although the architecture supports a wide range of cooperative 498 transformation services, it has few requirements for 499 interoperability. 501 The necessary and sufficient elements are specified in the following 502 documents: 504 o the OPES ruleset schema [6] which defines the syntax and semantics 505 of the rules interpreted by a data dispatcher; and, 507 o the OPES callout protocol (OCP) [7] which defines the protocol 508 between a data dispatcher and a callout server. 510 References 512 [1] McHenry, S., et. al, "OPES Scenarios and Use Cases", Internet- 513 Draft TBD, May 2002. 515 [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy 516 Considerations for Open Pluggable Edge Services", RFC 3238, 517 January 2002. 519 [3] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., 520 Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. 521 Waldbusser, "Terminology for Policy-Based Management", RFC 3198, 522 November 2001. 524 [4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 525 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 526 HTTP/1.1", RFC 2616, June 1999. 528 [5] OPES working group, "OPES Service Authorization and Enforcement 529 Requirements", Internet-Draft TBD, May 2002. 531 [6] OPES working group, "OPES Ruleset Schema", Internet-Draft TBD, 532 May 2002. 534 [7] A. Beck et al., "Requirements for OPES Callout Protocols", 535 Internet-Draft http://www.ietf.org/internet-drafts/draft-ietf- 536 opes-protocol-reqs-00.txt, May 2002. 538 Authors' Addresses 540 Abbie Barbir 541 Nortel Networks 542 3500 Carling Avenue 543 Nepean, Ontario K2H 8E9 544 Canada 546 Phone: +1 613 763 5229 547 EMail: abbieb@nortelnetworks.com 548 Robin Chen 549 AT&T Labs 550 Room E219, 180 Park Avenue 551 Florham Park, NJ 07932 552 US 554 Phone: +1 973 360 8653 555 EMail: chen@research.att.com 557 Markus Hofmann 558 Bell Labs/Lucent Technologies 559 Room 4F-513 560 101 Crawfords Corner Road 561 Holmdel, NJ 07733 562 US 564 Phone: +1 732 332 5983 565 EMail: hofmann@bell-labs.com 567 Hilarie Orman 568 Purple Streak Development 570 EMail: ho@alum.mit.edu 572 Reinaldo Penno 573 Nortel Networks 574 4555 Great America Parkway 575 Santa Clara, CA 95054 576 US 578 EMail: rpenno@nortelnetworks.com 580 Gary Tomlinson 581 The Tomlinson Group 583 EMail: gary@tomlinsongroup.net 585 Appendix A. Acknowledgements 587 The authors gratefully acknowledge the contributions of: Marshall T. 588 Rose, John Morris, Oskar Batuner, Mark Baker and Ian Cooper. 590 Full Copyright Statement 592 Copyright (C) The Internet Society (2002). All Rights Reserved. 594 This document and translations of it may be copied and furnished to 595 others, and derivative works that comment on or otherwise explain it 596 or assist in its implementation may be prepared, copied, published 597 and distributed, in whole or in part, without restriction of any 598 kind, provided that the above copyright notice and this paragraph are 599 included on all such copies and derivative works. However, this 600 document itself may not be modified in any way, such as by removing 601 the copyright notice or references to the Internet Society or other 602 Internet organizations, except as needed for the purpose of 603 developing Internet standards in which case the procedures for 604 copyrights defined in the Internet Standards process must be 605 followed, or as required to translate it into languages other than 606 English. 608 The limited permissions granted above are perpetual and will not be 609 revoked by the Internet Society or its successors or assigns. 611 This document and the information contained herein is provided on an 612 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 613 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 614 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 615 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 616 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 618 Acknowledgement 620 Funding for the RFC Editor function is currently provided by the 621 Internet Society.