From owner-ietf-openproxy@mail.imc.org Mon Aug 4 10:40:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29743 for ; Mon, 4 Aug 2003 10:40:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jgM5-0002AL-00 for opes-archive@ietf.org; Mon, 04 Aug 2003 10:30:33 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19jgM4-0002AF-00 for opes-archive@ietf.org; Mon, 04 Aug 2003 10:30:32 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74EFDqt005822 for ; Mon, 4 Aug 2003 07:15:13 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h74EFDDH005820 for ietf-openproxy-bks; Mon, 4 Aug 2003 07:15:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h74EFBqt005812 for ; Mon, 4 Aug 2003 07:15:12 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27559; Mon, 4 Aug 2003 10:15:08 -0400 (EDT) Message-Id: <200308041415.KAA27559@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-opes-http-00.txt Date: Mon, 04 Aug 2003 10:15:08 -0400 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF. Title : HTTP adaptation with OPES Author(s) : A. Rousskov, M. Stecher Filename : draft-ietf-opes-http-00.txt Pages : 17 Date : 2003-8-4 Open Pluggable Edge Services (OPES) framework documents several application-agnostic mechanisms such as OPES tracing, OPES bypass, and OPES callout protocol. This document binds those mechanisms to a specific application protocol, HTTP. Together, application-agnostic OPES documents and this HTTP binding constitute a complete specification for HTTP adaptation with OPES. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-http-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-opes-http-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-opes-http-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-4100024.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-http-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-http-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-4100024.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Thu Aug 7 17:20:24 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03463 for ; Thu, 7 Aug 2003 17:20:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ksBQ-0002vN-00 for opes-archive@ietf.org; Thu, 07 Aug 2003 17:20:28 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19ksBP-0002vJ-00 for opes-archive@ietf.org; Thu, 07 Aug 2003 17:20:27 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77L4iqt048329 for ; Thu, 7 Aug 2003 14:04:44 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77L4iKS048328 for ietf-openproxy-bks; Thu, 7 Aug 2003 14:04:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77L4hqt048323 for ; Thu, 7 Aug 2003 14:04:43 -0700 (PDT) (envelope-from info@utel.net) Received: from f01m-27-135.d0.club-internet.fr ([212.195.226.135] helo=jfc2.utel.net) by hosting.altserver.com with esmtp (Exim 4.20) id 19krwA-00047D-3f for ietf-openproxy@imc.org; Thu, 07 Aug 2003 14:04:42 -0700 Message-Id: <5.2.0.9.0.20030807225645.02f76b50@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 07 Aug 2003 23:07:58 +0200 To: OPES WG From: jfcm Subject: Re: draft-beck-opes-irml-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Not much interest in my proposition in here about alternative IP :-) but interest taken in some potential financing places. We will see. I just went across an interesting concept on the IMAA list. The problem is to support vernacular (real life, law consistent) LHS (left hand side) in e-mails. One idea could be to develop a meta data system. 1. I write my mails with a lot of additional data (Rich text) 2. An opes reduces it to standard presentation plus meta data 3. a possible OPES in front of the receiving mail server restores the rich text he receiving server can or want understand. The rich text information (as in RTF vs ascii text) is optional: - upper cases in the LHS or special characters - classing system shared between members of a group - url of the author - translated appendix - etc... ... and anti spam verification. This corresponds to the only want to make internet systems evolve : encapsulating them into added value layers. Comments? I may have an application for a financing in a few months. jfc From owner-ietf-openproxy@mail.imc.org Thu Aug 7 18:41:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07255 for ; Thu, 7 Aug 2003 18:41:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ktRc-0003QX-00 for opes-archive@ietf.org; Thu, 07 Aug 2003 18:41:16 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19ktRb-0003QS-00 for opes-archive@ietf.org; Thu, 07 Aug 2003 18:41:15 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77MOfqt053159 for ; Thu, 7 Aug 2003 15:24:41 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h77MOffo053158 for ietf-openproxy-bks; Thu, 7 Aug 2003 15:24:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h77MOeqt053151 for ; Thu, 7 Aug 2003 15:24:40 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.8/8.12.8) with ESMTP id h77MLYsT020261; Thu, 7 Aug 2003 16:21:35 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id h77MO3in031116; Thu, 7 Aug 2003 16:24:03 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h77MNthQ031108; Thu, 7 Aug 2003 16:23:55 -0600 Date: Thu, 7 Aug 2003 16:23:55 -0600 Message-Id: <200308072223.h77MNthQ031108@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: info@utel.net Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage <5.2.0.9.0.20030807225645.02f76b50@mail.utel.net> Subject: Re: draft-beck-opes-irml-03.txt Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Text markup and presentation seems like an end system application. I can't see any advantage to having it done as part of delivery. It would make a lot of sense to have the marked-up text available for translation into several different formats (pdf, word, html) even after the initial delivery, so it does not seem like an OPES application. Anti-spam, though, seems like a good OPES application. It involves delivery, it involves using an existing protocol (SMTP) embedded inside another protocol state machine, it only needs to be done once as part of message delivery. Hilarie From owner-ietf-openproxy@mail.imc.org Thu Aug 7 21:43:12 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11667 for ; Thu, 7 Aug 2003 21:43:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kwHk-0004Qu-00 for opes-archive@ietf.org; Thu, 07 Aug 2003 21:43:16 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19kwHj-0004Qr-00 for opes-archive@ietf.org; Thu, 07 Aug 2003 21:43:15 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h781Njqt063197 for ; Thu, 7 Aug 2003 18:23:45 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h781NjDH063196 for ietf-openproxy-bks; Thu, 7 Aug 2003 18:23:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h781Niqt063190 for ; Thu, 7 Aug 2003 18:23:44 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h781MsU13349; Thu, 7 Aug 2003 21:22:54 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Aug 2003 21:22:55 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754068D48BE@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: "The Purple Streak, Hilarie Orman" , info@utel.net Cc: ietf-openproxy@imc.org Subject: RE: draft-beck-opes-irml-03.txt Date: Thu, 7 Aug 2003 21:22:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35D4B.9755F870" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C35D4B.9755F870 Content-Type: text/plain Hilarie, yes, I agree with your observations. Abbie > -----Original Message----- > From: The Purple Streak, Hilarie Orman [mailto:ho@alum.mit.edu] > Sent: Thursday, August 07, 2003 6:24 PM > To: info@utel.net > Cc: ietf-openproxy@imc.org > Subject: Re: draft-beck-opes-irml-03.txt > > > > Text markup and presentation seems like an end system > application. I can't see any advantage to having it done as > part of delivery. It would make a lot of sense to have the > marked-up text available for translation into several > different formats (pdf, word, html) even after the initial > delivery, so it does not seem like an OPES application. > > Anti-spam, though, seems like a good OPES application. It > involves delivery, it involves using an existing protocol > (SMTP) embedded inside another protocol state machine, it > only needs to be done once as part of message delivery. > > Hilarie > ------_=_NextPart_001_01C35D4B.9755F870 Content-Type: text/html RE: draft-beck-opes-irml-03.txt

Hilarie,
yes, I agree  with your observations.

Abbie


> -----Original Message-----
> From: The Purple Streak, Hilarie Orman [mailto:ho@alum.mit.edu]
> Sent: Thursday, August 07, 2003 6:24 PM
> To: info@utel.net
> Cc: ietf-openproxy@imc.org
> Subject: Re: draft-beck-opes-irml-03.txt
>
>
>
> Text markup and presentation seems like an end system
> application.  I can't see any advantage to having it done as
> part of delivery.  It would make a lot of sense to have the
> marked-up text available for translation into several
> different formats (pdf, word, html) even after the initial
> delivery, so it does not seem like an OPES application.
>
> Anti-spam, though, seems like a good OPES application.  It
> involves delivery, it involves using an existing protocol
> (SMTP) embedded inside another protocol state machine, it
> only needs to be done once as part of message delivery.
>
> Hilarie
>

------_=_NextPart_001_01C35D4B.9755F870-- From owner-ietf-openproxy@mail.imc.org Fri Aug 8 09:45:26 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10599 for ; Fri, 8 Aug 2003 09:45:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l7Yf-0000ka-00 for opes-archive@ietf.org; Fri, 08 Aug 2003 09:45:29 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19l7Ye-0000kX-00 for opes-archive@ietf.org; Fri, 08 Aug 2003 09:45:29 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78DUPqt024452 for ; Fri, 8 Aug 2003 06:30:25 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h78DUPv7024451 for ietf-openproxy-bks; Fri, 8 Aug 2003 06:30:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78DUOqt024443 for ; Fri, 8 Aug 2003 06:30:24 -0700 (PDT) (envelope-from info@utel.net) Received: from f01m-23-43.d0.club-internet.fr ([212.195.222.43] helo=jfc2.utel.net) by hosting.altserver.com with esmtp (Exim 4.20) id 19l7K2-0001ci-M7; Fri, 08 Aug 2003 06:30:23 -0700 Message-Id: <5.2.0.9.0.20030808151722.00ab85c0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 08 Aug 2003 15:31:49 +0200 To: "The Purple Streak, Hilarie Orman" From: jfcm Subject: Re: draft-beck-opes-irml-03.txt Cc: ietf-openproxy@imc.org In-Reply-To: <200308072223.h77MNthQ031108@localhost.localdomain> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 00:23 08/08/03, The Purple Streak, Hilarie Orman wrote: >Text markup and presentation seems like an end system application. I can't >see any advantage to having it done as part of delivery. It would make >a lot of sense to have the marked-up text available for translation into >several different formats (pdf, word, html) even after the initial delivery, >so it does not seem like an OPES application. Unfortunately (fortunately?) this cannot be the case for three main reasons: 1. the support of the existing systems. Today we still have Bind 4 in operation on many name servers. We will still have current MUAs for a long. 2. this will protect the users interest as every user does not necessarily need a complex MUA able to support many features in addition to the today ones. 3. the IAB/IETF trend is to refuse the users demand in that area expressed by language groups such as Eurolinc (of which I Chair the WG-IDN). The demand is for Vernacular Names, ie names which are the ones used in real life (language, law, programs, documents, geography, culture, peoples names, etc.). This means for example the support of case-sensitive mailboxes. In making their support an option that an OPES may filter out, we permit them to develop while keeping continuity >Anti-spam, though, seems like a good OPES application. It involves delivery, >it involves using an existing protocol (SMTP) embedded inside another >protocol state machine, it only needs to be done once as part of message >delivery. Anti-Spam as filtering needs to be odnne once as a part of the mesage delivery. But anti-spam by dialog between sender's and receiver's OPES through OCP is an interesting feature which may add to value added mail services. An example is an acknowledgement system. Mail system does not support any mail delivery reporting. Using frontal Mail Opes might permit it with a mail control tower among a community. It could permit meta / common archiving too. etc. jfc From owner-ietf-openproxy@mail.imc.org Fri Aug 8 10:26:20 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13235 for ; Fri, 8 Aug 2003 10:26:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l8CG-00018Q-00 for opes-archive@ietf.org; Fri, 08 Aug 2003 10:26:24 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19l8CF-00018N-00 for opes-archive@ietf.org; Fri, 08 Aug 2003 10:26:23 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78EC6qt027865 for ; Fri, 8 Aug 2003 07:12:06 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h78EC6Nv027864 for ietf-openproxy-bks; Fri, 8 Aug 2003 07:12:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h78EC5qt027858 for ; Fri, 8 Aug 2003 07:12:05 -0700 (PDT) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h78EC59Y006523 for ; Fri, 8 Aug 2003 10:12:06 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h78EBw1u034496 for ; Fri, 8 Aug 2003 10:11:58 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h78EBwkO009350 for ; Fri, 8 Aug 2003 10:11:58 -0400 (EDT) Message-ID: <3F33B001.7080709@mhof.com> Date: Fri, 08 Aug 2003 10:13:21 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Draft minutes from IETF 57 References: <3F201FEB.4050404@mhof.com> In-Reply-To: <3F201FEB.4050404@mhof.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi, since there were no comments, these minutes have been submitted as final. -Markus Markus Hofmann wrote: > Hi, > > below the draft minutes from the OPES meeting in Vienna. In the absence > of substantive comments, the minutes get filed on Monday, 8/4/03. > > Thanks, > Markus > > ================================================================== > > Minutes of the 57th Vienna OPES WG. > > CHAIRS: Markus Hofmann > > Minutes by Dimitri Tombroff. > > > 1 Introduction and General Status: > ---------------------------------- > > Status of OPES documents: Initial versions of tracing/bypassing > (draft-ietf-opes-end-comm-00.txt) and OPES core protocol > > (draft-ietf-opes-ocp-core-00.txt) have been published. An individual > submission about OCP/HTTP mapping has also been published, > > and the group intendes to adopt this draft as WG document. > > General comments from the chair: > - WG needs more participants for reviewing drafts and brings in arguments. > - WG needs additional focusing on tracing/bypassing issues. > - WG is late with the rule language. Need expert contributors to start > this. > > > 2 Work on "Tracing/Bypass" document [P. Knight] > ----------------------------------------------- > > Main issues is to decide on is traceable in an OPES flow, how to do it, > and what are the requirements and privacy issues. > > The WG approach is to use in-band tracing on a per message flow with the > following requirements: > - an OPES system MUST be traceable > - an OPES processor SHOULD be traceable > - an OPES service MAY be traceable. > > question: this works only for application protocols that allow for > in-band signaling of meta information. How would the first > > MUST apply to other application protocols? > answer: At this point, it is assumed that the appplication protocol will > have to support in-band signaling, which is in-line > > with the WG's charter to focus on HTTP. This issue should be mentioned > in the drafts. > > question : what motivates the MUST, SHOULD, and MAY at three different > levels ? > answer: if you have a chain of processor, it may be unecessary that each > processor adds a trace. One per domain is enough. > > On 'How to support tracing', the chair noted that although the WG has so > far ruled out out-of-band notifications, more input is > > needed to confirm it is the correct approach. It was suggested that the > resulting discussion should be reflected in the > > document(s). > > On another issue, the WG needs to detail the definition of an "OPES > system". > > > 3 OPES Core Callout Protocol presented [Martin Stecher] > ------------------------------------------------------- > > The core OCP was presented. This was a rather detailed presentation, > the remarks and questions were the following: > > The chair pointed out that there are still many open issues and optional > mechanisms to discuss - just see the TBD section and > > the sections marked with XXX in the drafts. If no one is supporting the > inclusion of currently open/optional mechanisms (e.g. > > capability query) on the mailing list, they will be removed for the sake > of protocol simplicity. > > Performance is of big concern, and the WG needs to show benefits of OCP > over ICAP. > > It was noted that after long discussions about using BEEP, SOAP, or > HTTP, the consensus has been to move forward with a custom > > tailored transport protocol for OCP, and see how it works. Progresses > have been mostly made on OCP messages format. > > The 'can you' and 'do you' set of messages might bring unecessary > complication. Some input is needed to check if they are > > worthwhile. > > question : Since OCP is defined by a BNF grammar, is or will a parser be > provided ? > answer: none so far. > > > 4 OCP Http Adaptation [Martin Stecher] > -------------------------------------- > > The http adaptation was presented, as well as the status of prototype > callout servers by A. Rousskov and M. Stecher. > > One issue was raised about HTTP keep-alive connections and HTTP/1.1 > pipelining. The problem is that the callout server may have > > to transform a keep-alive http reply into a closed reply, because it may > not be able to set the correct Content-Length http > > header, nor use the chunked transfer encoding. > > Having a callout generating closed http replies is bad because it breaks > two desirable http properties: keep-alive connections > > and thus http pipelining (if any). It was also pointed out that it is > not clear if it's the callout server responsability or the > > OPES processor responsability to handle such closing. > > > > 5 OPES treatment of IAB Consideration [P. Knight] > ------------------------------------------------- > > IAB considerations were discussed. The goal is to show that all IAB > considerations are addressed. > Only IAB considerations are mentioned in this document that triggered > some remarks/questions during the meeting. > > 5.0 IP layer Addressability > > Comment: must be addressible at IP layer. Otherwise encryption will not > work. > > 5.1 Notification: > > As pointed out before, the tracing/notification issue is still at an > early stage. Following Remarks: > - hit metering analogy may not be approriate here, > content providers might want at least some limited > help in the OPES case > - (out-of-band) notification may be a problem for the > recipient if it must handle a lots of notification > information. A solution (should notification be needed) > would be to perform aggregation. I.e send me a > notification every hour rather than for each message. > > 5.2 Non-blocking: > > OPES intermediaries MUST support a bypass feature. There is a clear open > issue if the OPES service is essential. > > 5.3 Privacy. > > From the tracing information, the user can contact the OPES first node, > then ask its privacy policy. > What is not clear nor explicitely stated here is that the first OPES > node is not necessarilly addressible. A statement like "at > > least one trace per domain must identify one addressible node" is needed. > > question : is there any relationship with the ALIAS WG wrt to > establishing a trust relationship with an intermediary. > answer: OPES is application level while ALIAS deals with the transport > level. > > From owner-ietf-openproxy@mail.imc.org Mon Aug 11 10:41:31 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18738 for ; Mon, 11 Aug 2003 10:41:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mDrc-0006MS-00 for opes-archive@ietf.org; Mon, 11 Aug 2003 10:41:36 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19mDrb-0006MO-00 for opes-archive@ietf.org; Mon, 11 Aug 2003 10:41:35 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BEDeqt044487 for ; Mon, 11 Aug 2003 07:13:40 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BEDeDc044486 for ietf-openproxy-bks; Mon, 11 Aug 2003 07:13:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BEDdqt044477 for ; Mon, 11 Aug 2003 07:13:39 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7BEDXn29588 for ; Mon, 11 Aug 2003 10:13:33 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Aug 2003 10:13:33 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754068D5211@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: OPES Group Subject: [end points comm] OPES System Date: Mon, 11 Aug 2003 10:13:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36012.BE7C7A54" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C36012.BE7C7A54 Content-Type: text/plain All, As per the minutes of the 57th IETF, the work on draft-ietf-opes-end-comm-00 requires us to come up with a definition of an "OPES system". The intend of this e-mail is to start a thread that comes to a conclusion from the WG. This will be used in the -01 of the draft that will be comming soon. To start off the discussion, can we state that an OPES system is the collection of entities that perform OPES transformations on a request/responce within an OPES flow? Other e-mail threads will be used to discuss the remainder of the points that need to be addressed to finalize the draft. Cheers, Abbie ------_=_NextPart_001_01C36012.BE7C7A54 Content-Type: text/html Content-Transfer-Encoding: quoted-printable [end points comm] OPES System

All,

As per the minutes of the 57th IETF, the work on = draft-ietf-opes-end-comm-00 requires us to come up with a definition of = an "OPES system".

The intend of this e-mail is to start a thread that = comes to a conclusion from the WG. This will be used in the -01 of the = draft that will be comming soon.


To start off the discussion, can we state that an = OPES system is the collection of entities that perform OPES = transformations on a request/responce within an OPES flow?

Other e-mail threads will be used to discuss the = remainder of the points that need to be addressed to finalize the = draft.


Cheers,

Abbie


------_=_NextPart_001_01C36012.BE7C7A54-- From owner-ietf-openproxy@mail.imc.org Mon Aug 11 11:05:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19650 for ; Mon, 11 Aug 2003 11:05:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mEEL-0006XN-00 for opes-archive@ietf.org; Mon, 11 Aug 2003 11:05:05 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19mEEK-0006XI-00 for opes-archive@ietf.org; Mon, 11 Aug 2003 11:05:04 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BEp8qt046473 for ; Mon, 11 Aug 2003 07:51:08 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BEp8LB046472 for ietf-openproxy-bks; Mon, 11 Aug 2003 07:51:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BEp6qt046466 for ; Mon, 11 Aug 2003 07:51:07 -0700 (PDT) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7BEp7Ha004724 for ; Mon, 11 Aug 2003 10:51:07 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7BEp11u018114 for ; Mon, 11 Aug 2003 10:51:01 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7BEp0kO018347 for ; Mon, 11 Aug 2003 10:51:00 -0400 (EDT) Message-ID: <3F37ADA8.8060802@mhof.com> Date: Mon, 11 Aug 2003 10:52:24 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: [end points comm] OPES System References: <87609AFB433BD5118D5E0002A52CD754068D5211@zcard0k6.ca.nortel.com> In-Reply-To: <87609AFB433BD5118D5E0002A52CD754068D5211@zcard0k6.ca.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Abbie Barbir wrote: > To start off the discussion, can we state that an OPES system is the > collection of entities that perform OPES transformations on a > request/responce within an OPES flow? Isn't there somewhere an assumption in the drafts that an "OPES System" describes OPES entities that are operated (or belong) to a single operatore/trustdomain/carrier? Thanks, Markus From owner-ietf-openproxy@mail.imc.org Mon Aug 11 11:32:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20351 for ; Mon, 11 Aug 2003 11:32:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mEfJ-0006gX-00 for opes-archive@ietf.org; Mon, 11 Aug 2003 11:32:57 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19mEfI-0006gU-00 for opes-archive@ietf.org; Mon, 11 Aug 2003 11:32:56 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BFELqt047778 for ; Mon, 11 Aug 2003 08:14:22 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BFELuW047777 for ietf-openproxy-bks; Mon, 11 Aug 2003 08:14:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BFEKqt047768 for ; Mon, 11 Aug 2003 08:14:21 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7BFEDn14204; Mon, 11 Aug 2003 11:14:14 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Aug 2003 11:14:14 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754068D532F@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Markus Hofmann , OPES Group Subject: RE: [end points comm] OPES System Date: Mon, 11 Aug 2003 11:14:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3601B.38566378" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3601B.38566378 Content-Type: text/plain Markisn That is the main problem. We need a formal definition, since we refere to it a lot in the draft. Abbie > -----Original Message----- > From: Markus Hofmann [mailto:markus@mhof.com] > Sent: Monday, August 11, 2003 10:52 AM > To: OPES Group > Subject: Re: [end points comm] OPES System > > > > Abbie Barbir wrote: > > > To start off the discussion, can we state that an OPES > system is the > > collection of entities that perform OPES transformations on a > > request/responce within an OPES flow? > > Isn't there somewhere an assumption in the drafts that an "OPES > System" describes OPES entities that are operated (or belong) to a > single operatore/trustdomain/carrier? > > Thanks, > Markus > > ------_=_NextPart_001_01C3601B.38566378 Content-Type: text/html RE: [end points comm] OPES System

Markisn

That is the main problem. We need a formal definition, since we refere to it a lot in the draft.

Abbie


> -----Original Message-----
> From: Markus Hofmann [mailto:markus@mhof.com]
> Sent: Monday, August 11, 2003 10:52 AM
> To: OPES Group
> Subject: Re: [end points comm] OPES System
>
>
>
> Abbie Barbir wrote:
>
> > To start off the discussion, can we state that an OPES
> system is the
> > collection of entities that perform OPES transformations on a
> > request/responce within an OPES flow?
>
> Isn't there somewhere an assumption in the drafts that an "OPES
> System" describes OPES entities that are operated (or belong) to a
> single operatore/trustdomain/carrier?
>
> Thanks,
>    Markus
>
>

------_=_NextPart_001_01C3601B.38566378-- From owner-ietf-openproxy@mail.imc.org Mon Aug 11 11:49:29 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20750 for ; Mon, 11 Aug 2003 11:49:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mEvN-0006le-00 for opes-archive@ietf.org; Mon, 11 Aug 2003 11:49:34 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19mEvM-0006lb-00 for opes-archive@ietf.org; Mon, 11 Aug 2003 11:49:33 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BFXEqt050395 for ; Mon, 11 Aug 2003 08:33:14 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BFXET7050394 for ietf-openproxy-bks; Mon, 11 Aug 2003 08:33:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BFXDqt050381 for ; Mon, 11 Aug 2003 08:33:13 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7BFXD9Y028170 for ; Mon, 11 Aug 2003 11:33:13 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7BFX6F2059824 for ; Mon, 11 Aug 2003 11:33:07 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7BFX6kO020030 for ; Mon, 11 Aug 2003 11:33:06 -0400 (EDT) Message-ID: <3F37B786.2050309@mhof.com> Date: Mon, 11 Aug 2003 11:34:30 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: [end points comm] OPES System References: <87609AFB433BD5118D5E0002A52CD754068D532F@zcard0k6.ca.nortel.com> In-Reply-To: <87609AFB433BD5118D5E0002A52CD754068D532F@zcard0k6.ca.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Abbie, sure, so here's my understanding so far: An "OPES system" describes the collection of all OPES entities (i.e. OPES processors and callout servers) that are operated by a single provider (or, alternatively: ...within a single trust domain). If this describes what an "OPES system" was meant to be, I somehow don't like the term too much. Maybe the term "OPES domain" would be appropriate? -Markus Abbie Barbir wrote: > Markisn > > That is the main problem. We need a formal definition, since we refere to it > a lot in the draft. > > Abbie > > > >>-----Original Message----- >>From: Markus Hofmann [mailto:markus@mhof.com] >>Sent: Monday, August 11, 2003 10:52 AM >>To: OPES Group >>Subject: Re: [end points comm] OPES System >> >> >> >>Abbie Barbir wrote: >> >> >>>To start off the discussion, can we state that an OPES >> >>system is the >> >>>collection of entities that perform OPES transformations on a >>>request/responce within an OPES flow? >> >>Isn't there somewhere an assumption in the drafts that an "OPES >>System" describes OPES entities that are operated (or belong) to a >>single operatore/trustdomain/carrier? >> >>Thanks, >> Markus >> >> > > From owner-ietf-openproxy@mail.imc.org Mon Aug 11 12:39:45 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22393 for ; Mon, 11 Aug 2003 12:39:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mFi2-00073i-00 for opes-archive@ietf.org; Mon, 11 Aug 2003 12:39:50 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19mFi1-00073f-00 for opes-archive@ietf.org; Mon, 11 Aug 2003 12:39:49 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BGLhqt057047 for ; Mon, 11 Aug 2003 09:21:43 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BGLgpf057046 for ietf-openproxy-bks; Mon, 11 Aug 2003 09:21:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BGLfqt057037 for ; Mon, 11 Aug 2003 09:21:42 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7BGLZn27420; Mon, 11 Aug 2003 12:21:35 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Aug 2003 12:21:36 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754068D5412@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Markus Hofmann , OPES Group Subject: RE: [end points comm] OPES System Date: Mon, 11 Aug 2003 12:21:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36024.A1575932" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C36024.A1575932 Content-Type: text/plain Markus, SO are we saying that the system is static or the OPES flow can be dynamically decided (based on a user profile for eample) ABbie > -----Original Message----- > From: Markus Hofmann [mailto:markus@mhof.com] > Sent: Monday, August 11, 2003 11:35 AM > To: OPES Group > Subject: Re: [end points comm] OPES System > > > > Abbie, > > sure, so here's my understanding so far: > > An "OPES system" describes the collection of all OPES > entities (i.e. > OPES processors and callout servers) that are operated by a single > provider (or, alternatively: ...within a single trust domain). > > If this describes what an "OPES system" was meant to be, I somehow > don't like the term too much. Maybe the term "OPES domain" would be > appropriate? > > -Markus > > > > Abbie Barbir wrote: > > > Markisn > > > > That is the main problem. We need a formal definition, > since we refere > > to it a lot in the draft. > > > > Abbie > > > > > > > >>-----Original Message----- > >>From: Markus Hofmann [mailto:markus@mhof.com] > >>Sent: Monday, August 11, 2003 10:52 AM > >>To: OPES Group > >>Subject: Re: [end points comm] OPES System > >> > >> > >> > >>Abbie Barbir wrote: > >> > >> > >>>To start off the discussion, can we state that an OPES > >> > >>system is the > >> > >>>collection of entities that perform OPES transformations on a > >>>request/responce within an OPES flow? > >> > >>Isn't there somewhere an assumption in the drafts that an "OPES > >>System" describes OPES entities that are operated (or belong) to a > >>single operatore/trustdomain/carrier? > >> > >>Thanks, > >> Markus > >> > >> > > > > > > ------_=_NextPart_001_01C36024.A1575932 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [end points comm] OPES System

Markus,

SO are we saying that the system is static or the = OPES flow can be dynamically decided (based on a user profile for = eample)

ABbie


> -----Original Message-----
> From: Markus Hofmann [mailto:markus@mhof.com]
> Sent: Monday, August 11, 2003 11:35 AM
> To: OPES Group
> Subject: Re: [end points comm] OPES = System
>
>
>
> Abbie,
>
> sure, so here's my understanding so far:
>
>    An "OPES system" = describes the collection of all OPES
> entities (i.e.
>    OPES processors and callout = servers) that are operated by a single
>    provider (or, alternatively: = ...within a single trust domain).
>
> If this describes what an "OPES = system" was meant to be, I somehow
> don't like the term too much. Maybe the term = "OPES domain" would be
> appropriate?
>
> -Markus
>
>
>
> Abbie Barbir wrote:
>
> > Markisn
> >
> > That is the main problem. We need a formal = definition,
> since we refere
> > to it a lot in the draft.
> >
> > Abbie
> >
> >
> >
> >>-----Original Message-----
> >>From: Markus Hofmann [mailto:markus@mhof.com]
> >>Sent: Monday, August 11, 2003 10:52 = AM
> >>To: OPES Group
> >>Subject: Re: [end points comm] OPES = System
> >>
> >>
> >>
> >>Abbie Barbir wrote:
> >>
> >>
> >>>To start off the discussion, can we = state that an OPES
> >>
> >>system is the
> >>
> >>>collection of entities that perform = OPES transformations on a
> >>>request/responce within an OPES = flow?
> >>
> >>Isn't there somewhere an assumption in = the drafts that an "OPES
> >>System" describes OPES entities = that are operated (or belong) to a
> >>single = operatore/trustdomain/carrier?
> >>
> >>Thanks,
> >>   Markus
> >>
> >>
> >
> >
>
>

------_=_NextPart_001_01C36024.A1575932-- From owner-ietf-openproxy@mail.imc.org Mon Aug 11 13:05:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23192 for ; Mon, 11 Aug 2003 13:05:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mG6h-0007EX-00 for opes-archive@ietf.org; Mon, 11 Aug 2003 13:05:19 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19mG6h-0007EU-00 for opes-archive@ietf.org; Mon, 11 Aug 2003 13:05:19 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BGgwqt058203 for ; Mon, 11 Aug 2003 09:42:58 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BGgwKf058202 for ietf-openproxy-bks; Mon, 11 Aug 2003 09:42:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BGgvqt058194 for ; Mon, 11 Aug 2003 09:42:57 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.8/8.12.8) with ESMTP id h7BGdvxX009402; Mon, 11 Aug 2003 10:39:58 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id h7BGg0in007647; Mon, 11 Aug 2003 10:42:00 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h7BGfwtG007643; Mon, 11 Aug 2003 10:41:58 -0600 Date: Mon, 11 Aug 2003 10:41:58 -0600 Message-Id: <200308111641.h7BGfwtG007643@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: markus@mhof.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage <3F37B786.2050309@mhof.com> Subject: Re: [end points comm] OPES System Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think the concept of an "OPES system" being traceable, without requiring each OPES processor to be traceable, is unsupportable. It will not satisfy anyone, and it will lead to endless arguments about what constitutes compliance. Hilarie From owner-ietf-openproxy@mail.imc.org Mon Aug 11 13:51:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25924 for ; Mon, 11 Aug 2003 13:51:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mGp6-00004Z-00 for opes-archive@ietf.org; Mon, 11 Aug 2003 13:51:12 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19mGp5-00004W-00 for opes-archive@ietf.org; Mon, 11 Aug 2003 13:51:11 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BHZpqt061353 for ; Mon, 11 Aug 2003 10:35:51 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BHZpxE061352 for ietf-openproxy-bks; Mon, 11 Aug 2003 10:35:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BHZoqt061346 for ; Mon, 11 Aug 2003 10:35:50 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7BHZpHa006079 for ; Mon, 11 Aug 2003 13:35:51 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7BHZiF2069191 for ; Mon, 11 Aug 2003 13:35:44 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7BHZikO024312 for ; Mon, 11 Aug 2003 13:35:44 -0400 (EDT) Message-ID: <3F37D444.6030602@mhof.com> Date: Mon, 11 Aug 2003 13:37:08 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: [end points comm] OPES System References: <200308111641.h7BGfwtG007643@localhost.localdomain> In-Reply-To: <200308111641.h7BGfwtG007643@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit The Purple Streak, Hilarie Orman wrote: > I think the concept of an "OPES system" being traceable, without > requiring each OPES processor to be traceable, is unsupportable. > It will not satisfy anyone, and it will lead to endless arguments > about what constitutes compliance. If I recall correctly, there were two arguments that lead to this concept: (1) Carriers are typically hesitant to reveal information about their internal network infrastructure, i.e. they don't want to provide information (e.g. the IP address) about their internal network elements. (2) OPES processors might be configured to use non-routable, private IP addresses inside a carrier's network. How would they be identified? A user having problems/concerns would trace and contact the carrier who provided an OPES service (without tracing the exact OPES processor/callout server). It's up to the carrier to have maintained approriate internal detailed traces to find the answer to the customer's inquery. Anyone any thoughts or comments on that issue? This is a very important topic and we must get WG consensus on it, so please post your views to the mailing list! -Markus From owner-ietf-openproxy@mail.imc.org Mon Aug 11 13:51:13 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25940 for ; Mon, 11 Aug 2003 13:51:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mGpA-00004g-00 for opes-archive@ietf.org; Mon, 11 Aug 2003 13:51:16 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19mGp9-00004d-00 for opes-archive@ietf.org; Mon, 11 Aug 2003 13:51:16 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BHYBqt061274 for ; Mon, 11 Aug 2003 10:34:11 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BHYBeH061273 for ietf-openproxy-bks; Mon, 11 Aug 2003 10:34:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BHYAqt061263 for ; Mon, 11 Aug 2003 10:34:11 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7BHXMn09382; Mon, 11 Aug 2003 13:33:22 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Aug 2003 13:33:23 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754068D54FF@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: "The Purple Streak, Hilarie Orman" , markus@mhof.com Cc: ietf-openproxy@imc.org Subject: RE: [end points comm] OPES System Date: Mon, 11 Aug 2003 13:33:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3602E.A10DA918" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3602E.A10DA918 Content-Type: text/plain Hilarie, each processor (i know we do not talk about chaining) or one in a chain. what do we say about callout servers? (single or chain) Abbie > -----Original Message----- > From: The Purple Streak, Hilarie Orman [mailto:ho@alum.mit.edu] > Sent: Monday, August 11, 2003 12:42 PM > To: markus@mhof.com > Cc: ietf-openproxy@imc.org > Subject: Re: [end points comm] OPES System > > > > I think the concept of an "OPES system" being traceable, > without requiring each OPES processor to be traceable, is > unsupportable. It will not satisfy anyone, and it will lead > to endless arguments about what constitutes compliance. > > Hilarie > ------_=_NextPart_001_01C3602E.A10DA918 Content-Type: text/html RE: [end points comm] OPES System

Hilarie,

each processor (i know we do not talk about chaining) or one in a chain.
what do we say about callout servers? (single or chain)

Abbie


> -----Original Message-----
> From: The Purple Streak, Hilarie Orman [mailto:ho@alum.mit.edu]
> Sent: Monday, August 11, 2003 12:42 PM
> To: markus@mhof.com
> Cc: ietf-openproxy@imc.org
> Subject: Re: [end points comm] OPES System
>
>
>
> I think the concept of an "OPES system" being traceable,
> without requiring each OPES processor to be traceable, is
> unsupportable. It will not satisfy anyone, and it will lead
> to endless arguments about what constitutes compliance.
>
> Hilarie
>

------_=_NextPart_001_01C3602E.A10DA918-- From owner-ietf-openproxy@mail.imc.org Mon Aug 11 13:56:31 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26059 for ; Mon, 11 Aug 2003 13:56:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mGuJ-00006G-00 for opes-archive@ietf.org; Mon, 11 Aug 2003 13:56:35 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19mGuI-00006D-00 for opes-archive@ietf.org; Mon, 11 Aug 2003 13:56:34 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BHdpqt061678 for ; Mon, 11 Aug 2003 10:39:51 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BHdpqi061677 for ietf-openproxy-bks; Mon, 11 Aug 2003 10:39:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BHdoqt061672 for ; Mon, 11 Aug 2003 10:39:50 -0700 (PDT) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7BHdp9Y029214 for ; Mon, 11 Aug 2003 13:39:51 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7BHdi1u031350 for ; Mon, 11 Aug 2003 13:39:44 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7BHdikO024374 for ; Mon, 11 Aug 2003 13:39:44 -0400 (EDT) Message-ID: <3F37D534.3090804@mhof.com> Date: Mon, 11 Aug 2003 13:41:08 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: [end points comm] OPES System References: <87609AFB433BD5118D5E0002A52CD754068D5412@zcard0k6.ca.nortel.com> In-Reply-To: <87609AFB433BD5118D5E0002A52CD754068D5412@zcard0k6.ca.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Abbie Barbir wrote: > SO are we saying that the system is static or the OPES flow can be > dynamically decided (based on a user profile for eample) I had assumed that an "OPES system" (or and "OPES domain") describes the collection of OPES entities that a single carrier operates. As such, this would be independent of any specific OPES flow, and therefor static in your definition. (Are we talking about the same thing here?) Of course, every OPES flow can travel through different "OPES systems/domains". -Markus From owner-ietf-openproxy@mail.imc.org Mon Aug 11 14:23:26 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27212 for ; Mon, 11 Aug 2003 14:23:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mHKL-0000NR-00 for opes-archive@ietf.org; Mon, 11 Aug 2003 14:23:29 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19mHKL-0000NO-00 for opes-archive@ietf.org; Mon, 11 Aug 2003 14:23:29 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BI6Wqt063425 for ; Mon, 11 Aug 2003 11:06:32 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BI6WFc063423 for ietf-openproxy-bks; Mon, 11 Aug 2003 11:06:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BI6Vqt063415 for ; Mon, 11 Aug 2003 11:06:31 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7BI6Ob04149; Mon, 11 Aug 2003 14:06:24 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Aug 2003 14:06:25 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754068D556D@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Markus Hofmann , OPES Group Subject: RE: [end points comm] OPES System Date: Mon, 11 Aug 2003 14:06:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36033.45E097B2" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C36033.45E097B2 Content-Type: text/plain well, we need to clear these in the draft. Action item for me. abbie > -----Original Message----- > From: Markus Hofmann [mailto:markus@mhof.com] > Sent: Monday, August 11, 2003 1:41 PM > To: OPES Group > Subject: Re: [end points comm] OPES System > > > > Abbie Barbir wrote: > > > SO are we saying that the system is static or the OPES flow can be > > dynamically decided (based on a user profile for eample) > > I had assumed that an "OPES system" (or and "OPES domain") describes > the collection of OPES entities that a single carrier operates. As > such, this would be independent of any specific OPES flow, and > therefor static in your definition. (Are we talking about the same > thing here?) > > Of course, every OPES flow can travel through different "OPES > systems/domains". > > -Markus > > ------_=_NextPart_001_01C36033.45E097B2 Content-Type: text/html RE: [end points comm] OPES System

well,

we need to clear these in the draft.
Action item for me.

abbie

> -----Original Message-----
> From: Markus Hofmann [mailto:markus@mhof.com]
> Sent: Monday, August 11, 2003 1:41 PM
> To: OPES Group
> Subject: Re: [end points comm] OPES System
>
>
>
> Abbie Barbir wrote:
>
> > SO are we saying that the system is static or the OPES flow can be
> > dynamically decided (based on a user profile for eample)
>
> I had assumed that an "OPES system" (or and "OPES domain") describes
> the collection of OPES entities that a single carrier operates. As
> such, this would be independent of any specific OPES flow, and
> therefor static in your definition. (Are we talking about the same
> thing here?)
>
> Of course, every OPES flow can travel through different "OPES
> systems/domains".
>
> -Markus
>
>

------_=_NextPart_001_01C36033.45E097B2-- From owner-ietf-openproxy@mail.imc.org Mon Aug 11 16:19:23 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04612 for ; Mon, 11 Aug 2003 16:19:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mJ8Z-00022h-00 for opes-archive@ietf.org; Mon, 11 Aug 2003 16:19:27 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19mJ8Z-00022e-00 for opes-archive@ietf.org; Mon, 11 Aug 2003 16:19:27 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BK5Xqt070395 for ; Mon, 11 Aug 2003 13:05:33 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BK5XON070393 for ietf-openproxy-bks; Mon, 11 Aug 2003 13:05:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BK5Wqt070380 for ; Mon, 11 Aug 2003 13:05:32 -0700 (PDT) (envelope-from info@utel.net) Received: from f01v-25-252.d0.club-internet.fr ([212.195.244.252] helo=jfc2.utel.net) by hosting.altserver.com with esmtp (Exim 4.20) id 19mIv6-0002LH-DK; Mon, 11 Aug 2003 13:05:32 -0700 Message-Id: <5.2.0.9.0.20030811212907.0387cab0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 11 Aug 2003 21:40:19 +0200 To: Markus Hofmann , OPES Group From: jfcm Subject: Re: [end points comm] OPES System In-Reply-To: <3F37B786.2050309@mhof.com> References: <87609AFB433BD5118D5E0002A52CD754068D532F@zcard0k6.ca.nortel.com> <87609AFB433BD5118D5E0002A52CD754068D532F@zcard0k6.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 17:34 11/08/03, Markus Hofmann wrote: >Abbie, >sure, so here's my understanding so far: > > An "OPES system" describes the collection of all OPES entities (i.e. > OPES processors and callout servers) that are operated by a single > provider (or, alternatively: ...within a single trust domain). > >If this describes what an "OPES system" was meant to be, I somehow don't >like the term too much. Maybe the term "OPES domain" would be appropriate? I do not see why who is providing what would structurally interfere with the definition of a system. An OPES system is a system organized by someone to offer one or a set of edge services. If in so doing it uses thousand resources by a single or by thousand providers has no structural impact and should have no effect on the result. However who the someone is (user, called service, third party, community) may have an influence on the global nature of the system. An OPES domain maybe of interest to define the parts of an OPES system by a given operator, but we have to make clear that such an OPES domain may not be a sub-OPES system. jfc From owner-ietf-openproxy@mail.imc.org Mon Aug 11 17:13:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06676 for ; Mon, 11 Aug 2003 17:13:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mJzG-0002UQ-00 for opes-archive@ietf.org; Mon, 11 Aug 2003 17:13:54 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19mJzF-0002UM-00 for opes-archive@ietf.org; Mon, 11 Aug 2003 17:13:53 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BKuQqt074062 for ; Mon, 11 Aug 2003 13:56:26 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7BKuQHK074061 for ietf-openproxy-bks; Mon, 11 Aug 2003 13:56:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7BKuPqt074056 for ; Mon, 11 Aug 2003 13:56:25 -0700 (PDT) (envelope-from info@utel.net) Received: from f01v-25-252.d0.club-internet.fr ([212.195.244.252] helo=jfc2.utel.net) by hosting.altserver.com with esmtp (Exim 4.20) id 19mJiM-0000dz-C0 for ietf-openproxy@imc.org; Mon, 11 Aug 2003 13:56:26 -0700 Message-Id: <5.2.0.9.0.20030811225712.045792f0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 11 Aug 2003 23:02:54 +0200 To: OPES Group From: jfcm Subject: Re: [end points comm] OPES System Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: What about this? I presuppose we define in here system and domain. An OPES system is a system organized to permit its users to obtain a single or a coordinated set of open puggable edge services. Such a system can be statically and/or dynamically organized by its user, the community of its users, a host provider or any other third party. An OPES domain is the part of an OPES system belonging to a given operator. An OPES domain is not a sub-OPES system as it may need external ressources to provide services. OPES domains have no incidence on the structure of an OPES system, but they may influence its organization for different reasons such as security, payment, quality of service, delivery parameters, etc. particularly in the case of dynamicly prioritized organization and revamping choices. jfc From owner-ietf-openproxy@mail.imc.org Tue Aug 12 09:41:12 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13011 for ; Tue, 12 Aug 2003 09:41:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mZOm-0000UK-00 for opes-archive@ietf.org; Tue, 12 Aug 2003 09:41:16 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19mZOk-0000UH-00 for opes-archive@ietf.org; Tue, 12 Aug 2003 09:41:15 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CDOmqt068294 for ; Tue, 12 Aug 2003 06:24:48 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7CDOm5m068293 for ietf-openproxy-bks; Tue, 12 Aug 2003 06:24:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CDOkqt068286 for ; Tue, 12 Aug 2003 06:24:47 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7CDOc004738; Tue, 12 Aug 2003 09:24:38 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Aug 2003 09:24:38 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD7540694D71C@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: jfcm Cc: ietf-openproxy@imc.org Subject: RE: [end points comm] OPES System Date: Tue, 12 Aug 2003 09:01:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C360D1.D4B40ACA" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C360D1.D4B40ACA Content-Type: text/plain Jfc, good points. This is in-line with what I had in mine. So what are the requirements that we should impose on an OPES system? Abbie > -----Original Message----- > From: jfcm [mailto:info@utel.net] > Sent: Monday, August 11, 2003 3:40 PM > To: Markus Hofmann; OPES Group > Subject: Re: [end points comm] OPES System > > > > At 17:34 11/08/03, Markus Hofmann wrote: > >Abbie, > >sure, so here's my understanding so far: > > > > An "OPES system" describes the collection of all OPES > entities (i.e. > > OPES processors and callout servers) that are operated by a single > > provider (or, alternatively: ...within a single trust domain). > > > >If this describes what an "OPES system" was meant to be, I somehow > >don't > >like the term too much. Maybe the term "OPES domain" would > be appropriate? > > I do not see why who is providing what would structurally > interfere with > the definition of a system. > > An OPES system is a system organized by someone to offer one > or a set of > edge services. If in so doing it uses thousand resources by a > single or by > thousand providers has no structural impact and should have > no effect on > the result. However who the someone is (user, called > service, third party, > community) may have an influence on the global nature of the system. > > An OPES domain maybe of interest to define the parts of an > OPES system by a > given operator, but we have to make clear that such an OPES > domain may not > be a sub-OPES system. > > jfc > > > > ------_=_NextPart_001_01C360D1.D4B40ACA Content-Type: text/html RE: [end points comm] OPES System

Jfc,
good points. This is in-line with what I had in mine.

So what are the requirements that we should impose on an OPES system?

Abbie



> -----Original Message-----
> From: jfcm [mailto:info@utel.net]
> Sent: Monday, August 11, 2003 3:40 PM
> To: Markus Hofmann; OPES Group
> Subject: Re: [end points comm] OPES System
>
>
>
> At 17:34 11/08/03, Markus Hofmann wrote:
> >Abbie,
> >sure, so here's my understanding so far:
> >
> >   An "OPES system" describes the collection of all OPES
> entities (i.e.
> >   OPES processors and callout servers) that are operated by a single
> >   provider (or, alternatively: ...within a single trust domain).
> >
> >If this describes what an "OPES system" was meant to be, I somehow
> >don't
> >like the term too much. Maybe the term "OPES domain" would
> be appropriate?
>
> I do not see why who is providing what would structurally
> interfere with
> the definition of a system.
>
> An OPES system is a system organized by someone to offer one
> or a set of
> edge services. If in so doing it uses thousand resources by a
> single or by
> thousand providers has no structural impact and should have
> no effect on
> the result.  However who the someone is (user, called
> service, third party,
> community) may have an influence on the global nature of the system.
>
> An OPES domain maybe of interest to define the parts of an
> OPES system by a
> given operator, but we have to make clear that such an OPES
> domain may not
> be a sub-OPES system.
>
> jfc
>
>
>
>

------_=_NextPart_001_01C360D1.D4B40ACA-- From owner-ietf-openproxy@mail.imc.org Tue Aug 12 09:57:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13555 for ; Tue, 12 Aug 2003 09:57:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mZep-0000ZZ-00 for opes-archive@ietf.org; Tue, 12 Aug 2003 09:57:52 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19mZep-0000ZW-00 for opes-archive@ietf.org; Tue, 12 Aug 2003 09:57:51 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CDjjqt069424 for ; Tue, 12 Aug 2003 06:45:45 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7CDjj91069422 for ietf-openproxy-bks; Tue, 12 Aug 2003 06:45:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CDjiqt069413 for ; Tue, 12 Aug 2003 06:45:44 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7CDji9Y034654 for ; Tue, 12 Aug 2003 09:45:44 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7CDjcF2045777 for ; Tue, 12 Aug 2003 09:45:38 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7CDjZkO010769 for ; Tue, 12 Aug 2003 09:45:37 -0400 (EDT) Message-ID: <3F38EFD4.3010505@mhof.com> Date: Tue, 12 Aug 2003 09:47:00 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: [end points comm] OPES System References: <87609AFB433BD5118D5E0002A52CD754068D532F@zcard0k6.ca.nortel.com> <87609AFB433BD5118D5E0002A52CD754068D532F@zcard0k6.ca.nortel.com> <5.2.0.9.0.20030811212907.0387cab0@mail.utel.net> In-Reply-To: <5.2.0.9.0.20030811212907.0387cab0@mail.utel.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit jfcm wrote: > I do not see why who is providing what would structurally interfere with > the definition of a system. > > An OPES system is a system organized by someone to offer one or a set of > edge services. If in so doing it uses thousand resources by a single or > by thousand providers has no structural impact and should have no effect > on the result. In the context we talked about, it is important that the "OPES system" is operated by a single provider, or that all elements of the "OPES system" are in the same trust domain. As such, the notion of an "OPES domain" comes to mind. Also, as my advisor used to say, the term "system" is typically used when it's not clear what it refers to... :) A "system" can be anything and nothing, so if we can come up with a more specific term... -Markus From owner-ietf-openproxy@mail.imc.org Tue Aug 12 10:13:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14836 for ; Tue, 12 Aug 2003 10:13:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mZti-0000kO-00 for opes-archive@ietf.org; Tue, 12 Aug 2003 10:13:14 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19mZtg-0000kL-00 for opes-archive@ietf.org; Tue, 12 Aug 2003 10:13:13 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CDwFqt071809 for ; Tue, 12 Aug 2003 06:58:15 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7CDwFDA071808 for ietf-openproxy-bks; Tue, 12 Aug 2003 06:58:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CDwDqt071800 for ; Tue, 12 Aug 2003 06:58:13 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7CDwB9Y034736 for ; Tue, 12 Aug 2003 09:58:11 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7CDw4F2047106 for ; Tue, 12 Aug 2003 09:58:05 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7CDw4kO011057 for ; Tue, 12 Aug 2003 09:58:04 -0400 (EDT) Message-ID: <3F38F2C1.9040701@mhof.com> Date: Tue, 12 Aug 2003 09:59:29 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: [end points comm] OPES System References: <5.2.0.9.0.20030811225712.045792f0@mail.utel.net> In-Reply-To: <5.2.0.9.0.20030811225712.045792f0@mail.utel.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit jfcm wrote: > An OPES system is a system organized to permit its users to obtain a > single or a coordinated set of open puggable edge services. Such a > system can be statically and/or dynamically organized by its user, the > community of its users, a host provider or any other third party. An > OPES domain is the part of an OPES system belonging to a given operator. > An OPES domain is not a sub-OPES system as it may need external > ressources to provide services. OPES domains have no incidence on the > structure of an OPES system, but they may influence its organization for > different reasons such as security, payment, quality of service, > delivery parameters, etc. particularly in the case of dynamicly > prioritized organization and revamping choices. I basically agree, but I don't see the need to formally define the term "OPES system". If we've the notion of an OPES domain as indicated above - in which draft and where would we need the term "OPES system"? Let's simply say that "An OPES domain describes all OPES entities operated by a single provider". I would assume that's all we need in the context we talked about. Also, please keep in mind Hilarie's view on the need to identify every single OPES processor and post your thoughts to the list. If consensus would be that each single OPES processor needs to be identified, we might not even need the notion of an "OPES domain". -Markus From owner-ietf-openproxy@mail.imc.org Tue Aug 12 11:15:42 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18457 for ; Tue, 12 Aug 2003 11:15:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19masE-0001WH-00 for opes-archive@ietf.org; Tue, 12 Aug 2003 11:15:46 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19masD-0001WA-00 for opes-archive@ietf.org; Tue, 12 Aug 2003 11:15:45 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CEwxqt077238 for ; Tue, 12 Aug 2003 07:58:59 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7CEwwkt077237 for ietf-openproxy-bks; Tue, 12 Aug 2003 07:58:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7CEwvqt077230 for ; Tue, 12 Aug 2003 07:58:58 -0700 (PDT) (envelope-from info@utel.net) Received: from f01m-31-79.d0.club-internet.fr ([212.195.230.79] helo=jfc2.utel.net) by hosting.altserver.com with esmtp (Exim 4.20) id 19mabr-00071B-UO for ietf-openproxy@imc.org; Tue, 12 Aug 2003 07:58:53 -0700 Message-Id: <5.2.0.9.0.20030812165653.02abc350@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 12 Aug 2003 17:05:15 +0200 To: ietf-openproxy@imc.org From: jfcm Subject: Re: [end points comm] OPES System In-Reply-To: <3F38F2C1.9040701@mhof.com> References: <5.2.0.9.0.20030811225712.045792f0@mail.utel.net> <5.2.0.9.0.20030811225712.045792f0@mail.utel.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Very very strong objection to this. - military forces in Iraq are a military system made to free Iraq by GW Bush - UK milirary forces in Iraq are a Bristh domain of forces contributing to that system - Polish miliratry forces could join the system in Irak at a latter stage. In no way the US, the UK and the Polish domain can quailfy as the self sustainable military system that GW Bush deemed necessary to protect the world from Iraqi mass destruction weapons. I just picked that controversial image because it will be clearer to everyone. And that every one will easily understand that there are many differences/gateays between US, UK , Polish military domains in terms of equipment, security, chains of commands, standards, languages, operation protocols, etc. Defining OPES is like definining the Iraqi strategy. Defining the OPES system as definiing the way for the user (GWB) will organize the necessary resources. Talking of OPES domains is like defining the possible independent contributions to the OPES system. jfc On 15:59 12/08/03, Markus Hofmann said: >jfcm wrote: > >>An OPES system is a system organized to permit its users to obtain a >>single or a coordinated set of open puggable edge services. Such a system >>can be statically and/or dynamically organized by its user, the community >>of its users, a host provider or any other third party. An OPES domain is >>the part of an OPES system belonging to a given operator. An OPES domain >>is not a sub-OPES system as it may need external ressources to provide >>services. OPES domains have no incidence on the structure of an OPES >>system, but they may influence its organization for different reasons >>such as security, payment, quality of service, delivery parameters, etc. >>particularly in the case of dynamicly prioritized organization and >>revamping choices. > >I basically agree, but I don't see the need to formally define the term >"OPES system". If we've the notion of an OPES domain as indicated above - >in which draft and where would we need the term "OPES system"? > >Let's simply say that "An OPES domain describes all OPES entities operated >by a single provider". I would assume that's all we need in the context we >talked about. > >Also, please keep in mind Hilarie's view on the need to identify every >single OPES processor and post your thoughts to the list. If consensus >would be that each single OPES processor needs to be identified, we might >not even need the notion of an "OPES domain". From owner-ietf-openproxy@mail.imc.org Wed Aug 13 12:35:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25382 for ; Wed, 13 Aug 2003 12:35:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19myag-00032s-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 12:35:14 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19myag-00032n-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 12:35:14 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DGDoqt095187 for ; Wed, 13 Aug 2003 09:13:50 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DGDokk095186 for ietf-openproxy-bks; Wed, 13 Aug 2003 09:13:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DGDmqt095178 for ; Wed, 13 Aug 2003 09:13:49 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7DGDnMS041983; Wed, 13 Aug 2003 10:13:49 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7DGDdmU041976; Wed, 13 Aug 2003 10:13:39 -0600 (MDT) (envelope-from rousskov) Date: Wed, 13 Aug 2003 10:13:39 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: OPES WG Subject: Re: draft-beck-opes-irml-03.txt In-Reply-To: <3F21316F.5030504@mhof.com> Message-ID: References: <3EF8CADD.2060201@bell-labs.com> <3EF905A5.9000100@mhof.com> <3F0087EF.6020805@bell-labs.com> <3F20454E.9090706@mhof.com> <3F21316F.5030504@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 25 Jul 2003, Markus Hofmann wrote: > Alex Rousskov wrote: > > > I will try to show that XML presents virtually no advantages > > compared to a domain specific language and introduces significant > > hurdles. > > I assume "domain specific language" implies a "custom/new/specific" > language? Yes (assuming there is not one available already). Please note that proposed IRML is also a new domain specific language. > If so, allow me to raise flag in that we should use existing > approaches (e.g. XML or others) as long as they don't have serious > disadvantages, rather than inventing everything ourselves. It looks like I may have introduced a terminology/classification problem. Rules Language can use XML or, say, UTF-8 to represent its tokens. Both XML and UTF-8 are "existing approaches". The main problem with XML is that in addition to providing lexical tokens for the Rules Language, XML demands certain hierarchical relationship and order between language statements. IMO, that relationship and order are note appropriate for a good Rules Language because they do not exist in the original Rules Manipulation domain. In other words, it is not a question of reusing an existing encoding. It is a question of using the right existing encoding. Alex. From owner-ietf-openproxy@mail.imc.org Wed Aug 13 12:49:33 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25668 for ; Wed, 13 Aug 2003 12:49:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19myob-00038O-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 12:49:37 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19myoa-00038L-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 12:49:36 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DGUJqt097269 for ; Wed, 13 Aug 2003 09:30:19 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DGUJBb097268 for ietf-openproxy-bks; Wed, 13 Aug 2003 09:30:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DGUIqt097262 for ; Wed, 13 Aug 2003 09:30:18 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7DGUJMS042345 for ; Wed, 13 Aug 2003 10:30:19 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7DGUJsT042344; Wed, 13 Aug 2003 10:30:19 -0600 (MDT) (envelope-from rousskov) Date: Wed, 13 Aug 2003 10:30:19 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: property element in draft-beck-opes-irml-03 In-Reply-To: <3F0087EF.6020805@bell-labs.com> Message-ID: References: <3EF8CADD.2060201@bell-labs.com> <3EF905A5.9000100@mhof.com> <3F0087EF.6020805@bell-labs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I am confused by the "property" element. 3.6.1 The "property" Element The "property" element represents a rule condition and MAY contain one or more other "property" elements and/or one or more elements representing rule actions, i.e. "execute" elements. My interpretation of the above is that the "property" element is defined as "rule condition" that may contain other rule conditions and rule actions. In other words, property element is the rule itself: if "condition" then do "action" This should be clarified. Either "property" is a condition or it is an action. If it is a condition (logical expression), then why is it called "property"? If it is both condition and action, then why it is not called a "rule"? Alex. From owner-ietf-openproxy@mail.imc.org Wed Aug 13 13:29:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26726 for ; Wed, 13 Aug 2003 13:29:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mzQz-0003Nr-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 13:29:17 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19mzQy-0003No-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 13:29:17 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DHBNqt099551 for ; Wed, 13 Aug 2003 10:11:23 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DHBN7O099549 for ietf-openproxy-bks; Wed, 13 Aug 2003 10:11:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DHBLqt099537 for ; Wed, 13 Aug 2003 10:11:21 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7DHBJMS043368; Wed, 13 Aug 2003 11:11:19 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7DHBJiP043367; Wed, 13 Aug 2003 11:11:19 -0600 (MDT) (envelope-from rousskov) Date: Wed, 13 Aug 2003 11:11:19 -0600 (MDT) From: Alex Rousskov To: OPES WG cc: Andre Beck Subject: Re: draft-beck-opes-irml-03.txt In-Reply-To: <3F0087EF.6020805@bell-labs.com> Message-ID: References: <3EF8CADD.2060201@bell-labs.com> <3EF905A5.9000100@mhof.com> <3F0087EF.6020805@bell-labs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 30 Jun 2003, Andre Beck wrote: > Alex Rousskov wrote: > > > 1) IRLM is closely tied to a very narrow interpretation of the > > OPES architecture. The language should focus on a more general > > (yet well-scoped) task of expressing a message adaptation rule: > > > > if "condition" then do "action"; > > > > The "condition" expression should be powerful enough to express > > a mixture of processing points, processor state, application > > message properties, and extensions. The draft artificially > > segregates, for example, processing points, from message > > properties, severely limiting expression power. > > I don't consider the processing point a rule condition. Rather, I > believe it's a rule attribute as it specifies when a rule is to be > processed. As such, I don't see how the current IRML design limits > expression power. Can you think of a specific example that shows > where IRML lacks expression power? condition1 := processing_point == 2 or processing_point == 5 condition2 := message_headers contain "Connection" or message_headers contain "Proxy-Connection" rule := if condition1 and condition2 then do_something; Is there a good way to express the above logic using irml-03? BTW, the above example also illustrates (without details) how a UTF-8-based rule language could express the desired logic. Note that the use of processing_point is not really essential (moreover, documenting specific processing points is not appropriate for an application-agnostic rule language). Similar examples can be made with other attributes. For example, ... conditionA := condition1 and condition0; conditionB := condition2 and not condition0 rule := if conditionA or conditionB then do_something; While I was not technically accurate what I used the term "expression power", I hope the above examples illustrate that proposed irml-03 does not let us express the above logic in a good/convenient/suitable/efficient "enough" form. > > 2) IRML attempts to enforce rules authorship. IMO, the Rule > > Specification language must focus on specifying the rules, not > > trying to specify or enforce who has the right to submit or execute > > them. For example, imagine C or Java languages with constructs to > > specify/enforce software copyright. I believe that rights > > specification and enforcement requires different mechanisms from > > rules specification. Moreover, both mechanisms lack key features in > > the current draft. > > I am not sure IRML attempts to enforce rule authorship/authorization. It > does allow rule authors to specify rule authorship/authorization, but > how this is enforced is up to the OPES processor or whatever OPES > element receives IRML rules. The specs seem to enforce authorization (Section 4, IRML Rule Processing): For each data transaction the rule processor on the intermediary located in the path between data consumers and data providers MUST process only those IRML rule sets that ... contain rule sets which have been authorized by either endpoint of the transaction. > Generally, I agree with your statement, though. > > > 3) I doubt that efficient rule processing would be possible with IRML. > > The language provides no mechanisms to reuse groups of rules (e.g., > > procedures or functions) or to reuse computation results (i.e., > > variables). Without such mechanisms, a realistic IRML program will > > be slow. It will also be huge and difficult to manage. > > Well, we never envisioned that an OPES processor would actually > process IRML rule files on the fly as it receives user > requests/responses. Instead, we figured that there would be a > separate offline process that receives IRML rule files from external > sources, validates them and subsequently translates them into some > internal, proprietary format optimized for efficient rule > processing. Sorry if I missed this very important assumption in the spec. It seems to me that this assumption limits irml-03 applicability to intermediaries with which content providers have a long-lasting and mostly static relationship. IMO, the primary value of Rules Language (from IETF point of view) would be to allow dynamic rule interpretation and inclusion of rules with application message metadata. For example, if we are talking about HTTP adaptation, the content provider should be able to say something like this using HTTP response headers: OPES-Rule: if condition1 do apply_service1; Does everybody agree that support of such dynamic and/or embedded rules is out of scope? > > 4) I question the choice of XML syntax. Rule specification is much > > closer to a program than it is to a static tree of configuration > > options. I believe that the history of languages used to express > > application routing, load balancing, and filtering decisions at > > intermediaries proves my point: while the industry has started with > > simple maps and tables, the application-level requirements forced > > implementors to support much more flexible rule programming. The > > choice of XML as IRLM syntax makes it very awkward to express > > anything that goes beyond a simple rule. IMO, XML must not be used > > as a programming language syntax. > > I don't think it's realistic to expect that OPES processors would be > able to process whatever you can express with a full-fledged programming > language just to determine which requests/responses need further OPES > processing. Neither do I. There is a lot of room between irml-03 and a "full-fledged programming language". > This would probably impose an unacceptable performance penalty on > those transactions that don't need further processing. Also, I doubt > that a service provider would let external rule authors specify > complex rule logic that could use up any amount of processing power, > e.g. through loops etc. For these reasons we decided to keep IRML > rules very simple and XML seems to be a very suitable format to do > just that. Clearly, there is a trade-off between what the rules can do and how much processing is needed to interpret them. IMO, there are many useful enough cases that can be processed more efficiently than irml-03 (due to its simplifications/limitations) allows. See examples above. > > XML justification in the draft is "many publicly available parsers > > and editing tools can be used". This is a very weak argument > > because (a) getting XML tree parsed is only a minor step towards > > interpreting IRML and > > True, but would this second step by any easier if we used a different > format? Maybe not. That is exactly why this argument should not be used. All reasonable language formats would require at most the pre-interpretation expenses of irml-03. > > (b) there are more XML-unaware editing tools > > than XML-aware editing tools. > > True, but then again non-XML formats would have the same problem, right? Hard to say. There are more ASCII-aware editing tools than there are XML-aware editing tools. It is a question of whether generic editing tools can assist rules writing enough to justify a particular encoding format. IMO, no, they cannot (and so this argument should not be used). Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Wed Aug 13 14:17:25 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28616 for ; Wed, 13 Aug 2003 14:17:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n0Bc-0003kE-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 14:17:28 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19n0Bb-0003kB-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 14:17:27 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DHvDqt002845 for ; Wed, 13 Aug 2003 10:57:13 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DHvD4d002844 for ietf-openproxy-bks; Wed, 13 Aug 2003 10:57:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DHvCqt002839 for ; Wed, 13 Aug 2003 10:57:12 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7DHvDMS044419; Wed, 13 Aug 2003 11:57:13 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7DHvDhV044418; Wed, 13 Aug 2003 11:57:13 -0600 (MDT) (envelope-from rousskov) Date: Wed, 13 Aug 2003 11:57:13 -0600 (MDT) From: Alex Rousskov To: OPES Group cc: Markus Hofmann Subject: Re: [end points comm] OPES System In-Reply-To: <3F38F2C1.9040701@mhof.com> Message-ID: References: <5.2.0.9.0.20030811225712.045792f0@mail.utel.net> <3F38F2C1.9040701@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 12 Aug 2003, Markus Hofmann wrote: > I don't see the need to formally define the term "OPES system". If > we've the notion of an OPES domain as indicated above - in which > draft and where would we need the term "OPES system"? Tracing/bypass draft. We need to define either "OPES system" or "OPES domain" as the primary traceable/addressable entity. OPES system is not currently defined. OPES domain is semi-defined in draft-ietf-opes-architecture-04. > Let's simply say that "An OPES domain describes all OPES entities > operated by a single provider". I would assume that's all we need in > the context we talked about. I have to disagree. If Disney distributes its content with the help of Akamai, Akamai entities belong to the same OPES domain/system as Disney entities but are not operated by Disney. In fact, from an end user or trust point of view, Disney and Akamai are (should be) indistinguishable in this case -- they form a single OPES system/domain. > Also, please keep in mind Hilarie's view on the need to identify > every single OPES processor and post your thoughts to the list. If > consensus would be that each single OPES processor needs to be > identified, we might not even need the notion of an "OPES domain". I think it is totally unrealistic to expect/require every single OPES processor to be identified in a trace. Moreover, I see no practical value of such trace for the other side (the side reading the trace). Internal structure of an OPES system is that system internal matter. Knowing internals does not help the other side. Tracing and bypass requirements must be defined for OPES systems/domains. Here is where I would start: OPES system: OPES system is a set of OPES entities defined for a given application message. The formation of an OPES system is recursive: OPES system starts with either data provider or data consumer (for the given message); OPES system then includes any OPES entity trusted by (accepting authority from) an entity already in the OPES system. The trust and authority delegation is viewed in the context of the given application message. As implied by the above definition, some OPES entities in the system may not participate in the processing of a given message. Or we can use the "coloring" trick from draft-ietf-opes-architecture-04. Just make sure that the end (provider/consumer) is included in the OPES domain/system and that the definition is based on a given message. The above definition puts both Disney and Akamai into one OPES system, for a given application message they may process. Moreover, if Disney uses both Akamai and Mirror Image (or whatever) for content distribution, the distinction would be made on a per-message (per-content) basis, which is the right thing to do because Akamai and Mirror Image do not necessarily belong to the same OPES domain/system. Alex. From owner-ietf-openproxy@mail.imc.org Wed Aug 13 14:18:47 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28662 for ; Wed, 13 Aug 2003 14:18:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n0Cv-0003ki-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 14:18:49 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19n0Cu-0003kf-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 14:18:48 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DI3Fqt003121 for ; Wed, 13 Aug 2003 11:03:15 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DI3FP8003120 for ietf-openproxy-bks; Wed, 13 Aug 2003 11:03:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DI3Eqt003115 for ; Wed, 13 Aug 2003 11:03:14 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7DI2cMS045634; Wed, 13 Aug 2003 12:02:38 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7DI2cs8045633; Wed, 13 Aug 2003 12:02:38 -0600 (MDT) (envelope-from rousskov) Date: Wed, 13 Aug 2003 12:02:37 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: Re: [end points comm] OPES System In-Reply-To: <200308111641.h7BGfwtG007643@localhost.localdomain> Message-ID: References: <200308111641.h7BGfwtG007643@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 11 Aug 2003, The Purple Streak, Hilarie Orman wrote: > I think the concept of an "OPES system" being traceable, without > requiring each OPES processor to be traceable, is unsupportable. What do you mean by "unsupportable"? From protocol and implementation point of view it is much easier to trace larger things (a well-known collection of entities) than every single entity in that collection. > It will not satisfy anyone, and it will lead to endless arguments > about what constitutes compliance. Tracing OPES systems satisfies me :-). While I agree that endless arguments about compliance are unavoidable, I do not think that tracing individual system components will stop those arguments. To start with, "OPES processor" is not currently defined (AFAIK). Alex. From owner-ietf-openproxy@mail.imc.org Wed Aug 13 15:52:44 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04100 for ; Wed, 13 Aug 2003 15:52:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n1fr-0004g4-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 15:52:47 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19n1fq-0004g1-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 15:52:46 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DJWPqt006149 for ; Wed, 13 Aug 2003 12:32:25 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DJWPhs006148 for ietf-openproxy-bks; Wed, 13 Aug 2003 12:32:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DJWOqt006142 for ; Wed, 13 Aug 2003 12:32:24 -0700 (PDT) (envelope-from markus@mhof.com) Received: from mail.messagingengine.com (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 530119B0FE for ; Wed, 13 Aug 2003 15:32:25 -0400 (EDT) Received: from 10.202.2.150 ([10.202.2.150] helo=mail.messagingengine.com) by messagingengine.com with SMTP; Wed, 13 Aug 2003 15:32:25 -0400 X-Epoch: 1060803145 X-Sasl-enc: pdWoaeMAauM1MR1YhlcfTw Received: from mhof.com (unknown [135.104.86.27]) by www.fastmail.fm (Postfix) with ESMTP id B38D99BD73 for ; Wed, 13 Aug 2003 15:32:24 -0400 (EDT) Message-ID: <3F3A92E2.4020806@mhof.com> Date: Wed, 13 Aug 2003 15:34:58 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: draft-beck-opes-irml-03.txt References: <3EF8CADD.2060201@bell-labs.com> <3EF905A5.9000100@mhof.com> <3F0087EF.6020805@bell-labs.com> <3F20454E.9090706@mhof.com> <3F21316F.5030504@mhof.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > Yes (assuming there is not one available already). Please note that > proposed IRML is also a new domain specific language. Yup, but the usage of XML, for example, allows to very easily and very quickly implement an IRML parser using exisitng XML parsers - you almost get it for free. Sure, if there are other (or even more approriate) existing schemas/languages/etc., we need to discuss their suitability and decide on the most approriate one. All I'm saying is let's have a look at what's out there rather than always wanting to design our own new stuff from scratch... which I believe to understand you agree with. > In other words, it is not a question of reusing an existing encoding. > It is a question of using the right existing encoding. Correct. Using XML was partially inspired by CPL (Call Processing Language), which is used for similar problems in the SIP area. We should learn from their experience - both positive and negative. -Markus From owner-ietf-openproxy@mail.imc.org Wed Aug 13 16:10:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04494 for ; Wed, 13 Aug 2003 16:10:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n1wg-0004jQ-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 16:10:10 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19n1wf-0004jN-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 16:10:09 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DJq0qt006846 for ; Wed, 13 Aug 2003 12:52:00 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DJq0MG006845 for ietf-openproxy-bks; Wed, 13 Aug 2003 12:52:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DJpxqt006837 for ; Wed, 13 Aug 2003 12:51:59 -0700 (PDT) (envelope-from markus@mhof.com) Received: from mail.messagingengine.com (localhost [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 667E99AE3F for ; Wed, 13 Aug 2003 15:52:00 -0400 (EDT) Received: from 10.202.2.150 ([10.202.2.150] helo=mail.messagingengine.com) by messagingengine.com with SMTP; Wed, 13 Aug 2003 15:52:00 -0400 X-Epoch: 1060804320 X-Sasl-enc: GsoCwVjHbJZR4uGnpFJi+w Received: from mhof.com (unknown [135.104.86.27]) by www.fastmail.fm (Postfix) with ESMTP id CA16E9C385 for ; Wed, 13 Aug 2003 15:51:59 -0400 (EDT) Message-ID: <3F3A9779.4030901@mhof.com> Date: Wed, 13 Aug 2003 15:54:33 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: [end points comm] OPES System References: <5.2.0.9.0.20030811225712.045792f0@mail.utel.net> <3F38F2C1.9040701@mhof.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > Tracing/bypass draft. We need to define either "OPES system" or "OPES > domain" as the primary traceable/addressable entity. That's exactly what I said - we need either one, but not both. > I have to disagree. If Disney distributes its content with the help of > Akamai, Akamai entities belong to the same OPES domain/system as > Disney entities but are not operated by Disney. In fact, from an end > user or trust point of view, Disney and Akamai are (should be) > indistinguishable in this case -- they form a single OPES > system/domain. If Disney's (original) Web servers are operated by Akamai, they're part of the same OPES domain as Akamai entities. If they're not operated by Akamai, they do not belong to the same OPES domain. I don't see yet why Disney and Akamai should be indistinguishable in the latter case. If something goes wrong on an OPES entity operated by Akamai, I've to turn to Akamai, if something goes wrong on a Disney server, I need to turn to Disney. > Here is where I would start: > > OPES system: OPES system is a set of OPES entities > defined for a given application message. The formation of an > OPES system is recursive: OPES system starts with either data > provider or data consumer (for the given message); OPES system > then includes any OPES entity trusted by (accepting authority > from) an entity already in the OPES system. The trust and > authority delegation is viewed in the context of the given > application message. As implied by the above definition, some > OPES entities in the system may not participate in the > processing of a given message. Hm... Assume a carrier A trusting carrier B. According to above definition, they both form an OPES system/domain. As such, they're identified by a single OPES trace entry. To whom would an end user turn if there're any problems? I'm wondering whether - for tracing purposes - an OPES system/domain should be defined by trust boundaries or by operational boundaries. -Markus From owner-ietf-openproxy@mail.imc.org Wed Aug 13 16:30:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04863 for ; Wed, 13 Aug 2003 16:30:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n2GG-0004pE-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 16:30:24 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19n2GF-0004pB-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 16:30:24 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DKDXqt007516 for ; Wed, 13 Aug 2003 13:13:33 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DKDXlI007515 for ietf-openproxy-bks; Wed, 13 Aug 2003 13:13:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DKDWqt007510 for ; Wed, 13 Aug 2003 13:13:32 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7DKDYMS048686; Wed, 13 Aug 2003 14:13:34 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7DKDY7K048685; Wed, 13 Aug 2003 14:13:34 -0600 (MDT) (envelope-from rousskov) Date: Wed, 13 Aug 2003 14:13:34 -0600 (MDT) From: Alex Rousskov To: OPES WG cc: Markus Hofmann Subject: Re: draft-beck-opes-irml-03.txt In-Reply-To: <3F3A92E2.4020806@mhof.com> Message-ID: References: <3EF8CADD.2060201@bell-labs.com> <3EF905A5.9000100@mhof.com> <3F0087EF.6020805@bell-labs.com> <3F20454E.9090706@mhof.com> <3F21316F.5030504@mhof.com> <3F3A92E2.4020806@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 13 Aug 2003, Markus Hofmann wrote: > Alex Rousskov wrote: > > > Yes (assuming there is not one available already). Please note that > > proposed IRML is also a new domain specific language. > > Yup, but the usage of XML, for example, allows to very easily and very > quickly implement an IRML parser using exisitng XML parsers - you > almost get it for free. I believe this is a common misconception about XML. XML does not make parsing much easier than any BNF-defined syntax. Just like there are existing parsers for XML, there are existing parser-generators for arbitrary BNFs (YACC, Spirit, etc.). Practical usefulness of either for production interpreters and compilers is about the same. > Sure, if there are other (or even more approriate) existing > schemas/languages/etc., we need to discuss their suitability and > decide on the most approriate one. All I'm saying is let's have a > look at what's out there rather than always wanting to design our > own new stuff from scratch... which I believe to understand you > agree with. Absolutely. XML parsers exist. BNF parser-generators exist. IRML defines an XML DTD. It could use a BNF instead. Both approaches would reuse existing facilities to a similar degree. > Correct. Using XML was partially inspired by CPL (Call Processing > Language), which is used for similar problems in the SIP area. We > should learn from their experience - both positive and negative. Interesting. I need to look CPL up. My comments are based, in part, on experience with ACLs (Access Control Lists) languages and other configuration issues for HTTP intermediaries and L2-7 switches. Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Wed Aug 13 16:52:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05486 for ; Wed, 13 Aug 2003 16:52:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n2bJ-0004wn-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 16:52:09 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19n2bI-0004wi-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 16:52:08 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DKXlqt009102 for ; Wed, 13 Aug 2003 13:33:47 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DKXlcx009100 for ietf-openproxy-bks; Wed, 13 Aug 2003 13:33:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DKXkqt009093 for ; Wed, 13 Aug 2003 13:33:46 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7DKXmMS049146; Wed, 13 Aug 2003 14:33:48 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7DKXmu2049145; Wed, 13 Aug 2003 14:33:48 -0600 (MDT) (envelope-from rousskov) Date: Wed, 13 Aug 2003 14:33:48 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: Re: [end points comm] OPES System In-Reply-To: <3F3A9779.4030901@mhof.com> Message-ID: References: <5.2.0.9.0.20030811225712.045792f0@mail.utel.net> <3F38F2C1.9040701@mhof.com> <3F3A9779.4030901@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 13 Aug 2003, Markus Hofmann wrote: > > I have to disagree. If Disney distributes its content with the > > help of Akamai, Akamai entities belong to the same OPES > > domain/system as Disney entities but are not operated by Disney. > > In fact, from an end user or trust point of view, Disney and > > Akamai are (should be) indistinguishable in this case -- they form > > a single OPES system/domain. > > If Disney's (original) Web servers are operated by Akamai, they're > part of the same OPES domain as Akamai entities. If they're not > operated by Akamai, they do not belong to the same OPES domain. The content you receive is produced _both_ by OPES entities operated by Disney and OPES entities operated by Akamai. Each company operates its own entities, and the two groups of entities form a single OPES domain/system. > I don't see yet why Disney and Akamai should be indistinguishable in > the latter case. If something goes wrong on an OPES entity operated > by Akamai, I've to turn to Akamai, if something goes wrong on a > Disney server, I need to turn to Disney. The point is that you both (a) do not know where exactly something went wrong and (b) would very much prefer to have a single point of contact. Imagine a rather typical situation when there are several companies producing the final piece of content; as an end-user, you do not want to be responsible for figuring out which company made a mistake. Furthermore, imagine that the problem is in the _interaction_ between two OPES entities (i.e., each OPES entity is not at fault, but OPES system is malfunctioning). To summarize: One "end" does not want its internal organization to be known to the outside world. The other "end" wants to have a single point of contact/failure to troubleshoot. Tracing individual OPES entities violates both preferences. Tracing OPES systems satisfies both preferences. > > > Here is where I would start: > > > > OPES system: OPES system is a set of OPES entities > > defined for a given application message. The formation of an > > OPES system is recursive: OPES system starts with either data > > provider or data consumer (for the given message); OPES system > > then includes any OPES entity trusted by (accepting authority > > from) an entity already in the OPES system. The trust and > > authority delegation is viewed in the context of the given > > application message. As implied by the above definition, some > > OPES entities in the system may not participate in the > > processing of a given message. > > Hm... Assume a carrier A trusting carrier B. According to above > definition, they both form an OPES system/domain. As such, they're > identified by a single OPES trace entry. To whom would an end user > turn if there're any problems? To whoever is identified in the OPES trace. It would be up to the OPES system to decide what ID/contact info to put in the trace. Note that we are talking about authorized adaptation of content not just proxying/carrying of opaque data. In OPES world, A and B would have some kind of agreement between them. The trace would reflect that agreement in providing a single "responsible party". That party could be A, B, or even C (some support outsourcing agency). That party would be responsible for taking complaints, troubleshooting problems, and defining privacy policy. > I'm wondering whether - for tracing purposes - an OPES system/domain > should be defined by trust boundaries or by operational boundaries. Operational boundaries would be impossible to define clearly. Even if we define them, there will be too many distinct operational entities to manage. In OPES-compliant world, there should be no more than two mandatory traceable entities: data producer system/domain and data consumer system/domain. AFAIK, the "end-to-end" principle dictates the same bipolar design and prohibits mandatory exposure of internal organization within each system: We do not want to create intermediaries (from trust/authority/tracing point of view) -- we want two ends talking to each other. Alex. From owner-ietf-openproxy@mail.imc.org Wed Aug 13 17:02:20 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05930 for ; Wed, 13 Aug 2003 17:02:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n2lD-00054c-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 17:02:24 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19n2lD-00054V-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 17:02:23 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DKjKqt010384 for ; Wed, 13 Aug 2003 13:45:20 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DKjKum010383 for ietf-openproxy-bks; Wed, 13 Aug 2003 13:45:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DKjJqt010378 for ; Wed, 13 Aug 2003 13:45:19 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7DKjLMS049382; Wed, 13 Aug 2003 14:45:21 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7DKjLVT049381; Wed, 13 Aug 2003 14:45:21 -0600 (MDT) (envelope-from rousskov) Date: Wed, 13 Aug 2003 14:45:21 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: Re: [end points comm] OPES System In-Reply-To: <3F3A9779.4030901@mhof.com> Message-ID: References: <5.2.0.9.0.20030811225712.045792f0@mail.utel.net> <3F38F2C1.9040701@mhof.com> <3F3A9779.4030901@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 13 Aug 2003, Markus Hofmann wrote: > Alex Rousskov wrote: > > > Here is where I would start: > > > > OPES system: OPES system is a set of OPES entities > > defined for a given application message. The formation of an > > OPES system is recursive: OPES system starts with either data > > provider or data consumer (for the given message); OPES system > > then includes any OPES entity trusted by (accepting authority > > from) an entity already in the OPES system. The trust and > > authority delegation is viewed in the context of the given > > application message. As implied by the above definition, some > > OPES entities in the system may not participate in the > > processing of a given message. > > Hm... Assume a carrier A trusting carrier B. According to above > definition, they both form an OPES system/domain. As such, they're > identified by a single OPES trace entry. To whom would an end user > turn if there're any problems? To the [single] entity identified in the trace. Now suppose there are two or more trace entries. To whom would an end user turn if there're any problems? A real-world illustration of the same problem is baggage handling by airlines. When your checked-in baggage does not arrive with you at the final destination, you are supposed to complain to a single carrier only (the last airline, in this case). It is the responsibility of that carrier to follow the global airline system/domain rules to find your baggage and deliver it to you. Naturally, you would not normally know exactly where your baggage have been, who lost it, and how it was found. OPES system implementations can adopt the same last-entity model if they find it useful, but they do not have to. They may choose to outsource OPES troubleshooting instead (for example). Alex. From owner-ietf-openproxy@mail.imc.org Wed Aug 13 17:45:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07457 for ; Wed, 13 Aug 2003 17:45:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n3RM-0005Uj-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 17:45:56 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19n3RL-0005Ug-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 17:45:55 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DLJ3qt011500 for ; Wed, 13 Aug 2003 14:19:03 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DLJ3k1011499 for ietf-openproxy-bks; Wed, 13 Aug 2003 14:19:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DLJ2qt011493 for ; Wed, 13 Aug 2003 14:19:02 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7DLIor15665; Wed, 13 Aug 2003 17:18:51 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Aug 2003 17:18:51 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754035FD1B2@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: "'Alex Rousskov'" , OPES Group Subject: RE: [end points comm] OPES System Date: Wed, 13 Aug 2003 17:18:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C361E0.54994DCC" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C361E0.54994DCC Content-Type: text/plain Alex, Fully agree with you. Airline example is the example that we should use. I think we should define the OPES system in that fashion where there is only one accountable system . Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Wednesday, August 13, 2003 4:45 PM > To: OPES Group > Subject: Re: [end points comm] OPES System > > > > > On Wed, 13 Aug 2003, Markus Hofmann wrote: > > > Alex Rousskov wrote: > > > > > Here is where I would start: > > > > > > OPES system: OPES system is a set of OPES entities > > > defined for a given application message. The formation of an > > > OPES system is recursive: OPES system starts with either data > > > provider or data consumer (for the given message); OPES system > > > then includes any OPES entity trusted by (accepting authority > > > from) an entity already in the OPES system. The trust and > > > authority delegation is viewed in the context of the given > > > application message. As implied by the above definition, some > > > OPES entities in the system may not participate in the > > > processing of a given message. > > > > Hm... Assume a carrier A trusting carrier B. According to above > > definition, they both form an OPES system/domain. As such, they're > > identified by a single OPES trace entry. To whom would an end user > > turn if there're any problems? > > To the [single] entity identified in the trace. > > Now suppose there are two or more trace entries. To whom > would an end user turn if there're any problems? > > > A real-world illustration of the same problem is baggage > handling by airlines. When your checked-in baggage does not > arrive with you at the final destination, you are supposed to > complain to a single carrier only (the last airline, in this > case). It is the responsibility of that carrier to follow the > global airline system/domain rules to find your baggage and > deliver it to you. Naturally, you would not normally know > exactly where your baggage have been, who lost it, and how it > was found. > > OPES system implementations can adopt the same last-entity > model if they find it useful, but they do not have to. They > may choose to outsource OPES troubleshooting instead (for example). > > Alex. > > ------_=_NextPart_001_01C361E0.54994DCC Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [end points comm] OPES System

Alex,

Fully agree with you.

Airline example is the example that we should use. I = think we should define the OPES system in that fashion where there is = only one accountable system .

Abbie



> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Wednesday, August 13, 2003 4:45 PM
> To: OPES Group
> Subject: Re: [end points comm] OPES = System
>
>
>
>
> On Wed, 13 Aug 2003, Markus Hofmann = wrote:
>
> > Alex Rousskov wrote:
> >
> > > Here is where I would start:
> > >
> > >   OPES system: OPES system is a = set of OPES entities
> > >   defined for a given = application message. The formation of an
> > >   OPES system is recursive: OPES = system starts with either data
> > >   provider or data consumer (for = the given message); OPES system
> > >   then includes any OPES entity = trusted by (accepting authority
> > >   from) an entity already in the = OPES system. The trust and
> > >   authority delegation is viewed = in the context of the given
> > >   application message. As = implied by the above definition, some
> > >   OPES entities in the system = may not participate in the
> > >   processing of a given = message.
> >
> > Hm... Assume a carrier A trusting carrier = B. According to above
> > definition, they both form an OPES = system/domain. As such, they're
> > identified by a single OPES trace entry. = To whom would an end user
> > turn if there're any problems?
>
> To the [single] entity identified in the = trace.
>
> Now suppose there are two or more trace = entries. To whom
> would an end user turn if there're any = problems?
>
>
> A real-world illustration of the same problem = is baggage
> handling by airlines. When your checked-in = baggage does not
> arrive with you at the final destination, you = are supposed to
> complain to a single carrier only (the last = airline, in this
> case). It is the responsibility of that carrier = to follow the
> global airline system/domain rules to find your = baggage and
> deliver it to you. Naturally, you would not = normally know
> exactly where your baggage have been, who lost = it, and how it
> was found.
>
> OPES system implementations can adopt the same = last-entity
> model if they find it useful, but they do not = have to. They
> may choose to outsource OPES troubleshooting = instead (for example).
>
> Alex.
>
>

------_=_NextPart_001_01C361E0.54994DCC-- From owner-ietf-openproxy@mail.imc.org Wed Aug 13 18:08:28 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08625 for ; Wed, 13 Aug 2003 18:08:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n3nE-0005de-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 18:08:32 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19n3nD-0005db-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 18:08:31 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DLnBqt012768 for ; Wed, 13 Aug 2003 14:49:11 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DLnBeu012767 for ietf-openproxy-bks; Wed, 13 Aug 2003 14:49:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DLnAqt012757 for ; Wed, 13 Aug 2003 14:49:10 -0700 (PDT) (envelope-from info@utel.net) Received: from f01m-27-59.d0.club-internet.fr ([212.195.226.59] helo=jfc2.utel.net) by hosting.altserver.com with esmtp (Exim 4.20) id 19n3UU-0001bs-NT; Wed, 13 Aug 2003 14:49:11 -0700 Message-Id: <5.2.0.9.0.20030813232801.0308dec0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 13 Aug 2003 23:30:06 +0200 To: Markus Hofmann , OPES Group From: jfcm Subject: Re: [end points comm] OPES System In-Reply-To: <3F3A9779.4030901@mhof.com> References: <5.2.0.9.0.20030811225712.045792f0@mail.utel.net> <3F38F2C1.9040701@mhof.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Dear Markus, please stop confusing system and domains! Whatever the definition there are many needs to support. American is poor enough in terms not to reduce their number :-) Intuitively domain relates to what belong to someone or which is stable enough with boarders System relates to someting whch is assembled for a purpose and which may expand. And uses differnt domains. Ex. The moon belongs to the Earth Domain and the Earth participate to the Sun system. Or will you support the SNS for system name system? :-) jfc From owner-ietf-openproxy@mail.imc.org Wed Aug 13 18:08:35 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08652 for ; Wed, 13 Aug 2003 18:08:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n3nL-0005dk-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 18:08:39 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19n3nK-0005dh-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 18:08:38 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DLnAqt012759 for ; Wed, 13 Aug 2003 14:49:10 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DLnAxF012758 for ietf-openproxy-bks; Wed, 13 Aug 2003 14:49:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DLn8qt012747 for ; Wed, 13 Aug 2003 14:49:09 -0700 (PDT) (envelope-from info@utel.net) Received: from f01m-27-59.d0.club-internet.fr ([212.195.226.59] helo=jfc2.utel.net) by hosting.altserver.com with esmtp (Exim 4.20) id 19n3UR-0001bs-HU; Wed, 13 Aug 2003 14:49:08 -0700 Message-Id: <5.2.0.9.0.20030813230205.030da130@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 13 Aug 2003 23:11:16 +0200 To: Alex Rousskov , OPES Group From: jfcm Subject: Re: [end points comm] OPES System Cc: Markus Hofmann In-Reply-To: References: <3F38F2C1.9040701@mhof.com> <5.2.0.9.0.20030811225712.045792f0@mail.utel.net> <3F38F2C1.9040701@mhof.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 19:57 13/08/03, Alex Rousskov wrote: >On Tue, 12 Aug 2003, Markus Hofmann wrote: >Here is where I would start: > > OPES system: OPES system is a set of OPES entities > defined for a given application message. The formation of an > OPES system is recursive: OPES system starts with either data > provider or data consumer (for the given message); OPES system > then includes any OPES entity trusted by (accepting authority > from) an entity already in the OPES system. The trust and > authority delegation is viewed in the context of the given > application message. As implied by the above definition, some > OPES entities in the system may not participate in the > processing of a given message. OK for that definition with two provisions: 1. the recursiveness makes it potentially an illimited ectoplasm what I accept in principle if you read Open in that sense. Nevertheless I prefer my own approach of saying that a system is organized by someone because of the differences in the system, usage and awareness depending on who organize it. This permits me to qualify as a boarderless system as most probably a structural bug? 2. I maintain the important interest of the notion of domain as belonging to an operator. Because of the practical influence in terms of rates, contracts, security, qos, etc. Sub-domains should be alluded to to show that what count is the parameter decided by an authority. jfc >Or we can use the "coloring" trick from >draft-ietf-opes-architecture-04. Just make sure that the end >(provider/consumer) is included in the OPES domain/system and that the >definition is based on a given message. > >The above definition puts both Disney and Akamai into one OPES system, >for a given application message they may process. Moreover, if Disney >uses both Akamai and Mirror Image (or whatever) for content >distribution, the distinction would be made on a per-message >(per-content) basis, which is the right thing to do because Akamai and >Mirror Image do not necessarily belong to the same OPES domain/system. > >Alex. > > > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.507 / Virus Database: 304 - Release Date: 04/08/03 From owner-ietf-openproxy@mail.imc.org Wed Aug 13 18:36:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09986 for ; Wed, 13 Aug 2003 18:36:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n4Ef-0005mi-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 18:36:53 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19n4Ee-0005mf-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 18:36:52 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DMKkqt017255 for ; Wed, 13 Aug 2003 15:20:46 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DMKkRT017254 for ietf-openproxy-bks; Wed, 13 Aug 2003 15:20:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DMKiqt017249 for ; Wed, 13 Aug 2003 15:20:44 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7DMKkMS051612; Wed, 13 Aug 2003 16:20:46 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7DMKkff051611; Wed, 13 Aug 2003 16:20:46 -0600 (MDT) (envelope-from rousskov) Date: Wed, 13 Aug 2003 16:20:46 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: Re: [end points comm] OPES System In-Reply-To: <5.2.0.9.0.20030813230205.030da130@mail.utel.net> Message-ID: References: <3F38F2C1.9040701@mhof.com> <5.2.0.9.0.20030811225712.045792f0@mail.utel.net> <3F38F2C1.9040701@mhof.com> <5.2.0.9.0.20030813230205.030da130@mail.utel.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 13 Aug 2003, jfcm wrote: > At 19:57 13/08/03, Alex Rousskov wrote: > >On Tue, 12 Aug 2003, Markus Hofmann wrote: > >Here is where I would start: > > > > OPES system: OPES system is a set of OPES entities > > defined for a given application message. The formation of an > > OPES system is recursive: OPES system starts with either data > > provider or data consumer (for the given message); OPES system > > then includes any OPES entity trusted by (accepting authority > > from) an entity already in the OPES system. The trust and > > authority delegation is viewed in the context of the given > > application message. As implied by the above definition, some > > OPES entities in the system may not participate in the > > processing of a given message. > > OK for that definition with two provisions: > > 1. the recursiveness makes it potentially an illimited ectoplasm > what I accept in principle if you read Open in that sense. Not sure I follow. Are you objecting to potentially unlimited size of the set? > Nevertheless I prefer my own approach of saying that a system is > organized by someone because of the differences in the system, usage > and awareness depending on who organize it. This permits me to > qualify as a boarderless system as most probably a structural bug? IIRC, you proposed to define OPES system as "a system organized to permit its users to obtain a set of open puggable edge services." While that make sense, it allows for more than two OPES systems to exist for a given application message being adopted. Thus, it complicates tracing/bypass requirements and raises end-to-end/IAB concerns. My definition is essentially the same except a particular formation mechanism is embedded to prevent more than two (one "provider" and one "consumer") systems to co-exist. The two definitions can probably be merged: OPES system: A set of OPES entities organized by (or on behalf of) either a data provider or data consumer for adaptation of a given message. Alex. From owner-ietf-openproxy@mail.imc.org Wed Aug 13 19:03:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10497 for ; Wed, 13 Aug 2003 19:03:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n4eH-0005so-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 19:03:21 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19n4eG-0005sl-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 19:03:20 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DMjfqt018660 for ; Wed, 13 Aug 2003 15:45:41 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DMjfPo018659 for ietf-openproxy-bks; Wed, 13 Aug 2003 15:45:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DMjeqt018649 for ; Wed, 13 Aug 2003 15:45:40 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.8/8.12.8) with ESMTP id h7DMgPxX027314 for ; Wed, 13 Aug 2003 16:42:26 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id h7DMeamH006435 for ; Wed, 13 Aug 2003 16:40:36 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h7DMeZXd006431; Wed, 13 Aug 2003 16:40:35 -0600 Date: Wed, 13 Aug 2003 16:40:35 -0600 Message-Id: <200308132240.h7DMeZXd006431@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: ietf-openproxy@imc.org In-reply-to: Yourmessage <87609AFB433BD5118D5E0002A52CD754035FD1B2@zcard0k6.ca.nortel.com> Subject: RE: [end points comm] OPES System Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think this discussion has become far too embroiled in business practices and far too remote from protocols. And I'd like to note that today it is all too common to have airline baggage problems and be told that your problems are due to TSA and there is NO way to either trace or complain about lost items. An OPES processor MUST support tracing. You can set policy on who has authorization to turn on tracing or to see the results, you can set policy on granularity. But until this group has defined the tracing mechanism and told OPES implementors that the facility MUST be present, the rest of it is irrelevant. Hilarie From owner-ietf-openproxy@mail.imc.org Wed Aug 13 19:46:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11527 for ; Wed, 13 Aug 2003 19:46:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n5KN-000689-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 19:46:51 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19n5KM-000686-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 19:46:50 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DNTWqt020541 for ; Wed, 13 Aug 2003 16:29:32 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7DNTWm4020540 for ietf-openproxy-bks; Wed, 13 Aug 2003 16:29:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7DNTUqt020534 for ; Wed, 13 Aug 2003 16:29:31 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7DNSvMS053233; Wed, 13 Aug 2003 17:28:57 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7DNSvd4053232; Wed, 13 Aug 2003 17:28:57 -0600 (MDT) (envelope-from rousskov) Date: Wed, 13 Aug 2003 17:28:57 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: RE: [end points comm] OPES System In-Reply-To: <200308132240.h7DMeZXd006431@localhost.localdomain> Message-ID: References: <200308132240.h7DMeZXd006431@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 13 Aug 2003, The Purple Streak, Hilarie Orman wrote: > An OPES processor MUST support tracing. You can set policy on who > has authorization to turn on tracing or to see the results, you can > set policy on granularity. If a given OPES processor implementation is always used deep inside an OPES system, the above MUST would be an overkill. Moreover, violating that MUST may not affect interoperability if sufficient tracing is provided by other entities in the system. I agree that a general-purpose processor must support tracing (because it may be used in isolation), but it is wrong to require that from any OPES processor. Only OPES systems MUST be traceable. > But until this group has defined the tracing mechanism and told OPES > implementors that the facility MUST be present, the rest of it is > irrelevant. The purpose of this thread is to identify what MUST be traceable. Some (including myself) insist that only OPES system MUST be traceable while smaller OPES entities SHOULD or MAY be traceable. Such approach implies, of course, that a stand-alone, isolated OPES processor MUST be traceable (because it represents an OPES system). If you accept that point of view, we can move on to specific tracing mechanisms (what should be included in the trace and how that information should be encoded). Your comments regarding optional tracing and tracing granularity make me thing that our positions are not that different. Alex. P.S. > And I'd like to note that today it is all too common to have airline > baggage problems and be told that your problems are due to TSA and > there is NO way to either trace or complain about lost items. The above is a self-contradictory statement. If somebody is telling you that your baggage problems are "due to TSA", then you found somebody to complain about lost items to! Whether your complaint is going to be effective is not relevant in the context of this thread. The mechanism we discuss is not going to eliminate problems; It is going to identify the responsible party (or partIES, in your version). From owner-ietf-openproxy@mail.imc.org Wed Aug 13 20:40:29 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12960 for ; Wed, 13 Aug 2003 20:40:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n6AJ-0006Yl-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 20:40:31 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19n6AI-0006Yi-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 20:40:31 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E0Dtqt022675 for ; Wed, 13 Aug 2003 17:13:55 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7E0DtTx022674 for ietf-openproxy-bks; Wed, 13 Aug 2003 17:13:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E0Drqt022669 for ; Wed, 13 Aug 2003 17:13:54 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.8/8.12.8) with ESMTP id h7E0AhxX030485; Wed, 13 Aug 2003 18:10:43 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id h7E08nmH011977; Wed, 13 Aug 2003 18:08:49 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h7E08mlg011973; Wed, 13 Aug 2003 18:08:48 -0600 Date: Wed, 13 Aug 2003 18:08:48 -0600 Message-Id: <200308140008.h7E08mlg011973@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: RE: [end points comm] OPES System Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: My point about TSA is that there is no way to determine if items were lost by TSA or the airline. All you can do is to talk to the airline and be told "we didn't lose it, it must be TSA". That's not a "trace", and TSA will say the airline is at fault. We don't want a protocol system with this kind of information loss. Hilarie From owner-ietf-openproxy@mail.imc.org Wed Aug 13 23:23:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15458 for ; Wed, 13 Aug 2003 23:23:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n8hl-00078c-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 23:23:13 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19n8hk-00078Y-00 for opes-archive@ietf.org; Wed, 13 Aug 2003 23:23:12 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E2sHqt032996 for ; Wed, 13 Aug 2003 19:54:17 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7E2sHC6032995 for ietf-openproxy-bks; Wed, 13 Aug 2003 19:54:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7E2sGqt032990 for ; Wed, 13 Aug 2003 19:54:16 -0700 (PDT) (envelope-from abeck@bell-labs.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7E2sI9Y047762; Wed, 13 Aug 2003 22:54:18 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7E2sBF2026391; Wed, 13 Aug 2003 22:54:12 -0400 (EDT) Received: from bell-labs.com (abeck.lra.lucent.com [192.11.62.148]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7E2sBkO024589; Wed, 13 Aug 2003 22:54:11 -0400 (EDT) Message-ID: <3F3AF9D3.2000302@bell-labs.com> Date: Wed, 13 Aug 2003 22:54:11 -0400 From: Andre Beck User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Rousskov CC: OPES WG Subject: Re: draft-beck-opes-irml-03.txt References: <3EF8CADD.2060201@bell-labs.com> <3EF905A5.9000100@mhof.com> <3F0087EF.6020805@bell-labs.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > While I was not technically accurate what I used the term "expression > power", I hope the above examples illustrate that proposed irml-03 does > not let us express the above logic in a > good/convenient/suitable/efficient "enough" form. OK, I agree with that statement, though I still have doubts whether or not there is really a need to express rules that are so complex that it would be cumbersome to express them with IRML. Wouldn't most OPES services simply be triggered by matching a pattern against the requested URL? If I look at the classic OPES service examples like virus scanning, request filtering, ad insertion etc. I just don't see a need for rules with multiple, nested rule conditions. Also, the reason why processing points in IRML are rule attributes and not rule conditions is that this allows rules to be grouped by processing point. That way, only rules relevant to a specific processing point need to be evaluated at any given time. > The specs seem to enforce authorization (Section 4, IRML Rule > Processing): > > For each data transaction the rule processor on the intermediary > located in the path between data consumers and data providers MUST > process only those IRML rule sets that ... > contain rule sets which have been authorized by either endpoint > of the transaction. OK, that sentence should probably go to a separate document about rule authorization. I agree that IRML should neither specify how rules are authorized nor how the authorization is enforced. > Sorry if I missed this very important assumption in the spec. It seems > to me that this assumption limits irml-03 applicability to > intermediaries with which content providers have a long-lasting and > mostly static relationship. IMO, the primary value of Rules Language > (from IETF point of view) would be to allow dynamic rule > interpretation and inclusion of rules with application message > metadata. > > For example, if we are talking about HTTP adaptation, the content > provider should be able to say something like this using HTTP > response headers: > > OPES-Rule: if condition1 do apply_service1; > > Does everybody agree that support of such dynamic and/or embedded > rules is out of scope? That is indeed a good question. IRML certainly isn't designed to be used in application protocol headers. I would agree that an XML-based format would not be suitable for this type of dynamic rules. > Clearly, there is a trade-off between what the rules can do and how > much processing is needed to interpret them. IMO, there are many > useful enough cases that can be processed more efficiently than > irml-03 (due to its simplifications/limitations) allows. See examples > above. Again, I don't think OPES needs to or should support such rule constructs. Thus I think IRML's simplifications and limitations are a feature and not a bug. ;-) > Hard to say. There are more ASCII-aware editing tools than there are > XML-aware editing tools. It is a question of whether generic editing > tools can assist rules writing enough to justify a particular encoding > format. IMO, no, they cannot (and so this argument should not be > used). Well, a generic XML editor - if configured with the IRML DTD - can at least assist the author in that it can enforce the syntax and grammar of IRML modules. -Andre From owner-ietf-openproxy@mail.imc.org Thu Aug 14 07:24:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06653 for ; Thu, 14 Aug 2003 07:24:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nGDE-0001es-00 for opes-archive@ietf.org; Thu, 14 Aug 2003 07:24:12 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19nGDD-0001ep-00 for opes-archive@ietf.org; Thu, 14 Aug 2003 07:24:12 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EB1Pqt078484 for ; Thu, 14 Aug 2003 04:01:25 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EB1PVL078483 for ietf-openproxy-bks; Thu, 14 Aug 2003 04:01:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EB1Oqt078477 for ; Thu, 14 Aug 2003 04:01:24 -0700 (PDT) (envelope-from info@utel.net) Received: from f01m-31-108.d0.club-internet.fr ([212.195.230.108] helo=jfc2.utel.net) by hosting.altserver.com with esmtp (Exim 4.20) id 19nFr9-0000fJ-9o; Thu, 14 Aug 2003 04:01:23 -0700 Message-Id: <5.2.0.9.0.20030814122644.02cf68e0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 14 Aug 2003 12:45:52 +0200 To: Alex Rousskov , OPES Group From: jfcm Subject: Re: [end points comm] OPES System In-Reply-To: References: <5.2.0.9.0.20030813230205.030da130@mail.utel.net> <3F38F2C1.9040701@mhof.com> <5.2.0.9.0.20030811225712.045792f0@mail.utel.net> <3F38F2C1.9040701@mhof.com> <5.2.0.9.0.20030813230205.030da130@mail.utel.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 00:20 14/08/03, Alex Rousskov wrote: >On Wed, 13 Aug 2003, jfcm wrote: > > At 19:57 13/08/03, Alex Rousskov wrote: > > >On Tue, 12 Aug 2003, Markus Hofmann wrote: > > >Here is where I would start: > > > > > > OPES system: OPES system is a set of OPES entities > > > defined for a given application message. The formation of an > > > OPES system is recursive: OPES system starts with either data > > > provider or data consumer (for the given message); OPES system > > > then includes any OPES entity trusted by (accepting authority > > > from) an entity already in the OPES system. The trust and > > > authority delegation is viewed in the context of the given > > > application message. As implied by the above definition, some > > > OPES entities in the system may not participate in the > > > processing of a given message. > > > > OK for that definition with two provisions: > > > > 1. the recursiveness makes it potentially an illimited ectoplasm > > what I accept in principle if you read Open in that sense. > >Not sure I follow. Are you objecting to potentially unlimited size of >the set? No. But I ask if this is what we want. Your airfreight system is the best standard image. Passengers or luggages representing datagrams (however I do not understand your point about system tracability in another mail, I will address here, so we can see if we agree). Let come back to your real world image and wording. 1. there is an air transport system you chose/you are proposed to travel (your definition below) 2. this system calls on different companies. If a luggage is lost your last operator does not want to know where it has been lost, but who is reponsbile to find it back: the different involved companies domains of responsibility. The system MUST trace these domains however tiny they are (single machine). It COULD trace the different airports/processors but that may become confusing (they may use different wording, solutions) and useless (a company has no power within another company domain). The question I rose was: if you accept "recursive" in the definition you imply that whatever the transit, as long as the luggage arrives, it is OK. I say this may rise a lot of questions because the luggage may this way legitimately transit throught places I do not want and we lose the possibility to say there are transit bugs? or to restrict my luggage's travel and prefer them late than having transited in the USA, at risk of having been lost by the TSA. To keep with the discussed image. > > Nevertheless I prefer my own approach of saying that a system is > > organized by someone because of the differences in the system, usage > > and awareness depending on who organize it. This permits me to > > qualify as a boarderless system as most probably a structural bug? > >IIRC, you proposed to define OPES system as "a system organized to >permit its users to obtain a set of open puggable edge services." >While that make sense, it allows for more than two OPES systems to >exist for a given application message being adopted. Thus, it >complicates tracing/bypass requirements and raises end-to-end/IAB >concerns. > >My definition is essentially the same except a particular formation >mechanism is embedded to prevent more than two (one "provider" and one >"consumer") systems to co-exist. The two definitions can probably be >merged: > > OPES system: A set of OPES entities organized by (or on behalf > of) either a data provider or data consumer for adaptation of a > given message. Suits me. You may add "A set of OPES entities, parts of a single or of multiple OPES operators domains, organized ..." jfc From owner-ietf-openproxy@mail.imc.org Thu Aug 14 08:56:22 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08402 for ; Thu, 14 Aug 2003 08:56:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nHeS-00022e-00 for opes-archive@ietf.org; Thu, 14 Aug 2003 08:56:25 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19nHeS-00022b-00 for opes-archive@ietf.org; Thu, 14 Aug 2003 08:56:24 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ECZZqt084957 for ; Thu, 14 Aug 2003 05:35:35 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7ECZZcq084956 for ietf-openproxy-bks; Thu, 14 Aug 2003 05:35:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ECZXqt084947 for ; Thu, 14 Aug 2003 05:35:34 -0700 (PDT) (envelope-from cedric.goutard@francetelecom.com) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 14 Aug 2003 14:35:21 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE : [end points comm] OPES System Date: Thu, 14 Aug 2003 14:35:20 +0200 Message-ID: Thread-Topic: [end points comm] OPES System Thread-Index: AcNgMj5+7sn2N+CpTMuA6u6RhafAcQCLeEuQ From: =?iso-8859-1?Q?GOUTARD_C=E9dric_FTRD/DMI/CAE?= To: "Markus Hofmann" , X-OriginalArrivalTime: 14 Aug 2003 12:35:21.0105 (UTC) FILETIME=[8698D010:01C36260] X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7ECZZqt084952 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id h7ECZZqt084957 Content-Transfer-Encoding: quoted-printable Markus, From a carrier and/or ISP point of view, your arguments are completely re= levant. Indeed, the "OPES system" could give information about the services it=20 provides but nothing about the number of OPES processors, their IP=20 address, their specific version... =20 I hope that this comment will help finding a "deployable" solution. =20 Regards Cedric=20 [ France Telecom R&D ] -----Message d'origine----- De : Markus Hofmann [mailto:markus@mhof.com]=20 Envoy=E9 : lundi 11 ao=FBt 2003 19:37 =C0 : ietf-openproxy@imc.org Objet : Re: [end points comm] OPES System The Purple Streak, Hilarie Orman wrote: > I think the concept of an "OPES system" being traceable, without=20 > requiring each OPES processor to be traceable, is unsupportable. It=20 > will not satisfy anyone, and it will lead to endless arguments about=20 > what constitutes compliance. If I recall correctly, there were two arguments that lead to this concept= : (1) Carriers are typically hesitant to reveal information about their=20 internal network infrastructure, i.e. they don't want to provide=20 information (e.g. the IP address) about their internal network elements. (2) OPES processors might be configured to use non-routable, private=20 IP addresses inside a carrier's network. How would they be identified? A user having problems/concerns would trace and contact the carrier=20 who provided an OPES service (without tracing the exact OPES=20 processor/callout server). It's up to the carrier to have maintained=20 approriate internal detailed traces to find the answer to the=20 customer's inquery. Anyone any thoughts or comments on that issue? This is a very=20 important topic and we must get WG consensus on it, so please post=20 your views to the mailing list! -Markus From owner-ietf-openproxy@mail.imc.org Thu Aug 14 11:15:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14534 for ; Thu, 14 Aug 2003 11:15:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nJoo-0003J7-00 for opes-archive@ietf.org; Thu, 14 Aug 2003 11:15:14 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19nJon-0003J4-00 for opes-archive@ietf.org; Thu, 14 Aug 2003 11:15:13 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EEqMqt095772 for ; Thu, 14 Aug 2003 07:52:22 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EEqM4U095771 for ietf-openproxy-bks; Thu, 14 Aug 2003 07:52:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EEqJqt095766 for ; Thu, 14 Aug 2003 07:52:20 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7EEpdMS074775; Thu, 14 Aug 2003 08:51:39 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7EEpdWG074774; Thu, 14 Aug 2003 08:51:39 -0600 (MDT) (envelope-from rousskov) Date: Thu, 14 Aug 2003 08:51:39 -0600 (MDT) From: Alex Rousskov To: "The Purple Streak, Hilarie Orman" cc: ietf-openproxy@imc.org Subject: RE: [end points comm] OPES System In-Reply-To: <200308140008.h7E08mlg011973@localhost.localdomain> Message-ID: References: <200308140008.h7E08mlg011973@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 13 Aug 2003, The Purple Streak, Hilarie Orman wrote: > My point about TSA is that there is no way to determine if items were > lost by TSA or the airline. My point is that you should not care who lost the items. The only thing you should care about is who you should complain to (and, eventually, who will compensate you for your losses). If my bags are lost, I got to the last airline on my itinerary. I do not care who lost the bags. If the last airline cannot recover them on the spot, I can file a formal claim with them and take them to small claims court if needed. Then it will be the airline responsibility to recover their cost from TSA/government/whatever. This is how the system is supposed to work according to, IIRC, Warshaw Convention (and usually does). > All you can do is to talk to the airline and be told "we didn't lose > it, it must be TSA". That's not a "trace", and TSA will say the > airline is at fault. We don't want a protocol system with this kind > of information loss. It is not information loss. It is information/responsibility encapsulation. You do not need to know more than "who is responsible". The responsible party does not want you to know more than that they are responsible (but the trace may embed more opaque-to-you information to help them troubleshoot, of course; just like your bags have barcodes that you cannot understand but that are useful to the airline). Alex. From owner-ietf-openproxy@mail.imc.org Thu Aug 14 11:45:13 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15714 for ; Thu, 14 Aug 2003 11:45:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nKHs-0003cM-00 for opes-archive@ietf.org; Thu, 14 Aug 2003 11:45:16 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19nKHr-0003cJ-00 for opes-archive@ietf.org; Thu, 14 Aug 2003 11:45:15 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EFM2qt096881 for ; Thu, 14 Aug 2003 08:22:02 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EFM2Q6096880 for ietf-openproxy-bks; Thu, 14 Aug 2003 08:22:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EFM1qt096874 for ; Thu, 14 Aug 2003 08:22:01 -0700 (PDT) (envelope-from info@utel.net) Received: from f01v-29-23.d0.club-internet.fr ([212.195.248.23] helo=jfc2.utel.net) by hosting.altserver.com with esmtp (Exim 4.20) id 19nJvK-0006Tj-2Z; Thu, 14 Aug 2003 08:21:58 -0700 Message-Id: <5.2.0.9.0.20030814164121.03a49690@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 14 Aug 2003 16:53:52 +0200 To: GOUTARD Cédric FTRD/DMI/CAE , "Markus Hofmann" , From: jfcm Subject: RE : [end points comm] OPES System In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id h7EFM2qt096881 Content-Transfer-Encoding: quoted-printable C=E9dric, I think we are all in agreement on that and Alex's standard comparison wi= th=20 Arilines is the best image. Giving detailed infromation would be not only= =20 undisclosure and security breaches, but it would be unecessary and confus= ing. The problem is the wording confusion that Markus seems to=20 introduce/maintain between operators cooperating OPES domains and=20 organizer's global OPES system. If BNP jointly uses FT and UTEL (and may be others) OPES resources, the=20 only information I am ready to pass to you (and you to me I guess) are th= at=20 the UTEL OPES domain was invovled, when, how (domain name, etc.). Yet if=20 BNP wants support we will describe their whole set-up as the BNP OPES sys= tem. A+ jfc At 14:35 14/08/03, GOUTARD C=E9dric FTRD/DMI/CAE wrote: >Markus, > > >From a carrier and/or ISP point of view, your arguments are completely= =20 > relevant. >Indeed, the "OPES system" could give information about the services it >provides but nothing about the number of OPES processors, their IP >address, their specific version... > >I hope that this comment will help finding a "deployable" solution. > >Regards > >Cedric >[ France Telecom R&D ] > > > >-----Message d'origine----- >De : Markus Hofmann [mailto:markus@mhof.com] >Envoy=E9 : lundi 11 ao=FBt 2003 19:37 >=C0 : ietf-openproxy@imc.org >Objet : Re: [end points comm] OPES System > > > >The Purple Streak, Hilarie Orman wrote: > > > I think the concept of an "OPES system" being traceable, without > > requiring each OPES processor to be traceable, is unsupportable. It > > will not satisfy anyone, and it will lead to endless arguments about > > what constitutes compliance. > >If I recall correctly, there were two arguments that lead to this concep= t: > >(1) Carriers are typically hesitant to reveal information about their >internal network infrastructure, i.e. they don't want to provide >information (e.g. the IP address) about their internal network elements. > >(2) OPES processors might be configured to use non-routable, private >IP addresses inside a carrier's network. How would they be identified? > >A user having problems/concerns would trace and contact the carrier >who provided an OPES service (without tracing the exact OPES >processor/callout server). It's up to the carrier to have maintained >approriate internal detailed traces to find the answer to the >customer's inquery. > >Anyone any thoughts or comments on that issue? This is a very >important topic and we must get WG consensus on it, so please post >your views to the mailing list! > >-Markus > > > > > > > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.507 / Virus Database: 304 - Release Date: 04/08/03 From owner-ietf-openproxy@mail.imc.org Thu Aug 14 11:50:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15921 for ; Thu, 14 Aug 2003 11:50:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nKNN-0003ea-00 for opes-archive@ietf.org; Thu, 14 Aug 2003 11:50:57 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19nKNM-0003eX-00 for opes-archive@ietf.org; Thu, 14 Aug 2003 11:50:56 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EFVgqt097378 for ; Thu, 14 Aug 2003 08:31:42 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EFVgwM097377 for ietf-openproxy-bks; Thu, 14 Aug 2003 08:31:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EFVeqt097371 for ; Thu, 14 Aug 2003 08:31:40 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7EFVZMS075824; Thu, 14 Aug 2003 09:31:35 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7EFVZFc075823; Thu, 14 Aug 2003 09:31:35 -0600 (MDT) (envelope-from rousskov) Date: Thu, 14 Aug 2003 09:31:35 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: Re: draft-beck-opes-irml-03.txt In-Reply-To: <3F3AF9D3.2000302@bell-labs.com> Message-ID: References: <3EF8CADD.2060201@bell-labs.com> <3EF905A5.9000100@mhof.com> <3F0087EF.6020805@bell-labs.com> <3F3AF9D3.2000302@bell-labs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Andre, I think we narrowed our primary disagreement down to a manageable size: - You envision IRML to be used to describe very basic rules, occasionally distributed to OPES processors using off-band mechanisms. You want the language itself to make it difficult to describe complex manipulations. IRML inspiration comes, in part, from CPL which targets IP telephony needs. - I see the value of Rule Language in supporting in-band distribution and dynamic interpretation. I want the language to be compact and conveniently powerful. I expect arrangements within a given OPES system to limit the complexity of actual expressions as/if needed. My inspiration comes, in part, from trends in ACL (Access Control List) specification languages used by HTTP proxies and L2-7 switches. I doubt the above differences can be resolved by a compromise. One primary direction should be chosen by the working group. Am I the only person disliking the general direction of irml-03? Thanks, Alex. On Wed, 13 Aug 2003, Andre Beck wrote: > > Alex Rousskov wrote: > > > While I was not technically accurate what I used the term "expression > > power", I hope the above examples illustrate that proposed irml-03 does > > not let us express the above logic in a > > good/convenient/suitable/efficient "enough" form. > > OK, I agree with that statement, though I still have doubts whether or > not there is really a need to express rules that are so complex that it > would be cumbersome to express them with IRML. Wouldn't most OPES > services simply be triggered by matching a pattern against the requested > URL? If I look at the classic OPES service examples like virus scanning, > request filtering, ad insertion etc. I just don't see a need for rules > with multiple, nested rule conditions. > > Also, the reason why processing points in IRML are rule attributes and > not rule conditions is that this allows rules to be grouped by > processing point. That way, only rules relevant to a specific processing > point need to be evaluated at any given time. > > > The specs seem to enforce authorization (Section 4, IRML Rule > > Processing): > > > > For each data transaction the rule processor on the intermediary > > located in the path between data consumers and data providers MUST > > process only those IRML rule sets that ... > > contain rule sets which have been authorized by either endpoint > > of the transaction. > > OK, that sentence should probably go to a separate document about rule > authorization. I agree that IRML should neither specify how rules are > authorized nor how the authorization is enforced. > > > Sorry if I missed this very important assumption in the spec. It seems > > to me that this assumption limits irml-03 applicability to > > intermediaries with which content providers have a long-lasting and > > mostly static relationship. IMO, the primary value of Rules Language > > (from IETF point of view) would be to allow dynamic rule > > interpretation and inclusion of rules with application message > > metadata. > > > > For example, if we are talking about HTTP adaptation, the content > > provider should be able to say something like this using HTTP > > response headers: > > > > OPES-Rule: if condition1 do apply_service1; > > > > Does everybody agree that support of such dynamic and/or embedded > > rules is out of scope? > > That is indeed a good question. IRML certainly isn't designed to be used > in application protocol headers. I would agree that an XML-based format > would not be suitable for this type of dynamic rules. > > > Clearly, there is a trade-off between what the rules can do and how > > much processing is needed to interpret them. IMO, there are many > > useful enough cases that can be processed more efficiently than > > irml-03 (due to its simplifications/limitations) allows. See examples > > above. > > Again, I don't think OPES needs to or should support such rule > constructs. Thus I think IRML's simplifications and limitations are a > feature and not a bug. ;-) > > > Hard to say. There are more ASCII-aware editing tools than there are > > XML-aware editing tools. It is a question of whether generic editing > > tools can assist rules writing enough to justify a particular encoding > > format. IMO, no, they cannot (and so this argument should not be > > used). > > Well, a generic XML editor - if configured with the IRML DTD - can at > least assist the author in that it can enforce the syntax and grammar of > IRML modules. > > -Andre > > > > From owner-ietf-openproxy@mail.imc.org Thu Aug 14 11:53:32 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16007 for ; Thu, 14 Aug 2003 11:53:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nKPw-0003g5-00 for opes-archive@ietf.org; Thu, 14 Aug 2003 11:53:36 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19nKPv-0003g2-00 for opes-archive@ietf.org; Thu, 14 Aug 2003 11:53:35 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EFbCqt097990 for ; Thu, 14 Aug 2003 08:37:12 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EFbCqr097989 for ietf-openproxy-bks; Thu, 14 Aug 2003 08:37:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EFbBqt097984 for ; Thu, 14 Aug 2003 08:37:11 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7EFbCMS075950 for ; Thu, 14 Aug 2003 09:37:12 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7EFbCOm075949; Thu, 14 Aug 2003 09:37:12 -0600 (MDT) (envelope-from rousskov) Date: Thu, 14 Aug 2003 09:37:12 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: processing points in draft-beck-opes-irml-03 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Is the concept of a "processing point" application-agnostic? If it is application-specific, it should be removed from the application-agnostic spec (draft-beck-opes-irml-03). If we believe that every application protocol has some "processing points", then the definition of HTTP-specific points should probably be moved from draft-beck-opes-irml-03 to an HTTP binding for IRML. It may also be more appropriate to migrate from numbers to tokens/strings when describing application-specific points. Alex. From owner-ietf-openproxy@mail.imc.org Thu Aug 14 13:35:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19243 for ; Thu, 14 Aug 2003 13:35:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nM0t-0004Xt-00 for opes-archive@ietf.org; Thu, 14 Aug 2003 13:35:52 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19nM0t-0004Xp-00 for opes-archive@ietf.org; Thu, 14 Aug 2003 13:35:51 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EH6Tqt006641 for ; Thu, 14 Aug 2003 10:06:29 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EH6TA9006640 for ietf-openproxy-bks; Thu, 14 Aug 2003 10:06:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EH6Sqt006633 for ; Thu, 14 Aug 2003 10:06:28 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.8/8.12.8) with ESMTP id h7EH3Bd4032478; Thu, 14 Aug 2003 11:03:11 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id h7EGxUmH003919; Thu, 14 Aug 2003 10:59:30 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h7EGxTkZ003915; Thu, 14 Aug 2003 10:59:29 -0600 Date: Thu, 14 Aug 2003 10:59:29 -0600 Message-Id: <200308141659.h7EGxTkZ003915@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: RE: [end points comm] OPES System Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Airlines have no responsibility or ability to recover passenger items from government inspectors. Don't repeat this mistake in designing protocols. OPES processors MUST support tracing. Hilarie From owner-ietf-openproxy@mail.imc.org Thu Aug 14 13:46:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19747 for ; Thu, 14 Aug 2003 13:46:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nMAl-0004fF-00 for opes-archive@ietf.org; Thu, 14 Aug 2003 13:46:03 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19nMAk-0004fC-00 for opes-archive@ietf.org; Thu, 14 Aug 2003 13:46:02 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EHSOqt008513 for ; Thu, 14 Aug 2003 10:28:24 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EHSOAB008512 for ietf-openproxy-bks; Thu, 14 Aug 2003 10:28:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EHSMqt008505 for ; Thu, 14 Aug 2003 10:28:22 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7EHRlMS078492; Thu, 14 Aug 2003 11:27:47 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7EHRlxw078491; Thu, 14 Aug 2003 11:27:47 -0600 (MDT) (envelope-from rousskov) Date: Thu, 14 Aug 2003 11:27:47 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: RE: [end points comm] OPES System In-Reply-To: <200308141659.h7EGxTkZ003915@localhost.localdomain> Message-ID: References: <200308141659.h7EGxTkZ003915@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 14 Aug 2003, The Purple Streak, Hilarie Orman wrote: > Airlines have no responsibility or ability to recover passenger > items from government inspectors. Don't repeat this mistake in > designing protocols. I do not think we are repeating any mistakes yet. Government inspectors are, apparently, outside of the airline equivalent of the OPES system and, hence, are not in the scope of this discussion. According to your comments, they are similar to a "transparent" proxy adapting traffic without either end authorization; we do not consider such entities because we cannot regulate them. We only consider entities that want to be called OPES entities and want to obey OPES rules. > OPES processors MUST support tracing. We are not discussing what OPES processors must support. We are discussing what OPES entities MUST be represented in any OPES trace. IMO, only OPES systems MUST be represented. Alex. From owner-ietf-openproxy@mail.imc.org Thu Aug 14 15:24:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23845 for ; Thu, 14 Aug 2003 15:24:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nNiS-0005IP-00 for opes-archive@ietf.org; Thu, 14 Aug 2003 15:24:56 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19nNiS-0005IM-00 for opes-archive@ietf.org; Thu, 14 Aug 2003 15:24:56 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EJ50qt013643 for ; Thu, 14 Aug 2003 12:05:00 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EJ4xXt013642 for ietf-openproxy-bks; Thu, 14 Aug 2003 12:04:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EJ4wqt013637 for ; Thu, 14 Aug 2003 12:04:59 -0700 (PDT) (envelope-from info@utel.net) Received: from f01v-29-23.d0.club-internet.fr ([212.195.248.23] helo=jfc2.utel.net) by hosting.altserver.com with esmtp (Exim 4.20) id 19nNP6-00073I-Hz; Thu, 14 Aug 2003 12:04:57 -0700 Message-Id: <5.2.0.9.0.20030814182128.02fcb760@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 14 Aug 2003 18:28:39 +0200 To: Alex Rousskov , "The Purple Streak, Hilarie Orman" From: jfcm Subject: RE: [end points comm] OPES System Cc: ietf-openproxy@imc.org In-Reply-To: References: <200308140008.h7E08mlg011973@localhost.localdomain> <200308140008.h7E08mlg011973@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Alex, Hilarie point was correct and I think your response is final. At 16:51 14/08/03, Alex Rousskov wrote: >On Wed, 13 Aug 2003, The Purple Streak, Hilarie Orman wrote: > > > My point about TSA is that there is no way to determine if items were > > lost by TSA or the airline. > >My point is that you should not care who lost the items. The only >thing you should care about is who you should complain to (and, >eventually, who will compensate you for your losses). True as a passenger. But the Airline needs to know it (and probably to be able to document it a lot?). So the trace MUST tell it. >It is not information loss. It is information/responsibility encapsulation. >You do not need to know more than "who is responsible". The >responsible party does not want you to know more than that they are >responsible (but the trace may embed more opaque-to-you information to >help them troubleshoot, of course; just like your bags have barcodes >that you cannot understand but that are useful to the airline). This is the exact need we have: opaque information. I was told that when French Customs and Gendarmerie were asked to use TCP/IP to deversify from OSI they encapsulated the OSI packets into TCP/IP datagram and added crypted tracing data. This means that Hackers packets come with information about the hacker. May be someone knows better about their architecture? I think the idea interesting. jfc From owner-ietf-openproxy@mail.imc.org Thu Aug 14 19:23:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01481 for ; Thu, 14 Aug 2003 19:23:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nRR4-0006tT-00 for opes-archive@ietf.org; Thu, 14 Aug 2003 19:23:14 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19nRR3-0006tQ-00 for opes-archive@ietf.org; Thu, 14 Aug 2003 19:23:14 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EMuHqt023229 for ; Thu, 14 Aug 2003 15:56:17 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7EMuHUP023228 for ietf-openproxy-bks; Thu, 14 Aug 2003 15:56:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7EMuGqt023223 for ; Thu, 14 Aug 2003 15:56:16 -0700 (PDT) (envelope-from info@utel.net) Received: from f01v-29-23.d0.club-internet.fr ([212.195.248.23] helo=jfc2.utel.net) by hosting.altserver.com with esmtp (Exim 4.20) id 19nR0w-0007ry-Rr; Thu, 14 Aug 2003 15:56:17 -0700 Message-Id: <5.2.0.9.0.20030815005340.030df090@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 15 Aug 2003 00:56:10 +0200 To: Alex Rousskov , OPES WG From: jfcm Subject: RE: [end points comm] OPES System In-Reply-To: References: <200308141659.h7EGxTkZ003915@localhost.localdomain> <200308141659.h7EGxTkZ003915@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 19:27 14/08/03, Alex Rousskov wrote: >On Thu, 14 Aug 2003, The Purple Streak, Hilarie Orman wrote: > > > Airlines have no responsibility or ability to recover passenger > > items from government inspectors. Don't repeat this mistake in > > designing protocols. > >I do not think we are repeating any mistakes yet. Government >inspectors are, apparently, outside of the airline equivalent of the >OPES system and, hence, are not in the scope of this discussion. >According to your comments, they are similar to a "transparent" proxy >adapting traffic without either end authorization; we do not consider >such entities because we cannot regulate them. We only consider >entities that want to be called OPES entities and want to obey OPES >rules. This is a nice description of a hacker. Trace must help tro know who has been hacked. > > OPES processors MUST support tracing. > >We are not discussing what OPES processors must support. We are >discussing what OPES entities MUST be represented in any OPES trace. >IMO, only OPES systems MUST be represented. Please! Why are saying that again? As per (y)our previous definition there is only one system in use (even if user may call on different system. "only OPES domains MUST be presented". jfc From owner-ietf-openproxy@mail.imc.org Thu Aug 14 20:10:26 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02387 for ; Thu, 14 Aug 2003 20:10:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nSAm-00074V-00 for opes-archive@ietf.org; Thu, 14 Aug 2003 20:10:28 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19nSAl-00074S-00 for opes-archive@ietf.org; Thu, 14 Aug 2003 20:10:27 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ENhVqt025601 for ; Thu, 14 Aug 2003 16:43:31 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7ENhVTV025600 for ietf-openproxy-bks; Thu, 14 Aug 2003 16:43:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ENhTqt025595 for ; Thu, 14 Aug 2003 16:43:30 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7ENhWMS088228; Thu, 14 Aug 2003 17:43:32 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7ENhWis088227; Thu, 14 Aug 2003 17:43:32 -0600 (MDT) (envelope-from rousskov) Date: Thu, 14 Aug 2003 17:43:32 -0600 (MDT) From: Alex Rousskov To: jfcm cc: OPES WG Subject: RE: [end points comm] OPES System In-Reply-To: <5.2.0.9.0.20030815005340.030df090@mail.utel.net> Message-ID: References: <200308141659.h7EGxTkZ003915@localhost.localdomain> <200308141659.h7EGxTkZ003915@localhost.localdomain> <5.2.0.9.0.20030815005340.030df090@mail.utel.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 15 Aug 2003, jfcm wrote: > >We are not discussing what OPES processors must support. We are > >discussing what OPES entities MUST be represented in any OPES > >trace. IMO, only OPES systems MUST be represented. > > Please! Why are saying that again? > As per (y)our previous definition there is only one system in use (even if > user may call on different system. "only OPES domains MUST be presented". The purpose of the trace is not to count OPES systems (there can be no more than one on the other end), but to identify the OPES system (if any). As for OPES domains, it is not yet clear for me what they are in your definition. Nevertheless, I believe that the other end MUST receive at least one trace entry. If domains (whatever they are) within an OPES system decide to disclose their identity, that's up to them. Alex. From owner-ietf-openproxy@mail.imc.org Thu Aug 14 20:10:46 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02404 for ; Thu, 14 Aug 2003 20:10:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nSB6-00074b-00 for opes-archive@ietf.org; Thu, 14 Aug 2003 20:10:48 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19nSB5-00074Y-00 for opes-archive@ietf.org; Thu, 14 Aug 2003 20:10:47 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ENh2qt025582 for ; Thu, 14 Aug 2003 16:43:02 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7ENh2uw025581 for ietf-openproxy-bks; Thu, 14 Aug 2003 16:43:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ENh1qt025559 for ; Thu, 14 Aug 2003 16:43:01 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.8/8.12.8) with ESMTP id h7ENdfd4014022 for ; Thu, 14 Aug 2003 17:39:42 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id h7ENUmmH026763 for ; Thu, 14 Aug 2003 17:30:48 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h7ENUm0U026759; Thu, 14 Aug 2003 17:30:48 -0600 Date: Thu, 14 Aug 2003 17:30:48 -0600 Message-Id: <200308142330.h7ENUm0U026759@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: ietf-openproxy@imc.org In-reply-to: Yourmessage <5.2.0.9.0.20030815005340.030df090@mail.utel.net> Subject: RE: [end points comm] OPES System Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is truly a barrel of red herring. Separate mechanism from policy. The discussion is the policy that an organization can set regarding trace information. The proposal is that processor ids can be considered privileged information and deleted from the trace. Fine, then the organization must have a way to respond to queries about its tracing policies and to respond "processor ID's are not available". That doesn't mean that the policy is recommended, it doesn't have to appear in any RFC. An organization can have any policy its wants for trace information, but it MUST support tracing mechanisms and it MUST reveal its policy. Hilarie From owner-ietf-openproxy@mail.imc.org Thu Aug 14 20:44:26 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02960 for ; Thu, 14 Aug 2003 20:44:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nShg-0007DE-00 for opes-archive@ietf.org; Thu, 14 Aug 2003 20:44:28 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19nShf-0007DB-00 for opes-archive@ietf.org; Thu, 14 Aug 2003 20:44:27 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7F0HGqt026946 for ; Thu, 14 Aug 2003 17:17:16 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7F0HGhv026945 for ietf-openproxy-bks; Thu, 14 Aug 2003 17:17:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7F0HFqt026940 for ; Thu, 14 Aug 2003 17:17:15 -0700 (PDT) (envelope-from info@utel.net) Received: from f01m-26-142.d0.club-internet.fr ([212.195.225.142] helo=jfc2.utel.net) by hosting.altserver.com with esmtp (Exim 4.20) id 19nSHJ-00071J-6e; Thu, 14 Aug 2003 17:17:14 -0700 Message-Id: <5.2.0.9.0.20030815021815.02abc2d0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 15 Aug 2003 02:26:38 +0200 To: Alex Rousskov From: jfcm Subject: RE: [end points comm] OPES System Cc: ietf-openproxy@imc.org In-Reply-To: References: <5.2.0.9.0.20030815005340.030df090@mail.utel.net> <200308141659.h7EGxTkZ003915@localhost.localdomain> <200308141659.h7EGxTkZ003915@localhost.localdomain> <5.2.0.9.0.20030815005340.030df090@mail.utel.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 01:43 15/08/03, Alex Rousskov said: >The purpose of the trace is not to count OPES systems (there can be no >more than one on the other end), but to identify the OPES system (if >any). OK. If you name that a Trace (I would name that a signature) good to me. >As for OPES domains, it is not yet clear for me what they are in your >definition. Nevertheless, I believe that the other end MUST receive at >least one trace entry. If domains (whatever they are) within an OPES >system decide to disclose their identity, that's up to them. I name an OPES domain the area of reponsibility of an operator. That information MUST be traced (even if totally or partially opaque). 1. to be informed of/if (which) different "boarders" have been crossed. 2. to be informed of the possible loops or creeps. If I expect 2 domain booarders to be crossed and I am reported 10, I know that an unexpected recursion happened. 3. To prevent some operators domain to be accessed is a need. The report of the domain being crossed is therefore a need. 4. The reporting can be opque to permut concerned domains to get the store the private info they need in case of trouble shouting. jfc From owner-ietf-openproxy@mail.imc.org Fri Aug 15 19:38:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17903 for ; Fri, 15 Aug 2003 19:38:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19no8z-0006u2-00 for opes-archive@ietf.org; Fri, 15 Aug 2003 19:38:05 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19no8y-0006ty-00 for opes-archive@ietf.org; Fri, 15 Aug 2003 19:38:04 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FNFTqt025239 for ; Fri, 15 Aug 2003 16:15:29 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7FNFTms025238 for ietf-openproxy-bks; Fri, 15 Aug 2003 16:15:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FNFPqt025233 for ; Fri, 15 Aug 2003 16:15:27 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7FNEmMS022409; Fri, 15 Aug 2003 17:14:48 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7FNEmIX022408; Fri, 15 Aug 2003 17:14:48 -0600 (MDT) (envelope-from rousskov) Date: Fri, 15 Aug 2003 17:14:48 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: Re: IAB considerations In-Reply-To: <200307242119.h6OLJ5tJ003643@localhost.localdomain> Message-ID: References: <200307242119.h6OLJ5tJ003643@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 24 Jul 2003, The Purple Streak, Hilarie Orman wrote: > The current consideration draft confuses "privacy" and "undetected > modification" and "encryption". > > "Privacy" is about trusting a party with data that they may use but > not disclose. The detection modification of data is its > "integrity", and it can be ensured by cryptographic methods, > including keyed hashes and public key methods, but in general, not > encryption. Encryption is used for "confidentiality", and it can be > accomplished by cryptographic methods, but it is not a way to ensure > integrity: encrypted data on the wire can be undetectably modified > by third parties unless a cryptographic integrity mechanism is used > in conjunction with the encryption. While do not fully agree with your interpretation of privacy, integrity, and encryption, I would be more than happy to discuss specific draft flaws and address these concerns (of course). What draft text should be fixed in this regard? > The current draft characterizes processor identification at content > provider sites as "irrational" I disagree. The draft says (emphasis added) "It is irrational to expect a content provider to provide _access_ to internal hosts participating in content generation". This is different from providing identification of those hosts! The point is that in a typical environment an end user would have no way to access internal hosts, even if they are well identified. Furthermore, even if such access is provided as an exception to corporate integrity policy, the accessed servers will not be able to tell the end user much because they are not designed for or have enough information to communicate with end users. Note that the above quoted text belongs to the "IP-layer communication" section. We are discussing addressability of the OPES intermediaries there, nothing else. The conclusion in the current draft is that the IAB consideration in question can apply to a "a very limited subset of OPES intermediaries" and, hence, is not directly satisfiable in real world. My feeling is that IAB did not see the big picture (OPES systems) and focused their attention on components (OPES processors), creating irrelevant/misleading concerns. I am guessing that they simply did not consider common arrangements where many OPES processors form a single OPES system, representing a single content/data provider. Note that if IAB had expressed their concerns in terms of OPES systems, we would have no problems satisfying them! My suggestion is that we do not treat IAB concerns literary but apply our better understanding of the problem domain to satisfy "true" IAB intent. If you are familiar with Lawrence Lessig's work, this approach is similar to re-interpreting the Constitution authors' intent in the light of current [digital] reality instead of treating Constitution text literary and, hence, inapplicable. To our advantage, IAB members are still alive as opposed to US Constitution authors; we can always get a second opinion. Moreover, I think Markus intended to get such a second opinion sometime soon, using the existing draft. > It is also argues that end users cannot identify themselves usefully > to a content provider's internal processors. Although I don't > disagree that this might be true in some implementations, it isn't > clear that it is impossible in practice. It is not that the users cannot identify themselves. They [technically] can. It is that the internal OPES processors do not poses enough state and global understanding to respond to user requests. Most OPES processors do not have a notion of a "user"; they work with much more simple and well-focused objects like XML trees, access counters, or ad images. > I think that overall the viewpoint should clearly distinguish > between protocol feasibility and impact on content provider > practices. The text is trying to distinguish between micro-level feasibility (OPES processor MUST be addressable) and architectural macro-level feasibility (OPES processor is invisible behind an OPES system which MUST be addressable). We can approach the problem from a different angle: IAB already made an exception for chained OPES processors. An OPES system is nothing else but a chain of OPES processors or a very similar structure. Clearly, there should be no difference to the end user whether she deals with a chain or a "graph/tree" of OPES processors as long as the exit point is addressable/identified! Would that angle help you accept the notion of OPES system? If not, where do you see an important difference between a "chain of OPES processors with an addressable exit point" and a "graph of OPES processors with an addressable exit point"? Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Fri Aug 15 19:56:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18148 for ; Fri, 15 Aug 2003 19:56:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19noRC-0006xh-00 for opes-archive@ietf.org; Fri, 15 Aug 2003 19:56:55 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19noRC-0006xe-00 for opes-archive@ietf.org; Fri, 15 Aug 2003 19:56:54 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FNbsqt026076 for ; Fri, 15 Aug 2003 16:37:54 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7FNbsxd026075 for ietf-openproxy-bks; Fri, 15 Aug 2003 16:37:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from linux.grifflink.com (linux.royaleng.com [216.83.131.67]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7FNbqqt026066 for ; Fri, 15 Aug 2003 16:37:53 -0700 (PDT) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by linux.grifflink.com (8.12.8/8.12.8) with ESMTP id h7FNYRql002121; Fri, 15 Aug 2003 17:34:27 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id h7FNMDmH010211; Fri, 15 Aug 2003 17:22:13 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h7FNMDFp010207; Fri, 15 Aug 2003 17:22:13 -0600 Date: Fri, 15 Aug 2003 17:22:13 -0600 Message-Id: <200308152322.h7FNMDFp010207@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: rousskov@measurement-factory.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage Subject: Re: IAB considerations Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sounds like a good way to ensure that the documents never come close to RFC status ... Hilarie On Fri, 15 Aug 2003 at 17:14:48 -0600 (MDT) Alex Rousskov scribbled: > My suggestion is > that we do not treat IAB concerns literary but apply our better > understanding of the problem domain to satisfy "true" IAB intent. From owner-ietf-openproxy@mail.imc.org Sat Aug 16 07:44:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09726 for ; Sat, 16 Aug 2003 07:44:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nzTs-0002vo-00 for opes-archive@ietf.org; Sat, 16 Aug 2003 07:44:25 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19nzTs-0002vl-00 for opes-archive@ietf.org; Sat, 16 Aug 2003 07:44:24 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7GBO2qt090303 for ; Sat, 16 Aug 2003 04:24:02 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7GBO1bc090302 for ietf-openproxy-bks; Sat, 16 Aug 2003 04:24:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7GBNwqt090293 for ; Sat, 16 Aug 2003 04:23:59 -0700 (PDT) (envelope-from info@utel.net) Received: from f02v-16-38.d0.club-internet.fr ([212.195.235.38] helo=jfc2.utel.net) by hosting.altserver.com with esmtp (Exim 4.20) id 19nz9g-00005c-7o; Sat, 16 Aug 2003 04:23:34 -0700 Message-Id: <5.2.0.9.0.20030816125612.00ab9300@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 16 Aug 2003 13:01:49 +0200 To: "The Purple Streak, Hilarie Orman" , rousskov@measurement-factory.com From: jfcm Subject: Re: IAB considerations Cc: ietf-openproxy@imc.org In-Reply-To: <200308152322.h7FNMDFp010207@localhost.localdomain> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 01:22 16/08/03, The Purple Streak, Hilarie Orman wrote: >Sounds like a good way to ensure that the documents never come close to >RFC status ... Understood and accepted. This in turns sounds like the best explnation why my job is delayed for 15 years due to what some call the IAB ineptitude to understand the real world. This is not a critic of the concerned people but of the very nature of the consensual system. Good for developement specification, not for innovative architecture. Now question is: shall we stay with everyone, or shall we make them move ahaead? jfc >On Fri, 15 Aug 2003 at 17:14:48 -0600 (MDT) Alex Rousskov scribbled: > > My suggestion is > > that we do not treat IAB concerns literary but apply our better > > understanding of the problem domain to satisfy "true" IAB intent. > > > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.507 / Virus Database: 304 - Release Date: 04/08/03 From owner-ietf-openproxy@mail.imc.org Sat Aug 16 10:32:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12597 for ; Sat, 16 Aug 2003 10:32:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19o26u-0003P5-00 for opes-archive@ietf.org; Sat, 16 Aug 2003 10:32:52 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19o26u-0003P2-00 for opes-archive@ietf.org; Sat, 16 Aug 2003 10:32:52 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7GEDRqt002840 for ; Sat, 16 Aug 2003 07:13:27 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7GEDR3g002839 for ietf-openproxy-bks; Sat, 16 Aug 2003 07:13:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from drakken.dbc.mtview.ca.us (adsl-64-168-10-254.dsl.scrm01.pacbell.net [64.168.10.254]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7GEDQqt002833 for ; Sat, 16 Aug 2003 07:13:26 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from drakken.dbc.mtview.ca.us (localhost [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.9/8.12.9) with SMTP id h7GEDPNV000326; Sat, 16 Aug 2003 07:13:25 -0700 (PDT) Date: Sat, 16 Aug 2003 07:13:25 -0700 From: Marshall Rose To: ietf-openproxy@imc.org Subject: Re: IAB considerations Message-Id: <20030816071325.05f0451e.mrose@dbc.mtview.ca.us> In-Reply-To: <5.2.0.9.0.20030816125612.00ab9300@mail.utel.net> References: <5.2.0.9.0.20030816125612.00ab9300@mail.utel.net> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit [ speaking as co-chair... ] guys - this is tiring, so let's go back to first principles. the charter is quite clear in saying that the work product has to address the IAB considerations. it is also quite clear in stating that the work product can diverge from those considerations providing that it clearly documents the rationale. to topic of what the iab/framers know or didn't know isn't relevant. what is relevant is that the document editors need to make sure that there is concise explanations as to why a given document diverges, so that the poor iesg can decide whether the trade-off is acceptable. (by definition, only the iesg and iab know what "the big picture" is.) thanks, /mtr From owner-ietf-openproxy@mail.imc.org Sat Aug 16 14:33:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15705 for ; Sat, 16 Aug 2003 14:33:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19o5s9-0004KO-00 for opes-archive@ietf.org; Sat, 16 Aug 2003 14:33:53 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19o5s8-0004KL-00 for opes-archive@ietf.org; Sat, 16 Aug 2003 14:33:52 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7GIHpqt015093 for ; Sat, 16 Aug 2003 11:17:51 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7GIHp27015092 for ietf-openproxy-bks; Sat, 16 Aug 2003 11:17:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7GIHoqt015087 for ; Sat, 16 Aug 2003 11:17:50 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7GIHkMS052875; Sat, 16 Aug 2003 12:17:46 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7GIHkaZ052874; Sat, 16 Aug 2003 12:17:46 -0600 (MDT) (envelope-from rousskov) Date: Sat, 16 Aug 2003 12:17:46 -0600 (MDT) From: Alex Rousskov To: Marshall Rose cc: ietf-openproxy@imc.org Subject: Re: IAB considerations In-Reply-To: <20030816071325.05f0451e.mrose@dbc.mtview.ca.us> Message-ID: References: <5.2.0.9.0.20030816125612.00ab9300@mail.utel.net> <20030816071325.05f0451e.mrose@dbc.mtview.ca.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Marshall, I agree with your statement 100%. That is exactly what I was trying to do when writing the "IAB treatment" draft: address what we can, document what we cannot, and explain why. However, Hillarie asserts, in part, that if IAB says "OPES processor MUST be addressible" then it must be addressible even it makes no sense or is technically impossible. I disagree with such a position. I assume that IAB will listen to reasonable arguments. This difference in assumptions/approaches caused the discussion on this thread. I am not sure how to proceed though. Clearly, we cannot say both "OPES processor MUST be addressible" and "OPES processor MAY be addressible". We have to pick wether our primary unit of concern is OPES system as a whole or each OPES processor inside the system. I think I used up all the arguments for the former. If Hillarie is not convinced, we are stuck. Alex. On Sat, 16 Aug 2003, Marshall Rose wrote: > > [ speaking as co-chair... ] > > guys - this is tiring, so let's go back to first principles. > > the charter is quite clear in saying that the work product has to > address the IAB considerations. it is also quite clear in stating that > the work product can diverge from those considerations providing that it > clearly documents the rationale. > > to topic of what the iab/framers know or didn't know isn't > relevant. what is relevant is that the document editors need to make > sure that there is concise explanations as to why a given document > diverges, so that the poor iesg can decide whether the trade-off is > acceptable. (by definition, only the iesg and iab know what "the big > picture" is.) > > thanks, > > /mtr > > From owner-ietf-openproxy@mail.imc.org Sat Aug 16 16:23:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17920 for ; Sat, 16 Aug 2003 16:23:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19o7ah-0004cY-00 for opes-archive@ietf.org; Sat, 16 Aug 2003 16:23:59 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19o7ag-0004cV-00 for opes-archive@ietf.org; Sat, 16 Aug 2003 16:23:58 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7GK6Tqt019092 for ; Sat, 16 Aug 2003 13:06:29 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7GK6Tw5019091 for ietf-openproxy-bks; Sat, 16 Aug 2003 13:06:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7GK6Sqt019086 for ; Sat, 16 Aug 2003 13:06:28 -0700 (PDT) (envelope-from info@utel.net) Received: from f01v-25-191.d0.club-internet.fr ([212.195.244.191] helo=jfc2.utel.net) by hosting.altserver.com with esmtp (Exim 4.20) id 19o7Je-0002te-UA; Sat, 16 Aug 2003 13:06:23 -0700 Message-Id: <5.2.0.9.0.20030816213454.029e8be0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 16 Aug 2003 21:56:25 +0200 To: Alex Rousskov , Marshall Rose From: jfcm Subject: Re: IAB considerations Cc: ietf-openproxy@imc.org In-Reply-To: References: <20030816071325.05f0451e.mrose@dbc.mtview.ca.us> <5.2.0.9.0.20030816125612.00ab9300@mail.utel.net> <20030816071325.05f0451e.mrose@dbc.mtview.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 20:17 16/08/03, Alex Rousskov wrote: >If Hillarie is not convinced, we are stuck. I do not think so. If we take back the thinking we have; 1. IAB says each processor MUST be addressable 2. we say each OPES processor belongs to a domain 3. the owner of the domain may not want each of its OPES processors to be disclosed. 1. It seems that we can say that each OPES processor in an OPES system MUST be addressable through its OPES domain sub-address, however povided his OPES domain address is tracable; a domain owner MAY opacfied the sub-address of his processors. 2. in the security part it can be underlined that the OPES domain owners should be adviszed not to disclose the domain adress of their processors or to provide coded addresses suitable for trouble shouting but not for access. jfc From owner-ietf-openproxy@mail.imc.org Sat Aug 16 23:53:37 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23693 for ; Sat, 16 Aug 2003 23:53:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oEbt-0005zb-00 for opes-archive@ietf.org; Sat, 16 Aug 2003 23:53:41 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19oEbs-0005zX-00 for opes-archive@ietf.org; Sat, 16 Aug 2003 23:53:40 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7H3XWqt037143 for ; Sat, 16 Aug 2003 20:33:32 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7H3XWKe037142 for ietf-openproxy-bks; Sat, 16 Aug 2003 20:33:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7H3XUqt037136 for ; Sat, 16 Aug 2003 20:33:31 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7H3XXMS065501; Sat, 16 Aug 2003 21:33:33 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7H3XXse065500; Sat, 16 Aug 2003 21:33:33 -0600 (MDT) (envelope-from rousskov) Date: Sat, 16 Aug 2003 21:33:33 -0600 (MDT) From: Alex Rousskov To: jfcm cc: OPES WG Subject: Re: IAB considerations In-Reply-To: <5.2.0.9.0.20030816213454.029e8be0@mail.utel.net> Message-ID: References: <20030816071325.05f0451e.mrose@dbc.mtview.ca.us> <5.2.0.9.0.20030816125612.00ab9300@mail.utel.net> <20030816071325.05f0451e.mrose@dbc.mtview.ca.us> <5.2.0.9.0.20030816213454.029e8be0@mail.utel.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 16 Aug 2003, jfcm wrote: > At 20:17 16/08/03, Alex Rousskov wrote: > >If Hillarie is not convinced, we are stuck. > > I do not think so. If we take back the thinking we have; > > 1. IAB says each processor MUST be addressable > 2. we say each OPES processor belongs to a domain > 3. the owner of the domain may not want each of its OPES processors to be > disclosed. > > 1. It seems that we can say that each OPES processor in an OPES > system MUST be addressable through its OPES domain sub-address, > however povided his OPES domain address is tracable; a domain owner > MAY opacfied the sub-address of his processors. > > 2. in the security part it can be underlined that the OPES domain > owners should be adviszed not to disclose the domain adress of their > processors or to provide coded addresses suitable for trouble > shouting but not for access. First of all, you are mixing two distinct properties: IP-level addressability by end user (IAB consideration 2.2) and OPES processor identification in the trace for end user (IAB consideration 3.2). The opaque IDs will not make internal OPES processors addressable at IP level. Nothing short of OPES-specific VPNs will -- the whole point of an internal host is that it is not IP-addressable from the outside! If we concentrate on processor identification alone, then I agree with your approach as long as "opacification" (making opaque) of OPES IDs includes removing them completely. There is absolutely no reason for us to tell content provider how to identify their internal systems. In a simple case, for example, there will be a single path through the OPES system and no individual processor identification will be necessary. Combining the two observations above, we can see that we should concentrate on specifying OPES system IDs and may ignore all other IDs until we have spare cycles to waste. Alex. From owner-ietf-openproxy@mail.imc.org Sun Aug 17 01:00:31 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24304 for ; Sun, 17 Aug 2003 01:00:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oFea-0006Hs-00 for opes-archive@ietf.org; Sun, 17 Aug 2003 01:00:32 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19oFea-0006Hp-00 for opes-archive@ietf.org; Sun, 17 Aug 2003 01:00:32 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7H4hvqt039944 for ; Sat, 16 Aug 2003 21:43:57 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7H4hvOO039943 for ietf-openproxy-bks; Sat, 16 Aug 2003 21:43:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7H4huqt039938 for ; Sat, 16 Aug 2003 21:43:56 -0700 (PDT) (envelope-from info@utel.net) Received: from f01v-27-246.d0.club-internet.fr ([212.195.246.246] helo=jfc2.utel.net) by hosting.altserver.com with esmtp (Exim 4.20) id 19oFOY-0007nJ-KE; Sat, 16 Aug 2003 21:43:59 -0700 Message-Id: <5.2.0.9.0.20030817064637.02c6bd20@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 17 Aug 2003 06:54:08 +0200 To: Alex Rousskov From: jfcm Subject: Re: IAB considerations Cc: OPES WG In-Reply-To: References: <5.2.0.9.0.20030816213454.029e8be0@mail.utel.net> <20030816071325.05f0451e.mrose@dbc.mtview.ca.us> <5.2.0.9.0.20030816125612.00ab9300@mail.utel.net> <20030816071325.05f0451e.mrose@dbc.mtview.ca.us> <5.2.0.9.0.20030816213454.029e8be0@mail.utel.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 05:33 17/08/03, Alex Rousskov wrote: >First of all, you are mixing two distinct properties: IP-level >addressability by end user (IAB consideration 2.2) and OPES processor >identification in the trace for end user (IAB consideration 3.2). I obvilusly know. We have an arbitrary logic demand and we have oractual needs. We have to start fomr the practical needs and see how/if they can match the arbitrary logic, to doucment a response. >Combining the two observations above, we can see that we should >concentrate on specifying OPES system IDs and may ignore all other IDs >until we have spare cycles to waste. Here I disagree. Identifying various OPES operators domain and reacting on that information is important. Because for example I do nottryst them or I do not make or I make business with them. jfc From owner-ietf-openproxy@mail.imc.org Sun Aug 17 14:03:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17012 for ; Sun, 17 Aug 2003 14:03:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oRry-0001xo-00 for opes-archive@ietf.org; Sun, 17 Aug 2003 14:03:10 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19oRrx-0001xi-00 for opes-archive@ietf.org; Sun, 17 Aug 2003 14:03:09 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7HHmdqt025282 for ; Sun, 17 Aug 2003 10:48:39 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7HHmdTl025281 for ietf-openproxy-bks; Sun, 17 Aug 2003 10:48:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from drakken.dbc.mtview.ca.us (adsl-64-168-10-254.dsl.scrm01.pacbell.net [64.168.10.254]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7HHmcqt025276 for ; Sun, 17 Aug 2003 10:48:38 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from drakken.dbc.mtview.ca.us (localhost [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.9/8.12.9) with SMTP id h7HHmcD5001754; Sun, 17 Aug 2003 10:48:38 -0700 (PDT) Date: Sun, 17 Aug 2003 10:48:38 -0700 From: Marshall Rose To: Alex Rousskov Cc: ietf-openproxy@imc.org Subject: Re: IAB considerations Message-Id: <20030817104838.5bc3d1ff.mrose@dbc.mtview.ca.us> In-Reply-To: References: <5.2.0.9.0.20030816125612.00ab9300@mail.utel.net> <20030816071325.05f0451e.mrose@dbc.mtview.ca.us> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > However, Hillarie asserts, in part, that if IAB says "OPES > processor MUST be addressible" then it must be addressible even it > makes no sense or is technically impossible. I disagree with such a > position. I assume that IAB will listen to reasonable arguments. This > difference in assumptions/approaches caused the discussion on this > thread. let's try this: edit the draft so that is complete and self-consistent. to the extent it differs from what the IAB recommends, make sure that the differences are explain and justified. then have a friend take a pass through the document for clarity and conciseness. we will then see if we have concensus around that document. if so, we'll move forward, and wait to from the powers-that-be. if not, we'll try a different approach. /mtr From owner-ietf-openproxy@mail.imc.org Sun Aug 17 21:25:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25591 for ; Sun, 17 Aug 2003 21:25:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oYmS-0003rp-00 for opes-archive@ietf.org; Sun, 17 Aug 2003 21:25:56 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19oYmR-0003rm-00 for opes-archive@ietf.org; Sun, 17 Aug 2003 21:25:55 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7I1A8qt048173 for ; Sun, 17 Aug 2003 18:10:08 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7I1A89L048170 for ietf-openproxy-bks; Sun, 17 Aug 2003 18:10:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7I1A6qt048146 for ; Sun, 17 Aug 2003 18:10:07 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7I19Tl25852; Sun, 17 Aug 2003 21:09:29 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 17 Aug 2003 21:09:29 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754069B1B91@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Marshall Rose , Alex Rousskov Cc: ietf-openproxy@imc.org Subject: RE: IAB considerations Date: Sun, 17 Aug 2003 21:09:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36525.5F16762E" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C36525.5F16762E Content-Type: text/plain Hi, Sounds like a good plan Abbie > -----Original Message----- > From: Marshall Rose [mailto:mrose@dbc.mtview.ca.us] > Sent: Sunday, August 17, 2003 1:49 PM > To: Alex Rousskov > Cc: ietf-openproxy@imc.org > Subject: Re: IAB considerations > > > > > However, Hillarie asserts, in part, that if IAB says > "OPES processor > > MUST be addressible" then it must be addressible even it makes no > > sense or is technically impossible. I disagree with such a > position. I > > assume that IAB will listen to reasonable arguments. This > difference > > in assumptions/approaches caused the discussion on this thread. > > let's try this: edit the draft so that is complete and > self-consistent. to the extent it differs from what the IAB > recommends, make sure that the differences are explain and > justified. then have a friend take a pass through the > document for clarity and conciseness. > > we will then see if we have concensus around that document. > > if so, we'll move forward, and wait to from the powers-that-be. > > if not, we'll try a different approach. > > /mtr > ------_=_NextPart_001_01C36525.5F16762E Content-Type: text/html RE: IAB considerations

Hi,
Sounds like a good plan

Abbie


> -----Original Message-----
> From: Marshall Rose [mailto:mrose@dbc.mtview.ca.us]
> Sent: Sunday, August 17, 2003 1:49 PM
> To: Alex Rousskov
> Cc: ietf-openproxy@imc.org
> Subject: Re: IAB considerations
>
>
>
> >     However, Hillarie asserts, in part, that if IAB says
> "OPES processor
> > MUST be addressible" then it must be addressible even it makes no
> > sense or is technically impossible. I disagree with such a
> position. I
> > assume that IAB will listen to reasonable arguments. This
> difference
> > in assumptions/approaches caused the discussion on this thread.
>    
> let's try this: edit the draft so that is complete and
> self-consistent. to the extent it differs from what the IAB
> recommends, make sure that the differences are explain and
> justified. then have a friend take a pass through the
> document for clarity and conciseness.
>
> we will then see if we have concensus around that document.
>    
> if so, we'll move forward, and wait to from the powers-that-be.
>    
> if not, we'll try a different approach.
>    
> /mtr
>

------_=_NextPart_001_01C36525.5F16762E-- From owner-ietf-openproxy@mail.imc.org Mon Aug 18 13:54:39 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27448 for ; Mon, 18 Aug 2003 13:54:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ooDJ-0001HO-00 for opes-archive@ietf.org; Mon, 18 Aug 2003 13:54:41 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19ooDI-0001HK-00 for opes-archive@ietf.org; Mon, 18 Aug 2003 13:54:40 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IHc7qt019173 for ; Mon, 18 Aug 2003 10:38:07 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7IHc7e4019172 for ietf-openproxy-bks; Mon, 18 Aug 2003 10:38:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IHc5qt019162 for ; Mon, 18 Aug 2003 10:38:06 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7IHc7MS018351; Mon, 18 Aug 2003 11:38:07 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7IHbvAc018350; Mon, 18 Aug 2003 11:37:57 -0600 (MDT) (envelope-from rousskov) Date: Mon, 18 Aug 2003 11:37:56 -0600 (MDT) From: Alex Rousskov To: jfcm cc: OPES WG Subject: Re: IAB considerations In-Reply-To: <5.2.0.9.0.20030817064637.02c6bd20@mail.utel.net> Message-ID: References: <5.2.0.9.0.20030816213454.029e8be0@mail.utel.net> <20030816071325.05f0451e.mrose@dbc.mtview.ca.us> <5.2.0.9.0.20030816125612.00ab9300@mail.utel.net> <20030816071325.05f0451e.mrose@dbc.mtview.ca.us> <5.2.0.9.0.20030816213454.029e8be0@mail.utel.net> <5.2.0.9.0.20030817064637.02c6bd20@mail.utel.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, 17 Aug 2003, jfcm wrote: > At 05:33 17/08/03, Alex Rousskov wrote: > > >Combining the two observations above, we can see that we should > >concentrate on specifying OPES system IDs and may ignore all other IDs > >until we have spare cycles to waste. > > Here I disagree. Identifying various OPES operators domain and > reacting on that information is important. Because for example I do > nottryst them or I do not make or I make business with them. I dod not say it is not important. It is just a much smaller scale problem, where no good general solution may exist. If this WG does not define a solution for OPES processor identification (but defines OPES system identification), then OPES will still "work" and satisfy IAB concerns (in my rendition of them). The reverse is not true, IMO: OPES processor identification alone will not satisfy IAB (or mine) concerns. Alex. From owner-ietf-openproxy@mail.imc.org Mon Aug 18 13:55:42 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27499 for ; Mon, 18 Aug 2003 13:55:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ooEK-0001Hp-00 for opes-archive@ietf.org; Mon, 18 Aug 2003 13:55:44 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19ooEJ-0001Hm-00 for opes-archive@ietf.org; Mon, 18 Aug 2003 13:55:43 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IHfHqt019281 for ; Mon, 18 Aug 2003 10:41:17 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7IHfHgY019280 for ietf-openproxy-bks; Mon, 18 Aug 2003 10:41:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IHfFqt019275 for ; Mon, 18 Aug 2003 10:41:16 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7IHfGMS018459; Mon, 18 Aug 2003 11:41:16 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7IHfG6R018458; Mon, 18 Aug 2003 11:41:16 -0600 (MDT) (envelope-from rousskov) Date: Mon, 18 Aug 2003 11:41:16 -0600 (MDT) From: Alex Rousskov To: jfcm cc: ietf-openproxy@imc.org Subject: RE: [end points comm] OPES System In-Reply-To: <5.2.0.9.0.20030815021815.02abc2d0@mail.utel.net> Message-ID: References: <5.2.0.9.0.20030815005340.030df090@mail.utel.net> <200308141659.h7EGxTkZ003915@localhost.localdomain> <200308141659.h7EGxTkZ003915@localhost.localdomain> <5.2.0.9.0.20030815005340.030df090@mail.utel.net> <5.2.0.9.0.20030815021815.02abc2d0@mail.utel.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 15 Aug 2003, jfcm wrote: > I name an OPES domain the area of reponsibility of an operator. What's an operator or operator responsibility? When Disney-owned content is created on and made available via Akamai servers, is Disney an operator? Is Akamai? Is Disney+Akamai? Alex. From owner-ietf-openproxy@mail.imc.org Mon Aug 18 16:39:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03757 for ; Mon, 18 Aug 2003 16:39:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oqmU-0002Q4-00 for opes-archive@ietf.org; Mon, 18 Aug 2003 16:39:10 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19oqmT-0002Q1-00 for opes-archive@ietf.org; Mon, 18 Aug 2003 16:39:10 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IKNLqt025779 for ; Mon, 18 Aug 2003 13:23:21 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7IKNLom025778 for ietf-openproxy-bks; Mon, 18 Aug 2003 13:23:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IKNJqt025772 for ; Mon, 18 Aug 2003 13:23:20 -0700 (PDT) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7IKNLHa058912 for ; Mon, 18 Aug 2003 16:23:21 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7IKNB2e056101 for ; Mon, 18 Aug 2003 16:23:15 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7IKN7FU023691 for ; Mon, 18 Aug 2003 16:23:11 -0400 (EDT) Message-ID: <3F413601.4070909@mhof.com> Date: Mon, 18 Aug 2003 16:24:33 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: [end points comm] OPES System References: <5.2.0.9.0.20030815005340.030df090@mail.utel.net> <200308141659.h7EGxTkZ003915@localhost.localdomain> <200308141659.h7EGxTkZ003915@localhost.localdomain> <5.2.0.9.0.20030815005340.030df090@mail.utel.net> <5.2.0.9.0.20030815021815.02abc2d0@mail.utel.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi, rather than responding to individual emails, let me try to summarize the thread (while catching-up with queued emails...). Goal: Tracing must allow the endpoints to detect that some OPES services were involved, and which party to contact in order to resolve possible problems. This has resulted in different views: (a) One view is that this requires each individual OPES processor to support tracing. Policies can be used to authorize who can turn on tracing and who can see the results. (b) Another view is that this requires only one trace per "OPES system", with an "OPES system" being the collection of entities that are trusted by the respective endpoint. This assumes that certain business arrangements/rules are in place, which will ensure that problems can be traced across carrier domains. (c) One view might be that this requires only tracing per "OPES domain", with an "OPES domain" being the collection of entities operated by a single carrier. Both, (b) and (c), assume that the carriers somehow have enough (internal) information to answer possible inquiries, e.g. they themselves must figure out which exact OPES processors have been involved when a specific user inquiry comes in. For each of the views, it would be helpful to detail and to illustrate the entire tracing process showing an example scenario, including how a user would inquire about suspected problems and how this inquiry would be resolved. [It might also be helpful to learn from existing solutions to similar problems in other protocol areas, e.g. email etc.] Since (b) seems to be the most "relaxed" view, let's start with this approach, and then see whether/how it solves real-life problems, whether the assumptions are valid, how it addresses the IAB considerations, and how differences to IAB consideration will be explained. -Markus From owner-ietf-openproxy@mail.imc.org Mon Aug 18 16:46:22 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03953 for ; Mon, 18 Aug 2003 16:46:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oqtV-0002Sd-00 for opes-archive@ietf.org; Mon, 18 Aug 2003 16:46:25 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19oqtU-0002SU-00 for opes-archive@ietf.org; Mon, 18 Aug 2003 16:46:24 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IKUmqt026092 for ; Mon, 18 Aug 2003 13:30:48 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7IKUmIk026091 for ietf-openproxy-bks; Mon, 18 Aug 2003 13:30:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IKUlqt026085 for ; Mon, 18 Aug 2003 13:30:47 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7IKUm9Y081454 for ; Mon, 18 Aug 2003 16:30:48 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7IKUfF2026388 for ; Mon, 18 Aug 2003 16:30:41 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7IKUfFU023786 for ; Mon, 18 Aug 2003 16:30:41 -0400 (EDT) Message-ID: <3F4137C8.2090804@mhof.com> Date: Mon, 18 Aug 2003 16:32:08 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: OPES Group Subject: Re: [end points comm] OPES System References: <5.2.0.9.0.20030811225712.045792f0@mail.utel.net> <3F38F2C1.9040701@mhof.com> <5.2.0.9.0.20030813232801.0308dec0@mail.utel.net> In-Reply-To: <5.2.0.9.0.20030813232801.0308dec0@mail.utel.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit jfcm wrote: > please stop confusing system and domains! Not sure wheher I'm the one who's confusing things... I refered to "OPES domain" as a collection of OPES entities operated by a single carrier, while an "OPES system" is rather described by trust boundaries. Depending on how we define tracing, we probably need only one of the terms. -Markus From owner-ietf-openproxy@mail.imc.org Mon Aug 18 16:46:30 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03972 for ; Mon, 18 Aug 2003 16:46:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oqtd-0002So-00 for opes-archive@ietf.org; Mon, 18 Aug 2003 16:46:33 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19oqtc-0002Sl-00 for opes-archive@ietf.org; Mon, 18 Aug 2003 16:46:32 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IKXJqt026165 for ; Mon, 18 Aug 2003 13:33:19 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7IKXJHw026164 for ietf-openproxy-bks; Mon, 18 Aug 2003 13:33:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IKXIqt026158 for ; Mon, 18 Aug 2003 13:33:18 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7IKXK9Y081464 for ; Mon, 18 Aug 2003 16:33:20 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7IKXDF2026572 for ; Mon, 18 Aug 2003 16:33:13 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7IKXDFU023825 for ; Mon, 18 Aug 2003 16:33:13 -0400 (EDT) Message-ID: <3F41385F.1060506@mhof.com> Date: Mon, 18 Aug 2003 16:34:39 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: IAB considerations References: <200307242119.h6OLJ5tJ003643@localhost.localdomain> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > [...] Moreover, I think Markus intended to get such a > second opinion sometime soon, using the existing draft. Let's add some more details and, in particular, an example showing a specific trace flow and how it would be used to resolve problems. My feeling is that this would be helpful when asking of additional opinions. -Markus From owner-ietf-openproxy@mail.imc.org Mon Aug 18 17:35:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05440 for ; Mon, 18 Aug 2003 17:35:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oreZ-0002nA-00 for opes-archive@ietf.org; Mon, 18 Aug 2003 17:35:03 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19oreY-0002n7-00 for opes-archive@ietf.org; Mon, 18 Aug 2003 17:35:02 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ILJoqt027608 for ; Mon, 18 Aug 2003 14:19:50 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7ILJor4027607 for ietf-openproxy-bks; Mon, 18 Aug 2003 14:19:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ILJmqt027602 for ; Mon, 18 Aug 2003 14:19:48 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7ILJoMS024669; Mon, 18 Aug 2003 15:19:50 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7ILJoO4024668; Mon, 18 Aug 2003 15:19:50 -0600 (MDT) (envelope-from rousskov) Date: Mon, 18 Aug 2003 15:19:50 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: Re: IAB considerations In-Reply-To: <3F41385F.1060506@mhof.com> Message-ID: References: <200307242119.h6OLJ5tJ003643@localhost.localdomain> <3F41385F.1060506@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 18 Aug 2003, Markus Hofmann wrote: > Alex Rousskov wrote: > > > [...] Moreover, I think Markus intended to get such a > > second opinion sometime soon, using the existing draft. > > Let's add some more details and, in particular, an example showing a > specific trace flow and how it would be used to resolve problems. My > feeling is that this would be helpful when asking of additional > opinions. Agreed. In theory, three drafts will need to updated to provide an example: OPES communications draft (Abbie), HTTP adaptation draft (Martin Stecher or myself), and IAB treatment draft (Abbie or myself). I will update IAB treatment draft soon. That should be enough to get us started with the IAB review and other drafts can catch up if the review is positive. Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Mon Aug 18 17:45:29 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05789 for ; Mon, 18 Aug 2003 17:45:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oroi-0002qg-00 for opes-archive@ietf.org; Mon, 18 Aug 2003 17:45:32 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19oroh-0002qc-00 for opes-archive@ietf.org; Mon, 18 Aug 2003 17:45:31 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ILWXqt027925 for ; Mon, 18 Aug 2003 14:32:33 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7ILWXs9027924 for ietf-openproxy-bks; Mon, 18 Aug 2003 14:32:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ILWWqt027919 for ; Mon, 18 Aug 2003 14:32:32 -0700 (PDT) (envelope-from info@utel.net) Received: from f01m-22-57.d0.club-internet.fr ([212.195.221.57] helo=jfc2.utel.net) by hosting.altserver.com with esmtp (Exim 4.20) id 19orc2-0002iF-KZ; Mon, 18 Aug 2003 14:32:30 -0700 Message-Id: <5.2.0.9.0.20030818231505.03a11bd0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 18 Aug 2003 23:23:57 +0200 To: Alex Rousskov From: jfcm Subject: RE: [end points comm] OPES System Cc: ietf-openproxy@imc.org In-Reply-To: References: <5.2.0.9.0.20030815021815.02abc2d0@mail.utel.net> <5.2.0.9.0.20030815005340.030df090@mail.utel.net> <200308141659.h7EGxTkZ003915@localhost.localdomain> <200308141659.h7EGxTkZ003915@localhost.localdomain> <5.2.0.9.0.20030815005340.030df090@mail.utel.net> <5.2.0.9.0.20030815021815.02abc2d0@mail.utel.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 19:41 18/08/03, Alex Rousskov wrote: >On Fri, 15 Aug 2003, jfcm wrote: > > I name an OPES domain the area of reponsibility of an operator. > >What's an operator or operator responsibility? When Disney-owned >content is created on and made available via Akamai servers, is Disney >an operator? Is Akamai? Is Disney+Akamai? This is where you are confusing the issues by pleasure. The responsible operator is the one saying he is responsible. Stick to your airline image and do not make too many layer violation. NO processor should be without domain operator. And no processor can be with two separate domain owner. Otherwise I will/people will _NEVER_ trust.use an OPES. This means that every processor MUST be something and that something is to be decided by its operator. And as a SYSTEM user I must be able to say/decide if I trust or not an operator for who he is or for the information he discloses or for the cost of his services. You just do not pick any cab (system) because they are cabs. And every cab has a number makingtem part of a domain/company. They can fake them, they can hide them. It is up to you to decide if you trust or not a hiden number cab, for example because you like the name of the cab company or because you want to commit suicide. jfc >Alex. > > > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.507 / Virus Database: 304 - Release Date: 04/08/03 From owner-ietf-openproxy@mail.imc.org Mon Aug 18 17:54:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05952 for ; Mon, 18 Aug 2003 17:54:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19orxq-0002tb-00 for opes-archive@ietf.org; Mon, 18 Aug 2003 17:54:58 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19orxq-0002tY-00 for opes-archive@ietf.org; Mon, 18 Aug 2003 17:54:58 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ILf8qt028133 for ; Mon, 18 Aug 2003 14:41:08 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7ILf8vG028132 for ietf-openproxy-bks; Mon, 18 Aug 2003 14:41:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ILf6qt028127 for ; Mon, 18 Aug 2003 14:41:06 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7ILf8MS025253; Mon, 18 Aug 2003 15:41:08 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7ILf8tr025252; Mon, 18 Aug 2003 15:41:08 -0600 (MDT) (envelope-from rousskov) Date: Mon, 18 Aug 2003 15:41:08 -0600 (MDT) From: Alex Rousskov To: jfcm cc: ietf-openproxy@imc.org Subject: RE: [end points comm] OPES System In-Reply-To: <5.2.0.9.0.20030818231505.03a11bd0@mail.utel.net> Message-ID: References: <5.2.0.9.0.20030815021815.02abc2d0@mail.utel.net> <5.2.0.9.0.20030815005340.030df090@mail.utel.net> <200308141659.h7EGxTkZ003915@localhost.localdomain> <200308141659.h7EGxTkZ003915@localhost.localdomain> <5.2.0.9.0.20030815005340.030df090@mail.utel.net> <5.2.0.9.0.20030815021815.02abc2d0@mail.utel.net> <5.2.0.9.0.20030818231505.03a11bd0@mail.utel.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 18 Aug 2003, jfcm wrote: > At 19:41 18/08/03, Alex Rousskov wrote: > > >On Fri, 15 Aug 2003, jfcm wrote: > > > I name an OPES domain the area of reponsibility of an operator. > > > >What's an operator or operator responsibility? When Disney-owned > >content is created on and made available via Akamai servers, is Disney > >an operator? Is Akamai? Is Disney+Akamai? > > This is where you are confusing the issues by pleasure. > The responsible operator is the one saying he is responsible. > Stick to your airline image and do not make too many layer violation. > > NO processor should be without domain operator. And no processor can be > with two separate domain owner. Otherwise I will/people will _NEVER_ > trust.use an OPES. > > This means that every processor MUST be something and that something > is to be decided by its operator. And as a SYSTEM user I must be > able to say/decide if I trust or not an operator for who he is or > for the information he discloses or for the cost of his services. That's fine, but you need a better definition of a domain and/or operator. The original "OPES domain is the area of reponsibility of an operator" does not imply the above explanation. Also, since you leave domain boundaries for the operator to decide, you need to explain how conflicts (two operators think they are responsible for the same domain and instruct their processors to update the trace accordingly) and misses (no operator claims responsibility for a domain/processor). Alex. From owner-ietf-openproxy@mail.imc.org Mon Aug 18 18:21:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07750 for ; Mon, 18 Aug 2003 18:21:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19osNG-00034H-00 for opes-archive@ietf.org; Mon, 18 Aug 2003 18:21:14 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19osNG-00034E-00 for opes-archive@ietf.org; Mon, 18 Aug 2003 18:21:14 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IM6dqt029108 for ; Mon, 18 Aug 2003 15:06:39 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7IM6dJN029107 for ietf-openproxy-bks; Mon, 18 Aug 2003 15:06:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IM6cqt029102 for ; Mon, 18 Aug 2003 15:06:38 -0700 (PDT) (envelope-from info@utel.net) Received: from f01m-22-57.d0.club-internet.fr ([212.195.221.57] helo=jfc2.utel.net) by hosting.altserver.com with esmtp (Exim 4.20) id 19os91-0006WF-11; Mon, 18 Aug 2003 15:06:33 -0700 Message-Id: <5.2.0.9.0.20030819000141.03a32020@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 19 Aug 2003 00:15:07 +0200 To: Markus Hofmann From: jfcm Subject: Re: [end points comm] OPES System Cc: OPES Group In-Reply-To: <3F4137C8.2090804@mhof.com> References: <5.2.0.9.0.20030813232801.0308dec0@mail.utel.net> <5.2.0.9.0.20030811225712.045792f0@mail.utel.net> <3F38F2C1.9040701@mhof.com> <5.2.0.9.0.20030813232801.0308dec0@mail.utel.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 22:32 18/08/03, Markus Hofmann wrote: >jfcm wrote: > >>please stop confusing system and domains! > >Not sure wheher I'm the one who's confusing things... > >I refered to "OPES domain" as a collection of OPES entities operated by a >single carrier, while an "OPES system" is rather described by trust >boundaries. Depending on how we define tracing, we probably need only one >of the terms. No, sir. The OPES system is the system providing me/I organize to provide me a service. I need to reference it. But I can have several OPES system providing me the same service. Each of theses OPES system can be actually built in using system bu different operators with different responsibilities. Example: My ISP provides me translating services of the web pages I access. He calls on several services depending on the language: this is his WEBTranslationSystem He also provide the same translation service for mail he names Translate-mailSystem. These are two different systems and I need to identify them. Now WEBTS uses different translation servers, so does Te-mS. One is BBC and one is CNN. I does not like CNN, so I want to bar the CNN domain. As he does not want to lose me my ISP accepts to trim the load and to permit me to use BBC on both System but with a markup on Te-mS as it is a special service. Now I may decide to degrade to CNN on option for low importance mails. I obviously want to automate all that and be able to make statitstics etc. Now, CNN can come with a special deal: if I accept some delays they will permit me to use some of their processors @ lower cost, etc.... The system is my/someone decided construct. Like an Airline System. The domain is the processor owner accepted area of responsiblity? Like an Airport. Now to know if this is runway 31 or runway 33, (identifiying each processor) this may or not be of used and disclosed by the domain owner, potentially to who they want (crypted). Two totally different things. jfc From owner-ietf-openproxy@mail.imc.org Mon Aug 18 19:25:18 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09236 for ; Mon, 18 Aug 2003 19:25:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19otNH-0003Rx-00 for opes-archive@ietf.org; Mon, 18 Aug 2003 19:25:19 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19otNH-0003Ru-00 for opes-archive@ietf.org; Mon, 18 Aug 2003 19:25:19 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IN9dqt031163 for ; Mon, 18 Aug 2003 16:09:39 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7IN9cU9031162 for ietf-openproxy-bks; Mon, 18 Aug 2003 16:09:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com (hosting.altserver.com [209.124.80.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7IN9cqt031157 for ; Mon, 18 Aug 2003 16:09:38 -0700 (PDT) (envelope-from info@utel.net) Received: from f01m-22-57.d0.club-internet.fr ([212.195.221.57] helo=jfc2.utel.net) by hosting.altserver.com with esmtp (Exim 4.20) id 19ot7z-00058U-V4; Mon, 18 Aug 2003 16:09:35 -0700 Message-Id: <5.2.0.9.0.20030819005321.02a88230@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 19 Aug 2003 01:08:29 +0200 To: Alex Rousskov From: jfcm Subject: RE: [end points comm] OPES System Cc: ietf-openproxy@imc.org In-Reply-To: References: <5.2.0.9.0.20030818231505.03a11bd0@mail.utel.net> <5.2.0.9.0.20030815021815.02abc2d0@mail.utel.net> <5.2.0.9.0.20030815005340.030df090@mail.utel.net> <200308141659.h7EGxTkZ003915@localhost.localdomain> <200308141659.h7EGxTkZ003915@localhost.localdomain> <5.2.0.9.0.20030815005340.030df090@mail.utel.net> <5.2.0.9.0.20030815021815.02abc2d0@mail.utel.net> <5.2.0.9.0.20030818231505.03a11bd0@mail.utel.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 23:41 18/08/03, Alex Rousskov wrote: >On Mon, 18 Aug 2003, jfcm wrote: > > At 19:41 18/08/03, Alex Rousskov wrote: > > > > >On Fri, 15 Aug 2003, jfcm wrote: > > > > I name an OPES domain the area of reponsibility of an operator. > > > > > >What's an operator or operator responsibility? When Disney-owned > > >content is created on and made available via Akamai servers, is Disney > > >an operator? Is Akamai? Is Disney+Akamai? > > > > This is where you are confusing the issues by pleasure. > > The responsible operator is the one saying he is responsible. > > Stick to your airline image and do not make too many layer violation. > > > > NO processor should be without domain operator. And no processor can be > > with two separate domain owner. Otherwise I will/people will _NEVER_ > > trust.use an OPES. > > > > This means that every processor MUST be something and that something > > is to be decided by its operator. And as a SYSTEM user I must be > > able to say/decide if I trust or not an operator for who he is or > > for the information he discloses or for the cost of his services. > >That's fine, but you need a better definition of a domain and/or >operator. The original "OPES domain is the area of reponsibility of an >operator" does not imply the above explanation. > >Also, since you leave domain boundaries for the operator to decide, >you need to explain how conflicts (two operators think they are >responsible for the same domain and instruct their processors to >update the trace accordingly) and misses (no operator claims >responsibility for a domain/processor). I must go. But I think better anyway to proceed with a general response and see what you objet as I do not understand your question. So I suppose there is confusion to clarify. Let stick to the Airline image. And let take the following analogy (different of the one I took with Markus, but as good and clearer here). A jet = processor An airline = domain - area of responsibility of the ariline operator. An alliance (or a tour or a travel I organize, etc.) = a system Are all your questions answered or not? If not where are you difficulties coming from? The analogy or from not addressed conflicts? jfc From owner-ietf-openproxy@mail.imc.org Tue Aug 19 10:58:29 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16360 for ; Tue, 19 Aug 2003 10:58:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p7wP-0001dz-00 for opes-archive@ietf.org; Tue, 19 Aug 2003 10:58:33 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19p7wO-0001dv-00 for opes-archive@ietf.org; Tue, 19 Aug 2003 10:58:32 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JEhfqt001784 for ; Tue, 19 Aug 2003 07:43:41 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7JEhfCU001783 for ietf-openproxy-bks; Tue, 19 Aug 2003 07:43:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JEhdqt001778 for ; Tue, 19 Aug 2003 07:43:39 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7JEheMS049908; Tue, 19 Aug 2003 08:43:40 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7JEherv049907; Tue, 19 Aug 2003 08:43:40 -0600 (MDT) (envelope-from rousskov) Date: Tue, 19 Aug 2003 08:43:40 -0600 (MDT) From: Alex Rousskov To: jfcm cc: ietf-openproxy@imc.org Subject: RE: [end points comm] OPES System In-Reply-To: <5.2.0.9.0.20030819005321.02a88230@mail.utel.net> Message-ID: References: <5.2.0.9.0.20030818231505.03a11bd0@mail.utel.net> <5.2.0.9.0.20030815021815.02abc2d0@mail.utel.net> <5.2.0.9.0.20030815005340.030df090@mail.utel.net> <200308141659.h7EGxTkZ003915@localhost.localdomain> <200308141659.h7EGxTkZ003915@localhost.localdomain> <5.2.0.9.0.20030815005340.030df090@mail.utel.net> <5.2.0.9.0.20030815021815.02abc2d0@mail.utel.net> <5.2.0.9.0.20030818231505.03a11bd0@mail.utel.net> <5.2.0.9.0.20030819005321.02a88230@mail.utel.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 19 Aug 2003, jfcm wrote: > At 23:41 18/08/03, Alex Rousskov wrote: > > > >That's fine, but you need a better definition of a domain and/or > >operator. The original "OPES domain is the area of reponsibility of > >an operator" does not imply the above explanation. > > > >Also, since you leave domain boundaries for the operator to decide, > >you need to explain how conflicts (two operators think they are > >responsible for the same domain and instruct their processors to > >update the trace accordingly) and misses (no operator claims > >responsibility for a domain/processor). > > I must go. But I think better anyway to proceed with a general > response and see what you objet as I do not understand your > question. So I suppose there is confusion to clarify. > > Let stick to the Airline image. And let take the following analogy > (different of the one I took with Markus, but as good and clearer > here). > > A jet = processor > An airline = domain - area of responsibility of the ariline operator. > An alliance (or a tour or a travel I organize, etc.) = a system > > Are all your questions answered or not? > If not where are you difficulties coming from? > The analogy or from not addressed conflicts? I can use the airline analogy to illustrate what is missing in your definitions, though it may not be a perfect example: Lack of responsibility: Your tour group arrives at the destination with their bags lost. They call you (the "system" contact point) to complain. You tell them that the bags are not your responsibility and they should check with the last jet airline. They go to the last airline, Northwest Airlines. Northwest tells them that the last leg on their itinerary was operated by KLM and they have to complain to KLM. KLM says that based on their agreement with Northwest, Northwest is responsible for the lost baggage. Thus, your group has contacted three suspects and all refused to take responsibility. Since your definitions rely on somebody to accept/define responsibility, it is not clear who is at fault here. Double responsibility: Upon arrival, your tour group discovers that they were awarded twice the miles they should have been because both KLM and Northwest airlines took the responsibility to award miles for the trip. Each individual airline claims it had the right to do that since they can define the area of responsibility any way they want. HTH, Alex. From owner-ietf-openproxy@mail.imc.org Tue Aug 19 12:19:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21037 for ; Tue, 19 Aug 2003 12:19:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p9CQ-0002yH-00 for opes-archive@ietf.org; Tue, 19 Aug 2003 12:19:10 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19p9CQ-0002yD-00 for opes-archive@ietf.org; Tue, 19 Aug 2003 12:19:10 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JG2qqt007597 for ; Tue, 19 Aug 2003 09:02:52 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7JG2qDB007595 for ietf-openproxy-bks; Tue, 19 Aug 2003 09:02:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from drakken.dbc.mtview.ca.us (adsl-64-168-10-254.dsl.scrm01.pacbell.net [64.168.10.254]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JG2pqt007589 for ; Tue, 19 Aug 2003 09:02:51 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from drakken.dbc.mtview.ca.us (localhost [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.9/8.12.9) with SMTP id h7JG2pTk000588; Tue, 19 Aug 2003 09:02:51 -0700 (PDT) Date: Tue, 19 Aug 2003 09:02:51 -0700 From: Marshall Rose Cc: Alex Rousskov , ietf-openproxy@imc.org Subject: Re: IAB considerations Message-Id: <20030819090251.0d5dede6.mrose@dbc.mtview.ca.us> In-Reply-To: <20030817104838.5bc3d1ff.mrose@dbc.mtview.ca.us> References: <5.2.0.9.0.20030816125612.00ab9300@mail.utel.net> <20030816071325.05f0451e.mrose@dbc.mtview.ca.us> <20030817104838.5bc3d1ff.mrose@dbc.mtview.ca.us> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > let's try this: edit the draft so that is complete and > self-consistent. to the extent it differs from what the IAB recommends, > make sure that the differences are explain and justified. then have a > friend take a pass through the document for clarity and conciseness. ok, so when are we going to have this submitted as an I-D? /mtr From owner-ietf-openproxy@mail.imc.org Tue Aug 19 12:35:33 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21962 for ; Tue, 19 Aug 2003 12:35:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p9SL-0003E2-00 for opes-archive@ietf.org; Tue, 19 Aug 2003 12:35:37 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19p9SK-0003Dz-00 for opes-archive@ietf.org; Tue, 19 Aug 2003 12:35:36 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JGLBqt009582 for ; Tue, 19 Aug 2003 09:21:11 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7JGLBRZ009581 for ietf-openproxy-bks; Tue, 19 Aug 2003 09:21:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JGL9qt009573 for ; Tue, 19 Aug 2003 09:21:09 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7JGKuMS052132; Tue, 19 Aug 2003 10:20:56 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7JGKunM052131; Tue, 19 Aug 2003 10:20:56 -0600 (MDT) (envelope-from rousskov) Date: Tue, 19 Aug 2003 10:20:56 -0600 (MDT) From: Alex Rousskov To: Marshall Rose cc: ietf-openproxy@imc.org Subject: Re: IAB considerations In-Reply-To: <20030819090251.0d5dede6.mrose@dbc.mtview.ca.us> Message-ID: References: <5.2.0.9.0.20030816125612.00ab9300@mail.utel.net> <20030816071325.05f0451e.mrose@dbc.mtview.ca.us> <20030817104838.5bc3d1ff.mrose@dbc.mtview.ca.us> <20030819090251.0d5dede6.mrose@dbc.mtview.ca.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 19 Aug 2003, Marshall Rose wrote: > > let's try this: edit the draft so that is complete and > > self-consistent. to the extent it differs from what the IAB recommends, > > make sure that the differences are explain and justified. then have a > > friend take a pass through the document for clarity and conciseness. > > ok, so when are we going to have this submitted as an I-D? I can commit to finish another update by the end of this week, hopefully sooner. We will probably need at least three working days for a WG-wide review and then a day or two to apply changes suggested by that review, assuming the WG decides to proceed with the draft as a WG draft. Does August 30 sound like a reasonable self-imposed submission deadline? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Tue Aug 19 13:13:14 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23891 for ; Tue, 19 Aug 2003 13:13:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pA2l-0003pb-00 for opes-archive@ietf.org; Tue, 19 Aug 2003 13:13:15 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19pA2k-0003pW-00 for opes-archive@ietf.org; Tue, 19 Aug 2003 13:13:15 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JGxrqt013331 for ; Tue, 19 Aug 2003 09:59:53 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7JGxraJ013330 for ietf-openproxy-bks; Tue, 19 Aug 2003 09:59:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from drakken.dbc.mtview.ca.us (adsl-64-168-10-254.dsl.scrm01.pacbell.net [64.168.10.254]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JGxqqt013325 for ; Tue, 19 Aug 2003 09:59:52 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from drakken.dbc.mtview.ca.us (localhost [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.9/8.12.9) with SMTP id h7JGxrTk000932; Tue, 19 Aug 2003 09:59:53 -0700 (PDT) Date: Tue, 19 Aug 2003 09:59:53 -0700 From: Marshall Rose To: Alex Rousskov Cc: ietf-openproxy@imc.org Subject: Re: IAB considerations Message-Id: <20030819095953.7854c73a.mrose@dbc.mtview.ca.us> In-Reply-To: References: <5.2.0.9.0.20030816125612.00ab9300@mail.utel.net> <20030816071325.05f0451e.mrose@dbc.mtview.ca.us> <20030817104838.5bc3d1ff.mrose@dbc.mtview.ca.us> <20030819090251.0d5dede6.mrose@dbc.mtview.ca.us> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > I can commit to finish another update by the end of this week, > hopefully sooner. We will probably need at least three working days > for a WG-wide review and then a day or two to apply changes suggested > by that review, assuming the WG decides to proceed with the draft as a > WG draft. > > Does August 30 sound like a reasonable self-imposed submission > deadline? i can't quite parse this. what you need to do is to submit an I-D you say "works" according to the criteria i gave you. at that point, the chairs decide what the timeline is for review, comments, and whether their is concensus, based on what the feedback is on the mailing list. in other words: submit the draft on friday morning, and we'll worry about the rest later. /mtr From owner-ietf-openproxy@mail.imc.org Tue Aug 19 13:41:47 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25505 for ; Tue, 19 Aug 2003 13:41:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pAUQ-0004Ik-00 for opes-archive@ietf.org; Tue, 19 Aug 2003 13:41:50 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19pAUP-0004Ig-00 for opes-archive@ietf.org; Tue, 19 Aug 2003 13:41:49 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JHTBqt014857 for ; Tue, 19 Aug 2003 10:29:11 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7JHTB9N014856 for ietf-openproxy-bks; Tue, 19 Aug 2003 10:29:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JHTAqt014851 for ; Tue, 19 Aug 2003 10:29:10 -0700 (PDT) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7JHTB9Y090942 for ; Tue, 19 Aug 2003 13:29:11 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7JHT52e042528 for ; Tue, 19 Aug 2003 13:29:05 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7JHT4FU009932 for ; Tue, 19 Aug 2003 13:29:04 -0400 (EDT) Message-ID: <3F425EB8.2060205@mhof.com> Date: Tue, 19 Aug 2003 13:30:32 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: draft-beck-opes-irml-03.txt References: <3EF8CADD.2060201@bell-labs.com> <3EF905A5.9000100@mhof.com> <3F0087EF.6020805@bell-labs.com> <3F3AF9D3.2000302@bell-labs.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > [...] > > I doubt the above differences can be resolved by a compromise. One > primary direction should be chosen by the working group. Am I the only > person disliking the general direction of irml-03? Folks, please post if you've an opinion on this matter, since we really need to decide what to do with the rules language, whether to adopt the IRML draft and keep working on it as WG draft, or whether someone is willing to commit writing an alternative approach. -Markus From owner-ietf-openproxy@mail.imc.org Tue Aug 19 17:02:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09092 for ; Tue, 19 Aug 2003 17:02:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pDcK-0000BW-00 for opes-archive@ietf.org; Tue, 19 Aug 2003 17:02:12 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19pDcJ-0000BS-00 for opes-archive@ietf.org; Tue, 19 Aug 2003 17:02:11 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JKk6qt025503 for ; Tue, 19 Aug 2003 13:46:06 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7JKk65d025502 for ietf-openproxy-bks; Tue, 19 Aug 2003 13:46:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JKk5qt025496 for ; Tue, 19 Aug 2003 13:46:05 -0700 (PDT) (envelope-from abeck@bell-labs.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7JKk7Ha071767; Tue, 19 Aug 2003 16:46:07 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7JKjx2e071091; Tue, 19 Aug 2003 16:45:59 -0400 (EDT) Received: from bell-labs.com (abeck-hopc [135.180.240.202]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7JKjwFU014651; Tue, 19 Aug 2003 16:45:58 -0400 (EDT) Message-ID: <3F428C1D.7010608@bell-labs.com> Date: Tue, 19 Aug 2003 16:44:13 -0400 From: Andre Beck User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Rousskov CC: OPES WG Subject: Re: processing points in draft-beck-opes-irml-03 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > Is the concept of a "processing point" application-agnostic? If it is > application-specific, it should be removed from the > application-agnostic spec (draft-beck-opes-irml-03). I think the concept of processing points is indeed application agnostic, even though each application protocol may have different processing points. This depends, for example, on whether or not an OPES processor can implement a cache for the application protocol and on the request/response scheme of the application protocol. > If we believe that every application protocol has some "processing > points", then the definition of HTTP-specific points should probably > be moved from draft-beck-opes-irml-03 to an HTTP binding for IRML. It > may also be more appropriate to migrate from numbers to tokens/strings > when describing application-specific points. Yes, I think application-specific processing points should be defined in the corresponding application protocol binding for IRML, but I still think that it makes sense to define a general mechanism of how to specify processing points in IRML rules in the IRML spec. Is this what you had in mind as well? -Andre From owner-ietf-openproxy@mail.imc.org Tue Aug 19 17:56:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10979 for ; Tue, 19 Aug 2003 17:56:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pEST-0000iK-00 for opes-archive@ietf.org; Tue, 19 Aug 2003 17:56:05 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19pESS-0000iH-00 for opes-archive@ietf.org; Tue, 19 Aug 2003 17:56:04 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JLfbqt028444 for ; Tue, 19 Aug 2003 14:41:37 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7JLfb1k028442 for ietf-openproxy-bks; Tue, 19 Aug 2003 14:41:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JLfaqt028426 for ; Tue, 19 Aug 2003 14:41:36 -0700 (PDT) (envelope-from abeck@bell-labs.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7JLfZ9Y095087; Tue, 19 Aug 2003 17:41:35 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7JLfTF2051273; Tue, 19 Aug 2003 17:41:29 -0400 (EDT) Received: from bell-labs.com (abeck-hopc [135.180.240.202]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7JLfSFU017331; Tue, 19 Aug 2003 17:41:28 -0400 (EDT) Message-ID: <3F42991F.7000703@bell-labs.com> Date: Tue, 19 Aug 2003 17:39:43 -0400 From: Andre Beck User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Rousskov CC: OPES WG Subject: Re: draft-beck-opes-irml-03.txt References: <3EF8CADD.2060201@bell-labs.com> <3EF905A5.9000100@mhof.com> <3F0087EF.6020805@bell-labs.com> <3F3AF9D3.2000302@bell-labs.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alex, > - You envision IRML to be used to describe very basic > rules, occasionally distributed to OPES processors > using off-band mechanisms. You want the language > itself to make it difficult to describe complex > manipulations. It was not an explicit design goal to make it difficult to describe complex manipulations, but rather this resulted from the fact that we didn't see a requirement/need to support complex manipulations and in particular didn't want to allow advanced flow control constructs such as loops etc. > IRML inspiration comes, in part, > from CPL which targets IP telephony needs. Correct. It's true that CPL targets IP telephony, but the requirements on CPL are surprisingly similar to those of OPES systems which is we decided to partly model IRML after CPL. For example, CPL is (signaling) protocol agnostic, is limited in power so that it can run safely in Internet (telephony) servers, defines rule conditions that match patterns against protocol header values etc. -Andre From owner-ietf-openproxy@mail.imc.org Tue Aug 19 18:37:30 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13548 for ; Tue, 19 Aug 2003 18:37:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pF6c-00015v-00 for opes-archive@ietf.org; Tue, 19 Aug 2003 18:37:34 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19pF6b-00015s-00 for opes-archive@ietf.org; Tue, 19 Aug 2003 18:37:33 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JMP1qt034152 for ; Tue, 19 Aug 2003 15:25:02 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7JMP1t0034151 for ietf-openproxy-bks; Tue, 19 Aug 2003 15:25:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7JMP0qt034140 for ; Tue, 19 Aug 2003 15:25:00 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7JMOxMS061965; Tue, 19 Aug 2003 16:24:59 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7JMOxP8061964; Tue, 19 Aug 2003 16:24:59 -0600 (MDT) (envelope-from rousskov) Date: Tue, 19 Aug 2003 16:24:59 -0600 (MDT) From: Alex Rousskov To: Andre Beck cc: OPES WG Subject: Re: processing points in draft-beck-opes-irml-03 In-Reply-To: <3F428C1D.7010608@bell-labs.com> Message-ID: References: <3F428C1D.7010608@bell-labs.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 19 Aug 2003, Andre Beck wrote: > Yes, I think application-specific processing points should be > defined in the corresponding application protocol binding for IRML, > but I still think that it makes sense to define a general mechanism > of how to specify processing points in IRML rules in the IRML spec. > Is this what you had in mind as well? Yes, kind of. It all depends on the overall language design. With the current design, we have to describe "processing point" as a general concept/attribute (without defining any application-specific values). This is because the current draft makes this particular attribute special compared to other "properties". You have already explained the motivation behind this design. An alternative is a an approach where "processing point" becomes just one of the application-specific properties and requires no special treatment or even documentation in the IRML Core. Application-specific interpreters or compilers would be free to treat/optimize this property specially, of course. Alex. From owner-ietf-openproxy@mail.imc.org Wed Aug 20 11:16:46 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13399 for ; Wed, 20 Aug 2003 11:16:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pUhf-0001pm-00 for opes-archive@ietf.org; Wed, 20 Aug 2003 11:16:51 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19pUhf-0001ph-00 for opes-archive@ietf.org; Wed, 20 Aug 2003 11:16:51 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KEvKqt019637 for ; Wed, 20 Aug 2003 07:57:20 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KEvKpZ019636 for ietf-openproxy-bks; Wed, 20 Aug 2003 07:57:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com ([209.124.80.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KEvJqt019631 for ; Wed, 20 Aug 2003 07:57:19 -0700 (PDT) (envelope-from info@utel.net) Received: from f02v-15-153.d0.club-internet.fr ([212.195.234.153] helo=jfc2.utel.net) by hosting.altserver.com with esmtp (Exim 4.20) id 19pUOh-0002os-Oa; Wed, 20 Aug 2003 07:57:17 -0700 Message-Id: <5.2.0.9.0.20030819213408.026af990@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 19 Aug 2003 21:44:34 +0200 To: Alex Rousskov From: jfcm Subject: RE: [end points comm] OPES System Cc: ietf-openproxy@imc.org In-Reply-To: References: <5.2.0.9.0.20030819005321.02a88230@mail.utel.net> <5.2.0.9.0.20030818231505.03a11bd0@mail.utel.net> <5.2.0.9.0.20030815021815.02abc2d0@mail.utel.net> <5.2.0.9.0.20030815005340.030df090@mail.utel.net> <200308141659.h7EGxTkZ003915@localhost.localdomain> <200308141659.h7EGxTkZ003915@localhost.localdomain> <5.2.0.9.0.20030815005340.030df090@mail.utel.net> <5.2.0.9.0.20030815021815.02abc2d0@mail.utel.net> <5.2.0.9.0.20030818231505.03a11bd0@mail.utel.net> <5.2.0.9.0.20030819005321.02a88230@mail.utel.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 16:43 19/08/03, Alex Rousskov said: >On Tue, 19 Aug 2003, jfcm wrote: > > At 23:41 18/08/03, Alex Rousskov wrote: > > > > > >That's fine, but you need a better definition of a domain and/or > > >operator. The original "OPES domain is the area of reponsibility of > > >an operator" does not imply the above explanation. > > > > > >Also, since you leave domain boundaries for the operator to decide, > > >you need to explain how conflicts (two operators think they are > > >responsible for the same domain and instruct their processors to > > >update the trace accordingly) and misses (no operator claims > > >responsibility for a domain/processor). > > > > I must go. But I think better anyway to proceed with a general > > response and see what you objet as I do not understand your > > question. So I suppose there is confusion to clarify. > > > > Let stick to the Airline image. And let take the following analogy > > (different of the one I took with Markus, but as good and clearer > > here). > > > > A jet = processor > > An airline = domain - area of responsibility of the ariline operator. > > An alliance (or a tour or a travel I organize, etc.) = a system > > > > Are all your questions answered or not? > > If not where are you difficulties coming from? > > The analogy or from not addressed conflicts? > >I can use the airline analogy to illustrate what is missing in your >definitions, though it may not be a perfect example: Usually a good one. Let take it as long as it does not fail us. >Lack of responsibility: here you confuse system and domain operator. 1. as a user you go and see the system. Since you chose the image of a tour operator, the ystem for the user is the group operator. Period. 2. as a tour operator. i.e. a system. Your problem is to find back the luggage. And believe me, from experience as an operator _every relevant infromation_ to do that is necessary. > Your tour group arrives at the destination > with their bags lost. They call you (the > "system" contact point) to complain. You tell > them that the bags are not your responsibility > and they should check with the last jet airline. Then they sue you and win. > They go to the last airline, Northwest Airlines. Nroth West will not speak to them. They do not even know them as passengers. They only know you as a tour, etc.... > Northwest tells them that the last leg on their > itinerary was operated by KLM and they have to > complain to KLM. KLM says that based on their > agreement with Northwest, Northwest is responsible > for the lost baggage. > > Thus, your group has contacted three suspects and all refused > to take responsibility. Since your definitions rely > on somebody to accept/define responsibility, it is not clear > who is at fault here. I nover said that. I said that it is to people to accept to be a domain operator for a CPU/jet. That is to have the responibility of a domain. I selfom saw a jet takingof without pilot. >Double responsibility: > > Upon arrival, your tour group discovers that they > were awarded twice the miles they should have been > because both KLM and Northwest airlines took the > responsibility to award miles for the trip. Who will complain :-) > Each > individual airline claims it had the right to do > that since they can define the area of responsibility any way > they want. You probably missed one point again in confusing reponsibility and domain of responsibility (strange that such an obvious notion to any operational person can be a problem to you.). No CPU - jet - can have two owners or no owner. Fact of the life. You may tell your neighbor that his wife is yours, but usually law prevents this not to be a bug. jfc From owner-ietf-openproxy@mail.imc.org Wed Aug 20 12:12:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17592 for ; Wed, 20 Aug 2003 12:12:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pVa1-00030y-00 for opes-archive@ietf.org; Wed, 20 Aug 2003 12:13:01 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19pVa0-00030v-00 for opes-archive@ietf.org; Wed, 20 Aug 2003 12:13:00 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KFmvqt022679 for ; Wed, 20 Aug 2003 08:48:57 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KFmvYK022678 for ietf-openproxy-bks; Wed, 20 Aug 2003 08:48:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KFmtqt022673 for ; Wed, 20 Aug 2003 08:48:56 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7KFmuMS087031; Wed, 20 Aug 2003 09:48:56 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7KFmuss087030; Wed, 20 Aug 2003 09:48:56 -0600 (MDT) (envelope-from rousskov) Date: Wed, 20 Aug 2003 09:48:56 -0600 (MDT) From: Alex Rousskov To: jfcm cc: ietf-openproxy@imc.org Subject: RE: [end points comm] OPES System In-Reply-To: <5.2.0.9.0.20030819213408.026af990@mail.utel.net> Message-ID: References: <5.2.0.9.0.20030819005321.02a88230@mail.utel.net> <5.2.0.9.0.20030818231505.03a11bd0@mail.utel.net> <5.2.0.9.0.20030815021815.02abc2d0@mail.utel.net> <5.2.0.9.0.20030815005340.030df090@mail.utel.net> <200308141659.h7EGxTkZ003915@localhost.localdomain> <200308141659.h7EGxTkZ003915@localhost.localdomain> <5.2.0.9.0.20030815005340.030df090@mail.utel.net> <5.2.0.9.0.20030815021815.02abc2d0@mail.utel.net> <5.2.0.9.0.20030818231505.03a11bd0@mail.utel.net> <5.2.0.9.0.20030819005321.02a88230@mail.utel.net> <5.2.0.9.0.20030819213408.026af990@mail.utel.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 19 Aug 2003, jfcm wrote: > You probably missed one point again in confusing reponsibility and > domain of responsibility (strange that such an obvious notion to any > operational person can be a problem to you.). No CPU - jet - can > have two owners or no owner. Fact of the life. You may tell your > neighbor that his wife is yours, but usually law prevents this not > to be a bug. jfc Things that are clear to most people in the real world become very fuzzy in the virtual reality that we are building and documenting here. Not to mention that I disagree with your assumption that ownership and domain of responsibility are always clear in real world. The "take them to court and win the case" answer is not satisfactory to me. I want the specs to be clear how the responsibility is assigned, traced, and managed. Alex. From owner-ietf-openproxy@mail.imc.org Wed Aug 20 12:41:24 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18669 for ; Wed, 20 Aug 2003 12:41:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pW1Z-0003Mr-00 for opes-archive@ietf.org; Wed, 20 Aug 2003 12:41:29 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19pW1Y-0003Mj-00 for opes-archive@ietf.org; Wed, 20 Aug 2003 12:41:29 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KGJWqt024369 for ; Wed, 20 Aug 2003 09:19:32 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KGJW6B024368 for ietf-openproxy-bks; Wed, 20 Aug 2003 09:19:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KGJVqt024363 for ; Wed, 20 Aug 2003 09:19:31 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7KGJWMS087790; Wed, 20 Aug 2003 10:19:32 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7KGJWNW087789; Wed, 20 Aug 2003 10:19:32 -0600 (MDT) (envelope-from rousskov) Date: Wed, 20 Aug 2003 10:19:32 -0600 (MDT) From: Alex Rousskov To: OPES WG cc: Lee Beaumont Subject: renaming original dataflow Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: OCP calls application data flowing from OPES processor to callout server "original". This term is used to describe both dataflow and related OCP commands. The flow in the opposite direction is called "adapted". Several people were unhappy with the word "original" to describe the concept. Lee Beaumont, an independent consultant reviewing OCP draft, suggested a few alternatives: source, pristine, maiden, virgin, primal, prime, primary, prior, raw, initial, master, prototype, starting From the above list, I like "virgin" the most. Any other opinions? Does anybody think that "virgin dataflow" is better than current "original dataflow"? Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Wed Aug 20 15:40:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04904 for ; Wed, 20 Aug 2003 15:40:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pYpI-0006W9-00 for opes-archive@ietf.org; Wed, 20 Aug 2003 15:41:00 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19pYpH-0006W1-00 for opes-archive@ietf.org; Wed, 20 Aug 2003 15:40:59 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KJQgqt033609 for ; Wed, 20 Aug 2003 12:26:42 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KJQguX033608 for ietf-openproxy-bks; Wed, 20 Aug 2003 12:26:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com ([209.124.80.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KJQfqt033603 for ; Wed, 20 Aug 2003 12:26:41 -0700 (PDT) (envelope-from info@utel.net) Received: from f02v-15-153.d0.club-internet.fr ([212.195.234.153] helo=jfc2.utel.net) by hosting.altserver.com with esmtp (Exim 4.20) id 19pYbQ-0007KX-6A; Wed, 20 Aug 2003 12:26:41 -0700 Message-Id: <5.2.0.9.0.20030820211053.0435ad20@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 20 Aug 2003 21:18:20 +0200 To: Alex Rousskov , OPES WG From: jfcm Subject: Re: renaming original dataflow Cc: Lee Beaumont In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id h7KJQgqt033609 Content-Transfer-Encoding: quoted-printable At 18:19 20/08/03, Alex Rousskov wrote: >OCP calls application data flowing from OPES processor to callout >server "original". This term is used to describe both dataflow and >related OCP commands. The flow in the opposite direction is called >"adapted". > >Several people were unhappy with the word "original" to describe the >concept. Lee Beaumont, an independent consultant reviewing OCP draft, >suggested a few alternatives: > > source, pristine, maiden, virgin, > primal, prime, primary, prior, > raw, initial, master, prototype, starting "initial" seems the more internationaly sound. And the nearest of "original" which is probably better (at least for Fren= ch=20 speakers) I doubt "virigin" belongs to Basic English? Also the word is to mean "the initial data in this OPES system", but not=20 necessarily in other systems (OPES or not) so raw, master, prototype,=20 source are probably inadequate? Another problem are "virgin data" still virgin after having crossed an OP= ES=20 system and stayed unaltered? Many people will ask because not n=E9cessari= ly=20 obvious? > >From the above list, I like "virgin" the most. Any other opinions? >Does anybody think that "virgin dataflow" is better than current >"original dataflow"? > >Thank you, > >Alex. > > > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.507 / Virus Database: 304 - Release Date: 04/08/03 From owner-ietf-openproxy@mail.imc.org Wed Aug 20 15:42:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05311 for ; Wed, 20 Aug 2003 15:42:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pYqM-0006aR-00 for opes-archive@ietf.org; Wed, 20 Aug 2003 15:42:06 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19pYqL-0006aB-00 for opes-archive@ietf.org; Wed, 20 Aug 2003 15:42:05 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KJTYqt033673 for ; Wed, 20 Aug 2003 12:29:34 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KJTYCq033672 for ietf-openproxy-bks; Wed, 20 Aug 2003 12:29:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com ([209.124.80.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KJTXqt033667 for ; Wed, 20 Aug 2003 12:29:33 -0700 (PDT) (envelope-from info@utel.net) Received: from f02v-15-153.d0.club-internet.fr ([212.195.234.153] helo=jfc2.utel.net) by hosting.altserver.com with esmtp (Exim 4.20) id 19pYeB-0007ff-5i; Wed, 20 Aug 2003 12:29:31 -0700 Message-Id: <5.2.0.9.0.20030820190945.039ece70@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 20 Aug 2003 21:38:42 +0200 To: Alex Rousskov From: jfcm Subject: RE: [end points comm] OPES System Cc: ietf-openproxy@imc.org In-Reply-To: References: <5.2.0.9.0.20030819213408.026af990@mail.utel.net> <5.2.0.9.0.20030819005321.02a88230@mail.utel.net> <5.2.0.9.0.20030818231505.03a11bd0@mail.utel.net> <5.2.0.9.0.20030815021815.02abc2d0@mail.utel.net> <5.2.0.9.0.20030815005340.030df090@mail.utel.net> <200308141659.h7EGxTkZ003915@localhost.localdomain> <200308141659.h7EGxTkZ003915@localhost.localdomain> <5.2.0.9.0.20030815005340.030df090@mail.utel.net> <5.2.0.9.0.20030815021815.02abc2d0@mail.utel.net> <5.2.0.9.0.20030818231505.03a11bd0@mail.utel.net> <5.2.0.9.0.20030819005321.02a88230@mail.utel.net> <5.2.0.9.0.20030819213408.026af990@mail.utel.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 17:48 20/08/03, Alex Rousskov wrote: >On Tue, 19 Aug 2003, jfcm wrote: >Things that are clear to most people in the real world become very fuzzy >in the virtual reality that we are building and documenting here. Not to >mention that I disagree with your assumption that >ownership and domain of responsibility are always clear in real world. Sorry, these are comments. Not real logical facts. We have a hierarchical identification: - top is system - below is domain - below is server - below is service - below or aside is the traveler You may certainly imagine identification plan/protocol violations. But please come document them. In the model we chose (airtransport) as seen from the users (not from a single user _and_ from a tour operator): - the system (alliance, tour, travel) is identfied by the Warsaw conventions and the issuer of the ticket - the domain (airline) is idenfied by its international code - the server (plane) is international identified by its indicative and IFF or eventually destroyed (what you expect from an hacker) - the stewart, the offered bottle, the milleage plan, the luggages, the passengers, are idenified and traced in many ways, sometimes there are confusions but that works usually well because protocols are pretty clear. OK I accept that when we started I asked if OPES were ONES or not and I gave air reservation and SITA attached systems as a ONES example. Or Swift related systems. So I am ready to accept that OPES do not qualify to support that type of need, if you say so. But I do not see why. jfc >The "take them to court and win the case" answer is not satisfactory >to me. I want the specs to be clear how the responsibility is >assigned, traced, and managed. This was not a response to a technical problem. Only a comment on the way the question was meaningless because you confused two layers. You cannot demand a protocol to respond a question it is not to be asked. From owner-ietf-openproxy@mail.imc.org Wed Aug 20 16:10:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07441 for ; Wed, 20 Aug 2003 16:10:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pZIH-00076Q-00 for opes-archive@ietf.org; Wed, 20 Aug 2003 16:10:57 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19pZIG-00076M-00 for opes-archive@ietf.org; Wed, 20 Aug 2003 16:10:56 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KJvBqt034761 for ; Wed, 20 Aug 2003 12:57:11 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KJvAUC034760 for ietf-openproxy-bks; Wed, 20 Aug 2003 12:57:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KJv9qt034755 for ; Wed, 20 Aug 2003 12:57:09 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7KJvBMS094334; Wed, 20 Aug 2003 13:57:11 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7KJvBmU094333; Wed, 20 Aug 2003 13:57:11 -0600 (MDT) (envelope-from rousskov) Date: Wed, 20 Aug 2003 13:57:11 -0600 (MDT) From: Alex Rousskov To: OPES WG cc: Lee Beaumont Subject: Re: renaming original dataflow In-Reply-To: <5.2.0.9.0.20030820211053.0435ad20@mail.utel.net> Message-ID: References: <5.2.0.9.0.20030820211053.0435ad20@mail.utel.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by above.proper.com id h7KJv9qt034756 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id h7KJvBqt034761 Content-Transfer-Encoding: quoted-printable On Wed, 20 Aug 2003, jfcm wrote: > Another problem are "virgin data" still virgin after having crossed > an OPES system and stayed unaltered? Many people will ask because > not n=E9cessarily obvious? By OCP definition, any data that was processed (seen/touched) by a callout server is "adapted", regardless of whether data bytes remained unchanged. The idea is that just seeing (hence, possibly copying or exporting) the data is sufficiently important to be traced/etc. In other words, in OCP context, seeing data is as important as modifying data. Whatever word we choose, the problem you mention will persist, I guess. The only solution may be to go back to "input/output" terminology which I think we already rejected for other reasons. Alex. From owner-ietf-openproxy@mail.imc.org Wed Aug 20 16:15:14 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07666 for ; Wed, 20 Aug 2003 16:15:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pZMU-00079K-00 for opes-archive@ietf.org; Wed, 20 Aug 2003 16:15:18 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19pZMT-00079H-00 for opes-archive@ietf.org; Wed, 20 Aug 2003 16:15:18 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KK0oqt034841 for ; Wed, 20 Aug 2003 13:00:51 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KK0ou4034840 for ietf-openproxy-bks; Wed, 20 Aug 2003 13:00:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KK0nqt034835 for ; Wed, 20 Aug 2003 13:00:49 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7KK0pMS094354; Wed, 20 Aug 2003 14:00:51 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7KK0pU3094353; Wed, 20 Aug 2003 14:00:51 -0600 (MDT) (envelope-from rousskov) Date: Wed, 20 Aug 2003 14:00:51 -0600 (MDT) From: Alex Rousskov To: jfcm cc: OPES WG Subject: RE: [end points comm] OPES System In-Reply-To: <5.2.0.9.0.20030820190945.039ece70@mail.utel.net> Message-ID: References: <5.2.0.9.0.20030819213408.026af990@mail.utel.net> <5.2.0.9.0.20030819005321.02a88230@mail.utel.net> <5.2.0.9.0.20030818231505.03a11bd0@mail.utel.net> <5.2.0.9.0.20030815021815.02abc2d0@mail.utel.net> <5.2.0.9.0.20030815005340.030df090@mail.utel.net> <200308141659.h7EGxTkZ003915@localhost.localdomain> <200308141659.h7EGxTkZ003915@localhost.localdomain> <5.2.0.9.0.20030815005340.030df090@mail.utel.net> <5.2.0.9.0.20030815021815.02abc2d0@mail.utel.net> <5.2.0.9.0.20030818231505.03a11bd0@mail.utel.net> <5.2.0.9.0.20030819005321.02a88230@mail.utel.net> <5.2.0.9.0.20030819213408.026af990@mail.utel.net> <5.2.0.9.0.20030820190945.039ece70@mail.utel.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 20 Aug 2003, jfcm wrote: > - the system (alliance, tour, travel) is identfied by the Warsaw > conventions and the issuer of the ticket Exactly. What we need is an equivalent of Warsaw Convention. That is what is missing in your definition. "Accepting/taking the responsibility" is not sufficient. There has to be some rules about it (to avoid duplication or lack of responsibility). Alex. From owner-ietf-openproxy@mail.imc.org Wed Aug 20 17:30:30 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12341 for ; Wed, 20 Aug 2003 17:30:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19paXL-0000Qs-00 for opes-archive@ietf.org; Wed, 20 Aug 2003 17:30:35 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19paXK-0000Qo-00 for opes-archive@ietf.org; Wed, 20 Aug 2003 17:30:34 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLFTqt045041 for ; Wed, 20 Aug 2003 14:15:29 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KLFTYp045040 for ietf-openproxy-bks; Wed, 20 Aug 2003 14:15:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com ([209.124.80.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLFSqt044551 for ; Wed, 20 Aug 2003 14:15:28 -0700 (PDT) (envelope-from info@utel.net) Received: from f02v-15-153.d0.club-internet.fr ([212.195.234.153] helo=jfc2.utel.net) by hosting.altserver.com with esmtp (Exim 4.20) id 19paHT-0004I4-3y; Wed, 20 Aug 2003 14:14:13 -0700 Message-Id: <5.2.0.9.0.20030820224858.03a6e6a0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 20 Aug 2003 23:02:07 +0200 To: Alex Rousskov From: jfcm Subject: RE: [end points comm] OPES System Cc: OPES WG In-Reply-To: References: <5.2.0.9.0.20030820190945.039ece70@mail.utel.net> <5.2.0.9.0.20030819213408.026af990@mail.utel.net> <5.2.0.9.0.20030819005321.02a88230@mail.utel.net> <5.2.0.9.0.20030818231505.03a11bd0@mail.utel.net> <5.2.0.9.0.20030815021815.02abc2d0@mail.utel.net> <5.2.0.9.0.20030815005340.030df090@mail.utel.net> <200308141659.h7EGxTkZ003915@localhost.localdomain> <200308141659.h7EGxTkZ003915@localhost.localdomain> <5.2.0.9.0.20030815005340.030df090@mail.utel.net> <5.2.0.9.0.20030815021815.02abc2d0@mail.utel.net> <5.2.0.9.0.20030818231505.03a11bd0@mail.utel.net> <5.2.0.9.0.20030819005321.02a88230@mail.utel.net> <5.2.0.9.0.20030819213408.026af990@mail.utel.net> <5.2.0.9.0.20030820190945.039ece70@mail.utel.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 22:00 20/08/03, Alex Rousskov wrote: >On Wed, 20 Aug 2003, jfcm wrote: > > - the system (alliance, tour, travel) is identfied by the Warsaw > > conventions and the issuer of the ticket > >Exactly. What we need is an equivalent of Warsaw Convention. That is >what is missing in your definition. "Accepting/taking the >responsibility" is not sufficient. There has to be some rules about it >(to avoid duplication or lack of responsibility). Alex please consider what I/we said. The system is by essence what the user, the provider or a third party as decided as a global service. This is what in the Airline analogy we call the travel (user), the alliance (Air France with Delta, with NorthWest, etc against BA alliance etc.) The domain is the airline. It is made by a company accepting/taking responsbility to buy airplanes, to hire pilots, etc. No one else will setup any rule on the free decision of the investors, entrepreneurs, etc. Like it or not. And no other rule than the decision of the customers will say if they want or not to fly American Airways. I do not understand your problem. There cannot be lack of responsibilty - unless you the OCP designer wants it, but the TSA will not permit it. This means that you want to accept unknown planes, without pilots. As indicated there is a clear indentifcation hierarchy system, domain, server/service which permits everyone to determine classes of users and permitted access groups of domains (my first mails on this list) so one can deal with prefered, accepted, obliged services, security, laws, commercial policies, real life operations. etc. I really am at pain understanding your problem. And at understanding hos you cannot understand operators and users needs. Or please give examples. Or am I dumb stupid ? jfc From owner-ietf-openproxy@mail.imc.org Wed Aug 20 17:41:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12894 for ; Wed, 20 Aug 2003 17:41:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19paiP-0000aD-00 for opes-archive@ietf.org; Wed, 20 Aug 2003 17:42:01 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19paiO-0000a2-00 for opes-archive@ietf.org; Wed, 20 Aug 2003 17:42:00 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLFaqt045077 for ; Wed, 20 Aug 2003 14:15:36 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KLFaP7045076 for ietf-openproxy-bks; Wed, 20 Aug 2003 14:15:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from hosting.altserver.com ([209.124.80.2]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLFZqt044593 for ; Wed, 20 Aug 2003 14:15:35 -0700 (PDT) (envelope-from info@utel.net) Received: from f02v-15-153.d0.club-internet.fr ([212.195.234.153] helo=jfc2.utel.net) by hosting.altserver.com with esmtp (Exim 4.20) id 19paHb-0004I4-Jb; Wed, 20 Aug 2003 14:14:20 -0700 Message-Id: <5.2.0.9.0.20030820230213.043eaea0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 20 Aug 2003 23:10:25 +0200 To: Alex Rousskov , OPES WG From: jfcm Subject: Re: renaming original dataflow Cc: Lee Beaumont In-Reply-To: References: <5.2.0.9.0.20030820211053.0435ad20@mail.utel.net> <5.2.0.9.0.20030820211053.0435ad20@mail.utel.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id h7KLFaqt045077 Content-Transfer-Encoding: quoted-printable At 21:57 20/08/03, Alex Rousskov wrote: >On Wed, 20 Aug 2003, jfcm wrote: > > > Another problem are "virgin data" still virgin after having crossed > > an OPES system and stayed unaltered? Many people will ask because > > not n=E9cessarily obvious? > >By OCP definition, any data that was processed (seen/touched) by a >callout server is "adapted", regardless of whether data bytes remained >unchanged. The idea is that just seeing (hence, possibly copying or >exporting) the data is sufficiently important to be traced/etc. In >other words, in OCP context, seeing data is as important as modifying >data. You are right. The point is only is this. Are the two sentences intuitively clear for every one. "The virgin data adaptation left them unchanged" "The original data adaptation left them unchanged". The first one is not clear to me as "virigin" intuitively means that nothing happened even leaving it unchanged. Example: the "touch" command does not affect a file. But a "touched" file for me is no more virgin. Just semantic. But simplifies the thing when the words intuitively translate well. jfc From owner-ietf-openproxy@mail.imc.org Wed Aug 20 18:07:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14784 for ; Wed, 20 Aug 2003 18:07:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pb6q-0000uR-00 for opes-archive@ietf.org; Wed, 20 Aug 2003 18:07:16 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19pb6p-0000uO-00 for opes-archive@ietf.org; Wed, 20 Aug 2003 18:07:15 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLrtqt058460 for ; Wed, 20 Aug 2003 14:53:55 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7KLrt1q058459 for ietf-openproxy-bks; Wed, 20 Aug 2003 14:53:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7KLrsqt058438 for ; Wed, 20 Aug 2003 14:53:54 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7KLruMS097161; Wed, 20 Aug 2003 15:53:56 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.5/Submit) id h7KLruIg097160; Wed, 20 Aug 2003 15:53:56 -0600 (MDT) (envelope-from rousskov) Date: Wed, 20 Aug 2003 15:53:56 -0600 (MDT) From: Alex Rousskov To: OPES WG cc: Lee Beaumont Subject: Re: renaming original dataflow In-Reply-To: <5.2.0.9.0.20030820230213.043eaea0@mail.utel.net> Message-ID: References: <5.2.0.9.0.20030820211053.0435ad20@mail.utel.net> <5.2.0.9.0.20030820211053.0435ad20@mail.utel.net> <5.2.0.9.0.20030820230213.043eaea0@mail.utel.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 20 Aug 2003, jfcm wrote: > The point is only is this. Are the two sentences intuitively clear > for every one. > > "The virgin data adaptation left them unchanged" > "The original data adaptation left them unchanged". > > The first one is not clear to me as "virigin" intuitively means > that nothing happened even leaving it unchanged. Both sentences are very confusing (grammatically, IMHO). A better version might be: "Adaptation of virgin data resulted in no changes to the data" "Adaptation of original resulted in no changes to the data" Both make sense and are clear enough to me. The problem comes when we say "Adapted data was not changed by the callout server" "Adapted data and original data are identical" Some would question: What was "adapted" then? Alex. From owner-ietf-openproxy@mail.imc.org Fri Aug 22 15:12:30 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14591 for ; Fri, 22 Aug 2003 15:12:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qHJx-0000iN-00 for opes-archive@ietf.org; Fri, 22 Aug 2003 15:11:37 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19qHJm-0000iH-00 for opes-archive@ietf.org; Fri, 22 Aug 2003 15:11:26 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MItHqt052980 for ; Fri, 22 Aug 2003 11:55:19 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MItH3c052978 for ietf-openproxy-bks; Fri, 22 Aug 2003 11:55:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from drakken.dbc.mtview.ca.us (adsl-64-168-10-254.dsl.scrm01.pacbell.net [64.168.10.254]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MItGqt052973 for ; Fri, 22 Aug 2003 11:55:16 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from drakken.dbc.mtview.ca.us (localhost [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.9/8.12.9) with SMTP id h7MItGWY000943; Fri, 22 Aug 2003 11:55:16 -0700 (PDT) Date: Fri, 22 Aug 2003 11:55:16 -0700 From: Marshall Rose To: ietf-openproxy@imc.org Subject: moving along on rules language Message-Id: <20030822115516.4abe1229.mrose@dbc.mtview.ca.us> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit [ speaking as co-chair...] the milestones require that we have a rules language draft this month. thus far, there's been only one candidate (that has seen a fair amount of feedback during pre-WG times, but only very narrow feedback recently). we need to decide whether we want to finish opes. if not, let's disband now, and i can go back to managing some other disasters. otherwise, then unless someone can produce a credible alternative pdq, we should start with the beck irml document, finish it, and then decide whether there's a concensus (just like we're doing with the document alex is working on). any objections? /mtr From owner-ietf-openproxy@mail.imc.org Fri Aug 22 15:40:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16013 for ; Fri, 22 Aug 2003 15:40:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qHmM-00010T-00 for opes-archive@ietf.org; Fri, 22 Aug 2003 15:40:58 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19qHmL-00010P-00 for opes-archive@ietf.org; Fri, 22 Aug 2003 15:40:57 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MJR8qt054501 for ; Fri, 22 Aug 2003 12:27:08 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7MJR8xR054500 for ietf-openproxy-bks; Fri, 22 Aug 2003 12:27:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7MJR7qt054493 for ; Fri, 22 Aug 2003 12:27:07 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7MJR2ld065303; Fri, 22 Aug 2003 13:27:02 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h7MJR2UA065302; Fri, 22 Aug 2003 13:27:02 -0600 (MDT) (envelope-from rousskov) Date: Fri, 22 Aug 2003 13:27:02 -0600 (MDT) From: Alex Rousskov To: Marshall Rose cc: ietf-openproxy@imc.org Subject: Re: moving along on rules language In-Reply-To: <20030822115516.4abe1229.mrose@dbc.mtview.ca.us> Message-ID: References: <20030822115516.4abe1229.mrose@dbc.mtview.ca.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 22 Aug 2003, Marshall Rose wrote: > otherwise, then unless someone can produce a credible alternative pdq, Could you please briefly define/describe rough credibility criteria? For example, does the alternative need to come as an ID comparable to irml-03 in size? Does the alternative have to cover HTTP and other application-specific things that irml-03 covers (though there may already be consensus that those things do not belong to IRML Core)? I can come up with an alternative that a reasonable technical person would understand and can extrapolate, but I need to know the minimum requirements better so that I do not waste time on something that cannot be accepted as a viable alternative in the nearest future. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Fri Aug 22 17:22:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21254 for ; Fri, 22 Aug 2003 17:22:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qJMG-0002ET-00 for opes-archive@ietf.org; Fri, 22 Aug 2003 17:22:08 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19qJMF-0002EQ-00 for opes-archive@ietf.org; Fri, 22 Aug 2003 17:22:08 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ML8Uqt057812 for ; Fri, 22 Aug 2003 14:08:30 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7ML8U29057811 for ietf-openproxy-bks; Fri, 22 Aug 2003 14:08:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from drakken.dbc.mtview.ca.us (adsl-64-168-10-254.dsl.scrm01.pacbell.net [64.168.10.254]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7ML8Rqt057805 for ; Fri, 22 Aug 2003 14:08:29 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from drakken.dbc.mtview.ca.us (localhost [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.9/8.12.9) with SMTP id h7ML8SWY001321; Fri, 22 Aug 2003 14:08:28 -0700 (PDT) Date: Fri, 22 Aug 2003 14:08:28 -0700 From: Marshall Rose To: Alex Rousskov Cc: ietf-openproxy@imc.org Subject: Re: moving along on rules language Message-Id: <20030822140828.168c71e3.mrose@dbc.mtview.ca.us> In-Reply-To: References: <20030822115516.4abe1229.mrose@dbc.mtview.ca.us> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > Could you please briefly define/describe rough credibility criteria? sure. > For example, does the alternative need to come as an ID comparable to > irml-03 in size? no. beck-irml-03 is pretty much fleshed-out, so i'd expect an alternative to be copmlete enough for someone to understand what's going on, without having all the detail filled-in. > Does the alternative have to cover HTTP and other > application-specific things that irml-03 covers (though there may > already be consensus that those things do not belong to IRML Core)? the charter says HTTP is a MUST, others aren't. so the alternative, at a minimum, MUST deal with with HTTP > I can come up with an alternative that a reasonable technical person > would understand and can extrapolate, but I need to know the minimum > requirements better so that I do not waste time on something that > cannot be accepted as a viable alternative in the nearest future. great. if your confident with an alternative approach, put an initial document together and submit it. i don't want to forestall alternatives, but we need to be wrapping things up. (we also need that other document you were working on.) at some point the iesg is going to ask what we've done for them *lately*, and right now, markus and i don't have much of a response. thanks! /mtr From owner-ietf-openproxy@mail.imc.org Mon Aug 25 00:56:34 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12151 for ; Mon, 25 Aug 2003 00:56:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19r9PD-0001bw-00 for opes-archive@ietf.org; Mon, 25 Aug 2003 00:56:39 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19r9PD-0001bs-00 for opes-archive@ietf.org; Mon, 25 Aug 2003 00:56:39 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7P4dnqt074446 for ; Sun, 24 Aug 2003 21:39:49 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7P4dnEQ074445 for ietf-openproxy-bks; Sun, 24 Aug 2003 21:39:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7P4dmqt074440 for ; Sun, 24 Aug 2003 21:39:48 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7P4dpld048291 for ; Sun, 24 Aug 2003 22:39:51 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h7P4deHZ048290; Sun, 24 Aug 2003 22:39:40 -0600 (MDT) (envelope-from rousskov) Date: Sun, 24 Aug 2003 22:39:40 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: OCP Core version head_sid14 available Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a minor release. The log of major changes is quoted below. The latest snapshot is at http://www.measurement-factory.com/tmp/opes/ Please continue to comment and work on the to-do list. Thank you, Alex. -------------- change log ---------------- Appendix B. Change Log * Documented known resource-exhaustion security risks. * Polished compliance definition. Avoid two levels of compliance. From owner-ietf-openproxy@mail.imc.org Mon Aug 25 01:05:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12572 for ; Mon, 25 Aug 2003 01:05:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19r9XM-0001i9-00 for opes-archive@ietf.org; Mon, 25 Aug 2003 01:05:04 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19r9XL-0001i6-00 for opes-archive@ietf.org; Mon, 25 Aug 2003 01:05:03 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7P4pnqt074735 for ; Sun, 24 Aug 2003 21:51:49 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7P4pnY7074734 for ietf-openproxy-bks; Sun, 24 Aug 2003 21:51:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7P4pmqt074729 for ; Sun, 24 Aug 2003 21:51:48 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7P4ppld048627 for ; Sun, 24 Aug 2003 22:51:51 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h7P4ppkR048626; Sun, 24 Aug 2003 22:51:51 -0600 (MDT) (envelope-from rousskov) Date: Sun, 24 Aug 2003 22:51:51 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: IAB Treatment version head_sid14 available Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Here is a revision of the "IAB Treatment" draft, as promissed. I have added a couple of examples as requested by Markus. I may also found a way to reduce the level contravercy related to the IP Addressing consideration. I hope this major change and other minor edits will help address some of the Hilarie concerns, but I am sure more work will be needed as we get more specific feedback. While the current draft is sufficiently self-consistent IMO, there is a lot of work still needed in other drafts to make "IAB treatment" references valid. It would be nice to get a nod from IAB/IESG regarding our current direction (based on the "IAB treatment" draft) before we spent time documenting specific details (e.g., OPES-Via header format for HTTP). We need to get WG consensus first, of course. The log of major changes is quoted below. The latest snapshot, including XML sources for those doing hands-on modifications, is available at http://www.measurement-factory.com/tmp/opes/ Please comment. Thank you, Alex. -------------- change log ---------------- head-sid14 * Rewrote the Introduction to the IP addressing consideration. Do NOT explain how IAB considerations, if interpreted literary, do not satisfy important real-world constraints. Instead, use the "chain of OPES intermediaries" exception introduced by IAB itself to show that OPES architecture addresses IAB concerns as long as the "chain" is defined/formed for a given application message rather than being a statically configured application routing table of sorts. IAB had to add the "chain" exception to cover one of the most obvious real-world usage scenario. We use the very same exception to cover all usage scenarios we care about. * Polished text explaining the differences between tracing and notification mechanisms. * Added examples of OPES/HTTP traces. * Be careful not to imply that all OPES intermediaries must obey bypass instructions. Bypass should be ignored when no non-OPES version of the content exists. Ideally, this may need to be polished further -- if there is no non-OPES version of the content, most IAB considerations probably do not apply because there is really no adaptation, only creation of content (and we should not restrict content creation). * Added references to OPES "Communications" draft [I-D.ietf-opes-end-comm]. From owner-ietf-openproxy@mail.imc.org Mon Aug 25 08:37:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13451 for ; Mon, 25 Aug 2003 08:37:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rGbe-0000HY-00 for opes-archive@ietf.org; Mon, 25 Aug 2003 08:37:58 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19rGbe-0000HV-00 for opes-archive@ietf.org; Mon, 25 Aug 2003 08:37:58 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7PCLCqt031865 for ; Mon, 25 Aug 2003 05:21:12 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7PCLCXZ031864 for ietf-openproxy-bks; Mon, 25 Aug 2003 05:21:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7PCLAqt031827 for ; Mon, 25 Aug 2003 05:21:10 -0700 (PDT) (envelope-from karel.mittig@rd.francetelecom.com) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 25 Aug 2003 14:20:49 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: draft-ietf-opes-ocp-core Date: Mon, 25 Aug 2003 14:20:48 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB0260A6433@ftrdmel2.rd.francetelecom.fr> Thread-Topic: draft-ietf-opes-ocp-core Thread-Index: AcNovDL2yLsPLVdDTWiFFJSKQquHUgCIjtIQAAOZnRA= From: "MITTIG Karel FTRD/DMI/CAE" To: , X-OriginalArrivalTime: 25 Aug 2003 12:20:49.0711 (UTC) FILETIME=[51BFE3F0:01C36B03] X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7PCLBqt031860 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id h7PCLCqt031865 Content-Transfer-Encoding: quoted-printable Hello, I'm actually working on a generic OCP implementation for a later adaptati= on to DNS services. In this context, I have several comments on actual dr= aft, which I hope will help you to clarify or modify it: DUM=3D>'as-is' -------------- "as-is" includes an "am-id" parameter. What is the range of this am-id: A= M session or Transaction ? If it's only available in current AM session, = why using it when it's already present in DUM anonymous parameters ? DUM=3D>'ack' -------------- DUM 'ack' can be send by both processor and callout server, but DACK mess= ages can only be send by callout server. Draft modification needed to mak= e DACK sendable by both ? DH: -------------- First draft version was including DH message, which has been removed in t= he last version (replaced by ack flag in DUM message as I understand). Ho= wever, several parts of the draft still refer to DH: -DACK -Adapted dataflow definition -Message Examples =09 DACK -------------- DACK description speak about a "please-ack" parameter which is not define= d anywhere else. Also, the aim of "wont-forward" parameter is not clear t= o me. If it's only used to terminate preservation commitment, why not re-= using the "wont-use" parameter ? PONG/PING -------------- rid named parameter =3D> obsolete ? Name of [xid[am-id]] named parameter is not defined NO/NR -------------- ocp core draft defines anonymous parameters as a list of features(=A78.13= ), while HTTP adaptation uses a list of services(=A78.4) instead. Which o= ne is right ? :-) In NR, named parameters "Rejects" (which is normally indicated by omittin= g the "feature" parameter) & "Unknowns" are not defined. FLAGS -------------- "flag" named-parameters (error, ack & wont-forward) type is not clear. No= rmally, it should be boolean ("0"/"1", correct ?) but this is not explici= tly defined. Data syntax -------------- Result parameter is defined like for example {200 "2:OK"}. However, Marti= n presents on his OCP sample a {200 OK} result. Is it an error or are bot= h solutions possible ? If true, it will need useless syntax checks, intro= duce possible errors in implementation and should be avoid (in my opinion= ).=20 Named parameters use indifferently lowercase or uppercase ("Kept", "modp"= ,"Error", "sizep"). Knowing that the protocol is case-sensitive, it would= be clearer to use the same nomenclature for all parameters (everything i= n lowercase for example). Last point is about processor management of server "adapted" data, using = processing points defined in "draft-beck-opes-irml" (adding maybe 2 more = points corresponding to processor core treatments between 1->2 and 3->4). My idea is to add an optional parameter in DUM message (something like [n= ext-processing-point: value]). Receiving this parameter, processor SHOULD= transmit adapted message to given processing point. This will allow for example a filtering service to tell the processor (a = proxy in this case) to directly answer to a client with a denied message = (with or without allowing processor to cache the answer), or another serv= ice to tell the processor (server or proxy in this case) to get another c= ontent instead of the one provided in the answer, etc. Regards, Karel [France Telecom R&D ] From owner-ietf-openproxy@mail.imc.org Mon Aug 25 10:50:18 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22105 for ; Mon, 25 Aug 2003 10:50:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rIfm-00028i-00 for opes-archive@ietf.org; Mon, 25 Aug 2003 10:50:23 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19rIfm-00028d-00 for opes-archive@ietf.org; Mon, 25 Aug 2003 10:50:22 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7PEXYqt043985 for ; Mon, 25 Aug 2003 07:33:35 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7PEXYag043984 for ietf-openproxy-bks; Mon, 25 Aug 2003 07:33:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7PEXVqt043974 for ; Mon, 25 Aug 2003 07:33:33 -0700 (PDT) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7PEXV9Y079685 for ; Mon, 25 Aug 2003 10:33:32 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7PEXPF2053795 for ; Mon, 25 Aug 2003 10:33:25 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7PEXOFU017387 for ; Mon, 25 Aug 2003 10:33:24 -0400 (EDT) Message-ID: <3F4A1E8E.6090607@mhof.com> Date: Mon, 25 Aug 2003 10:34:54 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: IAB Treatment version head_sid14 available References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > While the current draft is sufficiently self-consistent IMO, there is > a lot of work still needed in other drafts to make "IAB treatment" > references valid. It would be nice to get a nod from IAB/IESG > regarding our current direction (based on the "IAB treatment" draft) > before we spent time documenting specific details (e.g., OPES-Via > header format for HTTP). We need to get WG consensus first, of course. Folks - plase provide comments on this new version of the draft by Thursday, 8/28. We would then try to get feedback from IAB/IESG on the direction of the draft. Thanks, Markus From owner-ietf-openproxy@mail.imc.org Mon Aug 25 12:13:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26124 for ; Mon, 25 Aug 2003 12:13:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rJyA-000343-00 for opes-archive@ietf.org; Mon, 25 Aug 2003 12:13:26 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19rJy9-000340-00 for opes-archive@ietf.org; Mon, 25 Aug 2003 12:13:25 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7PFuYqt050287 for ; Mon, 25 Aug 2003 08:56:34 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7PFuYhS050286 for ietf-openproxy-bks; Mon, 25 Aug 2003 08:56:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7PFuWqt050277 for ; Mon, 25 Aug 2003 08:56:33 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7PFuXMQ063341; Mon, 25 Aug 2003 09:56:33 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h7PFuX9c063340; Mon, 25 Aug 2003 09:56:33 -0600 (MDT) (envelope-from rousskov) Date: Mon, 25 Aug 2003 09:56:33 -0600 (MDT) From: Alex Rousskov To: MITTIG Karel FTRD/DMI/CAE cc: ietf-openproxy@imc.org Subject: Re: draft-ietf-opes-ocp-core In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB0260A6433@ftrdmel2.rd.francetelecom.fr> Message-ID: References: <7DBAFEC6A76F3E42817DF1EBE64CB0260A6433@ftrdmel2.rd.francetelecom.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by above.proper.com id h7PFuXqt050279 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id h7PFuYqt050287 Content-Transfer-Encoding: quoted-printable On Mon, 25 Aug 2003, MITTIG Karel FTRD/DMI/CAE wrote: > I'm actually working on a generic OCP implementation for a later > adaptation to DNS services. In this context, I have several comments > on actual draft, which I hope will help you to clarify or modify it: Glad to see more people interested in OCP and appreciate your comments! Detailed responses are below. > DUM=3D>'as-is' > -------------- > > "as-is" includes an "am-id" parameter. What is the range of this > am-id: AM session or Transaction ? If it's only available in current > AM session, why using it when it's already present in DUM anonymous > parameters ? Anonymous am-id parameter of DUM message identifies the _adapted_ application message within the transaction. There may be several adapted application messages within a single transaction for protocols such as SMTP. Am-id field of the "as-is" parameter identifies the _original_ application message within the transaction. For now, there can be only one original application message within a transaction, but that might change. Even if it never changes, it's good to keep original am-id in the protocol to keep original and adapted data messages symmetric (IMO). Do the above statements answer your questions? > DUM=3D>'ack' > -------------- > > DUM 'ack' can be send by both processor and callout server, but DACK > messages can only be send by callout server. Draft modification > needed to make DACK sendable by both ? I think you are right. Data acknowledgment mechanism should be symmetric. Added to the to-do list. BTW, I suspect it would be better to make the mechanism more universal so that any message can be acknowledged, not just DUM. We already have a problem with DUY messages that cannot be acknowledged. Unless I hear objections or better ideas, I will try to make the acknowledgment mechanism work with any OCP message. > DH: > -------------- > > First draft version was including DH message, which has been removed > in the last version (replaced by ack flag in DUM message as I > understand). However, several parts of the draft still refer to DH: > > -DACK > -Adapted dataflow definition > -Message Examples Indeed. The next draft version should have all DH references replaced with DUM. Please let me know if you find more leftovers after the next release. It is mostly a text management issue -- I still need to find a way to use some kind of XML placeholders with xml2rfc instead of actual message names, to better track name usage and reduce renaming problems. > DACK > -------------- > > DACK description speak about a "please-ack" parameter which is not > defined anywhere else. Also, the aim of "wont-forward" parameter is > not clear to me. If it's only used to terminate preservation > commitment, why not re-using the "wont-use" parameter ? Renamed "DUM.please-ack" in DACK description to "DUM.ack". Note that wont-use has a very different semantics: The ack parameter of a DUM message asks the recipient to acknowledge that the message has been received. The wont-use parameter informs OPES processor that a portion of the original data kept at the processor will not be used by the callout service (and, hence, does not need to be kept any longer). > PONG/PING > -------------- > rid named parameter =3D> obsolete ? Removed for now. I think we may need it later, but it is possible that we can merge the ping/pong and DACK mechanisms together and remove at least one of the ping/pong messages. See above comments regarding DACK future. > Name of [xid[am-id]] named parameter is not defined These will be anonymous parameters in the next draft release. > NO/NR > -------------- > > ocp core draft defines anonymous parameters as a list of > features(=A78.13), while HTTP adaptation uses a list of services(=A78.4= ) > instead. Which one is right ? :-) Both are correct, in principle. A "feature" is a generic mechanism that HTTP uses to negotiate "services". In other words, "service" is one of the "features" that can be negotiated. > In NR, named parameters "Rejects" (which is normally indicated by > omitting the "feature" parameter) & "Unknowns" are not defined. Will document for the next release: When accepting or rejecting an offer, the sender of the NR message MAY supply additional details via Rejects and Unknowns parameters. The Rejects parameter can be used to list features that were known to the NO recipient but could not be supported given negotiated state that existed when NO message was received. The Unknowns parameter can be used to list features that were unknown to the NO recipient. Note that even a positive NR response may have rejects and unknowns. > FLAGS > -------------- > > "flag" named-parameters (error, ack & wont-forward) type is not > clear. Normally, it should be boolean ("0"/"1", correct ?) but this > is not explicitly defined. True. Added to the to-do list. "0"/"1" would work. An alternative is to say that a present flag name means "true" and an absent flag means "false" (and have no value when the name is present). > Data syntax > -------------- > > Result parameter is defined like for example {200 "2:OK"}. However, > Martin presents on his OCP sample a {200 OK} result. Is it an error > or are both solutions possible ? If true, it will need useless > syntax checks, introduce possible errors in implementation and > should be avoid (in my opinion). {200 "2:OK"} is correct, {200 OK} is wrong, IMO. Both are syntactically valid, but we need to make it clear somewhere that only one form is valid because "OK" is a string, not a token. > Named parameters use indifferently lowercase or uppercase ("Kept", > "modp","Error", "sizep"). Knowing that the protocol is > case-sensitive, it would be clearer to use the same nomenclature for > all parameters (everything in lowercase for example). Yes. I think we are quite consistent with message names, but named parameters need more work. Use named constants rather than hard-coded strings in your code :-). > Last point is about processor management of server "adapted" data, > using processing points defined in "draft-beck-opes-irml" (adding > maybe 2 more points corresponding to processor core treatments > between 1->2 and 3->4). > > My idea is to add an optional parameter in DUM message (something > like [next-processing-point: value]). Receiving this parameter, > processor SHOULD transmit adapted message to given processing point. I am not very fond of the "processing points" approach because it is very rigid and application-specific. Some application/protocols may not have processing points (have one processing point). Some protocols may have processing points that are not appropriate to enumerate as integers or that change dynamically. And perhaps more importantly, it seems wrong for the callout service to tell processor which processing point to use next -- even if the callout service knows a lot about processing points at the processor, it cannot know whether adapted data it returns has to go through some more adaptations before being directed to a given processing point. > This will allow for example a filtering service to tell the > processor (a proxy in this case) to directly answer to a client with > a denied message (with or without allowing processor to cache the > answer), or another service to tell the processor (server or proxy > in this case) to get another content instead of the one provided in > the answer, etc. I do agree that supporting service-generated responses to client requests is a MUST-have for HTTP adaptations. I hope we can do that using application message parts concept (AM-Part): if processor is receiving response parts when adapting a request, it would know that the service is generating a response and would route that response accordingly. Would that approach work well for you? Thanks again for your comments and bug reports, Alex. From owner-ietf-openproxy@mail.imc.org Tue Aug 26 09:39:45 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03639 for ; Tue, 26 Aug 2003 09:39:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19re32-0000jN-00 for opes-archive@ietf.org; Tue, 26 Aug 2003 09:39:48 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19re31-0000jJ-00 for opes-archive@ietf.org; Tue, 26 Aug 2003 09:39:47 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7QDI7gc052874 for ; Tue, 26 Aug 2003 06:18:07 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7QDI7Am052873 for ietf-openproxy-bks; Tue, 26 Aug 2003 06:18:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7QDI5gc052865 for ; Tue, 26 Aug 2003 06:18:05 -0700 (PDT) (envelope-from karel.mittig@rd.francetelecom.com) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 26 Aug 2003 15:17:53 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE : draft-ietf-opes-ocp-core Date: Tue, 26 Aug 2003 15:17:51 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB0260A6436@ftrdmel2.rd.francetelecom.fr> Thread-Topic: draft-ietf-opes-ocp-core Thread-Index: AcNrIXb4YO5UAJT2TOW2cFyJWYP8TgAhMdMg From: "MITTIG Karel FTRD/DMI/CAE" To: "Alex Rousskov" Cc: X-OriginalArrivalTime: 26 Aug 2003 13:17:53.0061 (UTC) FILETIME=[74A36550:01C36BD4] X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7QDI6gc052869 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id h7QDI7gc052874 Content-Transfer-Encoding: quoted-printable Alex, Thanks for these usefull precisions. Just about AM-part and processing points: I didn't thought about AM-part,= but yes, it could match my need (even if it's need adaptation to DNS pro= tocol to limit overhead). However, I think we need at least a way to tell the processor if it's all= owed or not to cache specific adapted data. One example to explicit my need: having a filtering service, you may want= unfiltered content (for any client profil) to be cached by the processor= after the server call (to reduce load on this server), so the server has= to be called before the processor cache mecanism. However, you will want= potentially filtered content and corresponding adapted data not to be ca= ched because it will be managed by specific server policy. So I suggest introducing at least an optionnal flag in DUM message tellin= g processor not to cache the answer. Regards, Karel > -----Message d'origine----- > De : Alex Rousskov [mailto:rousskov@measurement-factory.com] > Envoy=E9 : lundi 25 ao=FBt 2003 17:57 > =C0 : MITTIG Karel FTRD/DMI/CAE > Cc : ietf-openproxy@imc.org > Objet : Re: draft-ietf-opes-ocp-core >=20 >=20 >=20 > On Mon, 25 Aug 2003, MITTIG Karel FTRD/DMI/CAE wrote: >=20 > > I'm actually working on a generic OCP implementation for a later > > adaptation to DNS services. In this context, I have several=20 > comments > > on actual draft, which I hope will help you to clarify or modify it: >=20 > Glad to see more people interested in OCP and appreciate your > comments! Detailed responses are below. >=20 > > DUM=3D>'as-is' > > -------------- > > > > "as-is" includes an "am-id" parameter. What is the range of this > > am-id: AM session or Transaction ? If it's only available > in current > > AM session, why using it when it's already present in DUM anonymous > > parameters ? >=20 > Anonymous am-id parameter of DUM message identifies the > _adapted_ application message within the transaction. There=20 > may be several adapted application messages within a single=20 > transaction for protocols such as SMTP. Am-id field of the=20 > "as-is" parameter identifies the _original_ application=20 > message within the transaction. >=20 > For now, there can be only one original application message > within a transaction, but that might change. Even if it never=20 > changes, it's good to keep original am-id in the protocol to=20 > keep original and adapted data messages symmetric (IMO). >=20 > Do the above statements answer your questions? >=20 > > DUM=3D>'ack' > > -------------- > > > > DUM 'ack' can be send by both processor and callout server, > but DACK > > messages can only be send by callout server. Draft > modification needed > > to make DACK sendable by both ? >=20 > I think you are right. Data acknowledgment mechanism should > be symmetric. Added to the to-do list. >=20 > BTW, I suspect it would be better to make the mechanism more > universal so that any message can be acknowledged, not just=20 > DUM. We already have a problem with DUY messages that cannot=20 > be acknowledged. Unless I hear objections or better ideas, I=20 > will try to make the acknowledgment mechanism work with any=20 > OCP message. >=20 > > DH: > > -------------- > > > > First draft version was including DH message, which has > been removed > > in the last version (replaced by ack flag in DUM message as I > > understand). However, several parts of the draft still refer to DH: > > > > -DACK > > -Adapted dataflow definition > > -Message Examples >=20 > Indeed. The next draft version should have all DH references > replaced with DUM. Please let me know if you find more=20 > leftovers after the next release. It is mostly a text=20 > management issue -- I still need to find a way to use some=20 > kind of XML placeholders with xml2rfc instead of actual=20 > message names, to better track name usage and reduce renaming=20 > problems. >=20 >=20 > > DACK > > -------------- > > > > DACK description speak about a "please-ack" parameter which is not > > defined anywhere else. Also, the aim of "wont-forward" parameter is=20 > > not clear to me. If it's only used to terminate preservation=20 > > commitment, why not re-using the "wont-use" parameter ? >=20 > Renamed "DUM.please-ack" in DACK description to "DUM.ack". >=20 > Note that wont-use has a very different semantics: The ack > parameter of a DUM message asks the recipient to acknowledge=20 > that the message has been received. The wont-use parameter=20 > informs OPES processor that a portion of the original data=20 > kept at the processor will not be used by the callout service=20 > (and, hence, does not need to be kept any longer). >=20 >=20 > > PONG/PING > > -------------- > > rid named parameter =3D> obsolete ? >=20 > Removed for now. I think we may need it later, but it is > possible that we can merge the ping/pong and DACK mechanisms=20 > together and remove at least one of the ping/pong messages.=20 > See above comments regarding DACK future. >=20 > > Name of [xid[am-id]] named parameter is not defined >=20 > These will be anonymous parameters in the next draft release. >=20 > > NO/NR > > -------------- > > > > ocp core draft defines anonymous parameters as a list of > > features(=A78.13), while HTTP adaptation uses a list of=20 > services(=A78.4) > > instead. Which one is right ? :-) >=20 > Both are correct, in principle. A "feature" is a generic > mechanism that HTTP uses to negotiate "services". In other=20 > words, "service" is one of the "features" that can be negotiated. >=20 > > In NR, named parameters "Rejects" (which is normally indicated by > > omitting the "feature" parameter) & "Unknowns" are not defined. >=20 > Will document for the next release: >=20 > When accepting or rejecting an offer, the sender of the NR message > MAY supply additional details via Rejects and Unknowns parameters. > The Rejects parameter can be used to list features that > were known to > the NO recipient but could not be supported given negotiated state > that existed when NO message was received. The Unknowns=20 > parameter can > be used to list features that were unknown to the NO recipient. >=20 > Note that even a positive NR response may have rejects and unknowns. >=20 > > FLAGS > > -------------- > > > > "flag" named-parameters (error, ack & wont-forward) type is > not clear. > > Normally, it should be boolean ("0"/"1", correct ?) but this is not > > explicitly defined. >=20 > True. Added to the to-do list. "0"/"1" would work. An > alternative is to say that a present flag name means "true"=20 > and an absent flag means "false" (and have no value when the=20 > name is present). >=20 > > Data syntax > > -------------- > > > > Result parameter is defined like for example {200 "2:OK"}. However, > > Martin presents on his OCP sample a {200 OK} result. Is it=20 > an error or > > are both solutions possible ? If true, it will need useless syntax > > checks, introduce possible errors in implementation and should be=20 > > avoid (in my opinion). >=20 > {200 "2:OK"} is correct, {200 OK} is wrong, IMO. Both are > syntactically valid, but we need to make it clear somewhere=20 > that only one form is valid because "OK" is a string, not a token. >=20 > > Named parameters use indifferently lowercase or uppercase ("Kept", > > "modp","Error", "sizep"). Knowing that the protocol is=20 > case-sensitive, > > it would be clearer to use the same nomenclature for all parameters > > (everything in lowercase for example). >=20 > Yes. I think we are quite consistent with message names, but > named parameters need more work. Use named constants rather=20 > than hard-coded strings in your code :-). >=20 > > Last point is about processor management of server "adapted" data, > > using processing points defined in "draft-beck-opes-irml" (adding=20 > > maybe 2 more points corresponding to processor core=20 > treatments between > > 1->2 and 3->4). > > > > My idea is to add an optional parameter in DUM message > (something like > > [next-processing-point: value]). Receiving this parameter, > processor > > SHOULD transmit adapted message to given processing point. >=20 > I am not very fond of the "processing points" approach > because it is very rigid and application-specific. Some=20 > application/protocols may not have processing points (have=20 > one processing point). Some protocols may have processing=20 > points that are not appropriate to enumerate as integers or=20 > that change dynamically. >=20 > And perhaps more importantly, it seems wrong for the callout > service to tell processor which processing point to use next=20 > -- even if the callout service knows a lot about processing=20 > points at the processor, it cannot know whether adapted data=20 > it returns has to go through some more adaptations before=20 > being directed to a given processing point. >=20 > > This will allow for example a filtering service to tell the > processor > > (a proxy in this case) to directly answer to a client with a denied > > message (with or without allowing processor to cache the=20 > answer), or > > another service to tell the processor (server or proxy in > this case) > > to get another content instead of the one provided in the > answer, etc. >=20 > I do agree that supporting service-generated responses to > client requests is a MUST-have for HTTP adaptations. I hope=20 > we can do that using application message parts concept=20 > (AM-Part): if processor is receiving response parts when=20 > adapting a request, it would know that the service is=20 > generating a response and would route that response=20 > accordingly. Would that approach work well for you? >=20 >=20 > Thanks again for your comments and bug reports, >=20 > Alex. >=20 >=20 From owner-ietf-openproxy@mail.imc.org Tue Aug 26 11:23:09 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10849 for ; Tue, 26 Aug 2003 11:23:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rff8-0002V7-00 for opes-archive@ietf.org; Tue, 26 Aug 2003 11:23:14 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19rff7-0002V4-00 for opes-archive@ietf.org; Tue, 26 Aug 2003 11:23:13 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7QF5Zgc058923 for ; Tue, 26 Aug 2003 08:05:35 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7QF5ZRI058922 for ietf-openproxy-bks; Tue, 26 Aug 2003 08:05:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7QF5Ygc058902 for ; Tue, 26 Aug 2003 08:05:34 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7QF5YMQ097141; Tue, 26 Aug 2003 09:05:34 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h7QF5YFJ097140; Tue, 26 Aug 2003 09:05:34 -0600 (MDT) (envelope-from rousskov) Date: Tue, 26 Aug 2003 09:05:34 -0600 (MDT) From: Alex Rousskov To: MITTIG Karel FTRD/DMI/CAE cc: ietf-openproxy@imc.org Subject: Re: RE : draft-ietf-opes-ocp-core In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB0260A6436@ftrdmel2.rd.francetelecom.fr> Message-ID: References: <7DBAFEC6A76F3E42817DF1EBE64CB0260A6436@ftrdmel2.rd.francetelecom.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 26 Aug 2003, MITTIG Karel FTRD/DMI/CAE wrote: > However, I think we need at least a way to tell the processor if > it's allowed or not to cache specific adapted data. > > One example to explicit my need: having a filtering service, you may > want unfiltered content (for any client profil) to be cached by the > processor after the server call (to reduce load on this server), so > the server has to be called before the processor cache mecanism. > However, you will want potentially filtered content and > corresponding adapted data not to be cached because it will be > managed by specific server policy. > > So I suggest introducing at least an optionnal flag in DUM message > telling processor not to cache the answer. I agree that cache control is a desirable feature in many environments. There are several related observations: - Some application protocols to not support the notion of caching (e.g., SMTP). - Application protocols that support caching usually have built-in caching controls (e.g., Cache-Control header in HTTP). These controls are often quite sophisticated. It looks to me that adding cache control features to OCP Core would be wrong because some protocols do not have a notion of caching at all, and those protocols that do already have extensive controls that OCP Core would not be able to duplicate in a generic manner. How about this: - Let OCP application bindings handle cache control issue. - Recommend that an application binding relies on existing application controls rather than extend OCP. Would that address your needs, including the filtering example you gave above? Can the filter service alter Cache-Control headers of the filtered responses appropriately? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Tue Aug 26 13:24:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16080 for ; Tue, 26 Aug 2003 13:24:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rhYv-0003kJ-00 for opes-archive@ietf.org; Tue, 26 Aug 2003 13:24:57 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19rhYu-0003kG-00 for opes-archive@ietf.org; Tue, 26 Aug 2003 13:24:56 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7QHB8gc070448 for ; Tue, 26 Aug 2003 10:11:08 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7QHB7Ha070447 for ietf-openproxy-bks; Tue, 26 Aug 2003 10:11:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7QHB5gc070426 for ; Tue, 26 Aug 2003 10:11:06 -0700 (PDT) (envelope-from karel.mittig@rd.francetelecom.com) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 26 Aug 2003 19:10:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE : RE : draft-ietf-opes-ocp-core Date: Tue, 26 Aug 2003 19:10:54 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02609FED0@ftrdmel2.rd.francetelecom.fr> Thread-Topic: RE : draft-ietf-opes-ocp-core Thread-Index: AcNr44IX3l8A4KChR2aF0+Tppg+90gAC2Cqw From: "MITTIG Karel FTRD/DMI/CAE" To: "Alex Rousskov" Cc: X-OriginalArrivalTime: 26 Aug 2003 17:10:55.0610 (UTC) FILETIME=[02E30DA0:01C36BF5] X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7QHB7gc070440 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id h7QHB8gc070448 Content-Transfer-Encoding: quoted-printable Altering the cache control header will work, but it could lead to side effects. If you take the case when service's clients are subnetworks or enterprise= s with proxies on it, they wont be able to cache the response any more. In the same way, client application can respect too closely zero TTL and re-send request very frequently. Result will then be an increased load on your processor, and the benefits of caching unfiltered content will be loss. But you're right, the problem is specific to some application protocols (and also some cases), so it can be address in application bindings. Karel > De : Alex Rousskov > Envoy=E9 : mardi 26 ao=FBt 2003 17:06 > =C0 : MITTIG Karel FTRD/DMI/CAE > Cc : ietf-openproxy@imc.org > Objet : Re: RE : draft-ietf-opes-ocp-core >=20 >=20 >=20 > I agree that cache control is a desirable feature in many=20 > environments. There are several related observations: >=20 > - Some application protocols to not support the > notion of caching (e.g., SMTP). >=20 > - Application protocols that support caching > usually have built-in caching controls (e.g., > Cache-Control header in HTTP). These controls > are often quite sophisticated. >=20 > It looks to me that adding cache control features to OCP Core=20 > would be wrong because some protocols do not have a notion of=20 > caching at all, and those protocols that do already have=20 > extensive controls that OCP Core would not be able to=20 > duplicate in a generic manner. >=20 > How about this: >=20 > - Let OCP application bindings handle cache control > issue. >=20 > - Recommend that an application binding relies > on existing application controls rather than > extend OCP. >=20 > Would that address your needs, including the filtering=20 > example you gave above? Can the filter service alter=20 > Cache-Control headers of the filtered responses appropriately? >=20 > Thanks, >=20 > Alex. >=20 From owner-ietf-openproxy@mail.imc.org Wed Aug 27 02:59:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28951 for ; Wed, 27 Aug 2003 02:59:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ruHe-0007Lg-00 for opes-archive@ietf.org; Wed, 27 Aug 2003 02:59:58 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19ruHd-0007Ld-00 for opes-archive@ietf.org; Wed, 27 Aug 2003 02:59:58 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7R6mBgc018990 for ; Tue, 26 Aug 2003 23:48:11 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7R6mBUD018989 for ietf-openproxy-bks; Tue, 26 Aug 2003 23:48:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from web14811.mail.yahoo.com (web14811.mail.yahoo.com [66.163.172.95]) by above.proper.com (8.12.9/8.12.8) with SMTP id h7R6mAgc018978 for ; Tue, 26 Aug 2003 23:48:10 -0700 (PDT) (envelope-from redkresearch@yahoo.com.sg) Message-ID: <20030827064810.37471.qmail@web14811.mail.yahoo.com> Received: from [137.132.3.8] by web14811.mail.yahoo.com via HTTP; Wed, 27 Aug 2003 14:48:10 CST Date: Wed, 27 Aug 2003 14:48:10 +0800 (CST) From: =?iso-8859-1?q?Red=20K?= Subject: is there OPES prototype proxy? To: ietf-openproxy@imc.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi, It is an fresh man's topic. But I still want to know if there is any prototype OPES proxy that supports Proxylet Local Execution Environment Java Binding V0.1. Thus I can develope my proxylet because I am interested in OPES. Thank you very much. Red K __________________________________________________ Do You Yahoo!? Play now and stand a chance to win cash prizes! http://yahoo.com.sg/millionaire From owner-ietf-openproxy@mail.imc.org Wed Aug 27 08:38:19 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22169 for ; Wed, 27 Aug 2003 08:38:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rzZ9-0004j9-00 for opes-archive@ietf.org; Wed, 27 Aug 2003 08:38:23 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19rzZ8-0004j6-00 for opes-archive@ietf.org; Wed, 27 Aug 2003 08:38:22 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RCQAgc061613 for ; Wed, 27 Aug 2003 05:26:10 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7RCQ99U061612 for ietf-openproxy-bks; Wed, 27 Aug 2003 05:26:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RCQ8gc061606 for ; Wed, 27 Aug 2003 05:26:08 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7RCQ9MQ028720; Wed, 27 Aug 2003 06:26:09 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h7RCQ8hJ028719; Wed, 27 Aug 2003 06:26:08 -0600 (MDT) (envelope-from rousskov) Date: Wed, 27 Aug 2003 06:26:08 -0600 (MDT) From: Alex Rousskov To: =?iso-8859-1?q?Red=20K?= cc: ietf-openproxy@imc.org Subject: Re: is there OPES prototype proxy? In-Reply-To: <20030827064810.37471.qmail@web14811.mail.yahoo.com> Message-ID: References: <20030827064810.37471.qmail@web14811.mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 27 Aug 2003, [iso-8859-1] Red K wrote: > It is an fresh man's topic. But I still want to know if there is any > prototype OPES proxy that supports Proxylet Local Execution > Environment Java Binding V0.1. Thus I can develope my proxylet > because I am interested in OPES. I am working on a prototype OPES proxy. It almost talks OCP to a prototype callout service being developed by Martin Stecher. There is no proxylet support. I heard proxylets were a popular topic long time ago, but there were no proxylets mentioned on this list for quite a while now. If you are interested in OPES, the shortest path to a working system may be to write a callout server that speaks OCP. One can write such a server in Java, of course. HTH, Alex. From owner-ietf-openproxy@mail.imc.org Wed Aug 27 09:18:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25128 for ; Wed, 27 Aug 2003 09:18:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s0CT-0005TK-00 for opes-archive@ietf.org; Wed, 27 Aug 2003 09:19:01 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19s0CT-0005TH-00 for opes-archive@ietf.org; Wed, 27 Aug 2003 09:19:01 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RD55gc065857 for ; Wed, 27 Aug 2003 06:05:05 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7RD55wG065856 for ietf-openproxy-bks; Wed, 27 Aug 2003 06:05:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from web14811.mail.yahoo.com (web14811.mail.yahoo.com [66.163.172.95]) by above.proper.com (8.12.9/8.12.8) with SMTP id h7RD53gc065851 for ; Wed, 27 Aug 2003 06:05:03 -0700 (PDT) (envelope-from redkresearch@yahoo.com.sg) Message-ID: <20030827130504.87687.qmail@web14811.mail.yahoo.com> Received: from [137.132.3.8] by web14811.mail.yahoo.com via HTTP; Wed, 27 Aug 2003 21:05:04 CST Date: Wed, 27 Aug 2003 21:05:04 +0800 (CST) From: =?iso-8859-1?q?Red=20K?= Subject: Re: is there OPES prototype proxy? To: Alex Rousskov Cc: ietf-openproxy@imc.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Yes, I also mentioned that proxylet is not discussed for a long time. But what is the reason for this? Is it related to system efficiency and simple maintainance? I mean to setup one callout server is easy to maintain and higher efficient to carry out specific service than put them onto a single host. --- Alex Rousskov wrote: > > On Wed, 27 Aug 2003, [iso-8859-1] Red K wrote: > > > It is an fresh man's topic. But I still want to > know if there is any > > prototype OPES proxy that supports Proxylet Local > Execution > > Environment Java Binding V0.1. Thus I can develope > my proxylet > > because I am interested in OPES. > > I am working on a prototype OPES proxy. It almost > talks OCP to a > prototype callout service being developed by Martin > Stecher. There is > no proxylet support. I heard proxylets were a > popular topic long time > ago, but there were no proxylets mentioned on this > list for quite a > while now. If you are interested in OPES, the > shortest path to a > working system may be to write a callout server that > speaks OCP. One > can write such a server in Java, of course. > > HTH, > > Alex. __________________________________________________ Do You Yahoo!? Play now and stand a chance to win cash prizes! http://yahoo.com.sg/millionaire From owner-ietf-openproxy@mail.imc.org Wed Aug 27 09:48:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27261 for ; Wed, 27 Aug 2003 09:48:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s0fO-00063X-00 for opes-archive@ietf.org; Wed, 27 Aug 2003 09:48:54 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19s0fN-00063T-00 for opes-archive@ietf.org; Wed, 27 Aug 2003 09:48:53 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RDZTgc066861 for ; Wed, 27 Aug 2003 06:35:29 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7RDZSFm066860 for ietf-openproxy-bks; Wed, 27 Aug 2003 06:35:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RDZRgc066855 for ; Wed, 27 Aug 2003 06:35:27 -0700 (PDT) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7RDZSHa078744 for ; Wed, 27 Aug 2003 09:35:28 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7RDZL2e077520 for ; Wed, 27 Aug 2003 09:35:21 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id h7RDZKFU000084 for ; Wed, 27 Aug 2003 09:35:20 -0400 (EDT) Message-ID: <3F4CB3F2.2090009@mhof.com> Date: Wed, 27 Aug 2003 09:36:50 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: is there OPES prototype proxy? References: <20030827130504.87687.qmail@web14811.mail.yahoo.com> In-Reply-To: <20030827130504.87687.qmail@web14811.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Red K wrote: > Yes, I also mentioned that proxylet is not discussed > for a long time. But what is the reason for this? Reason is that the OPES WG is chartered to specify the callout protocol and the rules language, but *not* a proxylet interface or a proxylet architecture - this would be a local implementation decision or standardized elsewhere. The OPES architecture does *not* rule out proxylet, but the focus of the WG is on the callout mechanism. -Markus From owner-ietf-openproxy@mail.imc.org Wed Aug 27 10:20:41 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00743 for ; Wed, 27 Aug 2003 10:20:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s1AD-0006ZJ-00 for opes-archive@ietf.org; Wed, 27 Aug 2003 10:20:45 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19s1AC-0006ZG-00 for opes-archive@ietf.org; Wed, 27 Aug 2003 10:20:44 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RE1Cgc067717 for ; Wed, 27 Aug 2003 07:01:12 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7RE1Brs067716 for ietf-openproxy-bks; Wed, 27 Aug 2003 07:01:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RE1Bgc067710 for ; Wed, 27 Aug 2003 07:01:11 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7RE13G28873; Wed, 27 Aug 2003 10:01:03 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Aug 2003 10:01:04 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD75406B68CCF@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Red K Cc: ietf-openproxy@imc.org Subject: RE: is there OPES prototype proxy? Date: Wed, 27 Aug 2003 10:01:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36CA3.A5F0562A" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C36CA3.A5F0562A Content-Type: text/plain Hi, At this stage our charter does not focus on proxylet or how rules are loaded to the opes processor. Abbie > -----Original Message----- > From: Red K [mailto:redkresearch@yahoo.com.sg] > Sent: Wednesday, August 27, 2003 9:05 AM > To: Alex Rousskov > Cc: ietf-openproxy@imc.org > Subject: Re: is there OPES prototype proxy? > > > > Yes, I also mentioned that proxylet is not discussed > for a long time. But what is the reason for this? > > Is it related to system efficiency and simple > maintainance? I mean to setup one callout server is > easy to maintain and higher efficient to carry out > specific service than put them onto a single host. > > --- Alex Rousskov > wrote: > > > On Wed, 27 Aug 2003, [iso-8859-1] Red K wrote: > > > > > It is an fresh man's topic. But I still want to > > know if there is any > > > prototype OPES proxy that supports Proxylet Local > > Execution > > > Environment Java Binding V0.1. Thus I can develope > > my proxylet > > > because I am interested in OPES. > > > > I am working on a prototype OPES proxy. It almost > > talks OCP to a > > prototype callout service being developed by Martin > > Stecher. There is > > no proxylet support. I heard proxylets were a > > popular topic long time > > ago, but there were no proxylets mentioned on this > > list for quite a > > while now. If you are interested in OPES, the > > shortest path to a > > working system may be to write a callout server that > > speaks OCP. One > > can write such a server in Java, of course. > > > > HTH, > > > > Alex. > > __________________________________________________ > Do You Yahoo!? > Play now and stand a chance to win cash prizes! > http://yahoo.com.sg/millionaire > ------_=_NextPart_001_01C36CA3.A5F0562A Content-Type: text/html RE: is there OPES prototype proxy?

Hi,

At this stage our charter does not focus on proxylet or how rules are loaded to the opes processor.

Abbie

> -----Original Message-----
> From: Red K [mailto:redkresearch@yahoo.com.sg]
> Sent: Wednesday, August 27, 2003 9:05 AM
> To: Alex Rousskov
> Cc: ietf-openproxy@imc.org
> Subject: Re: is there OPES prototype proxy?
>
>
>
> Yes, I also mentioned that proxylet is not discussed
> for a long time. But what is the reason for this?
>
> Is it related to system efficiency and simple
> maintainance? I mean to setup one callout server is
> easy to maintain and higher efficient to carry out
> specific service than put them onto a single host.
>
>  --- Alex Rousskov <rousskov@measurement-factory.com>
> wrote: >
> > On Wed, 27 Aug 2003, [iso-8859-1] Red K wrote:
> >
> > > It is an fresh man's topic. But I still want to
> > know if there is any
> > > prototype OPES proxy that supports Proxylet Local
> > Execution
> > > Environment Java Binding V0.1. Thus I can develope
> > my proxylet
> > > because I am interested in OPES.
> >
> > I am working on a prototype OPES proxy. It almost
> > talks OCP to a
> > prototype callout service being developed by Martin
> > Stecher. There is
> > no proxylet support. I heard proxylets were a
> > popular topic long time
> > ago, but there were no proxylets mentioned on this
> > list for quite a
> > while now. If you are interested in OPES, the
> > shortest path to a
> > working system may be to write a callout server that
> > speaks OCP. One
> > can write such a server in Java, of course.
> >
> > HTH,
> >
> > Alex.
>
> __________________________________________________
> Do You Yahoo!?
> Play now and stand a chance to win cash prizes!
> http://yahoo.com.sg/millionaire
>

------_=_NextPart_001_01C36CA3.A5F0562A-- From owner-ietf-openproxy@mail.imc.org Wed Aug 27 11:24:47 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08570 for ; Wed, 27 Aug 2003 11:24:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s2AE-0000th-00 for opes-archive@ietf.org; Wed, 27 Aug 2003 11:24:51 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19s2AE-0000te-00 for opes-archive@ietf.org; Wed, 27 Aug 2003 11:24:50 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RFCJgc070555 for ; Wed, 27 Aug 2003 08:12:19 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7RFCJuf070554 for ietf-openproxy-bks; Wed, 27 Aug 2003 08:12:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7RFCHgc070546 for ; Wed, 27 Aug 2003 08:12:17 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7RFCGMQ032763; Wed, 27 Aug 2003 09:12:16 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h7RFCGag032762; Wed, 27 Aug 2003 09:12:16 -0600 (MDT) (envelope-from rousskov) Date: Wed, 27 Aug 2003 09:12:16 -0600 (MDT) From: Alex Rousskov To: =?iso-8859-1?q?Red=20K?= cc: OPES WG Subject: Re: is there OPES prototype proxy? In-Reply-To: <87609AFB433BD5118D5E0002A52CD75406B68CCF@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD75406B68CCF@zcard0k6.ca.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 27 Aug 2003, [iso-8859-1] Red K wrote: > Yes, I also mentioned that proxylet is not discussed > for a long time. But what is the reason for this? > > Is it related to system efficiency and simple > maintainance? I mean to setup one callout server is > easy to maintain and higher efficient to carry out > specific service than put them onto a single host. I do not think that proxylets are always more or less efficient than callout services. Same for the ease of maintenance. It all depends on a particular environment and workload. Moreover, it is possible (if not desirable!) to have a proxylet that communicates with the OPES processor via OCP and, hence, is also a callout service. Alex. On Wed, 27 Aug 2003, Markus Hofmann wrote: > Reason is that the OPES WG is chartered to specify the callout > protocol and the rules language, but *not* a proxylet interface or a > proxylet architecture - this would be a local implementation > decision or standardized elsewhere. > > The OPES architecture does *not* rule out proxylet, but the focus of > the WG is on the callout mechanism. On Wed, 27 Aug 2003, Abbie Barbir wrote: > At this stage our charter does not focus on proxylet or how rules > are loaded to the opes processor. From owner-ietf-openproxy@mail.imc.org Thu Aug 28 08:30:23 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08161 for ; Thu, 28 Aug 2003 08:30:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sLv0-0005OH-00 for opes-archive@ietf.org; Thu, 28 Aug 2003 08:30:26 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19sLuz-0005O9-00 for opes-archive@ietf.org; Thu, 28 Aug 2003 08:30:25 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SC9ggc058228 for ; Thu, 28 Aug 2003 05:09:42 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7SC9gMp058227 for ietf-openproxy-bks; Thu, 28 Aug 2003 05:09:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SC9fgc058220 for ; Thu, 28 Aug 2003 05:09:41 -0700 (PDT) (envelope-from karel.mittig@rd.francetelecom.com) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 28 Aug 2003 14:09:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE : RE : RE : draft-ietf-opes-ocp-core Date: Thu, 28 Aug 2003 14:09:04 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02609FED3@ftrdmel2.rd.francetelecom.fr> Thread-Topic: RE : RE : draft-ietf-opes-ocp-core Thread-Index: AcNr99hHwxsX+z4MT9C8uPjKr00IBABYu/EA From: "MITTIG Karel FTRD/DMI/CAE" To: "Alex Rousskov" Cc: X-OriginalArrivalTime: 28 Aug 2003 12:09:11.0296 (UTC) FILETIME=[30B37800:01C36D5D] X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h7SC9ggc058223 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id h7SC9ggc058228 Content-Transfer-Encoding: quoted-printable Alex, I think I wasn't clear in previous mail. Please see response below, I hop= e it will better explain my need. > -----Message d'origine----- > De : Alex Rousskov [mailto:rousskov@measurement-factory.com]=20 > Envoy=E9 : mardi 26 ao=FBt 2003 19:31 > =C0 : MITTIG Karel FTRD/DMI/CAE > Cc : ietf-openproxy@imc.org > Objet : Re: RE : RE : draft-ietf-opes-ocp-core >=20 >=20 >=20 > On Tue, 26 Aug 2003, MITTIG Karel FTRD/DMI/CAE wrote: >=20 > > Altering the cache control header will work, but it could=20 > lead to side=20 > > effects. > > > > If you take the case when service's clients are subnetworks or=20 > > enterprises with proxies on it, they wont be able to cache the=20 > > response any more. In the same way, client application can=20 > respect too=20 > > closely zero TTL and re-send request very frequently.=20 > Result will then=20 > > be an increased load on your processor, and the benefits of caching=20 > > unfiltered content will be loss. >=20 > My interpretation of the above is "application cache controls=20 > may not be able to express what a particular OPES system may=20 > want to express". For example, HTTP does not have enough=20 > knobs to control caching at intermediaries separately from=20 > caching by end clients while your OPES system wants to do=20 > just that. Is this interpretation correct? >=20 Not exactly: my need is to be able to cache the OCP treatment applied, wh= ich should be independent of the application protocol and application cac= hing information. See example below. > Can you provide a more specific example that illustrates=20 > inability of, say, HTTP Cache-Control modifications to=20 > achieve your goals? >=20 Take an HTTP filtering service offered to 2 communities (for example high= and low schools using a filtering service), each passing through the OCP= processor. The aim of the service is to filter Internet access but with = a different level for each community. Internet content can then be divide= d in 3 parts: - the content allowed&denied only for community 1 (say [E1]) - the content allowed&denied only for community 2 (say [E2]) - the content allowed&denied for communities 1 and 2 (say [I]) There are 2 ways to treat the problem: - The "simplest" one is to say that the service is different, so you pro= vide 2 OCP processors calling 2 services (or the same service with differ= ent parameters). In this case, caching is not a problem, but this solutio= n becomes costly because you double the equipments. - The second one is to say that the service uses a policy to know which = treatment to apply depending of the client. In this case, there will only= be one processor and one service, which is far more interesting.=20 Normally, saying the processor can do HTTP caching, you will need to call= the service after the caching process ("response post-cache" vectoring p= oint) to avoid the cache storing a modified version which should only be = send to community 1 or 2. You don't have in this case to modify cache con= trol of responses, so it works fine. The problem with this solution is that you will query your service for ea= ch incoming request (or indeed each outgoing response). If there are prox= ies in one community, you will then save corresponding cached responses, = but it will be really hard to predict the gain. If you want to make some optimization, you can see that [I] content could= be cached by the processor. Or, this part can represent a lot of queries= , saying x%, so allowing the processor to cache corresponding modified re= sponse will save x% load on your service. But now, if you put your service before the caching process of your proce= ssor, the processor won't be able to distinguish between [E1]&[E2], even = if it is able to store the 2 versions of responses, because it doesn't (a= nd doesn't have to) know service policy. So the service has to tell proce= ssor not to cache this part. One way is to do this as you suggested by mo= difying the response using protocol parameters to say it is not cacheable. The drawback in this case is that it has an impact on clients application= s. If one community uses proxies, they wont be able to cache the response= s any more. You will then increase the service load related to these resp= onses to an unknown level (depending of the original TTL and the treatmen= t required). So the only way I see to be sure to gain those x% (which could be for som= e services around 80%) is to add a simple "is-cacheable" flag in OCP mess= ages (without needing extended controls like application protocols provid= e). Karel > > But you're right, the problem is specific to some application=20 > > protocols (and also some cases), so it can be address in=20 > application=20 > > bindings. >=20 > Agreed. This becomes are to-do item for HTTP OPES binding then. >=20 > Alex. >=20 >=20 From owner-ietf-openproxy@mail.imc.org Thu Aug 28 13:45:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04257 for ; Thu, 28 Aug 2003 13:45:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sQpp-0003tJ-00 for opes-archive@ietf.org; Thu, 28 Aug 2003 13:45:25 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19sQpp-0003tF-00 for opes-archive@ietf.org; Thu, 28 Aug 2003 13:45:25 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SHO5gc084594 for ; Thu, 28 Aug 2003 10:24:05 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7SHO5np084593 for ietf-openproxy-bks; Thu, 28 Aug 2003 10:24:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SHO1gc084588 for ; Thu, 28 Aug 2003 10:24:01 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7SHO2qF071857; Thu, 28 Aug 2003 11:24:02 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h7SHO2iN071856; Thu, 28 Aug 2003 11:24:02 -0600 (MDT) (envelope-from rousskov) Date: Thu, 28 Aug 2003 11:24:02 -0600 (MDT) From: Alex Rousskov To: MITTIG Karel FTRD/DMI/CAE cc: ietf-openproxy@imc.org Subject: RE: draft-ietf-opes-ocp-core In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB02609FED3@ftrdmel2.rd.francetelecom.fr> Message-ID: References: <7DBAFEC6A76F3E42817DF1EBE64CB02609FED3@ftrdmel2.rd.francetelecom.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 28 Aug 2003, MITTIG Karel FTRD/DMI/CAE wrote: > Not exactly: my need is to be able to cache the OCP treatment > applied, which should be independent of the application protocol and > application caching information. See example below. Thank you for providing a specific example. I think we are on the same page as far as your requirements are concerned, but I still think your needs can be addressed by existing HTTP cache controls. In fact, I think we can do better than x%. Please see below. > Take an HTTP filtering service offered to 2 communities (for example > high and low schools using a filtering service), each passing > through the OCP processor. The aim of the service is to filter > Internet access but with a different level for each community. > Internet content can then be divided in 3 parts: > > - the content allowed&denied only for community 1 (say [E1]) > - the content allowed&denied only for community 2 (say [E2]) > - the content allowed&denied for communities 1 and 2 (say [I]) > > There are 2 ways to treat the problem: > > > - The second one is to say that the service uses a policy to > know which treatment to apply depending of the client. In this case, > there will only be one processor and one service, which is far more > interesting. > > Normally, saying the processor can do HTTP caching, you will need to > call the service after the caching process ("response post-cache" > vectoring point) to avoid the cache storing a modified version which > should only be send to community 1 or 2. You don't have in this case > to modify cache control of responses, so it works fine. > > The problem with this solution is that you will query your service > for each incoming request (or indeed each outgoing response). If > there are proxies in one community, you will then save corresponding > cached responses, but it will be really hard to predict the gain. > > If you want to make some optimization, you can see that [I] content > could be cached by the processor. Or, this part can represent a lot > of queries, saying x%, so allowing the processor to cache > corresponding modified response will save x% load on your service. > > But now, if you put your service before the caching process of your > processor, the processor won't be able to distinguish between > [E1]&[E2], even if it is able to store the 2 versions of responses, > because it doesn't (and doesn't have to) know service policy. So the > service has to tell processor not to cache this part. One way is to > do this as you suggested by modifying the response using protocol > parameters to say it is not cacheable. > > The drawback in this case is that it has an impact on clients > applications. If one community uses proxies, they wont be able to > cache the responses any more. You will then increase the service > load related to these responses to an unknown level (depending of > the original TTL and the treatment required). > > So the only way I see to be sure to gain those x% (which could be > for some services around 80%) is to add a simple "is-cacheable" flag > in OCP messages (without needing extended controls like application > protocols provide). I believe HTTP already have the mechanism that supports the above optimization. In fact, it allows you to cache all three types of content! The mechanism is a Vary: header. If the caching proxy supports caching of responses with Vary: header, then OPES can use it as follows: - On the pre-cache response side, OPES needs to add a Vary: X-Client-Category HTTP response header. This is a very "cheap" modification that may even be supported by the HTTP proxy itself. - On the request side, OPES needs to set a X-Client-Category: HTTP request header, with one of the three appropriate header values. This is a very "cheap" modification as well, because the filter needs to determine client category to perform filtering checks anyway! With the above scheme in place, the cache can store all content for all clients. So can downstream caches. Will this work the way you want it? Note that you have to assume that there are no caches shared by both communities in front of the cache in question. If there are shared caches, neither your scheme nor Vary headers would work. Your scheme will not work because it affects cachability at the current HTTP hop only. My scheme will not work because all downstream requests will have no X-Client-Category header. The only solution is then to mark all controlled responses as uncachable using HTTP headers. Did I miss anything? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Thu Aug 28 15:45:24 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12251 for ; Thu, 28 Aug 2003 15:45:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sShz-0005LH-00 for opes-archive@ietf.org; Thu, 28 Aug 2003 15:45:27 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19sShz-0005LD-00 for opes-archive@ietf.org; Thu, 28 Aug 2003 15:45:27 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SJPDgc093674 for ; Thu, 28 Aug 2003 12:25:13 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7SJPCxK093673 for ietf-openproxy-bks; Thu, 28 Aug 2003 12:25:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SJPAgc093668 for ; Thu, 28 Aug 2003 12:25:11 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7SJNtU18714; Thu, 28 Aug 2003 15:23:56 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Aug 2003 15:23:56 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD75406BC5446@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: jfcm , Alex Rousskov Cc: OPES WG Subject: [end points comm] OPES System Date: Thu, 28 Aug 2003 15:23:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36D99.E9A8DC4C" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C36D99.E9A8DC4C Content-Type: text/plain All, I am Re-Reading this thread as I am working on the next version of the draft. I really can not come up with a conclusion as to what the WG has decided. Can each please resubmit thier final opnion. I will then come up with text and put it for voting. Abbie ------_=_NextPart_001_01C36D99.E9A8DC4C Content-Type: text/html [end points comm] OPES System

All,

I am Re-Reading this thread as I am working on the next version of the draft.
I really can not come up with a conclusion as to what the WG has decided.

Can each please resubmit thier final opnion. I will then come up with text and put it for voting.


Abbie

------_=_NextPart_001_01C36D99.E9A8DC4C-- From owner-ietf-openproxy@mail.imc.org Thu Aug 28 15:58:35 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13575 for ; Thu, 28 Aug 2003 15:58:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sSul-0005i0-00 for opes-archive@ietf.org; Thu, 28 Aug 2003 15:58:39 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19sSuk-0005hx-00 for opes-archive@ietf.org; Thu, 28 Aug 2003 15:58:38 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SJajgc094110 for ; Thu, 28 Aug 2003 12:36:45 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7SJajiJ094109 for ietf-openproxy-bks; Thu, 28 Aug 2003 12:36:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SJaHgc094087 for ; Thu, 28 Aug 2003 12:36:25 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7SJaHqF076216; Thu, 28 Aug 2003 13:36:17 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h7SJa7sl076214; Thu, 28 Aug 2003 13:36:07 -0600 (MDT) (envelope-from rousskov) Date: Thu, 28 Aug 2003 13:36:07 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: Re: [end points comm] OPES System In-Reply-To: <87609AFB433BD5118D5E0002A52CD75406BC5446@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD75406BC5446@zcard0k6.ca.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 28 Aug 2003, Abbie Barbir wrote: > I am Re-Reading this thread as I am working on the next version of > the draft. I really can not come up with a conclusion as to what > the WG has decided. > > Can each please resubmit thier final opnion. I will then come up > with text and put it for voting. In my opinion, all MUST-level tracing requirements must be limited to an OPES System. We would need to define an OPES system. The current "IAB treatment" draft (the IP Addressing section) can be used as a starting point: An OPES System is a collection of OPES entities that is directly addressable on IP level by an end user. This is just a starting point: We would need to apply the same logic to client-side systems and polish. SHOULD- and MAY-level tracing requirements can refer to OPES processors, callout services, and other OPES entities. We can deal with the exact definitions and SHOULDs later. The primary question is whether tracing MUST be supported below the System level. I say "no" because it is never essential for the other side to know details of System configuration and because it is often impractical for the System to provide such details. Alex. From owner-ietf-openproxy@mail.imc.org Thu Aug 28 16:16:15 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15086 for ; Thu, 28 Aug 2003 16:16:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sTBr-000696-00 for opes-archive@ietf.org; Thu, 28 Aug 2003 16:16:19 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19sTBq-000693-00 for opes-archive@ietf.org; Thu, 28 Aug 2003 16:16:18 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SJsQgc094847 for ; Thu, 28 Aug 2003 12:54:26 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7SJsQAj094846 for ietf-openproxy-bks; Thu, 28 Aug 2003 12:54:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SJsIgc094839 for ; Thu, 28 Aug 2003 12:54:21 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7SJsDt08242 for ; Thu, 28 Aug 2003 15:54:14 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Aug 2003 15:54:14 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD75406BC54C6@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: ietf-openproxy@imc.org Subject: [opes-end-comm]: What is traceable in an OPES Flow? Date: Thu, 28 Aug 2003 15:54:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36D9E.25E30080" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C36D9E.25E30080 Content-Type: text/plain Hi, I am working my way through the tracing draft. The next issue is section 2.1 "What is traceable in an OPES Flow?" The section is below o The data consumer application end point MUST be able to identify the OPES processors that have acted on an application message. o The data consumer application end point SHOULD be able to identify OPES services (including callout services) that were performed on request/responses that are part of an application message. o TBD o TBD For a given trace, an OPES entity involved in handling the corresponding application message is "traceable" or "traced" if information about it appears in that trace. OPES entities have different levels of traceability requirements. Specifically, o An OPES system MUST be traceable o An OPES processor SHOULD be traceable o An OPES service MAY be traceable I need feedback from the WG on this issue. Please send your remark ASAP Abbie ------_=_NextPart_001_01C36D9E.25E30080 Content-Type: text/html [opes-end-comm]: What is traceable in an OPES Flow?

Hi,

I am working my way through the tracing draft.
The next issue is section 2.1 "What is traceable in an OPES Flow?"

The section is below


  o  The data consumer application end point MUST be able to identify
      the OPES processors that have acted on an application message.

   o  The data consumer application end point SHOULD be able to identify
      OPES services (including callout services) that were performed on
      request/responses that are part of an application message.

   o  TBD

   o  TBD

   For a given trace, an OPES entity involved in handling the
   corresponding application message is "traceable" or "traced" if
   information about it appears in that trace. OPES entities have
   different levels of traceability requirements. Specifically,

   o  An OPES system MUST be traceable

   o  An OPES processor SHOULD be traceable

   o  An OPES service MAY be traceable

I need feedback from the WG on this issue. Please send your remark ASAP

Abbie

------_=_NextPart_001_01C36D9E.25E30080-- From owner-ietf-openproxy@mail.imc.org Thu Aug 28 16:19:44 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15256 for ; Thu, 28 Aug 2003 16:19:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sTFE-0006C4-00 for opes-archive@ietf.org; Thu, 28 Aug 2003 16:19:48 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19sTFD-0006Bx-00 for opes-archive@ietf.org; Thu, 28 Aug 2003 16:19:47 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SJxXgc095310 for ; Thu, 28 Aug 2003 12:59:33 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7SJxXQG095309 for ietf-openproxy-bks; Thu, 28 Aug 2003 12:59:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SJxWgc095295 for ; Thu, 28 Aug 2003 12:59:32 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7SJxRU25383 for ; Thu, 28 Aug 2003 15:59:27 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Aug 2003 15:59:28 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD75406BC54DB@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: OPES WG Subject: [end points comm] Section : 7.4 Tracing scenarios and examples: N eed volunteers for the text Date: Thu, 28 Aug 2003 15:59:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36D9E.E2464FE8" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C36D9E.E2464FE8 Content-Type: text/plain All, I need volunteers to help in supplying text for section 7.4 Tracing scenarios and examples. It will be useful to resuse the same examples that help define OPES System ( I know about the OPES Domain story, but I did not bite yet...) Abbie ------_=_NextPart_001_01C36D9E.E2464FE8 Content-Type: text/html Message
All,
 
I need volunteers to help in supplying text for section 7.4 Tracing scenarios and examples.
 
 
It will be useful to resuse the same examples that help define OPES System ( I know about the OPES Domain story, but I did not bite yet...)
 
 
Abbie
 
------_=_NextPart_001_01C36D9E.E2464FE8-- From owner-ietf-openproxy@mail.imc.org Thu Aug 28 17:00:23 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18599 for ; Thu, 28 Aug 2003 17:00:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sTsY-0006zc-00 for opes-archive@ietf.org; Thu, 28 Aug 2003 17:00:26 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19sTsX-0006zZ-00 for opes-archive@ietf.org; Thu, 28 Aug 2003 17:00:26 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKc0gc097879 for ; Thu, 28 Aug 2003 13:38:00 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7SKc0Vi097878 for ietf-openproxy-bks; Thu, 28 Aug 2003 13:38:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKbwgc097872 for ; Thu, 28 Aug 2003 13:37:58 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7SKc0qF077857; Thu, 28 Aug 2003 14:38:00 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h7SKc0bF077856; Thu, 28 Aug 2003 14:38:00 -0600 (MDT) (envelope-from rousskov) Date: Thu, 28 Aug 2003 14:38:00 -0600 (MDT) From: Alex Rousskov To: Abbie Barbir cc: ietf-openproxy@imc.org Subject: Re: [opes-end-comm]: What is traceable in an OPES Flow? In-Reply-To: <87609AFB433BD5118D5E0002A52CD75406BC54C6@zcard0k6.ca.nortel.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD75406BC54C6@zcard0k6.ca.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Abbie, I would remove the entire old text you quoted and replace it with implementation requirements: For a given trace, an OPES entity involved in handling the corresponding application message is "traceable" or "traced" if information about it appears in that trace. OPES entities have different levels of traceability requirements. Specifically, o An OPES system MUST add its entry to the trace. o An OPES processor SHOULD add its entry to the trace. o An OPES service MAY add its entry to the trace. An OPES entity MAY manage trace entries of entities it controls(?). For example, an OPES processor may add and/or remove callout service entries. The above needs further polishing of course. The main point is that we should have specific implementation requirements in this draft, and reduce abstract talk about what end points would like to see in the trace. In other words, describe how to build the trace, spend less time (and no RFC 2919 keywords!) on why we want the trace to look like that. Make all rationale explanations clearly non-normative. HTH, Alex. On Thu, 28 Aug 2003, Abbie Barbir wrote: > Hi, > > I am working my way through the tracing draft. > The next issue is section 2.1 "What is traceable in an OPES Flow?" > > The section is below > > > o The data consumer application end point MUST be able to identify > the OPES processors that have acted on an application message. > > o The data consumer application end point SHOULD be able to identify > OPES services (including callout services) that were performed on > request/responses that are part of an application message. > > o TBD > > o TBD > > For a given trace, an OPES entity involved in handling the > corresponding application message is "traceable" or "traced" if > information about it appears in that trace. OPES entities have > different levels of traceability requirements. Specifically, > > o An OPES system MUST be traceable > > o An OPES processor SHOULD be traceable > > o An OPES service MAY be traceable > > I need feedback from the WG on this issue. Please send your remark ASAP > > Abbie > From owner-ietf-openproxy@mail.imc.org Thu Aug 28 17:01:39 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18723 for ; Thu, 28 Aug 2003 17:01:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sTtn-00070z-00 for opes-archive@ietf.org; Thu, 28 Aug 2003 17:01:43 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19sTtm-00070t-00 for opes-archive@ietf.org; Thu, 28 Aug 2003 17:01:42 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKgQgc098328 for ; Thu, 28 Aug 2003 13:42:26 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7SKgQPI098327 for ietf-openproxy-bks; Thu, 28 Aug 2003 13:42:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7SKgPgc098317 for ; Thu, 28 Aug 2003 13:42:25 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7SKgEt15744; Thu, 28 Aug 2003 16:42:14 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Aug 2003 16:42:15 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD75406BC5562@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov Cc: ietf-openproxy@imc.org Subject: RE: [opes-end-comm]: What is traceable in an OPES Flow? Date: Thu, 28 Aug 2003 16:42:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36DA4.DCFF16B8" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C36DA4.DCFF16B8 Content-Type: text/plain Alex, Agree, This is why I did the cut/Paste. We need input from everyone here, please Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Thursday, August 28, 2003 4:38 PM > To: Barbir, Abbie [CAR:1A11:EXCH] > Cc: ietf-openproxy@imc.org > Subject: Re: [opes-end-comm]: What is traceable in an OPES Flow? > > > Abbie, > > I would remove the entire old text you quoted and replace it > with implementation requirements: > > For a given trace, an OPES entity involved in handling the > corresponding application message is "traceable" or "traced" if > information about it appears in that trace. OPES entities have > different levels of traceability requirements. Specifically, > > o An OPES system MUST add its entry to the trace. > > o An OPES processor SHOULD add its entry to the trace. > > o An OPES service MAY add its entry to the trace. > > An OPES entity MAY manage trace entries of entities it > controls(?). For example, an OPES processor may add > and/or remove callout service entries. > > The above needs further polishing of course. The main point > is that we should have specific implementation requirements > in this draft, and reduce abstract talk about what end points > would like to see in the trace. In other words, describe how > to build the trace, spend less time (and no RFC 2919 > keywords!) on why we want the trace to look like that. Make > all rationale explanations clearly non-normative. > > HTH, > > Alex. > > > On Thu, 28 Aug 2003, Abbie Barbir wrote: > > > Hi, > > > > I am working my way through the tracing draft. > > The next issue is section 2.1 "What is traceable in an OPES Flow?" > > > > The section is below > > > > > > o The data consumer application end point MUST be able > to identify > > the OPES processors that have acted on an application message. > > > > o The data consumer application end point SHOULD be > able to identify > > OPES services (including callout services) that were > performed on > > request/responses that are part of an application message. > > > > o TBD > > > > o TBD > > > > For a given trace, an OPES entity involved in handling the > > corresponding application message is "traceable" or "traced" if > > information about it appears in that trace. OPES entities have > > different levels of traceability requirements. Specifically, > > > > o An OPES system MUST be traceable > > > > o An OPES processor SHOULD be traceable > > > > o An OPES service MAY be traceable > > > > I need feedback from the WG on this issue. Please send your remark > > ASAP > > > > Abbie > > > ------_=_NextPart_001_01C36DA4.DCFF16B8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [opes-end-comm]: What is traceable in an OPES Flow?

Alex,

Agree, This is why I did the cut/Paste.

We need input from everyone here, please

Abbie


> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Thursday, August 28, 2003 4:38 PM
> To: Barbir, Abbie [CAR:1A11:EXCH]
> Cc: ietf-openproxy@imc.org
> Subject: Re: [opes-end-comm]: What is traceable = in an OPES Flow?
>
>
> Abbie,
>
> I would remove the entire old text you quoted = and replace it
> with implementation requirements:
>
>     For a given trace, an = OPES entity involved in handling the
>     corresponding = application message is "traceable" or "traced" = if
>     information about it = appears in that trace. OPES entities have
>     different levels of = traceability requirements. Specifically,
>
>     o  An OPES system = MUST add its entry to the trace.
>
>     o  An OPES = processor SHOULD add its entry to the trace.
>
>     o  An OPES service = MAY add its entry to the trace.
>
>     An OPES entity MAY = manage trace entries of entities it
>     controls(?). For = example, an OPES processor may add
>     and/or remove callout = service entries.
>
> The above needs further polishing of course. = The main point
> is that we should have specific implementation = requirements
> in this draft, and reduce abstract talk about = what end points
> would like to see in the trace. In other words, = describe how
> to build the trace, spend less time (and no RFC = 2919
> keywords!) on why we want the trace to look = like that. Make
> all rationale explanations clearly = non-normative.
>
> HTH,
>
> Alex.
>
>
> On Thu, 28 Aug 2003, Abbie Barbir wrote:
>
> > Hi,
> >
> > I am working my way through the tracing = draft.
> > The next issue is section 2.1 "What = is traceable in an OPES Flow?"
> >
> > The section is below
> >
> >
> >   o  The data consumer = application end point MUST be able
> to identify
> >       the = OPES processors that have acted on an application message.
> >
> >    o  The data = consumer application end point SHOULD be
> able to identify
> >       OPES = services (including callout services) that were
> performed on
> >       = request/responses that are part of an application message.
> >
> >    o  TBD
> >
> >    o  TBD
> >
> >    For a given trace, an = OPES entity involved in handling the
> >    corresponding = application message is "traceable" or "traced" = if
> >    information about it = appears in that trace. OPES entities have
> >    different levels of = traceability requirements. Specifically,
> >
> >    o  An OPES system = MUST be traceable
> >
> >    o  An OPES = processor SHOULD be traceable
> >
> >    o  An OPES service = MAY be traceable
> >
> > I need feedback from the WG on this issue. = Please send your remark
> > ASAP
> >
> > Abbie
> >
>

------_=_NextPart_001_01C36DA4.DCFF16B8-- From owner-ietf-openproxy@mail.imc.org Fri Aug 29 08:59:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20046 for ; Fri, 29 Aug 2003 08:59:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19siqY-0002XJ-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 08:59:22 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19siqX-0002XG-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 08:59:21 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TCcqgc071466 for ; Fri, 29 Aug 2003 05:38:52 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TCcqoP071465 for ietf-openproxy-bks; Fri, 29 Aug 2003 05:38:52 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from montage.altserver.com (montage.altserver.com [63.247.74.122]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TCcogc071460 for ; Fri, 29 Aug 2003 05:38:51 -0700 (PDT) (envelope-from info@utel.net) Received: from f02m-24-49.d0.club-internet.fr ([212.195.219.49] helo=jfc2.utel.net) by montage.altserver.com with esmtp (Exim 4.20) id 19siWa-00087y-Ih; Fri, 29 Aug 2003 05:38:45 -0700 Message-Id: <5.2.0.9.0.20030829143552.036e8af0@mail.utel.net> X-Sender: info+utel.net@mail.utel.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 29 Aug 2003 14:45:13 +0200 To: Alex Rousskov , Abbie Barbir From: jfcm Subject: Re: [opes-end-comm]: What is traceable in an OPES Flow? Cc: ietf-openproxy@imc.org In-Reply-To: References: <87609AFB433BD5118D5E0002A52CD75406BC54C6@zcard0k6.ca.nortel.com> <87609AFB433BD5118D5E0002A52CD75406BC54C6@zcard0k6.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - montage.altserver.com X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - utel.net Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Cute and approved with some questions. At 22:38 28/08/03, Alex Rousskov wrote: >I would remove the entire old text you quoted and replace it with >implementation requirements: > > For a given trace, an OPES entity involved in handling the > corresponding application message is "traceable" or "traced" if > information about it appears in that trace. OPES entities have > different levels of traceability requirements. Specifically, > > o An OPES system MUST add its entry to the trace. OK. > o An OPES processor SHOULD add its entry to the trace. OK. > o An OPES service MAY add its entry to the trace. OK. Would prefere SHOULD but real workd will tell. > An OPES entity MAY manage trace entries of entities it > controls(?). ? "it will be able to authoritatively document the tracing queries" > For example, an OPES processor may add > and/or remove callout service entries. "remove" or "screen"? >The above needs further polishing of course. The main point is that we >should have specific implementation requirements in this draft, and >reduce abstract talk about what end points would like to see in the >trace. In other words, describe how to build the trace, spend less >time (and no RFC 2919 keywords!) on why we want the trace to look like >that. Make all rationale explanations clearly non-normative. > >HTH, > >Alex. > > >On Thu, 28 Aug 2003, Abbie Barbir wrote: > > > Hi, > > > > I am working my way through the tracing draft. > > The next issue is section 2.1 "What is traceable in an OPES Flow?" > > > > The section is below > > > > > > o The data consumer application end point MUST be able to identify > > the OPES processors that have acted on an application message. > > > > o The data consumer application end point SHOULD be able to identify > > OPES services (including callout services) that were performed on > > request/responses that are part of an application message. > > > > o TBD > > > > o TBD > > > > For a given trace, an OPES entity involved in handling the > > corresponding application message is "traceable" or "traced" if > > information about it appears in that trace. OPES entities have > > different levels of traceability requirements. Specifically, > > > > o An OPES system MUST be traceable > > > > o An OPES processor SHOULD be traceable > > > > o An OPES service MAY be traceable > > > > I need feedback from the WG on this issue. Please send your remark ASAP > > > > Abbie > > > > > > >--- >Incoming mail is certified Virus Free. >Checked by AVG anti-virus system (http://www.grisoft.com). >Version: 6.0.512 / Virus Database: 309 - Release Date: 19/08/03 From owner-ietf-openproxy@mail.imc.org Fri Aug 29 11:39:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04186 for ; Fri, 29 Aug 2003 11:39:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19slLJ-0005k9-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 11:39:17 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19slLI-0005k2-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 11:39:16 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TFKbgc084202 for ; Fri, 29 Aug 2003 08:20:37 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TFKbHu084201 for ietf-openproxy-bks; Fri, 29 Aug 2003 08:20:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TFKZgc084196 for ; Fri, 29 Aug 2003 08:20:35 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7TFKZqF004247; Fri, 29 Aug 2003 09:20:35 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h7TFKZDJ004246; Fri, 29 Aug 2003 09:20:35 -0600 (MDT) (envelope-from rousskov) Date: Fri, 29 Aug 2003 09:20:35 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: Re: [opes-end-comm]: What is traceable in an OPES Flow? In-Reply-To: <5.2.0.9.0.20030829143552.036e8af0@mail.utel.net> Message-ID: References: <87609AFB433BD5118D5E0002A52CD75406BC54C6@zcard0k6.ca.nortel.com> <87609AFB433BD5118D5E0002A52CD75406BC54C6@zcard0k6.ca.nortel.com> <5.2.0.9.0.20030829143552.036e8af0@mail.utel.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 29 Aug 2003, jfcm wrote: > > An OPES entity MAY manage trace entries of entities it > > controls(?). > > ? "it will be able to authoritatively document > the tracing queries" > > > For example, an OPES processor may add > > and/or remove callout service entries. > The intent behind the above two sentences is to allow "higher level" entities to manage traces for or on bahalf of "lower level" entities. For example, if an OPES processor uses 100 tiny callout services, the processor may be configured to remove all callout service entries from the trace and just insert its own entry (to keep the trace reasonably small). Another example is when an OPES processor knows that a callout service does not trace itself and adds a callout service trace entry for that service. Similarly, an OPES system may designate an OPES processor to remove all tracing entries and ad a single system entry. I am not sure what you mean by "documenting tracing queries". Do we talk about "tracing queries" at all anywhere? What are they? > "remove" or "screen"? To me, "screen" means "looking at something with the intent to remove". "remove" sounds more direct in this context. Perhaps I misunderstood your question. Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Fri Aug 29 11:50:20 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05199 for ; Fri, 29 Aug 2003 11:50:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19slW6-00060J-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 11:50:26 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19slW5-00060F-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 11:50:25 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TFX6gc084572 for ; Fri, 29 Aug 2003 08:33:06 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TFX64I084571 for ietf-openproxy-bks; Fri, 29 Aug 2003 08:33:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TFX4gc084565 for ; Fri, 29 Aug 2003 08:33:05 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03513; Fri, 29 Aug 2003 11:32:59 -0400 (EDT) Message-Id: <200308291532.LAA03513@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-opes-ocp-core-01.txt Date: Fri, 29 Aug 2003 11:32:59 -0400 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF. Title : OPES Callout Protocol Core Author(s) : A. Rousskov Filename : draft-ietf-opes-ocp-core-01.txt Pages : 55 Date : 2003-8-29 This document specifies Open Pluggable Edge Services (OPES) Callout Protocol (OCP). OCP is an application-agnostic protocol that facilitates exchange of application messages between an OPES processor and a callout server, for the purpose of adaptation of application messages at the callout server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-ocp-core-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-opes-ocp-core-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-opes-ocp-core-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-29113740.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-ocp-core-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-ocp-core-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-29113740.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Fri Aug 29 11:51:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05298 for ; Fri, 29 Aug 2003 11:51:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19slWu-00061L-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 11:51:16 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19slWt-00061I-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 11:51:15 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TFX9gc084581 for ; Fri, 29 Aug 2003 08:33:09 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TFX9aZ084580 for ietf-openproxy-bks; Fri, 29 Aug 2003 08:33:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TFX8gc084575 for ; Fri, 29 Aug 2003 08:33:09 -0700 (PDT) (envelope-from nsyracus@cnri.reston.va.us) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03529; Fri, 29 Aug 2003 11:33:03 -0400 (EDT) Message-Id: <200308291533.LAA03529@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-opes-iab-01.txt Date: Fri, 29 Aug 2003 11:33:03 -0400 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF. Title : OPES Treatment of IAB Considerations Author(s) : A. Barbir, A. Rousskov Filename : draft-ietf-opes-iab-01.txt Pages : 26 Date : 2003-8-29 IETF Internet Architecture Board (IAB) expressed nine architecture-level considerations when Open Pluggable Edge Services (OPES) working group was being chartered at the IETF. The working group was chartered under the condition that IAB considerations were addressed by the group. This document describes how OPES addresses those considerations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-iab-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-opes-iab-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-opes-iab-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-29113750.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-iab-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-iab-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-29113750.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Fri Aug 29 12:11:28 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08391 for ; Fri, 29 Aug 2003 12:11:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19slqX-0006lE-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 12:11:34 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19slqX-0006lB-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 12:11:33 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TFsWgc085500 for ; Fri, 29 Aug 2003 08:54:32 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TFsWN8085499 for ietf-openproxy-bks; Fri, 29 Aug 2003 08:54:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TFsUgc085492 for ; Fri, 29 Aug 2003 08:54:30 -0700 (PDT) (envelope-from markus@mhof.com) Received: from mhof.com (unknown[135.104.20.69](misconfigured sender)) by comcast.net (sccrmhc13) with SMTP id <2003082915542601600qh48he> (Authid: mhofmann); Fri, 29 Aug 2003 15:54:26 +0000 Message-ID: <3F4F7737.1040708@mhof.com> Date: Fri, 29 Aug 2003 11:54:31 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: [opes-end-comm]: What is traceable in an OPES Flow? References: <87609AFB433BD5118D5E0002A52CD75406BC54C6@zcard0k6.ca.nortel.com> <87609AFB433BD5118D5E0002A52CD75406BC54C6@zcard0k6.ca.nortel.com> <5.2.0.9.0.20030829143552.036e8af0@mail.utel.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > The intent behind the above two sentences is to allow "higher level" > entities to manage traces for or on bahalf of "lower level" entities. > For example, if an OPES processor uses 100 tiny callout services, the > processor may be configured to remove all callout service entries from > the trace and just insert its own entry (to keep the trace reasonably > small). It seems to me, however, that in this case, the OPES processor must still be able to identify those 100 tiny callout services when a user inquiry arrives later on. It's not sufficient just to know "yes, I did something to the message and a several services were executed". It's necessary to know exactly which services were executed. How else would someone be able to solve possible problems? This should be spelled out in the document. It might be a local matter on how this is achieved - one might decide to maintain the necessary state (well, I probably wouldn't opt for that option), or maybe the executed services get somehow encoded/encrypted in the trace entry itself... -Markus From owner-ietf-openproxy@mail.imc.org Fri Aug 29 12:11:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08501 for ; Fri, 29 Aug 2003 12:11:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19slr2-0006nK-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 12:12:04 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19slr1-0006nH-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 12:12:03 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TFtsgc085609 for ; Fri, 29 Aug 2003 08:55:54 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TFtsCp085608 for ietf-openproxy-bks; Fri, 29 Aug 2003 08:55:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TFtqgc085602 for ; Fri, 29 Aug 2003 08:55:52 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7TFtqqF005064; Fri, 29 Aug 2003 09:55:52 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h7TFtpgp005063; Fri, 29 Aug 2003 09:55:51 -0600 (MDT) (envelope-from rousskov) Date: Fri, 29 Aug 2003 09:55:51 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: Re: moving along on rules language In-Reply-To: <20030822140828.168c71e3.mrose@dbc.mtview.ca.us> Message-ID: References: <20030822115516.4abe1229.mrose@dbc.mtview.ca.us> <20030822140828.168c71e3.mrose@dbc.mtview.ca.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 22 Aug 2003, Marshall Rose wrote: > great. if your confident with an alternative approach, put an > initial document together and submit it. i don't want to forestall > alternatives, but we need to be wrapping things up. I hope to submit an alternative draft for WG review by Tuesday. > (we also need that other document you were working on.) It is in the IESG queue. Alex. From owner-ietf-openproxy@mail.imc.org Fri Aug 29 12:53:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13332 for ; Fri, 29 Aug 2003 12:53:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19smVX-00014k-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 12:53:55 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19smVW-00014W-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 12:53:54 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TGZngc089376 for ; Fri, 29 Aug 2003 09:35:49 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TGZnTx089375 for ietf-openproxy-bks; Fri, 29 Aug 2003 09:35:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TGZmgc089370 for ; Fri, 29 Aug 2003 09:35:48 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7TGZnqF006069; Fri, 29 Aug 2003 10:35:49 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h7TGZnmt006068; Fri, 29 Aug 2003 10:35:49 -0600 (MDT) (envelope-from rousskov) Date: Fri, 29 Aug 2003 10:35:49 -0600 (MDT) From: Alex Rousskov To: OPES WG Subject: Re: [opes-end-comm]: What is traceable in an OPES Flow? In-Reply-To: <3F4F7737.1040708@mhof.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD75406BC54C6@zcard0k6.ca.nortel.com> <87609AFB433BD5118D5E0002A52CD75406BC54C6@zcard0k6.ca.nortel.com> <5.2.0.9.0.20030829143552.036e8af0@mail.utel.net> <3F4F7737.1040708@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 29 Aug 2003, Markus Hofmann wrote: > Alex Rousskov wrote: > > > The intent behind the above two sentences is to allow "higher > > level" entities to manage traces for or on bahalf of "lower level" > > entities. For example, if an OPES processor uses 100 tiny callout > > services, the processor may be configured to remove all callout > > service entries from the trace and just insert its own entry (to > > keep the trace reasonably small). > > It seems to me, however, that in this case, the OPES processor must > still be able to identify those 100 tiny callout services when a > user inquiry arrives later on. It's not sufficient just to know > "yes, I did something to the message and a several services were > executed". It's necessary to know exactly which services were > executed. How else would someone be able to solve possible problems? The above is indeed desirable but on a MAY level: - The OPES processor may have a fixed configuration so it can always answer your question without any extra information in the trace. - The OPES processor may insert a [coded] summary of the 100 services applied so that it can answer your question with more (but perhaps incomplete) information about 100 services. - The user will most likely not understand and not care what those 100 tiny services are. We cannot demand that every service is documented sufficiently enough that every reasonable human being understands what it does. * It is the job of the OPES processor to solve problems. Let's not tell it how. It is the right of the other side to complain about problems. Let's give it sufficient tools to do so. What is sufficient? Whatever the trace builder considers sufficient (because it is the builder that is responsible for decoding the trace details and solving the problem)! A System MUST be traced so that the other side always knows who to complain, regardless of what the trace builder considered "sufficient". The first three arguments are just examples of why anything above MAY level would not make much sense when we are talking about something as poorly scoped as an OPES service. The last argument is the most important one, IMO. It is the cornerstone of what I would consider a good tracing approach in an OPES context. The trace is a trouble ticket ready for submission to a known address. The trace in itself is not necessarily a detailed or clear description of what has happened. We are not dealing with two "equal" sides communicating with one another. Our sides have very different view of the problem domain. Let's make it easy for a side to complain. Let's leave troubleshooting specifics to the troubleshooter since there are so many different ones that we cannot even enumerate them. > This should be spelled out in the document. Yes, of course, but that's Abbie's job :-). > It might be a local matter on how this is achieved - one might > decide to maintain the necessary state (well, I probably wouldn't > opt for that option), or maybe the executed services get somehow > encoded/encrypted in the trace entry itself... Exactly. Alex. From owner-ietf-openproxy@mail.imc.org Fri Aug 29 12:55:36 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13555 for ; Fri, 29 Aug 2003 12:55:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19smXG-000182-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 12:55:42 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19smXG-00017z-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 12:55:42 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TGc3gc089437 for ; Fri, 29 Aug 2003 09:38:03 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TGc31Q089436 for ietf-openproxy-bks; Fri, 29 Aug 2003 09:38:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mx03.forces.gc.ca (mx03.forces.gc.ca [131.137.245.203]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TGc1gc089431 for ; Fri, 29 Aug 2003 09:38:03 -0700 (PDT) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 228F020660E for ; Fri, 29 Aug 2003 12:36:14 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19slRr-0007aZ-9N for ietf-announce-list@asgard.ietf.org; Fri, 29 Aug 2003 11:46:03 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19slFL-0006lP-Bv for all-ietf@asgard.ietf.org; Fri, 29 Aug 2003 11:33:07 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03513; Fri, 29 Aug 2003 11:32:59 -0400 (EDT) Message-Id: <200308291532.LAA03513@ietf.org> To: IETF-Announce: ; Cc: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-opes-ocp-core-01.txt Date: Fri, 29 Aug 2003 11:32:59 -0400 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+32216_905313217420027_2724005518" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --MIMEStream=_0+32216_905313217420027_2724005518 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF. Title : OPES Callout Protocol Core Author(s) : A. Rousskov Filename : draft-ietf-opes-ocp-core-01.txt Pages : 55 Date : 2003-8-29 This document specifies Open Pluggable Edge Services (OPES) Callout Protocol (OCP). OCP is an application-agnostic protocol that facilitates exchange of application messages between an OPES processor and a callout server, for the purpose of adaptation of application messages at the callout server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-ocp-core-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-opes-ocp-core-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-opes-ocp-core-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --MIMEStream=_0+32216_905313217420027_2724005518 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+129720_52603492317700_2621029572" --MIMEStream=_1+129720_52603492317700_2621029572 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-29113740.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-ocp-core-01.txt --MIMEStream=_1+129720_52603492317700_2621029572 Content-Type: Message/External-body; name="draft-ietf-opes-ocp-core-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-29113740.I-D@ietf.org> --MIMEStream=_1+129720_52603492317700_2621029572-- --MIMEStream=_0+32216_905313217420027_2724005518-- From owner-ietf-openproxy@mail.imc.org Fri Aug 29 12:58:14 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10599 for ; Fri, 29 Aug 2003 12:33:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sm3x-0007AB-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 12:25:25 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19sm3w-0007A8-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 12:25:24 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TG91gc086095 for ; Fri, 29 Aug 2003 09:09:01 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TG91Fu086094 for ietf-openproxy-bks; Fri, 29 Aug 2003 09:09:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TG90gc086087 for ; Fri, 29 Aug 2003 09:09:00 -0700 (PDT) (envelope-from markus@mhof.com) Received: from mhof.com (unknown[135.104.20.69](misconfigured sender)) by comcast.net (sccrmhc11) with SMTP id <2003082916085601100ppe44e> (Authid: mhofmann); Fri, 29 Aug 2003 16:08:56 +0000 Message-ID: <3F4F7A9C.3040807@mhof.com> Date: Fri, 29 Aug 2003 12:09:00 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Optional Notification? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi, in addition to the points Abbie already mentioned, we also need to discuss the notion of having optional notifications being sent - This was something briefly mentioned at the Vienna meeting. We already agreed that notifications should *not* be sent per default per message (scalability problems - notification aggregation was mentioned as possible approach to overcome this). An idea might be to specify sort of a flag that would allow endpoints to signal that they want to receive an explicit notification if an OPES service is applied to this specific message. This would allow endpoints to do some (random?) probes. The flag could possibly also include how the notification should be sent (e.g. via email, or by issuing an HTTP request, or....) Any thoughts? -Markus > Hi, > > I am working my way through the tracing draft. > The next issue is section 2.1 "What is traceable in an OPES Flow?" > > The section is below > > > o The data consumer application end point MUST be able to identify > the OPES processors that have acted on an application message. > > o The data consumer application end point SHOULD be able to identify > OPES services (including callout services) that were performed on > request/responses that are part of an application message. > > o TBD > > o TBD > > For a given trace, an OPES entity involved in handling the > corresponding application message is "traceable" or "traced" if > information about it appears in that trace. OPES entities have > different levels of traceability requirements. Specifically, > > o An OPES system MUST be traceable > > o An OPES processor SHOULD be traceable > > o An OPES service MAY be traceable > > I need feedback from the WG on this issue. Please send your remark ASAP > > Abbie > From owner-ietf-openproxy@mail.imc.org Fri Aug 29 13:01:19 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14158 for ; Fri, 29 Aug 2003 13:01:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19smcn-0001GJ-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 13:01:25 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19smcm-0001G9-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 13:01:24 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TGj5gc089688 for ; Fri, 29 Aug 2003 09:45:05 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TGj5Hp089687 for ietf-openproxy-bks; Fri, 29 Aug 2003 09:45:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from drakken.dbc.mtview.ca.us ([65.125.189.56]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TGj3gc089682 for ; Fri, 29 Aug 2003 09:45:04 -0700 (PDT) (envelope-from mrose@dbc.mtview.ca.us) Received: from drakken.dbc.mtview.ca.us (localhost [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.9/8.12.9) with SMTP id h7TGinj1000948; Fri, 29 Aug 2003 09:44:49 -0700 (PDT) Date: Fri, 29 Aug 2003 09:44:49 -0700 From: Marshall Rose To: Alex Rousskov Cc: OPES WG Subject: Re: moving along on rules language Message-Id: <20030829094449.5556b105.mrose@dbc.mtview.ca.us> In-Reply-To: References: <20030822115516.4abe1229.mrose@dbc.mtview.ca.us> <20030822140828.168c71e3.mrose@dbc.mtview.ca.us> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.11claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > great. if your confident with an alternative approach, put an > > initial document together and submit it. i don't want to forestall > > alternatives, but we need to be wrapping things up. > > I hope to submit an alternative draft for WG review by Tuesday. good. > > (we also need that other document you were working on.) > > It is in the IESG queue. IESG queue? i don't think so. you meant to say that you sent it to the I-D repository, right? /mtr From owner-ietf-openproxy@mail.imc.org Fri Aug 29 13:02:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14407 for ; Fri, 29 Aug 2003 13:02:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19smeL-0001Ks-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 13:03:01 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19smeK-0001Ko-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 13:03:00 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TGkIgc089770 for ; Fri, 29 Aug 2003 09:46:18 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TGkHRC089769 for ietf-openproxy-bks; Fri, 29 Aug 2003 09:46:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TGkGgc089762 for ; Fri, 29 Aug 2003 09:46:16 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7TGkHqF006412; Fri, 29 Aug 2003 10:46:17 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h7TGkH7H006411; Fri, 29 Aug 2003 10:46:17 -0600 (MDT) (envelope-from rousskov) Date: Fri, 29 Aug 2003 10:46:17 -0600 (MDT) From: Alex Rousskov To: OPES Group Subject: Re: Optional Notification? In-Reply-To: <3F4F7A9C.3040807@mhof.com> Message-ID: References: <3F4F7A9C.3040807@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 29 Aug 2003, Markus Hofmann wrote: > in addition to the points Abbie already mentioned, we also need to > discuss the notion of having optional notifications being sent - > This was something briefly mentioned at the Vienna meeting. > > We already agreed that notifications should *not* be sent per > default per message (scalability problems - notification aggregation > was mentioned as possible approach to overcome this). > > An idea might be to specify sort of a flag that would allow > endpoints to signal that they want to receive an explicit > notification if an OPES service is applied to this specific message. > This would allow endpoints to do some (random?) probes. The flag > could possibly also include how the notification should be sent > (e.g. via email, or by issuing an HTTP request, or....) We can say that the value of this optional flag/field is a URI that identifies notification method plus parameters. If a processor understands the method, it would be able to further decode the field and send a notification. This way, we only have to document the field name and format for ever application protocol. We do not have to invent the notification protocol. For example, we can document the following HTTP header: OPES-Notify: URI *(pname=pvalue) On the other hand, the utility of the above approach is going to be rather low. An alternative is for whoever writes the notification protocol is to document the above approach OR invent its own, specific to that protocol. For example, My-OPES-Notify: foo=bar q=0.5 (which simply moves URI standardization problem to the header name standardization problem). HTH, Alex. From owner-ietf-openproxy@mail.imc.org Fri Aug 29 13:07:16 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14991 for ; Fri, 29 Aug 2003 13:07:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19smiY-0001Sh-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 13:07:22 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19smiX-0001Sd-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 13:07:21 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TGp1gc090025 for ; Fri, 29 Aug 2003 09:51:01 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TGp1Ma090024 for ietf-openproxy-bks; Fri, 29 Aug 2003 09:51:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TGoxgc090016 for ; Fri, 29 Aug 2003 09:50:59 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7TGoxqF006438; Fri, 29 Aug 2003 10:50:59 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h7TGoxem006437; Fri, 29 Aug 2003 10:50:59 -0600 (MDT) (envelope-from rousskov) Date: Fri, 29 Aug 2003 10:50:59 -0600 (MDT) From: Alex Rousskov To: Marshall Rose cc: OPES WG Subject: Re: moving along on rules language In-Reply-To: <20030829094449.5556b105.mrose@dbc.mtview.ca.us> Message-ID: References: <20030822115516.4abe1229.mrose@dbc.mtview.ca.us> <20030822140828.168c71e3.mrose@dbc.mtview.ca.us> <20030829094449.5556b105.mrose@dbc.mtview.ca.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 29 Aug 2003, Marshall Rose wrote: > > > (we also need that other document you were working on.) > > > > It is in the IESG queue. > > IESG queue? i don't think so. you meant to say that you sent it to > the I-D repository, right? Probably. I just send to internet-drafts@ietf.org without knowing what it is called. I know the reaction is not immediate or 100% automated so I called it an IESG queue. Sorry for using the wrong term. The drafts have been published this morning. Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Fri Aug 29 13:07:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15031 for ; Fri, 29 Aug 2003 13:07:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19smjA-0001Tu-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 13:08:00 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19smj9-0001To-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 13:07:59 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TGpvgc090072 for ; Fri, 29 Aug 2003 09:51:57 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TGpvaB090071 for ietf-openproxy-bks; Fri, 29 Aug 2003 09:51:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TGpugc090065 for ; Fri, 29 Aug 2003 09:51:56 -0700 (PDT) (envelope-from markus@mhof.com) Received: from mhof.com (unknown[135.104.20.69](misconfigured sender)) by comcast.net (sccrmhc12) with SMTP id <20030829165142012001sc1ee> (Authid: mhofmann); Fri, 29 Aug 2003 16:51:42 +0000 Message-ID: <3F4F84A2.6000001@mhof.com> Date: Fri, 29 Aug 2003 12:51:46 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: [opes-end-comm]: What is traceable in an OPES Flow? References: <87609AFB433BD5118D5E0002A52CD75406BC54C6@zcard0k6.ca.nortel.com> <87609AFB433BD5118D5E0002A52CD75406BC54C6@zcard0k6.ca.nortel.com> <5.2.0.9.0.20030829143552.036e8af0@mail.utel.net> <3F4F7737.1040708@mhof.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'd suggest that the document includes and explains these thoughts and reasons - just along the lines of your comments below. It will help to decide whether we've consesus or not. -Markus Alex Rousskov wrote: > On Fri, 29 Aug 2003, Markus Hofmann wrote: > > >>Alex Rousskov wrote: >> >> >>>The intent behind the above two sentences is to allow "higher >>>level" entities to manage traces for or on bahalf of "lower level" >>>entities. For example, if an OPES processor uses 100 tiny callout >>>services, the processor may be configured to remove all callout >>>service entries from the trace and just insert its own entry (to >>>keep the trace reasonably small). >> >>It seems to me, however, that in this case, the OPES processor must >>still be able to identify those 100 tiny callout services when a >>user inquiry arrives later on. It's not sufficient just to know >>"yes, I did something to the message and a several services were >>executed". It's necessary to know exactly which services were >>executed. How else would someone be able to solve possible problems? > > > The above is indeed desirable but on a MAY level: > > - The OPES processor may have a fixed configuration > so it can always answer your question without > any extra information in the trace. > > - The OPES processor may insert a [coded] summary > of the 100 services applied so that it can > answer your question with more (but perhaps > incomplete) information about 100 services. > > - The user will most likely not understand and > not care what those 100 tiny services are. We > cannot demand that every service is documented > sufficiently enough that every reasonable > human being understands what it does. > > * It is the job of the OPES processor to solve > problems. Let's not tell it how. It is the right > of the other side to complain about problems. > Let's give it sufficient tools to do so. What is > sufficient? Whatever the trace builder considers > sufficient (because it is the builder that is > responsible for decoding the trace details and > solving the problem)! A System MUST be traced > so that the other side always knows who to > complain, regardless of what the trace builder > considered "sufficient". > > The first three arguments are just examples of why anything above MAY > level would not make much sense when we are talking about something as > poorly scoped as an OPES service. > > The last argument is the most important one, IMO. It is the > cornerstone of what I would consider a good tracing approach in an > OPES context. The trace is a trouble ticket ready for submission to a > known address. The trace in itself is not necessarily a detailed or > clear description of what has happened. > > We are not dealing with two "equal" sides communicating with one > another. Our sides have very different view of the problem domain. > Let's make it easy for a side to complain. Let's leave troubleshooting > specifics to the troubleshooter since there are so many different ones > that we cannot even enumerate them. > > >>This should be spelled out in the document. > > > Yes, of course, but that's Abbie's job :-). > > >>It might be a local matter on how this is achieved - one might >>decide to maintain the necessary state (well, I probably wouldn't >>opt for that option), or maybe the executed services get somehow >>encoded/encrypted in the trace entry itself... > > > Exactly. > > Alex. > From owner-ietf-openproxy@mail.imc.org Fri Aug 29 13:22:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15978 for ; Fri, 29 Aug 2003 13:22:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19smxh-0001hv-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 13:23:01 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19smxg-0001hn-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 13:23:00 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TH1Sgc090552 for ; Fri, 29 Aug 2003 10:01:28 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TH1Sv5090551 for ietf-openproxy-bks; Fri, 29 Aug 2003 10:01:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TH1Qgc090533 for ; Fri, 29 Aug 2003 10:01:26 -0700 (PDT) (envelope-from markus@mhof.com) Received: from mhof.com (unknown[135.104.20.69](misconfigured sender)) by comcast.net (sccrmhc12) with SMTP id <20030829170123012001s62je> (Authid: mhofmann); Fri, 29 Aug 2003 17:01:23 +0000 Message-ID: <3F4F86E7.3040009@mhof.com> Date: Fri, 29 Aug 2003 13:01:27 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Optional Notification? References: <3F4F7A9C.3040807@mhof.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > We can say that the value of this optional flag/field is a URI that > identifies notification method plus parameters. If a processor > understands the method, it would be able to further decode the field > and send a notification. This way, we only have to document the field > name and format for ever application protocol. We do not have to > invent the notification protocol. Exactly, that's what I had in mind. > For example, we can document the > following HTTP header: > > OPES-Notify: URI *(pname=pvalue) > > On the other hand, the utility of the above approach is going to be > rather low. An alternative is for whoever writes the notification > protocol is to document the above approach OR invent its own, specific > to that protocol. For example, > > My-OPES-Notify: foo=bar q=0.5 > > (which simply moves URI standardization problem to the header name > standardization problem). I don't think we want to start specifying our own notification protocol. Using the URI option for now, but allowing someone to specify - if needed - a notification protocol later on might be the way to go. Anyone else any thoughts? Should we include "OPES-Notify:" HTTP header in our OCP/HTTP bindings document? -Markus From owner-ietf-openproxy@mail.imc.org Fri Aug 29 13:38:32 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17095 for ; Fri, 29 Aug 2003 13:38:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19snCo-0001xx-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 13:38:38 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19snCn-0001xu-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 13:38:37 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7THPwgc095492 for ; Fri, 29 Aug 2003 10:25:58 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7THPwsI095490 for ietf-openproxy-bks; Fri, 29 Aug 2003 10:25:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7THPtgc095470 for ; Fri, 29 Aug 2003 10:25:55 -0700 (PDT) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id h7THPuqF007260; Fri, 29 Aug 2003 11:25:56 -0600 (MDT) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id h7THPuIE007259; Fri, 29 Aug 2003 11:25:56 -0600 (MDT) (envelope-from rousskov) Date: Fri, 29 Aug 2003 11:25:56 -0600 (MDT) From: Alex Rousskov To: Markus Hofmann cc: OPES WG Subject: Re: [opes-end-comm]: What is traceable in an OPES Flow? In-Reply-To: <3F4F84A2.6000001@mhof.com> Message-ID: References: <87609AFB433BD5118D5E0002A52CD75406BC54C6@zcard0k6.ca.nortel.com> <87609AFB433BD5118D5E0002A52CD75406BC54C6@zcard0k6.ca.nortel.com> <5.2.0.9.0.20030829143552.036e8af0@mail.utel.net> <3F4F7737.1040708@mhof.com> <3F4F84A2.6000001@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 29 Aug 2003, Markus Hofmann wrote: > I'd suggest that the document includes and explains these thoughts > and reasons - just along the lines of your comments below. It will > help to decide whether we've consesus or not. Yes, as a separate non-normative "Rationale" section or subsection. While I do want to document our rationale, I am afraid that if it is intermingled with normative text than people will find a mistake or a loophole in our reasoning and will use that as a reason to violate a related MUST. This common problem is especially dangerous when we talk about controversial and poorly defined concepts as OPES. Alex. > Alex Rousskov wrote: > > > On Fri, 29 Aug 2003, Markus Hofmann wrote: > > > > > >>Alex Rousskov wrote: > >> > >> > >>>The intent behind the above two sentences is to allow "higher > >>>level" entities to manage traces for or on bahalf of "lower level" > >>>entities. For example, if an OPES processor uses 100 tiny callout > >>>services, the processor may be configured to remove all callout > >>>service entries from the trace and just insert its own entry (to > >>>keep the trace reasonably small). > >> > >>It seems to me, however, that in this case, the OPES processor must > >>still be able to identify those 100 tiny callout services when a > >>user inquiry arrives later on. It's not sufficient just to know > >>"yes, I did something to the message and a several services were > >>executed". It's necessary to know exactly which services were > >>executed. How else would someone be able to solve possible problems? > > > > > > The above is indeed desirable but on a MAY level: > > > > - The OPES processor may have a fixed configuration > > so it can always answer your question without > > any extra information in the trace. > > > > - The OPES processor may insert a [coded] summary > > of the 100 services applied so that it can > > answer your question with more (but perhaps > > incomplete) information about 100 services. > > > > - The user will most likely not understand and > > not care what those 100 tiny services are. We > > cannot demand that every service is documented > > sufficiently enough that every reasonable > > human being understands what it does. > > > > * It is the job of the OPES processor to solve > > problems. Let's not tell it how. It is the right > > of the other side to complain about problems. > > Let's give it sufficient tools to do so. What is > > sufficient? Whatever the trace builder considers > > sufficient (because it is the builder that is > > responsible for decoding the trace details and > > solving the problem)! A System MUST be traced > > so that the other side always knows who to > > complain, regardless of what the trace builder > > considered "sufficient". > > > > The first three arguments are just examples of why anything above MAY > > level would not make much sense when we are talking about something as > > poorly scoped as an OPES service. > > > > The last argument is the most important one, IMO. It is the > > cornerstone of what I would consider a good tracing approach in an > > OPES context. The trace is a trouble ticket ready for submission to a > > known address. The trace in itself is not necessarily a detailed or > > clear description of what has happened. > > > > We are not dealing with two "equal" sides communicating with one > > another. Our sides have very different view of the problem domain. > > Let's make it easy for a side to complain. Let's leave troubleshooting > > specifics to the troubleshooter since there are so many different ones > > that we cannot even enumerate them. > > > > > >>This should be spelled out in the document. > > > > > > Yes, of course, but that's Abbie's job :-). > > > > > >>It might be a local matter on how this is achieved - one might > >>decide to maintain the necessary state (well, I probably wouldn't > >>opt for that option), or maybe the executed services get somehow > >>encoded/encrypted in the trace entry itself... > > > > > > Exactly. > > > > Alex. > > > > From owner-ietf-openproxy@mail.imc.org Fri Aug 29 15:04:16 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24049 for ; Fri, 29 Aug 2003 15:04:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19soXk-0003zP-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 15:04:20 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19soXj-0003zM-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 15:04:19 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TIpsgc001316 for ; Fri, 29 Aug 2003 11:51:54 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TIpsYY001315 for ietf-openproxy-bks; Fri, 29 Aug 2003 11:51:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TIprgc001302 for ; Fri, 29 Aug 2003 11:51:53 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7TIpgK28918; Fri, 29 Aug 2003 14:51:42 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Aug 2003 14:51:42 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD75406BC5C11@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , OPES WG Subject: RE: [opes-end-comm]: What is traceable in an OPES Flow? Date: Fri, 29 Aug 2003 14:51:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36E5E.94D97EAE" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C36E5E.94D97EAE Content-Type: text/plain Hi, Agreed on all Abbie > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Friday, August 29, 2003 12:36 PM > To: OPES WG > Subject: Re: [opes-end-comm]: What is traceable in an OPES Flow? > > > > > On Fri, 29 Aug 2003, Markus Hofmann wrote: > > > Alex Rousskov wrote: > > > > > The intent behind the above two sentences is to allow > "higher level" > > > entities to manage traces for or on bahalf of "lower level" > > > entities. For example, if an OPES processor uses 100 tiny callout > > > services, the processor may be configured to remove all callout > > > service entries from the trace and just insert its own entry (to > > > keep the trace reasonably small). > > > > It seems to me, however, that in this case, the OPES processor must > > still be able to identify those 100 tiny callout services > when a user > > inquiry arrives later on. It's not sufficient just to know > "yes, I did > > something to the message and a several services were > executed". It's > > necessary to know exactly which services were executed. How > else would > > someone be able to solve possible problems? > > The above is indeed desirable but on a MAY level: > > - The OPES processor may have a fixed configuration > so it can always answer your question without > any extra information in the trace. > > - The OPES processor may insert a [coded] summary > of the 100 services applied so that it can > answer your question with more (but perhaps > incomplete) information about 100 services. > > - The user will most likely not understand and > not care what those 100 tiny services are. We > cannot demand that every service is documented > sufficiently enough that every reasonable > human being understands what it does. > > * It is the job of the OPES processor to solve > problems. Let's not tell it how. It is the right > of the other side to complain about problems. > Let's give it sufficient tools to do so. What is > sufficient? Whatever the trace builder considers > sufficient (because it is the builder that is > responsible for decoding the trace details and > solving the problem)! A System MUST be traced > so that the other side always knows who to > complain, regardless of what the trace builder > considered "sufficient". > > The first three arguments are just examples of why anything > above MAY level would not make much sense when we are talking > about something as poorly scoped as an OPES service. > > The last argument is the most important one, IMO. It is the > cornerstone of what I would consider a good tracing approach > in an OPES context. The trace is a trouble ticket ready for > submission to a known address. The trace in itself is not > necessarily a detailed or clear description of what has happened. > > We are not dealing with two "equal" sides communicating with > one another. Our sides have very different view of the > problem domain. Let's make it easy for a side to complain. > Let's leave troubleshooting specifics to the troubleshooter > since there are so many different ones that we cannot even > enumerate them. > > > This should be spelled out in the document. > > Yes, of course, but that's Abbie's job :-). > > > It might be a local matter on how this is achieved - one > might decide > > to maintain the necessary state (well, I probably wouldn't opt for > > that option), or maybe the executed services get somehow > > encoded/encrypted in the trace entry itself... > > Exactly. > > Alex. > > ------_=_NextPart_001_01C36E5E.94D97EAE Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [opes-end-comm]: What is traceable in an OPES Flow?

Hi,

Agreed on all

Abbie


> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Friday, August 29, 2003 12:36 PM
> To: OPES WG
> Subject: Re: [opes-end-comm]: What is traceable = in an OPES Flow?
>
>
>
>
> On Fri, 29 Aug 2003, Markus Hofmann = wrote:
>
> > Alex Rousskov wrote:
> >
> > > The intent behind the above two = sentences is to allow
> "higher level"
> > > entities to manage traces for or on = bahalf of "lower level"
> > > entities. For example, if an OPES = processor uses 100 tiny callout
> > > services, the processor may be = configured to remove all callout
> > > service entries from the trace and = just insert its own entry (to
> > > keep the trace reasonably = small).
> >
> > It seems to me, however, that in this = case, the OPES processor must
> > still be able to identify those 100 tiny = callout services
> when a user
> > inquiry arrives later on. It's not = sufficient just to know
> "yes, I did
> > something to the message and a several = services were
> executed". It's
> > necessary to know exactly which services = were executed. How
> else would
> > someone be able to solve possible = problems?
>
> The above is indeed desirable but on a MAY = level:
>
>       - The OPES = processor may have a fixed configuration
>         so it can = always answer your question without
>         any extra = information in the trace.
>
>       - The OPES = processor may insert a [coded] summary
>         of the = 100 services applied so that it can
>         answer = your question with more (but perhaps
>         = incomplete) information about 100 services.
>
>       - The user will = most likely not understand and
>         not care = what those 100 tiny services are. We
>         cannot = demand that every service is documented
>         = sufficiently enough that every reasonable
>         human = being understands what it does.
>
>       * It is the job = of the OPES processor to solve
>         problems. = Let's not tell it how. It is the right
>         of the = other side to complain about problems.
>         Let's = give it sufficient tools to do so. What is
>         = sufficient? Whatever the trace builder considers
>         = sufficient (because it is the builder that is
>         = responsible for decoding the trace details and
>         solving = the problem)! A System MUST be traced
>         so that = the other side always knows who to
>         complain, = regardless of what the trace builder
>         = considered "sufficient".
>
> The first three arguments are just examples of = why anything
> above MAY level would not make much sense when = we are talking
> about something as poorly scoped as an OPES = service.
>
> The last argument is the most important one, = IMO. It is the
> cornerstone of what I would consider a good = tracing approach
> in an OPES context. The trace is a trouble = ticket ready for
> submission to a known address. The trace in = itself is not
> necessarily a detailed or clear description of = what has happened.
>
> We are not dealing with two "equal" = sides communicating with
> one another. Our sides have very different view = of the
> problem domain. Let's make it easy for a side = to complain.
> Let's leave troubleshooting specifics to the = troubleshooter
> since there are so many different ones that we = cannot even
> enumerate them.
>
> > This should be spelled out in the = document.
>
> Yes, of course, but that's Abbie's job = :-).
>
> > It might be a local matter on how this is = achieved - one
> might decide
> > to maintain the necessary state (well, I = probably wouldn't opt for
> > that option), or maybe the executed = services get somehow
> > encoded/encrypted in the trace entry = itself...
>
> Exactly.
>
> Alex.
>
>

------_=_NextPart_001_01C36E5E.94D97EAE-- From owner-ietf-openproxy@mail.imc.org Fri Aug 29 15:04:37 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24090 for ; Fri, 29 Aug 2003 15:04:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19soY5-0003zo-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 15:04:41 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19soY4-0003zl-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 15:04:40 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TIrXgc001387 for ; Fri, 29 Aug 2003 11:53:33 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TIrX1J001386 for ietf-openproxy-bks; Fri, 29 Aug 2003 11:53:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TIrWgc001375 for ; Fri, 29 Aug 2003 11:53:32 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7TIrQL09983; Fri, 29 Aug 2003 14:53:26 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Aug 2003 14:53:26 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD75406BC5C14@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Markus Hofmann , OPES Group Subject: RE: Optional Notification? Date: Fri, 29 Aug 2003 14:53:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36E5E.D3719B88" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C36E5E.D3719B88 Content-Type: text/plain All, I think we can mention that, but I really doubt that we should get involved in it. Aptional Notification in my opnion should be out of scope. Abbie > -----Original Message----- > From: Markus Hofmann [mailto:markus@mhof.com] > Sent: Friday, August 29, 2003 1:01 PM > To: OPES Group > Subject: Re: Optional Notification? > > > > Alex Rousskov wrote: > > > We can say that the value of this optional flag/field is a URI that > > identifies notification method plus parameters. If a processor > > understands the method, it would be able to further decode > the field > > and send a notification. This way, we only have to document > the field > > name and format for ever application protocol. We do not have to > > invent the notification protocol. > > Exactly, that's what I had in mind. > > > For example, we can document the > > following HTTP header: > > > > OPES-Notify: URI *(pname=pvalue) > > > > On the other hand, the utility of the above approach is going to be > > rather low. An alternative is for whoever writes the notification > > protocol is to document the above approach OR invent its > own, specific > > to that protocol. For example, > > > > My-OPES-Notify: foo=bar q=0.5 > > > > (which simply moves URI standardization problem to the header name > > standardization problem). > > I don't think we want to start specifying our own notification > protocol. Using the URI option for now, but allowing someone to > specify - if needed - a notification protocol later on might be the > way to go. > > Anyone else any thoughts? Should we include "OPES-Notify:" > HTTP header > in our OCP/HTTP bindings document? > > -Markus > > ------_=_NextPart_001_01C36E5E.D3719B88 Content-Type: text/html RE: Optional Notification?

All,

I think we can mention that, but I really doubt that we should get involved in it.

Aptional Notification in my opnion should be out of scope.

Abbie


> -----Original Message-----
> From: Markus Hofmann [mailto:markus@mhof.com]
> Sent: Friday, August 29, 2003 1:01 PM
> To: OPES Group
> Subject: Re: Optional Notification?
>
>
>
> Alex Rousskov wrote:
>
> > We can say that the value of this optional flag/field is a URI that
> > identifies notification method plus parameters. If a processor
> > understands the method, it would be able to further decode
> the field
> > and send a notification. This way, we only have to document
> the field
> > name and format for ever application protocol. We do not have to
> > invent the notification protocol.
>
> Exactly, that's what I had in mind.
>
> > For example, we can document the
> > following HTTP header:
> >
> >     OPES-Notify: URI *(pname=pvalue)
> >
> > On the other hand, the utility of the above approach is going to be
> > rather low. An alternative is for whoever writes the notification
> > protocol is to document the above approach OR invent its
> own, specific
> > to that protocol. For example,
> >
> >     My-OPES-Notify: foo=bar q=0.5
> >
> > (which simply moves URI standardization problem to the header name
> > standardization problem).
>
> I don't think we want to start specifying our own notification
> protocol. Using the URI option for now, but allowing someone to
> specify - if needed - a notification protocol later on might be the
> way to go.
>
> Anyone else any thoughts? Should we include "OPES-Notify:"
> HTTP header
> in our OCP/HTTP bindings document?
>
> -Markus
>
>

------_=_NextPart_001_01C36E5E.D3719B88-- From owner-ietf-openproxy@mail.imc.org Fri Aug 29 15:07:47 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24559 for ; Fri, 29 Aug 2003 15:07:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sob9-000445-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 15:07:51 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19sob8-00043v-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 15:07:50 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TIsCgc001418 for ; Fri, 29 Aug 2003 11:54:12 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TIsCKw001417 for ietf-openproxy-bks; Fri, 29 Aug 2003 11:54:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TIsBgc001407 for ; Fri, 29 Aug 2003 11:54:11 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7TIs0L10019; Fri, 29 Aug 2003 14:54:00 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Aug 2003 14:54:00 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD75406BC5C17@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Alex Rousskov , Markus Hofmann Cc: OPES WG Subject: RE: [opes-end-comm]: What is traceable in an OPES Flow? Date: Fri, 29 Aug 2003 14:53:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36E5E.E7A9ACC6" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C36E5E.E7A9ACC6 Content-Type: text/plain > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Friday, August 29, 2003 1:26 PM > To: Markus Hofmann > Cc: OPES WG > Subject: Re: [opes-end-comm]: What is traceable in an OPES Flow? > > > > > On Fri, 29 Aug 2003, Markus Hofmann wrote: > > > I'd suggest that the document includes and explains these > thoughts and > > reasons - just along the lines of your comments below. It > will help to > > decide whether we've consesus or not. > > Yes, as a separate non-normative "Rationale" section or > subsection. While I do want to document our rationale, I am > afraid that if it is intermingled with normative text than > people will find a mistake or a loophole in our reasoning and > will use that as a reason to violate a related MUST. This > common problem is especially dangerous when we talk about > controversial and poorly defined concepts as OPES. > > Alex. > --------Abbie Agreed ------_=_NextPart_001_01C36E5E.E7A9ACC6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [opes-end-comm]: What is traceable in an OPES Flow?

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@measure= ment-factory.com]
> Sent: Friday, August 29, 2003 1:26 PM
> To: Markus Hofmann
> Cc: OPES WG
> Subject: Re: [opes-end-comm]: What is traceable = in an OPES Flow?
>
>
>
>
> On Fri, 29 Aug 2003, Markus Hofmann = wrote:
>
> > I'd suggest that the document includes and = explains these
> thoughts and
> > reasons - just along the lines of your = comments below. It
> will help to
> > decide whether we've consesus or = not.
>
> Yes, as a separate non-normative = "Rationale" section or
> subsection. While I do want to document our = rationale, I am
> afraid that if it is intermingled with = normative text than
> people will find a mistake or a loophole in our = reasoning and
> will use that as a reason to violate a related = MUST. This
> common problem is especially dangerous when we = talk about
> controversial and poorly defined concepts as = OPES.
>
> Alex.
>
--------Abbie

Agreed

------_=_NextPart_001_01C36E5E.E7A9ACC6-- From owner-ietf-openproxy@mail.imc.org Fri Aug 29 15:31:25 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27587 for ; Fri, 29 Aug 2003 15:31:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19soy2-0004nW-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 15:31:30 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19soy1-0004nR-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 15:31:29 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TJIhgc004961 for ; Fri, 29 Aug 2003 12:18:44 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TJIhid004960 for ietf-openproxy-bks; Fri, 29 Aug 2003 12:18:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TJIggc004939 for ; Fri, 29 Aug 2003 12:18:42 -0700 (PDT) (envelope-from markus@mhof.com) Received: from mhof.com (unknown[135.104.20.69]) by comcast.net (sccrmhc13) with SMTP id <2003082919183801600cub07e> (Authid: mhofmann); Fri, 29 Aug 2003 19:18:38 +0000 Message-ID: <3F4FA712.206@mhof.com> Date: Fri, 29 Aug 2003 15:18:42 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Abbie Barbir CC: OPES Group Subject: Re: Optional Notification? References: <87609AFB433BD5118D5E0002A52CD75406BC5C14@zcard0k6.ca.nortel.com> In-Reply-To: <87609AFB433BD5118D5E0002A52CD75406BC5C14@zcard0k6.ca.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Abbie Barbir wrote: > I think we can mention that, but I really doubt that we should get involved > in it. > > Aptional Notification in my opnion should be out of scope. I agree in that we do *not* want to take on the specification of a separate notification protocol, but getting the necessary hooks into HTTP/OCP binding is very well in scope (e.g. using an additional HTTP header as discussed). -Markus From owner-ietf-openproxy@mail.imc.org Fri Aug 29 16:16:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01313 for ; Fri, 29 Aug 2003 16:16:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19spfC-0005wq-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 16:16:06 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 19spfB-0005wk-00 for opes-archive@ietf.org; Fri, 29 Aug 2003 16:16:06 -0400 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TK3Igc007432 for ; Fri, 29 Aug 2003 13:03:18 -0700 (PDT) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h7TK3IwP007431 for ietf-openproxy-bks; Fri, 29 Aug 2003 13:03:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h7TK3Hgc007417 for ; Fri, 29 Aug 2003 13:03:17 -0700 (PDT) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7TK39K17783; Fri, 29 Aug 2003 16:03:09 -0400 (EDT) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Aug 2003 16:03:09 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD75406BC5D0A@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Markus Hofmann Cc: OPES Group Subject: RE: Optional Notification? Date: Fri, 29 Aug 2003 16:03:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36E68.908C390E" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C36E68.908C390E Content-Type: text/plain Hi, yes, no problem. But we should be very clear on the boundary. I really do not want to start an something that is optional that ends being fully in scope and a ticket for a new disaster. abbie > -----Original Message----- > From: Markus Hofmann [mailto:markus@mhof.com] > Sent: Friday, August 29, 2003 3:19 PM > To: Barbir, Abbie [CAR:1A11:EXCH] > Cc: OPES Group > Subject: Re: Optional Notification? > > > Abbie Barbir wrote: > > > I think we can mention that, but I really doubt that we should get > > involved in it. > > > > Aptional Notification in my opnion should be out of scope. > > I agree in that we do *not* want to take on the specification of a > separate notification protocol, but getting the necessary hooks into > HTTP/OCP binding is very well in scope (e.g. using an additional HTTP > header as discussed). > > -Markus > > ------_=_NextPart_001_01C36E68.908C390E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Optional Notification?

Hi,
yes, no problem.
But we should be very clear on the boundary.
I really do not want to start an something that is = optional that ends being fully in scope and a ticket for a new = disaster.

abbie

> -----Original Message-----
> From: Markus Hofmann [mailto:markus@mhof.com]
> Sent: Friday, August 29, 2003 3:19 PM
> To: Barbir, Abbie [CAR:1A11:EXCH]
> Cc: OPES Group
> Subject: Re: Optional Notification?
>
>
> Abbie Barbir wrote:
>
> > I think we can mention that, but I really = doubt that we should get
> > involved in it.
> >
> > Aptional Notification in my opnion should = be out of scope.
>
> I agree in that we do *not* want to take on the = specification of a
> separate notification protocol, but getting the = necessary hooks into
> HTTP/OCP binding is very well in scope (e.g. = using an additional HTTP
> header as discussed).
>
> -Markus
>
>

------_=_NextPart_001_01C36E68.908C390E--