Internet Draft Ingrid Melve Expires: August 1999 UNINETT Informational Gary Tomlinson WREC Working Group Novell February, 26 1999 Internet Web Replication and Caching Taxonomy draft-melve-wrec-taxonomy-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo specifies standard terminology and the current taxonomy of web replication and caching infrastructure deployed today. It introduces standard concepts and protocols uses today within this application domain. Currently deployed solutions employing this technologies are presented to establish a standard taxonomy. Research issues are covered in an accompanying document, and are not part of this document. This document presents open protocols and points to published RFCs for each protocol. Melve, Tomlinson [Page 1] Replication and Caching Taxonomy February 26, 1999 Contents 1. Introduction 2. Terminology 3. Distributed Relationships 4. Client to Replica Communication 5. Inter-Replica Communication 6. Client to Proxy Communication 7. Inter-Cache Communication 8. Network Element Communication 9. Common Policy Management 10. Security Considerations 11. Conclusion 12. References 13. Authors' Addresses 1. Introduction [Ed note: This is a work in progress. It is being collaboratively contributed to and edited within the WREC working group. This is the first draft released to the working group. It represents a rough template to use as a guide. There are a number of contributions needed by those in attendance at the Orlando kick off meeting, primarily relating to the proprietary protocols and submitted drafts.] 2. Terminology Where possible, existing definitions [5, 6] have been used in this document. Additional terminology has been agreed upon and defined in this document. All of the terminology used in this document is considered to be standardized with respect to IETF WREC working group RFCs. In this document a number of terms are used to refer to the roles played by participants in, and objects of, the HTTP communication. The following definitions are used in the HTTP/1.1 specification [6] : client An application program that establishes connections for the purpose of sending requests. user agent The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user tools. Melve, Tomlinson [Page 2] Replication and Caching Taxonomy February 26, 1999 server An application program that accepts connections in order to service requests by sending back responses. Any given program may be capable of being both a client and a server; our use of these terms refers only to the role being performed by the program for a particular connection, rather than to the program's capabilities in general. Likewise, any server may act as an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request. origin server The server on which a given resource resides or is to be created. proxy An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them, with possible translation, on to other servers. A proxy must interpret and, if necessary, rewrite a request message before forwarding it. Proxies are often used as client-side portals through network firewalls and as helper applications for handling requests via protocols not implemented by the user agent. tunnel An intermediary program which is acting as a blind relay between two connections. Once active, a tunnel is not considered a party to the HTTP communication, though the tunnel may have been initiated by an HTTP request. The tunnel ceases to exist when both ends of the relayed connections are closed. cache A program's local store of response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server may include a cache, though a cache cannot be used by a server while it is acting as a tunnel. To these definitions we add definitions specifically concerned with Web cache systems: cache mesh Melve, Tomlinson [Page 3] Replication and Caching Taxonomy February 26, 1999 a set of cooperating caching servers local Web cache server caching server running on the same LAN as a client local cache , first level Web cache server the Web cache server an end user client connects to [Ed note: confusion on usage of "local cache" and "user agent cache"] upper level Web cache server seen from the clients view, all caches participating in the caching mesh that are not the clients first level cache are upper level caches top-level Web cache server one or more servers in a hierarchical caching mesh, normally few requests are made to other caching servers from the top level, serves first level Web cache servers caching proxy A proxy with a cache, acting as server to the client, and client to the server. network element router or switch transparent proxying Transparency means that the user should not be aware of the existence of the proxy. traffic interception ??? proxy cluster load sharing, tightly coupled proxy mesh loosely coupled co-operating proxies out-of-path transparent caching proxy A transparent caching proxy not in the forwarding path between client and server. Used with a redirecting network element. redirecting network element A network element which intercepts web traffic and redirects it to an out-of-path transparent caching proxy. Melve, Tomlinson [Page 4] Replication and Caching Taxonomy February 26, 1999 Temporal Domain, sparse working set cache collection of caching machines storing temporarily, a subset of data sets [Ed note: this term is very difficult to capture in a concise articulate statement] Persistent Domain collection of origin servers maintaining complete persistent data sets [Ed note: this term is very difficult to capture in a concise articulate statement] Replica Origin Server origin server storing a persistent replica of a data set Browser A browser is a special instance of an end user client (a user agent) that acts as a content presentation device for the end user. Diffused Arrays tightly coupled array of caching proxy servers, acting logically as one service and partitioning the URL name space across the array [Ed note: The section above is incomplete and needs a lot of work. Need to use generic terms, seek agreement on terms.] 3. Distributed System Relationships Melve, Tomlinson [Page 5] Replication and Caching Taxonomy February 26, 1999 Diagram of the components that make up a web replication and caching infrastructure, with communication between the components. ------------------ ----------------- ------------------ | Replica Origin |-----| Master Origin |-----| Replica Origin | | Server | | Server | | Server | ------------------ ----------------- ------------------ \ | / \ | / ----------------------------------------- | Client to ----------------- Replica Server | Top-Level | | Caching Proxy | ----------------- / \ Inter Cache / \ Communication ----------------- ----------------- | Upper-Level |-----------| Upper-Level | | Caching Proxy | | Caching Proxy | ----------------- ----------------- / Inter Cache \ / Communication \ Inter Cache / \ Communication / \ / ------------------ \ / ------------------| \ ----------------- ----------------- || ----------------- | First Level |-----| Caching Proxy | |-----| First Level | | Caching Proxy | | Array |-- | Caching Proxy | ----------------- ----------------- ----------------- | Client to | | Proxy Cache | Cache to Network Element ------------- ------------ | Client | | Network | ------------- | Element | ------------ | | ------------ | Client | ------------ [Ed Note: This diagram is a first attempt. There is much work to do] Melve, Tomlinson [Page 6] Replication and Caching Taxonomy February 26, 1999 Client to Replica: cooperation and communication between clients (both browser/user agents and proxy caches) and replica origin servers. Used to discover optimal replica proximity. Persistent Domain Complete Idem-Potent Set Replication ------------------ ----------------- ------------------ | Replica Origin | | Master Origin | | Replica Origin | | Server | | Server | | Server | ------------------ ----------------- ------------------ \ | / \ | / ----------------------------------------- | Client to ----------------- Replica Server | Client | | | ----------------- Inter-Replica: cooperation and communication between replica origin servers. Used in replicating data sets between origin servers. Persistent Domain Complete Idem-Potent Set Replication ------------------ ----------------- ------------------ | Replica Origin |-----| Master Origin |-----| Replica Origin | | Server | | Server | | Server | ------------------ ----------------- ------------------ Client to Proxy: configuration, cooperation and communication between end user clients (browsers and applications) and a caching proxy. Temporal Domain Sparse Working Set Cache ----------------- ----------------- ----------------- | First Level | | First Level | | First Level | | Caching Proxy | | Caching Proxy | | Caching Proxy | ----------------- ----------------- ----------------- \ | / \ | / ----------------------------------------- | ----------------- | Client | ----------------- Melve, Tomlinson [Page 7] Replication and Caching Taxonomy February 26, 1999 Inter-Cache: cooperation and communication between caching proxies. Temporal Domain Sparse Working Set Cache ----------------- | Top-Level | | Caching Proxy | ----------------- / \ / \ ----------------- ----------------- | Upper-Level |-----------| Upper-Level | | Caching Proxy | | Caching Proxy | ----------------- ----------------- / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ / \ ----------------- ----------------- ----------------- | First Level |-----| First Level |-------| First Level | | Caching Proxy | | Caching Proxy | | Caching Proxy | ----------------- ----------------- ----------------- Network Element to Proxy Cache: cooperation and communication between caching proxy and network elements. Examples include routes and switches. Generally used for transparent caching and/or diffused arrays. Temporal Domain Sparse Working Set Cache ----------------- ----------------- ----------------- | Caching Proxy | | Caching Proxy | | Caching Proxy | | Array | | Array | | Array | ----------------- ----------------- ----------------- \ | / \ | / ----------------------------------------- | -------------- | Network | | Element | -------------- | | ------------ Melve, Tomlinson [Page 8] Replication and Caching Taxonomy February 26, 1999 | Client | ------------ Replicated Origin Servers [Ed Note: To be completed] Caching Proxies [Ed Note: To be completed. Explain "normal" proxy setup, with more than one proxy as cluster or mesh. Brief intro to problem.] Caching Proxies with Transparency [Ed note: Currently contains citations from NetApp document, need rewording to avoid specific products and concentrate on generic properties. Explain network elements and NATs and other ways interception may happen. Intro to usage and "normal" setup.] Reference [1,2,3,4] for introduction to caching proxies with transparency. The goal of intercepting web traffic is to provide a transparent web proxy, thus avoiding the hassle of individually configuring each client. Transparency means that the user does not need to be aware of the proxy. The web origin server see connections coming from the proxy, not from the individual end user. Authentication based on client IP address do not work if there is a transparent proxy cache in the way to the web server. A web cache is said to be transparent if clients can access the cache without the need to configure their browsers, using either a proxy auto-configuration URL or a manual proxy setting. Transparent caches appear as a seamless part of the network infrastructure, rather than a set of discrete proxy servers, and function much like a transparent firewall. Many ISPs and carriers desire transparent caches because it lets them retrofit their network with caching without action at the client. However, when deployed transparently, a web cache must be as fail-safe and scalable as the rest of the network. [2] A transparent cache acts much like a gateway or firewall -- it effectively sits between the users and the network. The advantage of transparent caching is that it eliminates the need to configure Melve, Tomlinson [Page 9] Replication and Caching Taxonomy February 26, 1999 browsers to use caching. Another strength (and sometimes a weakness) is that it is impossible to bypass caching. [2] Conceptually, transparency works by modifying the TCP/IP stack of a cache so that it operates in "promiscuous mode" and effectively binds itself to all possible IP addresses. [2] We need to give a far more abstract definition which includes the way that router and switch redirection, and within-router action, operate. Comment on some of the problems: * limited number of ports which can be captured * due to "unexpected" data on other ports (or even on well known ports), as experienced by setting up various services on port 80 * well known problems with use of HTTP for transport [20] Out-of-path Transparent Caching Proxies An Out-of-path Transparent Caching Proxy performs the same proxy and caching functions as a Transparent Caching Proxy and is similarly transparent to the client. However it does not lie on the forwarding path between a client and a server and does not perform web traffic interception. Instead it relies upon a redirecting network element in the path between client and server to intercept and redirect web traffic to it. One advantage of this method of transparent caching is that in the case of cache failure the network element can, providing it monitors the state of the caches, revert to forwarding web traffic direct to the server. It is also possible for the network element to distribute the web traffic load across a group of caches. This method of transparent caching generally requires a protocol to be run between the redirecting network element and the cache or caches. Caching Accelerators [Ed note: to be completed] 4. Client to Replica Communication This section describes the cooperation and communication between clients (both browser/user agents and proxy caches) and replica origin servers. Used to discover optimal replica proximity. URL Redirection [Ed note: to be completed] Melve, Tomlinson [Page 10] Replication and Caching Taxonomy February 26, 1999 DNS Redirection [Ed note: to be completed] 5. Inter-Replica Communication This section describes the cooperation and communication between replica origin servers. Used in replicating data sets between origin servers. Batch Driven Mirror Replication [Ed note: to be completed] Demand Driven Mirror Replication [Ed note: to be completed by Gary Tomlinson] 6. Client to Proxy Configuration This section describes the configuration, cooperation and communication between end user clients (browsers and applications) a proxy. Manual Proxy Configuration Manual Proxy Configuration [Ed note: Does not need to be submitted for Informational RFC, in Ingrid's opinion] Authoritative reference: None. Description: Each user needs to configure its browser by typing in information Security: The potential for doing wrong is high, as each user individually sets preferences Deployment: Widely deployed, used in all current browsers. Most browsers Melve, Tomlinson [Page 11] Replication and Caching Taxonomy February 26, 1999 support other options as well. Submitter: PAC [7] PAC [Ed note: Does it really need to be submitted for Informational RFC?] Authoritative reference: Navigator Proxy Auto-Config File Format. Available from http://home.netscape.com/eng/mozilla/2.0/ relnotes/demo/proxy-live.html Description: A JavaScript page on a web server hands out information on where to find proxies. Clients need to point at the URL of this page. No bootstrap mechanism, manual configuration necessary. Manual configuration is made easier by centralizing the script to one URL. Security: Common policy per organization possible. Does still require manual configuration. PAC is better than "manual proxy configuration" because with PAC administrators can update the proxy configuration without user intervention. Interoperability of PAC files is not as good as wanted, since more popular browsers have slightly different interpretation of the script, and this may lead to undesired effects. Deployment: Implemented in most web clients. Submitter: CARP [9] CARP Cache Array Routing Protocol v1.0 [Ed note: to be completed] Melve, Tomlinson [Page 12] Replication and Caching Taxonomy February 26, 1999 Authoritative reference: Work in Progress: Internet-Draft draft-vinod-carp-v1-03.txt Description: Clients may use CARP directly as a hash function based proxy selection mechanism. They need to be configured with the location of the cluster information. Security: Deployment: Submitter: WPAD [Ed note: to be completed] Authoritative reference: None Description: WPAD uses a collection of pre-existing Internet resource discovery mechanisms to perform web proxy auto-discovery. The only goal of WPAD is to locate the PAC URL. WPAD does not specify which proxies will be used. WPAD gets you to the PAC URL, and the PAC script chooses the proxies for you. The WPAD protocol specifies the following: + how to use each mechanism for the specific purpose of web proxy auto-discovery + the order in which the mechanisms should be performed + the minimal set of mechanisms which must be attempted by a WPAD compliant web client The resource discovery mechanisms utilized by WPAD are as follows: + Dynamic Host Configuration Protocol DHCP + Service Location Protocol SLP + "Well Known Aliases" using DNS A records + DNS SRV records + "service: URLs" in DNS TXT records Melve, Tomlinson [Page 13] Replication and Caching Taxonomy February 26, 1999 Security: Deployment: Submitter: 7. Inter-Cache Communication This section describes the cooperation and communication between caching proxies. ICP [10, 11, 12, 13, 14] ICP Internet Cache Protocol Authoritative reference: RFC 2186 [10] Internet Cache Protocol (ICP), version 2 Description: ICP is used by caches to query other caches about web objects, to see if a web object is present at the other cache. ICP uses UDP. Since UDP is unreliable, an estimate of network congestion and availability may be calculated by ICP loss. This rudimentary loss measurement does, together with round trip times provide a load balancing method for caches. Security: ICP does not convey information about HTTP headers associated with a web object. HTTP headers may include access control and cache directives, Since caches ask for objects, and then download the objects using HTTP, false cache hits may occur (object present in cache, but not accessible for sibling cache is one example). ICP suffer from all the security problems of UDP. Deployment: Widely deployed. Most current cache implementations support ICP in one form or the other. Submitter: Melve, Tomlinson [Page 14] Replication and Caching Taxonomy February 26, 1999 HTCP [15] HTCP, Hyper Text Caching Protocol (HTCP/0.0). [Ed note: to be completed] Authoritative reference: Internet Draft draft-vixie-htcp-proto-03.txt, Work in Progress Description: HTCP is a protocol for discovering HTTP caches and cached data, managing sets of HTTP caches, and monitoring cache activity. HTCP includes HTTP headers, while ICPv2 does not. HTTP headers are vital information for web proxy caches. Security: Deployment: Implemented in caching proxies (two independent implementations) Submitter: CARP [9] CARP [Ed note: to be completed] Authoritative reference: Work in Progress: Internet-Draft draft-vinod-carp-v1-03.txt [Ed note: current draft has expired] Description: CARP is a hashing function for dividing URL-space among a cluster of proxy caches. Included in CARP is the definition of a Proxy Array Membership Table, and ways to download this information. An HTTP client agent (either a proxy server or a client browser) which implements CARP v1.0 can allocate and intelligently route requests for the correct URLs to any member of the Proxy Array. Due to the resulting sorting of requests through these proxies, duplication of cache contents is eliminated and global cache hit rates may be Melve, Tomlinson [Page 15] Replication and Caching Taxonomy February 26, 1999 improved. Security: Deployment: Implemented in caching proxy servers. More than two independent implementations. Submitter: Cache Digest [16] Cache Digest Authoritative reference: No RFC published, no Internet-Draft Cache Digest specification http://squid.nlanr.net/Squid/CacheDigest/ cache-digest-v5.txt Squid Digest FAQ entry http://squid.nlanr.net/Squid/FAQ/FAQ-16.html Description: Cache Digests are a response to the problems of latency and congestion associated with previous inter-cache communications mechanisms such as the Internet Cache Protocol (ICP) [10, 11] and the HyperText Cache Protocol [15]. Unlike most of these protocols, Cache Digests support peering between cache servers without a request-response exchange taking place. Instead, a summary of the contents of the server (the Digest) is fetched by other servers which peer with it. Using Cache Digests it is possible to determine with a relatively high degree of accuracy whether a given URL is cached by a particular server. Cache Digests are both an exchange protocol and a data format [16a,16b]. Security: If the contents of a Digest is sensitive, it should be protected from access by The Wrong People. Any methods which would normally be applied to secure an HTTP connection can be applied to Cache Digests. Melve, Tomlinson [Page 16] Replication and Caching Taxonomy February 26, 1999 A 'Trojan horse' attack is currently possible in a cache mesh: Cache A can build a fake peer Digest for cache B and serve it to B's peers if requested. This way A can direct traffic toward/from B. The impact of this problem is minimized by the 'pull' model of transferring Cache Digests from one server to another. Cache Digests provide knowledge about peer cache content on a URL level. Hence, they do not dictate a particular level of policy management and can be used to implement various policies on any level (user, organization, etc.). Deployment: Cache Digests are supported in Squid; several commercial vendors are looking into Digest support. Cache Meshes: + NLANR Mesh + TF-CACHE mesh (European Academic networks) Submitter: Alex Rousskov, NLANR, rousskov@nlanr.net 8. Network Element Communication This section describes the cooperation and communication between caching proxy and network elements. Examples include routers and switches. Generally used for transparent caching and/or diffused arrays. WCCP [18] WCCP, Web Cache Coordination Protocol V1 Authoritative reference: Internet Draft draft-forster-web-pro-00.txt Work in Progress Description: WCCP V1 runs between a router functioning as a redirecting network element and out-of-path transparent caching proxies. The protocol allows one or more caching proxies to register themselves with a single router to receive redirected web traffic. It also allows one of the proxies, the designated proxy, to dictate to the router how redirected web traffic is distributed across the caching proxies. Melve, Tomlinson [Page 17] Replication and Caching Taxonomy February 26, 1999 Security: WCCP V1 has no security features. Deployment: Network elements: WCCP V1 is deployed on a wide range of Cisco routers. Caching proxies: WCCP V1 is deployed on a number of vendors' caches. Submitter: David Forster, CISCO, dforster@cisco.com SOCKS [Ed note: to be completed] Alteon L4 Switch Protocol [Ed note: to be completed] ArrowPoint L4 Switch Protocol [Ed note: to be completed] Foundry L4 Switch Protocol [Ed note: to be completed] 9. Security Considerations Information on security in each protocol is provided in the description of the protocol, and in the accompanying RFC for each protocol. [Ed note: more information needed] 10. Conclusion [Ed note: to be completed] 11. Acknowledgements [Ed note: No decision made on authors list. Submitters of individual entries are acknowledged in the text. Need to sort out how to give credits where they are due.] Melve, Tomlinson [Page 18] Replication and Caching Taxonomy February 26, 1999 Ian Cooper, MirrorImage ian@mirror-image.com for really helpful comments. David Forster, Cisco, dforster@cisco.com provided info on Out-of-path Transparent Caching Proxies. Alex Rousskov and David Forster for protocol information. 12. References [1] Duane Wessels. Squid FAQ: Transparent Caching/Proxying. National Laboratory for Applied Network Research. Available from: http://squid.nlanr.net/Squid/FAQ/FAQ-17.html [2] Peter Danzig and Karl L. Swartz. Transparent, Scalable, Fail- Safe Web Caching. Network Appliance, Inc. Available from http://www.netapp.com/technology/level3/3033.html [3] Bert Williams. Transparent Web Caching Solutions. Alteon Networks. Available from Transparent Web Caching Solutions [4] Tony Hain. Architectural Implications of NAT. Internet Architecture Board. Internet Draft (Work in Progress). Available from ftp://ftp.nordu.net/internet-drafts/draft-iab-nat-implications-02.txt [5] Ingrid Melve, Lars Slettjord, Ton Verschuren, Henny Bekker, Technical report European Union RE1004-M4.3 "Web caching architecture" [6] Fielding, et al. Hypertext Transfer Protocol -- HTTP/1.1. IETF RFC2068. Available from http://info.internet.isi.edu/in- notes/rfc/files/rfc2068.txt [7] Netscape, Inc. Navigator Proxy Auto-Config File Format. Available from http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy- live.html [8] Paul Gauthier, J. Cohen, Martin Dunsmuir and Charles Perkins. The Web Proxy Auto-Discovery Protocol. Available from http://eggplant.rte.microsoft.com/wpad/ [9] Vinod Valloppillil and Keith W. Ross. Cache Array Routing Protocol. Internet Draft (Work in Progress) Available from ftp://ftp.nordu.net/internet-drafts/draft-vinod-carp-v1-03.txt [10] D. Wessels and K. Claffy. Internet Cache Protocol (ICP), version 2. 'RFC2186. Available from ftp://ftp.nordu.net/rfc/rfc2186.txt Melve, Tomlinson [Page 19] Replication and Caching Taxonomy February 26, 1999 [11] D. Wessels and K. Claffy. Application of Internet Cache Protocol (ICP), version 2, RFC2187. Available from ftp://ftp.nordu.net/rfc/rfc2187.txt [12] Ivan Lovric. Internet Cache Protocol Extension Internet Draft (Work in Progress) Available from ftp://ftp.nordu.net/internet- drafts/draft-lovric-icp-ext-01.txt [13] Duane Wessels. ICP Home Page, National Laboratory for Applied Research. Available from [52]http://ircache.nlanr.net/Cache/ICP/ [14] University of Southern California. Internet Cache Protocol Specification 1.4. Available from http://excalibur.usc.edu/icpdoc/icp.html [15] Paul Vixie and Duane Wessels. Hyper Text Caching Protocol (HTCP/0.0). Internet Draft (Work in Progress) Available from ftp://ftp.nordu.net/internet-drafts/draft-vixie-htcp-proto-03.txt [16] Alex Rouskov and Duane Wessels. Cache Digests. National Laboratory for Applied Network Research. Available from [16a] Cache Digest specification http://squid.nlanr.net/Squid/CacheDigest/cache- digest-v5.txt [16b] Squid Digest FAQ entry http://squid.nlanr.net/Squid/FAQ/FAQ-16.html [17] Berners-Lee, et al. Hypertext Transfer Protocol -- HTTP/1.0 IETF RFC1945 Available from http://info.internet.isi.edu/in- notes/rfc/files/rfc1945.txt [18] Cisco Web Cache Control Protocol (WCCP). Internet Draft (Work Progress) Available from ftp://ftp.nordu.net/internet-drafts/draft- forster-web-pro-00.txt [19] Leech, et al. SOCKS Protocol Version 5, RFC1928 Available from http://info.internet.isi.edu/in-notes/rfc/files/rfc1928.txt [20] Keith Moore, On the use of HTTP as a Substrate for Other Protocols. Internet Draft (Work in Progress) Available from ftp://ftp.nordu.net/internet-drafts/draft-iesg-using-http-00.txt 13. Authors' Addresses Ingrid Melve UNINETT Tempeveien 22, Trondheim, NORWAY Phone: +47 73 55 79 07 Email: Ingrid.Melve@uninett.no Melve, Tomlinson [Page 20] Replication and Caching Taxonomy February 26, 1999 Gary Tomlinson Novell, Inc. 122 East 1700 South Provo, Utah 84606 USA Phone: +1 801 861 7021 Email: garyt@novell.com Appendix Template Protocol information template Authoritative reference: (RFC published, or Internet-Draft) Description: (What does it do. Its benefits, intended purpose, etc) Security: (Security relative the protocol, Policy Management) Deployment: (Deployment scenario(s)) Submitter: (Name, email, institution) Melve, Tomlinson [Page 21]