From subs-reminder@imc.org Tue Jan 6 21:49:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17452 for ; Tue, 6 Jan 2004 21:49:45 -0500 (EST) From: subs-reminder@imc.org Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ae3lS-0000OK-00 for opes-archive@ietf.org; Tue, 06 Jan 2004 21:49:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ae3jW-0000F7-00 for opes-archive@ietf.org; Tue, 06 Jan 2004 21:47:47 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Ae3hc-00006K-00 for opes-archive@ietf.org; Tue, 06 Jan 2004 21:45:48 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i072jjib007263 for ; Tue, 6 Jan 2004 18:45:45 -0800 (PST) (envelope-from subs-reminder@imc.org) Received: (from root@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i072jjsX007262; Tue, 6 Jan 2004 18:45:45 -0800 (PST) Date: Tue, 6 Jan 2004 18:45:45 -0800 (PST) Message-Id: <200401070245.i072jjsX007262@above.proper.com> To: opes-archive@ietf.org Subject: [[184274768]] Subscription to ietf-openproxy for opes-archive@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=LINES_OF_YELLING,NO_REAL_NAME autolearn=no version=2.60 Greetings. This message is a periodic reminder that opes-archive@ietf.org is subscribed to the ietf-openproxy mailing list. *** SEE BELOW: PLEASE DO NOT RESPOND TO THIS MESSAGE. *** There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-openproxy mailing list, you do not need to do anything. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ietf-openproxy-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "opes-archive@ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ietf-openproxy@mail.imc.org Wed Jan 7 13:50:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24415 for ; Wed, 7 Jan 2004 13:50:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeIku-0005AH-00 for opes-archive@ietf.org; Wed, 07 Jan 2004 13:50:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeIiz-00056i-00 for opes-archive@ietf.org; Wed, 07 Jan 2004 13:48:13 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AeIhc-00053Q-00 for opes-archive@ietf.org; Wed, 07 Jan 2004 13:46:48 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07Ia8ib066648 for ; Wed, 7 Jan 2004 10:36:08 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i07Ia8av066647 for ietf-openproxy-bks; Wed, 7 Jan 2004 10:36:08 -0800 (PST) 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.10/8.12.8) with ESMTP id i07Ia6ib066641 for ; Wed, 7 Jan 2004 10:36:07 -0800 (PST) (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.10/8.12.10) with ESMTP id i07Ia7xl028202 for ; Wed, 7 Jan 2004 13:36:08 -0500 (EST) 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 i07IZx0C049882 for ; Wed, 7 Jan 2004 13:35:59 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i07IZwMl003763 for ; Wed, 7 Jan 2004 13:35:59 -0500 (EST) Message-ID: <3FFC51D2.9080303@mhof.com> Date: Wed, 07 Jan 2004 13:37:06 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Status and next IETF Meeting 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: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks, quick update on document status. We still have two open documents, namely - HTTP Adaptation with OPES -> We're expecting to issue WGLC on an updated version shortly. - Rules Language "P" -> We're discussing possible options with our AD. We're also waiting for more details from the IESG review of draft-ietf-opes-authorization-02, which we'll have to modify once the feedback has been provided. All other documents currently await action either from IESG, AD, or RFC Editor. You can check document status also at https://datatracker.ietf.org/public/pidtracker.cgi. Given the situation, we intend to *not* have a WG meeting at the next IETF in Seoul. We've to focus on wrapping up the open documents, and then will start discussing a possible re-charter. -Markus From owner-ietf-openproxy@mail.imc.org Wed Jan 7 15:19:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28913 for ; Wed, 7 Jan 2004 15:19:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeK9d-0001G2-00 for opes-archive@ietf.org; Wed, 07 Jan 2004 15:19:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeK4E-000153-00 for opes-archive@ietf.org; Wed, 07 Jan 2004 15:14:15 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AeK2R-0000wM-00 for opes-archive@ietf.org; Wed, 07 Jan 2004 15:12:23 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07JwPib070248 for ; Wed, 7 Jan 2004 11:58:25 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i07JwPnk070247 for ietf-openproxy-bks; Wed, 7 Jan 2004 11:58:25 -0800 (PST) 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.10/8.12.8) with ESMTP id i07JwNib070242 for ; Wed, 7 Jan 2004 11:58:23 -0800 (PST) (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 i07JwNk3063161; Wed, 7 Jan 2004 12:58:23 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i07JwNWU063160; Wed, 7 Jan 2004 12:58:23 -0700 (MST) (envelope-from rousskov) Date: Wed, 7 Jan 2004 12:58:23 -0700 (MST) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: Re: Status and next IETF Meeting In-Reply-To: <3FFC51D2.9080303@mhof.com> Message-ID: References: <3FFC51D2.9080303@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: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, 7 Jan 2004, Markus Hofmann wrote: > Given the situation, we intend to *not* have a WG meeting at the > next IETF in Seoul. We've to focus on wrapping up the open > documents, and then will start discussing a possible re-charter. FWIW, I support the intention to have no meeting in Seoul. Alex. From owner-ietf-openproxy@mail.imc.org Wed Jan 7 18:17:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12866 for ; Wed, 7 Jan 2004 18:17:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeMvT-0007Jt-00 for opes-archive@ietf.org; Wed, 07 Jan 2004 18:17:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeMsM-0007DF-00 for opes-archive@ietf.org; Wed, 07 Jan 2004 18:14:11 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AeMqV-00078u-00 for opes-archive@ietf.org; Wed, 07 Jan 2004 18:12:15 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07Mq0ib079219 for ; Wed, 7 Jan 2004 14:52:00 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i07Mq0ng079218 for ietf-openproxy-bks; Wed, 7 Jan 2004 14:52:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07Mpxib079212 for ; Wed, 7 Jan 2004 14:51:59 -0800 (PST) (envelope-from jgw@cisco.com) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 07 Jan 2004 14:59:40 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i07MpsVM009507 for ; Wed, 7 Jan 2004 14:51:54 -0800 (PST) Received: from cisco.com ([171.71.129.39]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id APA89725; Wed, 7 Jan 2004 14:51:53 -0800 (PST) Message-ID: <3FFC8D88.7020506@cisco.com> Date: Wed, 07 Jan 2004 17:51:52 -0500 From: "John G. Waclawsky" Reply-To: jgw@cisco.com Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: An opes usage question. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I have been looking over the opes drafts and trying to understand the efficiency of a distributed opes framework with a large volume of activity (and also trying to gauge how useful it would be for time dependent service execution activities). Consider an opes service where application data is transformed (or adapted) in some way. My question is, If I send the data flow to a callout server to perform some opes service task (or a string of call out servers), does the data always have to return to the data dispatcher at the opes data processor that directed the flow to the call out server in the first place (an ancillary question is: can just trace data and billing information only be sent back)?. Basically, will an opes framework allow the use of a piplining approach where once the service is complete at the call out server, the adapted application data can be forwarded directly to the data producer or data consumer (what ever the case may be)? Any information, advice or council would be greatly appreciated. Thanks. Regards John From owner-ietf-openproxy@mail.imc.org Wed Jan 7 19:16:03 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15220 for ; Wed, 7 Jan 2004 19:16:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeNqB-0002Gj-00 for opes-archive@ietf.org; Wed, 07 Jan 2004 19:15:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AeNmm-0002Bs-00 for opes-archive@ietf.org; Wed, 07 Jan 2004 19:12:28 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AeNlu-00026Z-00 for opes-archive@ietf.org; Wed, 07 Jan 2004 19:11:34 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07NuIib083772 for ; Wed, 7 Jan 2004 15:56:18 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i07NuIIq083771 for ietf-openproxy-bks; Wed, 7 Jan 2004 15:56:18 -0800 (PST) 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.10/8.12.8) with ESMTP id i07NuGib083765 for ; Wed, 7 Jan 2004 15:56:17 -0800 (PST) (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 i07Nttk3072720; Wed, 7 Jan 2004 16:55:55 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i07Ntt7p072719; Wed, 7 Jan 2004 16:55:55 -0700 (MST) (envelope-from rousskov) Date: Wed, 7 Jan 2004 16:55:55 -0700 (MST) From: Alex Rousskov To: "John G. Waclawsky" cc: OPES Group , Krishna Ramadas Subject: Re: An opes usage question. In-Reply-To: <3FFC8D88.7020506@cisco.com> Message-ID: References: <3FFC8D88.7020506@cisco.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: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 John, As far as I can see, your use case is 100% within the OPES scope. However, you are probably thinking at the protocol level and, hence, considering OCP protocol and not just OPES in general. If that is the case, please read on. Your use case is a case of two application proxies using OCP between each other: the data is pipelined via OCP from one application hop to another, possibly with some other data returning to the first hop. This use case has been discussed, but I do not think it was explicitly documented. OCP protocol can be used to do what you want. You will need to document and negotiate an OCP Core profile that specifies the details, including sending trace data and billing information back to the first proxy as an option. While doing that, you will need to be careful not to be confused by terminology that targets classic "callout" rather than classic "proxying" use cases. OCP protocol allows you to "pipeline" application messages very efficiently. It has a few features targeted at classic "callout" use cases, such as data preservation optimization. You will not need/use those. You can take OCP Core and document an application profile that changes OCP focus from callout to proxying. I cannot say whether OCP is the best protocol for your needs since I do not know the details of your environment. It may be a good candidate. Another option would be to use the native/original application protocol in one direction and return tracing/billing data via some other means. Please also see the following related message: http://www.imc.org/ietf-openproxy/mail-archive/msg02830.html It would be great if you can contribute your use case (and your OCP profile, if any) to OPES Framework. Please keep us posted on your progress and do not hesitate to discuss any related issues on this list. Thanks, Alex. On Wed, 7 Jan 2004, John G. Waclawsky wrote: > I have been looking over the opes drafts and trying to understand > the efficiency of a distributed opes framework with a large volume > of activity (and also trying to gauge how useful it would be for > time dependent service execution activities). Consider an opes > service where application data is transformed (or adapted) in some > way. My question is, If I send the data flow to a callout server to > perform some opes service task (or a string of call out servers), > does the data always have to return to the data dispatcher at the > opes data processor that directed the flow to the call out server in > the first place (an ancillary question is: can just trace data and > billing information only be sent back)?. Basically, will an opes > framework allow the use of a piplining approach where once the > service is complete at the call out server, the adapted application > data can be forwarded directly to the data producer or data consumer > (what ever the case may be)? Any information, advice or council > would be greatly appreciated. Thanks. Regards John From owner-ietf-openproxy@mail.imc.org Thu Jan 8 13:30:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05343 for ; Thu, 8 Jan 2004 13:30:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AeevR-0005CL-00 for opes-archive@ietf.org; Thu, 08 Jan 2004 13:30:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aeeta-00056f-00 for opes-archive@ietf.org; Thu, 08 Jan 2004 13:28:40 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Aees3-00051T-00 for opes-archive@ietf.org; Thu, 08 Jan 2004 13:27:03 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08IFPib011422 for ; Thu, 8 Jan 2004 10:15:26 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i08IFPWE011421 for ietf-openproxy-bks; Thu, 8 Jan 2004 10:15:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08IFOib011408 for ; Thu, 8 Jan 2004 10:15:24 -0800 (PST) (envelope-from jgw@cisco.com) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id i08IFIVM007741; Thu, 8 Jan 2004 10:15:18 -0800 (PST) Received: from cisco.com ([171.71.129.39]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id APB60836; Thu, 8 Jan 2004 10:15:17 -0800 (PST) Message-ID: <3FFD9E35.6080607@cisco.com> Date: Thu, 08 Jan 2004 13:15:17 -0500 From: "John G. Waclawsky" Reply-To: jgw@cisco.com Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Rousskov CC: OPES Group , Krishna Ramadas Subject: Re: An opes usage question. References: <3FFC8D88.7020506@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020608040402070003010309" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------020608040402070003010309 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Alex, thank you for your reply and the pointer. I agree with you that the use case I am interested in is not explicitly documented in the opes material. This gives the wrong impression, since all the examples show the data flows returning to the first hop data dispatcher. To restrict data flow in this way would be inefficient for high capacity applications and would tend to make the first hop a bottleneck. To be a little more specific on my use case and to make sure I understand your response let me add more detail. Fundamentally, I wish to have an "open" IETF network environment. The second requirement is speed in adaptation processing, so I am thinking that callout will be faster than using a proxy (maybe this is an incorrect assumption). I may be a little confused about the distinction between classic proxy and classic call out in this situation (this word proxy isn't even mentioned in the opes architecture document as a consideration). Also, I have a requirement to adapt a large volume of content for numerous devices. I expect that the volume of data will require a number of adaptation (call out) processors. I estimate 10 of them and therefore I would need load balancing as part of the solution for directing data to the call out servers (doing the adaptation). I am looking at Figure 3 in the opes architecture draft and considering a load balanced collection of ten call out servers. As I had mentioned previously, I'd like to have parallel pipeline approach where the adapted data from each of the opes call out server is simply forwarded on, directly to the producer or data consumer (what ever the case would be). In addition each of the opes call out servers would then send billing and trace data back to the load balancer (or another network location). Is it realistic to expect that this could this be accomplished within the opes framework? In fact a more fundamental question is the opes framework the best way to solve this problem and maintain an open system. I think this is what opes is all about. Thanks for your interest in this use case problem and the discussion. Regards John Alex Rousskov wrote: >John, > > As far as I can see, your use case is 100% within the OPES >scope. However, you are probably thinking at the protocol level and, >hence, considering OCP protocol and not just OPES in general. If that >is the case, please read on. > > Your use case is a case of two application proxies using OCP >between each other: the data is pipelined via OCP from one application >hop to another, possibly with some other data returning to the first >hop. This use case has been discussed, but I do not think it was >explicitly documented. > > OCP protocol can be used to do what you want. You will need to >document and negotiate an OCP Core profile that specifies the details, >including sending trace data and billing information back to the first >proxy as an option. While doing that, you will need to be careful not >to be confused by terminology that targets classic "callout" rather >than classic "proxying" use cases. > > OCP protocol allows you to "pipeline" application messages >very efficiently. It has a few features targeted at classic "callout" >use cases, such as data preservation optimization. You will not >need/use those. > > You can take OCP Core and document an application profile that >changes OCP focus from callout to proxying. I cannot say whether OCP >is the best protocol for your needs since I do not know the details of >your environment. It may be a good candidate. Another option would be >to use the native/original application protocol in one direction and >return tracing/billing data via some other means. > > Please also see the following related message: >http://www.imc.org/ietf-openproxy/mail-archive/msg02830.html > > > It would be great if you can contribute your use case (and >your OCP profile, if any) to OPES Framework. Please keep us posted on >your progress and do not hesitate to discuss any related issues on >this list. > >Thanks, > >Alex. > > >On Wed, 7 Jan 2004, John G. Waclawsky wrote: > > > >>I have been looking over the opes drafts and trying to understand >>the efficiency of a distributed opes framework with a large volume >>of activity (and also trying to gauge how useful it would be for >>time dependent service execution activities). Consider an opes >>service where application data is transformed (or adapted) in some >>way. My question is, If I send the data flow to a callout server to >>perform some opes service task (or a string of call out servers), >>does the data always have to return to the data dispatcher at the >>opes data processor that directed the flow to the call out server in >>the first place (an ancillary question is: can just trace data and >>billing information only be sent back)?. Basically, will an opes >>framework allow the use of a piplining approach where once the >>service is complete at the call out server, the adapted application >>data can be forwarded directly to the data producer or data consumer >>(what ever the case may be)? Any information, advice or council >>would be greatly appreciated. Thanks. Regards John >> >> > > > --------------020608040402070003010309 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Alex, thank you for your reply and the pointer. I agree with you that the use case I am interested in is not explicitly documented in the opes material. This gives the wrong impression, since all the examples show the data flows returning to the first hop data dispatcher. To restrict data flow in this way would be inefficient for high capacity applications and would tend to make the first hop a bottleneck.

To be a little more specific on my use case and to make sure I understand your response let me add more detail. Fundamentally, I wish to have an "open" IETF network environment. The second requirement is speed in adaptation processing, so I am thinking that callout will be faster than using a proxy (maybe this is an incorrect assumption). I may be a little confused about the distinction between classic proxy and classic call out in this situation (this word proxy isn't even mentioned in the opes architecture document as a consideration). Also, I have a requirement to adapt a large volume of content for numerous devices.

I expect that the volume of data will require a number of  adaptation (call out) processors. I estimate 10 of them and therefore I would need load balancing as part of the solution for directing data to the call out servers (doing the adaptation). I am looking at Figure 3 in the opes architecture draft and considering a load balanced collection of ten call out servers. As I had mentioned previously, I'd like to have parallel pipeline approach where the adapted data from each of the opes call out server is simply forwarded on, directly to the producer or data consumer (what ever the case would be). In addition each of the opes call out servers would then send billing and trace data back to the load balancer (or another network location). Is it realistic to expect that this could this be accomplished within the opes framework?  In fact a more fundamental question is the opes framework the best way to solve this problem and maintain an open system. I think this is what opes is all about.

Thanks for your interest in this use case problem and the discussion.
Regards  John

Alex Rousskov wrote:
John,

	As far as I can see, your use case is 100% within the OPES
scope. However, you are probably thinking at the protocol level and,
hence, considering OCP protocol and not just OPES in general. If that
is the case, please read on.

	Your use case is a case of two application proxies using OCP
between each other: the data is pipelined via OCP from one application
hop to another, possibly with some other data returning to the first
hop. This use case has been discussed, but I do not think it was
explicitly documented.

	OCP protocol can be used to do what you want. You will need to
document and negotiate an OCP Core profile that specifies the details,
including sending trace data and billing information back to the first
proxy as an option. While doing that, you will need to be careful not
to be confused by terminology that targets classic "callout" rather
than classic "proxying" use cases.

	OCP protocol allows you to "pipeline" application messages
very efficiently. It has a few features targeted at classic "callout"
use cases, such as data preservation optimization. You will not
need/use those.

	You can take OCP Core and document an application profile that
changes OCP focus from callout to proxying. I cannot say whether OCP
is the best protocol for your needs since I do not know the details of
your environment. It may be a good candidate. Another option would be
to use the native/original application protocol in one direction and
return tracing/billing data via some other means.

	Please also see the following related message:
http://www.imc.org/ietf-openproxy/mail-archive/msg02830.html


	It would be great if you can contribute your use case (and
your OCP profile, if any) to OPES Framework. Please keep us posted on
your progress and do not hesitate to discuss any related issues on
this list.

Thanks,

Alex.


On Wed, 7 Jan 2004, John G. Waclawsky wrote:

  
I have been looking over the opes drafts and trying to understand
the efficiency of a distributed opes framework with a large volume
of activity (and also trying to gauge how useful it would be for
time dependent service execution activities). Consider an opes
service where application data is transformed (or adapted) in some
way. My question is, If I send the data flow to a callout server to
perform some opes service task (or a string of call out servers),
does the data always have to return to the data dispatcher at the
opes data processor that directed the flow to the call out server in
the first place (an ancillary question is: can just trace data and
billing information only be sent back)?. Basically, will an opes
framework allow the use of a piplining approach where once the
service is complete at the call out server, the adapted application
data can be forwarded directly to the data producer or data consumer
(what ever the case may be)?  Any information, advice or council
would be greatly appreciated. Thanks. Regards John
--------------020608040402070003010309-- From owner-ietf-openproxy@mail.imc.org Thu Jan 8 15:26:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10439 for ; Thu, 8 Jan 2004 15:26:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aegjn-0003ob-00 for opes-archive@ietf.org; Thu, 08 Jan 2004 15:26:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aeghz-0003k9-00 for opes-archive@ietf.org; Thu, 08 Jan 2004 15:24:48 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AeghE-0003fL-00 for opes-archive@ietf.org; Thu, 08 Jan 2004 15:24:00 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08KClib018622 for ; Thu, 8 Jan 2004 12:12:47 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i08KClbo018621 for ietf-openproxy-bks; Thu, 8 Jan 2004 12:12:47 -0800 (PST) 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.10/8.12.8) with ESMTP id i08KCiib018614 for ; Thu, 8 Jan 2004 12:12:45 -0800 (PST) (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 i08KChk3019498; Thu, 8 Jan 2004 13:12:43 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i08KChdM019497; Thu, 8 Jan 2004 13:12:43 -0700 (MST) (envelope-from rousskov) Date: Thu, 8 Jan 2004 13:12:43 -0700 (MST) From: Alex Rousskov To: "John G. Waclawsky" cc: OPES Group , Krishna Ramadas Subject: Re: An opes usage question. In-Reply-To: <3FFD9E35.6080607@cisco.com> Message-ID: References: <3FFC8D88.7020506@cisco.com> <3FFD9E35.6080607@cisco.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: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, 8 Jan 2004, John G. Waclawsky wrote: > Alex, thank you for your reply and the pointer. I agree with you > that the use case I am interested in is not explicitly documented in > the opes material. This gives the wrong impression, since all the > examples show the data flows returning to the first hop data > dispatcher. To restrict data flow in this way would be inefficient > for high capacity applications and would tend to make the first hop > a bottleneck. John, You are misreading OPES architecture diagrams because you are thinking about a much "simpler" case than most diagrams attempt to document and, hence, you assign wrong roles to "boxes" that may not even exist in your environment. This is the architecture draft fault, not yours. Let me try to explain. Here is a "classic" OPES proxying case (horizontal lines are application data/protocols being proxied, proxies may be adapting data internally): Figure A. end -- proxy -- proxy -- ... -- end Here is a "classic" OPES callout case (vertical lines are callout data/protocols, proxy is not adapting data, callout servers may be adapting data): Figure B. end --- proxy --- end _________|__________ | | | | | | callout callout callout server server server A combination of the above is possible and common, of course. In a combined case, some proxies are adapting data internally and some use callout servers to adapt. In your particular case (the adapted data flows to the next hop), you do not have callout servers. You have proxies that adapt data internally. However, your case may not be a classic proxying case because you may want proxies to use a protocol that differs from the original application protocol (so that you can ship metadata and perhaps pipeline more efficiently). I will use curly (~) lines to show that new protocol below. You may also want to do some load balancing: Figure C. ~~~~~ proxy1 --- / end -- proxy ~~~~~~ proxy2 --- ?? end \ ~~~~~ proxyN --- I do not know how the proxies will get application data to the right "end", but it is not important for this discussion. Note that the curly path may use a completely new protocol (e.g., OCP) or can use a combination of the original application protocol to deliver data and some other protocol for metadata (billing, etc.) records. The above is OPES, but not a callout case. There are no callout servers, just proxies. Whether you want to use OCP for the curly path depends on what kind of data/metadata you want to exchange and what other protocols you have available. > To be a little more specific on my use case and to make sure I > understand your response let me add more detail. Fundamentally, I wish > to have an "open" IETF network environment. The second requirement is > speed in adaptation processing, so I am thinking that callout will be > faster than using a proxy (maybe this is an incorrect assumption). It's an incorrect question :-). Adaptations at the callout server can be as "fast" or as "slow" as adaptations performed internally at the proxy. The primary reason to use a callout server is to "outsource" (from business, development, support, logistics, legal, etc. points of view) adaptations. The primary reasons not to use a callout server are security and overheads of the data having to return back to the proxy. > I may be a little confused about the distinction between classic > proxy and classic call out in this situation (this word proxy isn't > even mentioned in the opes architecture document as a > consideration). I hope the above diagrams clarify the distinction. OPES processor is the term closest to the "proxy", I think. > Also, I have a requirement to adapt a large volume of content for > numerous devices. Both callout and builtin adaptations can handle large volumes of content. There are many factors at play here, from legal concerns to the kind of adaptation being performed. > I expect that the volume of data will require a number of adaptation > (call out) processors. I estimate 10 of them and therefore I would > need load balancing as part of the solution for directing data to > the call out servers (doing the adaptation). Load balancing can be done with both callout and proxying schemes. OPES mechanisms are usually per-message so any load balancing method that does not split individual application messages should work just fine. > I am looking at Figure 3 in the opes architecture draft and > considering a load balanced collection of ten call out servers. As I > had mentioned previously, I'd like to have parallel pipeline > approach where the adapted data from each of the opes call out > server is simply forwarded on, directly to the producer or data > consumer (what ever the case would be). The latter makes the adapter a proxy, not a callout server (by definition). See Figure C above. > In addition each of the opes call out servers would then send > billing and trace data back to the load balancer (or another network > location). Is it realistic to expect that this could this be > accomplished within the opes framework? It is. The only question is what protocol(s) you will use between your proxies (the curly lines in Figure C). > In fact a more fundamental question is the opes framework the best > way to solve this problem and maintain an open system. I think this > is what opes is all about. IMO, OPES framework accommodates, in principle, any intermediary adaptation. Thus, your problem is within the framework. However, the framework is not complete. It does not have ready-to-use tools for all possible intermediary adaptations. I hope that you will find OCP Core and OPES communications "tools" useful for your problems, but I lack information to tell your whether they are the best. The system is "open" if it uses "open standards". If current OPES tools are not right for you, and there are no better open tools, then we can work together, within the OPES Framework, on defining open standards (protocols and interfaces) that will solve your specific problem. Alex. From owner-ietf-openproxy@mail.imc.org Thu Jan 8 16:08:47 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12037 for ; Thu, 8 Jan 2004 16:08:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AehOU-0006K1-00 for opes-archive@ietf.org; Thu, 08 Jan 2004 16:08:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AehK1-00064Q-00 for opes-archive@ietf.org; Thu, 08 Jan 2004 16:04:06 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AehEp-0005p4-00 for opes-archive@ietf.org; Thu, 08 Jan 2004 15:58:43 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08KlKib022543 for ; Thu, 8 Jan 2004 12:47:20 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i08KlKA6022542 for ietf-openproxy-bks; Thu, 8 Jan 2004 12:47:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08KlJib022533 for ; Thu, 8 Jan 2004 12:47:19 -0800 (PST) (envelope-from jgw@cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 08 Jan 2004 12:54:48 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i08KlEGN024882; Thu, 8 Jan 2004 12:47:14 -0800 (PST) Received: from cisco.com ([171.71.129.39]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id APB81291; Thu, 8 Jan 2004 12:47:10 -0800 (PST) Message-ID: <3FFDC1CE.7060809@cisco.com> Date: Thu, 08 Jan 2004 15:47:10 -0500 From: "John G. Waclawsky" Reply-To: jgw@cisco.com Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Rousskov CC: OPES Group , Krishna Ramadas Subject: Re: An opes usage question. References: <3FFC8D88.7020506@cisco.com> <3FFD9E35.6080607@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030501070902080808030906" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------030501070902080808030906 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Alex, I very much appreciate your help and the additional information. I need a little time to digest this and think some more about my problem and opes "needs".... Thanks. Regards John Alex Rousskov wrote: >On Thu, 8 Jan 2004, John G. Waclawsky wrote: > > > >>Alex, thank you for your reply and the pointer. I agree with you >>that the use case I am interested in is not explicitly documented in >>the opes material. This gives the wrong impression, since all the >>examples show the data flows returning to the first hop data >>dispatcher. To restrict data flow in this way would be inefficient >>for high capacity applications and would tend to make the first hop >>a bottleneck. >> >> > >John, > > You are misreading OPES architecture diagrams because you are >thinking about a much "simpler" case than most diagrams attempt to >document and, hence, you assign wrong roles to "boxes" that may not >even exist in your environment. This is the architecture draft fault, >not yours. Let me try to explain. > >Here is a "classic" OPES proxying case (horizontal lines are >application data/protocols being proxied, proxies may be adapting data >internally): > > Figure A. > > end -- proxy -- proxy -- ... -- end > >Here is a "classic" OPES callout case (vertical lines are callout >data/protocols, proxy is not adapting data, callout servers may be >adapting data): > > Figure B. > > end --- proxy --- end > _________|__________ > | | | > | | | > callout callout callout > server server server > >A combination of the above is possible and common, of course. In a >combined case, some proxies are adapting data internally and some use >callout servers to adapt. > >In your particular case (the adapted data flows to the next hop), you >do not have callout servers. You have proxies that adapt data >internally. However, your case may not be a classic proxying case >because you may want proxies to use a protocol that differs from the >original application protocol (so that you can ship metadata and >perhaps pipeline more efficiently). I will use curly (~) lines to show >that new protocol below. You may also want to do some load balancing: > > Figure C. > > ~~~~~ proxy1 --- > / > end -- proxy ~~~~~~ proxy2 --- ?? end > \ > ~~~~~ proxyN --- > > >I do not know how the proxies will get application data to the right >"end", but it is not important for this discussion. > >Note that the curly path may use a completely new protocol (e.g., OCP) >or can use a combination of the original application protocol to >deliver data and some other protocol for metadata (billing, etc.) >records. > >The above is OPES, but not a callout case. There are no callout >servers, just proxies. Whether you want to use OCP for the curly path >depends on what kind of data/metadata you want to exchange and what >other protocols you have available. > > > >>To be a little more specific on my use case and to make sure I >>understand your response let me add more detail. Fundamentally, I wish >>to have an "open" IETF network environment. The second requirement is >>speed in adaptation processing, so I am thinking that callout will be >>faster than using a proxy (maybe this is an incorrect assumption). >> >> > >It's an incorrect question :-). Adaptations at the callout server can >be as "fast" or as "slow" as adaptations performed internally at the >proxy. The primary reason to use a callout server is to "outsource" >(from business, development, support, logistics, legal, etc. points of >view) adaptations. The primary reasons not to use a callout server are >security and overheads of the data having to return back to the proxy. > > > >>I may be a little confused about the distinction between classic >>proxy and classic call out in this situation (this word proxy isn't >>even mentioned in the opes architecture document as a >>consideration). >> >> > >I hope the above diagrams clarify the distinction. OPES processor is >the term closest to the "proxy", I think. > > > >>Also, I have a requirement to adapt a large volume of content for >>numerous devices. >> >> > >Both callout and builtin adaptations can handle large volumes of >content. There are many factors at play here, from legal concerns to >the kind of adaptation being performed. > > > >>I expect that the volume of data will require a number of adaptation >>(call out) processors. I estimate 10 of them and therefore I would >>need load balancing as part of the solution for directing data to >>the call out servers (doing the adaptation). >> >> > >Load balancing can be done with both callout and proxying schemes. >OPES mechanisms are usually per-message so any load balancing method >that does not split individual application messages should work just >fine. > > > >>I am looking at Figure 3 in the opes architecture draft and >>considering a load balanced collection of ten call out servers. As I >>had mentioned previously, I'd like to have parallel pipeline >>approach where the adapted data from each of the opes call out >>server is simply forwarded on, directly to the producer or data >>consumer (what ever the case would be). >> >> > >The latter makes the adapter a proxy, not a callout server (by >definition). See Figure C above. > > > >>In addition each of the opes call out servers would then send >>billing and trace data back to the load balancer (or another network >>location). Is it realistic to expect that this could this be >>accomplished within the opes framework? >> >> > >It is. The only question is what protocol(s) you will use between your >proxies (the curly lines in Figure C). > > > >>In fact a more fundamental question is the opes framework the best >>way to solve this problem and maintain an open system. I think this >>is what opes is all about. >> >> > >IMO, OPES framework accommodates, in principle, any intermediary >adaptation. Thus, your problem is within the framework. However, the >framework is not complete. It does not have ready-to-use tools for all >possible intermediary adaptations. I hope that you will find OCP Core >and OPES communications "tools" useful for your problems, but I lack >information to tell your whether they are the best. > >The system is "open" if it uses "open standards". If current OPES >tools are not right for you, and there are no better open tools, then >we can work together, within the OPES Framework, on defining open >standards (protocols and interfaces) that will solve your specific >problem. > >Alex. > > > --------------030501070902080808030906 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Alex, I very much appreciate your help and the additional  information. I need a little time to digest this and think some more about my problem and opes "needs".... 
Thanks.   Regards  John

Alex Rousskov wrote:
On Thu, 8 Jan 2004, John G. Waclawsky wrote:

  
Alex, thank you for your reply and the pointer. I agree with you
that the use case I am interested in is not explicitly documented in
the opes material. This gives the wrong impression, since all the
examples show the data flows returning to the first hop data
dispatcher. To restrict data flow in this way would be inefficient
for high capacity applications and would tend to make the first hop
a bottleneck.
    

John,

	You are misreading OPES architecture diagrams because you are
thinking about a much "simpler" case than most diagrams attempt to
document and, hence, you assign wrong roles to "boxes" that may not
even exist in your environment. This is the architecture draft fault,
not yours. Let me try to explain.

Here is a "classic" OPES proxying case (horizontal lines are
application data/protocols being proxied, proxies may be adapting data
internally):

    Figure A.

        end -- proxy -- proxy -- ... -- end

Here is a "classic" OPES callout case (vertical lines are callout
data/protocols, proxy is not adapting data, callout servers may be
adapting data):

    Figure B.

        end --- proxy --- end
         _________|__________
         |        |         |
         |        |         |
      callout   callout   callout
      server    server    server

A combination of the above is possible and common, of course. In a
combined case, some proxies are adapting data internally and some use
callout servers to adapt.

In your particular case (the adapted data flows to the next hop), you
do not have callout servers. You have proxies that adapt data
internally. However, your case may not be a classic proxying case
because you may want proxies to use a protocol that differs from the
original application protocol (so that you can ship metadata and
perhaps pipeline more efficiently). I will use curly (~) lines to show
that new protocol below. You may also want to do some load balancing:

    Figure C.

                    ~~~~~ proxy1 ---
                   /
      end -- proxy ~~~~~~ proxy2 ---  ??  end
                   \
                    ~~~~~ proxyN ---


I do not know how the proxies will get application data to the right
"end", but it is not important for this discussion.

Note that the curly path may use a completely new protocol (e.g., OCP)
or can use a combination of the original application protocol to
deliver data and some other protocol for metadata (billing, etc.)
records.

The above is OPES, but not a callout case. There are no callout
servers, just proxies. Whether you want to use OCP for the curly path
depends on what kind of data/metadata you want to exchange and what
other protocols you have available.

  
To be a little more specific on my use case and to make sure I
understand your response let me add more detail. Fundamentally, I wish
to have an "open" IETF network environment. The second requirement is
speed in adaptation processing, so I am thinking that callout will be
faster than using a proxy (maybe this is an incorrect assumption).
    

It's an incorrect question :-). Adaptations at the callout server can
be as "fast" or as "slow" as adaptations performed internally at the
proxy. The primary reason to use a callout server is to "outsource"
(from business, development, support, logistics, legal, etc. points of
view) adaptations. The primary reasons not to use a callout server are
security and overheads of the data having to return back to the proxy.

  
I may be a little confused about the distinction between classic
proxy and classic call out in this situation (this word proxy isn't
even mentioned in the opes architecture document as a
consideration).
    

I hope the above diagrams clarify the distinction. OPES processor is
the term closest to the "proxy", I think.

  
Also, I have a requirement to adapt a large volume of content for
numerous devices.
    

Both callout and builtin adaptations can handle large volumes of
content. There are many factors at play here, from legal concerns to
the kind of adaptation being performed.

  
I expect that the volume of data will require a number of adaptation
(call out) processors. I estimate 10 of them and therefore I would
need load balancing as part of the solution for directing data to
the call out servers (doing the adaptation).
    

Load balancing can be done with both callout and proxying schemes.
OPES mechanisms are usually per-message so any load balancing method
that does not split individual application messages should work just
fine.

  
I am looking at Figure 3 in the opes architecture draft and
considering a load balanced collection of ten call out servers. As I
had mentioned previously, I'd like to have parallel pipeline
approach where the adapted data from each of the opes call out
server is simply forwarded on, directly to the producer or data
consumer (what ever the case would be).
    

The latter makes the adapter a proxy, not a callout server (by
definition). See Figure C above.

  
In addition each of the opes call out servers would then send
billing and trace data back to the load balancer (or another network
location). Is it realistic to expect that this could this be
accomplished within the opes framework?
    

It is. The only question is what protocol(s) you will use between your
proxies (the curly lines in Figure C).

  
In fact a more fundamental question is the opes framework the best
way to solve this problem and maintain an open system. I think this
is what opes is all about.
    

IMO, OPES framework accommodates, in principle, any intermediary
adaptation. Thus, your problem is within the framework. However, the
framework is not complete. It does not have ready-to-use tools for all
possible intermediary adaptations. I hope that you will find OCP Core
and OPES communications "tools" useful for your problems, but I lack
information to tell your whether they are the best.

The system is "open" if it uses "open standards". If current OPES
tools are not right for you, and there are no better open tools, then
we can work together, within the OPES Framework, on defining open
standards (protocols and interfaces) that will solve your specific
problem.

Alex.
--------------030501070902080808030906-- From owner-ietf-openproxy@mail.imc.org Thu Jan 8 19:26:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19982 for ; Thu, 8 Jan 2004 19:26:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AekUJ-0002it-00 for opes-archive@ietf.org; Thu, 08 Jan 2004 19:26:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AekSJ-0002XJ-00 for opes-archive@ietf.org; Thu, 08 Jan 2004 19:24:52 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AekOd-0002Gr-00 for opes-archive@ietf.org; Thu, 08 Jan 2004 19:21:03 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i090AAib037289 for ; Thu, 8 Jan 2004 16:10:10 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i090AA8B037288 for ietf-openproxy-bks; Thu, 8 Jan 2004 16:10:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail.radioburst.com (mail.esmartstart.com [66.119.143.50]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i090A8ib037282 for ; Thu, 8 Jan 2004 16:10:08 -0800 (PST) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by mail.radioburst.com (8.12.8/8.12.8) with ESMTP id i0908GZW004134; Thu, 8 Jan 2004 17:09:50 -0700 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id i08Ii7Q5017531; Thu, 8 Jan 2004 11:44:17 -0700 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i08IhkeW017512; Thu, 8 Jan 2004 11:43:46 -0700 Date: Thu, 8 Jan 2004 11:43:46 -0700 Message-Id: <200401081843.i08IhkeW017512@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: jgw@cisco.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage <3FFD9E35.6080607@cisco.com> Subject: Re: An opes usage question. X-esmartscan-MailScanner: Found to be clean X-esmartscan-MailScanner-SpamCheck: not spam, SpamAssassin (score=-4.765, required 7, AWL 0.14, BAYES_00 -4.90) Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 The expectation is that you will be able to use a load-balancer as you describe. There shouldn't be any particular OPES protocol configuration issues involved in the setup. If you find some, let us know. The tracing and billing informatio is slightly different. You say that it might go back to the OPES processor(?) (through the load-balancer?) or to some other location. This non-specifity of destination is outside the OPES protocol, and you'd probably do best to just have the callout servers open a direct connection to the billing server. However, you'll need to think about whether or not the OCP message headers give you enough information to correlate the billing with the connection that triggered the callout server. If you simply attach the billing data to the adapted stream and let it flow back to the OPES processor, you'll need to write code that recognizes and detaches that data and sends it to your billing server. You could use OCP to communicate with the billing server, I suppose, but there are probably any number of other protocols that would be just as good. Hilarie From owner-ietf-openproxy@mail.imc.org Thu Jan 8 19:50:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20902 for ; Thu, 8 Jan 2004 19:50:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AekrK-0004Gx-00 for opes-archive@ietf.org; Thu, 08 Jan 2004 19:50:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AekpY-0004Aj-00 for opes-archive@ietf.org; Thu, 08 Jan 2004 19:48:53 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Aekog-00044W-00 for opes-archive@ietf.org; Thu, 08 Jan 2004 19:47:58 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i090bsib038466 for ; Thu, 8 Jan 2004 16:37:54 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i090bsBi038465 for ietf-openproxy-bks; Thu, 8 Jan 2004 16:37:54 -0800 (PST) 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.10/8.12.8) with ESMTP id i090brib038460 for ; Thu, 8 Jan 2004 16:37:53 -0800 (PST) (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 i090bpk3030053; Thu, 8 Jan 2004 17:37:51 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i090bpjs030052; Thu, 8 Jan 2004 17:37:51 -0700 (MST) (envelope-from rousskov) Date: Thu, 8 Jan 2004 17:37:51 -0700 (MST) From: Alex Rousskov To: "The Purple Streak, Hilarie Orman" cc: jgw@cisco.com, ietf-openproxy@imc.org Subject: Re: An opes usage question. In-Reply-To: <200401081843.i08IhkeW017512@localhost.localdomain> Message-ID: References: <200401081843.i08IhkeW017512@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: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hilarie, Note that John does NOT want the data to go from the place where it is adapted back to the proxy/dispatcher. Thus, this is a proxying case, not a callout server case for which OCP was designed. If John uses OCP to talk between two processors/proxies, then some default OCP Core assumptions will not work and will need to be overwritten in OCP profile. I agree that OCP can be used to send tracing and billing info from one OCP agent to another, and that using OCP for such info makes most sense if OCP is also used for application data. Alex. On Thu, 8 Jan 2004, The Purple Streak, Hilarie Orman wrote: > The tracing and billing informatio is slightly different. You say > that it might go back to the OPES processor(?) (through the > load-balancer?) or to some other location. This non-specifity of > destination is outside the OPES protocol, and you'd probably do best > to just have the callout servers open a direct connection to the > billing server. However, you'll need to think about whether or not > the OCP message headers give you enough information to correlate the > billing with the connection that triggered the callout server. > > If you simply attach the billing data to the adapted stream and let > it flow back to the OPES processor, you'll need to write code that > recognizes and detaches that data and sends it to your billing > server. You could use OCP to communicate with the billing server, I > suppose, but there are probably any number of other protocols that > would be just as good. > > Hilarie > From owner-ietf-openproxy@mail.imc.org Thu Jan 15 16:38:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01407 for ; Thu, 15 Jan 2004 16:38:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhFCL-0004uK-00 for opes-archive@ietf.org; Thu, 15 Jan 2004 16:38:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhFBL-0004mx-00 for opes-archive@ietf.org; Thu, 15 Jan 2004 16:37:40 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AhFAO-0004jb-00 for opes-archive@ietf.org; Thu, 15 Jan 2004 16:36:40 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0FLA1ib069727; Thu, 15 Jan 2004 13:10:01 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0FLA1Mt069726; Thu, 15 Jan 2004 13:10:01 -0800 (PST) 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.10/8.12.8) with ESMTP id i0FL9wib069716 for ; Thu, 15 Jan 2004 13:10:01 -0800 (PST) (envelope-from dinaras@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 QAA28502; Thu, 15 Jan 2004 16:09:58 -0500 (EST) Message-Id: <200401152109.QAA28502@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-02.txt Date: Thu, 15 Jan 2004 16:09:57 -0500 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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-02.txt Pages : 40 Date : 2004-1-15 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-02.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-02.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-02.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: <2004-1-15152525.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-http-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-http-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-15152525.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Thu Jan 15 17:38:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05954 for ; Thu, 15 Jan 2004 17:38:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AhG8T-0002LT-00 for opes-archive@ietf.org; Thu, 15 Jan 2004 17:38:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AhG7X-0002K1-00 for opes-archive@ietf.org; Thu, 15 Jan 2004 17:37:48 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AhG78-0002Ia-00 for opes-archive@ietf.org; Thu, 15 Jan 2004 17:37:22 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0FMKxib073933; Thu, 15 Jan 2004 14:20:59 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0FMKxOX073932; Thu, 15 Jan 2004 14:20:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0FMKwib073926 for ; Thu, 15 Jan 2004 14:20:58 -0800 (PST) (envelope-from markus@mhof.com) Received: from mhof.com (unknown[135.104.20.71]) by comcast.net (rwcrmhc11) with ESMTP id <20040115222052013008outme> (Authid: mhofmann); Thu, 15 Jan 2004 22:20:52 +0000 Message-ID: <4007124F.4000502@mhof.com> Date: Thu, 15 Jan 2004 17:21:03 -0500 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: WG Last Call: draft-ietf-opes-http-02.txt Content-Type: multipart/mixed; boundary="------------090208010900000303050801" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=MIME_SUSPECT_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. --------------090208010900000303050801 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit We are starting WG last call on the "HTTP adaptation with OPES" draft (see attached). The last call period closes on Friday, January 23 at 5pm EST. Please post any comments, etc. to the mailing list, and please point out whether you feel your comment is editorial or a show-stopper. Thanks, Markus --------------090208010900000303050801 Content-Type: message/rfc822; name="I-D ACTION:draft-ietf-opes-http-02.txt" Content-Disposition: inline; filename="I-D ACTION:draft-ietf-opes-http-02.txt" Return-Path: Received: from frontend1.messagingengine.com (frontend1.internal [10.202.2.150]) by server2.fastmail.fm (Cyrus v2.1.9) with LMTP; Thu, 15 Jan 2004 16:35:57 -0500 X-Sieve: CMU Sieve 2.2 X-Spam-score: 0.3 X-Spam-hits: BAYES_00, MIME_BOUND_NEXTPART, NO_REAL_NAME, RM_sl_Parens X-Virus-checked: Yes X-Attached: draft-ietf-opes-http-02.txt X-Attached: draft-ietf-opes-http-02.txt X-Resolved-to: hofmann@fastmail.fm X-Delivered-to: ietf@mhof.com X-Mail-from: owner-ietf-announce@ietf.org Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mail.messagingengine.com (Postfix) with ESMTP id E0982EE07B for ; Thu, 15 Jan 2004 16:35:54 -0500 (EST) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 1AhEkt-00057L-8M for ietf-announce-list@asgard.ietf.org; Thu, 15 Jan 2004 16:10:19 -0500 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 1AhEkd-00054n-Od for all-ietf@asgard.ietf.org; Thu, 15 Jan 2004 16:10:03 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28502; Thu, 15 Jan 2004 16:09:58 -0500 (EST) Message-Id: <200401152109.QAA28502@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-02.txt Date: Thu, 15 Jan 2004 16:09:57 -0500 Sender: owner-ietf-announce@ietf.org Precedence: bulk --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-02.txt Pages : 40 Date : 2004-1-15 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-02.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-02.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-02.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: <2004-1-15152525.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-http-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-http-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-1-15152525.I-D@ietf.org> --OtherAccess-- --NextPart-- --------------090208010900000303050801-- From spvdmki@msn.com Mon Jan 26 01:36:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08819 for ; Mon, 26 Jan 2004 01:36:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al0MV-0000cA-00 for opes-archive@ietf.org; Mon, 26 Jan 2004 01:36:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al0LZ-0000Zw-00 for opes-archive@ietf.org; Mon, 26 Jan 2004 01:35:46 -0500 Received: from midsouth-24-151-197-132.westtn.chartertn.net ([24.151.197.132]) by ietf-mx with smtp (Exim 4.12) id 1Al0Ky-0000Xp-00; Mon, 26 Jan 2004 01:35:09 -0500 Received: from 176.142.122.96 by web774.mail.yahoo.com; Mon, 26 Jan 2004 00:26:08 -0600 Message-ID: From: "Megan Lusk" To: bofchairs@ietf.org Subject: snyder oftentimes Date: Mon, 26 Jan 2004 12:33:08 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--456491436650134494" X-CS-IP: 96.156.18.96 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=7.3 required=5.0 tests=HTML_70_80,HTML_IMAGE_ONLY_02, HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, USERPASS autolearn=no version=2.60 X-Spam-Report: * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_70_80 BODY: Message is 70% to 80% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 2.2 HTML_IMAGE_ONLY_02 BODY: HTML: images with 0-200 bytes of words * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 3.1 USERPASS URI: URL contains username and (optional) password * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts ----456491436650134494 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable








preside uganda corp tolstoy background pit

----456491436650134494-- From owner-ietf-openproxy@mail.imc.org Mon Jan 26 10:04:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08057 for ; Mon, 26 Jan 2004 10:04:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Al8IL-00021P-00 for opes-archive@ietf.org; Mon, 26 Jan 2004 10:04:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Al8HP-0001yR-00 for opes-archive@ietf.org; Mon, 26 Jan 2004 10:04:00 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Al8GU-0001vd-00 for opes-archive@ietf.org; Mon, 26 Jan 2004 10:03:02 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0QEmB8w041822; Mon, 26 Jan 2004 06:48:11 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0QEmBi1041821; Mon, 26 Jan 2004 06:48:11 -0800 (PST) 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.11/8.12.8) with ESMTP id i0QEm9CK041813 for ; Mon, 26 Jan 2004 06:48:09 -0800 (PST) (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.10/8.12.10) with ESMTP id i0QEm7xl066349 for ; Mon, 26 Jan 2004 09:48:07 -0500 (EST) 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 i0QElxjh056459 for ; Mon, 26 Jan 2004 09:47:59 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i0QElwMl016530 for ; Mon, 26 Jan 2004 09:47:59 -0500 (EST) Message-ID: <401528E6.7050400@mhof.com> Date: Mon, 26 Jan 2004 09:49:10 -0500 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.5a (Windows/20040120) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: WG Last Call: draft-ietf-opes-http-02.txt References: <4007124F.4000502@mhof.com> In-Reply-To: <4007124F.4000502@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: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi, since there was no additional feedback, we've forwarded this draft to IESG for consideration as proposed standard. Thanks to everybody who contributed to the draft, but in particular to Martin and Alex who put in a lot of effort and time into this draft - great job!! Thanks, Markus Markus Hofmann wrote: > We are starting WG last call on the "HTTP adaptation with OPES" draft > (see attached). The last call period closes on Friday, January 23 > at 5pm EST. Please post any comments, etc. to the mailing list, and > please point out whether you feel your comment is editorial or a > show-stopper. > > Thanks, > Markus > > ------------------------------------------------------------------------ > > Subject: > I-D ACTION:draft-ietf-opes-http-02.txt > From: > Internet-Drafts@ietf.org > Date: > Thu, 15 Jan 2004 16:09:57 -0500 > To: > IETF-Announce: ; > > To: > IETF-Announce: ; > CC: > ietf-openproxy@imc.org > > > 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-02.txt > Pages : 40 > Date : 2004-1-15 > > 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-02.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-02.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-02.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. From owner-ietf-openproxy@mail.imc.org Mon Jan 26 11:59:01 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12854 for ; Mon, 26 Jan 2004 11:59:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlA4k-0000bH-00 for opes-archive@ietf.org; Mon, 26 Jan 2004 11:59:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlA3n-0000Zj-00 for opes-archive@ietf.org; Mon, 26 Jan 2004 11:58:03 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AlA3e-0000Y9-00 for opes-archive@ietf.org; Mon, 26 Jan 2004 11:57:54 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0QGhYLT048503; Mon, 26 Jan 2004 08:43:34 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0QGhXKA048502; Mon, 26 Jan 2004 08:43:33 -0800 (PST) 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.11/8.12.8) with ESMTP id i0QGhWhA048496 for ; Mon, 26 Jan 2004 08:43:32 -0800 (PST) (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 i0QGhYpv001746; Mon, 26 Jan 2004 08:43:34 -0800 (PST) Date: Mon, 26 Jan 2004 08:43:34 -0800 From: Marshall Rose To: Markus Hofmann Cc: OPES Group Subject: Re: WG Last Call: draft-ietf-opes-http-02.txt Message-Id: <20040126084334.7af571c4.mrose@dbc.mtview.ca.us> In-Reply-To: <401528E6.7050400@mhof.com> References: <4007124F.4000502@mhof.com> <401528E6.7050400@mhof.com> 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: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit > Thanks to everybody who contributed to the draft, but in particular to > Martin and Alex who put in a lot of effort and time into this draft - > great job!! i concur. excellent! /mtr From owner-ietf-openproxy@mail.imc.org Mon Jan 26 12:36:05 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13952 for ; Mon, 26 Jan 2004 12:36:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlAec-0002Qb-00 for opes-archive@ietf.org; Mon, 26 Jan 2004 12:36:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlAdg-0002Og-00 for opes-archive@ietf.org; Mon, 26 Jan 2004 12:35:09 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AlAdR-0002MU-00 for opes-archive@ietf.org; Mon, 26 Jan 2004 12:34:53 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0QHOQ3m050439; Mon, 26 Jan 2004 09:24:26 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0QHOQXm050438; Mon, 26 Jan 2004 09:24:26 -0800 (PST) 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.11/8.12.8) with ESMTP id i0QHOOrh050428 for ; Mon, 26 Jan 2004 09:24:24 -0800 (PST) (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 i0QHOP4v065938 for ; Mon, 26 Jan 2004 10:24:25 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i0QHOPhF065937; Mon, 26 Jan 2004 10:24:25 -0700 (MST) (envelope-from rousskov) Date: Mon, 26 Jan 2004 10:24:25 -0700 (MST) From: Alex Rousskov To: OPES WG Subject: AD advice regarding P 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: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Are there any news from our AD or other advisors regarding P destiny? With all other drafts submitted to or appoved by IESG, it seems like P is the only showstopper for discussions about rechartering. Can non-chair members of the group help in any way to speedup AD/advisor reaction? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Mon Jan 26 12:38:59 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14014 for ; Mon, 26 Jan 2004 12:38:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlAhR-0002XI-00 for opes-archive@ietf.org; Mon, 26 Jan 2004 12:39:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlAgX-0002VR-00 for opes-archive@ietf.org; Mon, 26 Jan 2004 12:38:05 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AlAfl-0002Tx-00 for opes-archive@ietf.org; Mon, 26 Jan 2004 12:37:17 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0QHKqU2050179; Mon, 26 Jan 2004 09:20:52 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0QHKq5b050178; Mon, 26 Jan 2004 09:20:52 -0800 (PST) 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.11/8.12.8) with ESMTP id i0QHKoN1050171 for ; Mon, 26 Jan 2004 09:20:50 -0800 (PST) (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 i0QHKP4v065723; Mon, 26 Jan 2004 10:20:25 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i0QHKPNK065722; Mon, 26 Jan 2004 10:20:25 -0700 (MST) (envelope-from rousskov) Date: Mon, 26 Jan 2004 10:20:25 -0700 (MST) From: Alex Rousskov To: Marshall Rose cc: OPES Group Subject: Re: WG Last Call: draft-ietf-opes-http-02.txt In-Reply-To: <20040126084334.7af571c4.mrose@dbc.mtview.ca.us> Message-ID: References: <4007124F.4000502@mhof.com> <401528E6.7050400@mhof.com> <20040126084334.7af571c4.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: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Thanks for nice comments! I am less excited about the HTTP draft quality, but I think the quality is sufficient for a PS status (as documented and, perhaps, as implemented by IESG as well). Early implementations should allow for further bugfixing and polishing of the draft. The first thing IESG should notice is that the draft lacks IANA Considerations section. We use iana.org URIs for profile feature identifiers, but we do not "register" them. The identifier domain and pathname components are questionable as well. We do not register message part tokens either. I did not comment about that during the last call because I do not know the solution, and because I am not sure PS status requires IANA Considerations section. Hopefully, this is a minor issue that will not delay the draft approval by much. Thanks, Alex. On Mon, 26 Jan 2004, Marshall Rose wrote: > > Thanks to everybody who contributed to the draft, but in > > particular to Martin and Alex who put in a lot of effort and time > > into this draft - great job!! > > i concur. excellent! > > /mtr > > From owner-ietf-openproxy@mail.imc.org Mon Jan 26 13:42:11 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15521 for ; Mon, 26 Jan 2004 13:42:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlBgZ-0005Ni-00 for opes-archive@ietf.org; Mon, 26 Jan 2004 13:42:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlBfe-0005Kj-00 for opes-archive@ietf.org; Mon, 26 Jan 2004 13:41:14 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AlBfG-0005IG-00 for opes-archive@ietf.org; Mon, 26 Jan 2004 13:40:50 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0QINlwO052697; Mon, 26 Jan 2004 10:23:47 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0QINlsa052696; Mon, 26 Jan 2004 10:23:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0QINkK2052690 for ; Mon, 26 Jan 2004 10:23:46 -0800 (PST) (envelope-from apache@asgard.ietf.org) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AlBOU-0007zX-65; Mon, 26 Jan 2004 13:23:30 -0500 X-test-idtracker: no To: IETF-Announce :; From: The IESG Subject: Last Call: 'OPES Callout Protocol Core' to Proposed Standard Reply-to: iesg@ietf.org Message-Id: Date: Mon, 26 Jan 2004 13:23:30 -0500 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,TO_HAS_SPACES autolearn=no version=2.60 The IESG has received a request from the Open Pluggable Edge Services WG to consider the following document: - 'OPES Callout Protocol Core ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-02-09. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-opes-ocp-core-04.txt From owner-ietf-openproxy@mail.imc.org Mon Jan 26 17:08:10 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21782 for ; Mon, 26 Jan 2004 17:08:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlEtu-0006nf-00 for opes-archive@ietf.org; Mon, 26 Jan 2004 17:08:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlEsw-0006ly-00 for opes-archive@ietf.org; Mon, 26 Jan 2004 17:07:11 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AlEs5-0006k5-00 for opes-archive@ietf.org; Mon, 26 Jan 2004 17:06:18 -0500 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0QLshcL061671; Mon, 26 Jan 2004 13:54:43 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0QLshPY061670; Mon, 26 Jan 2004 13:54:43 -0800 (PST) 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.11/8.12.8) with ESMTP id i0QLsf23061651 for ; Mon, 26 Jan 2004 13:54:42 -0800 (PST) (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.10/8.12.10) with ESMTP id i0QLshcD092469; Mon, 26 Jan 2004 16:54:43 -0500 (EST) 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 i0QLsW0C056563; Mon, 26 Jan 2004 16:54:33 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i0QLsVMl001780; Mon, 26 Jan 2004 16:54:31 -0500 (EST) Message-ID: <40158CDE.3020409@mhof.com> Date: Mon, 26 Jan 2004 16:55:42 -0500 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.5a (Windows/20040120) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG CC: Ned Freed Subject: Re: AD advice regarding P 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: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex, we're in touch with Ned and are waiting for his feedback and guidance on this issue. Thanks, Markus Alex Rousskov wrote: > > Are there any news from our AD or other advisors regarding P destiny? > > With all other drafts submitted to or appoved by IESG, it seems like P > is the only showstopper for discussions about rechartering. Can > non-chair members of the group help in any way to speedup AD/advisor > reaction? > > Thanks, > > Alex. >