Network Working Group                                        M. Hamilton
Internet-Draft                                   JANET Web Cache Service
Expires: January 15, 2002                                      I. Cooper
                                                            Equinix Inc.
                                                                   D. Li
                                                     Cisco Systems, Inc.
                                                           July 17, 2001


              Requirements for a Resource Update Protocol
                    draft-ietf-webi-rup-reqs-01.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.

   This Internet-Draft will expire on January 15, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This document seeks to establish the requirements for a Resource
   Update Protocol which may be used in conjunction with World-Wide Web
   intermediary systems such as caching proxies and surrogate servers to
   facilitate cache coherence.  It is envisaged that RUP will include
   invalidation of previously cached objects as a key feature, while
   providing hooks for future extensions to richer functionalities, such
   as directing a surrogate to retrieve content using delta encoding or
   IP multicast.  The main goal is to enable proxy caching and content



Hamilton, et. al.       Expires January 15, 2002                [Page 1]

Internet-Draft              RUP Requirements                   July 2001


   distribution of large amounts of frequently changing web objects,
   where periodically revalidating objects one by one is unacceptable in
   terms of performance and/or cache consistency.

   Please direct your comments to WEBI mailing list
   webi@lists.equinix.com.  To subscribe, email webi-request@equinix.com
   with body (un)subscribe.  The mailing list archive is at
   http://www.wrec.org/webi-archive/.

   Revision Log:

   1.  state that RUP requirements focus on cache invalidation, and not
        on content retrieval or content push.

   2.  state that RUP should strive to provide hooks so that future
        inclusion of richer functionality is possible.

   3.  add to "introduction" more background material and the motivation
        for better web coherence.

   4.  clarify in "introduction" the main goal of RUP.

   5.  clarify in "scoping requirement" the relationship between managed
        and unmanaged delivery entities in RUP.

   6.  add a "terminology" section.

   7.  change "design goals" into "design guidelines", and add
        scalability and minimal functionality requirement.

   8.  classify various functional requirements into five areas.

   9.  describe the requirements for strong and weak coherence model and
        the behavior expected of a cache.

   10.  state that both server and client may initiate message exchange.

   11.  state that the protocol semantics and message formats should be
        self-contained and portable.

   12.  remove "content update" from the use cases.

   13.  rename "content update redirect" into "content location update".

   14.  add "content prefetch hint" to the use cases

   15.  state that "dynamic discovery of RUP sessions" is out of scope
        for the first version of RUP.



Hamilton, et. al.       Expires January 15, 2002                [Page 2]

Internet-Draft              RUP Requirements                   July 2001


   16.  state that resource grouping is decided outside of RUP and not
        negotiable dynamically.  I.e., "targeted invalidation" is out of
        scope for the first version of RUP.

   17.  state the need for a feedback mechanism, as one of the operating
        modes, for sequential consistency and progress monitoring.

   18.  state that RUP must provide the means to describe the
        composition of a resource group, and describe the in-band as
        well as out-of-band modes as requirements.

   19.  state that RUP needs to support both enumeration and summary
        description (e.g., regular expression) of resource groups.

   20.  state the five RUP payloads: cache invalidation, location
        update, prefetch hints, removal and addition to resource groups,
        and adjustments to cache consistency parameters.

   21.  describe the requirements for a cache to provide RUP-controlled
        coherence and the requirements for clean transition between RUP
        controlled coherence and HTTP cache-control.

   22.  describe the requirements on an extension scheme using options
        (hints).  And mandate that "content prefetch hint" and "content
        location update" must be define as options.

   23.  state that the security profile of a RUP session cannot be
        circumvented.  However, alternate sessions may be provided with
        different security profiles.

   24.  switch the sections of the use cases and the functional
        requirements.

   25.  add more references to related work.

   26.  acknowledge people who've given comments on the mailing list or
        at the IETF meetings.

   27.  add pointers to the working group mailing list.












Hamilton, et. al.       Expires January 15, 2002                [Page 3]

Internet-Draft              RUP Requirements                   July 2001


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.  Design Guidelines  . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Scoping Requirement  . . . . . . . . . . . . . . . . . . . . .  9
   5.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  Functional Requirements  . . . . . . . . . . . . . . . . . . . 12
   6.1 Coherence Model  . . . . . . . . . . . . . . . . . . . . . . . 12
   6.2 Naming and Framing . . . . . . . . . . . . . . . . . . . . . . 13
   6.3 Client-Server Interaction  . . . . . . . . . . . . . . . . . . 14
   6.4 Network and Host Environment . . . . . . . . . . . . . . . . . 15
   6.5 Host-to-host Communication . . . . . . . . . . . . . . . . . . 16
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
       References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 21

































Hamilton, et. al.       Expires January 15, 2002                [Page 4]

Internet-Draft              RUP Requirements                   July 2001


1. Introduction

   Cache invalidation and cache coherence protocols enable cooperation
   among content servers and web intermediaries by eliminating the round
   trips in a per-request cache validation model, e.g., using HTTP if-
   modified-since directive.

   One of the main problems addressed here is the fact that the current
   practices proved the existing HTTP cache control mechanisms
   unsatisfactory.  Existing mechanisms are based on the assumption that
   the server knows the document expiration time at the moment when this
   document is delivered.  This assumption in many cases is not correct,
   and we need a new mechanism for server-driven updates.

   A number of cache coherence or cache invalidation protocols have been
   proposed by the research community and the caching and content
   distribution industry.  Approaches vary, with some proponents seeking
   to enhance existing protocols and others developing new protocols
   either specifically for this purpose or which include this
   functionality.  Examples include WCIP [1], PSI [2] and DOCP [3].

   A carefully developed mechanism for the communication of information
   about changes to Internet resources offers the potential for other
   functions above and beyond invalidation of cached objects.  More
   general applications for this mechanism might include automated
   tracking of changes to related groups of resources for real-time
   'mirroring' of collections of resources, and the sharing of
   information about cached objects between intermediaries from
   different vendors.  Resource updates may also be an appropriate way
   of informing systems which generate content dynamically that the
   underlying data which they manipulate (e.g.  to produce HTML pages)
   has changed.  While RUP may facilitate these functions in the future,
   they are currently outside of RUP scope.

   The IETF's Web Intermediaries working group (WEBI) has been chartered
   to develop a Protocol based on requirements to be gathered here.  For
   the reasons described above, we will refer to an abstract Resource
   Update Protocol (RUP, or simply 'the protocol') whose functionality
   will initially be limited to simple invalidation of cached objects,
   as a basis for future extensions to richer functionality.  Note that
   RUP is at least conceptually a new protocol, but may in practice be
   based wholly or partly on existing protocols.

   The main goal of a RUP protocol is to improve cache coherence
   compared to HTTP's client-polling protocol in order to (a) provide
   stronger guarantees at a similar cost or (b) provide similar
   gurantees at a lower cost.  Relevant costs include network load,
   server load, and/or client latency to revalidate cached objects.



Hamilton, et. al.       Expires January 15, 2002                [Page 5]

Internet-Draft              RUP Requirements                   July 2001


   Specific consistency guarantees supported by RUP will be described
   below.

















































Hamilton, et. al.       Expires January 15, 2002                [Page 6]

Internet-Draft              RUP Requirements                   July 2001


2. Terminology

   This document uses terms defined and explained in the WREC Taxonomy
   [4], and the HTTP/1.1 specification [5].  The reader should be
   familiar with both of these documents.

   In this document, the term "surrogate" is shorthand for a demand-
   driven surrogate origin server, unless explicitly stated otherwise.
   Similarly, "origin server" refers to a surrogate's master origin
   server.

   Cache coherence and invalidation is discussed in detail in the
   caching literature, e.g.  see [7] and [8] for background information.

   A RUP server is the entity that knows the state of the content and
   generates resource updates.  A RUP client is the entity that needs to
   know the state of the content and receives resource updates from the
   RUP server.

   An invalidation is a signal from a RUP server to a RUP client to
   indicate that the master copy of a certain resource has changed.  RUP
   must clearly define the actions this signal implies or mandates and
   the semantics the actions accomplish, in relationship to the RUP
   coherence models.  E.g., RUP may specify (among many things) that a
   RUP client must not serve an invalidated cached object without an if-
   modified-since HTTP query.

























Hamilton, et. al.       Expires January 15, 2002                [Page 7]

Internet-Draft              RUP Requirements                   July 2001


3. Design Guidelines

   1.  The protocol must be simple and extensible, and it should be
       possible to systematically extend the protocol to accommodate
       richer functionalities in future iterations of the protocol.

   2.  The protocol should not reinvent the same technologies, but
       leverage existing technologies (e.g.  XML, HTTP, URIs) that have
       proven themselves with wide bases of deployment.

   3.  RUP should allow other protocols of similar nature to interoperate 
       or co-exist with it. The protocol should be easy to integrate into 
       applications such as content management engines and Web 
       server-side software components.

   4.  The protocol must be scalable to tens of thousands of surrogates
       and caching proxies.

   5.  The protocol must define a set of minimal functionality that all
       implementations must support.  If other functions exist, the
       protocol must define a default reaction to those functions.































Hamilton, et. al.       Expires January 15, 2002                [Page 8]

Internet-Draft              RUP Requirements                   July 2001


4. Scoping Requirement

   RUP should work across a wide range of deployment environments and
   should be designed for use by origin servers, its delegates, and Web
   intermediaries, including surrogates, CDNs, and caching proxies
   alike.  User agents (e.g., browsers or crawlers) may in the future
   find RUP or its derivatives suitable for purposes beyond the core
   charter established at the writing of this document.

   RUP is motivated primarily by surrogates and CDNs, because there's
   much more urgent need for RUP among the more tightly coupled and
   managed content delivery systems.  Therefore, if there are conflicts
   in requirements between the managed delivery entities and standalone
   caching proxies, RUP should accommodate those of the managed delivery
   entities but make them optional (e.g., whether to join a RUP session,
   whether to perform prefetch, and whether to accept per-object state).
   A RUP client should not have to support every operation.

   RUP should accommodate performance requirements of all classes of Web
   intermediaries by making support of potentially expensive features
   optional.  RUP may guarantee support to specific features by
   mandating all Web intermediaries to acknowledge support of an
   optional feature at server request.




























Hamilton, et. al.       Expires January 15, 2002                [Page 9]

Internet-Draft              RUP Requirements                   July 2001


5. Use Cases

   Please note that the protocol level details discussed here are only
   hypothetical at this stage, but necessary to support the examples.

   1.  Server-driven invalidation: in this scenario the RUP server would
       send object or resource group invalidations to the RUP clients,
       sending invalidation signals according to its own scheduling
       configuration.  The connection between client and server could be
       established by either party, and could be persistent - so as to
       facilitate monitoring of the update guarantee, e.g., through
       heartbeat packets or positive acknowledgements.

   2.  Client-driven validation: in this scenario the RUP client would
       take the lead, querying the RUP server for the freshness status
       of an object or group of objects (e.g., denoted by a URI).  The
       RUP server would reply with the latest changes since the last
       time the client asked - based on information such as Etag,
       timestamp, and/or version number.  Whether and when the client
       asks the server is determined by the consistency guarantee the
       client is committed to provide, and should follow the semantic
       rules defined by the RUP protocol.

   3.  Content location update: in this scenario the RUP server is able
       to designate a new location as the source for a cached object.
       It could do that even if the object is fresh.  The RUP server
       would use the location update to notify RUP clients that an
       object is to be fetched, e.g., from a regular web server, the
       parent caching proxy, a CDN peer, or a multicast object
       distribution channel.  RUP may make this an optional use so that
       a standalone caching proxy may ignore the alternate location.

   4.  Content prefetch hint: in this scenario the RUP server may tag
       resources or resource groups as suitable for prefetch, and RUP
       clients may prefetch the content and pin it in their cache.  Such
       use is expected to be common in surrogate, CDN, and CDN peering
       deployment scenarios, to provide updates for prepositioned
       content besides on-demand content.  RUP may make this an optional
       use.

   A use case that is out of scope for the first RUP standard is
   "content updates".  In this scenario, the RUP server would, instead
   of sending a cache invalidation and/or location update signal to the
   client, send the RUP client with either the full content of a
   modified object or a delta update showing changes against the
   previous revision.  The reason for not supporting it right now is two
   fold.




Hamilton, et. al.       Expires January 15, 2002               [Page 10]

Internet-Draft              RUP Requirements                   July 2001


   First, relative to cache invalidation, there's much less
   understanding of the kinds of content updates RUP may need.  In
   particular, mixing signaling with data leads to problems including
   scaling, object consistency and security issues that are not well
   understood.  Second, there are existing mechanisms addressing content
   retrieval, e.g., HTTP [5] and Delta Encoding [6], which also
   demonstrate the high complexity of such a functionality.  RUP,
   however, will provide hooks for "content updates", i.e., through
   "content location update" (see use case 3).  This allows RUP to
   leverage, instead of reinventing, existing mechanisms.  RUP will not
   preclude future protocols that build on RUP to integrate more
   advanced content update functionality in the future.

   In short, RUP will not be used to update content or HTTP meta
   information of cached entities.  As use case 3 illustrates, such
   updates can be implemented as a sequence of invalidate-and-fetch
   operations.

   Another use case that is out of scope for RUP is the dynamic
   discovery of RUP services.  For example, the URI of a particular RUP
   resource group could be manually configured, sent as header
   information in the HTTP responses from the origin server, or
   distributed via a separate out-of-bound mechanism.




























Hamilton, et. al.       Expires January 15, 2002               [Page 11]

Internet-Draft              RUP Requirements                   July 2001


6. Functional Requirements

6.1 Coherence Model

   1.  The protocol should make strong consistency possible, e.g., by
       returning positive acknowledgement upon receiving an invalidation
       message to signal the completion of cache invalidation or even
       content retrieval.  If relay points are used, the relay node must
       preserve the semantics of positive acknowledgement, e.g., by
       waiting for every child client's acknowledgement before sending
       its acknowledgement upstream.  The protocol shall allow a server
       to specify that an invalidation message be acknowledged or that
       an invalidation message not be acknowledged.  Explicit
       acknowledgement may, for example, support strong consistency or
       support fail-over at CDN content routers.  Conversely, running in
       no-acknowledgements mode may improve scalability.

   2.  The protocol should also make loose consistency available, for
       applications that do not require tight coupling, e.g.,
       traditional batch mode mirroring applications.  In particular,
       the system should provide delta consistency guarantees in which a
       server may specify a maximum staleness "delta" in seconds.  If an
       object that a client is caching is updated, within delta seconds,
       the client will either (a) be notified of the update or (b)
       detect that its cache is no longer synchronized with the server.
       Note that this allows a client to enforce a worst-case staleness
       guarantee of delta seconds.

   3.  While participating in a RUP session, a cache should never return
       potentially stale RUP-controlled data without a warning that the
       data are potentially stale, e.g., via HTTP Warning: 110/111.

   4.  If a cache wants to transition a resource from RUP-controlled
       coherence to HTTP cache-control based coherence, it must first
       consider the resource stale and revalidated via HTTP (e.g., if-
       modified-since).  Similarly, to transition a resource from HTTP
       cache-control to RUP-controlled coherence, it must first consider
       the resource stale and revalidate via RUP.

   5.  It is essential that the protocol support "express
       resynchronization".  I.e., if a client becomes de-synchronized
       from a server, the client should be able to reconnect
       (resynchronize) quickly.  There are a number of ways to support
       this, e.g., batch revalidation based on version numbers,
       incremental background revalidation, incremental foreground
       revalidation, delayed invalidation, log playback, etc.  It's up
       to the RUP protocol design to decide on the specific mechanisms
       for revision control and express resynchronization of resources.



Hamilton, et. al.       Expires January 15, 2002               [Page 12]

Internet-Draft              RUP Requirements                   July 2001


   6.  Resource update guarantees must propagate correctly through the
       scaling mechanisms even if multiple levels of intermediary are
       used.


6.2 Naming and Framing

   1.  The protocol must enable the communication regarding an arbitrary
       group of resources.  The protocol must be able to invalidate
       multiple resources with one message.  A resource group can have
       multiple resources in it, denoted by a list of URIs (or regular
       expression URLs), i.e., the traditional "object URIs".  RUP
       server must be able to add or remove resources from a resource
       group.

   2.  A resource group itself can be denoted as a URI, too, e.g.,
       "wcip://server.com/channel7", as "resource group URI".  It
       denotes not only a group of objects for update purposes, but also
       the method to access the updates.  This resource group URI can
       then be widely shared by a content provider with its surrogates.

   3.  RUP must provide the means to describe the composition of a
       resource group.  The assignment of an object to a resource group
       may either be made out of band (outside of RUP information
       exchange procedure), e.g., in the object's HTTP header.  Or, the
       assignment can be in band, with a resource group definition
       message in RUP.  RUP may specify both the "in-band" and "out-of-
       band" protocols.  E.g., the HTTP header based approach
       specification is simple and makes it efficient to determine to
       which group an object belongs, while in-band specification should
       be supported so that RUP is self-contained.  In particular, CDN
       operators would prefer not having to change the origin web server
       before anything can be put into a resource group, but rather
       self-describe the composition within the group.

   4.  RUP must support both summary description of a resource group,
       e.g., using regular expression or prefix matching, and
       enumeration of a resource group.  Each deployment may choose what
       method(s) to use.

   5.  The grouping of resources is done outside of RUP, e.g., by the
       content provider, CDN operator, or traffic analysis tools.  RUP
       is not requires to provide dynamic negotiation, between the RUP
       server and client, over the composition of a resource group.  In
       other words, "targeted invalidation", in which a server only
       sends an invalidation about object X to clients that have
       registered callbacks on object X, is out of scope for the initial
       version of RUP.  This is out of complexity and scalability



Hamilton, et. al.       Expires January 15, 2002               [Page 13]

Internet-Draft              RUP Requirements                   July 2001


       concerns about servers (and clients) having to negotiate and
       maintain individual views of resource groups for all the clients
       (and servers) they speak to.  It's anticipated that predefined
       resource groups will fit well with the majority of the RUP
       deployment cases (surrogates, mirror sites, and CDNs).

   6.  The protocol must define an extensible format for RUP messages
       which is capable of carrying a variety of payloads.  Possible
       payloads include (1) cache invalidation, (2) content location
       update, (3) content prefetch hints, (4) removal and addition of
       resources to a resource group, (5) adjustments to cache
       consistency parameters, etc.  While the above payloads may share
       the same RUP mechanism, it's not a requirement for the initial
       protocol to address all of them simultaneously.

   7.  As an extension mechanism, a RUP message may carry a set of
       options for a group of resource.  The group may contain zero, one
       or more objects.  The set of options may be empty.  RUP must
       specify a generic option format and define the content prefetch
       hint and content location update as options.  No option is
       mandatory.  A RUP client can ignore any options it doesn't
       recognize or doesn't want to support.  If positive
       acknowledgement is requested, the acknowledgement must indicate
       the options it has carried out.


6.3 Client-Server Interaction

   1.  The protocol must define "client" and "server" roles.  It should
       be possible for either the server or the client to initiate
       information exchange.

   2.  We anticipate that the primary RUP clients and servers will be
       Web intermediaries and origin servers, although the protocol
       should not be so designed as to preclude use by other entities.
       For example, the origin server or servers may delegate the role
       of RUP server to a CDN which operates dedicated content signaling
       channels and servers.

   3.  The protocol should be designed to scale to systems where there
       are a large number (more than 10,000) surrogates of a given
       origin server.  This may require multiple levels of intermediary
       relay points and/or IP multicast.

   4.  The protocol should be capable of operating efficiently on a wide
       variety of underlying media, high latency satellite links in
       particular will need to be considered.  E.g., caching vendors
       have TCP optimizations that an administrator can turn on if the



Hamilton, et. al.       Expires January 15, 2002               [Page 14]

Internet-Draft              RUP Requirements                   July 2001


       link is satellite.  A reliable multicast protocol would use more
       FEC If the link is asymmetric.  The analogy in RUP is that RUP
       should be able to turn off any client->server messages (such as
       ACKs and client-driven updates) if the link is satellite or if
       the transport is IP multicast.

   5.  To support sequential consistency and monitoring of the RUP
       clients, it must be possible to determine whether resource update
       messages have been missed, e.g.  due to a client or server being
       down or unreachable.  There must be a feedback mechanism which
       enables the RUP server to determine the extent to which resource
       updates have propagated to surrogates and carried out.  E.g., if
       the feedback from a surrogate never comes back or comes back as
       failed, the RUP server may either delay publishing the content,
       syslog the failure, disable the surrogate that sent the failure
       code, or stop content routing to that CDN peer, etc.  Specific
       deployments must be able to choose whether or not to operate with
       feedbacks.

   6.  It should be possible to reach a consistent state on all
       surrogates of a given origin server and collection of resources.
       I.e., RUP must guarantee that either a RUP client sees an update
       as intended or be able to detect that it might have missed an
       update.


6.4 Network and Host Environment

   1.  The protocol should be useable both in a surrogate/origin server
       relationship and a traditional caching proxy/origin server
       relationship.  The protocol should also be general enough to be
       useable in content delivery network (CDN) environments to allow
       freshness control of CDN delivery nodes.

   2.  It must be possible for the protocol to be used in an environment
       where some or all communications are mediated through a firewall
       and/or Network Address Translation (NAT) device.  The protocol
       design must identify issues involved in firewall/NAT traversal
       and provide ways by which these may be avoided or circumvented.
       These may not be explicitly security related concerns, e.g.
       working around any problems caused by use of Network Address
       Translation.

   3.  It must be possible for the protocol information to be relayed
       (single source, single destination) and/or be broadcasted (single
       source, multiple destinations) by RUP proxies.  It must be
       possible for the protocol information to be cached (e.g., for
       broadcasting purposes) by RUP proxies.  RUP must guarantee that



Hamilton, et. al.       Expires January 15, 2002               [Page 15]

Internet-Draft              RUP Requirements                   July 2001


       the invalidation effect of a relayed messages on a compliant
       destination is the same as if the message reached the destination
       directly from the source.


6.5 Host-to-host Communication

   1.  The protocol should layer cleanly and independently on top of the
       underlying communication layers, e.g., TCP, HTTP, BEEP, or SOAP.
       The protocol semantics and message formats should be self-
       contained in that they stay the same regardless of the underlying
       transport, and thus portable to different transports.

   2.  The protocol must allow the information transferred between the
       RUP server and client to be authenticated and if necessary
       encrypted.  In particular, RUP should be layered on top of the
       TLS and SASL mechanisms, so as to accommodate security needs in
       various current and future deployment scenarios, without having
       to enumerate them in the RUP specification itself.  If either the
       RUP server or client is not willing or capable of the security
       profile of a particular RUP session, the session must not be
       initiated.  Instead, an alternate session (and its security
       profile) may be provided for them, e.g., via alternate
       configuration or out-of-band discovery mechanism.

   3.  A mechanism providing for discovery of RUP sessions is not
       required to be specified within RUP.  This should not preclude or
       be a pre-requisite for development of the protocol per se.  RUP
       service could be manually configured, sent as header information
       in the HTTP responses from the origin server, or distributed via
       a separate out-of-bound mechanism.




















Hamilton, et. al.       Expires January 15, 2002               [Page 16]

Internet-Draft              RUP Requirements                   July 2001


7. Security Considerations

   Intermediaries open up a large number of new security problems which
   do not exist in the classical end-to-end model of the Internet, by
   introducing a 'Man In The Middle' by design.

   As such, it is essential that this protocol level work on
   intermediaries takes care to devise means by which the integrity of
   the resources being updated can be preserved - or at least tested.

   The major risks associated with the protocol should be quantified and
   specifically addressed by the protocol design.







































Hamilton, et. al.       Expires January 15, 2002               [Page 17]

Internet-Draft              RUP Requirements                   July 2001


8. Acknowledgements

   Thanks to Mark Nottingham, Oskar Batuner, Mark Day, Phil Rzewski,
   Fred Douglis, Lisa Dusseault, Ted Hardie, Joe Touch, Brad Cain,
   Hilarie Orman, Lisa Amini, Joseph Hui, Alex Rousskov, Mike Dahlin,
   Stephane Perret, Darren New, Christian Maciocco, Michael Condry, Renu
   Tewari, Tao Wu, and the rest of the WEBI mailing list for their
   contributions.

   The JANET Web Cache Service is funded by the Joint Information
   Systems Committee of the UK Higher and Further Education Funding
   Councils (JISC).







































Hamilton, et. al.       Expires January 15, 2002               [Page 18]

Internet-Draft              RUP Requirements                   July 2001


References

   [1]   Li, D., Cao, P. and M. Dahlin, "WCIP: Web Cache Invalidation
         Protocol", draft-danli-wrec-wcip-00.txt (work in progress),
         November 2000.

   [2]   Krishnamurthy, B. and C. Wills, "Piggyback server invalidation
         for proxy cache coherency", In Computer Networks and ISDN
         Systems, Volume 30 1998.

   [3]   Dilley, J., Arlitt, M., Perret, S. and T. Jin, "The Distributed
         Object Consistency Protocol", Technical Report HPL-1999-109,
         September 1999.

   [4]   Cooper, I., Melve, I. and G. Tomlinson, "Replication and
         Caching Taxonomy", RFC 3040, January 2001.

   [5]   Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
         Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
         HTTP/1.1", RFC 2616, June 1999.

   [6]   Mogul, J., Krishnamurthy, B., Douglis, F., Feldmann, A.,
         Goland, Y., van Hoff, A. and D. Hellerstein, "Delta encoding in
         HTTP", draft-mogul-http-delta-08.txt (work in progress), March
         2001.

   [7]   Belloum, A. and L. Hertzberger, "Maintaining Web cache
         coherency", In Information Research, Volume 6 No. 1, October
         2000.

   [8]   Gwertzman, J. and M. Seltzer, "World-Wide Web Cache
         Consistency", In Proceedings 1996 USENIX Technical Conference,
         January 1996.

   [9]   Liu, C. and P. Cao, "Maintaining Strong Cache Consistency in
         the World-Wide Web", In Proceedings ICDCS97, May 1997.

   [10]  Yin, J., Alvisi, L., Dahlin, M. and C. Lin, "Using Leases to
         Support Server-Driven Consistency in Large-Scale Systems", In
         Proceedings ICDCS98, May 1998.

   [11]  Duuvvuri, V., Shenoy, P. and R. Tewari, "Adaptive Leases: A
         Strong Cache Consistency Mechanism for the World Wide Web", In
         Proceedings INFOCOM,   1999.

   [12]  Li, D. and D. Cheriton, "Scalable Web Caching of Frequently
         Updated Objects using Reliable Multicast", In Proceedings
         USITS, October 1999.



Hamilton, et. al.       Expires January 15, 2002               [Page 19]

Internet-Draft              RUP Requirements                   July 2001


   [13]  Yin, J., Alvisi, L., Dahlin, M. and C. Lin, "Hierarchical Cache
         Consistency in a WAN", In Proceedings USITS, October 1999.

   [14]  Yu, H., Breslau, L. and S. Shenker, "A Scalable Web Cache
         Consistency Architecture", In Proceedings SIGCOMM, 1999.

   [15]  Yin, J., Alvisi, L., Dahlin, M. and A. Iyengar, "Engineering
         server-driven consistency for large scale dynamic web
         services", In Proceedings WWW10, 2001.


Authors' Addresses

   Martin Hamilton
   JANET Web Cache Service
   Computing Services
   Loughborough University
   Loughborough, Leics  LE11 3TU
   UK

   Phone: +44 1509 263171
   EMail: martin@wwwcache.ja.net


   Ian Cooper
   Equinix Inc.
   2450 Bayshore Parkway
   Mountain View, CA  94043
   USA

   Phone: +1 650 316-6065
   EMail: icooper@equinix.com


   Dan Li
   Cisco Systems, Inc.
   170 W. Tasman Dr.
   San Jose, CA  94043
   USA

   Phone: +1 650 823 2362
   EMail: lidan@cisco.com









Hamilton, et. al.       Expires January 15, 2002               [Page 20]

Internet-Draft              RUP Requirements                   July 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Hamilton, et. al.       Expires January 15, 2002               [Page 21]