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.