I agree with concerns re: XML, but it deserves consideration. If it can be
used as an extensible packaging mechanism, we'd save a lot of future
headaches. re: inefficiency - in what situations would you want to store the
messages for any considerable period of time?
On Tue, Nov 21, 2000 at 09:45:16AM -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.
>
> 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 <lidan@cisco.com> 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: Internet-Drafts@ietf.org
> >>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:
> >> mailserv@ietf.org.
> >>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: <20001114131241.I-D@ietf.org>
> >>
> >>ENCODING mime
> >>FILE /internet-drafts/draft-danli-wrec-wcip-00.txt
> >>
> >><ftp://ftp.ietf.org/internet-drafts/draft-danli-wrec-wcip-00.txt>
> >
-- Mark Nottingham, Research Scientist Akamai Technologies (San Mateo, CA)
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:29 MST