45th IETF
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.
o 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
o Is it OK to diverge? Be less restrictive/specific?
o Influence HTTP/1.1 spec in the future?
* Proxy/Surrogate, reverse proxy/accelerator/server side portals.
o Decision taken:
* Interception/redirection/snooping/hijacking.
o Decision: drop snooping, define the other ones
* Cache array/diffused array/cache cluster.
o Decision: drop diffused array, describe the others.
* Proxy discovery/transparent proxy discovery.
o Transparent discovery for WPAD
* Missing parts:
o Surrogate, network element, reverse proxy
+ Network element: something which introduces multiple paths
between source and destination, transparent to HTTP
o 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
o Input solicited from wrec@cs.utk.edu
* Template completed and current problems solicited in June
o 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
WCCP v2 has been submitted for publication. It was not presented. A new WPAD
draft has been resubmitted. 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.
----------------------------------------------------------------------------
For more information see http://www.wrec.org/.
Contribute to wrec@cs.utk.edu; subscribe at wrec-request@cs.utk.edu.
Return to the 45the IETF Trip Report page.
$Id: ietf-45-wrec-minutes.html,v 1.4 1999/07/20 23:57:36 jad Exp $
----------------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:26 MST