Network Working Group                                          I. Cooper
Internet-Draft                                                    Editor
Expires: August 29, 2002                                           D. Li
                                                     Cisco Systems, Inc.
                                                               M. Dahlin
                                                     University of Texas
                                                             M. Hamilton
                                                 JANET Web Cache Service
                                                       February 28, 2002


       Requirements and Guidelines for A Resource Update Protocol
                      draft-ietf-webi-rup-reqs-03

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 August 29, 2002.

Copyright Notice

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

Abstract

   This document provides guidelines for the development of a Web
   Resource Update Protocol to facilitate cache coherence in Web
   intermediary systems such as caching proxies and surrogates.  Such a
   protocol is useful to maintain consistency in an environment where
   periodic revalidation is unacceptable in terms of performance and/or
   cache consistency.  This memo suggests invalidation methods as the



Cooper, et al.           Expires August 29, 2002                [Page 1]


Internet-Draft              RUP Requirements               February 2002


   only required functionality of a candidate protocol, but outlines
   other functionality that should be supported (possibly at a later
   date).

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.1   Definitions  . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.    Design Guidelines  . . . . . . . . . . . . . . . . . . . . .  4
   4.    Scoping  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.    Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.1   Intra-CDN  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.2   Inter-CDN  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.3   Content provider to CDN  . . . . . . . . . . . . . . . . . .  6
   5.4   Content provider to arbitrary Web intermediary . . . . . . .  6
   6.    Operations . . . . . . . . . . . . . . . . . . . . . . . . .  7
   6.1   RUP SERVER-driven invalidation . . . . . . . . . . . . . . .  7
   6.2   RUP CLIENT-driven invalidation . . . . . . . . . . . . . . .  7
   6.3   Content location update  . . . . . . . . . . . . . . . . . .  8
   6.4   Content prefetch hint  . . . . . . . . . . . . . . . . . . .  8
   6.5   Content updates  . . . . . . . . . . . . . . . . . . . . . .  8
   6.6   Metadata updates . . . . . . . . . . . . . . . . . . . . . .  9
   7.    Functional Requirements  . . . . . . . . . . . . . . . . . .  9
   7.1   Coherence Model  . . . . . . . . . . . . . . . . . . . . . .  9
   7.1.1 Confirmation of actions  . . . . . . . . . . . . . . . . . .  9
   7.1.2 Loose consistency  . . . . . . . . . . . . . . . . . . . . .  9
   7.1.3 HTTP Warnings  . . . . . . . . . . . . . . . . . . . . . . .  9
   7.1.4 Transitioning into/out of RUP control  . . . . . . . . . . . 10
   7.2   Resource Grouping  . . . . . . . . . . . . . . . . . . . . . 10
   7.2.1 Resource group identification  . . . . . . . . . . . . . . . 10
   7.3   Relays . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   7.4   Extensibility  . . . . . . . . . . . . . . . . . . . . . . . 11
   7.5   Other issues . . . . . . . . . . . . . . . . . . . . . . . . 11
   8.    Security Considerations  . . . . . . . . . . . . . . . . . . 11
   9.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
         References . . . . . . . . . . . . . . . . . . . . . . . . . 12
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
   A.    Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 15
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 22











Cooper, et al.           Expires August 29, 2002                [Page 2]


Internet-Draft              RUP Requirements               February 2002


1. Introduction

   This memo outlines guidelines for the speficification of a resource
   update protocol for the Web to enable cooperating content servers and
   web intermediaries (caching proxies and surrogates, for example) to
   offer a higher degree of cache coherence than is typically possible
   using per-request validation based on HTTP [6] conditional request
   directives (e.g.  If-Modified-Since).

   While HTTP cache control mechanisms provide a means for individual
   entities to be flagged with their own cacheability information, this
   is not always sufficient for content publishers requirements.
   Setting a long expiration time results in potentially correct but
   "old" material being served; setting a short expiration time results
   in newer content but requires more revalidation requests.  Empirical
   evidence suggests the need for a dynamic content-server driven update
   mechanism.

   Cache coherence and invalidation is discussed in detail in the
   caching literature, e.g.  see [8] and [9] for background information.
   At the time of writing several examples of cache conherence/
   invalidation protocols are known to the editors: WCIP [1], PSI [2]
   and DOCP [3].

   [Ed Note: Should we give examples as above if we can't provide an
   exhaustive list?]

   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.  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.  Such uses are
   currently outside the scope of consideration in this requirements
   document.

   The goal of this document is to provide guidelines for developers of
   a Resource Update Protocol (RUP), the purpose of which is to improve
   cache coherence over HTTP's conditional request polling technique.
   Base level requirements for candidate protocols are given; it is
   expected that protocols will initially provide support for only
   invalidation but that they will be suitably designed to provide
   richer functionality in the future.

2. Terminology

   This document uses terms defined in the Internet Web Replication
   Taxonomy [5], and the HTTP/1.1 specification [6].  The reader is



Cooper, et al.           Expires August 29, 2002                [Page 3]


Internet-Draft              RUP Requirements               February 2002


   expected to be familiar with these documents.  The term SURROGATE is
   used to refer to a demand driven surrogate origin web server unless
   explicitly stated otherwise.  ORIGIN SERVER refers to the master
   origin server.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [4].

2.1 Definitions

   RUP SERVER
      The entity that knows the state of a content provider's resources
      and generates resource updates.  Notionally co-located with the
      origin server.

   RUP CLIENT
      The entity that needs to know the state of resources and receives
      updates from the RUP SERVER.  Notionally co-located with a
      SURROGATE.

   INVALIDATION
      The signal from a RUP SERVER to a RUP CLIENT to indicate that the
      master copy of an entity has changed.

   CONSISTENCY GUARANTEE
      To be defined...

      [Ed note: Term used later in the text but not defined]

   RESOURCE GROUP
      To be defined...

      [Ed note: Term used later in the text but not defined]


3. Design Guidelines

   [Ed note: These are Ian's interpretations of the design guidelines in
   the -01 version and as such are up for discussion.]

   Protocol designers are expected to use their best judgement in their
   design and implementations, however, the following list provides
   high-level guidance:

   1.  Extensibility: the protocol SHOULD be extensible to enable richer
       functionalities to be provided in subsequent versions.




Cooper, et al.           Expires August 29, 2002                [Page 4]


Internet-Draft              RUP Requirements               February 2002


   2.  The protocol SHOULD leverage existing technologies where possible
       (e.g.  XML, HTTP, URIs).

   3.  Interoperability: it is anticipated that multiple protocols will
       exist in this area; protocols SHOULD interoperate or co-exist
       with each other.

   4.  Scaling: INVALIDATIONS are expected to be sent to tens of
       thousands of SURROGATES.  Protocols SHOULD provide reasonable
       features to enable scaling to such numbers, e.g.  by the use of
       relays or multicasting.

   5.  Compliance: protocols MUST define levels of compliance and
       document any side effects that might arise should lesser levels
       of compliance be used.

   6.  Expense: protocols SHOULD make expensive operations OPTIONAL.


4. Scoping

   It is anticipated that RUP will be deployed in origin servers (and
   their delegates) and Web intermediaries, including surrogates and
   caching proxies.  Other deployments are possible (e.g.  within search
   engine crawlers), though some carry scaling and denial of service
   implications if implemented in HTTP user agents (see [6]).  Specific
   warnings relating to implementations in user agents MUST be included
   in RUP protocol candidate specifications; this is most likely text to
   be included in the "Security Considerations" section of those
   documents.  Also see Security Considerations (Section Section 8).

   If conflicts arise between the needs of SURROGATEs and caching
   proxies, the needs of the SURROGATEs SHOULD take precendence.
   However, designers SHOULD make those parts of the protocol OPTIONAL.

5. Use Cases

   The following use cases provide examples of how RUP protocols are
   likely to be deployed.  While it is noted that these scenarios are
   only slightly different in places it is felt beneficial to identify
   them for the benefit of potential protocol developers.

   Particular attention is brought to the fact that RUP may be used to
   to interface between systems running alternative protocols beyond the
   boundaries defined here.  For example, individual content delivery
   networks (CDNs) may choose to operate proprietary protocols
   internally while speaking a RUP protocol externally.




Cooper, et al.           Expires August 29, 2002                [Page 5]


Internet-Draft              RUP Requirements               February 2002


5.1 Intra-CDN

   A Content Distribution/Delivery Network (CDN) may choose to use RUP
   to pass INVALIDATIONS within its own delivery network, e.g.  from a
   control node to intermediaries under its control.

   CDNs must typically have control protocols to ensure they serve the
   correct content as requested by their customers (the content
   providers).  Such protocols are currently proprietary in nature.
   Standardization within IETF will enable CDN operators to share their
   knowledge of their needs in a beneficial way, and will also gain from
   input from a wider technical community.

5.2 Inter-CDN

   Content Networks may internetwork, sharing the responsibility of
   serving content requests to end users (see [18][19]).  As such,
   INVALIDATIONS will also have to be shared among the cooperating
   networks.

   As an open standard, RUP would enable multiple Content Networks to
   share INVALIDATIONS, while allowing each Network to operate an
   invalidation protocol of its own choosing internally.

5.3 Content provider to CDN

   When using the services of a CDN, a content provider must use
   protocols or tools provided by that CDN in order to pass invalidation
   or update messages in order for the CDN to propagate that information
   to its own surrogates.

   A standardize protocol interface between content provider and CDN
   would ensure that content providers are not "locked" into the use of
   a single CDN through use of propriety protocols and the pain of
   migration.  Further, content management system developers would
   benefit by being able to publish into a variety of CDNs, not just
   those from which they license the interface technology.

5.4 Content provider to arbitrary Web intermediary

   Caching proxies provide "best effort" content delivery capabilities
   on behalf of the network operators running them (e.g.  they are not
   under direct or indirect control of the content provider, unlike
   SURROGATEs).  In an effort to ensure that end users see the content
   they wish, at all times, content providers will frequently make
   material appear uncacheable.

   Providing a protocol that enables content providers a tighter binding



Cooper, et al.           Expires August 29, 2002                [Page 6]


Internet-Draft              RUP Requirements               February 2002


   between their publication systems and caching proxies would enable
   those caching proxies to operate as SURROGATEs for that content.
   Such content could be treated as cacheable irrespective of
   indications within HTTP headers and would therefore offload the
   requests from the origin server.  In the absense of the control
   protocol, other caching proxies would treat the content as
   uncacheable as before.

   This use case is similar to Section 5.3 above.

6. Operations

   The following sections outline the various operations that make up a
   Resource Update Protocol.

   The RUP protocol SHOULD transfer multiple INVALIDATIONS in one
   request/response transaction when possible.

6.1 RUP SERVER-driven invalidation

   A RUP SERVER sends entity or resource group INVALIDATIONS to RUP
   CLIENTS.

   The RUP SERVER (and its administrator) controls the activity
   according to the RUP SERVER's load, scheduling, and configured
   preference.  The connection between RUP CLIENT and RUP SERVER MAY be
   established by either party; connections SHOULD be persistent.  It
   SHOULD be possible to monitor the update guarantee.

   RUP SERVER-driven invalidations MUST be supported by candidate
   protocols.

6.2 RUP CLIENT-driven invalidation

   A RUP CLIENT queries (polls) the RUP SERVER for freshness status of
   an entity or group of objects referenced by URI.

   The RUP CLIENT controls RUP activity accorting to its own load,
   failure recover needs, and configured preferences; connections are
   established by the RUP CLIENT and SHOULD be persistent.  The RUP
   SERVER responds to requests by indicating which entities or resource
   groups have been updated and must be invalidated.

   RUP CLIENT-driven invalidations MUST be supported by candidate
   protocols.






Cooper, et al.           Expires August 29, 2002                [Page 7]


Internet-Draft              RUP Requirements               February 2002


6.3 Content location update

   A RUP SERVER designates a new location as the source for an entity.
   Location may be, for example, from a new URI, parent caching proxy,
   CDN peer, multicast object distribution channel.

   By updating the location from which a given entity may be retrieved
   temporarily the RUP SERVER is able to indicate a deligate of the
   origin server that is better suited to respond to future queries.
   The need for Content Location Update was identified in section A.1.1
   of Known HTTP/Caching Problems [20].

   [Ed note: Should we draw an analogy with HTTP 30x responses?]

   Support of content location update is OPTIONAL.

6.4 Content prefetch hint

   A RUP SERVER identifies entities or RESOURCE GROUPS that are suitable
   for prefetching (pre-positioning).  RUP CLIENTS MAY prefetch the
   content and pin it in their corresponding caches.

   Prefetch hints enable content to be pre-positioned without the
   complexities involved in "push" operations (also see Section Section
   6.5).

   Support of content prefetch hint is OPTIONAL.

6.5 Content updates

   A RUP SERVER sends either the full content of entities (overwrite) or
   delta updates to RUP CLIENTS in order to update or push content into
   the corresponding content caches.

   At the time of writing there is insufficient understanding of the
   kinds of content updates that might need to be supported.  In
   particular, those working in this area are aware that mixing
   signalling with data leads to problems of scaling, entity
   consistency, and security issues, among others.  Existing mechanisms
   addressing content retrieval, e.g.  HTTP and Delta Encoding [7]
   demonstrate the high complexity of such functionality.

   Content prefetch hints (see Section Section 6.4) enable participating
   RUP CLIENTS to invalidate and fetch content with somewhat similar
   results to content updates.

   Content updates SHOULD NOT be supported.




Cooper, et al.           Expires August 29, 2002                [Page 8]


Internet-Draft              RUP Requirements               February 2002


6.6 Metadata updates

   [Ed note: place holder; we lost a comment about RUP not being used to
   "update content or HTTP meta information of cached entities."  This
   is still up for discussion, so this section is just to make sure it
   doesn't get lost.]

7. Functional Requirements

7.1 Coherence Model

7.1.1 Confirmation of actions

   A RUP SERVER MUST be able to specify whether actions it requests of a
   RUP CLIENT are acknowledged or not.  In a unicast environment a RUP
   SERVER SHOULD request acknowledgements.

   Acknowledgements from RUP CLIENTS SHOULD be sent as a result of
   carrying out an INVALIDATION.

   Where relays are used in a single control domain the relay MUST
   preserve the semantics of acknowledgement.  E.g.  a relay MUST wait
   for every child's acknowledgement before acknowledging to the RUP
   SERVER.  Semantics MUST be preserved irrespective of the number of
   levels of relays.

7.1.2 Loose consistency

   [Ed note: should this section be here?]

   To support applications that do not require tight coupling (e.g.
   batch mirroring), RUP SHOULD make loose consistency available.  In
   particular RUP SHOULD provide delta consistency guarantees such that
   a RUP SERVER MAY specify a maximum acceptable staleness, defined in
   seconds.

   If a cached entity is updated then within the period covered by the
   delta consistency guarantee the RUP CLIENT will either (a) be
   notified of the update, or (b) detect that its cache is no longer
   synchronized with the server.  [Ed note: what does that latter part
   actually mean?]

7.1.3 HTTP Warnings

   A cache MUST NOT return RUP-controlled entities that would be stale
   in HTTP without attaching an appropriate HTTP/1.1 Warning [6].

   [Ed note: Some description of the warning code chosen, especially if



Cooper, et al.           Expires August 29, 2002                [Page 9]


Internet-Draft              RUP Requirements               February 2002


   an existing code is used in this context]

7.1.4 Transitioning into/out of RUP control

   To transition from HTTP cache control to RUP controlled coherence a
   RUP CLIENT MUST first consider the resource stale and revalidate via
   RUP.  Protocol designers should carefully consider cases where a RUP
   CLIENT has become unsynchronized.

   To transition from RUP controlled coherence to HTTP cache control a
   RUP CLIENT MUST first consider the resource stale and revalidate via
   HTTP.

7.2 Resource Grouping

   It is common for multiple resources that are related to be updated or
   removed at the same time.  By grouping such resources into RESOUCE
   GROUPS (by examining content management systems or server logs, for
   example) that are addressed in their own right it is possible to
   invalidate many resourced with a single INVALIDATION.

   RUP protocols MUST provide a mechanism to enable RUP CLIENTs to
   update multiple entities as a result of receiving an INVALIDATION for
   a RESOURCE GROUP.

   RUP SERVERs SHOULD send INVALIDATIONS for only those RESOURCE GROUPs
   to which a given RUP CLIENT has subscribed.

   [Ed note: The above requirement serious limits the way in which a RUP
   SERVER operator may aid a RUP CLIENT, and the SHOULD clause seems
   inappropriate; a MAY clause seems meaningless.  Is it even worth
   mentioning?]

7.2.1 Resource group identification

   RESOURCE GROUPs are identified to the RUP CLIENT in one of two ways:

   Out-of-band: individual entities within the group contain a URI
      reference of the group within an HTTP header (to be defined by the
      RUP protocol).

   In-band: group identification and contents are transmitted from RUP
      SERVER to RUP CLIENT within the RUP protocol itself.

   Since there is no assumption of a 1:1 relationship between RUP SERVER
   and origin server, RESOURCE GROUPs may identify entites on separate
   origin servers (see Security Considerations).  Identification of a
   RESOURCE GROUP MUST indicate the method used to establish a



Cooper, et al.           Expires August 29, 2002               [Page 10]


Internet-Draft              RUP Requirements               February 2002


   connection between RUP SERVER and RUP CLIENT (e.g.  protocol://
   example.com/channel7 ).

7.3 Relays

   In order for RUP deployments to scale and to cross administrative
   boundaries it MUST be possible for the protocol to be relayed (single
   source, single destination) and/or broadcasted (single source,
   multiple destinations) by RUP proxies.

   It SHOULD be possible for INVALIDATIONS to be cached on RUP proxies
   (and potentially caching proxies of other types).  Such cached
   INVALIDATIONs MUST have the same effect as if the message had reached
   the destination directly from the source.

7.4 Extensibility

   It is anticipated that additional operations will be required, and
   that options for specific implementations and uses may be desired.
   RUP protocols SHOULD contain a means of extending the base protocol
   for the future.

   INVALIDATIONS MAY carry a set of options.  Options MUST be atomic.
   RUP CLIENTS MAY ignore options but MUST indicate in acknowledgments
   which options were applied.

   [Ed note: I believe that is impossible when using a relay.

7.5 Other issues

   Intermediaries are connected to the Internet in many ways, an in
   order to scale invalidation services many network/service providers
   are likely to want to make use of tecnologies such as satellite
   transmission and IP multicast.  Protocol designers should carefully
   consider the implications of running their protocol over such media
   (e.g.  "broadcast" nature of satellites).

   It is likely that either RUP SERVER or RUP CLIENT or both will be
   situated behind firewalls or Network Address Translators (NATs).
   Protocol desginers should consider implications of firewall traversal
   and the effects that NAT may have on their protocol.

8. Security Considerations

   Intermediaries present security problems which do not exist in the
   classic end-to-end model of the Internet, by introducing a 'Man In
   The Middle' by design.  As such, it is essential that protocol level
   work on intermediaries takes care to devise means by which the



Cooper, et al.           Expires August 29, 2002               [Page 11]


Internet-Draft              RUP Requirements               February 2002


   integrity of the resources being updated can be preserved - or at
   least tested.

   1.  Authentication and authorization: the protocol SHOULD be able to
       authenticate the parties of a session before commencing the
       session, so that no un-authorized parties may participate the
       session.

   2.  Session integrity: the protocol SHOULD be able to ensure the
       integrity of the resource update messages, so that any tempering
       can be detected and/or recovered from.

   3.  Session secrecy: the protocol SHOULD be able to ensure the
       secrecy of the resource update messages, so that no un-authorized
       parties can eavesdrop the session.

   4.  Denial of service: the protocol SHOULD provide counter measures
       to denial-of-service attacks, such as distributed SYN flood or
       resource update storm.
       [Ed note: Surely SYN flood operates at a level too far below
       anything that RUP would touch directly.]

   5.  In-band security: the protocol SHOULD be able to prevent trusted
       parties from flooding and/or disabling the RUP service,
       accidentally or intentionally.

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

9. Acknowledgements

   Thanks to Mark Nottingham, Oskar Batuner, Mark Day, Phil Rzewski,
   Paul H.  Gleichauf, Fred Douglis, Lisa Dusseault, Ted Hardie, Joe
   Touch, Brad Cain, Hilarie Orman, Lisa Amini, Joseph Hui, Alex
   Rousskov, Stephane Perret, Darren New, Christian Maciocco, Michael
   Condry, Renu Tewari, Tao Wu, and the rest of the WEBI working group
   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).

References

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




Cooper, et al.           Expires August 29, 2002               [Page 12]


Internet-Draft              RUP Requirements               February 2002


   [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]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

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

   [6]   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.

   [7]   Mogul, J., Krishnamurthy, B., Douglis, F., Feldmann, A.,
         Goland, Y., van Hoff, A. and D. Hellerstein, "Delta encoding in
         HTTP", RFC 3229, January 2002.

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

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

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

   [11]  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.

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

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

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




Cooper, et al.           Expires August 29, 2002               [Page 13]


Internet-Draft              RUP Requirements               February 2002


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

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

   [17]  Cohen, J. and S. Aggarwal, "General Event Notification
         Architecture Base", internet-draft http://www.alternic.org/
         drafts/drafts-c-d/draft-cohen-gena-p-base-01.pdf, July 1998.

   [18]  Day, M., "A Model for Content Internetworking (CDI)", draft-
         ietf-cdi-model-00 (work in progress), February 2002.

   [19]  Green, M., "Content Internetworking Architectural Overview",
         draft-ietf-cdi-architecture-00 (work in progress), February
         2002.

   [20]  Cooper, I. and J. Dilley, "Known HTTP Proxy/Caching Problems",
         RFC 3143, June 2001.


Authors' Addresses

   Ian Cooper
   Editor
   No address available

   Phone: +44 7966 285145
   EMail: ian@the-coopers.org


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

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











Cooper, et al.           Expires August 29, 2002               [Page 14]


Internet-Draft              RUP Requirements               February 2002


   Mike Dahlin
   University of Texas
   Taylor Hall 2.124
   Department of Computer Sciences
   University of Texas
   Austin, TX  78712-1188
   USA

   Phone: +1 512 327 7251
   EMail: dahlin@cs.utexas.edu


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

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

Appendix A. Change Log

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

   Revision Log:

   -02 to -03 [February 2002] / Edits by Ian Cooper

   Note: Section numbers refer to those in draft-02 NOT this version

   1.   Changed title and publication date

   2.   Amended abstract:

           Rearranged text to flow more intuitively

           Better described how RUP candidates should consider
           invalidation a mandatory requirement but should consider
           other methods that are also described in the document

   3.   Re-worded introduction to try and identify motivation using
        better language.




Cooper, et al.           Expires August 29, 2002               [Page 15]


Internet-Draft              RUP Requirements               February 2002


   4.   Examples of cache coherence/invalidation protocols/techniques
        changed from a paragraph introducing them to references of some
        known work

   5.   Re-jigged the text in "design guidelines"

   6.   Scoping (section 4): placed requirement on protocol candidate
        specifications to carry warnings/security considerations on
        integration of the protocol in user agents (as defined in
        RFC2616)

   7.   Scoping (section 4): text indicating SURROGATES should be
        favored over caching proxies clarified

   8.   Cleaned up introduction to the Use Cases

   9.   Intra-CDN use case: tidied up wording to better explain why a
        CDN might want to use an IETF standardized protocol internally

   10.  Content provider to CDN: re-jigged to better explain why content
        providers and developers of content management systems benefit
        from a standardized protocol.

   11.  Attempted to more accurately describe Content provider to
        arbitrary web intermediary use case.

   12.  Moved 5.5, Operations, to a new major section (section 6)

   13.  Content location update could be seen as offering a means to
        address A.1.1 in RFC3143, text inserted to identify this fact.

   14.  RUP Client invalidation:

        was: "The RUP CLIENT controls RUP activity according to its
           load, failure recovery needs and configured preferences.  The
           RUP SERVER replies to requests with latest changes since the
           last time the RUP CLIENT asked."

        now: "The RUP CLIENT controls RUP activity accorting to its own
           load, failure recover needs, and configured preferences;
           connections are established by the RUP CLIENT and SHOULD be
           persistent.  The RUP SERVER responds to requests by
           indicating which entities or resource groups have been
           updated and must be invalidated."

   15.  RUP Client invalidation: removed seemingly redundant paragraph:
        "Whether and when the RUP CLIENT communicates with the RUP
        SERVER is determined by the consistency guarantee the RUP CLIENT



Cooper, et al.           Expires August 29, 2002               [Page 16]


Internet-Draft              RUP Requirements               February 2002


        is committed to provide, and MUST [??] follow the semantic rules
        defined by the RUP protocol."

   16.  Content updates

        was: "RUP proposals SHOULD NOT provide mechanisms for providing
           content updates.  Any support of content updates is OPTIONAL.

           Content updates refers to the scenario where a RUP SERVER
           sends either the full content of updates to entities, or
           deltas of those changes to RUP CLIENTS.

           At the time of writing there is insufficient understanding of
           the kinds of content updates that RUP might need to support.
           In particular we are aware that mixing signalling with data
           leads to problems of scaling, object consistency, and
           security issues, among others.

           Existing mechanisms addressing content retrieval, e.g., HTTP
           [6] and Delta Encoding [7] demonstrate the high complexity of
           such functionality.  Content prefetch hints enable
           participating RUP CLIENTS to invalidate and fetch content
           with somewhat similar results to content updates."

        now: "A RUP SERVER sends either the full content of entities
           (overwrite) or delta updates to RUP CLIENTS in order to
           update or push content into the corresponding content caches.

           At the time of writing there is insufficient understanding of
           the kinds of content updates that might need to be supported.
           In particular, those working in this area are aware that
           mixing signalling with data leads to problems of scaling,
           entity consistency, and security issues, among others.
           Existing mechanisms addressing content retrieval, e.g.  HTTP
           and Delta Encoding [7] demonstrate the high complexity of
           such functionality.

           Content prefetch hints (see Section ...) enable participating
           RUP CLIENTS to invalidate and fetch content with somewhat
           similar results to content updates.

           Content updates SHOULD NOT be supported."

   17.  HTTP Warnings: SHOULD changed to MUST

   18.  Resynchronization: the content included in this section seems
        more usefully included as a hint to designers in the prior
        section (transitioning into RUP control).  "Express



Cooper, et al.           Expires August 29, 2002               [Page 17]


Internet-Draft              RUP Requirements               February 2002


        resynchronization" was a special case of this situation.

   19.  Section 6.2 (Naming and Framing) onwards have serious edits as
        given below.

   20.  6.2/1 This section describes the grouping of resources into a
        RESOURCE GROUP that has its own identifier for the purposes of
        scaling.

   21.  6.2/2 This item not needed.  Choice of grouping is up to the
        operator of the system, not even the protocol.  Item removed.

   22.  6.2/3 and 6.2/5 merged into a section on resource grouping.

   23.  6.2/4 addresses guidence to protocol designers on aspects of
        scaling their protocols, but should be common sense.  Item
        removed.

   24.  6.3 (Notification groups) defines a requirement for the protocol
        to transfer multiple INVALIDATIONs in the same request.  Move
        that point to "Operations" section.  6.3/2 is really just a way
        of encapsulating group URIs together under yet another URI (a
        further level of indirection).  This should be possible by
        recursive URI resolution of the groups in any case.  Item
        removed.

   25.  6.4 (extensibility) shortened

   26.  6.5/1 Redundant; implicit; removed

   27.  6.5/2 Mentioned in "Scoping", not necessary to repeat;
        presumtive; removed

   28.  6.5/3 Already stated in design guidelines; removed

   29.  6.5/4 Underlying media considerations reworded

   30.  6.5/5 Duplication of an earlier functional requirement for
        acknowledgements

   31.  6.5/6 Establishes a MUST requirement on acknowledgements;
        removed

   32.  6.5/7 Description of operation based on non receipt of
        acknowledgements should be left to protocol designers, not
        included in this document; removed

   33.  6.6/1 Already stated and unnecessary; removed



Cooper, et al.           Expires August 29, 2002               [Page 18]


Internet-Draft              RUP Requirements               February 2002


   34.  6.6/2 Reworded under "Other Issues"

   35.  6.6/3 This is an important point - promoted to a section
        directly under functional requirements.  Note: There may be a
        requirement for RUP SERVERs to be able to understand
        acknowledgements that may be relayed from sources that are
        unknown to it

   36.  6.7/1 If it should be possible to layer RUP on any underlying
        transport (e.g.  from TCP to BEEP to SOAP) then it seems
        pointless saying that; removed.

   37.  6.7/2 Duplication of a major security consideration; removed.

   38.  6.7/3 RUP SERVER discovery is out of scope for this document;
        RESOURCE GROUP discovery is already covered; removed

   20-Nov-2001/Edits by Ian Cooper

   1.   Moved revision log to appendix.

   2.   Changed draft to "compact" mode to save some space

   3.   Significant changes in second paragraph of introduction in an
        attempt to clarify motivation for this work

   4.   Cleared up terminology section
        Question: Does the term invalidation fit?  Removed initial
        wording which said "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 a conditional HTTP
        request.

   5.   Moved references to cache coherence literature to the
        introduction (sub-optimal, but at least it's not in the
        terminology section any more)

   6.   Design guideline 1, changed to just read it should be extensible

   7.   Ian's interpretation on the design guidelines.

   8.   Attempted some wording to try to stop RUP being put into user
        agents (or acting as a pointer to protocol developers to get
        them to try to design things that make doing this difficult).
        Need a security considerations section to go with this...




Cooper, et al.           Expires August 29, 2002               [Page 19]


Internet-Draft              RUP Requirements               February 2002


   9.   Moved performance requirement from "scoping" to "guidelines" (it
        can't be any more than that)

   10.  Attempted to clarify the differences of administrative domain
        use cases by splitting into sub-sections (more detail is
        probably needed).

   11.  Split operations into subsections.  Attempted to clarify the
        language.

   12.  Content updates added as an operation, but wording added to
        state that it SHOULD NOT be provided.

   13.  Changed format of 6.1 (coherence model) to give each point a
        sub-sub- section

   14.  Coherence model, requirement 6.1/6 (resource update guarantees
        must propagate through scaling mechanisms) clarified and
        restated in 6.1.1 since this is already talking about relays.
        (Note: Eeek, state!!!)

   15.  Changed client/server to RUP CLIENT and RUP SERVER throughout

   16.  Changed object etc.  to entity throughout (I hope)

   Previous:/Edits by Dan Li

   1.   remove references to NAT.

   2.   describe the need to work with RUP session discovery mechanisms.

   3.   limit the doc to "requirements", and not "protocol design".

   4.   remove the terms "transaction" and "mirrors" since they convey
        strong meanings in other senses.

   5.   ensure that "confirmation of action" is a requirement.

   6.   clarify on the "guarantees" RUP needs to provides, and not claim
        to "support" or "require" strong consistency.

   7.   clarify the motivations for server-driven and client-driven
        modes.

   8.   clarify that general "meta data" is allowed, and accommodated as
        concrete payload types and arbitrary payload options, while
        invalidation is the primary payload at present.




Cooper, et al.           Expires August 29, 2002               [Page 20]


Internet-Draft              RUP Requirements               February 2002


   9.   clarify the terms "RUP client" and "RUP server", and remove
        ambiguous references to "client" or "server".

   10.  remove the distinction between "managed" and "unmanaged", remove
        any mention of them.

   11.  add use cases in terms of administrative roles, i.e., a list of
        entities that are allowed to participate within the RUP protocol
        realm.

   12.  include the reference to a microsoft's notification proposal.

   13.  add requirements on flexible content "selectors".

   14.  restructure the section on "naming and framing" to clarify three
        items



































Cooper, et al.           Expires August 29, 2002               [Page 21]


Internet-Draft              RUP Requirements               February 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  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.



















Cooper, et al.           Expires August 29, 2002               [Page 22]