From owner-wrec@cs.utk.edu Fri Feb 4 05:46:50 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21578 for ; Fri, 4 Feb 2000 05:46:49 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id FAA12808; Fri, 4 Feb 2000 05:38:43 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Fri, 4 Feb 2000 05:38:43 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id FAA12789; Fri, 4 Feb 2000 05:38:43 -0500 (EST) Received: from ada.cs.ucy.ac.cy (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id FAA12736; Fri, 4 Feb 2000 05:37:28 -0500 (EST) Received: from ada.cs.ucy.ac.cy (194.42.10.200 -> ada.cs.ucy.ac.cy) by CS.UTK.EDU (smtpshim v1.0); Fri, 4 Feb 2000 05:37:29 -0500 Received: from cs099 (cs099.cs.ucy.ac.cy [194.42.10.211]) by ada.cs.ucy.ac.cy (8.8.8/8.8.8) with SMTP id MAA33184; Fri, 4 Feb 2000 12:40:13 +0200 Message-ID: <016801bf6efc$637a8110$d30a2ac2@cs.ucy.ac.cy> From: "Andreas Pitsillides" To: Subject: IEEE INFOCOM 2001 Call for participation Date: Fri, 4 Feb 2000 12:40:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 List-Unsubscribe: Content-Transfer-Encoding: 7bit ---------------------------------<>----------------------------------- The 20th Annual Conference of IEEE Communications and Computer Societies C A L L F O R P A P E R S I E E E I N F O C O M 2 0 0 1 The Conference on Computer Communications "20 Years into the Communications Odyssey" http://www.ieee-infocom.org/2001 April 22-26, 2001 - Anchorage, Alaska Sponsored by the IEEE Communications and Computer Societies CALL FOR PAPERS ================ The major conference on computer communications and networking is celebrating its 20th anniversary in the splendid setting of Anchorage (Alaska) during the week of April 22-26. The conference will bring together researchers and practitioners of every aspect of digital communications and networks, presenting the most up-to-date results and achievements in these fields. The IEEE INFOCOM 2001 program committee is soliciting original papers describing state-of-the-art research and development in all areas of computer networking and data communications. Topics of interest include, but are not limited to, the following: BISDN and ATM Network management and control Billing and pricing Network measurements and testbeds Communication protocols Protocol design and analysis Congestion and admission control Quality of service Flow control Queueing theory Cryptography, information hiding Scheduling Internet and web applications Security and privacy Optical networks Storage area networks Mobile networks Switching and switch architectures Multicast Traffic management and control Multimedia Routing Multiple access Web performance and caching Network architectures Wireless networks PAPER SUBMISSION ================ Papers must be submitted electronically according to the instructions described in and summarized below. Proposals for panels, half- or full-day tutorials should be submitted to the respective chairs. Please refer to the conference web site for further details. Papers must be formatted according to the IEEE standard format except for the font size, which MUST be 11pt. To make it easy to adhere to the formatting standard, we offer templates and samples for LaTex, MSWord, and FrameMaker (please refer to the pertinent web pages at ). ------------------------------------------------------------------- PAPERS THAT DO NOT COMPLY TO THE ABOVE FORMAT CANNOT BE REVIEWED ------------------------------------------------------------------- Submissions must be in PDF or Postscript. Postscript papers must use only standard PostScript fonts: Times Roman, Courier, Symbol, and Helvetica. (Please note that Postscript output from MSWord typically does not work on non-Microsoft platforms. The use of the Apple LaserWriter II printer driver is strongly recommended). The above formatted papers can be submitted in a compressed form (gzip, zip, WinZip, compress). Because of the size limitation on the final manuscript, and to ensure that the reviewed paper and the final version have a similar size, ----------------------------------------------------- PAPERS WITH MORE THAN 11 PAGES CANNOT BE REVIEWED ----------------------------------------------------- (this is roughly equivalent to 20 double-spaced pages). Papers must be submitted electronically using the Web site at . This web page contains exact and detailed instructions about the submission process. Author's contact information must be provided during submission. To save space, authors may omit this information from the paper itself. Authors will receive an immediate notification of the successful receipt of the file containing their paper. Subsequently, a formal notification will be sent after verifying that the paper can be printed successfully. ------------------------------------------------------------------------- | SUBMISSIONS WILL ONLY BE ACCEPTED BETWEEN MAY 1ST AND JULY 5TH, 2000. | ------------------------------------------------------------------------- SUBMISSION DEADLINES ARE STRICT! PAPERS THAT HAVE BEEN IMPROPERLY SUBMITTED OR IMPROPERLY FORMATTED BY THE SUBMISSION DEADLINE WILL NOT BE CONSIDERED. TO AVOID LAST MINUTE PROBLEMS, AUTHORS ARE ENCOURAGED TO SUBMIT THEIR PAPERS WELL IN ADVANCE OF THE DEADLINE. THE REVIEW PROCESS ================== Each paper will typically be reviewed by three independent reviewers, whose reviews will be relayed to the corresponding author. Following last year successful experiment, authors will have a chance to provide a limited rebuttal on the reviews before the program committee makes its final decision. TRAVEL GRANTS ============= Limited travel assistance to students, post-docs and junior faculty presenting a paper in the conference will be available. Please refer to the conference web site for further details. IMPORTANT DATES =============== Complete paper due July 5, 2000 Notification of acceptance October 31, 2000 Final version due December 31, 2000 PROGRAM COMMITTEE CO-CHAIRS [infocom@watson.ibm.com] =========================== Rene L. Cruz, UCSD Giovanni Pacifici, IBM Research From owner-wrec@cs.utk.edu Mon Feb 7 13:04:18 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17687 for ; Mon, 7 Feb 2000 13:04:18 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id MAA25477; Mon, 7 Feb 2000 12:56:29 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Mon, 7 Feb 2000 12:56:29 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id MAA25456; Mon, 7 Feb 2000 12:56:28 -0500 (EST) Received: from mailhost.iprg.nokia.com (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id MAA25414; Mon, 7 Feb 2000 12:56:09 -0500 (EST) Received: from mailhost.iprg.nokia.com (205.226.5.12 -> mailhost.iprg.nokia.com) by CS.UTK.EDU (smtpshim v1.0); Mon, 7 Feb 2000 12:56:11 -0500 Received: from aspen.iprg.nokia.com ([205.226.14.73]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id JAA29509 for ; Mon, 7 Feb 2000 09:55:54 -0800 (PST) From: Fred Bauer Received: (fred@localhost) by aspen.iprg.nokia.com (8.8.8/8.6.12) id JAA00427 for webrepl@cs.utk.edu; Mon, 7 Feb 2000 09:55:53 -0800 (PST) Date: Mon, 7 Feb 2000 09:55:53 -0800 (PST) Message-Id: <200002071755.JAA00427@aspen.iprg.nokia.com> To: webrepl@cs.utk.edu Subject: INFOCOM 2000 Call For Participation List-Unsubscribe: CALL FOR PARTICIPATION ------------------------ IEEE Infocom 2000 (Israel) http://www.comnet.technion.ac.il/infocom2000 (U.S.A.) http://www.cse.ucsc.edu/~rom/infocom2000 (Japan) http://halo.kuamp.kyoto-u.ac.jp/~infocom Dan Panorama Hotel, Tel Aviv, Israel March 26-30, 2000 Sponsored by the IEEE Communications and Computer Societies IMPORTANT ========= Early registration cut-off date: February 28, 2000 (only 3 more weeks) Registration fees for an IEEE member prior to February 28, 2000 will be $500 and it will include all technical sessions, open receptions, proceedings (CD) and three lunches. For other fees consult the web pages. On-line registration: https://secure.computer.org/conf/infocom/register.htm VENUE ===== For the last 18 years, Infocom has been the major conference on computer communications and networking, bringing together researchers and implementors of every aspect of data communications and networks presenting the most up-to-date results and achievements in the field. The 19th annual conference on Computer Communications, Infocom 2000, will be held at the Dan Panorama Hotel in Tel-Aviv, Israel, during the week of March 26-30, 2000. Overlooking the Mediterranean, the Dan Panorama Tel Aviv is a city hotel in a resort setting. Just a few steps away are fine shops, theaters, restaurants and the corporate world of Tel Aviv, contrasted by the ancient port city of Jaffa with its picturesque corners and flea markets for bargain hunters. The hotel features a large swimming pool, beach access and a fully equipped health & fitness center. SCOPE ===== Original papers and panel discussions describing state-of-the-art research and development in all areas of computer networking and data communications will be presented. Browse the excellent technical program and see the papers at http://www.comnet.technion.ac.il/infocom2000/program.html KEYNOTE SPEAKER =============== Prof. Leonard Kleinrock, Chairman, Nomadix, Inc. Keynote title: Nomadic Computing and Smart Spaces http://www.comnet.technion.ac.il/infocom2000/key.html TUTORIALS ========= Full Day -------- - Wavelength-routing optical networks (Kumar Sivarajan, Indian Institute of Science) - The evolution of QoS in the Internet standards community (Jon Crowcroft, University College London) - Overview of network security (Radia Perlman, Sun Microsystems) - Teletraffic Models and Tools: From Basics to Advanced(Khosrow Sohraby, University of Missouri, Kansas City) - IP Multicast: past, present and future (Radia Perlman, Sun Microsystems & Christophe Diot, Sprint) Half Day -------- - MPLS (Loa Andersson, Nortel Networks) - New technologies for LAN systems (Dono Van-Mierop, IBM Israel) - Satellite IP networking (Catherine Rosenberg, Purdue University) - Mobile IP: adding mobility to the Internet (Charles Perkins, Nokia Research) http://www.comnet.technion.ac.il/infocom2000/tutorial.html QUESTIONS? =========================== Write to infocom@comnet.technion.ac.il] From owner-wrec@cs.utk.edu Mon Feb 7 17:45:12 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23522 for ; Mon, 7 Feb 2000 17:45:09 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id RAA24082; Mon, 7 Feb 2000 17:40:43 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Mon, 7 Feb 2000 17:40:43 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id RAA24062; Mon, 7 Feb 2000 17:40:42 -0500 (EST) Received: from ircache.net (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id RAA24043; Mon, 7 Feb 2000 17:40:41 -0500 (EST) Received: from ircache.net (192.52.106.29 -> ack.ircache.net) by CS.UTK.EDU (smtpshim v1.0); Mon, 7 Feb 2000 17:40:41 -0500 Received: from surf.ircache.net (surf.scd.ucar.edu [128.117.28.53]) by ircache.net (8.8.6/8.8.6) with ESMTP id OAA10736; Mon, 7 Feb 2000 14:40:39 -0800 (PST) Received: from localhost (wessels@localhost) by surf.ircache.net (8.8.6/8.8.6) with ESMTP id PAA15092; Mon, 7 Feb 2000 15:40:09 -0700 (MST) Date: Mon, 7 Feb 2000 15:40:09 -0700 From: Duane Wessels To: squid-users@ircache.net, ircache@ircache.net, isp-caching@isp-caching.com, wrec@cs.utk.edu Subject: Reminder: Call for Papers for the Web Caching and Content Delivery Workshop Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: The Fifth International Web Caching and Content Delivery Workshop will be held at the National Laboratory of Civil Engineering (LNEC) in Lisbon, Portugal from 22-24 May 2000 in parallel to the TERENA Conference. Further information about the workshop is available at http://www.terena.nl/conf/wcw/ The deadline for paper submission is 20 February 2000. Full papers should be sent to Valentino Cavalli at TERENA . The text of the Call for Papers is published at http://www.terena.nl/conf/wcw/cfp.html All accepted papers will be presented at the workshop and will be published in the proceedings of the workshop, which will appear as a Special Issue of the international journal "Computer Communications" published by Elsevier Science publishers. Valentino Cavalli From owner-wrec@cs.utk.edu Tue Feb 8 08:28:25 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18984 for ; Tue, 8 Feb 2000 08:28:25 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id IAA19203; Tue, 8 Feb 2000 08:24:02 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Tue, 8 Feb 2000 08:24:02 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id IAA19185; Tue, 8 Feb 2000 08:24:02 -0500 (EST) Received: from p-voyageur.issy.cnet.fr (marvin@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id IAA19134; Tue, 8 Feb 2000 08:23:28 -0500 (EST) Received: from p-voyageur.issy.cnet.fr (139.100.0.39 -> p-voyageur.issy.cnet.fr) by CS.UTK.EDU (smtpshim v1.0); Tue, 8 Feb 2000 08:23:30 -0500 Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id <1F2281AV>; Tue, 8 Feb 2000 14:24:21 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D820A8DF2@lat3721.lannion.cnet.fr> From: LOVRIC Ivan CNET/DMI/CAE To: Ingrid.Melve@uninett.no Cc: wrec@cs.utk.edu Subject: Taxonomy about CDNs Date: Tue, 8 Feb 2000 14:23:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" List-Unsubscribe: Hi Ingrid, The mailing list is somewhat quiet since january. For the next IETF, I suggest to add CDN considerations to the taxonomy draft. Vendors like Akamai, Adero, Sandpiper use caches and/or mirrors to deliver content. At present, it is still difficult to see if CDN vendors use proprietary or standard protocols. Also, it is not easy to define exactly what are the boundaries of content delivery. That is why, IMO, CDNs are in the scope of the WREC WG, and therefore appropriate taxonomy should be defined. Do you agree with that proposal ? From owner-wrec@cs.utk.edu Wed Feb 9 12:17:52 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11247 for ; Wed, 9 Feb 2000 12:17:50 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id MAA21960; Wed, 9 Feb 2000 12:12:26 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Wed, 9 Feb 2000 12:12:26 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id MAA21942; Wed, 9 Feb 2000 12:12:26 -0500 (EST) Received: from anchor-post-31.mail.demon.net (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id MAA21918; Wed, 9 Feb 2000 12:12:19 -0500 (EST) Received: from anchor-post-31.mail.demon.net (194.217.242.89 -> anchor-post-31.mail.demon.net) by CS.UTK.EDU (smtpshim v1.0); Wed, 9 Feb 2000 12:12:19 -0500 Received: from alethea.demon.co.uk ([194.222.10.198] helo=IAN-NTLAP) by anchor-post-31.mail.demon.net with smtp (Exim 2.12 #1) id 12Iaf3-0005v7-0V; Wed, 9 Feb 2000 17:12:17 +0000 From: Ian Cooper To: LOVRIC Ivan CNET/DMI/CAE Cc: wrec@cs.utk.edu Subject: Re: Taxonomy about CDNs Date: Wed, 09 Feb 2000 17:12:13 +0000 Organization: Mirror Image Internet Message-ID: References: <91A311FF6A85D3118DDF0060080C3D820A8DF2@lat3721.lannion.cnet.fr> In-Reply-To: <91A311FF6A85D3118DDF0060080C3D820A8DF2@lat3721.lannion.cnet.fr> X-Mailer: Forte Agent 1.7/32.534 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit On Tue, 8 Feb 2000 14:23:02 +0100 , LOVRIC Ivan CNET/DMI/CAE wrote: >For the next IETF, I suggest to add CDN considerations to the taxonomy >draft. > >Vendors like Akamai, Adero, Sandpiper use caches and/or mirrors to deliver >content. >At present, it is still difficult to see if CDN vendors use proprietary or >standard protocols. Also, it is not easy to define exactly what are the >boundaries of content delivery. >That is why, IMO, CDNs are in the scope of the WREC WG, and therefore >appropriate taxonomy should be defined. Do you mean the taxonomy? (Or am I just totally brain dead today?) Section 5 of the taxonomy describes inter-replica communication (I need to go back and see what wording it uses to check that we're covered for things like "Master Origin Server"), and 3.1.1 describes client-replica communication. While I agree that the discussion of CDNs, and the protocols that are used to distribute content among replicas, is useful, I'm not sure that this belongs in the taxonomy itself. From owner-wrec@cs.utk.edu Wed Feb 9 15:56:09 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23293 for ; Wed, 9 Feb 2000 15:56:08 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id PAA11251; Wed, 9 Feb 2000 15:51:42 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Wed, 9 Feb 2000 15:51:42 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id PAA11233; Wed, 9 Feb 2000 15:51:41 -0500 (EST) Received: from prv-mail20.provo.novell.com (marvin@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id PAA11198; Wed, 9 Feb 2000 15:51:35 -0500 (EST) Received: from prv-mail20.provo.novell.com (137.65.82.195 -> prv-mail20.provo.novell.com) by CS.UTK.EDU (smtpshim v1.0); Wed, 9 Feb 2000 15:51:36 -0500 Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 09 Feb 2000 13:51:16 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Wed, 09 Feb 2000 13:51:11 -0700 From: "Gary Tomlinson" To: , Cc: Subject: Re: Taxonomy about CDNs Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA23293 I agree with Ian's assessment that CDN's are little out of scope for the Taxonomy. My reasoning here is, the ones's I'm familair with use a combination of open protocols and some proprietary protocols and algorithms to make them work. The CDN's I've worked with gaurd thier "secret sauce" proprietary value adds as they see these are core differentiators today. So, I would find it hard to document them in taxonomy given the proprietary constraints. The whole concept of the taxonomy is a little difficult to capture accurately at any point in time. We've done a good job of capturing the caching and replication space as it existed in the first half of 1999. In order to get the document published, we need to have a sunset on it. This of course leads to the need for WREC to define its future with respect to taxonomies. We may want to consider producing a new version over the next year that emcompasses the last 12-18 months in this space, including CDN's (with help from some of the CDN's). Gary >>> Ian Cooper 02/09/00 10:12AM >>> On Tue, 8 Feb 2000 14:23:02 +0100 , LOVRIC Ivan CNET/DMI/CAE wrote: >For the next IETF, I suggest to add CDN considerations to the taxonomy >draft. > >Vendors like Akamai, Adero, Sandpiper use caches and/or mirrors to deliver >content. >At present, it is still difficult to see if CDN vendors use proprietary or >standard protocols. Also, it is not easy to define exactly what are the >boundaries of content delivery. >That is why, IMO, CDNs are in the scope of the WREC WG, and therefore >appropriate taxonomy should be defined. Do you mean the taxonomy? (Or am I just totally brain dead today?) Section 5 of the taxonomy describes inter-replica communication (I need to go back and see what wording it uses to check that we're covered for things like "Master Origin Server"), and 3.1.1 describes client-replica communication. While I agree that the discussion of CDNs, and the protocols that are used to distribute content among replicas, is useful, I'm not sure that this belongs in the taxonomy itself. From owner-wrec@cs.utk.edu Mon Feb 14 18:42:50 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26524 for ; Mon, 14 Feb 2000 18:42:49 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id SAA01690; Mon, 14 Feb 2000 18:37:51 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Mon, 14 Feb 2000 18:37:51 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id SAA01666; Mon, 14 Feb 2000 18:37:51 -0500 (EST) Received: from astro.cs.utk.edu (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id SAA01650; Mon, 14 Feb 2000 18:37:50 -0500 (EST) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by CS.UTK.EDU (smtpshim v1.0); Mon, 14 Feb 2000 18:37:50 -0500 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id SAA00271; Mon, 14 Feb 2000 18:37:05 -0500 (EST) Message-Id: <200002142337.SAA00271@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: apps area chairs and working groups:; cc: ietf@ietf.org reply-to: ietf@ietf.org From: Keith Moore Subject: IETF Adelaide and interim meetings for APPS WGs Date: Mon, 14 Feb 2000 18:37:05 -0500 Sender: moore@cs.utk.edu List-Unsubscribe: It has come to the attention of the Applications Area Directors that one or more Applications area working groups have elected to not meet in Adelaide, and instead to hold an "interim meeting" in the United States, presumably because of distance and/or cost issues. IETF is an international organization, and it is IETF's longstanding practice to hold its meetings in various locations around the planet. This serves both to encourage wider participation in IETF and also to more fairly distribute travel costs and inconvenience (over time) among all participants. The scheduleing of an interim WG meeting in the US in lieu of a WG meeting in Adelaide undermines this policy. This is insulting to non-US participants of IETF (many of whom have attended meetings in the US for years), embarassing to IETF as a whole, and a threat to IETF's international stature. Even if a working group has few participants outside the United States, a working group does not work in isolation from other working groups. Attendance at IETF meetings is an invaluable mechanism for cross-group collaboration. RFC 2418 states: Interim meetings are subject to the same rules for advance notification, reporting, open participation, and process, which apply to other working group meetings. Since normal working group meetings require advance notification via email to the entire IETF list, and the process for getting a meeting slot involves prior approval of the Area Directors, the same requirements apply to interim working group meetings. Part of the reason for prior approval being required is to ensure that the locations of the meetings are not being chosen to favor certain participants over others. There have been several violations of this policy since publication of RFC 2418. Therefore, - All interim meetings within the Applications Area which were not previously and explicitly approved by the Applications Area Directors, are hereby cancelled. - No Applications Area group will hold any interim meeting prior to April 15. - No Applications Area group which does not hold a meeting in Adelaide, will hold any interim meeting prior to July 31. (i.e. prior to the Pittsburg IETF meeting) - This applies to all face to face meetings held for the purpose of conducting working group discussion and to which the working group is invited, even if labelled "informal" or otherwise labelled to distinguish them from official working group meetings. - Exceptions to this policy may be made for recently chartered groups, but Area Director approval is still required for such groups to schedule interim meetings. for the Applications Area Directors, Keith Moore From owner-wrec@cs.utk.edu Tue Feb 15 09:28:57 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03815 for ; Tue, 15 Feb 2000 09:28:57 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id JAA28190; Tue, 15 Feb 2000 09:24:17 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Tue, 15 Feb 2000 09:24:17 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id JAA28172; Tue, 15 Feb 2000 09:24:16 -0500 (EST) Received: from p-voyageur.issy.cnet.fr (marvin@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id JAA28155; Tue, 15 Feb 2000 09:23:57 -0500 (EST) Received: from p-voyageur.issy.cnet.fr (139.100.0.39 -> p-voyageur.issy.cnet.fr) by CS.UTK.EDU (smtpshim v1.0); Tue, 15 Feb 2000 09:23:58 -0500 Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id <1F220GX8>; Tue, 15 Feb 2000 15:25:28 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D820A8E0E@lat3721.lannion.cnet.fr> From: LOVRIC Ivan CNET/DMI/CAE To: "'Gary Tomlinson'" , ian@mirror-image.com Cc: wrec@cs.utk.edu Subject: RE: Taxonomy about CDNs Date: Tue, 15 Feb 2000 15:23:24 +0100 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 JAA03815 It is the goal of the taxonomy to describe the current practice related to cache and replication. IMO, CDNs should already be considered as a current practice, though they use proprietary protocols; so they are in the scope of the taxonomy. Nevertheless, I agree with you : this item did not exist in the first half of 1999, and it should be mentionned only in a next version of the taxonomy, if the WG wants to work on that topic. -----Message d'origine----- De: Gary Tomlinson [mailto:GARYT@novell.com] Date: mercredi 9 février 2000 21:51 À: ivan.lovric@cnet.francetelecom.fr; ian@mirror-image.com Cc: wrec@cs.utk.edu Objet: Re: Taxonomy about CDNs I agree with Ian's assessment that CDN's are little out of scope for the Taxonomy. My reasoning here is, the ones's I'm familair with use a combination of open protocols and some proprietary protocols and algorithms to make them work. The CDN's I've worked with gaurd thier "secret sauce" proprietary value adds as they see these are core differentiators today. So, I would find it hard to document them in taxonomy given the proprietary constraints. The whole concept of the taxonomy is a little difficult to capture accurately at any point in time. We've done a good job of capturing the caching and replication space as it existed in the first half of 1999. In order to get the document published, we need to have a sunset on it. This of course leads to the need for WREC to define its future with respect to taxonomies. We may want to consider producing a new version over the next year that emcompasses the last 12-18 months in this space, including CDN's (with help from some of the CDN's). Gary >>> Ian Cooper 02/09/00 10:12AM >>> On Tue, 8 Feb 2000 14:23:02 +0100 , LOVRIC Ivan CNET/DMI/CAE wrote: >For the next IETF, I suggest to add CDN considerations to the taxonomy >draft. > >Vendors like Akamai, Adero, Sandpiper use caches and/or mirrors to deliver >content. >At present, it is still difficult to see if CDN vendors use proprietary or >standard protocols. Also, it is not easy to define exactly what are the >boundaries of content delivery. >That is why, IMO, CDNs are in the scope of the WREC WG, and therefore >appropriate taxonomy should be defined. Do you mean the taxonomy? (Or am I just totally brain dead today?) Section 5 of the taxonomy describes inter-replica communication (I need to go back and see what wording it uses to check that we're covered for things like "Master Origin Server"), and 3.1.1 describes client-replica communication. While I agree that the discussion of CDNs, and the protocols that are used to distribute content among replicas, is useful, I'm not sure that this belongs in the taxonomy itself. From owner-wrec@cs.utk.edu Tue Feb 15 16:51:40 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24686 for ; Tue, 15 Feb 2000 16:51:40 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id QAA08396; Tue, 15 Feb 2000 16:46:18 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Tue, 15 Feb 2000 16:46:18 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id QAA08378; Tue, 15 Feb 2000 16:46:18 -0500 (EST) Received: from dhcp3-53.west.akamai.com (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id QAA08365; Tue, 15 Feb 2000 16:46:12 -0500 (EST) Received: from dhcp3-53.west.akamai.com (63.196.237.2 -> fw.west.akamai.com) by CS.UTK.EDU (smtpshim v1.0); Tue, 15 Feb 2000 16:46:13 -0500 Received: by dhcp3-53.west.akamai.com (Postfix, from userid 20351) id C0B905010; Tue, 15 Feb 2000 13:47:28 -0800 (PST) Date: Tue, 15 Feb 2000 13:47:28 -0800 From: Mark Nottingham To: LOVRIC Ivan CNET/DMI/CAE Cc: "'Gary Tomlinson'" , ian@mirror-image.com, wrec@cs.utk.edu Subject: Re: Taxonomy about CDNs Message-ID: <20000215134727.A12333@akamai.com> References: <91A311FF6A85D3118DDF0060080C3D820A8E0E@lat3721.lannion.cnet.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 User-Agent: Mutt/1.1.2-current-20000114i In-Reply-To: <91A311FF6A85D3118DDF0060080C3D820A8E0E@lat3721.lannion.cnet.fr>; from ivan.lovric@cnet.francetelecom.fr on Tue, Feb 15, 2000 at 03:23:24PM +0100 List-Unsubscribe: X-MIME-Autoconverted: from 8bit to quoted-printable by CS.UTK.EDU id QAA08396 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA24686 The taxonomy defines 'surrogate origin server', which is what AFAIK most CDNs operate as. It also defines several mechanisms for inter-replica communication (i.e, between the master origin server and surrogates). Most CDNs will be using some form of demand-driven or batch replication - IMHO these definitions are general enough to catch current implementations. On Tue, Feb 15, 2000 at 03:23:24PM +0100, LOVRIC Ivan CNET/DMI/CAE wrote: > It is the goal of the taxonomy to describe the current practice related to > cache and replication. IMO, CDNs should already be considered as a current > practice, though they use proprietary protocols; so they are in the scope of > the taxonomy. > Nevertheless, I agree with you : this item did not exist in the first half > of 1999, and it should be mentionned only in a next version of the taxonomy, > if the WG wants to work on that topic. > > > -----Message d'origine----- > De: Gary Tomlinson [mailto:GARYT@novell.com] > Date: mercredi 9 février 2000 21:51 > À: ivan.lovric@cnet.francetelecom.fr; ian@mirror-image.com > Cc: wrec@cs.utk.edu > Objet: Re: Taxonomy about CDNs > > > I agree with Ian's assessment that CDN's are little out of scope for the > Taxonomy. My reasoning here is, the ones's I'm familair with use a > combination of open protocols and some proprietary protocols and algorithms > to make them work. The CDN's I've worked with gaurd thier "secret sauce" > proprietary value adds as they see these are core differentiators today. > So, I would find it hard to document them in taxonomy given the proprietary > constraints. > > The whole concept of the taxonomy is a little difficult to capture > accurately at any point in time. We've done a good job of capturing the > caching and replication space as it existed in the first half of 1999. In > order to get the document published, we need to have a sunset on it. This > of course leads to the need for WREC to define its future with respect to > taxonomies. We may want to consider producing a new version over the next > year that emcompasses the last 12-18 months in this space, including CDN's > (with help from some of the CDN's). > > Gary > > >>> Ian Cooper 02/09/00 10:12AM >>> > On Tue, 8 Feb 2000 14:23:02 +0100 , LOVRIC Ivan CNET/DMI/CAE wrote: > > >For the next IETF, I suggest to add CDN considerations to the taxonomy > >draft. > > > >Vendors like Akamai, Adero, Sandpiper use caches and/or mirrors to deliver > >content. > >At present, it is still difficult to see if CDN vendors use proprietary or > >standard protocols. Also, it is not easy to define exactly what are the > >boundaries of content delivery. > >That is why, IMO, CDNs are in the scope of the WREC WG, and therefore > >appropriate taxonomy should be defined. > > Do you mean the taxonomy? (Or am I just totally brain dead today?) > > Section 5 of the taxonomy describes inter-replica communication (I > need to go back and see what wording it uses to check that we're > covered for things like "Master Origin Server"), and 3.1.1 describes > client-replica communication. > > > While I agree that the discussion of CDNs, and the protocols that are > used to distribute content among replicas, is useful, I'm not sure > that this belongs in the taxonomy itself. -- Mark Nottingham, Senior Developer Akamai Technologies (San Mateo, CA) From owner-wrec@cs.utk.edu Sat Feb 19 10:52:09 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25620 for ; Sat, 19 Feb 2000 10:52:08 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id KAA28546; Sat, 19 Feb 2000 10:47:12 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Sat, 19 Feb 2000 10:47:12 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id KAA28528; Sat, 19 Feb 2000 10:47:12 -0500 (EST) Received: from metis.mirror-image.co.uk (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id KAA28507; Sat, 19 Feb 2000 10:47:03 -0500 (EST) Received: from metis.mirror-image.co.uk (194.205.172.68 -> mail.mirror-image.co.uk) by CS.UTK.EDU (smtpshim v1.0); Sat, 19 Feb 2000 10:47:03 -0500 Received: from IAN-NTLAP (alethea.demon.co.uk [194.222.10.198]) by metis.mirror-image.co.uk (8.9.3/8.9.3) with SMTP id PAA07571; Sat, 19 Feb 2000 15:43:29 GMT From: Ian Cooper To: wrec@cs.utk.edu Cc: Gary Tomlinson , Ingrid Melve , Ian Cooper Subject: draft-ietf-wrec-taxonomy-03b.txt Date: Sat, 19 Feb 2000 15:46:48 +0000 Organization: Mirror Image Internet Message-ID: X-Mailer: Forte Agent 1.7/32.534 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--=_8netas4upavf7mttb0vkpcj6mrabmk6k34.MFSBCHJLHS" List-Unsubscribe: ----=_8netas4upavf7mttb0vkpcj6mrabmk6k34.MFSBCHJLHS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This is the modified version renaming "network transparent proxy" to "interception proxy" (plus a few other tweaks from Patrick McManus and others). Please let me know if the brief explanation in the definition of this term is sufficient, and whether I've missed updating any of the references later in the document. I've become very aware that we're citing quite a few expired drafts for some fairly important stuff. WCCP and WPAD are probably the most important, but if there's any chance of the CARP draft being updated that'd be good useful. I think Ivan's draft has also expired. Please take a look, and if we're citing something that you (co)authored and it has or is about to expire please do something about it. ----=_8netas4upavf7mttb0vkpcj6mrabmk6k34.MFSBCHJLHS Content-Type: text/plain; charset=us-ascii; name=draft-ietf-wrec-taxonomy-03b.txt Content-Disposition: attachment; filename=draft-ietf-wrec-taxonomy-03b.txt Content-Transfer-Encoding: 7bit Network Working Group I. Cooper Internet-Draft Mirror Image Expires: August 19, 2000 I. Melve UNINETT G. Tomlinson Novell February 19, 2000 Internet Web Replication and Caching Taxonomy draft-ietf-wrec-taxonomy-03.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 19, 2000. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo specifies standard terminology and the current taxonomy of web replication and caching infrastructure deployed today. It introduces standard concepts and protocols used today within this application domain. Currently deployed solutions employing these technologies are presented to establish a standard taxonomy. Known problems with caching proxies are covered in an accompanying document[22], and are not part of this document. This document presents open protocols and points to published material for each protocol. Cooper, et. al. Expires August 19, 2000 [Page 1] Internet-Draft WREC Taxonomy February 2000 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Base Terms . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 First order derivative terms . . . . . . . . . . . . . . . 7 2.3 Second order derivatives . . . . . . . . . . . . . . . . . 7 2.4 Topological terms . . . . . . . . . . . . . . . . . . . . 8 2.5 Automatic use of proxies . . . . . . . . . . . . . . . . . 8 3. Distributed System Relationships . . . . . . . . . . . . . 10 3.1 Replication Relationships . . . . . . . . . . . . . . . . 10 3.1.1 Client to Replica . . . . . . . . . . . . . . . . . . . . 10 3.1.2 Inter-Replica . . . . . . . . . . . . . . . . . . . . . . 10 3.2 Proxy Relationships . . . . . . . . . . . . . . . . . . . 11 3.2.1 Client to Non-Interception Proxy . . . . . . . . . . . . . 11 3.2.2 Surrogate to Origin Server . . . . . . . . . . . . . . . . 11 3.2.3 Inter-Proxy . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.3.1 (Caching) Proxy Meshes . . . . . . . . . . . . . . . . . . 12 3.2.3.2 (Caching) Proxy Clusters . . . . . . . . . . . . . . . . . 13 3.2.4 Network Element to Caching Proxy . . . . . . . . . . . . . 13 4. Client to Replica Communication . . . . . . . . . . . . . 15 4.1 Navigation Hyperlinks . . . . . . . . . . . . . . . . . . 15 4.2 URL Redirection . . . . . . . . . . . . . . . . . . . . . 15 4.3 DNS Redirection . . . . . . . . . . . . . . . . . . . . . 16 5. Inter-Replica Communication . . . . . . . . . . . . . . . 17 5.1 Batch Driven Replication . . . . . . . . . . . . . . . . . 17 5.2 Demand Driven Replication . . . . . . . . . . . . . . . . 17 5.3 Synchronized Replication . . . . . . . . . . . . . . . . . 18 6. Client to Proxy Configuration . . . . . . . . . . . . . . 19 6.1 Manual Proxy Configuration . . . . . . . . . . . . . . . . 19 6.2 Proxy Auto Configuration (PAC) . . . . . . . . . . . . . . 19 6.3 Cache Array Routing Protocol (CARP) v1.0 . . . . . . . . . 20 6.4 Web Proxy Auto-Discovery Protocol (WPAD) . . . . . . . . . 20 7. Inter-Proxy Communication . . . . . . . . . . . . . . . . 22 7.1 Loosely coupled Inter-Proxy Communication . . . . . . . . 22 7.1.1 Internet Cache Protocol (ICP) . . . . . . . . . . . . . . 22 7.1.2 Hyper Text Caching Protocol . . . . . . . . . . . . . . . 22 7.1.3 Cache Digest . . . . . . . . . . . . . . . . . . . . . . . 23 7.1.4 Cache Pre-filling . . . . . . . . . . . . . . . . . . . . 24 7.2 Tightly Coupled Inter-Cache Communication . . . . . . . . 24 7.2.1 Cache Array Routing Protocol (CARP) v1.0 . . . . . . . . . 25 8. Network Element Communication . . . . . . . . . . . . . . 26 8.1 Web Cache Control Protocol (WCCP) . . . . . . . . . . . . 26 8.2 Network Element Control Protocol (NECP) . . . . . . . . . 26 8.3 SOCKS . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9. Security Considerations . . . . . . . . . . . . . . . . . 28 9.1 Authentication . . . . . . . . . . . . . . . . . . . . . . 28 9.1.1 Man in the middle attacks . . . . . . . . . . . . . . . . 28 9.1.2 Trusted third party . . . . . . . . . . . . . . . . . . . 28 Cooper, et. al. Expires August 19, 2000 [Page 2] Internet-Draft WREC Taxonomy February 2000 9.1.3 Authentication based on IP number . . . . . . . . . . . . 29 9.2 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.2.1 Trusted third party . . . . . . . . . . . . . . . . . . . 29 9.2.2 Logs and legal implications . . . . . . . . . . . . . . . 29 9.3 Service security . . . . . . . . . . . . . . . . . . . . . 30 9.3.1 Denial of service . . . . . . . . . . . . . . . . . . . . 30 9.3.2 Replay attack . . . . . . . . . . . . . . . . . . . . . . 30 9.3.3 Stupid configuration of proxies . . . . . . . . . . . . . 30 9.3.4 Copyrighted transient copies . . . . . . . . . . . . . . . 30 9.3.5 Application level access . . . . . . . . . . . . . . . . . 30 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 31 References . . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 33 Full Copyright Statement . . . . . . . . . . . . . . . . . 35 Cooper, et. al. Expires August 19, 2000 [Page 3] Internet-Draft WREC Taxonomy February 2000 1. Introduction Since its introduction in 1990, the World-Wide Web has evolved from a simple client server model into a sophisticated distributed architecture. This evolution has been driven largely due to the scaling problems associated with exponential growth. Distinct paradigms and solutions have emerged to satisfy specific requirements. Two core infrastructure components being employed to meet the demands of this growth are replication and caching. In many cases, there is a need for web caches and replicated services to be able to coexist. There are many protocols, both open and proprietary, employed in web replication and caching today. A majority of the open protocols include DNS[13], Cache Digests [15][17], CARP[4], HTTP[1], ICP[5], PAC[2], SOCKS[12], WPAD[3], and WCCP[11]. Additional protocols are being planned to address emerging solution requirements. This memo specifies standard terminology and the taxonomy of web replication and caching infrastructure deployed in the Internet today. The principal goal of this document is to establish a common understanding and reference point of this application domain. We also expect that this document will be used in the creation of a standard architectural framework for efficient, reliable, and predictable service in a web which includes both replicas and caches. Cooper, et. al. Expires August 19, 2000 [Page 4] Internet-Draft WREC Taxonomy February 2000 2. Terminology The following terminology provides definitions of common terms used within the web replication and caching community. Base terms are taken, where possible, from the HTTP/1.1 specification[1] and are included here for reference. First- and second-order derivatives are constructed from these base terms to help define the relationships that exist within this area. Terms that are in common usage and which are contrary to the definitions in RFC2616 and this document are highlighted. 2.1 Base Terms The majority of these terms are taken as-is from RFC 2616[1], and are included here for reference. client (as given in [1]) A program that establishes connections for the purpose of sending requests. server (as given in [1]) An application program that accepts connections in order to service requests by sending back responses. Any given program may be capable of being both a client and a server; our use of these terms refers only to the role being performed by the program for a particular connection, rather than to the program's capabilities in general. Likewise, any server may act as an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request. proxy (as given in [1]) An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, with possible translation, to other servers. A proxy MUST implement both the client and server requirements of this specification. A "transparent proxy" is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification. A "non-transparent proxy" is a proxy that modifies the request or response in order to provide some added service to the user agent, such as group annotation services, media type transformation, protocol reduction, or anonymity filtering. Except where either transparent or non-transparent behavior is explicitly stated, the HTTP proxy requirements apply to both types of proxies. Note: The term "transparent proxy" refers to a semantically transparent proxy as described in [1], not what is commonly Cooper, et. al. Expires August 19, 2000 [Page 5] Internet-Draft WREC Taxonomy February 2000 understood within the caching community. We recommend that the term "transparent proxy" is always prefixed to avoid confusion (e.g. "network transparent proxy"). However, see definition of "interception proxy" below. The above condition requiring implementation of both the server and client requirements of HTTP/1.1 is only appropriate for a non-network transparent proxy. cache (as given in [1]) A program's local store of response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server may include a cache, though a cache cannot be used by a server that is acting as a tunnel. Note: The term "cache" used alone often is meant as "caching proxy". Note: There are additional motivations for caching, for example reducing server load (as a further means to reduce response time). cacheable (as given in [1]) A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests. The rules for determining the cacheability of HTTP responses are defined in section 13. Even if a resource is cacheable, there may be additional constraints on whether a cache can use the cached copy for a particular request. tunnel (as given in [1]) An intermediary program which is acting as a blind relay between two connections. Once active, a tunnel is not considered a party to the HTTP communication, though the tunnel may have been initiated by an HTTP request. The tunnel ceases to exist when both ends of the relayed connections are closed. replication (as given in [21]) Creating and maintaining a duplicate copy of a database or file system on a different computer, typically a server. inbound/outbound (as given in [1]) Inbound and outbound refer to the request and response paths for messages: "inbound" means "traveling toward the origin server", and "outbound" means "traveling toward the user agent". network element A network device that introduces multiple paths between source and destination, transparent to HTTP. Cooper, et. al. Expires August 19, 2000 [Page 6] Internet-Draft WREC Taxonomy February 2000 2.2 First order derivative terms The following terms are constructed taking the above base terms as foundation. origin server (as given in [1]) The server on which a given resource resides or is to be created. user agent (as given in [1]) The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user tools. caching proxy A proxy with a cache, acting as a server to clients, and a client to servers. Caching proxies are often referred to as "proxy caches" or simply "caches". The term "proxy" is also frequently misused when referring to caching proxies. surrogate (A.K.A. "reverse proxies", "web server accelerators") An intermediary program which acts as a server or tunnel for the purpose of responding to requests on behalf of one or more origin servers. Requests are serviced internally from a cache or by tunnelling them on to origin servers. The implementation requirements for surrogates have not been standardized; depending on the implementation, surrogates may or may not respond to the cache directives defined in [1]. Surrogates are also known as "reverse proxies" and "(origin) server accelerators". 2.3 Second order derivatives The following terms further build on first order derivatives: master origin server An origin server on which the definitive version of a resource resides. replica origin server An origin server holding a replica of a resource, but which may act as an authoritative reference for client requests. content consumer The user or system that initiates inbound requests, through use of a user agent. browser A special instance of a user agent that acts as a content presentation device for content consumers. Cooper, et. al. Expires August 19, 2000 [Page 7] Internet-Draft WREC Taxonomy February 2000 2.4 Topological terms The following definitions are added to describe caching device topology: user agent cache The cache within the user agent program. local caching proxy The caching proxy to which a user agent connects. intermediate caching proxy Seen from the content consumer's view, all caches participating in the caching mesh that are not the user agent's local caching proxy. cache server A server to requests made by local and intermediate caching proxies, but which does not act as a proxy. cache array A cluster of caching proxies, acting logically as one service and partitioning the resource name space across the array. Also known as "diffused array" or "cache cluster". caching mesh a loosely coupled set of co-operating proxy- and (optionally) caching-servers, or clusters, acting independently but sharing cacheable content between themselves using inter-cache communication protocols. 2.5 Automatic use of proxies Network administrators may wish to force or facilitate the use of proxies by clients, enabling such configuration within the network itself or within automatic systems in user agents, such that the content consumer need not be aware of any such configuration issues. The terms that describe such configurations are given below. automatic user-agent proxy configuration The technique of discovering the availability of one or more proxies and the automated configuration of the client to use them. The use of a proxy is transparent to the user but not to the client. The term "automatic proxy configuration" is also used in this sense. traffic interception The process of using a network element to examine network traffic Cooper, et. al. Expires August 19, 2000 [Page 8] Internet-Draft WREC Taxonomy February 2000 to determine whether it should be redirected. traffic redirection Redirection of client requests from a network element performing traffic interception to a proxy. Used to deploy (caching) proxies without the need to manually reconfigure individual user agents, or to force the use of a proxy where such use would not otherwise occur. interception proxy (A.K.A. "transparent proxy") The term "transparent proxy" has been used within the caching community to describe proxies used with no configuration within the client. Such use is somewhat transparent to clients. Due to discrepancies with [1] (see definition of "proxy" above), and objections to the use of the word "transparent", we introduce the term "interception proxy" to describe proxies that receive redirected traffic flows from network elements performing traffic interception. Interception proxies receive inbound traffic flows through the process of traffic redirection. (Such proxies are deployed by network administrators to facilitate or require the use of appropriate services offered by the proxy). Problems associated with the deployment of interception proxies are described in the companion document "Known HTTP Proxy/Caching Problems"[22]. The use of interception proxies requires zero configuration of the client, and the client acts as though it is communicating with an origin server. Cooper, et. al. Expires August 19, 2000 [Page 9] Internet-Draft WREC Taxonomy February 2000 3. Distributed System Relationships This section identifies the relationships that exist in a distributed replication and caching environment. Having defined these relationships, later sections describe the communication protocols used in each relationship. 3.1 Replication Relationships The following sections describe relationships between clients and replicas and between replicas themselves. 3.1.1 Client to Replica A client may communicate with one or more replica origin servers, as well as with master origin servers. (In the absence of replica servers the client interacts directly with the origin server as is the normal case.) ------------------ ----------------- ------------------ | Replica Origin | | Master Origin | | Replica Origin | | Server | | Server | | Server | ------------------ ----------------- ------------------ \ | / \ | / ----------------------------------------- | Client to ----------------- Replica Server | Client | ----------------- Protocols used to enable the client to use one of the replicas can be found in Section 4. 3.1.2 Inter-Replica This is the relationship between master origin server(s) and replica origin servers, to replicate data sets that are accessed by clients in the relationship shown in Section 3.1.1. ------------------ ----------------- ------------------ | Replica Origin |-----| Master Origin |-----| Replica Origin | | Server | | Server | | Server | ------------------ ----------------- ------------------ Protocols used in this relationship can be found in Section 5. Cooper, et. al. Expires August 19, 2000 [Page 10] Internet-Draft WREC Taxonomy February 2000 3.2 Proxy Relationships There are a variety of ways in which (caching) proxies and cache servers communicate with each other, and with clients. 3.2.1 Client to Non-Interception Proxy A client may communicate with zero or more proxies for some or all requests. Where the result of communication results in no proxy being used, the relationship is between cache and origin server or replica origin server (see Section 3.1.1). ----------------- ----------------- ----------------- | Local | | Local | | Local | | Proxy | | Proxy | | Proxy | ----------------- ----------------- ----------------- \ | / \ | / ----------------------------------------- | ----------------- | Client | ----------------- In addition, a client may interact with an additional server - operated on behalf of a proxy - to aid the configuration of the client to use that proxy. Protocols used in this relationship can be found in Section 6. 3.2.2 Surrogate to Origin Server A client may communicate with zero or more surrogates for requests intended for one or more origin servers. Where surrogates are not used, the client communicates directly with an origin server. Cooper, et. al. Expires August 19, 2000 [Page 11] Internet-Draft WREC Taxonomy February 2000 -------------- -------------- -------------- | Origin | | Origin | | Origin | | Server | | Server | | Server | -------------- -------------- -------------- \ | / \ | / ----------------- | Surrogate | | | ----------------- | | ------------ | Client | ------------ 3.2.3 Inter-Proxy Inter-Proxy relationships exist as meshes (loosely coupled) and clusters (tightly coupled). 3.2.3.1 (Caching) Proxy Meshes Within a loosely coupled mesh of (caching) proxies, communication can happen at the same level between peers, and with one or more parents. --------------------- --------------------- -----------| Intermediate | | Intermediate | | | Caching Proxy (D) | | Caching Proxy (E) | |(peer) --------------------- --------------------- -------------- | (parent) / (parent) | Cache | | ------/ | Server (C) | | / -------------- | / (peer) | ----------------- --------------------- -------------| Local Caching |-------| Intermediate | | Proxy (A) | (peer)| Caching Proxy (B) | ----------------- --------------------- | | ---------- | Client | ---------- Client included for illustration purposes only Cooper, et. al. Expires August 19, 2000 [Page 12] Internet-Draft WREC Taxonomy February 2000 An inbound request from a local (caching) proxy may be routed to one of a number of intermediate (caching) proxies based on a determination of whether that parent is better suited to resolving the request. For example, in the above figure, Cache Server C and Intermediate Caching Proxy B are peers of the Local Caching Proxy A, and may only be used when the resource requested by A is on either B or C. Intermediate Caching Proxies D & E are parents of A, and it is A's choice of which to use to resolve a particular query. The relationship between A & B only makes sense in a caching environment, while the relationships between A & D and A & E are also appropriate for non-caching proxies. Protocols used in these relationships can be found in Section 7.1. 3.2.3.2 (Caching) Proxy Clusters Where a client may have a relationship with a proxy, it is possible that it may instead have a relationship with an array of proxies arranged in a tightly coupled mesh. ---------------------- ---------------------- | --------------------- | | | (Caching) Proxy | |----- | Array |----- ^ ^ --------------------- ^ ^ | | ^ ^ | |--- | | |----- | -------------------------- Protocols used in this relationship can be found in Section 7.2. 3.2.4 Network Element to Caching Proxy A network element performing traffic interception may choose to redirect requests from a client to a specific proxy within an array. (It may also choose not to redirect the traffic, in which case the relationship is between client and origin server or replica origin server, see Section 3.1.1.) Cooper, et. al. Expires August 19, 2000 [Page 13] Internet-Draft WREC Taxonomy February 2000 ----------------- ----------------- ----------------- | Caching Proxy | | Caching Proxy | | Caching Proxy | | Array | | Array | | Array | ----------------- ----------------- ----------------- \ | / ----------------------------------------- | -------------- | Network | | Element | -------------- | /// | ------------ | Client | ------------ The interception proxy may be directly in-line of the flow of traffic - in which case the intercepting network element and interception proxy form parts of the same hardware system - or may be out-of-path, requiring the intercepting network element to redirect traffic over another network segment. In this latter case, communication protocols enable the intercepting network element to stop and start redirecting traffic when the interception proxy becomes (un)available. Details of these protocols can be found in Section 8. Cooper, et. al. Expires August 19, 2000 [Page 14] Internet-Draft WREC Taxonomy February 2000 4. Client to Replica Communication This section describes the cooperation and communication between clients and replica origin web servers. The ideal situation is to discover an optimal replica origin server for clients to communicate with. Optimality is a policy based decision, often based upon proximity, but may be based on other criteria such as load. 4.1 Navigation Hyperlinks Authoritative reference: This memo. Description: The simplest of client to replica communication mechanisms. This utilizes hyperlink URIs embedded in web pages that point to the mirror sites. The human user manually selects the link of the replica origin server they wish to use. Security: Relies on the protocol security associated with the appropriate URI scheme. Deployment: Probably the most commonly deployed client to replica communication mechanism. Ubiquitous interoperability with humans. Submitter: Document editors. 4.2 URL Redirection Authoritative reference: This memo. Description: A simple and commonly used mechanism to connect web clients with origin server replicas is to use URL redirection. Clients are redirected to a optimal web server replica via the use of the HTTP[1] protocol response codes, e.g. 302 "Found", or 307 "Temporary Redirect". A web client establishes HTTP communication with one of the web server replicas. The initially contacted replica origin web server can either choose to accept the service or redirect the client to the proper replica. Refer to section 10.3 in HTTP/1.1[1] for information on HTTP response codes. Security: Relies entirely upon HTTP security. Cooper, et. al. Expires August 19, 2000 [Page 15] Internet-Draft WREC Taxonomy February 2000 Deployment: Observed at a number of large web sites. Extent of usage in the Internet is unknown at this time. Submitter: Document editors. 4.3 DNS Redirection Authoritative reference: * RFC1794 DNS Support for Load Balancing Proximity[13] * This memo Description: The Domain Name Service (DNS) provides a more sophisticated client to replica communication mechanism. This is accomplished by DNS servers that sort resolved IP addresses based upon quality of service policies. When a client resolves the name of an origin server, the enhanced DNS server sorts the available IP addresses of the replica origin servers starting with the most optimal replica and ending with the least optimal replica. Security: Relies entirely upon DNS security, and other protocols that may be used in determining the sort order. Deployment: Observed at a number of large web sites and large ISP web hosted services. Extent of usage in the Internet is unknown at this time. Submitter: Document editors. Cooper, et. al. Expires August 19, 2000 [Page 16] Internet-Draft WREC Taxonomy February 2000 5. Inter-Replica Communication This section describes the cooperation and communication between master- and replica- origin servers. Used in replicating data sets between origin servers. 5.1 Batch Driven Replication Authoritative reference: This memo. Description: In this model, the replica origin server to be updated initiates communication with a master origin server. The communication is established at intervals based upon queued transactions which are scheduled for deferred processing. The scheduling mechanism policies vary, but generally are re-occurring at a specified time. Once communication is established, data sets are copied to the initiating replica origin server. Security: Relies upon the protocol being used to transfer the data set. FTP and RDIST are the most common protocols observed. Deployment: Very common for mirror synchronization in the Internet. Submitter: Document editors. 5.2 Demand Driven Replication Authoritative reference: This memo. Description: In this model the replica origin server acquires the content as needed due to client demand. This is generally done by a surrogate. When a client requests a resource that is not in the data set of the replica origin server/surrogate, the surrogate attempts to acquire it from the master origin server and then forwards it to the requesting client. Security: Relies upon the protocol being used to transfer the resources. FTP, Gopher, HTTP and ICP are the most common protocols observed. Deployment: Observed at several large web sites. Extent of usage in the Cooper, et. al. Expires August 19, 2000 [Page 17] Internet-Draft WREC Taxonomy February 2000 Internet is unknown at this time. Submitter: Document editors. 5.3 Synchronized Replication Authoritative reference: This memo. Ed note: there is no IETF protocol specified at this time. The editors are aware of at least two open source protocols, AFS and CODA, along with one expired IETF draft and one proprietary protocol Novell NRS; none of which can be considered an authoritative reference. Description: In this model, the replicated origin servers cooperate using synchronized strategies and specialized replica protocols to keep the replica data sets coherent. Synchronization strategies range from tightly coherent (a few minutes) to loosely coherent (a few or more hours). Updates occur between replicas based upon the synchronization time constraints of the coherency model employed and are generally in the form of deltas only. Security: All of the known protocols utilize strong cryptographic key exchange methods, which are either based upon the Kerberos shared secret model or the public/private key RSA model. Deployment: Observed at a few sites, primarily at university campuses. Submitter: Document editors. Cooper, et. al. Expires August 19, 2000 [Page 18] Internet-Draft WREC Taxonomy February 2000 6. Client to Proxy Configuration This section describes the configuration, cooperation and communication between end user clients (browsers and applications) and a proxy. 6.1 Manual Proxy Configuration Authoritative reference: This memo. Description: Each user needs to configure her user agent by supplying information pertaining to proxied protocols and local policies. Security: The potential for doing wrong is high; each user individually sets preferences. Deployment: Widely deployed, used in all current browsers. Most browsers also support additional options. Submitter: Document editors. 6.2 Proxy Auto Configuration (PAC) Authoritative reference: No RFC, no Internet-Draft; Navigator Proxy Auto-Config File Format[2]. Description: A JavaScript script retrieved from a web server is executed to determine an appropriate proxy (if any) for the resource being requested. User agents must be configured to request this JavaScript resource upon startup. No bootstrap mechanism, manual configuration necessary. Manual configuration is made easier by centralizing the script to one URI. Security: Common policy per organization possible but still requires initial manual configuration. PAC is better than "manual proxy configuration" since PAC administrators may update the proxy configuration without further user intervention. Interoperability of PAC files is not high, since different browsers have slightly different interpretations of the same script, possibly leading to undesired effects. Cooper, et. al. Expires August 19, 2000 [Page 19] Internet-Draft WREC Taxonomy February 2000 Deployment: Implemented in most browsers. Submitter: Document editors. 6.3 Cache Array Routing Protocol (CARP) v1.0 Authoritative reference: Expired Internet-Draft: draft-vinod-carp-v1-03.txt[4] Note: Reference kept since there is known implementation. Description: Clients may use CARP directly as a hash function based proxy selection mechanism. They need to be configured with the location of the cluster information. Security: Security considerations are not covered in the specification drafts. Deployment: Implemented in Microsoft Proxy Server, Squid. Implemented in clients via PAC scripts. Submitter: Document editors. 6.4 Web Proxy Auto-Discovery Protocol (WPAD) Authoritative reference: Internet-Draft: draft-ietf-wrec-wpad-01.txt[3] Description: WPAD uses a collection of pre-existing Internet resource discovery mechanisms to perform web proxy auto-discovery. The only goal of WPAD is to locate the PAC URL[2]. WPAD does not specify which proxies will be used. WPAD gets you to the PAC URL, and the PAC script then operates as defined above to choose proxies per resource request. The WPAD protocol specifies the following: * how to use each mechanism for the specific purpose of web proxy auto-discovery * the order in which the mechanisms should be performed * the minimal set of mechanisms which must be attempted by a WPAD compliant web client Cooper, et. al. Expires August 19, 2000 [Page 20] Internet-Draft WREC Taxonomy February 2000 The resource discovery mechanisms utilized by WPAD are as follows: * Dynamic Host Configuration Protocol DHCP * Service Location Protocol SLP * "Well Known Aliases" using DNS A records * DNS SRV records * "service: URLs" in DNS TXT records Security: Relies upon DNS and HTTP security. Deployment: Implemented in web clients and caching proxy servers. More than two independent implementations. Submitter: Josh Cohen, Microsoft, joshco@microsoft.com Cooper, et. al. Expires August 19, 2000 [Page 21] Internet-Draft WREC Taxonomy February 2000 7. Inter-Proxy Communication 7.1 Loosely coupled Inter-Proxy Communication This section describes the cooperation and communication between caching proxies. 7.1.1 Internet Cache Protocol (ICP) Authoritative reference: RFC 2186 Internet Cache Protocol (ICP), version 2[5] Description: ICP is used by caches to query other caches about web objects, to see if a web object is present at the other cache. ICP uses UDP. Since UDP is an uncorrected network transport protocol, an estimate of network congestion and availability may be calculated by ICP loss. This rudimentary loss measurement provides, together with round trip times a load balancing method for caches. Security: See RFC 2187[6] ICP does not convey information about HTTP headers associated with a web object. HTTP headers may include access control and cache directives, Since caches ask for objects, and then download the objects using HTTP, false cache hits may occur (object present in cache, but not accessible for sibling cache is one example). ICP suffers from all the security problems of UDP. Deployment: Widely deployed. Most current caching proxy implementations support ICP in some form. Submitter: Document editors. See also Internet-Draft draft-lovric-icp-ext-02.txt[7], ICP development Web page[8], ICP1.4 specification[9]. 7.1.2 Hyper Text Caching Protocol Authoritative reference: RFC 2756 Hyper Text Caching Protocol (HTCP/0.0)[16] Description: HTCP is a protocol for discovering HTTP caching proxies and cached data, managing sets of HTTP caching proxies, and Cooper, et. al. Expires August 19, 2000 [Page 22] Internet-Draft WREC Taxonomy February 2000 monitoring cache activity. HTCP includes HTTP headers, while ICPv2 does not. HTTP headers are vital information for caching proxies. Security: Optionally uses HMAC-MD5[18]shared secret authentication. Protocol is subject to attack if authentication is not used. Deployment: HTCP is implemented in Squid and the Web Gateway Interceptor[23]. Submitter: Document editors. 7.1.3 Cache Digest Authoritative reference: * No RFC, no Internet-Draft; Cache Digest specification - version 5[15] * Summary Cache[17] (see note) Description: Cache Digests are a response to the problems of latency and congestion associated with previous inter-cache communications mechanisms such as the Internet Cache Protocol (ICP)[5] and the HyperText Cache Protocol[16]. Unlike most of these protocols, Cache Digests support peering between caching proxies and cache servers without a request-response exchange taking place. Instead, a summary of the contents of the server (the Digest) is fetched by other servers which peer with it. Using Cache Digests it is possible to determine with a relatively high degree of accuracy whether a given URL is cached by a particular server. Cache Digests are both an exchange protocol and a data format [15]. Security: If the contents of a Digest are sensitive, they should be protected from access by The Wrong People. Any methods which would normally be applied to secure an HTTP connection can be applied to Cache Digests. A 'Trojan horse' attack is currently possible in a mesh: Cache A can build a fake peer Digest for cache B and serve it to B's peers if requested. This way A can direct traffic toward/from B. The impact of this problem is minimized by the 'pull' model of transferring Cache Digests from one system to another. Cache Digests provide knowledge about peer cache content on a URL level. Hence, they do not dictate a particular level of policy Cooper, et. al. Expires August 19, 2000 [Page 23] Internet-Draft WREC Taxonomy February 2000 management and can be used to implement various policies on any level (user, organization, etc.). Deployment: Cache Digests are supported in Squid. Cache Meshes: * NLANR Mesh * TF-CACHE mesh (European Academic networks) Submitter: Alex Rousskov, NLANR, rousskov@nlanr.net for [15] Pei Cao for [17] Note: The technology of Summary Cache[17] is patent pending by the University of Wisconsin-Madison. 7.1.4 Cache Pre-filling Authoritative reference: Expired Internet-Draft: draft-lovric-francetelecom-satellites-00.txt[14] Description: Cache pre-filling is a push-caching implementation. It is particularly well adapted to IP-multicast networks because it allows preselected URLs to be inserted in one single time within all the caches that belong to the targeted multicast group. Different implementations of cache pre-filling already exist, especially in satellite contexts. However, there is still no standard for this kind of push-caching and vendors propose solutions either based on dedicated equipment or public domain caches extended with a pre-filling module. Security: Relies on the inter cache protocols being employed. Deployment: Observed in two commercial content distribution service providers. Submitter: Ivan Lovric, France Telecom, ivan.lovric@cnet.francetelecom.fr 7.2 Tightly Coupled Inter-Cache Communication Cooper, et. al. Expires August 19, 2000 [Page 24] Internet-Draft WREC Taxonomy February 2000 7.2.1 Cache Array Routing Protocol (CARP) v1.0 Also see Section 6.3 Authoritative reference: Expired Internet-Draft: draft-vinod-carp-v1-03.txt[4] Note: Reference kept since there is known deployment. Description: CARP is a hashing function for dividing URL-space among a cluster of proxy caches. Included in CARP is the definition of a Proxy Array Membership Table, and ways to download this information. An HTTP client agent (either a proxy server or a client browser) which implements CARP v1.0 can allocate and intelligently route requests for the correct URLs to any member of the Proxy Array. Due to the resulting sorting of requests through these proxies, duplication of cache contents is eliminated and global cache hit rates may be improved. Security: Security considerations are not covered in the specification drafts. Deployment: Implemented in caching proxy servers. More than two independent implementations. Submitter: Document editors. Cooper, et. al. Expires August 19, 2000 [Page 25] Internet-Draft WREC Taxonomy February 2000 8. Network Element Communication This section describes the cooperation and communication between proxies and network elements. Examples of such network elements include routers and switches. Generally used for deploying interception proxies and/or diffused arrays. 8.1 Web Cache Control Protocol (WCCP) Authoritative reference: Internet-Draft: draft-ietf-wrec-web-pro-00.txt[11] Description: WCCP V1 runs between a router functioning as a redirecting network element and out-of-path interception proxies. The protocol allows one or more proxies to register themselves with a single router to receive redirected web traffic. It also allows one of the proxies, the designated proxy, to dictate to the router how redirected web traffic is distributed across the array. Security: WCCP V1 has no security features. Deployment: Network elements: WCCP V1 is deployed on a wide range of Cisco routers. Caching proxies: WCCP V1 is deployed on a number of vendors' caches. Submitter: David Forster, CISCO, dforster@cisco.com 8.2 Network Element Control Protocol (NECP) Authoritative reference: draft-cerpa-wrec-necp-01.txt[19] Description: NECP provides methods for network elements to learn about server capabilities, availability, and hints as to which flows can and cannot be serviced. This allows network elements to perform load balancing across a farm of servers, redirection to interception proxies, and cut-through of flows that cannot be served by the farm. Security: Optionally uses SHA-1[20] shared secret authentication along with complex sequence numbers to provide moderately strong security. Protocol is subject to attack if authentication is not used. Cooper, et. al. Expires August 19, 2000 [Page 26] Internet-Draft WREC Taxonomy February 2000 Deployment: NECP is a new protocol being implemented by more than two network element vendors and by more than two caching proxy vendors. It is anticipated to be broadly deployed in the Internet during the year 2000. Submitter: Gary Tomlinson, Novell, garyt@novell.com 8.3 SOCKS Authoritative reference: RFC1928 SOCKS Protocol Version 5[12] Description: SOCKS is primarily used as a proxy cache to firewall protocol. Although, firewalls don't conform to the narrowly defined network element definition of routers and switches, they are a integral part of the network infrastructure. When used in conjunction with a firewall, SOCKS provides a authenticated tunnel between the proxy cache and the firewall. Security: A extensive framework provides for multiple authentication methods. Currently, SSL, CHAP, DES, 3DES are known to be available. Deployment: SOCKS is been widely deployed in the Internet. Submitter: Document editors. Cooper, et. al. Expires August 19, 2000 [Page 27] Internet-Draft WREC Taxonomy February 2000 9. Security Considerations This document provides a taxonomy for web caching and replication. Recommended practice, architecture and protocols are not described in detail. Replication and caching mean copying objects. There are legal implications of making and keeping transient or permanent copies; these are not covered in the security considerations. Information on security in each protocol is provided in the preceding description of the protocol, and in their accompanying documentation. HTTP security is discussed in section 15 of RFC2616[1], the HTTP/1.1 specification, and to a lesser extent in RFC1945[10], the HTTP/1.0 specification. RFC2616 contains security considerations for HTTP proxies. Caching proxies have the same security issues as other application level proxies. Application level proxies are not covered in these security considerations. Authentication based on client IP number is problematic when connecting through a proxy, details are not discussed here. 9.1 Authentication Requests for web objects and responses to such requests may go to replicas and/or flow through proxies. The integrity of the communication needs to be preserved, to ensure protection of access to the communication and protect the communication exchange from unintended change. In the case of security breach, the culprit needs to be identified. 9.1.1 Man in the middle attacks HTTP proxies are men-in-the-middle, the perfect place for a man-in-the-middle-attack. A discussion of this is found in section 15 of RFC2616[1]. 9.1.2 Trusted third party A proxy must either be trusted to act on behalf of server and/or client, or it must act as a tunnel. When presenting cached objects to clients, the clients need to trust the caching proxy to act on behalf on the origin server. A replica may get accreditation from the origin server. Cooper, et. al. Expires August 19, 2000 [Page 28] Internet-Draft WREC Taxonomy February 2000 9.1.3 Authentication based on IP number Authentication based on client IP number is problematic when connecting through a proxy, as the authenticating server sees the proxy's IP number. One (not recommended) solution to this is spoofing the client's IP number. Authentication based on IP number assumes that the end-to-end properties of the Internet are preserved. This is typically not the case for an interception proxy. 9.2 Privacy 9.2.1 Trusted third party When using a replication service, you need to trust both the replica and the object location service. A object location service is used to find the replicated object. Current examples include DNS round robin, manual mirror lists, URNs, HTTP redirecting. Redirection of traffic, either by redirecting to replicas or by redirection done by proxies, may introduce third parties the end user and/or origin server need to trust. In the case of interception proxies, such trusted third parties are often unknown to both end points of the communication. Unknown trusted third parties may have security implications. Both proxies and location services may have access to aggregated access information. A proxy typically knows about all access by all the clients using it, information that is more sensitive than the information held by one origin server. 9.2.2 Logs and legal implications Logs from proxies need to be kept secure, as they provide information about users and end user patterns. A proxy log is even more sensitive than a web server log, as all requests from the user population goes through the proxy. Logs from replication servers may need to be amalgamated to get aggregated statistics from a service, transporting logs across borders may have legal implications. Log handling is restricted by law in some countries. Requirements for object security and privacy are the same in a web replication and caching system as it is in the Internet at large. The only reliable solution is strong cryptography. End to end encryption does not necessarily make objects cacheable, as is the case of SSL encrypted web sessions. Cooper, et. al. Expires August 19, 2000 [Page 29] Internet-Draft WREC Taxonomy February 2000 9.3 Service security 9.3.1 Denial of service Any redirection of traffic is susceptible to denial of service attacks at the redirect point, and both proxies and location services may redirect traffic. By attacking a proxy, access to all servers may be denied for a large set of clients. It has been argued that introduction of an interception proxy is denial of service since the end to end nature of the Internet is destroyed without the end users knowledge. 9.3.2 Replay attack A caching proxy is by definition a replay attack. 9.3.3 Stupid configuration of proxies It is quite easy to have a stupid configuration which will harm service for end users. This is the most common security problem with proxies. 9.3.4 Copyrighted transient copies The legislative forces of the world are considering the question of transient copies, like those kept in replication and caching system, being legal. Legal implications of replication and caching is subject to local law. Caching proxies need to preserve the protocol output, including headers. Replication services need to preserve the source of the objects. 9.3.5 Application level access Caching proxies are application level components in the traffic flow path, and may give intruders access to information that was only available at network level equipment in a proxy-free world. Some network level equipment may have required physical access to get sensitive information, and introducing application level components may require additional system security. Cooper, et. al. Expires August 19, 2000 [Page 30] Internet-Draft WREC Taxonomy February 2000 10. Acknowledgements The editors would like to thank the following for their assistance: David Forster, Alex Rousskov, Josh Cohen, John Martin, John Dilley, Ivan Lovric, Joe Touch, Henrik Nordstrom, Patrick McManus, Duane Wessels, Wojtek Sylwestrzak, Ted Hardie, Misha Rabinovich, Larry Masinter, and Keith Moore. Cooper, et. al. Expires August 19, 2000 [Page 31] Internet-Draft WREC Taxonomy February 2000 References [1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [2] Netscape, Inc., "Navigator Proxy Auto-Config File Format", External reference http://www.netscape.com/eng/mozilla/2.0/ relnotes/demo/proxy-live.html, March 1996. [3] Gauthier, P., Cohen, J., Dunsmuir, M. and C. Perkins, "The Web Proxy Auto-Discovery Protocol", Internet Draft draft-ietf-wrec-wpad-01.txt, July 1999. [4] Valloppillil, V. and K.W. Ross, "Cache Array Routing Protocol", Expired Internet Draft draft-vinod-carp-v1-03.txt available at http://ircache.nlanr.net/Cache/ICP/carp.txt, February 1998. [5] Wessels, D. and K. Claffy, "Internet Cache Protocol (ICP), Version 2", RFC 2186, September 1997. [6] Wessels, D. and K. Claffy, "Application of Internet Cache Protocol (ICP), Version 2", RFC 2187, September 1997. [7] Lovric, I., "Internet Cache Protocol Extension", Internet Draft draft-lovric-icp-ext-02.txt, October 1999. [8] Wessels, D., "ICP Home Page", External reference http://ircache.nlanr.net/Cache/ICP/, July 1999. [9] University of Southern California and University of Colorado-Boulder, "Internet Cache Protocol Specification 1.4", External reference http://excalibur.usc.edu/icpdoc/icp.html, September 1994. [10] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. [11] Cisco Systems, "Cisco Web Cache Control Protocol V1.0", Internet Draft draft-ietf-wrec-web-pro-00.txt, June 1999. [12] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D. and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996. [13] Brisco, T., "DNS Support for Load Balancing", RFC 1794, April 1995. [14] Goutard, C., Lovric, I. and E. Maschio-Esposito, "Pre-filling a cache - A satellite overview", Expired Internet Draft Cooper, et. al. Expires August 19, 2000 [Page 32] Internet-Draft WREC Taxonomy February 2000 draft-lovric-francetelecom-satellites-00.txt, February 1999. [15] Hamilton, M., Rousskov, A. and D. Wessels, "Cache Digest specification - version 5", External reference http://squid.nlanr.net/CacheDigest/cache-digest-v5.txt, December 1998. [16] Vixie, P. and D. Wessels, "Hyper Text Caching Protocol (HTCP/0.0)", RFC 2756, January 2000. [17] Fan, L., Cao, P., Almeida, J. and A. Broder, "Summary Cache: A Scalable Wide-Area Web Cache Sharing Protocol", Proceedings of ACM SIGCOMM'98 pp. 254-265, September 1998. [18] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [19] Cerpa, A., Elson, J., Beheshti, H., Chankhunthod, A., Danzig, P., Jalan, R., Neerdaels, C., Shroeder, T. and G. Tomlinson, "NECP: The Network Element Control Protocol", Internet Draft draft-cerpa-wrec-necp-01.txt, February 2000. [20] U.S. Department of Commerce/National Institute of Standard and Technology, "Secure Hash Standard", Federal Information Processing Standards Publication FIPS PUB 180-1, April 1995. [21] FOLDOC, "Free Online Dictionary of Computing: Replication", Online reference http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?replication, December 1997. [22] Dilley, J., "Known HTTP Proxy/Caching Problems", Internet Draft draft-ietf-wrec-known-prob-00.txt, September 1999. [23] http://www.vix.com/vix/wgi.html Authors' Addresses Ian Cooper Mirror Image Internet, Inc. 49 Dragon Court Woburn, MA 01801 USA Phone: +1 781 376 1109 EMail: ian.cooper@mirror-image.com Cooper, et. al. Expires August 19, 2000 [Page 33] Internet-Draft WREC Taxonomy February 2000 Ingrid Melve UNINETT Tempeveien 22 Trondheim Norway Phone: +47 73 55 79 07 EMail: Ingrid.Melve@uninett.no Gary Tomlinson Novell Inc. 122 East 1700 South Provo, Utah 84606 USA Phone: +1 801 861 7021 EMail: garyt@novell.com Cooper, et. al. Expires August 19, 2000 [Page 34] Internet-Draft WREC Taxonomy February 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Cooper, et. al. Expires August 19, 2000 [Page 35] ----=_8netas4upavf7mttb0vkpcj6mrabmk6k34.MFSBCHJLHS-- From owner-wrec@cs.utk.edu Sun Feb 20 13:43:13 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12074 for ; Sun, 20 Feb 2000 13:43:12 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id NAA03655; Sun, 20 Feb 2000 13:38:25 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Sun, 20 Feb 2000 13:38:24 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id NAA03633; Sun, 20 Feb 2000 13:38:24 -0500 (EST) Received: from mx01-ext.netapp.com (marvin@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id NAA03619; Sun, 20 Feb 2000 13:38:21 -0500 (EST) Received: from mx01-ext.netapp.com (198.95.224.34 -> mx01-ext.netapp.com) by CS.UTK.EDU (smtpshim v1.0); Sun, 20 Feb 2000 13:38:21 -0500 Received: (qmail 20574 invoked from network); 20 Feb 2000 18:45:07 -0000 Received: from herra.netapp.com (HELO herra.corp.netapp.com) (198.95.224.184) by mx01-ext.netapp.com with SMTP; 20 Feb 2000 18:45:07 -0000 Received: from johnm ([192.168.199.35]) by herra.corp.netapp.com (8.9.3/8.9.3/NTAP-1.0) with ESMTP id KAA18956 for ; Sun, 20 Feb 2000 10:38:12 -0800 (PST) Message-Id: <4.2.0.58.20000220192629.06064430@pop.netapp.com> X-Sender: jmartin@pop.netapp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 20 Feb 2000 19:29:23 +0100 To: wrec@cs.utk.edu From: John Martin Subject: Meeting in Adelaide? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: Normally we go ahead and arrange a WREC meeting at each IETF but with little progress made since the last meeting, and a straw poll showing that many of the contributors to the previous drafts will not make it to Adelaide, is there any point in us scheduling a meeting? [Note: The previous meeting was supposed to be our last; the "next" meeting is intended to be under the new charter.] Please reply to me and I will summarize. Rgds, John --------------------------------------------------------------- Network Appliance Direct / Voicemail: +31 23 567 9615 Kruisweg 799 Fax: +31 23 567 9699 NL-2132 NG Hoofddorp Main Office: +31 23 567 9600 --------------------------------------------------------------- From owner-wrec@cs.utk.edu Tue Feb 22 15:20:06 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21824 for ; Tue, 22 Feb 2000 15:20:01 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id PAA08399; Tue, 22 Feb 2000 15:11:04 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Tue, 22 Feb 2000 15:11:04 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id PAA08381; Tue, 22 Feb 2000 15:11:03 -0500 (EST) Received: from prv-mail20.provo.novell.com (marvin@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id PAA08360; Tue, 22 Feb 2000 15:10:59 -0500 (EST) Received: from prv-mail20.provo.novell.com (137.65.82.195 -> prv-mail20.provo.novell.com) by CS.UTK.EDU (smtpshim v1.0); Tue, 22 Feb 2000 15:11:01 -0500 Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 22 Feb 2000 13:10:51 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Tue, 22 Feb 2000 13:10:43 -0700 From: "Gary Tomlinson" To: , Cc: Subject: Re: draft-ietf-wrec-taxonomy-03b.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA21824 Editing comments: Section 8.2 NECP. The current draft is . The name was changed to reflect the status of this document being an individual submission. A new draft, will be submitted shortly for IESG review. We anticipate this version to be the RFC candidate. Per IESG review, the HMAC-SHA-1 secuirty mechansims will be employed, rather than the weaker SHA-1. The taxonomy needs updating to reflect this change, which includes a different reference. Reference 18 is correct for HMAC-SHA-1 and reference 20 needs to be removed. Progression to RFC suggestions: In order for us to submit the taxonomy to the RFC editor we need to remove authoritative reference encumberances. At a minimum, I suggest we bundle up all of WREC drafts and submit them as a set. These include This document This will allow us to complete the work items and remove the encumberances for them within the taxonomy. However, we still are left with 3 encumbered references which are outside the charter of the group. These are: Archived work in progress. Unless anyone knows of a more appropriate mechanism, I suggest we get these moved to archived works in progress and cited as such, so that we can submit the taxonomy unencumbered. Gary >>> Ian Cooper 02/19/00 08:46AM >>> This is the modified version renaming "network transparent proxy" to "interception proxy" (plus a few other tweaks from Patrick McManus and others). Please let me know if the brief explanation in the definition of this term is sufficient, and whether I've missed updating any of the references later in the document. I've become very aware that we're citing quite a few expired drafts for some fairly important stuff. WCCP and WPAD are probably the most important, but if there's any chance of the CARP draft being updated that'd be good useful. I think Ivan's draft has also expired. Please take a look, and if we're citing something that you (co)authored and it has or is about to expire please do something about it. From owner-wrec@cs.utk.edu Tue Feb 22 17:23:47 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25449 for ; Tue, 22 Feb 2000 17:23:43 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id RAA22875; Tue, 22 Feb 2000 17:15:30 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Tue, 22 Feb 2000 17:15:30 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id RAA22857; Tue, 22 Feb 2000 17:15:29 -0500 (EST) Received: from catarina.usc.edu (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id RAA22840; Tue, 22 Feb 2000 17:15:26 -0500 (EST) Received: from catarina.usc.edu (128.125.51.47 -> catarina.usc.edu) by CS.UTK.EDU (smtpshim v1.0); Tue, 22 Feb 2000 17:15:26 -0500 Received: from usc.edu (localhost [127.0.0.1]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA71593; Tue, 22 Feb 2000 14:15:27 -0800 (PST) Message-Id: <200002222215.OAA71593@catarina.usc.edu> To: "Gary Tomlinson" cc: wrec@cs.utk.edu, ian@mirror-image.com, Ingrid.Melve@uninett.no Subject: Re: draft-ietf-wrec-taxonomy-03b.txt In-Reply-To: Message from "Gary Tomlinson" of "Tue, 22 Feb 2000 13:10:43 MST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <71590.951257726.1@usc.edu> Date: Tue, 22 Feb 2000 14:15:26 -0800 From: Jeremy Elson List-Unsubscribe: "Gary Tomlinson" writes: >Section 8.2 NECP. The current draft is . The name w >as changed to reflect the status of this document being an individual submissi >on. A new draft, will be submitted shortly for IESG > review. Just FYI, I just submitted draft-cerpa-necp-02.txt to be an I-D. We'll submit it to the RFC queue as soon as it is an I-D. -Jer From owner-wrec@cs.utk.edu Wed Feb 23 12:52:05 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28321 for ; Wed, 23 Feb 2000 12:52:02 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id MAA17258; Wed, 23 Feb 2000 12:43:15 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Wed, 23 Feb 2000 12:43:15 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id MAA17240; Wed, 23 Feb 2000 12:43:14 -0500 (EST) Received: from mailhost.iprg.nokia.com (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id MAA17219; Wed, 23 Feb 2000 12:43:12 -0500 (EST) From: Received: from mailhost.iprg.nokia.com (205.226.5.12 -> mailhost.iprg.nokia.com) by CS.UTK.EDU (smtpshim v1.0); Wed, 23 Feb 2000 12:43:12 -0500 Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA16078 for ; Wed, 23 Feb 2000 09:43:11 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id JAA18718 for ; Wed, 23 Feb 2000 09:43:10 -0800 X-Virus-Scanned: Wed, 23 Feb 2000 09:43:10 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from (vienna.iprg.nokia.com [205.226.11.35]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma018056; Wed, 23 Feb 00 09:42:55 -0800 Received: (fred@localhost) by vienna.iprg.nokia.com (8.8.8/8.6.12) id JAA00525 for webrepl@cs.utk.edu; Wed, 23 Feb 2000 09:42:55 -0800 (PST) Date: Wed, 23 Feb 2000 09:42:55 -0800 (PST) Message-Id: <200002231742.JAA00525@vienna.iprg.nokia.com> To: webrepl@cs.utk.edu Subject: INFOCOM 2000: Last week for early registration List-Unsubscribe: >>>>> INFOCOM 2000 - LAST WEEK FOR EARLY REGISTRATION <<<<< CALL FOR PARTICIPATION ------------------------ IEEE Infocom 2000 (Israel) http://www.comnet.technion.ac.il/infocom2000 (U.S.A.) http://www.cse.ucsc.edu/~rom/infocom2000 (Japan) http://halo.kuamp.kyoto-u.ac.jp/~infocom Dan Panorama Hotel, Tel Aviv, Israel March 26-30, 2000 Sponsored by the IEEE Communications and Computer Societies IMPORTANT ========= Early registration cut-off date: February 28, 2000 (last week) Registration fees for an IEEE member prior to February 28, 2000 will be $500 and it will include all technical sessions, open receptions, proceedings (CD) and three lunches. For other fees consult the web pages. On-line registration: https://secure.computer.org/conf/infocom/register.htm VENUE ===== For the last 18 years, Infocom has been the major conference on computer communications and networking, bringing together researchers and implementors of every aspect of data communications and networks presenting the most up-to-date results and achievements in the field. The 19th annual conference on Computer Communications, Infocom 2000, will be held at the Dan Panorama Hotel in Tel-Aviv, Israel, during the week of March 26-30, 2000. Overlooking the Mediterranean, the Dan Panorama Tel Aviv is a city hotel in a resort setting. Just a few steps away are fine shops, theaters, restaurants and the corporate world of Tel Aviv, contrasted by the ancient port city of Jaffa with its picturesque corners and flea markets for bargain hunters. The hotel features a large swimming pool, beach access and a fully equipped health & fitness center. SCOPE ===== Original papers and panel discussions describing state-of-the-art research and development in all areas of computer networking and data communications will be presented. Browse the excellent technical program and see the papers at http://www.comnet.technion.ac.il/infocom2000/program.html KEYNOTE SPEAKER =============== Prof. Leonard Kleinrock, Chairman, Nomadix, Inc. Keynote title: Nomadic Computing and Smart Spaces http://www.comnet.technion.ac.il/infocom2000/key.html TUTORIALS ========= Full Day -------- - Wavelength-routing optical networks (Kumar Sivarajan, Indian Institute of Science) - The evolution of QoS in the Internet standards community (Jon Crowcroft, University College London) - Overview of network security (Radia Perlman, Sun Microsystems) - Teletraffic Models and Tools: From Basics to Advanced(Khosrow Sohraby, University of Missouri, Kansas City) - IP Multicast: past, present and future (Radia Perlman, Sun Microsystems & Christophe Diot, Sprint) Half Day -------- - MPLS (Loa Andersson, Nortel Networks) - New technologies for LAN systems (Dono Van-Mierop, IBM Israel) - Satellite IP networking (Catherine Rosenberg, Purdue University) - Mobile IP: adding mobility to the Internet (Charles Perkins, Nokia Research) http://www.comnet.technion.ac.il/infocom2000/tutorial.html QUESTIONS? =========================== Write to infocom@comnet.technion.ac.il] From owner-wrec@cs.utk.edu Mon Feb 28 03:07:52 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01331 for ; Mon, 28 Feb 2000 03:07:52 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id DAA15542; Mon, 28 Feb 2000 03:01:36 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Mon, 28 Feb 2000 03:01:35 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id DAA15524; Mon, 28 Feb 2000 03:01:35 -0500 (EST) Received: from leonis.nus.edu.sg (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id DAA15488; Mon, 28 Feb 2000 03:01:22 -0500 (EST) Received: from leonis.nus.edu.sg (137.132.1.18 -> leonis.nus.edu.sg) by CS.UTK.EDU (smtpshim v1.0); Mon, 28 Feb 2000 03:01:24 -0500 Received: from engtanlk.nus.edu.sg ([137.132.204.177]) by leonis.nus.edu.sg (8.9.3/8.9.3) with SMTP id PAA18765; Tue, 22 Feb 2000 15:26:44 +0800 (SST) Message-ID: <005001bf7d06$a56fb320$b1cc8489@engtanlk.nus.edu.sg> From: "ICON'2000 Secretariat" To: Subject: Calling for your contribution! Date: Tue, 22 Feb 2000 15:26:39 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01BF7D49.B392F320" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_004D_01BF7D49.B392F320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All =20 * Kindly ignore this email if you have received this before.=20 Thanks you for your kind attention. =20 The 8th IEEE International Conference On Networks will be held from=20 September 5- 8, 2000 in Singapore. The aim of the conference is to = provide=20 an international forum for experts to promote, share and discuss various = issues and developments in the broad field of computer and communication = networks. We thus seek and solicit your contributions in the form of original/unpublished papers, tutorials, and topics for=20 special sessions/panel discussions. More information on the scope of the = conference and the guidelines for the submission of contributions can be obtained at this web site : http://www.comp.nus.edu.sg/~icon/ We look forward to your participation. Thank you. Icon 2000 organizing Committee ------=_NextPart_000_004D_01BF7D49.B392F320 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear All
 
*=20 Kindly ignore this email if you have received this before.=20
Thanks you for your kind = attention.
 

The 8th IEEE International Conference On Networks will be held from =

September 5- 8, 2000 in Singapore. The aim of the conference is to = provide=20

an international forum for experts to promote, share and discuss = various

issues and developments in the broad field of computer and = communication

networks. We thus seek and solicit your contributions

in the form of original/unpublished papers, tutorials, and topics for =

special sessions/panel discussions. More information on the scope of = the

conference and the guidelines for the submission of contributions = can

be obtained at this web site :

http://www.comp.nus.edu.sg/~ic= on/

We look forward to your participation. Thank you.

Icon 2000 organizing=20 Committee

------=_NextPart_000_004D_01BF7D49.B392F320-- From owner-wrec@cs.utk.edu Tue Feb 29 04:08:32 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13775 for ; Tue, 29 Feb 2000 04:08:31 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id EAA27862; Tue, 29 Feb 2000 04:03:03 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Tue, 29 Feb 2000 04:03:03 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id EAA27844; Tue, 29 Feb 2000 04:03:02 -0500 (EST) Received: from leonis.nus.edu.sg (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id EAA27776; Tue, 29 Feb 2000 04:02:55 -0500 (EST) Received: from leonis.nus.edu.sg (137.132.1.18 -> leonis.nus.edu.sg) by CS.UTK.EDU (smtpshim v1.0); Tue, 29 Feb 2000 04:02:56 -0500 Received: from engtanlk.nus.edu.sg ([137.132.204.165]) by leonis.nus.edu.sg (8.9.3/8.9.3) with SMTP id PAA28647; Tue, 29 Feb 2000 15:06:20 +0800 (SST) Message-ID: <028401bf8284$44618940$a5cc8489@engtanlk.nus.edu.sg> From: "ICON'2000 Secretariat" To: Subject: 14 days to countdown! Have you submitted your papers??? Date: Tue, 29 Feb 2000 15:06:17 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0281_01BF82C7.5284C940" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0281_01BF82C7.5284C940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All =20 * Kindly ignore this email if you have received this before.=20 Thanks you for your kind attention. =20 The 8th IEEE International Conference On Networks will be held from=20 September 5- 8, 2000 in Singapore. The aim of the conference is to = provide=20 an international forum for experts to promote, share and discuss various = issues and developments in the broad field of computer and communication = networks. We thus seek and solicit your contributions in the form of original/unpublished papers, tutorials, and topics for=20 special sessions/panel discussions. More information on the scope of the = conference and the guidelines for the submission of contributions can be obtained at this web site :http://www.comp.nus.edu.sg/~icon/ We look forward to your participation. Thank you. Icon 2000 organizing Committee ------=_NextPart_000_0281_01BF82C7.5284C940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear All
 
*=20 Kindly ignore this email if you have received this before.=20
Thanks you for your kind = attention.
 

The 8th IEEE International Conference On Networks will be held from =

September 5- 8, 2000 in Singapore. The aim of the conference is to = provide=20

an international forum for experts to promote, share and discuss = various

issues and developments in the broad field of computer and = communication

networks. We thus seek and solicit your contributions

in the form of original/unpublished papers, tutorials, and topics for =

special sessions/panel discussions. More information on the scope of = the

conference and the guidelines for the submission of contributions = can

be obtained at this web site :http://www.comp.nus.edu.sg/~icon/

 

We look forward to your participation. Thank you.

Icon 2000 organizing Committee

 

= ------=_NextPart_000_0281_01BF82C7.5284C940-- From owner-wrec@cs.utk.edu Tue Feb 29 17:24:00 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04003 for ; Tue, 29 Feb 2000 17:24:00 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id RAA11449; Tue, 29 Feb 2000 17:19:08 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Tue, 29 Feb 2000 17:19:08 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id RAA11431; Tue, 29 Feb 2000 17:19:07 -0500 (EST) Received: from ziggy.stardust.com (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id RAA11408; Tue, 29 Feb 2000 17:19:04 -0500 (EST) Received: from ziggy.stardust.com (205.184.205.34 -> ns.stardust.com) by CS.UTK.EDU (smtpshim v1.0); Tue, 29 Feb 2000 17:19:04 -0500 Received: from WHITESTAR (dhcp204-106.stardust.com [205.184.204.106]) by ziggy.stardust.com (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA23445; Tue, 29 Feb 2000 14:18:25 -0800 Message-Id: <3.0.5.32.20000229141821.009eaaf0@stardust.com> X-Sender: martinb@stardust.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 29 Feb 2000 14:18:21 -0800 To: Marty Bickford From: Marty Bickford Subject: Call for Presentations: iBAND4 June 11-14 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" List-Unsubscribe: Call for Papers - http://www.stardust.com/iband4/conference.htm --------------- iBAND4 - Advancing the Technology of Internet Bandwidth Management and Traffic Engineering Technical Conference - June 11-13 Workshops with DMTF - June 14 iBAND4 is the fourth in a series of events focused on innovation in the areas of bandwidth management and traffic engineering. iBAND5 will be co-located and run together with ISPCON. The goal of iBAND is to help IP network professionals at ISP's and enterprise's understand the direction of work being done by standards groups and vendors. These events have also become a meeting place for the folks driving innovation in the areas of bandwidth management and traffic engineering. iBAND attendees include IP network engineers, network architects, engineering and business executives, MIS and IT professionals, product and development managers, researchers and other innovators. You are invited to submit a presentation proposal. To aid you in submitting a proposal, please visit http://www.stardust.com/iband4/conference.htm If you do not wish to present, we hope you will mark your calendar to attend this fun and innovative conference. Email or call me with any questions. Sincerely, Marty --- Marty Bickford - 408.879.8080 (8081-fax) Stardust.com - http://www.stardust.com