Subject: Draft WREC minutes (IETF48)

From: Ian Cooper <[email-masked]>
Date: Sun, 10 Sep 2000 12:21:52 +0100

[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: [email-masked]
    (subscribe at [email-masked])

Open source surrogate: bellwether 
<URL:ftp://ftp.equinix.com/bellwether/bellwether.tar.gz>

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: [email-masked]
    (subscribe [email-masked])

<URL:http://www.extproxy.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)
     Dos 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)