[Draft] minutes for the WREC meeting, IETF48 (Pittsburgh) Apologies for absence: John Martin In addition to a discussion of the WREC Known Problems document (draft-ietf-wrec-known-prob-02.txt) there were two presentations. There was no discussion on the WREC Taxonomy document at this meeting. Surrogates presentation ----------------------- Ted Hardie & Mark Nottingham (draft-nottingham-surrogates-00.txt) Mailing list: surrogates@equinix.com (subscribe at surrogates-request@equinix.com) Open source surrogate: bellwether Definition of the term "surrogate" exists in the WREC taxonomy but this needs to be extended. Need to document the differences from other devices (e.g. proxies); caching surrogates vs. caching proxies. Must examine HTTP headers related to cache-control to distinguish between caching proxies and caching surrogates; determine the applicability of existing headers; get rid of proxy-specific directives. There are currently no interoperable standards for a content provider to interact with multiple CDNs (how to choose between multiple CDNs, where URL re-writing is performed?). There are a minimal set of interactions: expire, refresh, extend TTL, pre-load. Surrogate specific enhancements: authoritative surrogates, content negotiation, authentication issues, redirect resolution. Define semantics of how surrogates behave within the network. Fixing bugs in cache-control headers vs. defining new directives; cache-control headers do not necessarily apply to surrogates (but do apply to other clients). Other groups (e.g. Extensible Proxies & Content Control HTTP headers) are investigating HTTP header issues; there should be cooperation between the groups. HTTP specification prohibits (new?) end-to-end headers. However, the surrogate acts as a gateway. The authorization issues surrounding surrogates are presently not clear. Work needed: * Definition of the term * Document differences from other devices * Examine HTTP headers for applicability Volunteer Authors: Mark Day, Fred Douglis, Jon Stracke Extensible Proxies presentation ------------------------------- Gary Tomlinson (draft-tomlinson-epsfw-00.txt) Mailing list: ietf-opencache@imc.org (subscribe ietf-opencache-request@imc.org) Workshop on 13 September 2000 Intent is to provide content driver services within proxies: * there are currently no standards in place * orthogonal to caching proxy infrastructure * provides an opportunity for a (caching) proxy to exploit content-driven services * Need to develop the framework, requirements, and standards * Examine security issues * Modifying bits on the fly * Value add to content services (e.g. Ad. injection) * Operate on behalf of users or content providers Within the extensible proxies framework an interception proxy should never change content without a content provider relationship. Goals: * Establish standard architecture requirements, protocols, APIs * Consistent with end-to-end principle * Encompass IETF frameworks including AAA and policy * Programming language independence First goal is to develop the framework. Next steps: * suitable for IETF? (consensus suggests *not* suitable for WREC) * spans sufficient space for own WG * need input from content providers - their perspective is currently missing * consider the issue of APIs in IETF * request for a bof in San Diego? WREC Known Problems draft ------------------------- Ian Cooper (draft-ietf-wrec-known-prob-02.txt) 19 submissions covered in the current draft, plus 1 submission since - Architecture: 9 (+1) - Implementation: 6 - Administration: 4 Architecture: "Interception proxies break client cache directives" (Clients do not send cache-control headers as they believe they are communicating with a server, not a proxy) Fix RFC2616 - cache control headers should always be sent Very high priority (10/10) Work on proxy discovery to remove need for interception proxies "Interception proxies prevent introduction of new HTTP methods" Already "fixed" within RFC2616 RFC2616 states that a proxy must operate as a tunnel if it does not understand a request "Interception proxies break IP address-based authentication" (Content providers mistakenly using IP based authentication) Recommend creation of an Informational RFC for advise on dos and don'ts for content providers Medium priority (6/10) "Cannot specify multiple URIs for replicated resources" (Servers/proxies cannot redirect requests to alternate locations where the resource is known to reside) Priority -1/10 - take to mailing list "Replica distance is unknown" Priority of -10/10 - "impossible" to calculate, should not be an area of interest for the group, let CDNs use their own secret sauce "Proxy resource location" (and surrogates) Medium priority (4/10) "Caching proxy peer selection in heterogeneous networks" Of interest to the group, come back to this at a later date Low priority (2/10) "ICP performance" (should be moving away from ICP) "Caching proxy meshes can break HTTP serialization of content" Move away from use of heuristics Low priority (1/10) "The Vary header is underspecified and/or misleading" Work with other groups (e.g. cnhhttp) to improve Medium priority (5/10) Implementation: "Use of Cache-Control headers" (Content providers not using Cache-Control headers) Do's and don'ts document Medium priority (6/10) "Lack of HTTP/1.1 compliance for caching proxies" Little that the group can do directly Push the community to provide better support Low priority (for WREC) (1/10) "ETag support" Little that the group can do directly Push the community to provide better support Low priority (for WREC) (1/10) "User agent/proxy failover" Related to discovery of proxies Medium to high priority (7/10) "Servers and content should be optimized for caching" Dos and don'ts document Medium priority (6/10) "Some servers send bad Content-Length header for files that contain CR" Not something the group can address, programming bugs (0/10) Administration: The group identified that WREC is not in a position to do any work in this area. Next steps: * Re-work KP document to better describe those problems the group plans to address; move other problems to appendix so that they are at least captured in a single location * Identify those areas future work for the group and get started - "fix" RFC2616 cache-control issues - proxy/surrogate discovery - document on dos and don'ts for content providers - better specification of Vary header (with cnhhttp)