From owner-wrec@cs.utk.edu Wed Oct 4 05:21:47 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14017 for ; Wed, 4 Oct 2000 05:21:47 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id FAA14214; Wed, 4 Oct 2000 05:17:09 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 4 Oct 2000 05:15:31 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id FAA11293; Wed, 4 Oct 2000 05:15:31 -0400 (EDT) Received: from lecs.cs.ucla.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id FAA11209; Wed, 4 Oct 2000 05:15:28 -0400 (EDT) Received: from lecs.cs.ucla.edu (131.179.144.100 -> Lecs.CS.UCLA.EDU) by cs.utk.edu (smtpshim v1.0); Wed, 4 Oct 2000 05:15:28 -0400 Received: from concorde.cs.ucla.edu (concorde.cs.ucla.edu [131.179.144.102]) by lecs.cs.ucla.edu (8.9.3/8.9.3) with ESMTP id CAA08142; Wed, 4 Oct 2000 02:14:58 -0700 Received: from concorde.cs.ucla.edu (localhost [127.0.0.1]) by concorde.cs.ucla.edu (8.9.3/8.9.3) with ESMTP id CAA24360; Wed, 4 Oct 2000 02:14:58 -0700 Message-Id: <200010040914.CAA24360@concorde.cs.ucla.edu> From: Jeremy Elson To: comments@i-cap.org, wrec@cs.utk.edu cc: jelson@isi.edu Subject: ICAP suggested changes/ call for comments Date: Wed, 04 Oct 2000 02:14:58 -0700 Sender: jelson@lecs.cs.ucla.edu List-Unsubscribe: Hi, Some of the early implementors of the new ICAP protocol have been meeting over the past couple of weeks to discuss how the protocol is broken based on recent implementation experience. Based on these discussions we would like to change the protocol in certain ways that we think will make it better but will break interoperability with existing implementations (hey, it was just a draft, right? :-) ) The purpose of this message is to ask any other implementors of ICAP to please join us in our current discussions. In particular, if you have any proposed changes that you think would make the protocol better but would break interoperability, this is a good time to speak up since we're breaking it anyway (and only want to break it once). Please let me know if you'd like to be included in our teleconferences that are Thursday mornings at 9AM Pacific time. The current (proposed) changes that break interoperability are: 1- Chunked encoding will be required, instead of optional (this only affects clients since servers need to understand chunking anyway) 2- Encapsulation Forwarded HTTP requests and responses will be changing. Both forwarded bodies *and* forwarded headers will be contained completely in the body of ICAP message instead of encapsulating the (inner) forwarded headers in the (outer) headers of the ICAP message. 3- We want to make the simplifying assumption that the ICAP server is in the same admin domain as ICAP client. Parts of the protocol had already made this assumption (e.g. for configuration and authentication purposes) but it would make things easier if this was assumed throughout. Also, at the suggestion of some within IETF we will most likely define ICAP to use a port other than 80. (No one on our side of the fence feels strongly at all about this issue; we're just doing what we're told :-)) If you have feedback please let us know at pwg@catarina.usc.edu, or join our teleconf on Thursdays. Regards, Jeremy From owner-wrec@cs.utk.edu Wed Oct 4 06:37:22 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14568 for ; Wed, 4 Oct 2000 06:37:21 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id GAA18812; Wed, 4 Oct 2000 06:33:04 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 4 Oct 2000 06:31:42 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id GAA18724; Wed, 4 Oct 2000 06:31:41 -0400 (EDT) Received: from tyholt.uninett.no (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id GAA18710; Wed, 4 Oct 2000 06:31:38 -0400 (EDT) Received: from tyholt.uninett.no (158.38.60.10 -> tyholt.uninett.no) by cs.utk.edu (smtpshim v1.0); Wed, 4 Oct 2000 06:31:39 -0400 Received: from bakke.uninett.no (IDENT:im@bakke.uninett.no [158.38.60.84]) by tyholt.uninett.no (8.9.3/8.9.3) with ESMTP id MAA04033 for ; Wed, 4 Oct 2000 12:31:36 +0200 Message-Id: <200010041031.MAA04033@tyholt.uninett.no> X-Mailer: exmh version 2.1.1 10/15/1999 To: wrec@cs.utk.edu Subject: FYI, I-Ds on CDNs MIME-Version: 1.0 Content-Type: multipart/digest; boundary="----- =_aaaaaaaaaa0" Content-ID: <1893.970655496.1@bakke.uninett.no> Content-Description: forwarded messages Date: Wed, 04 Oct 2000 12:31:37 +0200 From: Ingrid Melve List-Unsubscribe: ------- =_aaaaaaaaaa0 Content-Type: message/rfc822 Return-Path: ietf-123-owner@loki.ietf.org Delivery-Date: Tue Oct 3 14:26:33 2000 Return-Path: Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by tyholt.uninett.no (8.9.3/8.9.3) with ESMTP id OAA02787; Tue, 3 Oct 2000 14:26:31 +0200 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA12457 for ietf-123-outbound.09@ietf.org; Tue, 3 Oct 2000 07:05:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12328 for ; Tue, 3 Oct 2000 06:49:14 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05332 for ; Tue, 3 Oct 2000 06:49:14 -0400 (EDT) Message-Id: <200010031049.GAA05332@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-day-cdnp-model-01.txt Date: Tue, 03 Oct 2000 06:49:14 -0400 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Model for CDN Peering Author(s) : M. Day, B. Cain, G. Tomlinson Filename : draft-day-cdnp-model-01.txt Pages : 17 Date : 02-Oct-00 There is wide interest in interconnecting content distribution networks (CDNs), variously called 'content peering' or 'CDN peering'. A common vocabulary helps the process of discussing such interconnection and interoperation. This document proposes elements for a such a common vocabulary. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-day-cdnp-model-01.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-day-cdnp-model-01.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-day-cdnp-model-01.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001002120537.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-day-cdnp-model-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-day-cdnp-model-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001002120537.I-D@ietf.org> --OtherAccess-- --NextPart-- ------- =_aaaaaaaaaa0 Content-Type: message/rfc822 Return-Path: ietf-123-owner@loki.ietf.org Delivery-Date: Tue Oct 3 14:42:40 2000 Return-Path: Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by tyholt.uninett.no (8.9.3/8.9.3) with ESMTP id OAA04469; Tue, 3 Oct 2000 14:42:38 +0200 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA12576 for ietf-123-outbound.09@ietf.org; Tue, 3 Oct 2000 07:25:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12342 for ; Tue, 3 Oct 2000 06:49:24 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05368 for ; Tue, 3 Oct 2000 06:49:25 -0400 (EDT) Message-Id: <200010031049.GAA05368@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-green-cdnp-gen-arch-00.txt Date: Tue, 03 Oct 2000 06:49:24 -0400 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CDN Peering Architectural Overview Author(s) : M. Green, B. Cain, G. Tomlinson Filename : draft-green-cdnp-gen-arch-00.txt Pages : 32 Date : 02-Oct-00 This memo presents the general architecture and core building blocks used in the peering of content distribution networks (CDNs). This involves the interconnection of CDNs to create larger virtual CDNs with greater reach, while still retaining the same simple interface to both content providers and viewers. The scope of this work is limited to external interconnections between CDNs and does not address internal mechanisms used within CDNs, which for the purpose of the document are considered to be black boxes. This work is intended to establish an abstract architectural framework to be used in the development of protocols, interfaces and system models for standardized, interoperable, peering among CDNs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-green-cdnp-gen-arch-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-green-cdnp-gen-arch-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-green-cdnp-gen-arch-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001002120554.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-green-cdnp-gen-arch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-green-cdnp-gen-arch-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001002120555.I-D@ietf.org> --OtherAccess-- --NextPart-- ------- =_aaaaaaaaaa0 Content-Type: message/rfc822 Return-Path: ietf-123-owner@loki.ietf.org Delivery-Date: Tue Oct 3 14:51:21 2000 Return-Path: Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by tyholt.uninett.no (8.9.3/8.9.3) with ESMTP id OAA05445; Tue, 3 Oct 2000 14:51:20 +0200 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA12517 for ietf-123-outbound.09@ietf.org; Tue, 3 Oct 2000 07:15:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12335 for ; Tue, 3 Oct 2000 06:49:20 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05352 for ; Tue, 3 Oct 2000 06:49:20 -0400 (EDT) Message-Id: <200010031049.GAA05352@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-gilletti-cdnp-accounting-models-01.txt Date: Tue, 03 Oct 2000 06:49:20 -0400 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Accounting Models for CDN Peering Author(s) : D. Gilletti, R. Nair, J. Scharber Filename : draft-gilletti-cdnp-accounting-models-01.txt Pages : 19 Date : 02-Oct-00 This document presents several conceptual and logical models for accounting activities between peered CDNs. This is a new piece of work intended to enumerate the issues and provide additional detail for use when deriving the ACCOUNTING PEERING SYSTEM for a CDN peering model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gilletti-cdnp-accounting-models-01.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-gilletti-cdnp-accounting-models-01.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-gilletti-cdnp-accounting-models-01.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001002120546.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-gilletti-cdnp-accounting-models-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-gilletti-cdnp-accounting-models-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001002120546.I-D@ietf.org> --OtherAccess-- --NextPart-- ------- =_aaaaaaaaaa0-- From owner-wrec@cs.utk.edu Wed Oct 4 18:42:47 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03301 for ; Wed, 4 Oct 2000 18:42:38 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id SAA29681; Wed, 4 Oct 2000 18:38:15 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 4 Oct 2000 18:36:30 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id SAA29479; Wed, 4 Oct 2000 18:36:30 -0400 (EDT) Received: from dirty.research.bell-labs.com (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id SAA29455; Wed, 4 Oct 2000 18:36:11 -0400 (EDT) Received: from dirty.research.bell-labs.com (204.178.16.6 -> dirty.research.bell-labs.com) by cs.utk.edu (smtpshim v1.0); Wed, 4 Oct 2000 18:36:11 -0400 Received: from bronx.dnrc.bell-labs.com ([135.180.160.8]) by dirty; Wed Oct 4 18:34:09 EDT 2000 Received: from bell-labs.com (apache [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id SAA08578; Wed, 4 Oct 2000 18:34:08 -0400 (EDT) Message-ID: <39DBB062.AD58E49@bell-labs.com> Date: Wed, 04 Oct 2000 18:34:10 -0400 From: Markus Hofmann Organization: Bell Labs Research, USA X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,de-DE MIME-Version: 1.0 To: Jeremy Elson CC: comments@i-cap.org, wrec@cs.utk.edu, pwg@catarina.usc.edu, Markus Hofmann , Andre Beck Subject: Re: ICAP suggested changes/ call for comments References: <200010040914.CAA24360@concorde.cs.ucla.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Jeremy, just some quick thoughts and comments on the proposed modifications: > 1- Chunked encoding will be required, instead of optional (this only > affects clients since servers need to understand chunking anyway) This assumes that either no (interception) proxies/caches are on the path between ICAP client and ICAP server, or that all proxies/caches on that path support chunked encoding and forward the message chuncked. This might limit scenarios in which ICAP can be used. Could this be kept optional? This might increase implementation complexity a bit, but it would allow usage of ICAP in the above mentioned environments (having the buffering problem again, of course). Hm, the problem might also be "solved" by using a port different from 80 et. al and by assuming that no other proxy/cache on the path will "intercept" this port... don't want to start the discussion about "interception proxies" again... but they might be there... > 3- We want to make the simplifying assumption that the ICAP server is > in the same admin domain as ICAP client. Hm, this might simply things at the moment, but in general it might not be a good idea to base the protocol design on this assumption. We can imagine scenarios in which a cache service provider collaborates with, for example, a translation service provider - in different admin domains. We would like to have a solution that also works in such an environment - which, of course, would also require mechanisms for authentification and authorization (which might be added later on, but the basic protocol design would still work). Another suggestion we have: Would it make sense to allow multiple ICAP-URIs in a single message? Example: We want to execute two services in Response Modification mode at the same ICAP server, e.g. ad insertion and translation (or vice versa :). Instead of sending two requests in sequence to the same server, it would make sense to send only a single request including both ICAP URIs (i.e ad insertion and translation). What would be the syntax, and what about the ordering (ssems to be important, too). -Markus and Andre From owner-wrec@cs.utk.edu Fri Oct 6 01:13:00 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14328 for ; Fri, 6 Oct 2000 01:12:55 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id BAA19430; Fri, 6 Oct 2000 01:08:35 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 6 Oct 2000 01:06:54 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id BAA19297; Fri, 6 Oct 2000 01:06:53 -0400 (EDT) Received: from server (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id BAA19245; Fri, 6 Oct 2000 01:06:32 -0400 (EDT) From: Message-Id: <200010060506.BAA19245@cs.utk.edu> Received: from server (209.179.44.153 -> pool0153.cvx15-bradley.dialup.earthlink.net) by cs.utk.edu (smtpshim v1.0); Fri, 6 Oct 2000 01:06:51 -0400 Subject: GOCA Date: Thu, 5 Oct 2000 14:28:41 To: undisclosed-recipients:; List-Unsubscribe: Go Call Inc. Announces Arrangement for Private Funding of Reactivation Costs for the Companies Gaming Sites SAN JOSE, Costa Rica--(BUSINESS WIRE)--Oct. 4, 2000--Go Call Inc. (Pink Sheets:GOCA) has announced the arrangement of private funding to enable reactivation of it's key business functions. This funding will allow the company to purchase the remaining technology needed to complete the restructuring started last June. James Palmer, CEO of Go Call Inc (www.gocash.com) said, ``The restructuring done to get the business ready for the Business Plan requirements going into 2001 was lengthy and very involved. We have had a lot of challenges to overcome in getting everything up to the level required to meet our plan. The Company has entered into new contracts, bought new software, changed procedures, changed suppliers, reprogrammed, bought new equipment, and built new graphics interfaces. This restructuring was not only involved but also, with most sites having to be taken down, our income was lower making it a challenge to get it all completed with the available financing. This funding is going to enable us to finish the remaining tasks in October and have all the sites activated, advertising in place, and business systems ready to close out the year with a solid preview of 2001.'' Go Call Inc. is a publicly held company trading on the ``Pink Sheets'' under the symbol ``GOCA''. For more information about the company, please visit the web site at www.gocash.com. Go Call Inc. is an Internet and E-commerce Company. Its services include processing of transactions for online gaming through its Go Cash Inc. subsidiary, whose customers include Lucky Charm Sports Book (www.gowager.com), Rhino's Book (www.goplayit.com), GoScratchTickets.com (www.goscratchtickets.com), Super Mega Lotto (www.supermegeloto.com), and Mega Scratch (www.megascratch.com). Some paragraphs of this news release, particularly those describing Go Call Inc.'s strategies and business plans, contain forward-looking statements within the meaning of Section 27A of the Securities Act of 1933, as amended, and Section 21E of the Securities Exchange of 1934, as amended. While Go Call Inc. is working to achieve those goals, actual results could differ materially from those projected in the forward-looking statements as a result of a number of factors, including difficulties in marketing their products and services, need for capital, competition from other companies and other factors, any of which could have an adverse effect on the business plans of Go Call Inc., its reputation in the industry or its expected financial return from operations. Factors such as these could have an adverse effect on Go Call Inc.'s results of operation. In light of significant uncertainties inherent in forward looking statements included herein, the inclusion of such information should not be regarded as a representation by Go Call Inc. or any other person that the objectives and plans of Go Call Inc. will be achieved. From owner-wrec@cs.utk.edu Fri Oct 6 20:50:26 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15818 for ; Fri, 6 Oct 2000 20:50:26 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id UAA19493; Fri, 6 Oct 2000 20:46:07 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 6 Oct 2000 20:44:41 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id UAA19169; Fri, 6 Oct 2000 20:44:40 -0400 (EDT) Received: from tropical.co.cr (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id UAA19147; Fri, 6 Oct 2000 20:44:28 -0400 (EDT) From: <63426672@yahoo.com> Received: from tropical.co.cr (63.160.71.196) by cs.utk.edu (smtpshim v1.0); Fri, 6 Oct 2000 20:44:29 -0400 Received: from tropical.co.cr [63.178.136.109] by tropical.co.cr (SMTPD32-6.00 EVAL) id A2876E60108; Tue, 03 Oct 2000 20:14:31 -0600 Received: from tv@yahoo.com by info@excite.com (8.8.5/8.6.5) with SMTP id GAA09654 for ; Wed, 04 Oct 2000 09:31:00 -0600 (EST) Date: Wed, 04 Oct 00 09:31:00 EST To: cable@yahoo.com Subject: cable services Message-ID: <> List-Unsubscribe: > > NOTE: THIS IS AN ADVERTISEMENT FOR LEGAL TV > > DE-SCRAMBLER. IF YOU HAVE NO INTEREST IN THIS > > INFORMATION PLEASE CLICK DELETE NOW. THANK YOU-- > > > > LEGAL CABLE TV DE-SCRAMBLER > > Want to watch Sporting Events?--Movies?--Pay-Per-View?? > > You can assemble from electronic store parts for about $12.00. > > We Send You: > > E-Z To follow Assembly Instructions. > > E-Z To read Original Drawings. > > Electronic parts lists. > > PLUS SOMETHING NEW YOU MUST HAVE! > > Something you can't do without. > > THE UP-TO-DATE REPORT: USING A DESCRAMBLER LEGALLY > > Warning: You should not build a TV Descrambler without > > reading this report first. > > Frequently Asked Questions--CABLE TV DESCRAMBLER > > Q: Will the descrambler work on Fiber, TCI, Jarrod > > A: The answer is YES. > > Q: Do I need a converter box? > > A: This plan works with or without a converter box. > > Specific instructions are included in the plans for each! > > Q: Can the cable company detect that I have the descrambler? > > A: No, the signal descrambles right at the box and does > > not move back through the line! > > Q: Do I have to alter my existing cable system, > > television or VCR? > > A: The answer is no! > > Q: Does this work with my remote control? > > A: The answer is yes. The descrambler is > > manually controlled--but very easy to use! > > Q: Can you email me the plans? > > A: No the program comes with an easy to follow picture guide. > > Q: Does this work everywhere across the country? > > A: Yes, every where in the USA plus England, > > Brazil, Canada and other countries! > > Q: Is this deal guaranteed? > > A: Yes, if you are unhappy for any reason we will refund your money. > > Q: When I order, when will I get my stuff? > > A: We mail out all orders within 48 hours of receiving them. > > ORDER INFORMATION > > ACT WITHIN THE NEXT 14 DAYS AND RECEIVE TWO FREE BONUS!! > > THE CABLE MANUAL! This manual contains hard to find information your > > cable company does not want you to know. Also receive The RADAR > > JAMMER PLANS! Never get another speeding ticket. Build you own > > radar jammer, this unit will jam police radar so they can't get a reading > on > > your vechicle. Radar jammers are legal in 48 states. It is simple to > build. > > The FREE BONUSES ALONE ARE WORTH ACTING NOW! > > THE CABLE DESCRAMBLER KIT COMES WITH A THIRTY DAY > > MONEY BACK GUARANTEE! IF YOUR NOT COMPLETELY SATISFIED, > > SEND THE CABLE DESCRAMBLER KIT BACK AND YOU KEEP > > THE BONUSES FOR FREE. YOU HAVE NOTHING TO LOSE > > ONLY FREE CABLE TV TO GAIN! ACT NOW! SIMPLY SEND > > $14.00 CHECK OR, MONEY ORDER. > > INFORMATION TO: > > > > NET SERVICES > > PO BOX 42013 > > URBANDALE, IA 50322 > > > > > > > > THIS INFORMATION IS SOLD FOR EDUCATIONAL PURPOSES ONLY! > > This mailing is done by an independent marketing co. > > We apologize if this message has reached you in error. > > Save the Planet, Save the Trees! Advertise > > via E mail. No wasted paper! Delete with > > one simple keystroke! Less refuse in our Dumps! > > This is the new way of new millenium! > > If you would like to be removed move233@dcemail.com > > > From owner-wrec@cs.utk.edu Sun Oct 8 16:01:46 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11075 for ; Sun, 8 Oct 2000 16:01:41 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA16140; Sun, 8 Oct 2000 15:56:55 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 8 Oct 2000 15:55:04 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA15984; Sun, 8 Oct 2000 15:55:04 -0400 (EDT) Received: from mnot.sanmateo.akamai.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA15970; Sun, 8 Oct 2000 15:54:54 -0400 (EDT) Received: from mnot.sanmateo.akamai.com (63.102.156.130 -> fw-west.west.akamai.com) by cs.utk.edu (smtpshim v1.0); Sun, 8 Oct 2000 15:54:54 -0400 Received: by mnot.sanmateo.akamai.com (Postfix, from userid 20351) id 29958503B; Sun, 8 Oct 2000 12:54:43 -0700 (PDT) Date: Sun, 8 Oct 2000 12:54:43 -0700 From: Mark Nottingham To: WREC Working Group , ietf@ietf.org Subject: Rechartering WREC Message-ID: <20001008125442.C9255@akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i List-Unsubscribe: Recently, there's been a lot of discussion in various places about the status of WREC, particularly since there are a few other proposals for new working groups (currently at the BoF request stage) that need to define a relationship, or lack thereof, to WREC before they can move forward. WREC has a somewhat difficult past, and is currently somewhat dormant. This may lead people to believe that the sensible thing to do is to close the group down and split any work items off to the new groups; I'd like to dispute this, and open more public discussion about the future of WREC. The group's past has been difficult because it had some work items (the taxonomy, and the known problems document) that had to be completed before "real" work could be started. Additionally, the interception proxy issues and misconceptions have plagued the group for some time; it's only recently that a clear consensus about them seems to be forming. However, these work items are nearly finished, and interception proxies are an issue that can be resolved (either within the group, or in another non-Application group). The main reason for domancy of the group is the fact that there have been no further milestones identified for it, so that we're stuck at re-chartering. I'd argue that now is an excellent time for WREC to become an active and useful working group; there are many potential work items for it, including: * content peering * enhanced coherence mechanisms (invalidation) * log summary formats * surrogate role clarification * semantic transparency issues in intermediates * coordination with content negotiation, other groups which affect intermediates * proxy discovery (very important, in light of interception proxies) More to the point, there's a real need in the IETF for a group that can address the Web infrastructure as a whole. Highly focused groups, while usually productive, can miss out on the bigger picture. To this point, I'd propose that WREC re-charter as soon as possible, with the above work items as well as others that come to light. In particular; * I'd like there to be open discussion with the Content Alliance participants on the best forum for content peering. I very much appreciate the fact that they've opened their mailing list and documents for public view; this is a good first step. At first glance, it seems confusing that they are proposing a separate working group, as content peering is squarely within the charter of WREC. While I can understand that this avoids some problems for them, I think it would be interesting to explore how their work and resources can be integrated into WREC. * A relationship should be established with the EPSFW effort, if it evolves into a WG (as it appears it may). EPSFW doesn't seem to have as much overlap with WREC, except in that it affects proxies and involves semantic transparency issues. These need to be coordinated. WREC has been languishing for a while, for a number of reasons. This doesn't mean that there isn't a role for it, and that it can't address new issues. Instead of killing it and wasteing a lot of effort, let's address those reasons and move forward. -- Mark Nottingham, Research Scientist Akamai Technologies (San Mateo, CA) From owner-wrec@cs.utk.edu Sun Oct 8 18:10:42 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11668 for ; Sun, 8 Oct 2000 18:10:41 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id SAA26518; Sun, 8 Oct 2000 18:06:09 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 8 Oct 2000 18:04:43 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id SAA26396; Sun, 8 Oct 2000 18:04:42 -0400 (EDT) Received: from kiwi.equinix.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id SAA26380; Sun, 8 Oct 2000 18:04:36 -0400 (EDT) Received: from kiwi.equinix.com (207.20.85.65 -> kiwi.equinix.com) by cs.utk.edu (smtpshim v1.0); Sun, 8 Oct 2000 18:04:37 -0400 Received: from icooper.equinix.com (tunnel2-3.corp.equinix.com [172.16.252.3]) by kiwi.equinix.com (8.9.3/8.9.3) with ESMTP id PAA03186; Sun, 8 Oct 2000 15:04:25 -0700 (PDT) Message-Id: <5.0.0.25.2.20001008221413.00a6ba30@nemo.corp.equinix.com> X-Sender: icooper@nemo.corp.equinix.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sun, 08 Oct 2000 23:04:23 +0100 To: Mark Nottingham , WREC Working Group , ietf@ietf.org From: Ian Cooper Subject: Re: Rechartering WREC In-Reply-To: <20001008125442.C9255@akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: Mark, many thanks for your comments; I've had very similar thoughts and concerns myself. At 12:54 10/8/00 -0700, Mark Nottingham wrote: >Recently, there's been a lot of discussion in various places about the >status of WREC, particularly since there are a few other proposals for new >working groups (currently at the BoF request stage) that need to define a >relationship, or lack thereof, to WREC before they can move forward. I've received requests for clarification on WREC's plans by some of the folks involved in those other groups. I'm very aware that they would like some kind of decision on our position as soon as possible in order that the ADs can make decisions as to whether the BoF requests should be accepted. (WREC folks, that means we want your input!) >WREC has a somewhat difficult past, and is currently somewhat dormant. This >may lead people to believe that the sensible thing to do is to close the >group down and split any work items off to the new groups; I'd like to >dispute this, and open more public discussion about the future of WREC. > >The group's past has been difficult because it had some work items (the >taxonomy, and the known problems document) that had to be completed before >"real" work could be started. Additionally, the interception proxy issues >and misconceptions have plagued the group for some time; it's only recently >that a clear consensus about them seems to be forming. > >However, these work items are nearly finished, To further clarify, the taxonomy has been approved and is currently in the rfc-editor queue. > and interception proxies are >an issue that can be resolved (either within the group, or in another >non-Application group). The main reason for domancy of the group is the fact >that there have been no further milestones identified for it, so that we're >stuck at re-chartering. > >I'd argue that now is an excellent time for WREC to become an active and >useful working group; there are many potential work items for it, including: > >* content peering >* enhanced coherence mechanisms (invalidation) >* log summary formats >* surrogate role clarification >* semantic transparency issues in intermediates >* coordination with content negotiation, other groups which affect > intermediates >* proxy discovery (very important, in light of interception proxies) That's a useful list. Thanks! >More to the point, there's a real need in the IETF for a group that can >address the Web infrastructure as a whole. Highly focused groups, while >usually productive, can miss out on the bigger picture. > >To this point, I'd propose that WREC re-charter as soon as possible, with the >above work items as well as others that come to light. In particular; > >* I'd like there to be open discussion with the Content Alliance > participants on the best forum for content peering. I very much appreciate > the fact that they've opened their mailing list and documents for public > view; this is a good first step. > > At first glance, it seems confusing that they are proposing a separate > working group, as content peering is squarely within the charter of WREC. > While I can understand that this avoids some problems for them, I think it > would be interesting to explore how their work and resources can be > integrated into WREC. Info on the group at: http://www.content-peering.org/ >* A relationship should be established with the EPSFW effort, if it evolves > into a WG (as it appears it may). EPSFW doesn't seem to have as much > overlap with WREC, except in that it affects proxies and involves semantic > transparency issues. These need to be coordinated. Info on the group at: http://www.extproxy.org/ The EPSFW folks("Extensible Proxies" - have you guys finalized on a name yet? :) ) gave a presentation in Pittsburgh, and the group consensus there was that this wasn't something that WREC should take on (that said I don't recall any followup discussion on the mailing list, so we shouldn't assume anything.) To my knowledge the Content Alliance/Peering work hasn't had any such review to date, and I think that it's vital we have some discussion before any decision is made. I agree with Mark that at first glance it seems confusing that there's a proposal for a separate group and would find it useful - purely from a WREC management perspective - on why that proposal was made. From owner-wrec@cs.utk.edu Mon Oct 9 09:39:55 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03929 for ; Mon, 9 Oct 2000 09:39:54 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA00126; Mon, 9 Oct 2000 09:35:39 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 9 Oct 2000 09:34:17 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id JAA00020; Mon, 9 Oct 2000 09:34:16 -0400 (EDT) Received: from frampton.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id JAA00004; Mon, 9 Oct 2000 09:34:12 -0400 (EDT) Received: from frampton.cisco.com (161.44.253.15 -> frampton.cisco.com) by cs.utk.edu (smtpshim v1.0); Mon, 9 Oct 2000 09:34:12 -0400 Received: from spamsicle.cisco.com (mirapoint@spamsicle.cisco.com [161.44.253.17]) by frampton.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA09380; Mon, 9 Oct 2000 09:33:36 -0400 (EDT) Received: from markdaypc (wal-baikal.cisco.com [10.89.5.124]) by spamsicle.cisco.com (Mirapoint) with SMTP id AAQ17003; Mon, 9 Oct 2000 09:33:31 -0400 (EDT) From: "Mark Day" To: "Ian Cooper" , "Mark Nottingham" , "WREC Working Group" , Subject: RE: Rechartering WREC Date: Mon, 9 Oct 2000 09:56:30 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <5.0.0.25.2.20001008221413.00a6ba30@nemo.corp.equinix.com> List-Unsubscribe: Content-Transfer-Encoding: 7bit > To my knowledge the Content Alliance/Peering work hasn't had any such > review to date, and I think that it's vital we have some > discussion before > any decision is made. I agree with Mark [Nottingham] that at first glance it seems > confusing that there's a proposal for a separate group and would find it > useful - purely from a WREC management perspective - on why that proposal > was made. I think we have been consistently agnostic on the issue of where CDN peering belongs, as long as the work gets done by a group that is focused on doing it. Our initial BOF request was to the IESG as a whole, largely because there was some doubt as to whether CDN peering was more sensibly handled as part of Applications, Operations, Routing, or Internet. On the smaller question of relationship with WREC specifically, again I don't think that there is much of an "Alliance position." Personally, I think it would be fine for the IESG to put the CDN peering work into WREC, subject to two constraints: 1) I wouldn't want for the CDN peering work to be a small fraction of a larger agenda; WREC's rechartering, if it happens in this way, should be squarely focused on CDN peering as its primary deliverable. 2) I would want to give the IETF community as a whole a chance for a thumbs-up/thumbs-down on the work, as a BOF does, rather than somehow sneaking CDN peering into an existing WG. I agree that the WREC charter arguably encompasses CDN peering already, but I doubt that the IETF had that specifically in mind at the point when WREC was initially chartered. So I would argue for treating the rechartering as a BOF-like event. Both of these have more to do with establishing the conditions for success in a CDN peering effort than they have to do with the history of WREC. I understand that WREC has had some travails in the past, but I don't have any opinion about whether those have impaired its ability to be successful in the future. I have heard multiple people express concern about WREC's ability to be a productive forum, but I am not in a position to judge; I believe the ADs will have a better perspective on that than I have. --Mark (current chair, Content Peering working group of the Content Alliance) Mark Stuart Day Senior Scientist Cisco Systems +1 (781) 663-8310 markday@cisco.com From owner-wrec@cs.utk.edu Mon Oct 9 12:46:31 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06661 for ; Mon, 9 Oct 2000 12:46:30 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA28508; Mon, 9 Oct 2000 12:40:05 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 9 Oct 2000 12:38:39 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA28321; Mon, 9 Oct 2000 12:38:38 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA28308; Mon, 9 Oct 2000 12:38:36 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (171.69.43.88 -> sj-msg-core-2.cisco.com) by cs.utk.edu (smtpshim v1.0); Mon, 9 Oct 2000 12:38:36 -0400 Received: from wooly-booly.cisco.com (wooly-booly.cisco.com [171.69.167.33]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA29862; Mon, 9 Oct 2000 09:35:42 -0700 (PDT) Received: from bgreenent2 (bgreene-dsl3.cisco.com [144.254.193.60]) by wooly-booly.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with SMTP id LAA21844; Mon, 9 Oct 2000 11:35:38 -0500 (CDT) From: "Barry Raveendran Greene" To: "Mark Nottingham" , "WREC Working Group" , Subject: RE: Rechartering WREC Date: Mon, 9 Oct 2000 09:27:37 -0700 Message-ID: <005d01c0320d$d66104e0$4f01a8c0@bgreenent2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <20001008125442.C9255@akamai.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: Normal List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Mark, I understand the points you are raising. First off, I support the idea of doing this sort of work in the IETF vs competitive commercial interest groups. It is in the Internet's best interest to have all the "competitive parties" come together in the IETF to work on architecture and protocols that will further the Internet's success. Right now that is not happening. Second, there is a lot of history behind the WREC that we do not need to rehash (i.e. the end-to-end dogma battles). It is for this reason that I would like to see WREC finish it's work and close down. But that is my opinion - hence a rechartering discussion should be scheduled at the next WREC meeting. Lastly, stacking all the various pieces of work into one WG would be too cumbersome - bogging down the WG. IMHO - it would be better to break the work apart into several WGs. If you look at the history of successful WGs, the most successful WGs (i.e. things that reach draft standard status) have been single protocol - single issue WGs. So if the Caching/Replication/CDN/Content/ISP/Co-Location community would like to see things reach draft standard stage, it would be in the community's best interest to think about narrowly focused WGs working on specific protocols/problems. If necessary, a WG just to address the architecture could be chartered to keep all the pieces of work coordinated. Yes, there would be push back about "too many WGs," But the community has had to do this in the past and it can do it again. So .... I think there should be a "CDN" BOF at the next IETF that will have several people walk down the list of work that think could be addressed in IETF WGs. And, WREC should meet - work on closure on the existing work - and have a discussion on rechartering. At that point, people should start proposing WGs to the Applications Area Directors. Barry > -----Original Message----- > From: Mark Nottingham [mailto:mnot@akamai.com] > Sent: Sunday, October 08, 2000 12:55 PM > To: WREC Working Group; ietf@ietf.org > Subject: Rechartering WREC > > > > Recently, there's been a lot of discussion in various places about the > status of WREC, particularly since there are a few other proposals for new > working groups (currently at the BoF request stage) that need to define a > relationship, or lack thereof, to WREC before they can move forward. > > WREC has a somewhat difficult past, and is currently somewhat > dormant. This > may lead people to believe that the sensible thing to do is to close the > group down and split any work items off to the new groups; I'd like to > dispute this, and open more public discussion about the future of WREC. > > The group's past has been difficult because it had some work items (the > taxonomy, and the known problems document) that had to be completed before > "real" work could be started. Additionally, the interception proxy issues > and misconceptions have plagued the group for some time; it's > only recently > that a clear consensus about them seems to be forming. > > However, these work items are nearly finished, and interception > proxies are > an issue that can be resolved (either within the group, or in another > non-Application group). The main reason for domancy of the group > is the fact > that there have been no further milestones identified for it, so > that we're > stuck at re-chartering. > > I'd argue that now is an excellent time for WREC to become an active and > useful working group; there are many potential work items for it, > including: > > * content peering > * enhanced coherence mechanisms (invalidation) > * log summary formats > * surrogate role clarification > * semantic transparency issues in intermediates > * coordination with content negotiation, other groups which affect > intermediates > * proxy discovery (very important, in light of interception proxies) > > More to the point, there's a real need in the IETF for a group that can > address the Web infrastructure as a whole. Highly focused groups, while > usually productive, can miss out on the bigger picture. > > To this point, I'd propose that WREC re-charter as soon as > possible, with the > above work items as well as others that come to light. In particular; > > * I'd like there to be open discussion with the Content Alliance > participants on the best forum for content peering. I very much > appreciate > the fact that they've opened their mailing list and documents for public > view; this is a good first step. > > At first glance, it seems confusing that they are proposing a separate > working group, as content peering is squarely within the > charter of WREC. > While I can understand that this avoids some problems for them, > I think it > would be interesting to explore how their work and resources can be > integrated into WREC. > > * A relationship should be established with the EPSFW effort, if > it evolves > into a WG (as it appears it may). EPSFW doesn't seem to have as much > overlap with WREC, except in that it affects proxies and > involves semantic > transparency issues. These need to be coordinated. > > WREC has been languishing for a while, for a number of reasons. > This doesn't > mean that there isn't a role for it, and that it can't address new issues. > Instead of killing it and wasteing a lot of effort, let's address those > reasons and move forward. > > -- > Mark Nottingham, Research Scientist > Akamai Technologies (San Mateo, CA) > From owner-wrec@cs.utk.edu Tue Oct 10 03:09:54 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA29257 for ; Tue, 10 Oct 2000 03:09:54 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id DAA14287; Tue, 10 Oct 2000 03:05:44 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 10 Oct 2000 03:03:51 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id DAA14176; Tue, 10 Oct 2000 03:03:51 -0400 (EDT) Received: from mailman.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id DAA14163; Tue, 10 Oct 2000 03:03:49 -0400 (EDT) Received: from mailman.cisco.com (171.68.225.9 -> mailman.cisco.com) by cs.utk.edu (smtpshim v1.0); Tue, 10 Oct 2000 03:03:49 -0400 Received: from [192.168.1.19] (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id AAA20796; Tue, 10 Oct 2000 00:03:38 -0700 (PDT) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 (Unverified) Message-Id: In-Reply-To: <005d01c0320d$d66104e0$4f01a8c0@bgreenent2.cisco.com> References: <005d01c0320d$d66104e0$4f01a8c0@bgreenent2.cisco.com> Date: Tue, 10 Oct 2000 09:03:27 +0200 To: "Barry Raveendran Greene" , "Mark Nottingham" , "WREC Working Group" , From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: Rechartering WREC Content-Type: text/plain; charset="us-ascii" ; format="flowed" List-Unsubscribe: At 09.27 -0700 00-10-09, Barry Raveendran Greene wrote: >So .... I think there should be a "CDN" BOF at the next IETF that will have >several people walk down the list of work that think could be addressed in >IETF WGs. And, WREC should meet - work on closure on the existing work - and >have a discussion on rechartering. At that point, people should start >proposing WGs to the Applications Area Directors. Not only sending proposed WG charters in the direction of myself an Ned, but more importantly a general plan for content distribution. I would like to see a one-page paper (not much more is needed, or?) which talks about what different components exist in a content network. A list such as (but it should fit together): - Distribution of data from origin server to copies within administrative control of the owner of the data - Distribution of data from origin server to copies outside of - Preloading / load on demand of caches - Cache discovery - Routing of client to closest site with data - Switching of client to good server within site - Billing / charging / statistics collection - HTTP / HTML extensions for cache control - Continuation of work on taxonomy : : : You are the one doing the list, and you then tell what on that list should be handled by each of the proposed wg's. I am definitly not saying that you have to create wg's for everything (I rather see not :-), but what pieces you are going to work on, and what have to wait. And, I want a list which you all in the "wrec" area agree on. Not one explanation from each one of you (which I have got so far :-). I.e. the stories have to fit together. Patrik From owner-wrec@cs.utk.edu Tue Oct 10 07:26:59 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01466 for ; Tue, 10 Oct 2000 07:26:59 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id HAA00220; Tue, 10 Oct 2000 07:23:01 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 10 Oct 2000 07:21:38 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id HAA00136; Tue, 10 Oct 2000 07:21:38 -0400 (EDT) Received: from dokka.maxware.no (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id HAA00113; Tue, 10 Oct 2000 07:21:34 -0400 (EDT) Received: from dokka.maxware.no (195.139.236.69 -> dokka.maxware.no) by cs.utk.edu (smtpshim v1.0); Tue, 10 Oct 2000 07:21:35 -0400 Received: from HALVESTR-8KCDT.maxware.no (isdn-nat-1.cisco.com [192.82.152.130]) by dokka.maxware.no (8.9.3/8.9.3) with ESMTP id NAA03479; Tue, 10 Oct 2000 13:21:23 +0200 Message-Id: <4.3.2.7.2.20001010123244.0572f610@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Oct 2000 12:35:45 +0200 To: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= , "Barry Raveendran Greene" , "Mark Nottingham" , "WREC Working Group" , From: Harald Alvestrand Subject: RE: Rechartering WREC In-Reply-To: References: <005d01c0320d$d66104e0$4f01a8c0@bgreenent2.cisco.com> <005d01c0320d$d66104e0$4f01a8c0@bgreenent2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed List-Unsubscribe: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA01466 At 09:03 10/10/2000 +0200, Patrik Fältström wrote: >A list such as (but it should fit together): > > - Distribution of data from origin server to copies within administrative > control of the owner of the data > - Distribution of data from origin server to copies outside of > - Preloading / load on demand of caches > - Cache discovery > - Routing of client to closest site with data > - Switching of client to good server within site or rather: - routing of client to closest WORKING site with data > - Billing / charging / statistics collection more: - user session state management - TLS interaction - authentication models for multi-sited servers (having all of them configured with the same secret key is not optimal security-wise - loss of one means loss of all) > - HTTP / HTML extensions for cache control > - Continuation of work on taxonomy I know I shouldn't be bringing more tinder to the bonfire, but.... -- Harald Tveit Alvestrand, alvestrand@cisco.com +47 41 44 29 94 Personal email: Harald@Alvestrand.no From owner-wrec@cs.utk.edu Tue Oct 10 08:21:45 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02547 for ; Tue, 10 Oct 2000 08:21:45 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id IAA05707; Tue, 10 Oct 2000 08:17:48 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 10 Oct 2000 08:16:27 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id IAA05613; Tue, 10 Oct 2000 08:16:26 -0400 (EDT) Received: from mailman.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id IAA05595; Tue, 10 Oct 2000 08:16:25 -0400 (EDT) Received: from mailman.cisco.com (171.68.225.9 -> mailman.cisco.com) by cs.utk.edu (smtpshim v1.0); Tue, 10 Oct 2000 08:16:25 -0400 Received: from [192.168.1.19] (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id FAA08605; Tue, 10 Oct 2000 05:15:40 -0700 (PDT) Mime-Version: 1.0 X-Sender: pfaltstr@127.0.0.1 Message-Id: In-Reply-To: <4.3.2.7.2.20001010123244.0572f610@127.0.0.1> References: <005d01c0320d$d66104e0$4f01a8c0@bgreenent2.cisco.com> <005d01c0320d$d66104e0$4f01a8c0@bgreenent2.cisco.com> <4.3.2.7.2.20001010123244.0572f610@127.0.0.1> Date: Tue, 10 Oct 2000 14:01:08 +0200 To: Harald Alvestrand , "Barry Raveendran Greene" , "Mark Nottingham" , "WREC Working Group" , From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: RE: Rechartering WREC Content-Type: text/plain; charset="us-ascii" ; format="flowed" List-Unsubscribe: At 12.35 +0200 00-10-10, Harald Alvestrand wrote: >I know I shouldn't be bringing more tinder to the bonfire, but.... You should, as many other people. I.e. when I get the BOF/wg proposals, I want in parallel a list of things which you belive should be part of a (sort of) complete model of this part of the Internet, and you then say that: - WG xxxx is proposed to work with item 1, 3, 4 and 7 - WG yyyy is proposed to work with item 9 - Other work items are left for future studies I don't claim my list was complete (or by any means complete or correct). You do the list, and you do the charters. Patrik From owner-wrec@cs.utk.edu Tue Oct 10 08:59:58 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03186 for ; Tue, 10 Oct 2000 08:59:57 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id IAA10381; Tue, 10 Oct 2000 08:56:01 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 10 Oct 2000 08:54:39 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id IAA10218; Tue, 10 Oct 2000 08:54:39 -0400 (EDT) Received: from nic-naa.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id IAA10202; Tue, 10 Oct 2000 08:54:27 -0400 (EDT) Received: from nic-naa.net (24.95.12.91 -> dt0b4n5b.maine.rr.com) by cs.utk.edu (smtpshim v1.0); Tue, 10 Oct 2000 08:54:27 -0400 Received: from nic-naa.net (localhost.maine.rr.com [127.0.0.1]) by nic-naa.net (8.11.0/8.9.3) with ESMTP id e9ACoGT10004; Tue, 10 Oct 2000 08:50:42 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-Id: <200010101250.e9ACoGT10004@nic-naa.net> To: mnot@akamai.com cc: Harald@Alvestrand.no, paf@cisco.com, bgreene@cisco.com, wrec@cs.utk.edu, ietf@ietf.org Subject: Re: Rechartering WREC In-Reply-To: Your message of "Tue, 10 Oct 2000 14:01:08 +0200." Date: Tue, 10 Oct 2000 08:50:16 -0400 From: Eric Brunner-Williams List-Unsubscribe: Harald (the match peddler) wrote: > I know I shouldn't be bringing more tinder to the bonfire, but.... Cache interposition semantics on end-to-end policy evaluation and expiry semantics is my cup of gasoline. The policy-de-jour is P3P, to which Mark and I both ... contribute ... or er, illuminate. I second the user session state management item, and offer a cookie in lieu of a second cup of gasoline. Eric From owner-wrec@cs.utk.edu Tue Oct 10 15:57:14 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12193 for ; Tue, 10 Oct 2000 15:57:14 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA27072; Tue, 10 Oct 2000 15:51:16 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 10 Oct 2000 15:49:47 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA26768; Tue, 10 Oct 2000 15:49:46 -0400 (EDT) Received: from kiwi.equinix.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA26749; Tue, 10 Oct 2000 15:49:34 -0400 (EDT) Received: from kiwi.equinix.com (207.20.85.65 -> kiwi.equinix.com) by cs.utk.edu (smtpshim v1.0); Tue, 10 Oct 2000 15:49:35 -0400 Received: from icooper.equinix.com (tunnel2-11.corp.equinix.com [172.16.252.11]) by kiwi.equinix.com (8.9.3/8.9.3) with ESMTP id MAA23716 for ; Tue, 10 Oct 2000 12:49:31 -0700 (PDT) Message-Id: <5.0.0.25.2.20001010194121.00a501a0@nemo.corp.equinix.com> X-Sender: icooper@nemo.corp.equinix.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 10 Oct 2000 20:49:28 +0100 To: wrec@cs.utk.edu From: Ian Cooper Subject: WREC/CDNP/extproxy ... moving forward Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: In order to try and move in some kind of positive direction I've compiled the following list of possible things to work on, as identified in emails and in the WREC known problems document. Apologies if it's a bit rough around the edges, but the idea is to try and get some discussion going among us. Having spoken to a few folks, Mark Nottingham and I are coming around to the idea that splitting some of the CDNP work into a separate group (as proposed) is probably a good thing. However, we still think there are some things that WREC should be working on (the items identified for WREC below are those Mark and I believe we can make progress on and which need to be delivered in a reasonable timeframe). I've tried to identify some of the issues I think CDNP might be interested in looking at, though I'm probably ignoring some other obvious things. (This is really an attempt to ask "can you take these on?" while also working from Patrik's small list.) There are also some other issues that are interesting and which a group may wish to visit down the road, or else a group might possibly form to address them. If there are other bullets that folks think need adding, please do so. Similarly, if you think I've got something in the wrong place please feel free to edit. WREC ==== * Proxy/surrogate discovery protocol for user agents - initial intent is probably for "user agents" to mean browsers; - should also consider some aspects of wider proxy/surrogate discovery or registration that will probably be interesting to CDNP and extproxy (e.g. proxies/surrogates being able to discover other proxies or surrogates) - obviously of interest to the folks doing the extensible proxy work * Cache coherence/invalidation protocol - including delta encoding and preloading within the administrative control of the data owner - will probably touch on expiry semantics in passing - will be of interest to the CDNP folks too (Yes, that's it for now.) I'm not going to suggest milestones at this point, but we feel that aiming to have these completed within a 12-14 month window shouldn't be too unreasonable. (And we definitely want to try and keep things focused and achievable.) CDNP ==== * Distribution of data from origin servers outside of the administrative control of the data owner (I'd specifically exclude the scenario where the distribution occurs within a single administrative domain... do we really need to standardize that?) * Routing request to closest site (service) with the requested data - should probably consider caching proxies in the model - (obviously has some aspects of competitive advantage as was discussed from the WREC KP draft in Pittsburgh) - definition of the "closest" site (see WREC KP draft on known failings of ICP in heterogeneous network) - may overlap with, or provide us with, (or show us that it's unnecessary to have) some replacement for ICP in the caching world Billing (and more) ================== There seems to be a case for billing/accounting to be covered in all three of WREC, CDNP and extensible proxies. I believe that the extproxy folks have commented that this may be appropriate work for another group (AAA?), and it definitely seems that it's beyond any one of those being discussed here. If we therefore open the scope to the wider issue of authentication and authorization I guess we can add * Exchange format for log summaries (essentially some form of accounting records; this is the problem identified in the WREC known problems document) * User session management * Authentication models for multi-sited services/TLS interaction (A pet peeve of mine is that there's an awfully large amount of non-private information that has to get sent via https and could be cached. Can that issue be addressed, or is it simply a browser implementation issue?) Remainder ========= The remaining items I have on the list are: * Outstanding HTTP header issues - "Vary header underspecified" - registration of new HTTP headers * Various end-to-end issues and concerns (includes content negotiation) most likely something that needs to be considered for a world where surrogates and extproxies live in the network; a few folks are interested in this; may be a very short lived WG in its own right * Some kind of documentation to cover those recurring items on "how to make servers and content cache friendly" not really an IETF WG matter; individual submission/W3C or elsewhere * Re-visit the taxonomy something that WREC and/or CDNP will need to revisit in the future... perhaps the WREC and CDNP terminology sections need rolling into one? - definition of a surrogate ;-) From owner-wrec@cs.utk.edu Tue Oct 10 20:02:50 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15833 for ; Tue, 10 Oct 2000 20:02:45 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id TAA24088; Tue, 10 Oct 2000 19:58:10 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 10 Oct 2000 19:56:21 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id TAA23950; Tue, 10 Oct 2000 19:56:21 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id TAA23934; Tue, 10 Oct 2000 19:56:20 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Tue, 10 Oct 2000 19:56:20 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id TAA10510; Tue, 10 Oct 2000 19:56:07 -0400 (EDT) Message-Id: <200010102356.TAA10510@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Ian Cooper cc: wrec@cs.utk.edu Subject: Re: WREC/CDNP/extproxy ... moving forward In-reply-to: Your message of "Tue, 10 Oct 2000 20:49:28 BST." <5.0.0.25.2.20001010194121.00a501a0@nemo.corp.equinix.com> Date: Tue, 10 Oct 2000 19:56:07 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: > > CDNP > ==== > * Distribution of data from origin servers outside of the administrative > control of the data owner assuming I understand what you mean by the above, I don't think IETF should be endorsing such practices at all. I see two pieces: 1. how the content provider makes data available to consumers, and how it makes the locations of those data known to consumers 2. how consumers find and access such data the first is under control of the content-provider; the second is under control over the consumer. I see no legitimate role for a third party that isn't acting under explicit instructions from one or the other of the first two parties. IMHO, *this* is what IETF should standardize. > (I'd specifically exclude the scenario where the distribution occurs within > a single administrative domain... do we really need to standardize that?) yes, because there is a need to have standardized interfaces between content providers and content-distribution networks acting on behalf of the content providers. there is also a need for a standardized and efficient interface between content users and content distribution networks - the stuff we are using now is quite crude. > * Routing request to closest site (service) with the requested data > - should probably consider caching proxies in the model > - (obviously has some aspects of competitive advantage as was discussed > from the WREC KP draft in Pittsburgh) > - definition of the "closest" site (see WREC KP draft on known failings > of ICP in heterogeneous network) not sure how to define it better but "closest" (or any superlative) may be over-ambitious Keith From owner-wrec@cs.utk.edu Tue Oct 10 22:35:30 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18814 for ; Tue, 10 Oct 2000 22:35:30 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id WAA08723; Tue, 10 Oct 2000 22:31:31 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 10 Oct 2000 22:30:05 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id WAA08553; Tue, 10 Oct 2000 22:30:03 -0400 (EDT) Received: from frampton.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id WAA08520; Tue, 10 Oct 2000 22:29:55 -0400 (EDT) Received: from frampton.cisco.com (161.44.253.15 -> frampton.cisco.com) by cs.utk.edu (smtpshim v1.0); Tue, 10 Oct 2000 22:30:00 -0400 Received: from spamsicle.cisco.com (mirapoint@spamsicle.cisco.com [161.44.253.17]) by frampton.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id WAA16664; Tue, 10 Oct 2000 22:29:45 -0400 (EDT) Received: from markdaypc (wal-baikal.cisco.com [10.89.5.124]) by spamsicle.cisco.com (Mirapoint) with SMTP id AAQ21015; Tue, 10 Oct 2000 22:29:38 -0400 (EDT) From: "Mark Day" To: , "Ian Cooper" Cc: Subject: RE: WREC/CDNP/extproxy ... moving forward Date: Tue, 10 Oct 2000 22:52:45 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <200010102356.TAA10510@astro.cs.utk.edu> List-Unsubscribe: Content-Transfer-Encoding: 7bit > > CDNP > > ==== > > * Distribution of data from origin servers outside of the > administrative > > control of the data owner > > assuming I understand what you mean by the above, I don't think IETF > should be endorsing such practices at all. I see two pieces: > > 1. how the content provider makes data available to consumers, and > how it makes the locations of those data known to consumers > > 2. how consumers find and access such data > > the first is under control of the content-provider; the second > is under control over the consumer. > > I see no legitimate role for a third party that isn't acting under > explicit instructions from one or the other of the first two > parties. IMHO, *this* is what IETF should standardize. The data owner (the content provider) is often not the owner of the distribution network/system. That's all that I think Ian means by "outside of the administrative control of the data owner." Our discussions about CDN peering have pushed this separation between content and distribution one step further, to the idea of distributing content onto networks not directly contracting with the data owner, but (say) acting as subcontractors, or in other similar arrangements. I don't know if such arrangements would strike you as "explicit instructions" from the content provider (indeed, part of the value is in hiding the seams of such distribution-provider cooperation from the content provider). But I have trouble identifying the illegitimate part of such arrangements. I don't mean to be argumentative (yet ;-)), so if you do mean to say that such subcontracting of content distribution is evil, then please help me out by elaborating a little on why. I think that your two-piece division (how content is advertised; how content is found) is fine as far as it goes. I'd claim that CDN peering deals with refining each of those two parts to fill in the details of how they should work in the presence of multiple administratively-distinct networks that nevertheless choose to cooperate. Feel free to explain to me that I'm missing your point. I have a sense that you're vigorously attacking as illegitimate something that I see as a technically challenging but ethically sound goal, so I suspect there's some sort of misunderstanding here. --Mark Mark Stuart Day Senior Scientist Cisco Systems +1 (781) 663-8310 markday@cisco.com From owner-wrec@cs.utk.edu Tue Oct 10 22:57:40 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA19153 for ; Tue, 10 Oct 2000 22:57:39 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id WAA12730; Tue, 10 Oct 2000 22:53:45 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 10 Oct 2000 22:52:24 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id WAA12489; Tue, 10 Oct 2000 22:52:23 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id WAA12469; Tue, 10 Oct 2000 22:52:21 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Tue, 10 Oct 2000 22:52:21 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id WAA12117; Tue, 10 Oct 2000 22:52:11 -0400 (EDT) Message-Id: <200010110252.WAA12117@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Mark Day" cc: moore@cs.utk.edu, "Ian Cooper" , wrec@cs.utk.edu Subject: Re: WREC/CDNP/extproxy ... moving forward In-reply-to: Your message of "Tue, 10 Oct 2000 22:52:45 EDT." Date: Tue, 10 Oct 2000 22:52:11 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: I don't see much in your message with which I would disagree. > The data owner (the content provider) is often not the owner of the > distribution network/system. right, and I see nothing wrong with that so long as the distribution network is distributing the material with the consent of the content provider, and according to whatever instructions to which they might mutually agree. part of the point (which I'm struggling to articulate even to myself) is that the system as a whole needs to behave predictably and there needs to be a clear division of responsibility between the various parties that handle the data. otherwise, when something goes wrong, (say, incorrect, altered, or stale data is delivered to the consumer) there will be no clear direction as to which pieces are at fault and who is responsible for fixing it. (yes, I realize that such problems often occur even in well-designed systems, but we should try to minimize them) Keith p.s. note that the content provider is not necessarily the owner of the data in a legal sense, though in general one hopes that the content provider has permission to distribute the data. still, there's a subtle difference between roles that should be specified by the protocol architecture and those that are specified by laws - the protocol architecture should be concerned with reliable and predictable operation (and hence, for instance, that the replicas of data that are obtained by querying the content provider are actually those intended by the content provider) but the protocol should not concern itself with whether a content provider has the legal right to make that content available. From owner-wrec@cs.utk.edu Wed Oct 11 03:28:20 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04163 for ; Wed, 11 Oct 2000 03:28:19 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id DAA29636; Wed, 11 Oct 2000 03:23:55 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 11 Oct 2000 03:22:21 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id DAA29566; Wed, 11 Oct 2000 03:22:21 -0400 (EDT) Received: from p-mail2.cnet.fr (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id DAA29553; Wed, 11 Oct 2000 03:22:18 -0400 (EDT) Received: from p-mail2.cnet.fr (193.49.124.32 -> p-mail2.rd.francetelecom.fr) by cs.utk.edu (smtpshim v1.0); Wed, 11 Oct 2000 03:22:19 -0400 Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id <4JWLYTLB>; Wed, 11 Oct 2000 09:20:27 +0200 Message-ID: <91A311FF6A85D3118DDF0060080C3D8291A096@lat3721.lannion.cnet.fr> From: LOVRIC Ivan FTRD/DMI/CAE To: "'Jeremy Elson'" , comments@i-cap.org, wrec@cs.utk.edu Subject: RE: ICAP suggested changes/ call for comments Date: Wed, 11 Oct 2000 09:19:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" List-Unsubscribe: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA04163 Hi, As implementors of the iCAP protocol, we also noticed several ways to improve it. 1) Some kind of a negotiation between the ICAP client and the ICAP server should occur during activation of the system. The purpose here is to take the server capabilities into account, for example if the iCAP server modifies only text files, there is no use to transmit image files to that server. 2)The current specification doesn't deal with any error or status messages. This leads to misunderstandings between implementors about the way to process iCAP requests and responses according to status codes. If we want to have compliant implementations whatever the clients and servers are, the issue of status codes should also be solved within the specification. Regards, ___________________ Ivan Lovric E-mail: ivan.lovric@cnet.francetelecom.fr tel. office: (+33) 2 31 75 91 25 tel. home:(+33) 2 31 97 38 70 France Telecom R&D 42, rue des Coutures - BP 6243 - 14066 Caen Cédex 4 - France -----Message d'origine----- De: Jeremy Elson [mailto:jelson@isi.edu] Date: mercredi 4 octobre 2000 11:15 À: comments@i-cap.org; wrec@cs.utk.edu Cc: jelson@isi.edu Objet: ICAP suggested changes/ call for comments Hi, Some of the early implementors of the new ICAP protocol have been meeting over the past couple of weeks to discuss how the protocol is broken based on recent implementation experience. Based on these discussions we would like to change the protocol in certain ways that we think will make it better but will break interoperability with existing implementations (hey, it was just a draft, right? :-) ) The purpose of this message is to ask any other implementors of ICAP to please join us in our current discussions. In particular, if you have any proposed changes that you think would make the protocol better but would break interoperability, this is a good time to speak up since we're breaking it anyway (and only want to break it once). Please let me know if you'd like to be included in our teleconferences that are Thursday mornings at 9AM Pacific time. The current (proposed) changes that break interoperability are: 1- Chunked encoding will be required, instead of optional (this only affects clients since servers need to understand chunking anyway) 2- Encapsulation Forwarded HTTP requests and responses will be changing. Both forwarded bodies *and* forwarded headers will be contained completely in the body of ICAP message instead of encapsulating the (inner) forwarded headers in the (outer) headers of the ICAP message. 3- We want to make the simplifying assumption that the ICAP server is in the same admin domain as ICAP client. Parts of the protocol had already made this assumption (e.g. for configuration and authentication purposes) but it would make things easier if this was assumed throughout. Also, at the suggestion of some within IETF we will most likely define ICAP to use a port other than 80. (No one on our side of the fence feels strongly at all about this issue; we're just doing what we're told :-)) If you have feedback please let us know at pwg@catarina.usc.edu, or join our teleconf on Thursdays. Regards, Jeremy From owner-wrec@cs.utk.edu Wed Oct 11 03:41:29 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04285 for ; Wed, 11 Oct 2000 03:41:29 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id DAA00862; Wed, 11 Oct 2000 03:37:37 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 11 Oct 2000 03:36:15 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id DAA00821; Wed, 11 Oct 2000 03:36:14 -0400 (EDT) Received: from p-mail1.cnet.fr (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id DAA00804; Wed, 11 Oct 2000 03:36:11 -0400 (EDT) Received: from p-mail1.cnet.fr (193.49.124.31 -> p-mail1.rd.francetelecom.fr) by cs.utk.edu (smtpshim v1.0); Wed, 11 Oct 2000 03:36:12 -0400 Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id <4JQS53PG>; Wed, 11 Oct 2000 09:35:56 +0200 Message-ID: <91A311FF6A85D3118DDF0060080C3D8291A099@lat3721.lannion.cnet.fr> From: LOVRIC Ivan FTRD/DMI/CAE To: "'Keith Moore'" , "'wrec@cs.utk.edu'" Subject: RE: WREC/CDNP/extproxy ... moving forward Date: Wed, 11 Oct 2000 09:34:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" List-Unsubscribe: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA04285 I guess a third party within the network should be useful for everybody, for instance, to filter viruses. The issue is to define what role is acceptable and legitimate for that party. Regards, -----Message d'origine----- De: Keith Moore [mailto:moore@cs.utk.edu] Date: mercredi 11 octobre 2000 01:56 À: Ian Cooper Cc: wrec@cs.utk.edu Objet: Re: WREC/CDNP/extproxy ... moving forward > > CDNP > ==== > * Distribution of data from origin servers outside of the administrative > control of the data owner assuming I understand what you mean by the above, I don't think IETF should be endorsing such practices at all. I see two pieces: 1. how the content provider makes data available to consumers, and how it makes the locations of those data known to consumers 2. how consumers find and access such data the first is under control of the content-provider; the second is under control over the consumer. I see no legitimate role for a third party that isn't acting under explicit instructions from one or the other of the first two parties. IMHO, *this* is what IETF should standardize. > (I'd specifically exclude the scenario where the distribution occurs within > a single administrative domain... do we really need to standardize that?) yes, because there is a need to have standardized interfaces between content providers and content-distribution networks acting on behalf of the content providers. there is also a need for a standardized and efficient interface between content users and content distribution networks - the stuff we are using now is quite crude. > * Routing request to closest site (service) with the requested data > - should probably consider caching proxies in the model > - (obviously has some aspects of competitive advantage as was discussed > from the WREC KP draft in Pittsburgh) > - definition of the "closest" site (see WREC KP draft on known failings > of ICP in heterogeneous network) not sure how to define it better but "closest" (or any superlative) may be over-ambitious Keith From owner-wrec@cs.utk.edu Wed Oct 11 09:30:12 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10246 for ; Wed, 11 Oct 2000 09:30:11 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA27818; Wed, 11 Oct 2000 09:26:08 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 11 Oct 2000 09:24:45 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id JAA27657; Wed, 11 Oct 2000 09:24:45 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id JAA27635; Wed, 11 Oct 2000 09:24:43 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Wed, 11 Oct 2000 09:24:43 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id JAA09122; Wed, 11 Oct 2000 09:24:38 -0400 (EDT) Message-Id: <200010111324.JAA09122@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: LOVRIC Ivan FTRD/DMI/CAE cc: "'Keith Moore'" , "'wrec@cs.utk.edu'" Subject: Re: WREC/CDNP/extproxy ... moving forward In-reply-to: Your message of "Wed, 11 Oct 2000 09:34:31 +0200." <91A311FF6A85D3118DDF0060080C3D8291A099@lat3721.lannion.cnet.fr> Date: Wed, 11 Oct 2000 09:24:38 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: > I guess a third party within the network should be useful for everybody, for > instance, to filter viruses. > > The issue is to define what role is acceptable and legitimate for that > party. imho, no amount of filtering is acceptable or legitimate for a third party, unless such filtering is both authorized by, and under the control of, either the provider or the consumer. this gets back to predictable operation. what if the consumer has a legitimate need to access something that just happens to look to the virus filter like it contains a virus? what if the filter doesn't just check for viruses, but also things that look (to it) like porn? Keith From owner-wrec@cs.utk.edu Wed Oct 11 10:40:26 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11988 for ; Wed, 11 Oct 2000 10:40:26 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id KAA06177; Wed, 11 Oct 2000 10:36:33 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 11 Oct 2000 10:35:10 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id KAA05974; Wed, 11 Oct 2000 10:35:09 -0400 (EDT) Received: from kiwi.equinix.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id KAA05918; Wed, 11 Oct 2000 10:35:06 -0400 (EDT) Received: from kiwi.equinix.com (207.20.85.65 -> kiwi.equinix.com) by cs.utk.edu (smtpshim v1.0); Wed, 11 Oct 2000 10:35:07 -0400 Received: from icooper.equinix.com (tunnel2-7.corp.equinix.com [172.16.252.7]) by kiwi.equinix.com (8.9.3/8.9.3) with ESMTP id HAA25978; Wed, 11 Oct 2000 07:35:02 -0700 (PDT) Message-Id: <5.0.0.25.2.20001011152331.00a76880@nemo.corp.equinix.com> X-Sender: icooper@nemo.corp.equinix.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 11 Oct 2000 15:32:18 +0100 To: Keith Moore , LOVRIC Ivan FTRD/DMI/CAE From: Ian Cooper Subject: Re: WREC/CDNP/extproxy ... moving forward Cc: wrec@cs.utk.edu In-Reply-To: <200010111324.JAA09122@astro.cs.utk.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: At 09:24 10/11/00 -0400, Keith Moore wrote: > > I guess a third party within the network should be useful for > everybody, for > > instance, to filter viruses. > > > > The issue is to define what role is acceptable and legitimate for that > > party. > >imho, no amount of filtering is acceptable or legitimate for a third party, >unless such filtering is both authorized by, and under the control of, >either the provider or the consumer. Define consumer :) I seem to recall you having made some comments about this elsewhere... > this gets back to predictable operation. Right. >what if the consumer has a legitimate need to access something that just >happens to look to the virus filter like it contains a virus? >what if the filter doesn't just check for viruses, but also things that >look (to it) like porn? Those examples are problematic as they demonstrate situations where there could be a valid reason for having filters on the network border. In those cases you can argue that the consumer isn't the user sat in front of her browser, but the guy that decides who can use the network and what they can use it for. From owner-wrec@cs.utk.edu Wed Oct 11 10:40:39 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11999 for ; Wed, 11 Oct 2000 10:40:34 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id KAA06173; Wed, 11 Oct 2000 10:36:33 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 11 Oct 2000 10:35:10 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id KAA05951; Wed, 11 Oct 2000 10:35:08 -0400 (EDT) Received: from kiwi.equinix.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id KAA05902; Wed, 11 Oct 2000 10:35:03 -0400 (EDT) Received: from kiwi.equinix.com (207.20.85.65 -> kiwi.equinix.com) by cs.utk.edu (smtpshim v1.0); Wed, 11 Oct 2000 10:35:04 -0400 Received: from icooper.equinix.com (tunnel2-7.corp.equinix.com [172.16.252.7]) by kiwi.equinix.com (8.9.3/8.9.3) with ESMTP id HAA25925; Wed, 11 Oct 2000 07:34:57 -0700 (PDT) Message-Id: <5.0.0.25.2.20001011150921.00a75eb0@nemo.corp.equinix.com> X-Sender: icooper@nemo.corp.equinix.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 11 Oct 2000 15:18:34 +0100 To: Keith Moore From: Ian Cooper Subject: Re: WREC/CDNP/extproxy ... moving forward Cc: wrec@cs.utk.edu In-Reply-To: <200010102356.TAA10510@astro.cs.utk.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: At 19:56 10/10/00 -0400, Keith Moore wrote: > > > > CDNP > > ==== > > * Distribution of data from origin servers outside of the administrative > > control of the data owner > >assuming I understand what you mean by the above, I don't think IETF >should be endorsing such practices at all. I see two pieces: > >1. how the content provider makes data available to consumers, and >how it makes the locations of those data known to consumers > >2. how consumers find and access such data > >the first is under control of the content-provider; the second >is under control over the consumer. > >I see no legitimate role for a third party that isn't acting under >explicit instructions from one or the other of the first two >parties. IMHO, *this* is what IETF should standardize. Mark was right in his comments. This was meant to mean distribution to servers where the data owner/content provider is not the owner of the systems to which the end-user connects in order to retrieve material (e.g. surrogates within a CDN). > > (I'd specifically exclude the scenario where the distribution occurs > within > > a single administrative domain... do we really need to standardize that?) > >yes, because there is a need to have standardized interfaces between >content providers and content-distribution networks acting on >behalf of the content providers. there is also a need for a standardized >and efficient interface between content users and content >distribution networks - the stuff we are using now is quite crude. Looks like I was misunderstood, since I meant that part to be where a content provider wanted to do distribution across systems that they owned rather than CDNs. Is that something that we should be looking at? > > * Routing request to closest site (service) with the requested data > > - should probably consider caching proxies in the model > > - (obviously has some aspects of competitive advantage as was discussed > > from the WREC KP draft in Pittsburgh) > > - definition of the "closest" site (see WREC KP draft on known failings > > of ICP in heterogeneous network) > >not sure how to define it better but "closest" (or any superlative) may >be over-ambitious Yes, that was the sort of point I was trying to raise. The KP draft gives an example where "close" (network RTT) may be worse when there's more bandwidth available between 2 points. We need a succinct way to say "there, yes, that thing, that's in the currently optimal place to serve it". I seem to recall some heated "discussion" over the use of the word "optimal" in Mark's presentation at WCW5 earlier this year. From owner-wrec@cs.utk.edu Wed Oct 11 11:15:41 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12810 for ; Wed, 11 Oct 2000 11:15:40 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id LAA12933; Wed, 11 Oct 2000 11:11:46 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 11 Oct 2000 11:10:23 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id LAA12706; Wed, 11 Oct 2000 11:10:23 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id LAA12685; Wed, 11 Oct 2000 11:10:21 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Wed, 11 Oct 2000 11:10:21 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id LAA10228; Wed, 11 Oct 2000 11:10:19 -0400 (EDT) Message-Id: <200010111510.LAA10228@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Ian Cooper cc: Keith Moore , wrec@cs.utk.edu Subject: Re: WREC/CDNP/extproxy ... moving forward In-reply-to: Your message of "Wed, 11 Oct 2000 15:18:34 BST." <5.0.0.25.2.20001011150921.00a75eb0@nemo.corp.equinix.com> Date: Wed, 11 Oct 2000 11:10:19 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: > >yes, because there is a need to have standardized interfaces between > >content providers and content-distribution networks acting on > >behalf of the content providers. there is also a need for a standardized > >and efficient interface between content users and content > >distribution networks - the stuff we are using now is quite crude. > > Looks like I was misunderstood, since I meant that part to be where a > content provider wanted to do distribution across systems that they owned > rather than CDNs. Is that something that we should be looking at? from a protocol perspective, I don't think it matters whether the CDN is owned by the content-provider or whether it is owned by a separate party. we still need to define the interaction between the two, so that there are standard components. then it's a business decision on the content-provider's part as to whether to build the CDN itself (and whether to do so out of standard components or to roll its own), or pay someone else to do that function. (note that accounting/billing support are useful even when the content and the CDN are owned by the same party) Keith From owner-wrec@cs.utk.edu Wed Oct 11 11:24:27 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13032 for ; Wed, 11 Oct 2000 11:24:26 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id LAA15188; Wed, 11 Oct 2000 11:20:28 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 11 Oct 2000 11:19:06 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id LAA15011; Wed, 11 Oct 2000 11:19:06 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id LAA14991; Wed, 11 Oct 2000 11:19:04 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Wed, 11 Oct 2000 11:19:04 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id LAA10298; Wed, 11 Oct 2000 11:19:00 -0400 (EDT) Message-Id: <200010111519.LAA10298@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Ian Cooper cc: Keith Moore , LOVRIC Ivan FTRD/DMI/CAE , wrec@cs.utk.edu Subject: Re: WREC/CDNP/extproxy ... moving forward In-reply-to: Your message of "Wed, 11 Oct 2000 15:32:18 BST." <5.0.0.25.2.20001011152331.00a76880@nemo.corp.equinix.com> Date: Wed, 11 Oct 2000 11:18:59 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: > >what if the consumer has a legitimate need to access something that just > >happens to look to the virus filter like it contains a virus? > >what if the filter doesn't just check for viruses, but also things that > >look (to it) like porn? > > Those examples are problematic as they demonstrate situations where there > could be a valid reason for having filters on the network border. define 'network border'. :) (now try to define it in a world with ubiquitous portable/wireless devices, where legitimate interaction patterns no longer correlate well with network topology. imho, topology-based filters are a dead-end. ) > In those cases you can argue that the consumer isn't the user sat in > front of her browser, but the guy that decides who can use the network > and what they can use it for. you could argue that. I'm not at all sure it's either socially valuable, or that it makes sense from an architectural point of view. however, without trying to nail down the definition of 'consumer' just yet, my point is that different users have different needs, and the filters which one might find useful, will cause harm to another. if you want the system to work predictably you can't have third parties who have no responsibility to the consumer or the content-provider imposing arbitrary constraints on how the system operates. Keith From owner-wrec@cs.utk.edu Wed Oct 11 11:56:34 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13828 for ; Wed, 11 Oct 2000 11:56:33 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id LAA20608; Wed, 11 Oct 2000 11:52:31 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 11 Oct 2000 11:51:06 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id LAA20429; Wed, 11 Oct 2000 11:51:05 -0400 (EDT) Received: from mail-blue.research.att.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id LAA20406; Wed, 11 Oct 2000 11:51:03 -0400 (EDT) Received: from mail-blue.research.att.com (135.207.30.102 -> mail-blue.research.att.com) by cs.utk.edu (smtpshim v1.0); Wed, 11 Oct 2000 11:51:03 -0400 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id ABD484CE3D; Wed, 11 Oct 2000 11:50:58 -0400 (EDT) Received: from escort.research.att.com (wave-118.research.att.com [135.207.10.118]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id LAA10280; Wed, 11 Oct 2000 11:50:57 -0400 (EDT) Received: (from spatsch@localhost) by escort.research.att.com (8.11.0/8.9.3) id e9BBrCC26233; Wed, 11 Oct 2000 07:53:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14820.21671.939553.702750@escort.research.att.com> Date: Wed, 11 Oct 2000 07:53:11 -0400 (EDT) From: Oliver Spatscheck To: Keith Moore Cc: Ian Cooper , LOVRIC Ivan FTRD/DMI/CAE , wrec@cs.utk.edu Subject: Re: WREC/CDNP/extproxy ... moving forward In-Reply-To: <200010111519.LAA10298@astro.cs.utk.edu> References: <5.0.0.25.2.20001011152331.00a76880@nemo.corp.equinix.com> <200010111519.LAA10298@astro.cs.utk.edu> X-Mailer: VM 6.72 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid List-Unsubscribe: Content-Transfer-Encoding: 7bit Keith Moore writes: > > however, without trying to nail down the definition of 'consumer' just > yet, my point is that different users have different needs, and > the filters which one might find useful, will cause harm to another. > if you want the system to work predictably you can't have third parties > who have no responsibility to the consumer or the content-provider > imposing arbitrary constraints on how the system operates. > Keith, without telling me what a consumer is I am not quite sure if there is a third party in the network. According to your definition it would have no responsibility to the consumer or the content-provider now every player on the Internet has some kind of responsibility to the consumer or the content-provider. Oliver From owner-wrec@cs.utk.edu Wed Oct 11 12:31:24 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14592 for ; Wed, 11 Oct 2000 12:31:23 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA25610; Wed, 11 Oct 2000 12:27:11 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 11 Oct 2000 12:25:45 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA25460; Wed, 11 Oct 2000 12:25:43 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA25432; Wed, 11 Oct 2000 12:25:36 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Wed, 11 Oct 2000 12:25:36 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id MAA10952; Wed, 11 Oct 2000 12:25:28 -0400 (EDT) Message-Id: <200010111625.MAA10952@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Oliver Spatscheck cc: Keith Moore , Ian Cooper , LOVRIC Ivan FTRD/DMI/CAE , wrec@cs.utk.edu Subject: Re: WREC/CDNP/extproxy ... moving forward In-reply-to: Your message of "Wed, 11 Oct 2000 07:53:11 EDT." <14820.21671.939553.702750@escort.research.att.com> Date: Wed, 11 Oct 2000 12:25:28 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: > now every player on the Internet has some kind of responsibility to the > consumer or the content-provider. right, but at some point that responsibility is so distant that it is no help in fixing things when they don't work. or to put it another way, we should design the system in such a way that (at least, for components that conform to the specification) the behavior of intermedaries is specified by the end-users of the system (meaning both providers and consumers) and such intermediaries can be circumvented when the need arieses. Keith From owner-wrec@cs.utk.edu Wed Oct 11 12:33:45 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14640 for ; Wed, 11 Oct 2000 12:33:45 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA26168; Wed, 11 Oct 2000 12:29:39 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 11 Oct 2000 12:28:17 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA25750; Wed, 11 Oct 2000 12:28:17 -0400 (EDT) Received: from mercury.Sun.COM (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA25729; Wed, 11 Oct 2000 12:28:11 -0400 (EDT) Received: from mercury.Sun.COM (192.9.25.1 -> mercury.Sun.COM) by cs.utk.edu (smtpshim v1.0); Wed, 11 Oct 2000 12:28:11 -0400 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA29437; Wed, 11 Oct 2000 09:28:06 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.88.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id JAA12700; Wed, 11 Oct 2000 09:27:51 -0700 (PDT) Received: from viper (viper.Eng.Sun.COM [129.146.88.132]) by jurassic.eng.sun.com (8.11.1+Sun/8.11.1) with SMTP id e9BGRpf165631; Wed, 11 Oct 2000 09:27:51 -0700 (PDT) Message-Id: <200010111627.e9BGRpf165631@jurassic.eng.sun.com> Date: Wed, 11 Oct 2000 09:28:42 -0700 (PDT) From: Michael Condry Reply-To: Michael Condry Subject: Re: WREC/CDNP/extproxy ... moving forward To: icooper@equinix.com, moore@cs.utk.edu Cc: moore@cs.utk.edu, ivan.lovric@rd.francetelecom.fr, wrec@cs.utk.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: DrkT+p5czL3M3hkFhnCAvA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc List-Unsubscribe: > X-URI: http://www.cs.utk.edu/~moore/ > To: Ian Cooper > cc: Keith Moore , LOVRIC Ivan FTRD/DMI/CAE , wrec@cs.utk.edu > Subject: Re: WREC/CDNP/extproxy ... moving forward > List-Unsubscribe: > > > >what if the consumer has a legitimate need to access something that just > > >happens to look to the virus filter like it contains a virus? > > >what if the filter doesn't just check for viruses, but also things that > > >look (to it) like porn? > > > > Those examples are problematic as they demonstrate situations where there > > could be a valid reason for having filters on the network border. > > define 'network border'. :) > > (now try to define it in a world with ubiquitous portable/wireless devices, > where legitimate interaction patterns no longer correlate well with > network topology. imho, topology-based filters are a dead-end. ) Does it really have to be defined? Its seems that the issue is "it is not the ends". It can be a device anywhere "inside". > > > In those cases you can argue that the consumer isn't the user sat in > > front of her browser, but the guy that decides who can use the network > > and what they can use it for. > > you could argue that. I'm not at all sure it's either socially valuable, > or that it makes sense from an architectural point of view. > > however, without trying to nail down the definition of 'consumer' just > yet, my point is that different users have different needs, and > the filters which one might find useful, will cause harm to another. > if you want the system to work predictably you can't have third parties > who have no responsibility to the consumer or the content-provider > imposing arbitrary constraints on how the system operates. > > Keith Isn't there a "content services" model here where one point is a provider that gets paid and the other is a consumer that pays. From owner-wrec@cs.utk.edu Wed Oct 11 12:44:53 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14812 for ; Wed, 11 Oct 2000 12:44:52 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA28668; Wed, 11 Oct 2000 12:40:52 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 11 Oct 2000 12:39:30 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA28501; Wed, 11 Oct 2000 12:39:29 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA28479; Wed, 11 Oct 2000 12:39:27 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Wed, 11 Oct 2000 12:39:27 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id MAA11113; Wed, 11 Oct 2000 12:39:19 -0400 (EDT) Message-Id: <200010111639.MAA11113@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Michael Condry cc: icooper@equinix.com, moore@cs.utk.edu, ivan.lovric@rd.francetelecom.fr, wrec@cs.utk.edu Subject: Re: WREC/CDNP/extproxy ... moving forward In-reply-to: Your message of "Wed, 11 Oct 2000 09:28:42 PDT." <200010111627.e9BGRpf165631@jurassic.eng.sun.com> Date: Wed, 11 Oct 2000 12:39:18 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: > > > Those examples are problematic as they demonstrate situations where there > > > could be a valid reason for having filters on the network border. > > > > define 'network border'. :) > > > > (now try to define it in a world with ubiquitous portable/wireless devices, > > where legitimate interaction patterns no longer correlate well with > > network topology. imho, topology-based filters are a dead-end. ) > > Does it really have to be defined? Its seems that the issue > is "it is not the ends". It can be a device anywhere "inside". my point was that the notion that you can reliably filter traffic by interception traffic at some point in the network topology is probably going to go away. but yes, once we have an architecture for locating intermediaries independent of network topology then those intermediaries are also in a position to do filtering. > > > In those cases you can argue that the consumer isn't the user sat in > > > front of her browser, but the guy that decides who can use the network > > > and what they can use it for. > > > > you could argue that. I'm not at all sure it's either socially valuable, > > or that it makes sense from an architectural point of view. > > > > however, without trying to nail down the definition of 'consumer' just > > yet, my point is that different users have different needs, and > > the filters which one might find useful, will cause harm to another. > > if you want the system to work predictably you can't have third parties > > who have no responsibility to the consumer or the content-provider > > imposing arbitrary constraints on how the system operates. > > > > Keith > > Isn't there a "content services" model here where one point > is a provider that gets paid and the other is a consumer that > pays. I'd rather leave assumptions about who pays whom out of the model. The information might be freely available, or the provider could be paying the consumer for reading his advertisements. Keith p.s. actually I don't even like the provider vs. consumer dichotomy - I'd rather think in terms of a bidirectional flow of information without assigning such roles. after all, nearly every "consumer" is a provider of some information - forms that are filled in, click trails derived from cookies, etc. - and I don't inherently see why consumer-provided information should not be treated with the same respect as provider-provided information. either party should have the right to control dissemenation of that information; neither should have it viewed or modified by third parties without consent. From owner-wrec@cs.utk.edu Wed Oct 11 12:57:57 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15181 for ; Wed, 11 Oct 2000 12:57:56 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA01182; Wed, 11 Oct 2000 12:53:53 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 11 Oct 2000 12:52:25 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA00929; Wed, 11 Oct 2000 12:52:25 -0400 (EDT) Received: from mercury.Sun.COM (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA00912; Wed, 11 Oct 2000 12:52:22 -0400 (EDT) Received: from mercury.Sun.COM (192.9.25.1 -> mercury.Sun.COM) by cs.utk.edu (smtpshim v1.0); Wed, 11 Oct 2000 12:52:22 -0400 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA10071; Wed, 11 Oct 2000 09:51:52 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.88.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id JAA18781; Wed, 11 Oct 2000 09:48:50 -0700 (PDT) Received: from viper (viper.Eng.Sun.COM [129.146.88.132]) by jurassic.eng.sun.com (8.11.1+Sun/8.11.1) with SMTP id e9BGmnf169401; Wed, 11 Oct 2000 09:48:49 -0700 (PDT) Message-Id: <200010111648.e9BGmnf169401@jurassic.eng.sun.com> Date: Wed, 11 Oct 2000 09:49:40 -0700 (PDT) From: Michael Condry Reply-To: Michael Condry Subject: Re: WREC/CDNP/extproxy ... moving forward To: spatsch@research.att.com, moore@cs.utk.edu Cc: moore@cs.utk.edu, icooper@equinix.com, ivan.lovric@rd.francetelecom.fr, wrec@cs.utk.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: q0lNWebA6I10EH4h4kJDqQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc List-Unsubscribe: > X-URI: http://www.cs.utk.edu/~moore/ > To: Oliver Spatscheck > cc: Keith Moore , Ian Cooper , LOVRIC Ivan FTRD/DMI/CAE , wrec@cs.utk.edu > Subject: Re: WREC/CDNP/extproxy ... moving forward > List-Unsubscribe: > > > now every player on the Internet has some kind of responsibility to the > > consumer or the content-provider. > > right, but at some point that responsibility is so distant that it > is no help in fixing things when they don't work. I am not sure I agree. That is the way things work today. This is the additional architecture we need to add. > > or to put it another way, we should design the system in such a way that > (at least, for components that conform to the specification) > the behavior of intermedaries is specified by the end-users of the system > (meaning both providers and consumers) and such intermediaries can > be circumvented when the need arieses. > > Keith From owner-wrec@cs.utk.edu Wed Oct 11 13:01:29 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15275 for ; Wed, 11 Oct 2000 13:01:29 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA02021; Wed, 11 Oct 2000 12:57:21 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 11 Oct 2000 12:55:59 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA01513; Wed, 11 Oct 2000 12:55:58 -0400 (EDT) Received: from mercury.Sun.COM (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA01449; Wed, 11 Oct 2000 12:55:51 -0400 (EDT) Received: from mercury.Sun.COM (192.9.25.1 -> mercury.Sun.COM) by cs.utk.edu (smtpshim v1.0); Wed, 11 Oct 2000 12:55:51 -0400 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA13752; Wed, 11 Oct 2000 09:55:42 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.88.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id JAA20820; Wed, 11 Oct 2000 09:55:40 -0700 (PDT) Received: from viper (viper.Eng.Sun.COM [129.146.88.132]) by jurassic.eng.sun.com (8.11.1+Sun/8.11.1) with SMTP id e9BGtef170915; Wed, 11 Oct 2000 09:55:40 -0700 (PDT) Message-Id: <200010111655.e9BGtef170915@jurassic.eng.sun.com> Date: Wed, 11 Oct 2000 09:56:31 -0700 (PDT) From: Michael Condry Reply-To: Michael Condry Subject: Re: WREC/CDNP/extproxy ... moving forward To: moore@cs.utk.edu Cc: wrec@cs.utk.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: fTya7dDlvlhXnPRNOjIAlw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc List-Unsubscribe: > X-URI: http://www.cs.utk.edu/~moore/ > ..... > > Isn't there a "content services" model here where one point > > is a provider that gets paid and the other is a consumer that > > pays. > > I'd rather leave assumptions about who pays whom out of the model. > The information might be freely available, or the provider could be > paying the consumer for reading his advertisements. > > Keith > > p.s. actually I don't even like the provider vs. consumer dichotomy - > I'd rather think in terms of a bidirectional flow of information > without assigning such roles. after all, nearly every "consumer" > is a provider of some information - forms that are filled in, > click trails derived from cookies, etc. - and I don't inherently > see why consumer-provided information should not be treated with > the same respect as provider-provided information. either party > should have the right to control dissemenation of that > information; neither should have it viewed or modified by third > parties without consent. > We are not in disagreement over concepts, just language. Somewhere a point requesting content/information, locating the content for that requestor, and telling the content owner its being used have be spelled out. I do not like the CDN peering language either but it does spell some of this out! From owner-wrec@cs.utk.edu Wed Oct 11 13:16:10 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15568 for ; Wed, 11 Oct 2000 13:16:09 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id NAA05240; Wed, 11 Oct 2000 13:11:49 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 11 Oct 2000 13:10:22 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id NAA05019; Wed, 11 Oct 2000 13:10:21 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id NAA04997; Wed, 11 Oct 2000 13:10:20 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Wed, 11 Oct 2000 13:10:20 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA11398; Wed, 11 Oct 2000 13:10:15 -0400 (EDT) Message-Id: <200010111710.NAA11398@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Michael Condry cc: spatsch@research.att.com, moore@cs.utk.edu, icooper@equinix.com, ivan.lovric@rd.francetelecom.fr, wrec@cs.utk.edu Subject: Re: WREC/CDNP/extproxy ... moving forward In-reply-to: Your message of "Wed, 11 Oct 2000 09:49:40 PDT." <200010111648.e9BGmnf169401@jurassic.eng.sun.com> Date: Wed, 11 Oct 2000 13:10:15 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: > > right, but at some point that responsibility is so distant that it > > is no help in fixing things when they don't work. > > I am not sure I agree. That is the way things work today. > This is the additional architecture we need to add. I'm not sure what you're trying to say here. as far as I can tell, things mostly work today in the absence of intermediaries, and they fail quite often in the presence of intermediaries that filter and/or alter content. in the cases where the intermediaries cause failures, it's often difficult to fix the problem because the intermediary cannot be controlled. (often it's not even identified as the culprit) this is at every level of the protocol stack. Keith From owner-wrec@cs.utk.edu Thu Oct 12 01:14:02 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA01357 for ; Thu, 12 Oct 2000 01:14:02 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id BAA24643; Thu, 12 Oct 2000 01:09:58 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 12 Oct 2000 01:08:34 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id BAA24567; Thu, 12 Oct 2000 01:08:33 -0400 (EDT) Received: from ogma.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id BAA24553; Thu, 12 Oct 2000 01:08:31 -0400 (EDT) Received: from ogma.cisco.com (144.254.74.39 -> ogma.cisco.com) by cs.utk.edu (smtpshim v1.0); Thu, 12 Oct 2000 01:08:32 -0400 Received: from nordic.cisco.com (nordic.cisco.com [144.254.116.14]) by ogma.cisco.com (Postfix) with ESMTP id 32496AD for ; Thu, 12 Oct 2000 07:08:30 +0200 (MET DST) Received: from [144.254.47.143] (ams-vpdn-client-395.cisco.com [144.254.47.143]) by nordic.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id HAA05618 for ; Thu, 12 Oct 2000 07:08:28 +0200 (MET DST) Mime-Version: 1.0 X-Sender: pfaltstr@nordic.cisco.com Message-Id: In-Reply-To: <200010111710.NAA11398@astro.cs.utk.edu> References: <200010111710.NAA11398@astro.cs.utk.edu> Date: Thu, 12 Oct 2000 00:55:24 +0200 To: wrec@cs.utk.edu From: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?= Subject: Re: WREC/CDNP/extproxy ... moving forward Content-Type: text/plain; charset="us-ascii" ; format="flowed" List-Unsubscribe: I would like people to differ in the discussions between: - What issues are there to talk about - What issues are good/bad/inside IETF/outside IETF I don't mind having things on the list which we later find that IETF should not deal with because of various reasons. A list of "this wg should NOT deal with the following things" is sometimes better than one only talking about things which are included. That said, I never saw a list with issues which people agreed on... Patrik From owner-wrec@cs.utk.edu Thu Oct 12 11:39:55 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00126 for ; Thu, 12 Oct 2000 11:39:55 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id LAA13843; Thu, 12 Oct 2000 11:35:48 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 12 Oct 2000 11:34:15 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id LAA13512; Thu, 12 Oct 2000 11:34:14 -0400 (EDT) Received: from havoc.entera.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id LAA13465; Thu, 12 Oct 2000 11:34:11 -0400 (EDT) Received: from havoc.entera.com (206.165.109.130 -> havoc.entera.com) by cs.utk.edu (smtpshim v1.0); Thu, 12 Oct 2000 11:34:12 -0400 Received: from exchange.entera.com ([206.165.109.233]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-68752U400L100S0V35) with ESMTP id com; Thu, 12 Oct 2000 08:36:25 -0700 Received: by exchange.entera.com with Internet Mail Service (5.5.2650.21) id <4123WZHF>; Thu, 12 Oct 2000 08:32:37 -0700 Message-ID: <733880CDF866D3118C69005004D1701E0121E734@exchange.entera.com> From: garyt@entera.com (Gary Tomlinson) To: Keith Moore , Ian Cooper Cc: wrec@cs.utk.edu Subject: RE: WREC/CDNP/extproxy ... moving forward Date: Thu, 12 Oct 2000 08:32:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" List-Unsubscribe: >From: Keith Moore [mailto:moore@cs.utk.edu] >Sent: Wednesday, October 11, 2000 8:10 AM >from a protocol perspective, I don't think it matters whether the CDN >is owned by the content-provider or whether it is owned by a separate >party. we still need to define the interaction between the two, so >that there are standard components. then it's a business decision >on the content-provider's part as to whether to build the CDN itself >(and whether to do so out of standard components or to roll its own), >or pay someone else to do that function. Yes, this in part is the essence of what we've proposed thus far in CDNP. Peering is the interaction between CDNs (including Content Provider to CDN relationship as well) and is not intended to constrain business model value chains. A slight clarification is in order with respect to building CDNs. CDNP deals with interaction between CDNs but does not address the components within CDNs, which is a seperate but interesting topic. Think of CDNP as being the exterior protocols used between administrative domains, much like EGP was used for in IP peering. >(note that accounting/billing support are useful even when >the content and the CDN are owned by the same party) In CDNP, we imagine accounting being of great value in providing feedback to the system in order to tune it, provision it, as well as determine its effectiveness. Gary From owner-wrec@cs.utk.edu Thu Oct 12 12:14:45 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01249 for ; Thu, 12 Oct 2000 12:14:45 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA19010; Thu, 12 Oct 2000 12:10:41 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 12 Oct 2000 12:09:18 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA18734; Thu, 12 Oct 2000 12:09:17 -0400 (EDT) Received: from havoc.entera.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA18718; Thu, 12 Oct 2000 12:09:16 -0400 (EDT) Received: from havoc.entera.com (206.165.109.130 -> havoc.entera.com) by cs.utk.edu (smtpshim v1.0); Thu, 12 Oct 2000 12:09:16 -0400 Received: from exchange.entera.com ([206.165.109.233]) by havoc.entera.com (Post.Office MTA v3.5.3 release 223 ID# 0-68752U400L100S0V35) with ESMTP id com; Thu, 12 Oct 2000 09:11:29 -0700 Received: by exchange.entera.com with Internet Mail Service (5.5.2650.21) id <4123WZJX>; Thu, 12 Oct 2000 09:07:41 -0700 Message-ID: <733880CDF866D3118C69005004D1701E0121E739@exchange.entera.com> From: garyt@entera.com (Gary Tomlinson) To: icooper@equinix.com, wrec@cs.utk.edu Subject: RE: WREC/CDNP/extproxy ... moving forward Date: Thu, 12 Oct 2000 09:07:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" List-Unsubscribe: >From: Ian Cooper [mailto:icooper@equinix.com] >Sent: Tuesday, October 10, 2000 12:49 PM >WREC >==== >* Proxy/surrogate discovery protocol for user agents > - initial intent is probably for "user agents" to mean browsers; > - should also consider some aspects of wider proxy/surrogate discovery >or registration that will probably be interesting to CDNP and extproxy >(e.g. proxies/surrogates being able to discover other proxies or surrogates) > - obviously of interest to the folks doing the extensible proxy work > >* Cache coherence/invalidation protocol > - including delta encoding and preloading within the administrative >control of the data owner > - will probably touch on expiry semantics in passing > - will be of interest to the CDNP folks too > List looks reasonable. CDNP BOF -> WG? >==== >* Distribution of data from origin servers outside of the administrative >control of the data owner > >(I'd specifically exclude the scenario where the distribution occurs within >a single administrative domain... do we really need to standardize that?) I second the motion to limit scope to INTER-CDN interactions which implies inter administrative domains. The need to standardize within a CDN is IMHO an important step to take in the future (outside the scope of CDNP), as it would allow CDNs to be built from standard components. Possibly the work undertaken in WREC with repect to discovery and cache coherency would prove usefull in seeding this. > >* Routing request to closest site (service) with the requested data > - should probably consider caching proxies in the model > - (obviously has some aspects of competitive advantage as was discussed >from the WREC KP draft in Pittsburgh) > - definition of the "closest" site (see WREC KP draft on known failings >of ICP in heterogeneous network) > - may overlap with, or provide us with, (or show us that it's >unnecessary to have) some replacement for ICP in the caching world > > >Billing (and more) >================== >There seems to be a case for billing/accounting to be covered in all three >of WREC, CDNP and extensible proxies. I believe that the extproxy folks >have commented that this may be appropriate work for another group (AAA?), >and it definitely seems that it's beyond any one of those being discussed here. > Actually, there is precedence in the IETF for WGs to provide their own AAA extensions. mobileip and ipv6 are examples. >If we therefore open the scope to the wider issue of authentication and >authorization I guess we can add > >* Exchange format for log summaries (essentially some form of accounting >records; this is the problem identified in the WREC known problems document) > >* User session management > >* Authentication models for multi-sited services/TLS interaction Authentication is likely needed for surrogates in CDNP. Extensible Proxies BOF --> WG? ================== Here's are strawman on activities within Extensible Proxies * Trigger rule base syntax & semantics * Excution run time model and security constraints * Proxylet distribution protocol * ICAP remote call out protocol standardization It makes sense to me to have 3 WGs attacking this space in parallel focused charters that can be complete signifiant deliverables in 12-18 months and then address the issues of rechartering to take on deferred work. Gary From owner-wrec@cs.utk.edu Thu Oct 12 12:53:07 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02073 for ; Thu, 12 Oct 2000 12:53:05 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA24442; Thu, 12 Oct 2000 12:49:06 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 12 Oct 2000 12:47:43 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA24334; Thu, 12 Oct 2000 12:47:43 -0400 (EDT) Received: from harrier.prod.itd.earthlink.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA24321; Thu, 12 Oct 2000 12:47:41 -0400 (EDT) From: <00914698@yahoo.com> Received: from harrier.prod.itd.earthlink.net (207.217.121.12 -> harrier.prod.itd.earthlink.net) by cs.utk.edu (smtpshim v1.0); Thu, 12 Oct 2000 12:47:41 -0400 Received: from mail.earthlink.net (1Cust57.tnt2.des-moines.ia.da.uu.net [63.11.130.57]) by harrier.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with SMTP id JAA14327; Thu, 12 Oct 2000 09:46:52 -0700 (PDT) Received: from spyguide22@yahoo.com by cathy127@excite.com (8.8.5/8.6.5) with SMTP id GAA02774 for ; Thu, 12 Oct 2000 23:11:36 -0600 (EST) Date: Thu, 12 Oct 00 23:11:36 EST To: mikeh727@yahoo.com Subject: The Net Detective. Learn how to snoop on Anyone! Message-ID: <> List-Unsubscribe: READY TO KNOW? > > CONFIDENTIAL > > The SOFTWARE They Want BANNED In all 50 STATES. > Why? Because these secrets were never intended to reach your eyes... > Get the facts on anyone! > > Locate Missing Persons, find Lost Relatives, obtain Addresses > and Phone Numbers of old school friends, even Skip Trace Dead > Beat Spouses. This is not a Private Investigator, but a > sophisticated SOFTWARE program DESIGNED to automatically > CRACK YOUR CASE with links to thousands of Public Record databases. > > Find out SECRETS about your relatives, friends, enemies, > and everyone else! -- even your spouse! With the New, > INTERNET SPY AND YOU! > > It's absolutely astounding! Here's what you can learn: > > License plate number! > Get anyone's name and address with just a license plate number! > (Find that girl you met in traffic!) > > Driving record! > Get anyone's driving record > > Social security number! > Trace anyone by social security number! > > Address! > Get anyone's address with just a name! > > Unlisted phone numbers! > Get anyone's phone number with just a name-even unlisted numbers! > > Locate! > Long lost friends, relatives, a past lover who broke your heart! > > E-mail! > Send anonymous e-mail completely untraceable! > > Dirty secrets! > Discover dirty secrets your in-laws don't want you to know! > > Investigate anyone! > Use the sources that private investigators use (all on the Internet) > secretly! > > Ex-spouse! > Learn how to get information on an ex-spouse that will help you > win in court! (Dig up old skeletons) > > Criminal search-Backround check! > Find out about your daughters boyfriend! > (or her husband) > > Find out! > If you are being investigated! > > Neighbors! > Learn all about your mysterious neighbors! Find out what they > have to hide! > > People you work with! > Be astonished by what you'll learn about people you work with! > > Education verification! > Did he really graduate college? Find out! > > Internet Spy and You > Software will help you discover ANYTHING about anyone, with > clickable hyperlinks and no typing in Internet addresses! Just > insert the floppy disk and Go! > > You will be shocked and amazed by the secrets that can be > discovered about absolutely everyone! Find out the secrets > they don't want you to know! About others, about yourself! > > It's INCREDIBLE what you can find out using Internet Spy and You > and the Internet! You'll be riveted to your computer screen! > Get the software they're trying to ban! Before it's too late! > > LIMITED TIME OFFER: ORDER TODAY! > > Only $24.95 > > > We will RUSH YOU our Internet Spy and You software so you can > begin discovering all the secrets you ever wanted to know! > > You can know EVERYTHING about ANYONE with our Internet Spy and > You Software. Works with all browsers and all versions of AOL! > > ORDER TODAY: SEND ONLY $24.95 US CASH, CHECK, OR MONEY ORDER > (you may also send one of your own address labels > for accuracy if you have one.) > > ATTENTION ORDERS OUTSIDE THE US: You must ad $5 for shipping. > > > *Foreign money orders must be payable on a US BANK AND IN US FUNDS! > NO EXCEPTIONS! > > > > > DON'T WAIT TO GET STARTED... it's as easy as 1. 2. 3. > > > STEP 1 - Print the order form text below > > STEP 2 - Type or print your order information into the order form section > > STEP 3 - Mail order form and payment to the address below > > > > > >>>>>>>>>>>>>>>>>>>>>>>>>>Mail the portion below<<<<<<<<<<<<<<<<<<<< > > Send to: > > Consumer Resources > > PO BOX 283 > > Johnston, IA 50131 > > > U.S.A > > > > > > >>>>>>>>>>>>>>>>>>>>> Mail-in Order Form <<<<<<<<<<<<<<<<<<<<<<<< > > > > > Name: ______________________________ > > > Address: _____________________________ > > > City/State/Zip __________________________________________ > > > > > > > > > >>>>>>>>>>>>>>>>>>>>>> end of form <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< > > DISCLAIMER: The seller of this powerful software resource will not be > held responsible for how the purchaser chooses to use its resources. > > > > > To be removed from our mailing list please > send an email to m743@dcemail.com and put remove > in the subject. > Thank you From owner-wrec@cs.utk.edu Fri Oct 13 19:30:51 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13229 for ; Fri, 13 Oct 2000 19:30:50 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id TAA01175; Fri, 13 Oct 2000 19:26:32 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 13 Oct 2000 19:25:06 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id TAA01025; Fri, 13 Oct 2000 19:25:00 -0400 (EDT) Received: from 1-132.mnot.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id TAA01010; Fri, 13 Oct 2000 19:24:53 -0400 (EDT) Received: from 1-132.mnot.net (63.201.242.106 -> adsl-63-201-242-106.dsl.snfc21.pacbell.net) by cs.utk.edu (smtpshim v1.0); Fri, 13 Oct 2000 19:24:53 -0400 Received: by 1-132.mnot.net (Postfix, from userid 500) id D17EF6601; Fri, 13 Oct 2000 16:24:45 -0700 (PDT) Date: Fri, 13 Oct 2000 16:24:45 -0700 From: Mark Nottingham To: http-wg@hplb.hpl.hp.com, WREC Working Group Subject: ANN: HTTP compliance mailing list Message-ID: <20001013162445.A1649@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i List-Unsubscribe: Since there seems to be some level of interest in HTTP compliance testing, but it's not clear that such discussion belongs in the IETF, I've created a mailing list, http-compliance@egroups.com I'd like to discuss the nature and scoping of possible testing, and gather specific items for testing. I'm also interesting in getting input from server, client and intermediate vendors. Hopefully, the list can be used to gauge the amount of interest in compliance testing, define the issues (like scoping, nature of tests, etc) in order to be able to ease the work into a standards body like the W3C. You can subscribe by sending mail to: http-compliance-subscribe@egroups.com alternatively, visit http://www.egroups.com/subscribe/http-compliance Cheers, -- Mark Nottingham http://www.mnot.net/ From owner-wrec@cs.utk.edu Sun Oct 15 14:10:10 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09512 for ; Sun, 15 Oct 2000 14:10:10 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id OAA21969; Sun, 15 Oct 2000 14:06:10 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 15 Oct 2000 14:04:27 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id OAA21850; Sun, 15 Oct 2000 14:04:26 -0400 (EDT) Received: from fozzie.sanmateo.akamai.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id OAA21803; Sun, 15 Oct 2000 14:04:19 -0400 (EDT) Received: from fozzie.sanmateo.akamai.com (63.102.156.130 -> fw-west.west.akamai.com) by cs.utk.edu (smtpshim v1.0); Sun, 15 Oct 2000 14:04:20 -0400 Received: from jad ([172.23.3.60]) by fozzie.sanmateo.akamai.com (8.9.3/8.9.3) with SMTP id LAA06026 for ; Sun, 15 Oct 2000 11:01:48 -0700 (PDT) Message-ID: <030501c036d2$5ca197e0$ab45c53f@jad> Reply-To: "John Dilley" From: "John Dilley" To: Subject: WREC rechartering Date: Sun, 15 Oct 2000 11:04:21 -0700 Organization: Akamai Technologies X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 List-Unsubscribe: I'd like to add my vote for the web replication and caching working group re-charter. The group has developed a taxonomy and list of issues and research problems, as required when originally chartered. The important open issues which seem relevant for future WREC work are: * Browser location of and binding to an authorized, available proxy. * Content distribution networks, surrogates, and content peering. * Content consistency in autonomous proxy/replica servers. The WPAD work addresses the first item; I'd like to see forward progress on this. It is not a single-vendor solution that WREC has been asked to rubber-stamp, I believe it is a step in the right direction. It helps to alleviate the need for interception proxies by allowing browsers to locate and bind to an intermediate. One issue is that the intermediate may not be an authorized distributor for the content provider; that's where the CDN/surrogate work comes in. Content providers are delegating authority to serve their content to distribution networks. There is a push for these networks to peer with each other to distribute content. This requires cooperation at the protocol level to ensure interoperability and clean semantics from content provider end to end user. I think IETF is a good place to do this protocol architecture work. The third item relates to using invalidation to achieve content consistency rather than validation. This can improve efficiency and response time. I do not know of a better forum to discuss this than IETF. It could be outside the WREC working group, but to me is well aligned with replication and caching. The discussion on WREC has been good to see. The working group was too quiet for too long. I support re-chartering WREC to discuss these topics. I do not think there is so much to discuss that we need to splinter into multiple working group, nor do I feel the topics are too disparate. I do not think WREC should attempt to discuss the following topics: * Proxy implementation issues. Forward proxy server implementations are mature. There are issues in the known problems draft that will hopefully be worked on, but I do not believe WREC should devote further attention to them at this time. Interception has been discussed enough IMHO. * HTTP protocol level issues. There was an HTTP working group; that's the right place for this work. The invalidation work, if it happens in WREC, will need to work with an external group to evolve HTTP. If there is not such a group, I think the work should be deprioritized in WREC. Protocol compliance also does not belong in WREC. Regards, -- jad -- John Dilley jad@akamai.com From owner-wrec@cs.utk.edu Tue Oct 17 15:49:57 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20055 for ; Tue, 17 Oct 2000 15:49:28 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA27344; Tue, 17 Oct 2000 15:43:41 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 17 Oct 2000 15:41:09 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA27054; Tue, 17 Oct 2000 15:41:07 -0400 (EDT) Received: from mercury.Sun.COM (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA27021; Tue, 17 Oct 2000 15:40:59 -0400 (EDT) Received: from mercury.Sun.COM (192.9.25.1 -> mercury.Sun.COM) by cs.utk.edu (smtpshim v1.0); Tue, 17 Oct 2000 15:40:59 -0400 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA22594; Tue, 17 Oct 2000 12:40:24 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id MAA03252; Tue, 17 Oct 2000 12:40:23 -0700 (PDT) Received: from condry.org (gbl-rem-33.France.Sun.COM [129.157.174.33]) by jurassic.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9HJeKf128807; Tue, 17 Oct 2000 12:40:21 -0700 (PDT) Message-ID: <39ECAA6B.B9305D73@condry.org> Date: Tue, 17 Oct 2000 12:37:15 -0700 From: "Michael W. Condry" X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en,pdf,zh,zh-CN,zh-TW MIME-Version: 1.0 To: wrec , extproxy Subject: BCD Forum Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit The Broadband folks have a strong need for our proxy model and the associated caching. It gets interesting when they have the volume of bits to deal with. I have asked them to create some requirements that we can feed to WREC and OPES on broadband needs. I will make more notes on the BCDForum meeting later. From owner-wrec@cs.utk.edu Wed Oct 18 00:59:20 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA29458 for ; Wed, 18 Oct 2000 00:59:20 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id AAA00292; Wed, 18 Oct 2000 00:51:28 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 18 Oct 2000 00:50:00 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id AAA29893; Wed, 18 Oct 2000 00:49:59 -0400 (EDT) Received: from mercury.Sun.COM (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id AAA29879; Wed, 18 Oct 2000 00:49:52 -0400 (EDT) Received: from mercury.Sun.COM (192.9.25.1 -> mercury.Sun.COM) by cs.utk.edu (smtpshim v1.0); Wed, 18 Oct 2000 00:49:53 -0400 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA02657; Tue, 17 Oct 2000 21:49:41 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id VAA21698; Tue, 17 Oct 2000 21:49:40 -0700 (PDT) Received: from condry.org (gbl-rem-39.France.Sun.COM [129.157.174.39]) by jurassic.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e9I4nbf215667; Tue, 17 Oct 2000 21:49:38 -0700 (PDT) Message-ID: <39ED2B29.90554075@condry.org> Date: Tue, 17 Oct 2000 21:46:33 -0700 From: "Michael W. Condry" X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en,pdf,zh,zh-CN,zh-TW MIME-Version: 1.0 To: Mark Day , wrec , extproxy Subject: Re: BCD Forum References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit The BCD Forum are more focused on the requirements end of things, rather than competing with the IETF. In fact, I am presenting a proposal today of working together. The do represent a different community and a possible bridge to the content providers. In that way, using them to market our technologies is a good idea and we will respond to their requirements. Like other groups, if we ignore them then they will consider organizing technical requirements. Mark Day wrote: > Is there real technical content to the BCD Forum? I haven't been able to > unearth any yet, but I haven't had much time to pursue the subject. I had a > couple of people tell me it was primarily a marketing activity, but I've > also had BCD Forum people claim otherwise. > > --Mark > > Mark Stuart Day > Senior Scientist > Cisco Systems > +1 (781) 663-8310 > markday@cisco.com > > > -----Original Message----- > > From: Michael W. Condry [mailto:condry@condry.org] > > Sent: Tuesday, October 17, 2000 3:37 PM > > To: wrec; extproxy > > Subject: BCD Forum > > > > > > The Broadband folks have a strong need for our proxy model > > and the associated caching. It gets interesting when they > > have the volume of bits to deal with. > > > > I have asked them to create some requirements that we can > > feed to WREC and OPES on broadband needs. > > > > I will make more notes on the BCDForum meeting later. > > From owner-wrec@cs.utk.edu Wed Oct 18 02:54:16 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA12587 for ; Wed, 18 Oct 2000 02:54:15 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id CAA08230; Wed, 18 Oct 2000 02:50:23 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 18 Oct 2000 02:49:00 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id CAA08160; Wed, 18 Oct 2000 02:49:00 -0400 (EDT) Received: from piglet.dstc.edu.au (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id CAA08129; Wed, 18 Oct 2000 02:48:52 -0400 (EDT) Received: from piglet.dstc.edu.au (130.102.176.1 -> piglet.dstc.edu.au) by cs.utk.edu (smtpshim v1.0); Wed, 18 Oct 2000 02:48:54 -0400 Received: from dstc.edu.au (sunburn.dstc.edu.au [130.102.176.16]) by piglet.dstc.edu.au (8.10.1/8.10.1) with ESMTP id e9I6mWM04187; Wed, 18 Oct 2000 16:48:33 +1000 (EST) To: "Michael W. Condry" cc: wrec , extproxy Subject: Re: BCD Forum In-reply-to: Your message of "Tue, 17 Oct 2000 12:37:15 MST." <39ECAA6B.B9305D73@condry.org> Date: Wed, 18 Oct 2000 16:48:42 +1000 Message-ID: <5523.971851722@dstc.edu.au> From: George Michaelson List-Unsubscribe: The Proposal Van Jacobsen had up for multicast based caches surely fits into this niche well? -George -- George Michaelson | DSTC Pty Ltd Email: ggm@dstc.edu.au | University of Qld 4072 Phone: +61 7 3365 4310 | Australia Fax: +61 7 3365 4311 | http://www.dstc.edu.au From owner-wrec@cs.utk.edu Tue Oct 24 17:02:47 2000 Received: from cs.utk.edu ([128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11414 for ; Tue, 24 Oct 2000 17:02:47 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id QAA27438; Tue, 24 Oct 2000 16:58:26 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 24 Oct 2000 16:56:33 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id QAA27027; Tue, 24 Oct 2000 16:56:32 -0400 (EDT) Received: from mercury.Sun.COM (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id QAA27012; Tue, 24 Oct 2000 16:56:29 -0400 (EDT) Received: from mercury.Sun.COM (192.9.25.1 -> mercury.Sun.COM) by cs.utk.edu (smtpshim v1.0); Tue, 24 Oct 2000 16:56:29 -0400 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA09745; Tue, 24 Oct 2000 13:56:14 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.81.144]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id NAA20585; Tue, 24 Oct 2000 13:55:35 -0700 (PDT) Received: from viper (viper.Eng.Sun.COM [129.146.88.132]) by jurassic.eng.sun.com (8.11.1+Sun/8.11.1) with SMTP id e9OKtXf178060; Tue, 24 Oct 2000 13:55:34 -0700 (PDT) Message-Id: <200010242055.e9OKtXf178060@jurassic.eng.sun.com> Date: Tue, 24 Oct 2000 13:56:27 -0700 (PDT) From: Michael Condry Reply-To: Michael Condry Subject: BCD Forum meeting To: ietf-openproxy@imc.org Cc: wrec@cs.utk.edu, cdn@ops.ietf.org, paf@cisco.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: SN8nOtNspTNOvuKo+HUcVw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc List-Unsubscribe: The BCDF (Broadband Content Delivery Forum) charter is to determine the requirements needed for broadband content delivery. Examining the issues concerning content delivery is coming up a critical area of interest for the Internet folks because of the heading "merger" of network technologies: IP, Cable, Voice, etc. The big content owners, CNN, CBS, NBC, ABC, Time-Warner, etc. are highly concerned with this area including - finding content - how to locate it - delivery of content - receiving "well presented" content - billing - assuring that the content taker is billed (both billing and security). The BCDF was created by Nortel but has since the start restructured itself as an industry consortium focused on broadband issues. The membership is strongly represented by the Telco areas. Projects are partitioned into three areas, called working groups: 1. Market Development - focused on BCDF (broadband) market development issues. 2. Content and Applications - working with the Content groups to assure requirements are met. 3. Infrastructure - defining the requirements for the infrastructure. There are many similarities with the Content Alliance and Content Bridge. All groups seem to be strongly represented by the infrastructure guys and weekly represented by the actual content owners. The Content Alliance is creating the CDN working group at the IETF. My experience and BCDF was with the general forums and infrastructure groups. Although some members were in the "lets invent it here" mode most agreed that listing the requirements and submitting them to the IETF would be the most productive. They also agreed that having the BCDF spend most of its energy working with the content providers to obtain requirements would be the most productive (certainly more than trying to create a different but similar set of specifications to the IETF CNF group). We agreed to get the Content and Applications folks focused on that and attempt to enumerate the broadband requirements for the concerns listed above (location, delivery, billing). I presented the open proxy services architecture and how it might be employed in solving some of their broadband issues. The infrastructure folks felt that the open proxy services model was exactly the kind of infrastructure needed for services in a merged networked technologies environment. They plan to support this for the upcoming IETF. I also gave them a brief overview of the IETF and suggested a plan for submitting requirements there (rather than any self invention). In my opinion they are still too technology focused and not sufficiently strong in understanding the operational rules of the "content "owners. This group has the benefit of beliving that it would be better to let the IETF sort out the technical issues.