NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 24-Jun-99
Chair(s):
John Martin <martin@terena.nl>
Bill Maggs <billm@mci.net>
Applications Area Director(s):
Keith Moore <moore@cs.utk.edu>
Patrik Faltstrom <paf@swip.net>
Applications Area Advisor:
Keith Moore <moore@cs.utk.edu>
Mailing Lists:
General Discussion:wrec@cs.utk.edu
To Subscribe: wrec-request@cs.utk.edu
Archive: ftp://cs.utk.edu/pub/wrec
Description of Working Group:
The purpose of this working group is to define a co-ordinated caching and replication framework for the world wide web.
Replication of web services and caching of http responses are distinct paradigms that to a large degree require distinct solutions. However, it is also important that web caches and replicated services be able to coexist. Ultimately, the working group will define a framework for efficient, reliable, and predictable service in a web which includes both replicas and caches. Part of this framework will be a means by which replicas and caches may be automatically discovered and utilized by clients.
Because of the wide variety of caching and replication solutions which are already in use, the initial task of the group is to familiarize itself with the diversity of existing practice. The group will therefore produce a document which provides a taxonomy of existing caching / replication developments and terminology which would be used as a reference for later work. In parallel with this, existing protocols and standards which are not publicly documented will be submitted to the IESG for publication as informational RFCs by their respective proponents. Once the initial phase is complete, the group will make a recommendation as to whether further protocol work is necessary or desirable, and submit a revised charter for consideration by IESG and IAB.
Goals and Milestones:
Mar 99 |
|
First issue of I-D on taxonomy and terminology (Editor: I. Melve) |
Mar 99 |
|
First issue of I-Ds on existing caching / replication protocols |
Mar 99 |
|
Meet at Minneapolis IETF |
Apr 99 |
|
First issue of I-D on design goals / research issues (Editor: J. Touch) |
Apr 99 |
|
Final issues of I-Ds on existing caching / replication protocols |
Jun 99 |
|
Final issue of I-D on taxonomy and terminology |
Jun 99 |
|
Final issue of I-D on design goals / 688 research issues |
Jul 99 |
|
Meet at Oslo IETF |
Jul 99 |
|
Submit I-Ds to IESG for publication as Informational RFCs |
Jul 99 |
|
Revise charter |
Internet-Drafts:
· Inter Cache Communication Protocols
· Internet Web Replication and Caching Taxonomy
· Web Caching and Replication -- Research Issues
No Request For Comments
WREC Working Group Minutes
These are the minutes from the Web Replication and Caching (wrec) working group meeting at the 45th IETF meeting in Oslo, Norway on 12 July 1999. These minutes are available on the web at http://www.hpl.hp.com/personal/John_Dilley/ietf-45-wrec-minutes.html.
WREC Taxonomy Document - Ingrid Melve
Ingrid presented the current status of the Web Replication and Caching Taxonomy working draft, draft-ietf-wrec-taxonomy-01.txt, and asked the attendees for input on a number of remaining open issues. This section captures highlights from the presentation, summarizing the slide presentation.
Taxonomy Draft
Points here: assume you have read the draft. The main issues are security, terminology, and "transparent". The team is aiming for a final version "real soon now".
Security, Non-issues
Non-issues related to security include system security and HTTP; the draft is not doing anything about these, take them as they are. The underlying security issues are taken as a baseline for web cache security.
Security Issues
The main security issues for web caching were discussed. At present these are
· Authentication: man in the middle, trusted third party.
· Privacy: logs and legal implications, trusted third party.
· Service security: denial of service, replay attack, stupid configuration of proxies, copyrighted transient copies.
· Transient copies includes both the issue of trust of data from the cache and copyright (IP rights). IPR issue to be referred to a separate working group.
Terminology
· Some terms are different from the HTTP/1.1 spec: proxy, tunnel, cache, transparent
· Is it OK to diverge? Be less restrictive/specific?
· Influence HTTP/1.1 spec in the future?
· Proxy/Surrogate, reverse proxy/accelerator/server side portals.
· Decision taken:
· Interception/redirection/snooping/hijacking.
· Decision: drop snooping, define the other ones
· Cache array/diffused array/cache cluster.
· Decision: drop diffused array, describe the others.
· Proxy discovery/transparent proxy discovery.
· Transparent discovery for WPAD
· Missing parts:
· Surrogate, network element, reverse proxy
- Network element: something which introduces multiple paths between source and destination, transparent to HTTP
· Temporal domain, sparse working set cache. Persistent domain.
· Scratch these and replace by functional definition?
- Joe Touch will send mail on spatial, temporal, and ensemble domains.
How should terminology be described in the document?
· Try where possible to use commonly used term and list synonyms and other terms
· Or present functional description and list the terms used to describe that function.
· Resolution: functional description followed by commonly used terms (which fill a continuum in current usage).
Transparency
Suggestion: always preface the term transparent with an adjective, such as "semantic", "network", "user", "automatic configuration". Define these terms. Transparency is dependent upon the layer you are working at. HTTP/1.1 working group has also fought with this.
Need to distinguish between browser configuration and network transparency. Avoid use of transparency for browser configuration -- call that automatic browser configuration.
Next draft to be available by 1st September 1999 for presentation to the wrec@cs.utk.edu mailing list. Goal: get closure via the mailing list before the Washington IETF meeting.
Inter-Cache - Ian Cooper
The Inter-Cache effort is working out protocol modifications in ICP and HTCP to improve how caches communicate. Three changes have been agreed to in the last six months, and are in the process of being implemented. The next document revision will correct some remaining minor problems and will be submitted as an Internet Draft. The three changes are:
· Via header modification to HTTP (at request of NetApp). Additional comments.
· PURGE method added to HTTP and ICP to delete copies of objects from cache.
· Remove redundant URL from ICP replies on hit and miss. Not actually needed so remove it.
Via Header Mods
Add product-name and product-version, add tracecode and trace-time. See the working draft for details.
Comment: you might want to carry this information for events other than a hit or a miss, for example access denied or for caches to exchange product name and version information.
Question: what is trace time? Trace time is the time the object was last verified by the proxy. Need for multiple trace times since each proxy in the chain can validate at a different time; trace time is different from last-modified time.
PURGE Method
Two purge operations are proposed for ICP and HTTP:
· Trivial: carried by ICP over UDP, has no response, does not change ICP version, cache may ignore it.
· Decisive: carried over HTTP, is acknowledged using standard HTTP response codes, must not be forwarded to an origin server. Conditionals in request must be forwarded.
Should have an implementation note so proxies will err on the side of conservatism and : keep these PURGE methods from going too far.
Question: the threat model is obvious. What is the security model?
· Not yet defined/documented. Expect to use HTTP when security is desired and use authentication and authorization.
· Expected to be used within an administration domain or which have an administrative relationship; not intended for general use in the open Internet.
· Default is not to forward PURGEs; can be configured to forward to child caches.
· Does this work with a collection (as defined in webdav wg)? A PURGE on a collection should remove the "ls" output; it should not purge the children.
Remove URL from ICP Replies
New ICP flag; if present in a request, response must include the flag and should not send the URL in payload. Standard RFC2168 response if flag is not present in a request - products should be careful to follow the spec.
Recommend to make this an informational RFC.
Point from the floor: documents must be standards track to add a new method to HTTP/1.1 standard. Is this planned?
Known Problems Draft - John Dilley
Document Purpose: Document the state of content caching protocols and products on the web today.
· Provides information to the caching community (vendors and users). Requires participation from the community.
· Known Problems template created and distributed for comment in May
· Input solicited from wrec@cs.utk.edu
· Template completed and current problems solicited in June
· Input solicited to jad@hpl.hp.com
· Next draft will be posted to mailing list shortly incorporating input to date.
Known Problems - Summary of current submissions made; see the draft for details.
· Input received from several contributors. Problem areas include: ICP, transparency, cache-control headers
· Problems reported had very little overlap - Indicates the coverage is far from complete
· Input needed from cache operators, end users, and vendors.
Next Steps
· Please send comments to the editor! - John Dilley jad@hpl.hp.com
· Subscribe to the wrec mailing list - wrec-request@cs.utk.edu
· Watch for publication of working draft - draft-wrec-known-prob-00.txt
Brian Carpenter: Status of WPAD: is it really a solution to a known problem? Is it a proprietary technology? May not be relevant to this document. Company submittals are OK but are different from (IETF) standard solutions.
Joe Touch: Difference between performance issues and known problems. Know problems break the spec, cause catastrophic problems for conformant products. "Not as good as we want it to be" is another issue. Do we want to capture those in this document? General feeling was yes, we did, although the serious problems should be separated from the performance issues.
Other Business - WREC Chairs
Version 2 of WCCP v1 has been submitted for publication. It was not presented at the meeting. A new version of the WPAD draft has also been submitted. It is implemented in ie5. It was not presented either.
Publishing RFCs as Informational or Standard - Informational is acceptable for proprietary protocols and are useful so specifications are freely available from ietf.org. Standards track RFCs require multiple independent implementations and open, community-influenced specifications.
John Dilley briefly introduced a potential alternative for inter-cache communication based upon a distributed object consistency protocol. An introductory white paper will be posted to the wrec mailing list for discussion and input.
Rechartering: John Martin mentioned the desire to re-charter the group to be able to address broader topics, but noted that we need further progress on current work before rechartering the working group.
None received.