Subject: Re: Fwd: I-D ACTION:draft-danli-wrec-wcip-00.txt

From: "Hilarie Orman" <[email-masked]>
Date: Tue, 21 Nov 2000 15:19:37 -0700

SSL doesn't mandate secrecy.

The IETF and W3C have an XML signature standard in
progress.

Hilarie

>>> Dan Li <[email-masked]> 11/21/00 12:27PM >>>
At 09:45 AM 11/21/00 -0700, Hilarie Orman wrote:
>I think the security section is a little confused.  SSL doesn't use digital
>signatures to validate content.  Instead, SSL uses public key methods
>to establish a symmetric key that can be used to generate a message
>authentication code for data carried over TCP.  Maybe that's what was
>meant by "unicast can use SSL" after option 2, but it's not clear.
>
>You might use an XML signature for messages
>that were multicast, or you might establish a symmetric key for
>use by a group.  It's unlikely that you'd want to use digital
>signatures because of the computational cost and induced
>latency in processing the messages, but that's an engineering
>tradeoff decision.
>
>Basically, you need to decide if the security is done at the
>transport or application level, what the trust relationships are,
>and what the crypto encoding framework is.

I hope we only get to decide on a off-the-shelf security protocol and not 
reinventing anything. So, SSL, PGP, seem good candidates. SSL is transport 
level while PGP is app level. PGP may be a bit more flexible (optional 
encryption, signature, etc.), while SSL mandates not only authenticity but 
also secrecy and applies to all bytes (it's very simple this way though). 
Any other candidate? AAA?

Dan

>There's a need for a generic cache communication protocol that
>will support cache functionality extensions without requiring a lot
>of new protocols over http.  Sessions, security, robustness,
>multicast, encodings, etc., these keep being reinvented.
>If BXXP+XML can cover the space, then this is probably the
>time to adopt them.
>
>XML for bulk data seems worrisome because of the processing
>latency and space inefficiency.
>
>Hilarie
>
> >>> Dan Li <[email-masked]> 11/15/00 01:57PM >>>
>Hi, please take a look of the WCIP draft before the IETF meeting, as we'd
>spend time on issue discussions and won't cover the draft in detail. This
>draft is a strawman, at least the following things need more work:
>
>- clearly define the relationship of wcip with normal cache-control 
>directives.
>
>- specify in more detail the role of relay point, especially for channel
>aggregation. Can we or can we not aggregate heartbeats, possibly but
>cutting freshness guarantee.
>
>- pick a security model. Use SSL, or PGP signature, or both, and also the
>security of the channel info.
>
>- do we need a default port number? pros and cons wrt. to port 80.
>
>- are people happy with persistent TCP connection? are people happy with
>"delta consistency" (vs. eventual consistency, strong consistency, or
>anything else).
>
>- in the absence of a off-the-shelf realtime reliable multicast protocol,
>can we still run wcip on multicast UDP for scalability. See section 3.2.3.
>
>- preloading, log reporting, advanced event notification, programability,
>.. future stuff on vertical peering and dynamic content
>
>What do people think?
>
>Dan
>
>
>
>
>
>At 08:12 AM 11/15/00 -0800, Ian Cooper wrote:
>
> >>To: IETF-Announce: ;
> >>From: [email-masked] 
> >>Subject: I-D ACTION:draft-danli-wrec-wcip-00.txt
> >>Date: Wed, 15 Nov 2000 06:41:12 -0500
> >>
> >>A New Internet-Draft is available from the on-line Internet-Drafts
> >>directories.
> >>
> >>
> >>         Title           : WCIP: Web Cache Invalidation Protocol
> >>         Author(s)       : D. Li, P. Cao, M. Dahlin
> >>         Filename        : draft-danli-wrec-wcip-00.txt
> >>         Pages           : 26
> >>         Date            : 14-Nov-00
> >>
> >>Cache consistency is a major impediment to scalable content
> >>delivery. This document describes the Web Cache Invalidation
> >>Protocol (WCIP) which uses invalidations and updates to keep
> >>changing objects up to date in web caches. Moreover, it allows
> >>automatic one-to-may relay and many-to-one aggregation in a CDN
> >>(content delivery network) environment.
> >>
> >>A URL for this Internet-Draft is:
> >>http://www.ietf.org/internet-drafts/draft-danli-wrec-wcip-00.txt 
> >>
> >>Internet-Drafts are also available by anonymous FTP. Login with the 
> username
> >>"anonymous" and a password of your e-mail address. After logging in,
> >>type "cd internet-drafts" and then
> >>         "get draft-danli-wrec-wcip-00.txt".
> >>
> >>A list of Internet-Drafts directories can be found in
> >>http://www.ietf.org/shadow.html 
> >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt 
> >>
> >>
> >>Internet-Drafts can also be obtained by e-mail.
> >>
> >>Send a message to:
> >>         [email-masked].
> >>In the body type:
> >>         "FILE /internet-drafts/draft-danli-wrec-wcip-00.txt".
> >>
> >>NOTE:   The mail server at ietf.org can return the document in
> >>         MIME-encoded form by using the "mpack" utility.  To use this
> >>         feature, insert the command "ENCODING mime" before the "FILE"
> >>         command.  To decode the response(s), you will need "munpack" or
> >>         a MIME-compliant mail reader.  Different MIME-compliant mail 
> readers
> >>         exhibit different behavior, especially when dealing with
> >>         "multipart" MIME messages (i.e. documents which have been split
> >>         up into multiple messages), so check your local documentation on
> >>         how to manipulate these messages.
> >>
> >>
> >>Below is the data which will enable a MIME compliant mail reader
> >>implementation to automatically retrieve the ASCII version of the
> >>Internet-Draft.
> >>
> >>Content-Type: text/plain
> >>Content-ID:     <[email-masked]>
> >>
> >>ENCODING mime
> >>FILE /internet-drafts/draft-danli-wrec-wcip-00.txt
> >>
> >><ftp://ftp.ietf.org/internet-drafts/draft-danli-wrec-wcip-00.txt>
> >

---

From: Dan Li <[email-masked]>
Date: Wed, 22 Nov 2000 06:31:39 -0800

Given that this protocol specifies a notification transport (channels, 
relays, aggregations, etc.) and various notifications (invalidation, 
updates, preloads, log report, etc.) on top of it, the word "invalidation" 
seems less than descriptive as in WCIP.

Along this line, it sounds to me that something like WCUP "web cache update 
protocol" would be better. If the name WCIP is over restrictive and we may 
need to change it sooner or later, I'd say we change it now. Do you feel 
the need?

Dan

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 22 Nov 2000 11:17:29 -0800

Agree; I think that this can and should evolve into a general mechanism for
propagating messages from the origin to intermediaries.

I'd say the general characteristics of what we're chasing (straw man) are:

* intermediary (client) registers interest in resource(s) with a server (can
  be, but doesn't have to be, the origin)

* once registered, message flow is predominantly server->client, initiated
  by server

* message payload can be invalidations, object metadata/handling
  instructions, deltas, etc. (don't know if log pushing is in scope)

So, 'U' for update is more accurate, if we go this way. One might also say
that 'C' for cache is a bit restrictive/misleading; How about Web
Intermediary Update Protocol -- WIUP? 

I like 'W' for Web, as Web is > HTTP; it denotes that the protocol can
update anything with a URI.

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA)

---

From: <[email-masked]>
Date: Wed, 22 Nov 2000 12:18:54 -0800 (PST)

URI Update Protocol would end up being "You up?", a common enough
protocol message in this arena.

For the irony impaired, I'm joking.

					Ted

---

From: Dan Li <[email-masked]>
Date: Sat, 25 Nov 2000 12:52:26 -0800

>protocol message in this arena.

with WIUP, it may sound like "Why Up" ;-) Could we get rid of one vowel?

I agree "cache" as in WCUP is too restrictive, and yet "intermediary" in 
WIUP is too loose. How about a Web Proxy Update Protocol?

Dan

---

From: Ian Cooper <[email-masked]>
Date: Sat, 25 Nov 2000 16:45:10 -0800

[With apologies to everyone getting 2 copies.  We're probably all on the 
mailing list, but just in case...]

>WIUP is too loose. How about a Web Proxy Update Protocol?

The protocol has use in CDN environments (for example, it could be of use 
in CDN peering), in which case "proxy" is too restrictive.  Not sure that 
simply using "proxy" gets the right message across anyway (it's the cache 
within a caching proxy that's being updates).

"Distributed Web Object Consistency Protocol" (choose your acronym to come 
up with something funky) seems closer to what's being considered.

All that said, we're perhaps spending too much time thinking about what to 
call it when we should be working on what it actually does and how it does 
it.  (Hmm, memories of a certain Dilbert come to mind.)

---

From: Dan Li <[email-masked]>
Date: Sat, 25 Nov 2000 21:26:42 -0800

>up with something funky) seems closer to what's being considered.

"consistency protocol" is just one aspect of it, given that the protocol 
ought to cover not only invalidation but also updates and other types of 
notifications. I think having a "U" for update there is the right thing.

Dan