idnits 2.17.00 (12 Aug 2021) /tmp/idnits34841/draft-ietf-webi-idd-reqs-00.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (February 21, 2001) is 7752 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: '1' is defined on line 302, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 306, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 309, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (ref. '1') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Downref: Normative reference to an Informational RFC: RFC 3040 (ref. '2') -- Possible downref: Normative reference to a draft: ref. '3' Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. McManus 3 Internet-Draft AppliedTheory Corporation 4 Expires: August 22, 2001 M. Nottingham 5 Akamai Technologies, Inc. 6 February 21, 2001 8 Requirements for Intermediary Discovery and Description 9 draft-ietf-webi-idd-reqs-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 22, 2001. 34 Copyright Notice 36 Copyright (C) The Internet Society (2001). All Rights Reserved. 38 Abstract 40 World Wide Web (WWW) intermediaries (such as proxy caches, gateways, 41 and surrogate servers) are widely used by information providers, 42 transport providers, and information consumers to enhance the 43 characteristics of a web transaction. While there are firm models 44 and protocols for the interactions between these devices when they 45 are used, there is no common method used to discover what 46 intermediaries are available. This document establishes a set of 47 requirements for a system that would make discovery of application 48 level intermediaries by web clients efficient and practical. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Scoping Requirements . . . . . . . . . . . . . . . . . . . . . 5 55 4. Discovery Requirements . . . . . . . . . . . . . . . . . . . . 6 56 5. Description Requirements . . . . . . . . . . . . . . . . . . . 7 57 6. Rationale/Use Cases . . . . . . . . . . . . . . . . . . . . . 8 58 6.1 Small Network Configuration . . . . . . . . . . . . . . . . . 8 59 6.2 ISP Client Configuration . . . . . . . . . . . . . . . . . . . 8 60 6.3 Enterprise Client Configuration . . . . . . . . . . . . . . . 8 61 6.4 Surrogate Discovery . . . . . . . . . . . . . . . . . . . . . 9 62 6.5 Automated Mesh Building . . . . . . . . . . . . . . . . . . . 9 63 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 65 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11 67 1. Introduction 69 Intermediaries are commonly deployed to help scale the WWW. Lack of 70 mechanisms to control and communicate with them brings about 71 scalability issues with intermediaries themselves. Furthermore, 72 access providers who wish to provision caching proxies in their 73 networks have no standardized mechanism to announce such devices to 74 user agents. 76 As a result of this situation, many network operators resort to the 77 use of interception proxies, which break the end-to-end relationship 78 between client and server at the transport layer, leading to 79 undesired behaviors. Additionally such systems introduce significant 80 cost to override the transport layer and may significantly 81 under-utilize the flexibility of intermediary options that a client 82 has available to it. 84 This document establishes the functional requirements necessary to 85 build a system for the automatic discovery and description of 86 intermediaries by web clients that they may interact with. It also 87 defines a series of use cases and design goals appropriate to that 88 system. 90 Requirements for the description and discovery of intermediaries are 91 listed separately in this document, as they comprise two different 92 concepts. It is not assumed that these will, or will not, be 93 separate functions of an eventual system that satisfies these 94 requirements. 96 2. Terminology 98 Intermediary - An application level web device that is part of a 99 transaction but is neither the originating or terminating device 100 in the transaction. In HTTP, this includes proxies, surrogates 101 and other gateways but neither User-Agents or Origin Servers. 103 Discovery Mesh - A logical set of coordinated intermediaries, and 104 their attributes, that reside within a single administrative 105 domain. 107 Intermediary Discovery - The process of determining and keeping 108 current what devices are in a discovery mesh. 110 Intermediary Description - The process of conveying to a web 111 client the attributes, roles, and functionality of an 112 intermediary. 114 IDD Client - A device that seeks to interact with the discovery 115 mesh for either the purposes of providing or obtaining discovery 116 or definition information. 118 IDD Server - A device that may interact with clients on behalf of 119 a discovery mesh. 121 3. Scoping Requirements 123 1. In order to promote modular design and extensibility, some 124 separation in between the discovery and definition aspects of 125 any system fulfilling the requirements of this document should 126 be maintained. This requirement neither prohibits nor requires a 127 single protocol definition. 129 2. The IDD mechanism should be easy for people with a reasonable 130 amount of knowledge about Web technologies to grasp by 131 leveraging established technologies (e.g. HTTP, XML, URI, etc.) 132 where possible. 134 3. Server location of "downstream" intermediaries is out of scope. 136 4. Negotiation of features associated with modification of messages 137 by intermediaries are out of scope. 139 4. Discovery Requirements 141 1. The IDD protocol must not require unusual deployment 142 considerations. In particular, IP version 4 broadcast and 143 unicast must form a sufficient operating base. 145 2. The IDD protocol must provide web clients with a mechanism for 146 locating intermediaries and determining their description 147 properties. 149 3. The IDD protocol must provide support for an extensible variety 150 of application level web intermediaries. Initially, base 151 support for HTTP, ICP, and RTSP must be provided. 153 4. The IDD protocol should allow (semi-)automatic configuration in 154 simple networks, with appropriate software. 156 5. IDD clients must have at least one simple method of interaction 157 that does not require significant state or other processing 158 resources. This method should be suitable for embedded 159 applications. 161 6. The IDD protocol must be as robust as possible in the event of a 162 network partition of the discovery mesh. This requirement 163 includes the need for well-defined failure modes so that 164 clients have unambiguous information about the state of their 165 request. 167 7. Significant latency and processing loads to interact with the 168 discovery mesh are only acceptable upon IDD client 169 initialization. 171 8. The IDD protocol should allow incorporation of 172 externally-derived information where possible (network map, 173 etc..). 175 9. The IDD discovery mesh should have a mechanism for 176 (semi-)automatic update of itself. 178 10. The IDD protocol must support a wide diversity of timeliness 179 requirements for IDD clients to learn of changes to the 180 discovery mesh. At a minimum, a range of times from a few 181 seconds to several hours must be supported. 183 11. The IDD protocol must provide a mechanism for intermediaries to 184 restrict their discovery by IDD clients on an end-to-end basis, 185 without regard to the IDD server. 187 5. Description Requirements 189 1. The IDD description mechanism must provide web clients with a 190 method for determining which URIs a particular web client and 191 intermediary pair may resolve. 193 2. The IDD description mechanism must provide a method for IDD 194 clients to differentiate between surrogates and other more 195 general intermediaries. 197 3. The IDD description mechanism must provide a method for IDD 198 clients to determine if use of an intermediary is 199 administratively required. If it is required the IDD client must 200 be able to determine a specific path for satisfaction of that 201 requirement. 203 4. The IDD description mechanism should support determination of 204 "best" intermediary in a multi-faceted extensible way including 205 use of 207 * URI characteristics 209 * Network metrics 211 * Failover options 213 * Intermediary capacity 215 * Intermediary locality 217 * Protocols supported and their specific options (e.g. HTTP 218 method, version, transfer-encodings supported, etc.) 220 * Intermediary authentication and security capabilities 222 5. The IDD description mechanism should promote efficient use of 223 intermediaries by use of content bucketing, etc.. 225 6. The IDD description mechanism should provide IDD clients with a 226 notion of the freshness and perceived future validity of the 227 data it is serving. 229 6. Rationale/Use Cases 231 6.1 Small Network Configuration 233 A user or access provider wishes to route all HTTP requests through 234 a single proxy. If the proxy is not reachable, requests should be 235 able to be routed directly to their origin servers, but clients 236 should check with the proxy every minute to check its availability. 238 Deployment should be possible without significant network 239 reconfiguration, preferably by leveraging services already deployed, 240 such as DNS, DHCP, HTTP servers, etc. 242 The administrative domain in this example is scoped by the /24 243 network which the proxy serves, which may include both ethernet- and 244 dialup-connected connected clients. 246 6.2 ISP Client Configuration 248 An ISP has deployed a cache mesh to control bandwidth requirements. 249 Currently, all requests on port 80 are intercepted and redirected to 250 one of the proxies, but this does not capture all interesting 251 traffic, and causes problems with some applications. The ISP would 252 like to have greater control over proxy load balancing and failover 253 behaviours, and would also like to be able to route certain messages 254 to particular devices, in order to interpose value-added services 255 (such as protocol upgrades, transcoding, ad insertion, etc.). 257 Deployment must interoperate with the current interception solution 258 with a minimal amount of modification to established services. 260 The administrative domain in this example is all networks 261 connectected to the ISP's border routers, whose scope may be 262 expressed as IP blocks, or as those addresses which reverse-map to a 263 particular domain name. 265 6.3 Enterprise Client Configuration 267 An enterprise controls user access to Internet resources by 268 mandating use of proxies at its border firewalls. Additionally, a 269 cache mesh has been deployed internally to reduce internal network 270 load, as well as redistribute internally-sourced content, including 271 both HTTP and streaming. 273 Deployment should allow clients to locate an appropriate local 274 proxy, and then route messages through the mesh to the appropriate 275 border proxy or internal server, taking into account considerations 276 such as load balancing, failure recovery, client and content 277 locality. 279 The administrative domain here is all devices inside of the 280 firewall. 282 6.4 Surrogate Discovery 284 In any deployment (such as the others listed here), authorititive 285 intermediaries may be present (e.g., surrogates, as part of a CDN). 286 It would be desireable to be able to route appropriate messages to 287 them using IDD, rather than lower-layer mechanisms (such as DNS). 288 This allows tighter integration between the intermediaries and 289 clients, allowing more specific targetting of messages to the 290 appropriate device, without using these mechanisms. 292 6.5 Automated Mesh Building 294 Using IDD's description component, an intermediary vendor wishes to 295 specify a system which uses local context (e.g., IP/subnet 296 information) to help generate system configuration, and then combine 297 a number of these configurations to build and manage a caching mesh 298 in a semi-automated manner. 300 References 302 [1] Fielding, R. T., Gettys, J., Mogul, J. C., Nielsen, H. F., 303 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer 304 Protocol -- HTTP/1.1", RFC 2616, June 1999. 306 [2] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web 307 Replication and Caching Taxonomy", RFC 3040, January 2001. 309 [3] Gauthier, P., Cohen, J., Dunsmuir, M. and C. Perkins, "The Web 310 Proxy Auto-Discovery Protocol", draft-ietf-wrec-wpad-01.txt 311 (work in progress), July 1999. 313 Authors' Addresses 315 Patrick R. McManus 316 AppliedTheory Corporation 317 890 Winter Street 318 Waltham, MA 02451 319 USA 321 Phone: +1 781 839-7078 322 EMail: mcmanus@appliedtheory.com 324 Mark Nottingham 325 Akamai Technologies, Inc. 326 1400 Fashion Island Blvd 327 Suite 703 328 San Mateo, CA 94404 329 USA 331 Phone: +1 650 627-5247 332 EMail: mnot@akamai.com 334 Full Copyright Statement 336 Copyright (C) The Internet Society (2001). All Rights Reserved. 338 This document and translations of it may be copied and furnished to 339 others, and derivative works that comment on or otherwise explain it 340 or assist in its implementation may be prepared, copied, published 341 and distributed, in whole or in part, without restriction of any 342 kind, provided that the above copyright notice and this paragraph 343 are included on all such copies and derivative works. However, this 344 document itself may not be modified in any way, such as by removing 345 the copyright notice or references to the Internet Society or other 346 Internet organizations, except as needed for the purpose of 347 developing Internet standards in which case the procedures for 348 copyrights defined in the Internet Standards process must be 349 followed, or as required to translate it into languages other than 350 English. 352 The limited permissions granted above are perpetual and will not be 353 revoked by the Internet Society or its successors or assigns. 355 This document and the information contained herein is provided on an 356 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 357 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 358 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 359 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 360 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 362 Acknowledgement 364 Funding for the RFC editor function is currently provided by the 365 Internet Society.