From owner-ietf-openproxy@mail.imc.org  Sun Jun  2 19:59:04 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20677
	for <opes-archive@ietf.org>; Sun, 2 Jun 2002 19:59:04 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g52NOpc01023
	for ietf-openproxy-bks; Sun, 2 Jun 2002 16:24:51 -0700 (PDT)
Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g52NOjg01019
	for <ietf-openproxy@imc.org>; Sun, 2 Jun 2002 16:24:45 -0700 (PDT)
Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47])
	by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g52NOXp26367;
	Sun, 2 Jun 2002 18:24:34 -0500 (CDT)
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <KLRZRMTT>; Sun, 2 Jun 2002 16:24:18 -0700
Message-ID: <7B802811BE77D51189910002A55CFD2C0292738B@zsc3c032.us.nortel.com>
From: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>
To: "Rochberger, Haim" <Haim_Rochberger@icomverse.com>,
        Andre Beck
	 <abeck@bell-labs.com>
Cc: Markus Hofmann <markus@mhof.com>, OPES Group <ietf-openproxy@imc.org>
Subject: RE: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-
	 re qs-00.txt
Date: Sun, 2 Jun 2002 16:24:18 -0700 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C20A8C.9DE25912"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C20A8C.9DE25912
Content-Type: text/plain;
	charset="iso-8859-1"

Hello,
 
by chaining of callout servers you are implying different physical boxes,
that provide different services, right?
 
Because a certain data channel can be setup to provide several services,
e.g., virus scanning, content filtering and langugage translation. The main
difference is that although they are different services, they sit on the
same box. 
 
On the other hand one could argue that a callout server and a opes data
processor can set up such a channel but what the callout server is actually
doing is saying "I know how to provide you with these services, but not
necessarily I'm doing everything". So, in the backend the "callout server
proxy" can use other callout servers to do the job. This callout server
proxy could even be a layer 7 switch which only establish the callout
protocol but relinquish everything to a pool of callout servers. The
responses then go back to the layer 7 switch, which send to some other
callout server on the pool for a different service.
 
So, I see a lot of borderline cases and different scenarios where there are
different meaning of "chaining callout servers" 
 
regards,
 
Reinaldo

 
 -----Original Message-----
From: Rochberger, Haim [mailto:Haim_Rochberger@icomverse.com]
Sent: Friday, May 31, 2002 1:53 PM
To: Andre Beck
Cc: Markus Hofmann; OPES Group
Subject: RE: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-
re qs-00.txt



Hi Andre, 

Thanks for the quick reply. 
I see your point, but since I see the callout servers as an "expert server"
who is giving a specific, non trivial service, 

then I can see a model of such service providers who own those servers, and
whoever has a trusting relations with - it may give that service to, and
charge for it.

Now I don't think the issue should be whether they are close by or not, but
since there could be a situation that performance both on a specific
message, and the OPES engine, is important, then the question is if I can
propose to add an OPTION for the OPES engine to specify in the callout
protocol (whatever it will be) a list of the trusted servers and their
order, and insert a security signature on the list so that the chain of
trust can be achieved, and billing too. and add mechanism so that each
server on the chain must notify the OPES engine  on his activity and status
in a secured way, This can eventually be an option that in the local domain
with no performance issues be ignored... but if the implementations WILL
need it and will not have it standardized - will not use this OPES mechanism
altogether.

I do understand that this is a "second stage" issue now - as the first
specification still on the way, but if someone volunteers to take this issue
under their wings...?

Are there other members who feel this should be at list optional ? 

Warm regards, 

Haim Rochberger 
System Architect 
Comverse 
Mobile Internet & Broadband Division 
Office: +972-3-766-9121 
Mobile: +972-54-970-504 
Email: Haim_rochberger@comverse.com < mailto:Haim_rochberger@comverse.com
<mailto:Haim_rochberger@comverse.com> > 



-----Original Message----- 
From: Andre Beck [ mailto:abeck@bell-labs.com <mailto:abeck@bell-labs.com> ]

Sent: Fri, May 31, 2002 5:29 PM 
To: Rochberger, Haim 
Cc: Markus Hofmann; OPES Group 
Subject: Re: 
http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-
<http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol->  re 
qs-00.txt 


Rochberger, Haim wrote: 
> Is it still possible to add this requirement ? I mean chaining callout 
> servers ? 
> 
> This may improve the performance in case you have a few callout servers 
> that need to handle a specific message in order. 

Callout server chaining would add a lot of complexity to callout 
transactions and callout servers, e.g. in terms of error handling, 
fail-over, tracing, trust relationships etc. I can only see performance 
benefits in cases where the distance between the callout servers is 
shorter than the distance between the OPES processor and the callout 
servers. However, I think whenever the performance of callout 
transactions is critical, it is much more likely that the callout 
servers will be co-located with the OPES processor, i.e. in the same 
domain. Hence the distance between the OPES processor and callout 
servers would be similar to the distance between the callout servers and 
there wouldn't be much of a performance benefit any more with callout 
chaining. 

-Andre 


------_=_NextPart_001_01C20A8C.9DE25912
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol- re qs-00.txt</TITLE>

<META content="MSHTML 6.00.2716.2200" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=701362123-02062002><FONT face=Arial color=#0000ff 
size=2>Hello,</FONT></SPAN></DIV>
<DIV><SPAN class=701362123-02062002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=701362123-02062002><FONT face=Arial color=#0000ff size=2>by 
chaining of callout servers you are implying different physical boxes, that 
provide different services, right?</FONT></SPAN></DIV>
<DIV><SPAN class=701362123-02062002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=701362123-02062002><FONT face=Arial color=#0000ff 
size=2>Because a certain data channel can be setup to provide several services, 
e.g., virus scanning, content filtering and langugage translation. The main 
difference is that although they are different services, they sit on the same 
box. </FONT></SPAN></DIV>
<DIV><SPAN class=701362123-02062002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=701362123-02062002><FONT face=Arial color=#0000ff size=2>On the 
other hand one could argue that a callout server and a opes data processor can 
set up such a channel but what the callout server is actually doing is saying "I 
know how to provide you with these services, but not necessarily I'm doing 
everything". So, in the backend the "callout server proxy" can use other callout 
servers to do the job. This callout server proxy could even be a layer 7 switch 
which only establish the callout protocol but relinquish everything to a pool of 
callout servers. The responses then go back to the layer 7 switch, which send to 
some other callout server on the pool for a different 
service.</FONT></SPAN></DIV>
<DIV><SPAN class=701362123-02062002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=701362123-02062002><FONT face=Arial color=#0000ff size=2>So, I 
see a lot of borderline cases and different scenarios where there are different 
meaning of "chaining callout servers" </FONT></SPAN></DIV>
<DIV><SPAN class=701362123-02062002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=701362123-02062002><FONT face=Arial color=#0000ff 
size=2>regards,</FONT></SPAN></DIV>
<DIV><SPAN class=701362123-02062002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=701362123-02062002><FONT face=Arial color=#0000ff 
size=2>Reinaldo</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
  size=2><SPAN class=701362123-02062002><FONT face=Arial 
  color=#0000ff>&nbsp;</FONT></SPAN></FONT></FONT></DIV>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma><FONT 
  size=2><SPAN class=701362123-02062002>&nbsp;</SPAN>-----Original 
  Message-----<BR><B>From:</B> Rochberger, Haim 
  [mailto:Haim_Rochberger@icomverse.com]<BR><B>Sent:</B> Friday, May 31, 2002 
  1:53 PM<BR><B>To:</B> Andre Beck<BR><B>Cc:</B> Markus Hofmann; OPES 
  Group<BR><B>Subject:</B> RE: 
  http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol- re 
  qs-00.txt<BR><BR></DIV></FONT></FONT>
  <P><FONT size=2>Hi Andre,</FONT> </P>
  <P><FONT size=2>Thanks for the quick reply.</FONT> <BR><FONT size=2>I see your 
  point, but since I see the callout servers as an "expert server" who is giving 
  a specific, non trivial service, </FONT></P>
  <P><FONT size=2>then I can see a model of such service providers who own those 
  servers, and whoever has a trusting relations with - it may give that service 
  to, and charge for it.</FONT></P>
  <P><FONT size=2>Now I don't think the issue should be whether they are close 
  by or not, but since there could be a situation that performance both on a 
  specific message, and the OPES engine, is important, then the question is if I 
  can propose to add an OPTION for the OPES engine to specify in the callout 
  protocol (whatever it will be) a list of the trusted servers and their order, 
  and insert a security signature on the list so that the chain of trust can be 
  achieved, and billing too. and add mechanism so that each server on the chain 
  must notify the OPES engine&nbsp; on his activity and status in a secured way, 
  This can eventually be an option that in the local domain with no performance 
  issues be ignored... but if the implementations WILL need it and will not have 
  it standardized - will not use this OPES mechanism altogether.</FONT></P>
  <P><FONT size=2>I do understand that this is a "second stage" issue now - as 
  the first specification still on the way, but if someone volunteers to take 
  this issue under their wings...?</FONT></P>
  <P><FONT size=2>Are there other members who feel this should be at list 
  optional ?</FONT> </P>
  <P><FONT size=2>Warm regards,</FONT> </P>
  <P><FONT size=2>Haim Rochberger</FONT> <BR><FONT size=2>System 
  Architect</FONT> <BR><FONT size=2>Comverse</FONT> <BR><FONT size=2>Mobile 
  Internet &amp; Broadband Division</FONT> <BR><FONT size=2>Office: 
  +972-3-766-9121</FONT> <BR><FONT size=2>Mobile: +972-54-970-504</FONT> 
  <BR><FONT size=2>Email: Haim_rochberger@comverse.com &lt;<A 
  href="mailto:Haim_rochberger@comverse.com">mailto:Haim_rochberger@comverse.com</A>&gt;</FONT> 
  </P><BR><BR>
  <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: Andre 
  Beck [<A 
  href="mailto:abeck@bell-labs.com">mailto:abeck@bell-labs.com</A>]</FONT> 
  <BR><FONT size=2>Sent: Fri, May 31, 2002 5:29 PM</FONT> <BR><FONT size=2>To: 
  Rochberger, Haim</FONT> <BR><FONT size=2>Cc: Markus Hofmann; OPES Group</FONT> 
  <BR><FONT size=2>Subject: Re:</FONT> <BR><FONT size=2><A 
  href="http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-" 
  target=_blank>http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-</A> 
  re</FONT> <BR><FONT size=2>qs-00.txt</FONT> </P><BR>
  <P><FONT size=2>Rochberger, Haim wrote:</FONT> <BR><FONT size=2>&gt; Is it 
  still possible to add this requirement ? I mean chaining callout 
  </FONT><BR><FONT size=2>&gt; servers ?</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; This may improve the performance in case you have 
  a few callout servers </FONT><BR><FONT size=2>&gt; that need to handle a 
  specific message in order.</FONT> </P>
  <P><FONT size=2>Callout server chaining would add a lot of complexity to 
  callout </FONT><BR><FONT size=2>transactions and callout servers, e.g. in 
  terms of error handling, </FONT><BR><FONT size=2>fail-over, tracing, trust 
  relationships etc. I can only see performance </FONT><BR><FONT size=2>benefits 
  in cases where the distance between the callout servers is </FONT><BR><FONT 
  size=2>shorter than the distance between the OPES processor and the callout 
  </FONT><BR><FONT size=2>servers. However, I think whenever the performance of 
  callout </FONT><BR><FONT size=2>transactions is critical, it is much more 
  likely that the callout </FONT><BR><FONT size=2>servers will be co-located 
  with the OPES processor, i.e. in the same </FONT><BR><FONT size=2>domain. 
  Hence the distance between the OPES processor and callout </FONT><BR><FONT 
  size=2>servers would be similar to the distance between the callout servers 
  and </FONT><BR><FONT size=2>there wouldn't be much of a performance benefit 
  any more with callout </FONT><BR><FONT size=2>chaining.</FONT> </P>
  <P><FONT size=2>-Andre</FONT> </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C20A8C.9DE25912--


From owner-ietf-openproxy@mail.imc.org  Mon Jun  3 11:09:43 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17417
	for <opes-archive@ietf.org>; Mon, 3 Jun 2002 11:09:43 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g53Ee1928374
	for ietf-openproxy-bks; Mon, 3 Jun 2002 07:40:01 -0700 (PDT)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g53Edxg28367
	for <ietf-openproxy@imc.org>; Mon, 3 Jun 2002 07:39:59 -0700 (PDT)
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.2/8.12.2) with ESMTP id g53EdvEF020062;
	Mon, 3 Jun 2002 10:39:57 -0400 (EDT)
Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8])
	by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g53EdIo90821;
	Mon, 3 Jun 2002 10:39:19 -0400 (EDT)
Received: from mhof.com (biena [135.180.160.86])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA10175;
	Mon, 3 Jun 2002 10:39:18 -0400 (EDT)
Message-ID: <3CFB7F96.9010502@mhof.com>
Date: Mon, 03 Jun 2002 10:39:18 -0400
From: Markus Hofmann <markus@mhof.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rochberger, Haim" <Haim_Rochberger@icomverse.com>
CC: OPES Group <ietf-openproxy@imc.org>
Subject: Re: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-
  re qs-00.txt
References: <6682DE381343D511BFD400508BDD16E70188B09A@ISMAILEXA>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


Haim,

> Now I don't think the issue should be whether they are close by or not, 
> but since there could be a situation that performance both on a specific 
> message, and the OPES engine, is important, then the question is if I 
> can propose to add an OPTION for the OPES engine to specify in the 
> callout protocol (whatever it will be) a list of the trusted servers and 
> their order, and insert a security signature on the list so that the 
> chain of trust can be achieved, and billing too. and add mechanism so 
> that each server on the chain must notify the OPES engine  on his 
> activity and status in a secured way, 

The current draft already requires the callout protocol to provide the 
capability of transporting meta data, see Section 3.11:

   "The OPES callout protocol MUST provide a mechanism for the
    endpoints of a particular callout transaction to include in
    callout requests and responses meta data and instructions for
    the OPES data processor or callout server."

I would assume that this could include the kind of information you're 
talking about.

Nevertheless, one might wonder whether the benefits that could be 
expected from chaining callout servers outweight the increased 
complexity, in particular with respect to trust relationships, 
privacy, security, etc. Therefore, I'd be little bit hesitant to put 
more specific requirements for callout server chaining on the calloout 
protocol.

We first need to get a clear understanding about the 
security/privacy/etc. implications of callout server chaining, and 
then decide whether to support/allow it or not. The WG document on 
"endpoint authorization and enforcement requirements" would probably 
be an appropriate place to do that - would you be willing to take a 
crack contribute to that document?

-Markus



From owner-ietf-openproxy@mail.imc.org  Mon Jun  3 13:58:17 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25556
	for <opes-archive@ietf.org>; Mon, 3 Jun 2002 13:58:16 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g53HT3809158
	for ietf-openproxy-bks; Mon, 3 Jun 2002 10:29:03 -0700 (PDT)
Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g53HT2g09151
	for <ietf-openproxy@imc.org>; Mon, 3 Jun 2002 10:29:02 -0700 (PDT)
Received: from eburger (keeper.snowshore.com [216.57.133.4])
	by flyingfox.snowshore.com (8.11.2/8.11.2) with SMTP id g53HT2B01848;
	Mon, 3 Jun 2002 13:29:02 -0400 (EDT)
Reply-To: <eburger@snowshore.com>
From: "Eric Burger" <eburger@snowshore.com>
To: "John Morris" <jmorris@cdt.org>
Cc: "OPES Group" <ietf-openproxy@imc.org>
Subject: RE: [ OPES architecture] Final Points of Discussion: Tracing
Date: Mon, 3 Jun 2002 13:30:12 -0400
Message-ID: <BEEMKJGAMKLMAIKEECBACEFFCGAA.eburger@snowshore.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <v0422080cb912df8ca18a@[10.0.1.20]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


Hmmm.

Does this mean that a source can block ANY transformation?  The concept
"breaks" the Internet model of "bits are bits".  The good news is that it is
impossible to enforce such a request.  An end-point is an end-point.  Unless
we go the way of the DMCA and end up pressuring hardware manufacturers to
physically block the execution of transformation code...

Where the model may work is if we assume it operates like the US Patent
system.  I can patent something, like the use of aspirin to cure cancer.
There is NOTHING to stop someone from buying aspirin for relieving a
headache and then using it to cure their own cancer (the "bits are bits"
reality).  However, my patent would prevent someone from PROVIDING a cure
for cancer using asprin.

Given the impossibility of enforcing a "do not OPES" indicator, but there
being some utility of requesting "no OPES, please", can we make this an
informational indicator, if we need it at all?

-----Original Message-----
From: owner-ietf-openproxy@mail.imc.org
[mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of John Morris
Sent: Thursday, May 23, 2002 2:32 PM
To: The Purple Streak (Hilarie Orman)
Cc: OPES Group
Subject: Re: [ OPES architecture] Final Points of Discussion: Tracing



At least some content providers are going to want this capability for
reasons other than an after-the-fact forensic analysis.
Hypothetically, a big content site that offers both (a) free web
based content, AND (b) a fee-based option to get the same content in
a low-bandwidth wireless-friendly format, might want to block an end
user from getting a third party OPES wireless-reformatter to make the
conversion.

Even though I personally am not thrilled about that hypothetical
situation, I think it is very plausible, and one that should concern
OPES intermediaries.  A site could easily, in its terms of service or
other clipwrap agreement, limit a user's license to view content to
only a single format.  At least arguably, if an OPES intermediary
then transforms the content into a different format, the site might
have a claim against the intermediary.

Stated more generally, I can easily see situations in which an OPES
intermediary would want to (or would be required to) have the
abililty to allow either primary party to veto a planned OPES
transformation.  In many (but not all) cases, the end user might be
able to exercise this veto simply by discarding the OPESized content.
The approach that Markus suggests could give the content provider a
similar veto (assuming the OPES intermediary honored the primary
party's veto).

To be clear, there are lots of arguments why a content provider
should not be able to control how the user transforms the delivered
content.  But content owners are certainly going to want that
capability, and the IAB discussed some reasons why that capability
might in some cases be appropriate.

One alternative would be for OPES dispatchers to recognize a blanket
"DO NOT OPES" flag on content received from content providers.  But
if that is the only option a content provider has, we could see an
unnecessarily high number of such flags on content (thereby
marginalizing the client-centric OPES service market).

John


At 11:40 AM -0600 5/23/02, The Purple Streak (Hilarie Orman) wrote:
>I can see this as being an option for debugging, but making it
>mandantory for use in forensic analysis of "inappropriateness"
>by end users is simply outside the scope of protocol development.
>
>Hilarie
>
>Markus Hofmann wrote:
>
>>
>>John Morris wrote:
>>
>>>Unless I've missed something (which is certainly possible), the
>>>draft may want to suggest how the OPES architecture will respond
>>>to the following IAB consideration:
>>>
>>>    (3.1) Notification: The overall OPES framework needs to assist
>>>    content providers in detecting and responding to client-centric
>>>    actions by OPES intermediaries that are deemed inappropriate by the
>>>    content provider.
>>
>>
>>Section 2.6 of the draft should extend to include some form of
>>notification of the OPES action to the originating party *when
>>requested* by the originating party. Implicit notification
>>mechanisms would not scale, but a content provider should be able
>>to explicitly request notification in some form.



From owner-ietf-openproxy@mail.imc.org  Mon Jun  3 14:04:44 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25790
	for <opes-archive@ietf.org>; Mon, 3 Jun 2002 14:04:43 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g53HT4b09161
	for ietf-openproxy-bks; Mon, 3 Jun 2002 10:29:04 -0700 (PDT)
Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g53HT2g09154
	for <ietf-openproxy@imc.org>; Mon, 3 Jun 2002 10:29:02 -0700 (PDT)
Received: from eburger (keeper.snowshore.com [216.57.133.4])
	by flyingfox.snowshore.com (8.11.2/8.11.2) with SMTP id g53HT1B01845;
	Mon, 3 Jun 2002 13:29:02 -0400 (EDT)
Reply-To: <eburger@snowshore.com>
From: "Eric Burger" <eburger@snowshore.com>
To: "Markus Hofmann" <markus@mhof.com>
Cc: "OPES Group" <ietf-openproxy@imc.org>
Subject: RE: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-reqs-00.txt
Date: Mon, 3 Jun 2002 13:30:12 -0400
Message-ID: <BEEMKJGAMKLMAIKEECBAAEFFCGAA.eburger@snowshore.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <3CFB7F96.9010502@mhof.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


We're struggling with the very issue in the CATS work group.  In the CATS
case, we were hoping OPES would either come up with a solution or make it
acceptable to punt for now.

My vote is to punt.

-----Original Message-----
On Behalf Of Markus Hofmann:

[snip]
Nevertheless, one might wonder whether the benefits that could be
expected from chaining callout servers outweight the increased
complexity, in particular with respect to trust relationships,
privacy, security, etc. Therefore, I'd be little bit hesitant to put
more specific requirements for callout server chaining on the calloout
protocol.



From owner-ietf-openproxy@mail.imc.org  Mon Jun  3 14:24:16 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26305
	for <opes-archive@ietf.org>; Mon, 3 Jun 2002 14:24:15 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g53HtjV09877
	for ietf-openproxy-bks; Mon, 3 Jun 2002 10:55:45 -0700 (PDT)
Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g53Htig09872
	for <ietf-openproxy@imc.org>; Mon, 3 Jun 2002 10:55:44 -0700 (PDT)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g53HtPl11358;
	Mon, 3 Jun 2002 13:55:26 -0400 (EDT)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <KTYB3VMM>; Mon, 3 Jun 2002 13:55:25 -0400
Message-ID: <87609AFB433BD5118D5E0002A52CD754025D5D4A@zcard0k6.ca.nortel.com>
From: "Abbie Barbir" <abbieb@nortelnetworks.com>
To: eburger@snowshore.com, Markus Hofmann <markus@mhof.com>
Cc: OPES Group <ietf-openproxy@imc.org>
Subject: RE: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-
	reqs-00.txt
Date: Mon, 3 Jun 2002 13:55:16 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C20B27.D15F50B0"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C20B27.D15F50B0
Content-Type: text/plain;
	charset="iso-8859-1"


+1 

abbie

> -----Original Message-----
> From: Eric Burger [mailto:eburger@snowshore.com]
> Sent: Monday, June 03, 2002 1:30 PM
> To: Markus Hofmann
> Cc: OPES Group
> Subject: RE:
> http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-r
> eqs-00.txt
> 
> 
> 
> We're struggling with the very issue in the CATS work group.  
> In the CATS
> case, we were hoping OPES would either come up with a 
> solution or make it
> acceptable to punt for now.
> 
> My vote is to punt.
> 
> -----Original Message-----
> On Behalf Of Markus Hofmann:
> 
> [snip]
> Nevertheless, one might wonder whether the benefits that could be
> expected from chaining callout servers outweight the increased
> complexity, in particular with respect to trust relationships,
> privacy, security, etc. Therefore, I'd be little bit hesitant to put
> more specific requirements for callout server chaining on the calloout
> protocol.
> 
> 

------_=_NextPart_001_01C20B27.D15F50B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: =
http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-reqs-00.txt=
</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>+1 </FONT>
</P>

<P><FONT SIZE=3D2>abbie</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Eric Burger [<A =
HREF=3D"mailto:eburger@snowshore.com">mailto:eburger@snowshore.com</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Monday, June 03, 2002 1:30 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Markus Hofmann</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: OPES Group</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE:</FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-r" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-opes-pr=
otocol-r</A></FONT>
<BR><FONT SIZE=3D2>&gt; eqs-00.txt</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; We're struggling with the very issue in the =
CATS work group.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; In the CATS</FONT>
<BR><FONT SIZE=3D2>&gt; case, we were hoping OPES would either come up =
with a </FONT>
<BR><FONT SIZE=3D2>&gt; solution or make it</FONT>
<BR><FONT SIZE=3D2>&gt; acceptable to punt for now.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; My vote is to punt.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; On Behalf Of Markus Hofmann:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; [snip]</FONT>
<BR><FONT SIZE=3D2>&gt; Nevertheless, one might wonder whether the =
benefits that could be</FONT>
<BR><FONT SIZE=3D2>&gt; expected from chaining callout servers =
outweight the increased</FONT>
<BR><FONT SIZE=3D2>&gt; complexity, in particular with respect to trust =
relationships,</FONT>
<BR><FONT SIZE=3D2>&gt; privacy, security, etc. Therefore, I'd be =
little bit hesitant to put</FONT>
<BR><FONT SIZE=3D2>&gt; more specific requirements for callout server =
chaining on the calloout</FONT>
<BR><FONT SIZE=3D2>&gt; protocol.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C20B27.D15F50B0--


From owner-ietf-openproxy@mail.imc.org  Tue Jun  4 14:16:21 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08818
	for <opes-archive@ietf.org>; Tue, 4 Jun 2002 14:16:21 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g54HfJ701936
	for ietf-openproxy-bks; Tue, 4 Jun 2002 10:41:19 -0700 (PDT)
Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g54HfIg01932
	for <ietf-openproxy@imc.org>; Tue, 4 Jun 2002 10:41:18 -0700 (PDT)
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.2/8.12.2) with ESMTP id g54HfhUL078057
	for <ietf-openproxy@imc.org>; Tue, 4 Jun 2002 13:41:43 -0400 (EDT)
Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8])
	by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g54HfCk69843
	for <ietf-openproxy@imc.org>; Tue, 4 Jun 2002 13:41:12 -0400 (EDT)
Received: from mhof.com (biena [135.180.160.86])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA29223;
	Tue, 4 Jun 2002 13:41:11 -0400 (EDT)
Message-ID: <3CFCFBB6.40801@mhof.com>
Date: Tue, 04 Jun 2002 13:41:10 -0400
From: Markus Hofmann <markus@mhof.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: OPES Group <ietf-openproxy@imc.org>
Subject: Content Provider Notification
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


Hi,

in a previous email exchange on this list concerning the IAB 
consideration (3.1) about notification to content providers, I 
somewhere typed the following:

 >> (3.1) Notification: The overall OPES framework needs to assist
 >> content providers in detecting and responding to client-centric
 >> actions by OPES intermediaries that are deemed inappropriate by
 >> the content provider.
 >
 > Section 2.6 of the draft should extend to include some form of
 > notification of the OPES action to the originating party *when
 > requested* by the originating party. Implicit notification
 > mechanisms would not scale, but a content provider should be able
 > to explicitly request notification in some form.

In discussing this issue with others, the question arised whether the 
capability of requesting such notification might eventually violate 
the privacy of a content consumer/client, since it would allow a 
CONTENT PROVIDER to find out about CLIENT-CENTRIC actions.

Such notification might eventually reveal private information the 
client does not necessarily want to share with a content provider, for 
example the client's prefered language (revealed by a language 
translation service). Or what about a scenario in which the client 
browses the Web through an anonymizing proxy, but the client-centric 
service is provided on an OPES box sitting between the client and the 
anonymizing proxy? Normally, the content provider would only see the 
IP address of the anonymizing proxy, but with requested OPES 
notifiactions he/she would eventually find out about the OPES box 
sitting close to the client, thus eventually allowing him/her to 
figure out the client's ISP and such like. Other scenarios are thinkable.

Any thoughts on that? How should this be adressed? Does this rule out 
direct notification of CLIENT-CENTRIC actions to the CONTENT-PROVIDER, 
or would the benefits of such notifications outweight the privacy 
concerns? Might indirect notification by the client (based on OPES 
tracing information) be acceptable, i.e. bringing the client back into 
the notifiaction loop? Does the client have a right to veto direct 
notification?

-Markus



From owner-ietf-openproxy@mail.imc.org  Tue Jun  4 16:05:50 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13102
	for <opes-archive@ietf.org>; Tue, 4 Jun 2002 16:05:50 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g54JZHe07863
	for ietf-openproxy-bks; Tue, 4 Jun 2002 12:35:17 -0700 (PDT)
Received: from esarhaddon.ability.net (esarhaddon.ability.net [216.3.3.68])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g54JZFg07859
	for <ietf-openproxy@imc.org>; Tue, 4 Jun 2002 12:35:16 -0700 (PDT)
Received: from [10.0.1.20] (66.safeclick.net [63.119.245.66])
	by esarhaddon.ability.net (8.11.6/8.11.6) with ESMTP id g54JYsG01183;
	Tue, 4 Jun 2002 15:34:54 -0400
Mime-Version: 1.0
X-Sender: john@mail.cdtmail.org
Message-Id: <v04220816b922bab652bf@[10.0.1.20]>
In-Reply-To: <3CFCFBB6.40801@mhof.com>
References: <3CFCFBB6.40801@mhof.com>
Date: Tue, 4 Jun 2002 15:34:51 -0400
To: Markus Hofmann <markus@mhof.com>
From: John Morris <jmorris@cdt.org>
Subject: Re: Content Provider Notification
Cc: OPES Group <ietf-openproxy@imc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


At 1:41 PM -0400 6/4/02, Markus Hofmann wrote:
><snip>
>In discussing this issue with others, the question arised whether 
>the capability of requesting such notification might eventually 
>violate the privacy of a content consumer/client, since it would 
>allow a CONTENT PROVIDER to find out about CLIENT-CENTRIC actions.
>
><snip>
>Any thoughts on that? How should this be adressed? Does this rule 
>out direct notification of CLIENT-CENTRIC actions to the 
>CONTENT-PROVIDER, or would the benefits of such notifications 
>outweight the privacy concerns? Might indirect notification by the 
>client (based on OPES tracing information) be acceptable, i.e. 
>bringing the client back into the notifiaction loop? Does the client 
>have a right to veto direct notification?
>
>-Markus

Markus,

The privacy concern you raise is a very real and very challenging 
one.  I think that the IAB properly placed a great value in 
transparency (motivated, in part, to protect users' privacy by 
telling users who has access to their information).  But in some 
situations transparency can harm privacy and anonymity.  I do not 
think that there is any easy answer that can fully protect the rights 
of all concerned.

I set out below a middle ground approach that strikes me as a 
reasonable compromise.  But before getting to it, let me respond to 
an earlier question raised by Eric Burger:


At 1:30 PM -0400 6/3/02, Eric Burger wrote:
>Hmmm.
>
>Does this mean that a source can block ANY transformation?  The concept
>"breaks" the Internet model of "bits are bits".  The good news is that it is
>impossible to enforce such a request.  An end-point is an end-point.  Unless
>we go the way of the DMCA and end up pressuring hardware manufacturers to
>physically block the execution of transformation code...
>
><snip>
>
>Given the impossibility of enforcing a "do not OPES" indicator, but there
>being some utility of requesting "no OPES, please", can we make this an
>informational indicator, if we need it at all?

My answer to Eric is that I don't think he and I disagree about what 
is reasonably plausible to implement -- a source will not be able to 
"enforce" a "do not OPES" flag.  But the term "informational 
indicator" suggests, to me, a bit of information that is largely 
ignored downstream.  Here, I believe that an OPES dispatcher should 
look for and honor a "do not OPES" instruction.

To avoid getting a "do not OPES" instruction, a user/client might 
well be willing to tell the server what OPES transformation the 
client wants to do, and the server might then permit the 
transformation.  As a hypothetical, if a publisher wants to block 
OPES transformations of its content into a compact wireless format 
(because the publisher offers a separate wireless service, for 
example), the publisher may well not have any problem with an OPES 
service that translates (at the request of a German-speaking human 
client) all content into German.

BUT, a client-to-server notification of proposed OPES transformations 
can raise the exact privacy problem that Markus identified.

An approach that gives some (but not all) protection to both sides would be:

1.  OPES defaults to provide client-to-server notification of 
proposed OPES transformations.
2.  A client can change the default and thus block the notification.
3.  A server can issue a general "do not OPES" instruction, which a 
properly implemented OPES dispatcher would honor.  Thus, while a 
client could block client-to-server notification, the server could 
block all OPES transformations.

This approach would allow the client control over his or her privacy 
and/or anonymity, but at the potential cost of (a) losing access to 
certain information, or (b) only getting access to the information in 
an untransformed way.

To be clear, the suggested approach is NOT symmetric.  I would 
support giving the client the option to block client-to-server 
notification, but I think that server-to-client notification should 
be mandatory (assuming the OPES dispatcher or OPES service provider 
is an entity other than the server itself).  This asymmetry seems 
appropriate because, in the end, the server typically holds all of 
the cards (in the form of holding some requested information) and 
commonly the client is the entity that needs greater protection.

But, to loop back, the privacy/anonymity implications of the 
client-to-server notification raises tough questions.

John

--------------------------------------------------
John Morris // CDT // http://www.cdt.org/standards
--------------------------------------------------


From owner-ietf-openproxy@mail.imc.org  Tue Jun  4 21:59:23 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22064
	for <opes-archive@ietf.org>; Tue, 4 Jun 2002 21:59:22 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g551QYH16983
	for ietf-openproxy-bks; Tue, 4 Jun 2002 18:26:34 -0700 (PDT)
Received: from mgr4.xmission.com (mail@mgr4.xmission.com [198.60.22.204])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g551QWg16978
	for <ietf-openproxy@imc.org>; Tue, 4 Jun 2002 18:26:32 -0700 (PDT)
Received: from mail by mgr4.xmission.com with spam-scanned (Exim 3.35 #1)
	id 17FPZL-0002OE-00; Tue, 04 Jun 2002 19:26:35 -0600
Received: from [198.60.22.200] (helo=mail.xmission.com)
	by mgr4.xmission.com with esmtp (Exim 3.35 #1)
	id 17FPZL-0002OB-00; Tue, 04 Jun 2002 19:26:35 -0600
Received: from [166.70.13.202] (helo=alum.mit.edu)
	by mail.xmission.com with esmtp (Exim 3.22 #1)
	id 17FPZJ-0001dA-00; Tue, 04 Jun 2002 19:26:34 -0600
Message-ID: <3CFD5F54.9020307@alum.mit.edu>
Date: Tue, 04 Jun 2002 18:46:12 -0600
From: "The Purple Streak (Hilarie Orman)" <ho@alum.mit.edu>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: John Morris <jmorris@cdt.org>
CC: OPES Group <ietf-openproxy@imc.org>
Subject: Re: Content Provider Notification
References: <3CFCFBB6.40801@mhof.com> <v04220816b922bab652bf@[10.0.1.20]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=0.0 required=8.0 tests= version=2.20
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


I suppose the content could be marked with an advisory to the
content consumer's software - the advisory being "upon reading,
mail or POST the OPES headers to the content provider."  That's about
the only reasonable way I can see to provide strong forms of
notification while still giving the content consumer some control.
But the content provider just isn't going to want to be bombarded
with all these notifications, and if notifications were a default
requirement, it would be crippling.  The providers would need
a detailed way of specifying which kinds of OPES services or which
OPES service providers did or did not have to provide notifications.
Which gets back to the inline policy specification and validation
methods of my paper of last year.  It's a heavyweight solution, done
to show that these problems have solutions, but at a cost.  And it
is clearly outside what the working group wants to do.

The mechanisms for notification would be complicated, as they cannot
follow the content path.  They must be the same for both endpoints
(because both the request and the response can be part of OPES
processing), and they must handle the case of intermediate content
providers (consider a personalization service contracted for by the
content provider; if the content consumer's personalization service
conflicted with it, the personalization service provider must be
notified).  How can one relate the notification to the request that
ocassioned it?  In the case of a caching proxy, the content provider
would not have seen the request, and the notification of an OPES
service would not be related to any activity seen by the provider or
his contracted services.

In short, I do not see how to design a meaningful notification service
that suits anyone's purposes within the current working group's
talents and desires.  And there's no point in saying "no notification"
if we haven't got a notification service.  So there's no impact
on the architecture.

I suggest we put this issue aside for the time being.  It has been
considered, it is very difficult, and it can be a topic for a later
encharterment.

Hilarie


John Morris wrote:

> 
> At 1:41 PM -0400 6/4/02, Markus Hofmann wrote:
> 
>> <snip>
>> In discussing this issue with others, the question arised whether the 
>> capability of requesting such notification might eventually violate 
>> the privacy of a content consumer/client, since it would allow a 
>> CONTENT PROVIDER to find out about CLIENT-CENTRIC actions.
>>
>> <snip>
>> Any thoughts on that? How should this be adressed? Does this rule out 
>> direct notification of CLIENT-CENTRIC actions to the CONTENT-PROVIDER, 
>> or would the benefits of such notifications outweight the privacy 
>> concerns? Might indirect notification by the client (based on OPES 
>> tracing information) be acceptable, i.e. bringing the client back into 
>> the notifiaction loop? Does the client have a right to veto direct 
>> notification?
>>
>> -Markus
> 
> 
> Markus,
> 
> The privacy concern you raise is a very real and very challenging one.  
> I think that the IAB properly placed a great value in transparency 
> (motivated, in part, to protect users' privacy by telling users who has 
> access to their information).  But in some situations transparency can 
> harm privacy and anonymity.  I do not think that there is any easy 
> answer that can fully protect the rights of all concerned.
> 
> I set out below a middle ground approach that strikes me as a reasonable 
> compromise.  But before getting to it, let me respond to an earlier 
> question raised by Eric Burger:
> 
> 
> At 1:30 PM -0400 6/3/02, Eric Burger wrote:
> 
>> Hmmm.
>>
>> Does this mean that a source can block ANY transformation?  The concept
>> "breaks" the Internet model of "bits are bits".  The good news is that 
>> it is
>> impossible to enforce such a request.  An end-point is an end-point.  
>> Unless
>> we go the way of the DMCA and end up pressuring hardware manufacturers to
>> physically block the execution of transformation code...
>>
>> <snip>
>>
>> Given the impossibility of enforcing a "do not OPES" indicator, but there
>> being some utility of requesting "no OPES, please", can we make this an
>> informational indicator, if we need it at all?
> 
> 
> My answer to Eric is that I don't think he and I disagree about what is 
> reasonably plausible to implement -- a source will not be able to 
> "enforce" a "do not OPES" flag.  But the term "informational indicator" 
> suggests, to me, a bit of information that is largely ignored 
> downstream.  Here, I believe that an OPES dispatcher should look for and 
> honor a "do not OPES" instruction.
> 
> To avoid getting a "do not OPES" instruction, a user/client might well 
> be willing to tell the server what OPES transformation the client wants 
> to do, and the server might then permit the transformation.  As a 
> hypothetical, if a publisher wants to block OPES transformations of its 
> content into a compact wireless format (because the publisher offers a 
> separate wireless service, for example), the publisher may well not have 
> any problem with an OPES service that translates (at the request of a 
> German-speaking human client) all content into German.
> 
> BUT, a client-to-server notification of proposed OPES transformations 
> can raise the exact privacy problem that Markus identified.
> 
> An approach that gives some (but not all) protection to both sides would 
> be:
> 
> 1.  OPES defaults to provide client-to-server notification of proposed 
> OPES transformations.
> 2.  A client can change the default and thus block the notification.
> 3.  A server can issue a general "do not OPES" instruction, which a 
> properly implemented OPES dispatcher would honor.  Thus, while a client 
> could block client-to-server notification, the server could block all 
> OPES transformations.
> 
> This approach would allow the client control over his or her privacy 
> and/or anonymity, but at the potential cost of (a) losing access to 
> certain information, or (b) only getting access to the information in an 
> untransformed way.
> 
> To be clear, the suggested approach is NOT symmetric.  I would support 
> giving the client the option to block client-to-server notification, but 
> I think that server-to-client notification should be mandatory (assuming 
> the OPES dispatcher or OPES service provider is an entity other than the 
> server itself).  This asymmetry seems appropriate because, in the end, 
> the server typically holds all of the cards (in the form of holding some 
> requested information) and commonly the client is the entity that needs 
> greater protection.
> 
> But, to loop back, the privacy/anonymity implications of the 
> client-to-server notification raises tough questions.
> 
> John
> 
> --------------------------------------------------
> John Morris // CDT // http://www.cdt.org/standards
> --------------------------------------------------
> 
> 




From owner-ietf-openproxy@mail.imc.org  Wed Jun  5 12:01:12 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04630
	for <opes-archive@ietf.org>; Wed, 5 Jun 2002 12:01:12 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g55FShe17973
	for ietf-openproxy-bks; Wed, 5 Jun 2002 08:28:43 -0700 (PDT)
Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g55FSgg17969
	for <ietf-openproxy@imc.org>; Wed, 5 Jun 2002 08:28:42 -0700 (PDT)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g55FSFE00427;
	Wed, 5 Jun 2002 11:28:15 -0400 (EDT)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <KTYBPYC9>; Wed, 5 Jun 2002 11:28:16 -0400
Message-ID: <87609AFB433BD5118D5E0002A52CD7540264A143@zcard0k6.ca.nortel.com>
From: "Abbie Barbir" <abbieb@nortelnetworks.com>
To: "The Purple Streak (Hilarie Orman)" <ho@alum.mit.edu>,
        John Morris
	 <jmorris@cdt.org>
Cc: OPES Group <ietf-openproxy@imc.org>
Subject:  Content Provider Notification: Proposal to address it in the nex
	t phase of the WG
Date: Wed, 5 Jun 2002 11:28:16 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C20CA5.9CE9D524"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C20CA5.9CE9D524
Content-Type: text/plain;
	charset="iso-8859-1"

Hi all,

I here reiterate Hilarie proposal,
i would like  all the possible feedback

+1 from my side

abbie

> -----Original Message-----
> From: The Purple Streak (Hilarie Orman) [mailto:ho@alum.mit.edu]
> Sent: Tuesday, June 04, 2002 8:46 PM
> To: John Morris
> Cc: OPES Group
> Subject: Re: Content Provider Notification
> 
> 
SNIP

> I suggest we put this issue aside for the time being.  It has been
> considered, it is very difficult, and it can be a topic for a later
> encharterment.
> 
> Hilarie
> 
> 
SNIP

 

------_=_NextPart_001_01C20CA5.9CE9D524
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE> Content Provider Notification: Proposal to address it in the next phase of the WG</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Hi all,</FONT>
</P>

<P><FONT SIZE=2>I here reiterate Hilarie proposal,</FONT>
<BR><FONT SIZE=2>i would like&nbsp; all the possible feedback</FONT>
</P>

<P><FONT SIZE=2>+1 from my side</FONT>
</P>

<P><FONT SIZE=2>abbie</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: The Purple Streak (Hilarie Orman) [<A HREF="mailto:ho@alum.mit.edu">mailto:ho@alum.mit.edu</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Tuesday, June 04, 2002 8:46 PM</FONT>
<BR><FONT SIZE=2>&gt; To: John Morris</FONT>
<BR><FONT SIZE=2>&gt; Cc: OPES Group</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: Content Provider Notification</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>SNIP</FONT>
</P>

<P><FONT SIZE=2>&gt; I suggest we put this issue aside for the time being.&nbsp; It has been</FONT>
<BR><FONT SIZE=2>&gt; considered, it is very difficult, and it can be a topic for a later</FONT>
<BR><FONT SIZE=2>&gt; encharterment.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hilarie</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>SNIP</FONT>
</P>

<P><FONT SIZE=2>&nbsp;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C20CA5.9CE9D524--


From owner-ietf-openproxy@mail.imc.org  Wed Jun  5 13:12:56 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07410
	for <opes-archive@ietf.org>; Wed, 5 Jun 2002 13:12:53 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g55GhKe22649
	for ietf-openproxy-bks; Wed, 5 Jun 2002 09:43:20 -0700 (PDT)
Received: from hermes.webwasher.com (mail.webwasher.com [195.162.240.3])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g55GhIn22640
	for <ietf-openproxy@imc.org>; Wed, 5 Jun 2002 09:43:18 -0700 (PDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-reqs-00.txt
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Date: Wed, 5 Jun 2002 18:41:41 +0200
Message-ID: <72992B39BBD9294BB636A960E89AE02E50BEC8@hermes.webwasher.com>
Thread-Topic: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-reqs-00.txt
Thread-Index: AcIHF5s51MY5Bf0fSA22jc/e2/DoZQFlXqgg
From: "Martin Stecher" <martin.stecher@webwasher.com>
To: "OPES WG (E-mail)" <ietf-openproxy@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g55GhJn22645
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


Regarding Section 3.5 Support for Keep-Alive Mechanism
"The OPES callout protocol MUST provide an optional keep-alive mechanism
[...]"

Is this really a MUST?

As I understand the section the keep alive mechanism has to belong to
the OPES protocol not to the lower-level transport protocol.
So, a possible implementation would be that the data processor opens a
channel (let's say it is a TCP connection), keeps it open forever and
sends and receives protocol keep alive messages in absence of any real
transaction, so that both data processor and callout server will know
that the other peer is alive.

While this is a great idea and good for a SHOULD requirment, I do not
see why this is a MUST.

From other sections we can learn that we are looking for a real client
server protocol, in which only the data processor establishes the
channel and the callout server MUST be able to handle many different
channels from different data processors and so on.

Since HTTP is a good example for such a protocol in general, the callout
server is like an HTTP server and is typically not really concerned if
some clients fail and do not longer send requests for some time. When
all connections are closed, the server can free its resources.

On the other hand, the data processor is probably very much interested
in knowing that a callout server has a failure even in times when no
transaction has to be handled (in order to start some failover actions).
But for this task the protocol still does not stringently needs the
keep-alive mechanism but could also reuse the must-have parameter
negotiation messages from time to time to check a callout server's
availability.

Martin


From owner-ietf-openproxy@mail.imc.org  Wed Jun  5 14:46:21 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11807
	for <opes-archive@ietf.org>; Wed, 5 Jun 2002 14:46:21 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g55II6x28114
	for ietf-openproxy-bks; Wed, 5 Jun 2002 11:18:06 -0700 (PDT)
Received: from scl8owa01.int.exodus.net ([66.35.230.241])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g55II5n28110
	for <ietf-openproxy@imc.org>; Wed, 5 Jun 2002 11:18:05 -0700 (PDT)
Received: from SJDCEX01.int.exodus.net ([165.193.27.80]) by scl8owa01.int.exodus.net with Microsoft SMTPSVC(5.0.2195.4905);
	 Wed, 5 Jun 2002 11:18:48 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: Will the OPES WG meet  in Yokohama?  Thx!<eom>
Date: Wed, 5 Jun 2002 11:18:42 -0700
Message-ID: <45258A4365C6B24A9832BFE224837D551D1C36@SJDCEX01.int.exodus.net>
Thread-Topic: Will the OPES WG meet  in Yokohama?  Thx!<eom>
Thread-Index: AcIMvVRAMj27qrOOQnm/5EU+snxmPA==
From: "Joseph Hui" <Joseph.Hui@exodus.net>
To: <hofmann@bell-labs.com>, <mrose@dbc.mtview.ca.us>
Cc: <ietf-openproxy@imc.org>
X-OriginalArrivalTime: 05 Jun 2002 18:18:48.0248 (UTC) FILETIME=[6FB80B80:01C20CBD]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g55II6n28111
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit




From owner-ietf-openproxy@mail.imc.org  Wed Jun  5 15:35:05 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14482
	for <opes-archive@ietf.org>; Wed, 5 Jun 2002 15:35:04 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g55JAO729325
	for ietf-openproxy-bks; Wed, 5 Jun 2002 12:10:24 -0700 (PDT)
Received: from kalia.dbc.mtview.ca.us (adsl-64-168-10-253.dsl.scrm01.pacbell.net [64.168.10.253])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g55JALn29315
	for <ietf-openproxy@imc.org>; Wed, 5 Jun 2002 12:10:21 -0700 (PDT)
Received: from kalia (localhost [127.0.0.1])
	by kalia.dbc.mtview.ca.us (8.11.6+3.4W/8.11.6) with SMTP id g55J8rM00318;
	Wed, 5 Jun 2002 12:08:53 -0700 (PDT)
Date: Wed, 5 Jun 2002 12:08:53 -0700
From: Marshall Rose <mrose@dbc.mtview.ca.us>
To: "Joseph Hui" <Joseph.Hui@exodus.net>
Cc: hofmann@bell-labs.com, ietf-openproxy@imc.org
Subject: Re: Will the OPES WG meet  in Yokohama?  Thx!<eom>
Message-Id: <20020605120853.03417e78.mrose@dbc.mtview.ca.us>
In-Reply-To: <45258A4365C6B24A9832BFE224837D551D1C36@SJDCEX01.int.exodus.net>
References: <45258A4365C6B24A9832BFE224837D551D1C36@SJDCEX01.int.exodus.net>
Organization: Dover Beach Consulting, Inc.
X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386-unknown-netbsdelf1.5ZA)
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: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


yes. agenda to follow later this week.

/mtr


From owner-ietf-openproxy@mail.imc.org  Wed Jun  5 16:41:53 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18526
	for <opes-archive@ietf.org>; Wed, 5 Jun 2002 16:41:53 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g55KGDN03439
	for ietf-openproxy-bks; Wed, 5 Jun 2002 13:16:13 -0700 (PDT)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g55KG7n03433
	for <ietf-openproxy@imc.org>; Wed, 5 Jun 2002 13:16:08 -0700 (PDT)
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.2/8.12.2) with ESMTP id g55KG9EF043560;
	Wed, 5 Jun 2002 16:16:09 -0400 (EDT)
Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8])
	by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g55KG3o41512;
	Wed, 5 Jun 2002 16:16:03 -0400 (EDT)
Received: from bell-labs.com ([135.5.126.183])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id QAA06694;
	Wed, 5 Jun 2002 16:16:02 -0400 (EDT)
Message-ID: <3CFE70EB.4020408@bell-labs.com>
Date: Wed, 05 Jun 2002 15:13:31 -0500
From: Andre Beck <abeck@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-US
MIME-Version: 1.0
To: Martin Stecher <martin.stecher@webwasher.com>
CC: OPES Group <ietf-openproxy@imc.org>
Subject: Re: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-reqs-00.txt
References: <72992B39BBD9294BB636A960E89AE02E50BEC8@hermes.webwasher.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: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


Hi Martin,

 >>From other sections we can learn that we are looking for a real client
 > server protocol, in which only the data processor establishes the
 > channel and the callout server MUST be able to handle many different
 > channels from different data processors and so on.
 >
 > Since HTTP is a good example for such a protocol in general, the callout
 > server is like an HTTP server and is typically not really concerned if
 > some clients fail and do not longer send requests for some time. When
 > all connections are closed, the server can free its resources.

True, but the difference is that HTTP servers typically can use some 
sort of time-out mechanism to close idling persistent connections and 
free resources. Callout servers can't do that because such a behavior 
could result in the loss of application message data and the OPES 
processor may not necessarily be able to repeat a callout request (since 
it cannot always keep a copy of application messages).

Also, unlike HTTP servers, callout servers will have to maintain state 
information for callout channel connections (mostly negotiated channel 
parameters).

 > On the other hand, the data processor is probably very much interested
 > in knowing that a callout server has a failure even in times when no
 > transaction has to be handled (in order to start some failover actions).
 > But for this task the protocol still does not stringently needs the
 > keep-alive mechanism but could also reuse the must-have parameter
 > negotiation messages from time to time to check a callout server's
 > availability.

Yes, this would be feasible (but not necessarily very efficient).

-Andre





From owner-ietf-openproxy@mail.imc.org  Wed Jun  5 17:03:41 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19805
	for <opes-archive@ietf.org>; Wed, 5 Jun 2002 17:03:41 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g55Kaw004071
	for ietf-openproxy-bks; Wed, 5 Jun 2002 13:36:58 -0700 (PDT)
Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g55Kavn04067
	for <ietf-openproxy@imc.org>; Wed, 5 Jun 2002 13:36:57 -0700 (PDT)
Received: from oskar3 ([24.60.133.29]) by rwcrmhc52.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20020605203655.YDGU2751.rwcrmhc52.attbi.com@oskar3>;
          Wed, 5 Jun 2002 20:36:55 +0000
From: "Oskar Batuner" <batuner@attbi.com>
To: "Markus Hofmann" <markus@mhof.com>, "OPES Group" <ietf-openproxy@imc.org>
Subject: RE: Content Provider Notification
Date: Wed, 5 Jun 2002 16:36:56 -0400
Message-ID: <JMEPINMLHPLMNBBANKEHKEANCDAA.batuner@attbi.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <3CFCFBB6.40801@mhof.com>
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


This issue comes to question - who has the final authority on what.
Authority domains should be divided between server's origin of authority and
client's origin of authority. None may have an absolute authority over all
OPES servers in the delivery path.

An example: virus checking. If the server is able to issue some directive
like "no OPES action" which disables all OPES intermediaries - any malicious
life form that takes control over the server may just defeat all antivirus
security.

Filters also may be made vulnerable to adaptive attack by probing using
trace/report facilities.

I think this also answers to the Markus question:

>Any thoughts on that? How should this be addressed? Does this rule out
>direct notification of CLIENT-CENTRIC actions to the CONTENT-PROVIDER,
>or would the benefits of such notifications outweight the privacy
>concerns? Might indirect notification by the client (based on OPES
>tracing information) be acceptable, i.e. bringing the client back into
>the notification loop? Does the client have a right to veto direct
>notification?

There are cases like those above where we have conflict of interests between
content provider and content consumer. Such conflict undermines the
 "benefit" approach - each side may have different understanding of
benefits.

I'd suggest limiting any MUST-level requirements in tracing/reporting
mechanism by appropriate authoritative domain ("color" in the architecture
draft terminology). Client definitely should have the veto right in it's
domain, otherwise it can not rely on certain types of legitimate OPES
services.

I do agree with Hilarie that detailed specification of this mechanism may be
delayed. Such a mechanism may be subject of a separate draft. But the
architecture draft should set the general framework and requirements for the
tracing/reporting.

Oskar




From owner-ietf-openproxy@mail.imc.org  Wed Jun  5 17:30:32 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20915
	for <opes-archive@ietf.org>; Wed, 5 Jun 2002 17:30:32 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g55L3Nv04725
	for ietf-openproxy-bks; Wed, 5 Jun 2002 14:03:23 -0700 (PDT)
Received: from esarhaddon.ability.net (esarhaddon.ability.net [216.3.3.68])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g55L3Ln04721
	for <ietf-openproxy@imc.org>; Wed, 5 Jun 2002 14:03:21 -0700 (PDT)
Received: from TOSH (pat1.qualcomm.com [199.106.101.20])
	by esarhaddon.ability.net (8.11.6/8.11.6) with ESMTP id g55L37f07738;
	Wed, 5 Jun 2002 17:03:07 -0400
Message-Id: <4.2.0.58.20020605144633.0097e660@mail.cdtmail.org>
X-Sender: john@mail.cdtmail.org
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 05 Jun 2002 15:26:25 -0400
To: "The Purple Streak (Hilarie Orman)" <ho@alum.mit.edu>
From: John Morris <jmorris@cdt.org>
Subject: Re: Content Provider Notification
Cc: OPES Group <ietf-openproxy@imc.org>
In-Reply-To: <3CFD5F54.9020307@alum.mit.edu>
References: <3CFCFBB6.40801@mhof.com>
 <v04220816b922bab652bf@[10.0.1.20]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


Some comments inline.....

At 06:46 PM 6/4/02 -0600, The Purple Streak (Hilarie Orman) wrote:

>I suppose the content could be marked with an advisory to the
>content consumer's software - the advisory being "upon reading,
>mail or POST the OPES headers to the content provider."  That's about
>the only reasonable way I can see to provide strong forms of
>notification while still giving the content consumer some control.
>But the content provider just isn't going to want to be bombarded
>with all these notifications, and if notifications were a default
>requirement, it would be crippling.

Wouldn't client-to-server notice transmitted as part of the initial request 
to the server provide the server with some notice without creating a flurry 
of after-the-fact notifications?

>   The providers would need
>a detailed way of specifying which kinds of OPES services or which
>OPES service providers did or did not have to provide notifications.

Although it is clearly a non-trivial task, I expect that some time of 
description method will in the end be a necessary part of OPES.

>Which gets back to the inline policy specification and validation
>methods of my paper of last year.  It's a heavyweight solution, done
>to show that these problems have solutions, but at a cost.  And it
>is clearly outside what the working group wants to do.
>
>The mechanisms for notification would be complicated, as they cannot
>follow the content path.  They must be the same for both endpoints
>(because both the request and the response can be part of OPES
>processing), and they must handle the case of intermediate content
>providers (consider a personalization service contracted for by the
>content provider; if the content consumer's personalization service
>conflicted with it, the personalization service provider must be
>notified).  How can one relate the notification to the request that
>ocassioned it?  In the case of a caching proxy, the content provider
>would not have seen the request, and the notification of an OPES
>service would not be related to any activity seen by the provider or
>his contracted services.

Let me float a simpler and still plausible approach:

1.  By default, no client-to-server notice is necessary.
2.  For the limited number of servers that care, they can send out an "are 
you planning to OPES" inquiry before filling the client's request.
3.  The client side OPES operator would be able to respond to the inquiry 
in the hope of satisfying whatever concern the server might have,  UNLESS 
in initially requesting the service from the OPES provider the client said 
"do not give notice to the server."

>In short, I do not see how to design a meaningful notification service
>that suits anyone's purposes within the current working group's
>talents and desires.  And there's no point in saying "no notification"
>if we haven't got a notification service.  So there's no impact
>on the architecture.
>
>I suggest we put this issue aside for the time being.  It has been
>considered, it is very difficult, and it can be a topic for a later
>encharterment.
>
>Hilarie

It strikes me that there are at least some questions that can and should be 
answered now, such as whether the protocol will honor a "do not OPES" flag.

John


>John Morris wrote:
>
>>At 1:41 PM -0400 6/4/02, Markus Hofmann wrote:
>>
>>><snip>
>>>In discussing this issue with others, the question arised whether the 
>>>capability of requesting such notification might eventually violate the 
>>>privacy of a content consumer/client, since it would allow a CONTENT 
>>>PROVIDER to find out about CLIENT-CENTRIC actions.
>>>
>>><snip>
>>>Any thoughts on that? How should this be adressed? Does this rule out 
>>>direct notification of CLIENT-CENTRIC actions to the CONTENT-PROVIDER, 
>>>or would the benefits of such notifications outweight the privacy 
>>>concerns? Might indirect notification by the client (based on OPES 
>>>tracing information) be acceptable, i.e. bringing the client back into 
>>>the notifiaction loop? Does the client have a right to veto direct 
>>>notification?
>>>
>>>-Markus
>>
>>Markus,
>>The privacy concern you raise is a very real and very challenging one.
>>I think that the IAB properly placed a great value in transparency 
>>(motivated, in part, to protect users' privacy by telling users who has 
>>access to their information).  But in some situations transparency can 
>>harm privacy and anonymity.  I do not think that there is any easy answer 
>>that can fully protect the rights of all concerned.
>>I set out below a middle ground approach that strikes me as a reasonable 
>>compromise.  But before getting to it, let me respond to an earlier 
>>question raised by Eric Burger:
>>
>>At 1:30 PM -0400 6/3/02, Eric Burger wrote:
>>
>>>Hmmm.
>>>
>>>Does this mean that a source can block ANY transformation?  The concept
>>>"breaks" the Internet model of "bits are bits".  The good news is that it is
>>>impossible to enforce such a request.  An end-point is an end-point.
>>>Unless
>>>we go the way of the DMCA and end up pressuring hardware manufacturers to
>>>physically block the execution of transformation code...
>>>
>>><snip>
>>>
>>>Given the impossibility of enforcing a "do not OPES" indicator, but there
>>>being some utility of requesting "no OPES, please", can we make this an
>>>informational indicator, if we need it at all?
>>
>>My answer to Eric is that I don't think he and I disagree about what is 
>>reasonably plausible to implement -- a source will not be able to 
>>"enforce" a "do not OPES" flag.  But the term "informational indicator" 
>>suggests, to me, a bit of information that is largely ignored 
>>downstream.  Here, I believe that an OPES dispatcher should look for and 
>>honor a "do not OPES" instruction.
>>To avoid getting a "do not OPES" instruction, a user/client might well be 
>>willing to tell the server what OPES transformation the client wants to 
>>do, and the server might then permit the transformation.  As a 
>>hypothetical, if a publisher wants to block OPES transformations of its 
>>content into a compact wireless format (because the publisher offers a 
>>separate wireless service, for example), the publisher may well not have 
>>any problem with an OPES service that translates (at the request of a 
>>German-speaking human client) all content into German.
>>BUT, a client-to-server notification of proposed OPES transformations can 
>>raise the exact privacy problem that Markus identified.
>>An approach that gives some (but not all) protection to both sides would be:
>>1.  OPES defaults to provide client-to-server notification of proposed 
>>OPES transformations.
>>2.  A client can change the default and thus block the notification.
>>3.  A server can issue a general "do not OPES" instruction, which a 
>>properly implemented OPES dispatcher would honor.  Thus, while a client 
>>could block client-to-server notification, the server could block all 
>>OPES transformations.
>>This approach would allow the client control over his or her privacy 
>>and/or anonymity, but at the potential cost of (a) losing access to 
>>certain information, or (b) only getting access to the information in an 
>>untransformed way.
>>To be clear, the suggested approach is NOT symmetric.  I would support 
>>giving the client the option to block client-to-server notification, but 
>>I think that server-to-client notification should be mandatory (assuming 
>>the OPES dispatcher or OPES service provider is an entity other than the 
>>server itself).  This asymmetry seems appropriate because, in the end, 
>>the server typically holds all of the cards (in the form of holding some 
>>requested information) and commonly the client is the entity that needs 
>>greater protection.
>>But, to loop back, the privacy/anonymity implications of the 
>>client-to-server notification raises tough questions.
>>John
>>--------------------------------------------------
>>John Morris // CDT // http://www.cdt.org/standards
>>--------------------------------------------------
>



From owner-ietf-openproxy@mail.imc.org  Thu Jun  6 01:12:30 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18273
	for <opes-archive@ietf.org>; Thu, 6 Jun 2002 01:12:30 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g564i7s17861
	for ietf-openproxy-bks; Wed, 5 Jun 2002 21:44:07 -0700 (PDT)
Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g564i6n17857
	for <ietf-openproxy@imc.org>; Wed, 5 Jun 2002 21:44:06 -0700 (PDT)
Received: from oskar3 ([24.60.133.29]) by rwcrmhc51.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20020606044406.VXTO11426.rwcrmhc51.attbi.com@oskar3>;
          Thu, 6 Jun 2002 04:44:06 +0000
From: "Oskar Batuner" <batuner@attbi.com>
To: "John Morris" <jmorris@cdt.org>,
        "The Purple Streak \(Hilarie Orman\)" <ho@alum.mit.edu>
Cc: "OPES Group" <ietf-openproxy@imc.org>
Subject: RE: Content Provider Notification
Date: Thu, 6 Jun 2002 00:44:06 -0400
Message-ID: <JMEPINMLHPLMNBBANKEHKEAOCDAA.batuner@attbi.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <4.2.0.58.20020605144633.0097e660@mail.cdtmail.org>
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit




> -----Original Message-----
> From: owner-ietf-openproxy@mail.imc.org
> [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of John Morris
> Sent: Wednesday, June 05, 2002 3:26 PM
> To: The Purple Streak (Hilarie Orman)
> Cc: OPES Group
> Subject: Re: Content Provider Notification
>
>
>
> Some comments inline.....
>
> At 06:46 PM 6/4/02 -0600, The Purple Streak (Hilarie Orman) wrote:
>
[..............}

>
> Let me float a simpler and still plausible approach:
>
> 1.  By default, no client-to-server notice is necessary.
> 2.  For the limited number of servers that care, they can send
> out an "are
> you planning to OPES" inquiry before filling the client's request.
> 3.  The client side OPES operator would be able to respond to the inquiry
> in the hope of satisfying whatever concern the server might have,  UNLESS
> in initially requesting the service from the OPES provider the
> client said
> "do not give notice to the server."

This mode of operation requires all participants to be OPES-enabled, very
strict limitation. If in response to request from the standard
browser comes inquiry (2) - well, this just means that the server
breaks HTTP and browser may behave unpredictably.

I think the same goal may be achieved (even more efficiently) by adding to
the request coming through the OPES proxy an additional header - OPES
advertisement (again, if permitted/instructed by the end user). Non-OPES
enabled server will simply ignore this additional header; OPES-enabled one
may add some instructions to the response.

As a side effect I'd suggest to add an explicit architectural requirement
that the presence of OPES server in the dataflow SHALL NOT disrupt
operations of non-OPES aware clients and servers. OPES server, content
server and content consumer MAY use OPES extensions to the base protocol
(HTTP), but support of these extensions SHALL NOT be required.

Oskar



From owner-ietf-openproxy@mail.imc.org  Thu Jun  6 01:40:12 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19767
	for <opes-archive@ietf.org>; Thu, 6 Jun 2002 01:40:11 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g565DFT18738
	for ietf-openproxy-bks; Wed, 5 Jun 2002 22:13:15 -0700 (PDT)
Received: from mgr4.xmission.com (mail@mgr4.xmission.com [198.60.22.204])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g565DEn18734
	for <ietf-openproxy@imc.org>; Wed, 5 Jun 2002 22:13:14 -0700 (PDT)
Received: from mail by mgr4.xmission.com with spam-scanned (Exim 3.35 #1)
	id 17FpaE-0003Li-00
	for ietf-openproxy@imc.org; Wed, 05 Jun 2002 23:13:14 -0600
Received: from [198.60.22.200] (helo=mail.xmission.com)
	by mgr4.xmission.com with esmtp (Exim 3.35 #1)
	id 17FpaE-0003Lf-00
	for ietf-openproxy@imc.org; Wed, 05 Jun 2002 23:13:14 -0600
Received: from [166.70.6.184] (helo=alum.mit.edu)
	by mail.xmission.com with esmtp (Exim 3.22 #1)
	id 17FpaD-0000xS-00
	for ietf-openproxy@imc.org; Wed, 05 Jun 2002 23:13:13 -0600
Message-ID: <3CFEEF04.2030304@alum.mit.edu>
Date: Wed, 05 Jun 2002 23:11:32 -0600
From: "The Purple Streak (Hilarie Orman)" <ho@alum.mit.edu>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: OPES Group <ietf-openproxy@imc.org>
Subject: Re: Content Provider Notification
References: <JMEPINMLHPLMNBBANKEHKEAOCDAA.batuner@attbi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=0.0 required=8.0 tests= version=2.20
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


My comments are inline headed by [HKO].

Oskar Batuner wrote:

> 
>>-----Original Message-----
>>From: owner-ietf-openproxy@mail.imc.org
>>[mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of John Morris
>>Sent: Wednesday, June 05, 2002 3:26 PM
>>To: The Purple Streak (Hilarie Orman)
>>Cc: OPES Group
>>Subject: Re: Content Provider Notification
>>
>>
>>
>>Some comments inline.....
>>
>>At 06:46 PM 6/4/02 -0600, The Purple Streak (Hilarie Orman) wrote:
>>
>>
> [..............}
> 
> 
>>Let me float a simpler and still plausible approach:
>>
>>1.  By default, no client-to-server notice is necessary.
>>2.  For the limited number of servers that care, they can send
>>out an "are
>>you planning to OPES" inquiry before filling the client's request.


[HKO] Reading the IAB considerations carefully, and noting that the
content provider is only interested in corrupted or malicious OPES
services, one finds that this would not be a limited number of servers,
it would probably be almost all servers.  Also, as an aside, note that
this inquiry itself could be implemented as an OPES service by a
content distributor.

[HKO] Further, the OPES intermediary will not, in general, forward
every request for a particular piece of content back to the content
provider.  Thus, the best that could be done is for the content to
contain some header saying "please notify me each time you serve this
content with an OPES service applied", because in general, whether or
not an OPES service is applied will depend on some attributes particular
to the requestor.


>>3.  The client side OPES operator would be able to respond to the inquiry
>>in the hope of satisfying whatever concern the server might have,  UNLESS
>>in initially requesting the service from the OPES provider the
>>client said
>>"do not give notice to the server."
>>
> 
> This mode of operation requires all participants to be OPES-enabled, very
> strict limitation. If in response to request from the standard
> browser comes inquiry (2) - well, this just means that the server
> breaks HTTP and browser may behave unpredictably.
> 
> I think the same goal may be achieved (even more efficiently) by adding to
> the request coming through the OPES proxy an additional header - OPES
> advertisement (again, if permitted/instructed by the end user). Non-OPES
> enabled server will simply ignore this additional header; OPES-enabled one
> may add some instructions to the response.


[HKO] But in general, the decision about applying an OPES service will
not be made until the content arrives at the OPES box, so the
notification cannot travel with the request.  I suppose all potential
OPES services could be listed in the request, but that seems unscalable
because it discourages adminstrators from installing services - they
cause request bloat.


> 
> As a side effect I'd suggest to add an explicit architectural requirement
> that the presence of OPES server in the dataflow SHALL NOT disrupt
> operations of non-OPES aware clients and servers. OPES server, content
> server and content consumer MAY use OPES extensions to the base protocol
> (HTTP), but support of these extensions SHALL NOT be required.


If you can amplify "disrupt" reasonably I'd probably agree with this
suggestion.


> 
> Oskar


Hilarie




From owner-ietf-openproxy@mail.imc.org  Thu Jun  6 03:45:17 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01020
	for <opes-archive@ietf.org>; Thu, 6 Jun 2002 03:45:17 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g567GeZ01065
	for ietf-openproxy-bks; Thu, 6 Jun 2002 00:16:40 -0700 (PDT)
Received: from hermes.webwasher.com (mail.webwasher.com [195.162.240.3])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g567Gcn01060
	for <ietf-openproxy@imc.org>; Thu, 6 Jun 2002 00:16:38 -0700 (PDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Subject: RE: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-reqs-00.txt
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Date: Thu, 6 Jun 2002 09:15:20 +0200
Message-ID: <72992B39BBD9294BB636A960E89AE02E50BEC9@hermes.webwasher.com>
Thread-Topic: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-reqs-00.txt
Thread-Index: AcIMzaxcsh57m1prTkiFVgE5+VTkdAAWibrA
From: "Martin Stecher" <martin.stecher@webwasher.com>
To: "Andre Beck" <abeck@bell-labs.com>
Cc: "OPES Group" <ietf-openproxy@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id g567Gdn01062
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


Hi Andre,

> True, but the difference is that HTTP servers typically can use some 
> sort of time-out mechanism to close idling persistent connections and 
> free resources. Callout servers can't do that because such a behavior 
> could result in the loss of application message data and the OPES 
> processor may not necessarily be able to repeat a callout 
> request (since 
> it cannot always keep a copy of application messages).

Think of a very simple callout protocol that starts each request with a
little handshake before application data is transfered (like in SMTP).
For such a protocol it will be possible to timeout a connection by the
callout server without loosing data if the next request is just about to
be sent in this moment.

> 
> Yes, this would be feasible (but not necessarily very efficient).
> 

Absolutely. And that's why an OPES protocol SHOULD offer a keep-alive
mechanism.

Regards
Martin


From owner-ietf-openproxy@mail.imc.org  Thu Jun  6 11:45:13 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18444
	for <opes-archive@ietf.org>; Thu, 6 Jun 2002 11:45:13 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g56FGWX16849
	for ietf-openproxy-bks; Thu, 6 Jun 2002 08:16:32 -0700 (PDT)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g56FGVn16845
	for <ietf-openproxy@imc.org>; Thu, 6 Jun 2002 08:16:31 -0700 (PDT)
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.2/8.12.2) with ESMTP id g56FGWEF051004;
	Thu, 6 Jun 2002 11:16:32 -0400 (EDT)
Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8])
	by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g56FGPk60713;
	Thu, 6 Jun 2002 11:16:26 -0400 (EDT)
Received: from bell-labs.com ([135.5.126.183])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA02484;
	Thu, 6 Jun 2002 11:16:24 -0400 (EDT)
Message-ID: <3CFF7C80.5060109@bell-labs.com>
Date: Thu, 06 Jun 2002 10:15:12 -0500
From: Andre Beck <abeck@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-US
MIME-Version: 1.0
To: Martin Stecher <martin.stecher@webwasher.com>
CC: OPES Group <ietf-openproxy@imc.org>
Subject: Re: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-reqs-00.txt
References: <72992B39BBD9294BB636A960E89AE02E50BEC9@hermes.webwasher.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


Hi Martin,

>>True, but the difference is that HTTP servers typically can use some 
>>sort of time-out mechanism to close idling persistent connections and 
>>free resources. Callout servers can't do that because such a behavior 
>>could result in the loss of application message data and the OPES 
>>processor may not necessarily be able to repeat a callout 
>>request (since 
>>it cannot always keep a copy of application messages).
> 
> Think of a very simple callout protocol that starts each request with a
> little handshake before application data is transfered (like in SMTP).
> For such a protocol it will be possible to timeout a connection by the
> callout server without loosing data if the next request is just about to
> be sent in this moment.

I agree, but this approach would kind of defeat the purpose of why we 
want to use persistent connections in the first place, i.e. to avoid 
handshakes and the like before each and every callout transaction.

> 
>>Yes, this would be feasible (but not necessarily very efficient).
> 
> Absolutely. And that's why an OPES protocol SHOULD offer a keep-alive
> mechanism.

How about we leave the requirement for a keep-alive mechanism in the 
document, but add a sentence that says that the callout protocol MAY 
choose to use an implicit mechanism in order to check the health status 
of a callout connection endpoint, e.g. the parameter negotiation process.

-Andre






From owner-ietf-openproxy@mail.imc.org  Thu Jun  6 12:53:57 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20201
	for <opes-archive@ietf.org>; Thu, 6 Jun 2002 12:53:56 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g56GQmE20765
	for ietf-openproxy-bks; Thu, 6 Jun 2002 09:26:48 -0700 (PDT)
Received: from hermes.webwasher.com (mail.webwasher.com [195.162.240.3])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g56GQkn20761
	for <ietf-openproxy@imc.org>; Thu, 6 Jun 2002 09:26:47 -0700 (PDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Subject: RE: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-reqs-00.txt
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Date: Thu, 6 Jun 2002 18:25:31 +0200
Message-ID: <72992B39BBD9294BB636A960E89AE02E50BECE@hermes.webwasher.com>
Thread-Topic: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-reqs-00.txt
Thread-Index: AcINbPrnQRkyUbgxQiu6DlMY1dBfFgABjdmQ
From: "Martin Stecher" <martin.stecher@webwasher.com>
To: "Andre Beck" <abeck@bell-labs.com>
Cc: "OPES Group" <ietf-openproxy@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by above.proper.com id g56GQln20762
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


My point is:

I see this protocol having (at least) two purposes:
1. Preparation to create a good OPES callout protocol
2. Being an evaluation basis for any other wannabe callout protocol

For number 1 we will obviously want to design a protocol that meets all
MUST and SHOULD requirements, i.e. the OPES protocol will include these
keep-alive messages.

But having more MUST requirements than necessary means that evaluation
of other protocols will be less detailed.

ICAP as an example:
That protocol uses persistent connections but misses the keep-alive
messages. Timing out the connections works but puts more responsibility
to the client side. An ICAP client has at least to keep the last chunk
of application data in order to recover from a connection that is just
about to be closed by the ICAP server and to make a retry or to connect
to an alternate server.
This is a less good solution and it shows that ICAP/1.0 cannot be the
final OPES protocol but I still think that ICAP somehow addresses the
idea of persistent channels and should receive a better evaluation than
a very simple protocol that does not offer this at all.

And that's why I think a SHOULD for this section is a good choice.

Martin

> -----Original Message-----
> From: Andre Beck [mailto:abeck@bell-labs.com]
> Sent: Thursday, June 06, 2002 5:15 PM
> To: Martin Stecher
> Cc: OPES Group
> Subject: Re:
> http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-r
> eqs-00.txt
> 
> 
> Hi Martin,
> 
> >>True, but the difference is that HTTP servers typically can 
> use some 
> >>sort of time-out mechanism to close idling persistent 
> connections and 
> >>free resources. Callout servers can't do that because such 
> a behavior 
> >>could result in the loss of application message data and the OPES 
> >>processor may not necessarily be able to repeat a callout 
> >>request (since 
> >>it cannot always keep a copy of application messages).
> > 
> > Think of a very simple callout protocol that starts each 
> request with a
> > little handshake before application data is transfered 
> (like in SMTP).
> > For such a protocol it will be possible to timeout a 
> connection by the
> > callout server without loosing data if the next request is 
> just about to
> > be sent in this moment.
> 
> I agree, but this approach would kind of defeat the purpose of why we 
> want to use persistent connections in the first place, i.e. to avoid 
> handshakes and the like before each and every callout transaction.
> 
> > 
> >>Yes, this would be feasible (but not necessarily very efficient).
> > 
> > Absolutely. And that's why an OPES protocol SHOULD offer a 
> keep-alive
> > mechanism.
> 
> How about we leave the requirement for a keep-alive mechanism in the 
> document, but add a sentence that says that the callout protocol MAY 
> choose to use an implicit mechanism in order to check the 
> health status 
> of a callout connection endpoint, e.g. the parameter 
> negotiation process.
> 
> -Andre
> 
> 
> 
> 
> 


From owner-ietf-openproxy@mail.imc.org  Thu Jun  6 20:30:01 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19917
	for <opes-archive@ietf.org>; Thu, 6 Jun 2002 20:30:00 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g56NpBl10959
	for ietf-openproxy-bks; Thu, 6 Jun 2002 16:51:11 -0700 (PDT)
Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g56NpAn10955
	for <ietf-openproxy@imc.org>; Thu, 6 Jun 2002 16:51:10 -0700 (PDT)
Received: from oskar3 ([24.60.133.29]) by sccrmhc02.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20020606235108.LHEE975.sccrmhc02.attbi.com@oskar3>;
          Thu, 6 Jun 2002 23:51:08 +0000
From: "Oskar Batuner" <batuner@attbi.com>
To: "The Purple Streak \(Hilarie Orman\)" <ho@alum.mit.edu>,
        "OPES Group" <ietf-openproxy@imc.org>
Subject: RE: Content Provider Notification
Date: Thu, 6 Jun 2002 19:51:09 -0400
Message-ID: <JMEPINMLHPLMNBBANKEHGEBCCDAA.batuner@attbi.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <3CFEEF04.2030304@alum.mit.edu>
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


On OPES advertisement/notification headers:

The main idea is to let the content server know that
there is an OPES entity in the dataflow path. Adding
an "existence and capabilities" notification to request
or response does not replace tracing and reporting
mechanism, it just supplements it and helps to overcome
limitations imposed by "don't break end-to-end HTTP" rule.

If such notification is present it SHALL include:
a) OPES protocol extensions level supported, including
tracing and reporting support available;
b) method to be used by the content server to communicate
with OPES server - OPES extensions to base protocol or
out-of-band. In the latter case OPES server address
MUST be included.

It MAY also include:

c) OPES server origin-of-authority address (if one is different
from the OPES server itself and the OPES server is willing to
expose one). This may be useful for out-of-band negotiations
(for example getting/checking authorization for certain actions
or signing up for pay-per-use services);
d) services or classes of services available.

I don't think such notification creates a scalability
problem - number of OPES servers in a particular dataflow is
very limited. The main goal of notification is not to advertise
all available services or their classes (though this also may
be feasible in some cases) but to declare willingness of the
OPES server to disclose its presence and negotiate services
(including tracing and reporting) with the content server
or user agent.

Oskar


> -----Original Message-----
> From: owner-ietf-openproxy@mail.imc.org
> [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of The Purple Streak
> (Hilarie Orman)
> Sent: Thursday, June 06, 2002 1:12 AM
> To: OPES Group
> Subject: Re: Content Provider Notification
>
>
>
> My comments are inline headed by [HKO].
>
> Oskar Batuner wrote:
>
> >
> >>-----Original Message-----
> >>From: owner-ietf-openproxy@mail.imc.org
> >>[mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of John Morris
> >>Sent: Wednesday, June 05, 2002 3:26 PM
> >>To: The Purple Streak (Hilarie Orman)
> >>Cc: OPES Group
> >>Subject: Re: Content Provider Notification
> >>
> >>
> >>
> >>Some comments inline.....
> >>
> >>At 06:46 PM 6/4/02 -0600, The Purple Streak (Hilarie Orman) wrote:
> >>
> >>
> > [..............}
> >
> >
> >>Let me float a simpler and still plausible approach:
> >>
> >>1.  By default, no client-to-server notice is necessary.
> >>2.  For the limited number of servers that care, they can send
> >>out an "are
> >>you planning to OPES" inquiry before filling the client's request.
>
>
> [HKO] Reading the IAB considerations carefully, and noting that the
> content provider is only interested in corrupted or malicious OPES
> services, one finds that this would not be a limited number of servers,
> it would probably be almost all servers.  Also, as an aside, note that
> this inquiry itself could be implemented as an OPES service by a
> content distributor.
>
> [HKO] Further, the OPES intermediary will not, in general, forward
> every request for a particular piece of content back to the content
> provider.  Thus, the best that could be done is for the content to
> contain some header saying "please notify me each time you serve this
> content with an OPES service applied", because in general, whether or
> not an OPES service is applied will depend on some attributes particular
> to the requestor.
>
>
> >>3.  The client side OPES operator would be able to respond to
> the inquiry
> >>in the hope of satisfying whatever concern the server might
> have,  UNLESS
> >>in initially requesting the service from the OPES provider the
> >>client said
> >>"do not give notice to the server."
> >>
> >
> > This mode of operation requires all participants to be
> OPES-enabled, very
> > strict limitation. If in response to request from the standard
> > browser comes inquiry (2) - well, this just means that the server
> > breaks HTTP and browser may behave unpredictably.
> >
> > I think the same goal may be achieved (even more efficiently)
> by adding to
> > the request coming through the OPES proxy an additional header - OPES
> > advertisement (again, if permitted/instructed by the end user). Non-OPES
> > enabled server will simply ignore this additional header;
> OPES-enabled one
> > may add some instructions to the response.
>
>
> [HKO] But in general, the decision about applying an OPES service will
> not be made until the content arrives at the OPES box, so the
> notification cannot travel with the request.  I suppose all potential
> OPES services could be listed in the request, but that seems unscalable
> because it discourages adminstrators from installing services - they
> cause request bloat.
>
>
> >
> > As a side effect I'd suggest to add an explicit architectural
> requirement
> > that the presence of OPES server in the dataflow SHALL NOT disrupt
> > operations of non-OPES aware clients and servers. OPES server, content
> > server and content consumer MAY use OPES extensions to the base protocol
> > (HTTP), but support of these extensions SHALL NOT be required.
>
>
> If you can amplify "disrupt" reasonably I'd probably agree with this
> suggestion.
>
>
> >
> > Oskar
>
>
> Hilarie
>
>



From owner-ietf-openproxy@mail.imc.org  Thu Jun  6 20:38:11 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20528
	for <opes-archive@ietf.org>; Thu, 6 Jun 2002 20:38:10 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5706Nl11231
	for ietf-openproxy-bks; Thu, 6 Jun 2002 17:06:23 -0700 (PDT)
Received: from mgr3.xmission.com (mgr3.xmission.com [198.60.22.203])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5706Mn11227
	for <ietf-openproxy@imc.org>; Thu, 6 Jun 2002 17:06:22 -0700 (PDT)
Received: from mail by mgr3.xmission.com with spam-scanned (Exim 3.35 #1)
	id 17G7Gr-0007wk-00
	for ietf-openproxy@imc.org; Thu, 06 Jun 2002 18:06:25 -0600
Received: from [198.60.22.200] (helo=mail.xmission.com)
	by mgr3.xmission.com with esmtp (Exim 3.35 #1)
	id 17G7Gr-0007wh-00
	for ietf-openproxy@imc.org; Thu, 06 Jun 2002 18:06:25 -0600
Received: from [166.70.13.2] (helo=alum.mit.edu)
	by mail.xmission.com with esmtp (Exim 3.22 #1)
	id 17G7Gp-0007xE-00
	for ietf-openproxy@imc.org; Thu, 06 Jun 2002 18:06:23 -0600
Message-ID: <3CFFF7B5.8060405@alum.mit.edu>
Date: Thu, 06 Jun 2002 18:00:53 -0600
From: "The Purple Streak (Hilarie Orman)" <ho@alum.mit.edu>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
CC: OPES Group <ietf-openproxy@imc.org>
Subject: Re: Content Provider Notification
References: <JMEPINMLHPLMNBBANKEHGEBCCDAA.batuner@attbi.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=0.9 required=8.0 tests=MISSING_HEADERS version=2.20
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit




Oskar Batuner wrote:

> On OPES advertisement/notification headers:
> 
> The main idea is to let the content server know that
> there is an OPES entity in the dataflow path. Adding
> an "existence and capabilities" notification to request
> or response does not replace tracing and reporting
> mechanism, it just supplements it and helps to overcome
> limitations imposed by "don't break end-to-end HTTP" rule.
> 
> If such notification is present it SHALL include:
> a) OPES protocol extensions level supported, including
> tracing and reporting support available;
> b) method to be used by the content server to communicate
> with OPES server - OPES extensions to base protocol or
> out-of-band. In the latter case OPES server address
> MUST be included.


[HKO] This implies that there is a new communication protocol and
that the OPES server MUST be directly addressable from outside
the content path.  That opens a security hole for DOS attacks
that didn't have to be there before.


> 
> It MAY also include:
> 
> c) OPES server origin-of-authority address (if one is different
> from the OPES server itself and the OPES server is willing to
> expose one). This may be useful for out-of-band negotiations
> (for example getting/checking authorization for certain actions
> or signing up for pay-per-use services);


[HKO] Signing up for services is not part of the OPES callout or
tracing protocol.  The architecture specifies this as a separate
function.  I don't see how an SOA in a request helps the process.


> d) services or classes of services available.


[HKO] Do you mean "available" or "might be applied sometime to the 
result of this request"?  What about subsequent requests for the
same content, requests that do not go to the origin server?  If
the OPES data processor changes it policies, must it notify all
origin servers for which it holds cached data of the changes?


> 
> I don't think such notification creates a scalability
> problem - number of OPES servers in a particular dataflow is
> very limited. The main goal of notification is not to advertise
> all available services or their classes (though this also may
> be feasible in some cases) but to declare willingness of the
> OPES server to disclose its presence and negotiate services
> (including tracing and reporting) with the content server
> or user agent.


[HKO] This extra negotiation seems to be a needless complication.

Hilarie


> 
> Oskar
> 
> 
> 
>>-----Original Message-----
>>From: owner-ietf-openproxy@mail.imc.org
>>[mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of The Purple Streak
>>(Hilarie Orman)
>>Sent: Thursday, June 06, 2002 1:12 AM
>>To: OPES Group
>>Subject: Re: Content Provider Notification
>>
>>
>>
>>My comments are inline headed by [HKO].
>>
>>Oskar Batuner wrote:
>>
>>
>>>>-----Original Message-----
>>>>From: owner-ietf-openproxy@mail.imc.org
>>>>[mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of John Morris
>>>>Sent: Wednesday, June 05, 2002 3:26 PM
>>>>To: The Purple Streak (Hilarie Orman)
>>>>Cc: OPES Group
>>>>Subject: Re: Content Provider Notification
>>>>
>>>>
>>>>
>>>>Some comments inline.....
>>>>
>>>>At 06:46 PM 6/4/02 -0600, The Purple Streak (Hilarie Orman) wrote:
>>>>
>>>>
>>>>
>>>[..............}
>>>
>>>
>>>
>>>>Let me float a simpler and still plausible approach:
>>>>
>>>>1.  By default, no client-to-server notice is necessary.
>>>>2.  For the limited number of servers that care, they can send
>>>>out an "are
>>>>you planning to OPES" inquiry before filling the client's request.
>>>>
>>
>>[HKO] Reading the IAB considerations carefully, and noting that the
>>content provider is only interested in corrupted or malicious OPES
>>services, one finds that this would not be a limited number of servers,
>>it would probably be almost all servers.  Also, as an aside, note that
>>this inquiry itself could be implemented as an OPES service by a
>>content distributor.
>>
>>[HKO] Further, the OPES intermediary will not, in general, forward
>>every request for a particular piece of content back to the content
>>provider.  Thus, the best that could be done is for the content to
>>contain some header saying "please notify me each time you serve this
>>content with an OPES service applied", because in general, whether or
>>not an OPES service is applied will depend on some attributes particular
>>to the requestor.
>>
>>
>>
>>>>3.  The client side OPES operator would be able to respond to
>>>>
>>the inquiry
>>
>>>>in the hope of satisfying whatever concern the server might
>>>>
>>have,  UNLESS
>>
>>>>in initially requesting the service from the OPES provider the
>>>>client said
>>>>"do not give notice to the server."
>>>>
>>>>
>>>This mode of operation requires all participants to be
>>>
>>OPES-enabled, very
>>
>>>strict limitation. If in response to request from the standard
>>>browser comes inquiry (2) - well, this just means that the server
>>>breaks HTTP and browser may behave unpredictably.
>>>
>>>I think the same goal may be achieved (even more efficiently)
>>>
>>by adding to
>>
>>>the request coming through the OPES proxy an additional header - OPES
>>>advertisement (again, if permitted/instructed by the end user). Non-OPES
>>>enabled server will simply ignore this additional header;
>>>
>>OPES-enabled one
>>
>>>may add some instructions to the response.
>>>
>>
>>[HKO] But in general, the decision about applying an OPES service will
>>not be made until the content arrives at the OPES box, so the
>>notification cannot travel with the request.  I suppose all potential
>>OPES services could be listed in the request, but that seems unscalable
>>because it discourages adminstrators from installing services - they
>>cause request bloat.
>>
>>
>>
>>>As a side effect I'd suggest to add an explicit architectural
>>>
>>requirement
>>
>>>that the presence of OPES server in the dataflow SHALL NOT disrupt
>>>operations of non-OPES aware clients and servers. OPES server, content
>>>server and content consumer MAY use OPES extensions to the base protocol
>>>(HTTP), but support of these extensions SHALL NOT be required.
>>>
>>
>>If you can amplify "disrupt" reasonably I'd probably agree with this
>>suggestion.
>>
>>
>>
>>>Oskar
>>>
>>
>>Hilarie
>>
>>
>>
> 
> 
> 




From owner-ietf-openproxy@mail.imc.org  Thu Jun  6 23:50:51 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02503
	for <opes-archive@ietf.org>; Thu, 6 Jun 2002 23:50:50 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g573Lmn15875
	for ietf-openproxy-bks; Thu, 6 Jun 2002 20:21:48 -0700 (PDT)
Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g573Lmn15869
	for <ietf-openproxy@imc.org>; Thu, 6 Jun 2002 20:21:48 -0700 (PDT)
Received: from oskar3 ([24.60.133.29]) by sccrmhc02.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20020607032147.VEVA975.sccrmhc02.attbi.com@oskar3>;
          Fri, 7 Jun 2002 03:21:47 +0000
From: "Oskar Batuner" <batuner@attbi.com>
To: "The Purple Streak \(Hilarie Orman\)" <ho@alum.mit.edu>
Cc: "OPES Group" <ietf-openproxy@imc.org>
Subject: RE: Content Provider Notification
Date: Thu, 6 Jun 2002 23:21:47 -0400
Message-ID: <JMEPINMLHPLMNBBANKEHGEBDCDAA.batuner@attbi.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <3CFFF7B5.8060405@alum.mit.edu>
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit




> -----Original Message-----
> From: owner-ietf-openproxy@mail.imc.org
> [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of The Purple Streak
> (Hilarie Orman)
> Sent: Thursday, June 06, 2002 8:01 PM
> Cc: OPES Group
> Subject: Re: Content Provider Notification
> 
> 
> Oskar Batuner wrote:
> 
> > On OPES advertisement/notification headers:
> > 
> > The main idea is to let the content server know that
> > there is an OPES entity in the dataflow path. Adding
> > an "existence and capabilities" notification to request
> > or response does not replace tracing and reporting
> > mechanism, it just supplements it and helps to overcome
> > limitations imposed by "don't break end-to-end HTTP" rule.
> > 
> > If such notification is present it SHALL include:
> > a) OPES protocol extensions level supported, including
> > tracing and reporting support available;
> > b) method to be used by the content server to communicate
> > with OPES server - OPES extensions to base protocol or
> > out-of-band. In the latter case OPES server address
> > MUST be included.
> 
> 
> [HKO] This implies that there is a new communication protocol and
> that the OPES server MUST be directly addressable from outside
> the content path.  That opens a security hole for DOS attacks
> that didn't have to be there before.

I'm afraid this is not exactly correct, see draft p.9: 

"One of those annotations could be a URL with more detailed
information on the transformation that occurred to the data 
on the OPES flow."  

I do not see an additional risk in both cases: If I understand 
correctly the architecture statements (like Figure 1) - OPES 
works over TCP/IP connection that terminates at OPES entity. 
This means that the entity's IP is already exposed. Explicit 
declaration just removes dependency from the underlying 
protocol and points to the address that OPES entity wants to 
use for communication. Very convenient for legitimate usage 
(may be different from the connection IP) but not essential for 
attackers - they may use IP anyway.

As for adding out-of-band capabilities - you are right about 
complexity that comes with them, but satisfying all OPES 
requirements in-band may also be tricky. It may result in 
unnecessary growth of OPES-related information added to each 
message - in-band channel may be closed after any 
request/response exchange and there will be no second 
chance to ask questions.

> > 
> > It MAY also include:
> > 
> > c) OPES server origin-of-authority address (if one is different
> > from the OPES server itself and the OPES server is willing to
> > expose one). This may be useful for out-of-band negotiations
> > (for example getting/checking authorization for certain actions
> > or signing up for pay-per-use services);
> 
> 
> [HKO] Signing up for services is not part of the OPES callout or
> tracing protocol.  The architecture specifies this as a separate
> function.  I don't see how an SOA in a request helps the process.
> 

Let's suppose some service requires authorization for usage or 
control. Content server (or user agent) may go to the SOA 
server and get an authorization. How this is done is outside 
of OPES architecture. But then this authorization will be 
included into all (restricted) instructions to the OPES 
server - probably using OPES extension to the base 
protocol.   

> 
> > d) services or classes of services available.
> 
> 
> [HKO] Do you mean "available" or "might be applied sometime to the 
> result of this request"?  What about subsequent requests for the
> same content, requests that do not go to the origin server?  If
> the OPES data processor changes it policies, must it notify all
> origin servers for which it holds cached data of the changes?

I mean "available in general". As you've pointed out earlier 
it may be not possible to determine what rules will be applied 
without analyzing the response, and I do not propose notifying 
server of all possible variations.

The goal is to give the server (or user agent) a possibility to 
add some advise/instructions related to the specific service 
class. Some (naive) examples are:

"I'm a translation service" - "Include original text with 
translation"

"I'm going to insert regional ads" - "Sports related will 
work best with this content"

Due to the generic nature of such instructions they remain 
valid for subsequent requests for the same content, change 
of OPES policy just affects the way instructions are applied. 
 
> 
> 
> > 
> > I don't think such notification creates a scalability
> > problem - number of OPES servers in a particular dataflow is
> > very limited. The main goal of notification is not to advertise
> > all available services or their classes (though this also may
> > be feasible in some cases) but to declare willingness of the
> > OPES server to disclose its presence and negotiate services
> > (including tracing and reporting) with the content server
> > or user agent.
> 
> 
> [HKO] This extra negotiation seems to be a needless complication.

Sorry, maybe I've used a wrong word. Here by negotiations I mean 
willingness to take into account OPES-related instructions/advice 
from the server or user agent and ability to satisfy inquiries 
like those proposed by John Morris. BTW such inquiry is a good 
candidate for out-of-band communications.

Oskar
  


From owner-ietf-openproxy@mail.imc.org  Sat Jun  8 09:53:43 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06725
	for <opes-archive@ietf.org>; Sat, 8 Jun 2002 09:53:42 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g58DQEb24822
	for ietf-openproxy-bks; Sat, 8 Jun 2002 06:26:14 -0700 (PDT)
Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g58DQ9n24810
	for <ietf-openproxy@imc.org>; Sat, 8 Jun 2002 06:26:13 -0700 (PDT)
Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215])
 by mtaout01.icomcast.net
 (iPlanet Messaging Server 5.1 HotFix 0.8 (built May 13 2002))
 with ESMTP id <0GXE006T22MD6O@mtaout01.icomcast.net> for
 ietf-openproxy@imc.org; Sat, 08 Jun 2002 09:25:25 -0400 (EDT)
Date: Sat, 08 Jun 2002 09:25:24 -0400
From: Markus Hofmann <markus@mhof.com>
Subject: FYI - Meeting Schedule
To: OPES Group <ietf-openproxy@imc.org>
Message-id: <3D0205C4.8030906@mhof.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0)
 Gecko/20020530
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7BIT


Hi,

we're tentatively scheduled to meet in Yokohama in the afternoon of 
Tuesday, July 17, from 1700-1800. Please be aware that this is a 
tentative agenda, which have shown to be quite fluid in the past., so 
this migt not be our final slot!!!

-Markus

 > TUESDAY, July 16, 2002
 >
 > 1700-1800 Afternoon Sessions IV
 > APP     opes      Open Pluggable Edge Services WG
 > INT     send      SEcuring Neighbor Discovery BOF
 > RTG     vrrp      Virtual Router Redundancy Protocol WG
 > OPS     bridge    Bridge MIB WG
 > TSV     tsvwg     Transport Area Working Group WG



From owner-ietf-openproxy@mail.imc.org  Mon Jun 10 14:19:41 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17420
	for <opes-archive@ietf.org>; Mon, 10 Jun 2002 14:19:40 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5AGiSZ18134
	for ietf-openproxy-bks; Mon, 10 Jun 2002 09:44:28 -0700 (PDT)
Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5AGiQn18129
	for <ietf-openproxy@imc.org>; Mon, 10 Jun 2002 09:44:27 -0700 (PDT)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5AGiGg27331;
	Mon, 10 Jun 2002 12:44:16 -0400 (EDT)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <KTYBRW1S>; Mon, 10 Jun 2002 12:44:15 -0400
Message-ID: <87609AFB433BD5118D5E0002A52CD754026EEC22@zcard0k6.ca.nortel.com>
From: "Abbie Barbir" <abbieb@nortelnetworks.com>
To: OPES Group <ietf-openproxy@imc.org>
Cc: "The Purple Streak (Hilarie Orman)" <ho@alum.mit.edu>,
        Markus Hofmann
	 <markus@mhof.com>,
        Marshall Rose <mrose@dbc.mtview.ca.us>
Subject:  Content Provider Notification: Summary: Please provide feedback 
	ASAP
Date: Mon, 10 Jun 2002 12:44:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2109E.097308EA"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2109E.097308EA
Content-Type: text/plain;
	charset="iso-8859-1"

All,

Following the thread on Content Provider Notification, it seems to me that
no 
conclusion could be made about the course of action.

There were proposals and counter proposals with no way of determining that a

general conclusion that the group could live with was reached.

However, it seems to me that if properly phrased, the following should be
added to 
the architecture document.

"
The presence of an OPES processor in the data request/responce flow SHALL
NOT 
interfere with the operations of non-OPES aware clients and servers. OPES 
processors, content server and content consumer MAY use OPES extensions to 
the base protocol (HTTP), but support of these extensions SHALL NOT be
required."

I am proposing to add this extra requirement to the architecture document 
provided that i do not get negative feedback(S).

Furtheremore, I think that the topic of general notification should be
delayed 
for a later stage. This will be mentioned in the draft also.


Please give feedback by the end of the day. The new -01 draft will be
comming out soon.

Abbie




------_=_NextPart_001_01C2109E.097308EA
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE> Content Provider Notification: Summary: Please provide feedback ASAP</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>All,</FONT>
</P>

<P><FONT SIZE=2>Following the thread on Content Provider Notification, it seems to me that no </FONT>
<BR><FONT SIZE=2>conclusion could be made about the course of action.</FONT>
</P>

<P><FONT SIZE=2>There were proposals and counter proposals with no way of determining that a </FONT>
<BR><FONT SIZE=2>general conclusion that the group could live with was reached.</FONT>
</P>

<P><FONT SIZE=2>However, it seems to me that if properly phrased, the following should be added to </FONT>
<BR><FONT SIZE=2>the architecture document.</FONT>
</P>

<P><FONT SIZE=2>&quot;</FONT>
<BR><FONT SIZE=2>The presence of an OPES processor in the data request/responce flow SHALL NOT </FONT>
<BR><FONT SIZE=2>interfere with the operations of non-OPES aware clients and servers. OPES </FONT>
<BR><FONT SIZE=2>processors, content server and content consumer MAY use OPES extensions to </FONT>
<BR><FONT SIZE=2>the base protocol (HTTP), but support of these extensions SHALL NOT be required.&quot;</FONT>
</P>

<P><FONT SIZE=2>I am proposing to add this extra requirement to the architecture document </FONT>
<BR><FONT SIZE=2>provided that i do not get negative feedback(S).</FONT>
</P>

<P><FONT SIZE=2>Furtheremore, I think that the topic of general notification should be delayed </FONT>
<BR><FONT SIZE=2>for a later stage. This will be mentioned in the draft also.</FONT>
</P>
<BR>

<P><FONT SIZE=2>Please give feedback by the end of the day. The new -01 draft will be comming out soon.</FONT>
</P>

<P><FONT SIZE=2>Abbie</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C2109E.097308EA--


From owner-ietf-openproxy@mail.imc.org  Mon Jun 10 15:03:47 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19651
	for <opes-archive@ietf.org>; Mon, 10 Jun 2002 15:03:46 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g5AIbPF23505
	for ietf-openproxy-bks; Mon, 10 Jun 2002 11:37:25 -0700 (PDT)
Received: from mgr2.xmission.com (mgr2.xmission.com [198.60.22.202])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5AIbOn23498
	for <ietf-openproxy@imc.org>; Mon, 10 Jun 2002 11:37:24 -0700 (PDT)
Received: from mail by mgr2.xmission.com with spam-scanned (Exim 3.35 #1)
	id 17HU2g-0003IU-00; Mon, 10 Jun 2002 12:37:26 -0600
Received: from [198.60.22.200] (helo=mail.xmission.com)
	by mgr2.xmission.com with esmtp (Exim 3.35 #1)
	id 17HU2g-0003IR-00; Mon, 10 Jun 2002 12:37:26 -0600
Received: from [166.70.2.217] (helo=alum.mit.edu)
	by mail.xmission.com with esmtp (Exim 3.22 #1)
	id 17HU2f-0002OP-00; Mon, 10 Jun 2002 12:37:25 -0600
Message-ID: <3D04EC31.4040004@alum.mit.edu>
Date: Mon, 10 Jun 2002 12:13:05 -0600
From: "The Purple Streak (Hilarie Orman)" <ho@alum.mit.edu>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Abbie Barbir <abbieb@nortelnetworks.com>
CC: OPES Group <ietf-openproxy@imc.org>
Subject: Re: Content Provider Notification: Summary: Please provide feedback 	ASAP
References: <87609AFB433BD5118D5E0002A52CD754026EEC22@zcard0k6.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=2.7 required=8.0 tests=SUBJ_HAS_SPACES version=2.20
X-Spam-Level: **
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


Fine with me.

Hilarie

Abbie Barbir wrote:

> All,
> 
> Following the thread on Content Provider Notification, it seems to me 
> that no
> conclusion could be made about the course of action.
> 
> There were proposals and counter proposals with no way of determining 
> that a
> general conclusion that the group could live with was reached.
> 
> However, it seems to me that if properly phrased, the following should 
> be added to
> the architecture document.
> 
> "
> The presence of an OPES processor in the data request/responce flow 
> SHALL NOT
> interfere with the operations of non-OPES aware clients and servers. OPES
> processors, content server and content consumer MAY use OPES extensions to
> the base protocol (HTTP), but support of these extensions SHALL NOT be 
> required."
> 
> I am proposing to add this extra requirement to the architecture document
> provided that i do not get negative feedback(S).
> 
> Furtheremore, I think that the topic of general notification should be 
> delayed
> for a later stage. This will be mentioned in the draft also.
> 
> 
> Please give feedback by the end of the day. The new -01 draft will be 
> comming out soon.
> 
> Abbie
> 
> 
> 




From owner-ietf-openproxy@mail.imc.org  Mon Jun 10 15:49:04 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22108
	for <opes-archive@ietf.org>; Mon, 10 Jun 2002 15:49:04 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g5AJPgO27527
	for ietf-openproxy-bks; Mon, 10 Jun 2002 12:25:42 -0700 (PDT)
Received: from esarhaddon.ability.net (esarhaddon.ability.net [216.3.3.68])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5AJPfn27523
	for <ietf-openproxy@imc.org>; Mon, 10 Jun 2002 12:25:41 -0700 (PDT)
Received: from [10.0.1.28] (66.safeclick.net [63.119.245.66])
	by esarhaddon.ability.net (8.11.6/8.11.6) with ESMTP id g5AJPPx22680;
	Mon, 10 Jun 2002 15:25:27 -0400
Mime-Version: 1.0
X-Sender: john@mail.cdtmail.org
Message-Id: <v04220803b92aa7bc495f@[10.0.1.28]>
In-Reply-To: 
 <87609AFB433BD5118D5E0002A52CD754026EEC22@zcard0k6.ca.nortel.com>
References: 
 <87609AFB433BD5118D5E0002A52CD754026EEC22@zcard0k6.ca.nortel.com>
Date: Mon, 10 Jun 2002 15:25:23 -0400
To: "Abbie Barbir" <abbieb@nortelnetworks.com>
From: John Morris <jmorris@cdt.org>
Subject: Re: Content Provider Notification: Summary: Please provide
 feedback  	ASAP
Cc: OPES Group <ietf-openproxy@imc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


At 12:44 PM -0400 6/10/02, Abbie Barbir wrote:
><snip>
>Furtheremore, I think that the topic of general notification should be delayed
>for a later stage. This will be mentioned in the draft also.
>

I don't have any problem delaying the notification issue at this 
point, but it does strike me that addressing the IAB's concerns on 
notification could possibly require "architectural" elements -- but 
also might possibly not.  Some of Oskar Batuner's suggestions seem to 
help and may not change any architecture.

I also agree with Oskar's concern that a server veto of a client-side 
virus checking OPES service would not be acceptable -- unless the 
server's veto was manifested by a simple refusal to serve the 
requested content.  In most cases, the server will want 
viewers/users/visitors, and so will have an incentive NOT to veto 
reasonable OPES services.

We obviously will have to think carefully about whether server 
review/consent/veto of client-side OPES services will be viable.  I 
would suggest, however, that the WG not reject the concept entirely, 
because I think it very likely that (a) client-side OPES services 
will be used to do things that some servers/content-owners do not 
like, and (b) those servers/content-owners will take action to block 
or break those OPES services.  The WG might well in the long run be 
avoiding problems if it can devise a way to give servers appropriate 
notice of client-side OPES services.

John



From owner-ietf-openproxy@mail.imc.org  Mon Jun 10 18:11:02 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27704
	for <opes-archive@ietf.org>; Mon, 10 Jun 2002 18:11:01 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5ALiIN11799
	for ietf-openproxy-bks; Mon, 10 Jun 2002 14:44:18 -0700 (PDT)
Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5ALiGn11794
	for <ietf-openproxy@imc.org>; Mon, 10 Jun 2002 14:44:17 -0700 (PDT)
Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47])
	by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5ALiDH08431;
	Mon, 10 Jun 2002 16:44:14 -0500 (CDT)
Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19)
	id <MS9G41VL>; Mon, 10 Jun 2002 14:43:57 -0700
Message-ID: <7B802811BE77D51189910002A55CFD2C02AE872A@zsc3c032.us.nortel.com>
From: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>
To: Martin Stecher <martin.stecher@webwasher.com>,
        Andre Beck
	 <abeck@bell-labs.com>
Cc: OPES Group <ietf-openproxy@imc.org>
Subject: RE: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-
	reqs-00.txt
Date: Mon, 10 Jun 2002 14:43:56 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C210C7.EC38FAEE"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C210C7.EC38FAEE
Content-Type: text/plain;
	charset="utf-8"

Hello Martin,

>-----Original Message-----
>From: Martin Stecher [mailto:martin.stecher@webwasher.com]
>Sent: Thursday, June 06, 2002 9:26 AM
>To: Andre Beck
>Cc: OPES Group
>Subject: RE:
>http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-re
>qs-00.txt
>
>
>
>My point is:
>
>I see this protocol having (at least) two purposes:
>1. Preparation to create a good OPES callout protocol
>2. Being an evaluation basis for any other wannabe callout protocol
>
>For number 1 we will obviously want to design a protocol that meets all
>MUST and SHOULD requirements, i.e. the OPES protocol will include these
>keep-alive messages.
>
>But having more MUST requirements than necessary means that evaluation
>of other protocols will be less detailed.

or we won't be wasting time evaluating protocols that do not comply..

>
>ICAP as an example:
>That protocol uses persistent connections but misses the keep-alive
>messages. Timing out the connections works but puts more responsibility
>to the client side. An ICAP client has at least to keep the last chunk
>of application data in order to recover from a connection that is just
>about to be closed by the ICAP server and to make a retry or to connect
>to an alternate server.
>This is a less good solution and it shows that ICAP/1.0 cannot be the
>final OPES protocol but I still think that ICAP somehow addresses the
>idea of persistent channels and should receive a better evaluation than
>a very simple protocol that does not offer this at all.
>
>And that's why I think a SHOULD for this section is a good choice.

I'm not sure I agree with this...It seems you are asking for SHOULD in order
to make ICAP a more viable solution. I have nothing against ICAP, but the
idea of the requirements draft (which I stated on the last IETF
presentation), was to have a clean slate and not to think on any existing
protocols while we write the draft.

For continuity sake let me say that I read your argument regarding the
keepalive as a capability message. As Andre put it I do not consider it very
efficient and it complicates the semantics of the capability message, which
now can be used for keep alives. We have several protocols that use some
type of special 'hello' message and also have capability negotiation and
they are different things. 

Also, I would like to decoupled for the sake of this discussion the
importance of kepalives and how it will be done. 

So, if you think having keepalives as a SHOULD is the right thing to do from
a deployment/technical perspective than I would like to hear your arguments
why, otherwise having it as a SHOULD because of protocol X or Y, then I'm
not sure I agree. 

regards,

Reinaldo




>
>Martin
>
>> -----Original Message-----
>> From: Andre Beck [mailto:abeck@bell-labs.com]
>> Sent: Thursday, June 06, 2002 5:15 PM
>> To: Martin Stecher
>> Cc: OPES Group
>> Subject: Re:
>> http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-r
>> eqs-00.txt
>> 
>> 
>> Hi Martin,
>> 
>> >>True, but the difference is that HTTP servers typically can 
>> use some 
>> >>sort of time-out mechanism to close idling persistent 
>> connections and 
>> >>free resources. Callout servers can't do that because such 
>> a behavior 
>> >>could result in the loss of application message data and the OPES 
>> >>processor may not necessarily be able to repeat a callout 
>> >>request (since 
>> >>it cannot always keep a copy of application messages).
>> > 
>> > Think of a very simple callout protocol that starts each 
>> request with a
>> > little handshake before application data is transfered 
>> (like in SMTP).
>> > For such a protocol it will be possible to timeout a 
>> connection by the
>> > callout server without loosing data if the next request is 
>> just about to
>> > be sent in this moment.
>> 
>> I agree, but this approach would kind of defeat the purpose 
>of why we 
>> want to use persistent connections in the first place, i.e. to avoid 
>> handshakes and the like before each and every callout transaction.
>> 
>> > 
>> >>Yes, this would be feasible (but not necessarily very efficient).
>> > 
>> > Absolutely. And that's why an OPES protocol SHOULD offer a 
>> keep-alive
>> > mechanism.
>> 
>> How about we leave the requirement for a keep-alive mechanism in the 
>> document, but add a sentence that says that the callout protocol MAY 
>> choose to use an implicit mechanism in order to check the 
>> health status 
>> of a callout connection endpoint, e.g. the parameter 
>> negotiation process.
>> 
>> -Andre
>> 
>> 
>> 
>> 
>> 
>

------_=_NextPart_001_01C210C7.EC38FAEE
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dutf-8">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: =
http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-reqs-00.txt=
</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hello Martin,</FONT>
</P>

<P><FONT SIZE=3D2>&gt;-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;From: Martin Stecher [<A =
HREF=3D"mailto:martin.stecher@webwasher.com">mailto:martin.stecher@webwa=
sher.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt;Sent: Thursday, June 06, 2002 9:26 AM</FONT>
<BR><FONT SIZE=3D2>&gt;To: Andre Beck</FONT>
<BR><FONT SIZE=3D2>&gt;Cc: OPES Group</FONT>
<BR><FONT SIZE=3D2>&gt;Subject: RE:</FONT>
<BR><FONT SIZE=3D2>&gt;<A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-re"=
 =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-opes-pr=
otocol-re</A></FONT>
<BR><FONT SIZE=3D2>&gt;qs-00.txt</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;My point is:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;I see this protocol having (at least) two =
purposes:</FONT>
<BR><FONT SIZE=3D2>&gt;1. Preparation to create a good OPES callout =
protocol</FONT>
<BR><FONT SIZE=3D2>&gt;2. Being an evaluation basis for any other =
wannabe callout protocol</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;For number 1 we will obviously want to design a =
protocol that meets all</FONT>
<BR><FONT SIZE=3D2>&gt;MUST and SHOULD requirements, i.e. the OPES =
protocol will include these</FONT>
<BR><FONT SIZE=3D2>&gt;keep-alive messages.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;But having more MUST requirements than necessary =
means that evaluation</FONT>
<BR><FONT SIZE=3D2>&gt;of other protocols will be less detailed.</FONT>
</P>

<P><FONT SIZE=3D2>or we won't be wasting time evaluating protocols that =
do not comply..</FONT>
</P>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;ICAP as an example:</FONT>
<BR><FONT SIZE=3D2>&gt;That protocol uses persistent connections but =
misses the keep-alive</FONT>
<BR><FONT SIZE=3D2>&gt;messages. Timing out the connections works but =
puts more responsibility</FONT>
<BR><FONT SIZE=3D2>&gt;to the client side. An ICAP client has at least =
to keep the last chunk</FONT>
<BR><FONT SIZE=3D2>&gt;of application data in order to recover from a =
connection that is just</FONT>
<BR><FONT SIZE=3D2>&gt;about to be closed by the ICAP server and to =
make a retry or to connect</FONT>
<BR><FONT SIZE=3D2>&gt;to an alternate server.</FONT>
<BR><FONT SIZE=3D2>&gt;This is a less good solution and it shows that =
ICAP/1.0 cannot be the</FONT>
<BR><FONT SIZE=3D2>&gt;final OPES protocol but I still think that ICAP =
somehow addresses the</FONT>
<BR><FONT SIZE=3D2>&gt;idea of persistent channels and should receive a =
better evaluation than</FONT>
<BR><FONT SIZE=3D2>&gt;a very simple protocol that does not offer this =
at all.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;And that's why I think a SHOULD for this section =
is a good choice.</FONT>
</P>

<P><FONT SIZE=3D2>I'm not sure I agree with this...It seems you are =
asking for SHOULD in order to make ICAP a more viable solution. I have =
nothing against ICAP, but the idea of the requirements draft (which I =
stated on the last IETF presentation), was to have a clean slate and =
not to think on any existing protocols while we write the =
draft.</FONT></P>

<P><FONT SIZE=3D2>For continuity sake let me say that I read your =
argument regarding the keepalive as a capability message. As Andre put =
it I do not consider it very efficient and it complicates the semantics =
of the capability message, which now can be used for keep alives. We =
have several protocols that use some type of special 'hello' message =
and also have capability negotiation and they are different things. =
</FONT></P>

<P><FONT SIZE=3D2>Also, I would like to decoupled for the sake of this =
discussion the importance of kepalives and how it will be done. </FONT>
</P>

<P><FONT SIZE=3D2>So, if you think having keepalives as a SHOULD is the =
right thing to do from a deployment/technical perspective than I would =
like to hear your arguments why, otherwise having it as a SHOULD =
because of protocol X or Y, then I'm not sure I agree. </FONT></P>

<P><FONT SIZE=3D2>regards,</FONT>
</P>

<P><FONT SIZE=3D2>Reinaldo</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Martin</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; From: Andre Beck [<A =
HREF=3D"mailto:abeck@bell-labs.com">mailto:abeck@bell-labs.com</A>]</FON=
T>
<BR><FONT SIZE=3D2>&gt;&gt; Sent: Thursday, June 06, 2002 5:15 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; To: Martin Stecher</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Cc: OPES Group</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Subject: Re:</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; <A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-r" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-opes-pr=
otocol-r</A></FONT>
<BR><FONT SIZE=3D2>&gt;&gt; eqs-00.txt</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Hi Martin,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt;&gt;True, but the difference is that =
HTTP servers typically can </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; use some </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt;&gt;sort of time-out mechanism to close =
idling persistent </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; connections and </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt;&gt;free resources. Callout servers =
can't do that because such </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; a behavior </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt;&gt;could result in the loss of =
application message data and the OPES </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt;&gt;processor may not necessarily be =
able to repeat a callout </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt;&gt;request (since </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt;&gt;it cannot always keep a copy of =
application messages).</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt; Think of a very simple callout =
protocol that starts each </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; request with a</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt; little handshake before application =
data is transfered </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; (like in SMTP).</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt; For such a protocol it will be =
possible to timeout a </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; connection by the</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt; callout server without loosing data if =
the next request is </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; just about to</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt; be sent in this moment.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; I agree, but this approach would kind of =
defeat the purpose </FONT>
<BR><FONT SIZE=3D2>&gt;of why we </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; want to use persistent connections in the =
first place, i.e. to avoid </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; handshakes and the like before each and =
every callout transaction.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt;&gt;Yes, this would be feasible (but =
not necessarily very efficient).</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt; Absolutely. And that's why an OPES =
protocol SHOULD offer a </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; keep-alive</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &gt; mechanism.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; How about we leave the requirement for a =
keep-alive mechanism in the </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; document, but add a sentence that says that =
the callout protocol MAY </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; choose to use an implicit mechanism in =
order to check the </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; health status </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; of a callout connection endpoint, e.g. the =
parameter </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; negotiation process.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; -Andre</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C210C7.EC38FAEE--


From owner-ietf-openproxy@mail.imc.org  Mon Jun 10 18:58:06 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28737
	for <opes-archive@ietf.org>; Mon, 10 Jun 2002 18:58:05 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5AMXLp17955
	for ietf-openproxy-bks; Mon, 10 Jun 2002 15:33:21 -0700 (PDT)
Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5AMXKn17951
	for <ietf-openproxy@imc.org>; Mon, 10 Jun 2002 15:33:20 -0700 (PDT)
Received: from oskar3 ([24.60.133.29]) by rwcrmhc52.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20020610223227.YZCE2751.rwcrmhc52.attbi.com@oskar3>;
          Mon, 10 Jun 2002 22:32:27 +0000
From: "Oskar Batuner" <batuner@attbi.com>
To: "John Morris" <jmorris@cdt.org>
Cc: "OPES Group" <ietf-openproxy@imc.org>
Subject: RE: Content Provider Notification: Summary: Please provide feedback  	ASAP
Date: Mon, 10 Jun 2002 18:32:28 -0400
Message-ID: <JMEPINMLHPLMNBBANKEHIEBOCDAA.batuner@attbi.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <v04220803b92aa7bc495f@[10.0.1.28]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


John, it looks like there are two main differences in
our approach:

1. You are looking at OPES as enabling technology that makes possible
things that do not exist now. I look at OPES mainly as a technology
standard that may facilitate deployment of services that do already
exist but are deployed in a less efficient/controllable way (like
filters, edge services, etc.)

As a result you are more concerned with the ability of new OPES
entities to affect end-to-end interaction between content producers
and content consumers. On another hand I think that with the proper
architecture and taking into account IAB requirements (RFC3238),
especially  requirement of explicit authorization, OPES does not
create a situation that is substantially different from the existing
one. OPES deals with the threats that already exist (Trojans, spyware,
server security flaws, etc.).

OPES development requires careful consideration of all possible
threats but as a result I'd really like to see new
security/authorization/tracing/reporting methods and standards that
are equally applicable to both OPES and non-OPES systems.

2. You are looking at "good guys" environment - both sides are
perusing legitimate goals but may have different interests.
I'm looking also at "bad guys" - viruses, worms, DDoS bots,
spyware, persistent distributors of unwanted information and
the like.

"Bad guys" can not be trusted and have no legitimate
interests that should be protected in any way. In situations
of conflict between protection of legitimate content
distributor rights and protection of end user from malicious
intents I usually sympathize with the end-user.

Oskar



> -----Original Message-----
> From: owner-ietf-openproxy@mail.imc.org
> [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of John Morris
> Sent: Monday, June 10, 2002 3:25 PM
> To: Abbie Barbir
> Cc: OPES Group
> Subject: Re: Content Provider Notification: Summary: Please provide
> feedback ASAP
>
>
>
> At 12:44 PM -0400 6/10/02, Abbie Barbir wrote:
> ><snip>
> >Furtheremore, I think that the topic of general notification
> should be delayed
> >for a later stage. This will be mentioned in the draft also.
> >
>
> I don't have any problem delaying the notification issue at this
> point, but it does strike me that addressing the IAB's concerns on
> notification could possibly require "architectural" elements -- but
> also might possibly not.  Some of Oskar Batuner's suggestions seem to
> help and may not change any architecture.
>
> I also agree with Oskar's concern that a server veto of a client-side
> virus checking OPES service would not be acceptable -- unless the
> server's veto was manifested by a simple refusal to serve the
> requested content.  In most cases, the server will want
> viewers/users/visitors, and so will have an incentive NOT to veto
> reasonable OPES services.
>
> We obviously will have to think carefully about whether server
> review/consent/veto of client-side OPES services will be viable.  I
> would suggest, however, that the WG not reject the concept entirely,
> because I think it very likely that (a) client-side OPES services
> will be used to do things that some servers/content-owners do not
> like, and (b) those servers/content-owners will take action to block
> or break those OPES services.  The WG might well in the long run be
> avoiding problems if it can devise a way to give servers appropriate
> notice of client-side OPES services.
>
> John
>



From owner-ietf-openproxy@mail.imc.org  Mon Jun 10 20:30:04 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29877
	for <opes-archive@ietf.org>; Mon, 10 Jun 2002 20:30:03 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5B01Sm00108
	for ietf-openproxy-bks; Mon, 10 Jun 2002 17:01:28 -0700 (PDT)
Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5B01Rn00103
	for <ietf-openproxy@imc.org>; Mon, 10 Jun 2002 17:01:27 -0700 (PDT)
Received: from oskar3 ([24.60.133.29]) by rwcrmhc52.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20020610235134.DBKL2751.rwcrmhc52.attbi.com@oskar3>;
          Mon, 10 Jun 2002 23:51:34 +0000
From: "Oskar Batuner" <batuner@attbi.com>
To: "OPES Group" <ietf-openproxy@imc.org>
Cc: "The Purple Streak \(Hilarie Orman\)" <ho@alum.mit.edu>,
        "Markus Hofmann" <markus@mhof.com>,
        "Marshall Rose" <mrose@dbc.mtview.ca.us>
Subject: RE: Content Provider Notification: Summary: Please provide feedback ASAP
Date: Mon, 10 Jun 2002 19:51:34 -0400
Message-ID: <JMEPINMLHPLMNBBANKEHIEBPCDAA.batuner@attbi.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <87609AFB433BD5118D5E0002A52CD754026EEC22@zcard0k6.ca.nortel.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


What about some proposal from other threads that did not met
objections:

1. Introduction

>In some cases it may be impossible to offer the customization service
>at either the provider or the consumer applications. In this case,
>one or more additional application entities may participate in the
>data stream service.

This term - "impossible" - may leave an impression that this is the
only, or at least main justification to use OPES. This does not look
right. The only scenario (from existing draft-beck-opes-esfnep) where
OPES is the only way to implement the service is request filtering
for hand-held devices, in all other cases service can be implemented
either at the server side or at the client side, or both.
Still use of OPES may be beneficial, so I'd suggest ether to use
a different wording, like:

"In some cases in may be beneficial to provide a customization service
at network location instead of deploying it at either the provider or
the consumer host. For certain services performed on end-user behalf
this may be the only option of service deployment".

2. > 2.1 OPES Entities

Figure 1 should look like this:


                             +----------------+
                             | OPES service   |
                             | application    |
                             +----------------+
                             |data dispatcher |
                             +----------------+
                             |                |
                             |    HTTP        |
                             |                |
                             +----------------+
                             |   TCP/IP       |
                             +----------------+
                             |     ...        |
                             +----------------+

                    Figure 1: An OPES protocol stack


It also may have sense to point out explicitly that

"OPES application may be executed either on the same box (or
even in the same application environment) with the dispatcher
or on a different box through OCP."

I thing it has sense to emphasize this possibility and to provide a
figure like this:


        +--------------------------+
        | +----------+             |
        | |   OPES   |             |
        | |  service |             |      +----------------+
        | |   appl   |             |      | Callout Server |
        | +----------+             |      |                |
        |     ||                   |      | +--------+     |
        | +----------------------+ |      | | OPES   |     |
        | |     data dispatcher  | |      | | Service|     |
        | +----------------------+ |      | |  App2  |     |
        | |   HTTP     | OCP     | |      | +--------+     |
        | +------------|         |==========|  OCP   |     |
        | |            |---------+ |      | +--------+     |
        | |   TCP/IP   |           |      +----------------+
 =========|            |=============== OPES Data Flow ====
        | +------------+           |
        +--------------------------+


It illustrates positions and interaction of different components
of OPES architecture.

There were some other things mentioned, like use of PEP abbreviation,
but the most important are:

- Trust domains: delegation of authority (coloring) propagates
from the content producer start of authority or from the content
consumer start of authority, that may be different from the
the end points in the data flow.

- OPES processor MUST obey tracing/reporting/notification requirements
set by the center of authority in the trust domain to which OPES
processor belongs. As part of these requirements OPES processor MAY
be instructed to reject or ignore such requirements from the
the sources of a different "color".

Oskar

-----Original Message-----
From: owner-ietf-openproxy@mail.imc.org
[mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Abbie Barbir
Sent: Monday, June 10, 2002 12:44 PM
To: OPES Group
Cc: The Purple Streak (Hilarie Orman); Markus Hofmann; Marshall Rose
Subject: Content Provider Notification: Summary: Please provide feedback
ASAP


All,
Following the thread on Content Provider Notification, it seems to me that
no
conclusion could be made about the course of action.
There were proposals and counter proposals with no way of determining that a
general conclusion that the group could live with was reached.
However, it seems to me that if properly phrased, the following should be
added to
the architecture document.
"
The presence of an OPES processor in the data request/responce flow SHALL
NOT
interfere with the operations of non-OPES aware clients and servers. OPES
processors, content server and content consumer MAY use OPES extensions to
the base protocol (HTTP), but support of these extensions SHALL NOT be
required."
I am proposing to add this extra requirement to the architecture document
provided that i do not get negative feedback(S).
Furtheremore, I think that the topic of general notification should be
delayed
for a later stage. This will be mentioned in the draft also.


Please give feedback by the end of the day. The new -01 draft will be
comming out soon.
Abbie



From owner-ietf-openproxy@mail.imc.org  Tue Jun 11 04:10:25 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15822
	for <opes-archive@ietf.org>; Tue, 11 Jun 2002 04:10:24 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5B7h5x01584
	for ietf-openproxy-bks; Tue, 11 Jun 2002 00:43:05 -0700 (PDT)
Received: from hermes.webwasher.com (mail.webwasher.com [195.162.240.3])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5B7h2n01580
	for <ietf-openproxy@imc.org>; Tue, 11 Jun 2002 00:43:03 -0700 (PDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2111B.5ACB17E6"
Subject: RE: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-reqs-00.txt
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Date: Tue, 11 Jun 2002 09:41:10 +0200
Message-ID: <72992B39BBD9294BB636A960E89AE02E50BED8@hermes.webwasher.com>
Thread-Topic: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-reqs-00.txt
Thread-Index: AcIQx8SMKao0oTtUQEq8691dNReiigAT4rMw
From: "Martin Stecher" <martin.stecher@webwasher.com>
To: "Reinaldo Penno" <reinaldo_penno@nortelnetworks.com>,
        "Andre Beck" <abeck@bell-labs.com>
Cc: "OPES Group" <ietf-openproxy@imc.org>
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This is a multi-part message in MIME format.

------_=_NextPart_001_01C2111B.5ACB17E6
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

SGkgUmVpbmFsZG8sDQoNCj4gQWxzbywgSSB3b3VsZCBsaWtlIHRvIGRlY291cGxlZCBmb3IgdGhl
IHNha2Ugb2YgdGhpcyBkaXNjdXNzaW9uDQo+IHRoZSBpbXBvcnRhbmNlIG9mIGtlcGFsaXZlcyBh
bmQgaG93IGl0IHdpbGwgYmUgZG9uZS4gDQo+DQo+IFNvLCBpZiB5b3UgdGhpbmsgaGF2aW5nIGtl
ZXBhbGl2ZXMgYXMgYSBTSE9VTEQgaXMgdGhlIHJpZ2h0IHRoaW5nDQo+IHRvIGRvIGZyb20gYSBk
ZXBsb3ltZW50L3RlY2huaWNhbCBwZXJzcGVjdGl2ZSB0aGFuIEkgd291bGQgbGlrZSB0bw0KaGVh
cg0KPiB5b3VyIGFyZ3VtZW50cyB3aHksIG90aGVyd2lzZSBoYXZpbmcgaXQgYXMgYSBTSE9VTEQg
YmVjYXVzZSBvZg0KPiBwcm90b2NvbCBYIG9yIFksIHRoZW4gSSdtIG5vdCBzdXJlIEkgYWdyZWUu
IA0KIA0KSSBqdXN0IHJlYWQgYWdhaW4gdGhlIGRlZmluaXRpb25zIG9mIE1VU1QgYW5kIFNIT1VM
RCBpbiBSRkMgMjExOS4NCiANCkhvdyBjYW4gSSBhcmd1ZSBmb3IgYSBTSE9VTEQgd2l0aG91dCBz
aG93aW5nIHBhcnRpY3VsYXIgY2lyY3Vtc3RhbmNlcw0KdGhhdCBtYXkgaGF2ZSB0aGVpciB2YWxp
ZCByZWFzb25zIHRvIGRvIHdpdGhvdXQga2VlcC1hbGl2ZT8gSSBmb2xsb3cNCkFuZHJlIGFuZCB5
b3UgdGhhdCBhIHByb3RvY29sIHdpdGhvdXQga2VlcC1hbGl2ZSBoYXMgc29tZSBkaXNhZHZhbnRh
Z2VzDQphbmQgc28gdGVjaG5pY2FsIGFyZ3VtZW50cyB0byBpZ25vcmUga2VlcC1hbGl2ZSBhcmUg
d2Vhay4NCiANCkJ1dCBJIGRvIG5vdCB1bmRlcnN0YW5kIHdoeSBpdCBpcyBhbiBhYnNvbHV0ZSBy
ZXF1aXJlbWVudCB0byBoYXZlIGENCmtlZXAtYWxpdmUgbWVzc2FnZSBpbiBvcmRlciB0byBjcmVh
dGUgYSB3b3JraW5nIGNhbGxvdXQgcHJvdG9jb2wuIEFuZCBJDQphbSBtaXNzaW5nIHlvdXIgYXJn
dW1lbnRzIGZvciB0aGlzIHBvc2l0aW9uLg0KQW5kcmUgYW5kIHlvdSB0ZWxsIG1lIGFib3V0ICJs
ZXNzIGVmZmljaWVudCIgYW5kICJpdCBjb21wbGljYXRlcw0Kd2l0aG91dC4uLiIuIFRoZXNlIGFy
ZSBub3QgYXJndW1lbnRzIGZvciBhIE1VU1QsIGFyZSB0aGV5Pw0KIA0KVGhlIEFic3RyYWN0IHNl
Y3Rpb24gb2YgdGhpcyBPUEVTIGRyYWZ0IHNheXM6ICJUaGUgcmVxdWlyZW1lbnRzIGFyZQ0KaW50
ZW5kZWQgdG8gaGVscCBldmFsdWF0aW5nIHBvc3NpYmxlIHByb3RvY29sIGNhbmRpZGF0ZXMgYW5k
IHRvIGd1aWRlDQp0aGUgZGV2ZWxvcG1lbnQgb2Ygc3VjaCBwcm90b2NvbHMuIg0KIA0KSSB0aGlu
ayB0aGF0IGtlZXAtYWxpdmVzIGFzIGFuIGFic29sdXRlIHJlcXVpcmVtZW50IHdpdGhvdXQgZXhj
ZXB0aW9ucw0KaW4gcGFydGljdWxhciBjaXJjdW1zdGFuY2VzIGlzIHdyb25nIHRvIHN1cHBvcnQg
dGhpcyB0YXNrLg0KIA0KVGhlcmUgaXMgbm90aGluZyBtb3JlIEkgY2FuIHNheSBhYm91dCB0aGlz
LiBJIHdpbGwgbm90IGNvbnRpbnVlIHdpdGgNCnRoaXMgYXJndW1lbnRhdGlvbi4gSWYgeW91IGNh
bm5vdCBmb2xsb3cgbXkgYXJndW1lbnRzLCBrZWVwIHRoZSBNVVNUDQphbGl2ZSA7LSkNCiANClJl
Z2FyZHMNCk1hcnRpbg0KIA0K

------_=_NextPart_001_01C2111B.5ACB17E6
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U
RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPFRJVExFPlJFOiBodHRwOi8vd3d3Lmll
dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW9wZXMtcHJvdG9jb2wtcmVxcy0wMC50
eHQ8L1RJVExFPg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS41MC40OTE2LjIzMDAiIG5hbWU9
R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZPg0KPERJVj48U1BBTiBjbGFzcz0zMjcxMzEyMDctMTEw
NjIwMDI+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj5IaSANClJlaW5hbGRv
LDwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTMyNzEzMTIwNy0xMTA2MjAw
Mj48Rk9OVCBzaXplPTI+PFNQQU4gDQpjbGFzcz0zMjcxMzEyMDctMTEwNjIwMDI+PEJSPiZndDsg
PC9TUEFOPkFsc28sIEkgd291bGQgbGlrZSB0byBkZWNvdXBsZWQgZm9yIHRoZSANCnNha2Ugb2Yg
dGhpcyBkaXNjdXNzaW9uPEJSPjxTUEFOIGNsYXNzPTMyNzEzMTIwNy0xMTA2MjAwMj4mZ3Q7IDwv
U1BBTj50aGUgDQppbXBvcnRhbmNlIG9mIGtlcGFsaXZlcyBhbmQgaG93IGl0IHdpbGwgYmUgZG9u
ZS4mbmJzcDs8QlI+PFNQQU4gDQpjbGFzcz0zMjcxMzEyMDctMTEwNjIwMDI+PC9TUEFOPiZndDs8
QlI+PFNQQU4gY2xhc3M9MzI3MTMxMjA3LTExMDYyMDAyPiZndDsgDQo8L1NQQU4+U28sIGlmIHlv
dSB0aGluayBoYXZpbmcga2VlcGFsaXZlcyBhcyBhIFNIT1VMRCBpcyB0aGUgcmlnaHQgDQp0aGlu
ZzxCUj48U1BBTiBjbGFzcz0zMjcxMzEyMDctMTEwNjIwMDI+Jmd0OyA8L1NQQU4+dG8gZG8gZnJv
bSBhIA0KZGVwbG95bWVudC90ZWNobmljYWwgcGVyc3BlY3RpdmUgdGhhbiBJIHdvdWxkIGxpa2Ug
dG8gaGVhcjxCUj48U1BBTiANCmNsYXNzPTMyNzEzMTIwNy0xMTA2MjAwMj4mZ3Q7IDwvU1BBTj55
b3VyIGFyZ3VtZW50cyB3aHksIG90aGVyd2lzZSBoYXZpbmcgaXQgYXMgDQphIFNIT1VMRCBiZWNh
dXNlIG9mPEJSPjxTUEFOIGNsYXNzPTMyNzEzMTIwNy0xMTA2MjAwMj4mZ3Q7IDwvU1BBTj5wcm90
b2NvbCBYIG9yIA0KWSwgdGhlbiBJJ20gbm90IHN1cmUgSSBhZ3JlZS4gPC9GT05UPjwvRElWPjwv
U1BBTj4NCjxESVY+PFNQQU4gY2xhc3M9MzI3MTMxMjA3LTExMDYyMDAyPjxGT05UIGZhY2U9QXJp
YWwgY29sb3I9IzAwMDBmZiANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJ
Vj48U1BBTiBjbGFzcz0zMjcxMzEyMDctMTEwNjIwMDI+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0j
MDAwMGZmIHNpemU9Mj5JIGp1c3QgDQpyZWFkIGFnYWluIHRoZSBkZWZpbml0aW9ucyBvZiBNVVNU
IGFuZCBTSE9VTEQgaW4gUkZDIDIxMTkuPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4g
Y2xhc3M9MzI3MTMxMjA3LTExMDYyMDAyPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiAN
CnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0zMjcx
MzEyMDctMTEwNjIwMDI+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj5Ib3cg
DQpjYW4gSSBhcmd1ZSBmb3IgYSBTSE9VTEQgd2l0aG91dCBzaG93aW5nIHBhcnRpY3VsYXIgY2ly
Y3Vtc3RhbmNlcyB0aGF0IG1heSBoYXZlIA0KdGhlaXIgdmFsaWQgcmVhc29ucyB0byBkbyB3aXRo
b3V0IGtlZXAtYWxpdmU/IEkgZm9sbG93IEFuZHJlIGFuZCB5b3UgdGhhdCBhIA0KcHJvdG9jb2wg
d2l0aG91dCBrZWVwLWFsaXZlIGhhcyBzb21lIGRpc2FkdmFudGFnZXMgYW5kIHNvIHRlY2huaWNh
bCBhcmd1bWVudHMgdG8gDQppZ25vcmUga2VlcC1hbGl2ZSBhcmUgd2Vhay48L0ZPTlQ+PC9TUEFO
PjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0zMjcxMzEyMDctMTEwNjIwMDI+PEZPTlQgZmFjZT1B
cmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8
RElWPjxTUEFOIGNsYXNzPTMyNzEzMTIwNy0xMTA2MjAwMj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9y
PSMwMDAwZmYgc2l6ZT0yPkJ1dCBJIA0KZG8gbm90IHVuZGVyc3RhbmQgd2h5IGl0IGlzIGFuIGFi
c29sdXRlIHJlcXVpcmVtZW50IHRvIGhhdmUgYSBrZWVwLWFsaXZlIG1lc3NhZ2UgDQppbiBvcmRl
ciB0byBjcmVhdGUgYSB3b3JraW5nIGNhbGxvdXQgcHJvdG9jb2wuIEFuZCBJIGFtIG1pc3Npbmcg
eW91ciBhcmd1bWVudHMgDQpmb3IgdGhpcyBwb3NpdGlvbi48L0ZPTlQ+PC9TUEFOPjwvRElWPg0K
PERJVj48U1BBTiBjbGFzcz0zMjcxMzEyMDctMTEwNjIwMDI+PEZPTlQgZmFjZT1BcmlhbCBjb2xv
cj0jMDAwMGZmIHNpemU9Mj5BbmRyZSANCmFuZCB5b3UgdGVsbCBtZSBhYm91dCAibGVzcyBlZmZp
Y2llbnQiIGFuZCAiaXQgY29tcGxpY2F0ZXMgd2l0aG91dC4uLiIuIFRoZXNlIA0KYXJlIG5vdCBh
cmd1bWVudHMgZm9yIGEgTVVTVCwgYXJlIHRoZXk/PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+
PFNQQU4gY2xhc3M9MzI3MTMxMjA3LTExMDYyMDAyPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAw
MDBmZiANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFz
cz0zMjcxMzEyMDctMTEwNjIwMDI+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9
Mj5UaGUgDQpBYnN0cmFjdCBzZWN0aW9uIG9mIHRoaXMgT1BFUyBkcmFmdCBzYXlzOiAiVGhlIHJl
cXVpcmVtZW50cyBhcmUgaW50ZW5kZWQgdG8gaGVscCANCmV2YWx1YXRpbmcgcG9zc2libGUgcHJv
dG9jb2wgY2FuZGlkYXRlcyBhbmQgdG8gZ3VpZGUgdGhlIGRldmVsb3BtZW50IG9mIHN1Y2ggDQpw
cm90b2NvbHMuIjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTMyNzEzMTIw
Ny0xMTA2MjAwMj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQpzaXplPTI+PC9GT05U
PjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MzI3MTMxMjA3LTExMDYyMDAy
PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+SSANCnRoaW5rIHRoYXQmbmJz
cDtrZWVwLWFsaXZlcyBhcyBhbiBhYnNvbHV0ZSByZXF1aXJlbWVudCB3aXRob3V0IGV4Y2VwdGlv
bnMgaW4gDQpwYXJ0aWN1bGFyIGNpcmN1bXN0YW5jZXMgaXMgd3JvbmcgdG8gc3VwcG9ydCB0aGlz
IHRhc2suPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MzI3MTMxMjA3LTEx
MDYyMDAyPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9Mj48L0ZPTlQ+PC9T
UEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0zMjcxMzEyMDctMTEwNjIwMDI+PEZP
TlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj5UaGVyZSANCmlzIG5vdGhpbmcgbW9y
ZSBJIGNhbiBzYXkgYWJvdXQgdGhpcy4gSSB3aWxsIG5vdCBjb250aW51ZSB3aXRoIHRoaXMgDQph
cmd1bWVudGF0aW9uLiBJZiB5b3UgY2Fubm90IGZvbGxvdyBteSBhcmd1bWVudHMsIGtlZXAgdGhl
IE1VU1QgYWxpdmUgDQo7LSk8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz0z
MjcxMzEyMDctMTEwNjIwMDI+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0y
PjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTMyNzEzMTIwNy0x
MTA2MjAwMj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQpzaXplPTI+UmVnYXJkczwv
Rk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTMyNzEzMTIwNy0xMTA2MjAwMj48
Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQpzaXplPTI+TWFydGluPC9GT05UPjwvU1BB
Tj48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg==

------_=_NextPart_001_01C2111B.5ACB17E6--


From owner-ietf-openproxy@mail.imc.org  Tue Jun 11 10:09:22 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25041
	for <opes-archive@ietf.org>; Tue, 11 Jun 2002 10:09:21 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5BDbil02629
	for ietf-openproxy-bks; Tue, 11 Jun 2002 06:37:44 -0700 (PDT)
Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5BDbhn02622
	for <ietf-openproxy@imc.org>; Tue, 11 Jun 2002 06:37:43 -0700 (PDT)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5BDbZe09687;
	Tue, 11 Jun 2002 09:37:36 -0400 (EDT)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <KTYBS117>; Tue, 11 Jun 2002 09:37:31 -0400
Message-ID: <87609AFB433BD5118D5E0002A52CD754026EF281@zcard0k6.ca.nortel.com>
From: "Abbie Barbir" <abbieb@nortelnetworks.com>
To: Oskar Batuner <batuner@attbi.com>, OPES Group <ietf-openproxy@imc.org>
Cc: "The Purple Streak (Hilarie Orman)" <ho@alum.mit.edu>,
        Markus Hofmann
	 <markus@mhof.com>,
        Marshall Rose <mrose@dbc.mtview.ca.us>
Subject: RE: Content Provider Notification: Summary: Please provide feedba
	ck ASAP
Date: Tue, 11 Jun 2002 09:37:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2114D.2292AEAC"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2114D.2292AEAC
Content-Type: text/plain;
	charset="iso-8859-1"

oskar,

thanks,

the e-mail was specific for notification.

the other threads will be added to the draft.

thanks again

abbie


> -----Original Message-----
> From: Oskar Batuner [mailto:batuner@attbi.com]
> Sent: Monday, June 10, 2002 7:52 PM
> To: OPES Group
> Cc: The Purple Streak (Hilarie Orman); Markus Hofmann; Marshall Rose
> Subject: RE: Content Provider Notification: Summary: Please provide
> feedback ASAP
> 
> 
> 
> What about some proposal from other threads that did not met
> objections:
> 
> 1. Introduction
> 
> >In some cases it may be impossible to offer the customization service
> >at either the provider or the consumer applications. In this case,
> >one or more additional application entities may participate in the
> >data stream service.
> 
> This term - "impossible" - may leave an impression that this is the
> only, or at least main justification to use OPES. This does not look
> right. The only scenario (from existing draft-beck-opes-esfnep) where
> OPES is the only way to implement the service is request filtering
> for hand-held devices, in all other cases service can be implemented
> either at the server side or at the client side, or both.
> Still use of OPES may be beneficial, so I'd suggest ether to use
> a different wording, like:
> 
> "In some cases in may be beneficial to provide a customization service
> at network location instead of deploying it at either the provider or
> the consumer host. For certain services performed on end-user behalf
> this may be the only option of service deployment".
> 
> 2. > 2.1 OPES Entities
> 
> Figure 1 should look like this:
> 
> 
>                              +----------------+
>                              | OPES service   |
>                              | application    |
>                              +----------------+
>                              |data dispatcher |
>                              +----------------+
>                              |                |
>                              |    HTTP        |
>                              |                |
>                              +----------------+
>                              |   TCP/IP       |
>                              +----------------+
>                              |     ...        |
>                              +----------------+
> 
>                     Figure 1: An OPES protocol stack
> 
> 
> It also may have sense to point out explicitly that
> 
> "OPES application may be executed either on the same box (or
> even in the same application environment) with the dispatcher
> or on a different box through OCP."
> 
> I thing it has sense to emphasize this possibility and to provide a
> figure like this:
> 
> 
>         +--------------------------+
>         | +----------+             |
>         | |   OPES   |             |
>         | |  service |             |      +----------------+
>         | |   appl   |             |      | Callout Server |
>         | +----------+             |      |                |
>         |     ||                   |      | +--------+     |
>         | +----------------------+ |      | | OPES   |     |
>         | |     data dispatcher  | |      | | Service|     |
>         | +----------------------+ |      | |  App2  |     |
>         | |   HTTP     | OCP     | |      | +--------+     |
>         | +------------|         |==========|  OCP   |     |
>         | |            |---------+ |      | +--------+     |
>         | |   TCP/IP   |           |      +----------------+
>  =========|            |=============== OPES Data Flow ====
>         | +------------+           |
>         +--------------------------+
> 
> 
> It illustrates positions and interaction of different components
> of OPES architecture.
> 
> There were some other things mentioned, like use of PEP abbreviation,
> but the most important are:
> 
> - Trust domains: delegation of authority (coloring) propagates
> from the content producer start of authority or from the content
> consumer start of authority, that may be different from the
> the end points in the data flow.
> 
> - OPES processor MUST obey tracing/reporting/notification requirements
> set by the center of authority in the trust domain to which OPES
> processor belongs. As part of these requirements OPES processor MAY
> be instructed to reject or ignore such requirements from the
> the sources of a different "color".
> 
> Oskar
> 
> -----Original Message-----
> From: owner-ietf-openproxy@mail.imc.org
> [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Abbie Barbir
> Sent: Monday, June 10, 2002 12:44 PM
> To: OPES Group
> Cc: The Purple Streak (Hilarie Orman); Markus Hofmann; Marshall Rose
> Subject: Content Provider Notification: Summary: Please 
> provide feedback
> ASAP
> 
> 
> All,
> Following the thread on Content Provider Notification, it 
> seems to me that
> no
> conclusion could be made about the course of action.
> There were proposals and counter proposals with no way of 
> determining that a
> general conclusion that the group could live with was reached.
> However, it seems to me that if properly phrased, the 
> following should be
> added to
> the architecture document.
> "
> The presence of an OPES processor in the data 
> request/responce flow SHALL
> NOT
> interfere with the operations of non-OPES aware clients and 
> servers. OPES
> processors, content server and content consumer MAY use OPES 
> extensions to
> the base protocol (HTTP), but support of these extensions SHALL NOT be
> required."
> I am proposing to add this extra requirement to the 
> architecture document
> provided that i do not get negative feedback(S).
> Furtheremore, I think that the topic of general notification should be
> delayed
> for a later stage. This will be mentioned in the draft also.
> 
> 
> Please give feedback by the end of the day. The new -01 draft will be
> comming out soon.
> Abbie
> 
> 

------_=_NextPart_001_01C2114D.2292AEAC
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>RE: Content Provider Notification: Summary: Please provide =
feedback ASAP</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>oskar,</FONT>
</P>

<P><FONT SIZE=3D2>thanks,</FONT>
</P>

<P><FONT SIZE=3D2>the e-mail was specific for notification.</FONT>
</P>

<P><FONT SIZE=3D2>the other threads will be added to the draft.</FONT>
</P>

<P><FONT SIZE=3D2>thanks again</FONT>
</P>

<P><FONT SIZE=3D2>abbie</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Oskar Batuner [<A =
HREF=3D"mailto:batuner@attbi.com">mailto:batuner@attbi.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Monday, June 10, 2002 7:52 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: OPES Group</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: The Purple Streak (Hilarie Orman); Markus =
Hofmann; Marshall Rose</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: Content Provider Notification: =
Summary: Please provide</FONT>
<BR><FONT SIZE=3D2>&gt; feedback ASAP</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; What about some proposal from other threads =
that did not met</FONT>
<BR><FONT SIZE=3D2>&gt; objections:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 1. Introduction</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;In some cases it may be impossible to offer =
the customization service</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;at either the provider or the consumer =
applications. In this case,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;one or more additional application entities =
may participate in the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;data stream service.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This term - &quot;impossible&quot; - may leave =
an impression that this is the</FONT>
<BR><FONT SIZE=3D2>&gt; only, or at least main justification to use =
OPES. This does not look</FONT>
<BR><FONT SIZE=3D2>&gt; right. The only scenario (from existing =
draft-beck-opes-esfnep) where</FONT>
<BR><FONT SIZE=3D2>&gt; OPES is the only way to implement the service =
is request filtering</FONT>
<BR><FONT SIZE=3D2>&gt; for hand-held devices, in all other cases =
service can be implemented</FONT>
<BR><FONT SIZE=3D2>&gt; either at the server side or at the client =
side, or both.</FONT>
<BR><FONT SIZE=3D2>&gt; Still use of OPES may be beneficial, so I'd =
suggest ether to use</FONT>
<BR><FONT SIZE=3D2>&gt; a different wording, like:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;In some cases in may be beneficial to =
provide a customization service</FONT>
<BR><FONT SIZE=3D2>&gt; at network location instead of deploying it at =
either the provider or</FONT>
<BR><FONT SIZE=3D2>&gt; the consumer host. For certain services =
performed on end-user behalf</FONT>
<BR><FONT SIZE=3D2>&gt; this may be the only option of service =
deployment&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 2. &gt; 2.1 OPES Entities</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Figure 1 should look like this:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +----------------+</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | OPES service&nbsp;&nbsp; =
|</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | =
application&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +----------------+</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |data dispatcher |</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +----------------+</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; =
HTTP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +----------------+</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; =
TCP/IP&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +----------------+</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; =
...&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +----------------+</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Figure 1: =
An OPES protocol stack</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; It also may have sense to point out explicitly =
that</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;OPES application may be executed either =
on the same box (or</FONT>
<BR><FONT SIZE=3D2>&gt; even in the same application environment) with =
the dispatcher</FONT>
<BR><FONT SIZE=3D2>&gt; or on a different box through OCP.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I thing it has sense to emphasize this =
possibility and to provide a</FONT>
<BR><FONT SIZE=3D2>&gt; figure like this:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+--------------------------+</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
| =
+----------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
| |&nbsp;&nbsp; OPES&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
| |&nbsp; service =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +----------------+</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
| |&nbsp;&nbsp; appl&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | Callout Server |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
| =
+----------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp; =
||&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
| +--------+&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
| +----------------------+ |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | | =
OPES&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
| |&nbsp;&nbsp;&nbsp;&nbsp; data dispatcher&nbsp; | =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | | Service|&nbsp;&nbsp;&nbsp;&nbsp; =
|</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
| +----------------------+ |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | |&nbsp; =
App2&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
| |&nbsp;&nbsp; HTTP&nbsp;&nbsp;&nbsp;&nbsp; | =
OCP&nbsp;&nbsp;&nbsp;&nbsp; | |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | =
+--------+&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
| +------------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|&nbsp; OCP&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|---------+ |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | =
+--------+&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
| |&nbsp;&nbsp; TCP/IP&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +----------------+</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; =
=3D=3D=3D=3D=3D=3D=3D=3D=3D|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =
OPES Data Flow =3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
| =
+------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+--------------------------+</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; It illustrates positions and interaction of =
different components</FONT>
<BR><FONT SIZE=3D2>&gt; of OPES architecture.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; There were some other things mentioned, like =
use of PEP abbreviation,</FONT>
<BR><FONT SIZE=3D2>&gt; but the most important are:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; - Trust domains: delegation of authority =
(coloring) propagates</FONT>
<BR><FONT SIZE=3D2>&gt; from the content producer start of authority or =
from the content</FONT>
<BR><FONT SIZE=3D2>&gt; consumer start of authority, that may be =
different from the</FONT>
<BR><FONT SIZE=3D2>&gt; the end points in the data flow.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; - OPES processor MUST obey =
tracing/reporting/notification requirements</FONT>
<BR><FONT SIZE=3D2>&gt; set by the center of authority in the trust =
domain to which OPES</FONT>
<BR><FONT SIZE=3D2>&gt; processor belongs. As part of these =
requirements OPES processor MAY</FONT>
<BR><FONT SIZE=3D2>&gt; be instructed to reject or ignore such =
requirements from the</FONT>
<BR><FONT SIZE=3D2>&gt; the sources of a different =
&quot;color&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Oskar</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: owner-ietf-openproxy@mail.imc.org</FONT>
<BR><FONT SIZE=3D2>&gt; [<A =
HREF=3D"mailto:owner-ietf-openproxy@mail.imc.org">mailto:owner-ietf-open=
proxy@mail.imc.org</A>]On Behalf Of Abbie Barbir</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Monday, June 10, 2002 12:44 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: OPES Group</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: The Purple Streak (Hilarie Orman); Markus =
Hofmann; Marshall Rose</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Content Provider Notification: =
Summary: Please </FONT>
<BR><FONT SIZE=3D2>&gt; provide feedback</FONT>
<BR><FONT SIZE=3D2>&gt; ASAP</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; All,</FONT>
<BR><FONT SIZE=3D2>&gt; Following the thread on Content Provider =
Notification, it </FONT>
<BR><FONT SIZE=3D2>&gt; seems to me that</FONT>
<BR><FONT SIZE=3D2>&gt; no</FONT>
<BR><FONT SIZE=3D2>&gt; conclusion could be made about the course of =
action.</FONT>
<BR><FONT SIZE=3D2>&gt; There were proposals and counter proposals with =
no way of </FONT>
<BR><FONT SIZE=3D2>&gt; determining that a</FONT>
<BR><FONT SIZE=3D2>&gt; general conclusion that the group could live =
with was reached.</FONT>
<BR><FONT SIZE=3D2>&gt; However, it seems to me that if properly =
phrased, the </FONT>
<BR><FONT SIZE=3D2>&gt; following should be</FONT>
<BR><FONT SIZE=3D2>&gt; added to</FONT>
<BR><FONT SIZE=3D2>&gt; the architecture document.</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;</FONT>
<BR><FONT SIZE=3D2>&gt; The presence of an OPES processor in the data =
</FONT>
<BR><FONT SIZE=3D2>&gt; request/responce flow SHALL</FONT>
<BR><FONT SIZE=3D2>&gt; NOT</FONT>
<BR><FONT SIZE=3D2>&gt; interfere with the operations of non-OPES aware =
clients and </FONT>
<BR><FONT SIZE=3D2>&gt; servers. OPES</FONT>
<BR><FONT SIZE=3D2>&gt; processors, content server and content consumer =
MAY use OPES </FONT>
<BR><FONT SIZE=3D2>&gt; extensions to</FONT>
<BR><FONT SIZE=3D2>&gt; the base protocol (HTTP), but support of these =
extensions SHALL NOT be</FONT>
<BR><FONT SIZE=3D2>&gt; required.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; I am proposing to add this extra requirement to =
the </FONT>
<BR><FONT SIZE=3D2>&gt; architecture document</FONT>
<BR><FONT SIZE=3D2>&gt; provided that i do not get negative =
feedback(S).</FONT>
<BR><FONT SIZE=3D2>&gt; Furtheremore, I think that the topic of general =
notification should be</FONT>
<BR><FONT SIZE=3D2>&gt; delayed</FONT>
<BR><FONT SIZE=3D2>&gt; for a later stage. This will be mentioned in =
the draft also.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Please give feedback by the end of the day. The =
new -01 draft will be</FONT>
<BR><FONT SIZE=3D2>&gt; comming out soon.</FONT>
<BR><FONT SIZE=3D2>&gt; Abbie</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2114D.2292AEAC--


From owner-ietf-openproxy@mail.imc.org  Tue Jun 11 10:57:24 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27829
	for <opes-archive@ietf.org>; Tue, 11 Jun 2002 10:57:24 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5BER6Y06067
	for ietf-openproxy-bks; Tue, 11 Jun 2002 07:27:06 -0700 (PDT)
Received: from esarhaddon.ability.net (esarhaddon.ability.net [216.3.3.68])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5BER5n06063
	for <ietf-openproxy@imc.org>; Tue, 11 Jun 2002 07:27:05 -0700 (PDT)
Received: from [10.0.1.28] (66.safeclick.net [63.119.245.66])
	by esarhaddon.ability.net (8.11.6/8.11.6) with ESMTP id g5BEQdx16635;
	Tue, 11 Jun 2002 10:26:40 -0400
Mime-Version: 1.0
X-Sender: john@mail.cdtmail.org
Message-Id: <v04220800b92bb645972d@[10.0.1.28]>
In-Reply-To: <JMEPINMLHPLMNBBANKEHIEBOCDAA.batuner@attbi.com>
References: <JMEPINMLHPLMNBBANKEHIEBOCDAA.batuner@attbi.com>
Date: Tue, 11 Jun 2002 10:26:30 -0400
To: "Oskar Batuner" <batuner@attbi.com>
From: John Morris <jmorris@cdt.org>
Subject: RE: Content Provider Notification: Summary: Please provide
 feedback  	ASAP
Cc: "OPES Group" <ietf-openproxy@imc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


At 6:32 PM -0400 6/10/02, Oskar Batuner wrote:
>John, it looks like there are two main differences in
>our approach:
>
>1. You are looking at OPES as enabling technology that makes possible
>things that do not exist now. I look at OPES mainly as a technology
>standard that may facilitate deployment of services that do already
>exist but are deployed in a less efficient/controllable way (like
>filters, edge services, etc.)

You are correct that I am (perhaps too) focused on new services.  I 
appreciate the need/desire to use OPES to perform existing services 
better.

>As a result you are more concerned with the ability of new OPES
>entities to affect end-to-end interaction between content producers
>and content consumers. On another hand I think that with the proper
>architecture and taking into account IAB requirements (RFC3238),
>especially  requirement of explicit authorization, OPES does not
>create a situation that is substantially different from the existing
>one. OPES deals with the threats that already exist (Trojans, spyware,
>server security flaws, etc.).

I am a little unsure of what you are saying.  If you are saying that 
"OPES will be no worse than bad stuff that is already  out there, so 
we do not need to worry about notice, authoritzation, etc." then I 
cannot agree.

But I don't think you are saying that.  If you are saying that so 
long as OPES is built with the proper architecture and consistent 
with the IAB requirements, it will not create new problems or 
perpetuate old ones, then I am fully supportive of that approach.

>OPES development requires careful consideration of all possible
>threats but as a result I'd really like to see new
>security/authorization/tracing/reporting methods and standards that
>are equally applicable to both OPES and non-OPES systems.

Agreed.

>2. You are looking at "good guys" environment - both sides are
>perusing legitimate goals but may have different interests.
>I'm looking also at "bad guys" - viruses, worms, DDoS bots,
>spyware, persistent distributors of unwanted information and
>the like.
>
>"Bad guys" can not be trusted and have no legitimate
>interests that should be protected in any way. In situations
>of conflict between protection of legitimate content
>distributor rights and protection of end user from malicious
>intents I usually sympathize with the end-user.

Agreed.

>
>Oskar
>

John



From owner-ietf-openproxy@mail.imc.org  Tue Jun 11 11:49:10 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29953
	for <opes-archive@ietf.org>; Tue, 11 Jun 2002 11:49:08 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5BFMQE11480
	for ietf-openproxy-bks; Tue, 11 Jun 2002 08:22:26 -0700 (PDT)
Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5BFMOn11474
	for <ietf-openproxy@imc.org>; Tue, 11 Jun 2002 08:22:24 -0700 (PDT)
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.2/8.12.2) with ESMTP id g5BFMY6R055969;
	Tue, 11 Jun 2002 11:22:34 -0400 (EDT)
Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8])
	by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g5BFMJk63854;
	Tue, 11 Jun 2002 11:22:19 -0400 (EDT)
Received: from mhof.com (biena [135.180.160.86])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA07050;
	Tue, 11 Jun 2002 11:22:18 -0400 (EDT)
Message-ID: <3D0615AA.4000900@mhof.com>
Date: Tue, 11 Jun 2002 11:22:18 -0400
From: Markus Hofmann <markus@mhof.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Martin Stecher <martin.stecher@webwasher.com>
CC: OPES Group <ietf-openproxy@imc.org>
Subject: Re: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-reqs-00.txt
References: <72992B39BBD9294BB636A960E89AE02E50BED8@hermes.webwasher.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


Martin,

 > But I do not understand why it is an absolute requirement to have a
 > keep-alive message in order to create a working callout protocol.
 > And I am missing your arguments for this position. Andre and you
 > tell me about "less efficient" and "it complicates without...".
 > These are not arguments for a MUST, are they?

If the goal would only be to have some "working" mechanism for remote 
service execution, you could probably do this with already existing 
mechanisms - a callout protocol is somehow motivatate by 
efficiency/complexity considerations, so I'd assume it's fine to have 
some requirements with respect to those issues.

-Markus



From owner-ietf-openproxy@mail.imc.org  Tue Jun 11 13:46:15 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05053
	for <opes-archive@ietf.org>; Tue, 11 Jun 2002 13:46:14 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5BHIab16405
	for ietf-openproxy-bks; Tue, 11 Jun 2002 10:18:36 -0700 (PDT)
Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5BHIZn16400
	for <ietf-openproxy@imc.org>; Tue, 11 Jun 2002 10:18:35 -0700 (PDT)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5BHHre28830;
	Tue, 11 Jun 2002 13:17:53 -0400 (EDT)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <KTYBSLAF>; Tue, 11 Jun 2002 13:17:53 -0400
Message-ID: <87609AFB433BD5118D5E0002A52CD7540275F23D@zcard0k6.ca.nortel.com>
From: "Abbie Barbir" <abbieb@nortelnetworks.com>
To: internet-drafts@ietf.org
Cc: ietf-openproxy@imc.org, Markus Hofmann <markus@mhof.com>,
        Marshall Rose <mrose@dbc.mtview.ca.us>,
        "Abbie Barbir" <abbieb@nortelnetworks.com>
Subject: Publish Draft: draft-ietf-opes-architecture-01
Date: Tue, 11 Jun 2002 13:17:51 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C2116B.E94AB85A"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C2116B.E94AB85A
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2116B.E94AB85A"


------_=_NextPart_001_01C2116B.E94AB85A
Content-Type: text/plain;
	charset="iso-8859-1"

Please publish the attached as an Internet Draft

draft-ietf-opes-architecture-01

thanks

abbie


------_=_NextPart_001_01C2116B.E94AB85A
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE>Publish Draft: draft-ietf-opes-architecture-01</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Please publish the attached as an Internet Draft</FONT>
</P>

<P><FONT SIZE=2>draft-ietf-opes-architecture-01</FONT>
</P>

<P><FONT SIZE=2>thanks</FONT>
</P>

<P><FONT SIZE=2>abbie</FONT>
</P>

<P><FONT FACE="Arial" SIZE=2 COLOR="#000000"></FONT>&nbsp;

</BODY>
</HTML>
------_=_NextPart_001_01C2116B.E94AB85A--

------_=_NextPart_000_01C2116B.E94AB85A
Content-Type: text/plain;
	name="draft-ietf-opes-architecture-01.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-opes-architecture-01.txt"
Content-Transfer-Encoding: quoted-printable



Network Working Group                                     Abbie. Barbir
Internet-Draft                                           Nortel =
Networks
Expires: December 10, 2002                                       R. =
Chen
                                                               AT&T =
Labs
                                                              M. =
Hofmann
                                           Bell Labs/Lucent =
Technologies
                                                                H. =
Orman
                                           The Purple Streak =
Development
                                                                R. =
Penno
                                                         Nortel =
Networks
                                                            G. =
Tomlinson
                                                               =
Cacheflow
                                                           June 11, =
2002


        An Architecture for Open Pluggable Edge Services (OPES)
                    draft-ietf-opes-architecture-01

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six =
months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 10, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This memo defines an architecture for a cooperative application
   service in which a data provider, a data consumer, and zero or more



Barbir , et al.         Expires December 10, 2002               [Page =
1]


Internet-Draft              OPES Architecture                  June =
2002


   application entities cooperatively realize a data stream service.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  =
3
   2.  The Architecture . . . . . . . . . . . . . . . . . . . . . . .  =
4
   2.1 OPES Entities  . . . . . . . . . . . . . . . . . . . . . . . .  =
4
   2.2 OPES Flows . . . . . . . . . . . . . . . . . . . . . . . . . .  =
5
   2.3 OPES Rules . . . . . . . . . . . . . . . . . . . . . . . . . .  =
6
   2.4 Callout Servers  . . . . . . . . . . . . . . . . . . . . . . .  =
7
   2.5 Policy Enforcement . . . . . . . . . . . . . . . . . . . . . .  =
8
   2.6 Tracing Facility . . . . . . . . . . . . . . . . . . . . . . .  =
9
   3.  Security and Privacy Considerations  . . . . . . . . . . . . . =
11
   3.1 Trust Domains  . . . . . . . . . . . . . . . . . . . . . . . . =
11
   3.2 Callout protocol . . . . . . . . . . . . . . . . . . . . . . . =
12
   3.3 Privacy  . . . . . . . . . . . . . . . . . . . . . . . . . . . =
12
   3.4 Establishing trust . . . . . . . . . . . . . . . . . . . . . . =
12
   3.5 End-to-end Integrity . . . . . . . . . . . . . . . . . . . . . =
13
   4.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . =
14
       References . . . . . . . . . . . . . . . . . . . . . . . . . . =
15
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . =
15
   A.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . =
17
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . =
18




























Barbir , et al.         Expires December 10, 2002               [Page =
2]


Internet-Draft              OPES Architecture                  June =
2002


1. Introduction

   When realizing a data stream service between a provider and a
   consumer, the need may arise to provision the use of other
   application entities, in addition to the provider and consumer.  For
   example, some party may wish to customize a data stream as a service
   to a consumer, e.g., a service might customize the data based on the
   customer's geographical locality (e.g., language) or resource
   availability (e.g., display capabilities).

   In some cases in may be beneficial to provide a customization =
service
   at network location instead of deploying it at either the provider =
or
   the consumer host.  For certain services performed on end-user =
behalf
   this may be the only option of service deployment.  In this case, =
one
   or more additional application entities may participate in the data
   stream service.  There are many possible provisioning scenarios =
which
   make a data stream service attractive.  The reader is referred to =
[1]
   for a  description of several scenarios.

   The document presents the architectural components of Open Pluggable
   Edge Services (OPES) that are needed in order to perform a data
   stream service.  The architecture addresses the IAB considerations
   described in [2].  These considerations are covered in the various
   parts of the document, specifically with respect to tracing (Section
   2.6) and security considerations (Section 3).

   The document is organized as follows: Section 2 introduces the OPES
   architecture.  Section 3 discusses security considerations.  Section
   4 provides a summary of the architecture and the requirements for
   interoperability.





















Barbir , et al.         Expires December 10, 2002               [Page =
3]


Internet-Draft              OPES Architecture                  June =
2002


2. The Architecture

   The architecture of Open Pluggable Edge Services (OPES) can be
   described in terms of three interrelated concepts, mainly:

   o  OPES entities: processes operating in the network;

   o  OPES flows:  data flows that are cooperatively realized by the
      OPES entities; and,

   o  OPES rules: these determine how a given data flow is modified by
      an OPES entity.


2.1 OPES Entities

   An OPES entity is an application that operates on a data flow =
between
   a data provider application and a data consumer application.  OPES
   entities can be one of the following:

   o  an OPES service application, which analyzes and possibly
      transforms messages exchanged between the data provider
      application and the data consumer application; or,

   o  a data dispatcher, which invokes an OPES service application =
based
      on OPES ruleset and application-specific knowledge.

   In the network, OPES entities reside inside OPES processors.  The
   cooperative behavior of OPES entities introduces additional
   functionality for each data flow provided that it matches the OPES
   rules.

   In the current work, the data provider and data consumer =
applications
   are not considered as OPES entities.  The OPES architecture is
   largely independent of the protocol that is used by the OPES =
entities
   to exchange data.  However, this document selects HTTP [4] as the
   example protocol to be used for realizing a data flow.  In this
   regard, the logical implementation  stack of an OPES entity is
   summarized in Figure 1.












Barbir , et al.         Expires December 10, 2002               [Page =
4]


Internet-Draft              OPES Architecture                  June =
2002


   =
---------------------------------------------------------------------



                                +-------------+
                                |OPES service |
                                | Application |
                                |             |
                                +-------------+
                                |   Data      |
                                | Dispatcher  |
                                |             |
                                +-------------+
                                |             |
                                |    HTTP     |
                                |             |
                                +-------------+
                                |   TCP/IP    |
                                +-------------+
                                |     ...     |
                                +-------------+


                 Figure 1: OPES Logical Implementation

   =
---------------------------------------------------------------------

   Figure 1  depicts a "minimal" stack for OPES.  However, other
   protocols may be present, depending on the functions that are
   performed by the application.

2.2 OPES Flows

   An OPES flow is a cooperative undertaking between a data provider
   application, a data consumer application, zero or more OPES service
   applications, and zero or more data dispatchers.

   In order to understand the trust relationships between OPES =
entities,
   each is labeled as residing in an administrative domain.  Entities
   associated with a given OPES flow may reside in one or more
   administrative domains.

   For example, Figure 2 depicts a data flow (also known as an "OPES
   flow"), that spans two administrative domains.







Barbir , et al.         Expires December 10, 2002               [Page =
5]


Internet-Draft              OPES Architecture                  June =
2002


   =
---------------------------------------------------------------------



    consumer administrative domain       provider administrative domain
   +------------------------------+     =
+------------------------------+
   |                              |     |                              =
|
   |       data          OPES     |     |     OPES          data       =
|
   |     consumer      processor  |     |   processor     provider     =
|
   |                              |     |                              =
|
   |   +----------+   +--------+  |     |  +--------+   +----------+   =
|
   |   |   data   |   |  OPES  |  |     |  |  OPES  |   |   data   |   =
|
   |   | consumer |   |service |  |     |  |service |   | provider |   =
|
   |   |   appl   |   |  appl  |  |     |  |  appl  |   |   appl   |   =
|
   |   +----------+   +--------+  |     |  +--------+   +----------+   =
|
   |   |          |   |        |  |     |  |        |   |          |   =
|
   |   |   HTTP   |   |  HTTP  |  |     |  |  HTTP  |   |   HTTP   |   =
|
   |   |          |   |        |  |     |  |        |   |          |   =
|
   |   +----------+   +--------+  |     |  +--------+   +----------+   =
|
   |   |  TCP/IP  |   | TCP/IP |  |     |  | TCP/IP |   |  TCP/IP  |   =
|
   |   +----------+   +--------+  |     |  +--------+   +----------+   =
|
   |        ||         ||    ||   |     |   ||    ||         ||        =
|
   |        =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D    =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D    =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D        |
   |                              |     |                              =
|
   +------------------------------+     =
+------------------------------+
            | <----------------- OPES flow -----------------> |


                         Figure 2: An OPES flow

   =
---------------------------------------------------------------------

   Figure 2 depicts two data dispatchers that are present in the OPES
   flow.  However, the architecture allows for zero or more data
   dispatchers to be present in any flow.

2.3 OPES Rules

   OPES policy regarding services and the data provided to them is
   determined by a ruleset consisting of OPES rules.  The rules consist
   of a set of conditions and related actions.  The ruleset is the
   superset of all OPES rules on the processor.  The OPES ruleset
   determines which service applications will operate on a data stream.
   The communication of data stream elements to an application is
   performed by data dispatchers.  In this model, all data  filters are
   invoked for all data.

   In order to ensure predictable behavior  the OPES architecture



Barbir , et al.         Expires December 10, 2002               [Page =
6]


Internet-Draft              OPES Architecture                  June =
2002


   requires the use of a standardized schema for the purpose of =
defining
   and interpreting the ruleset.  The OPES architecture does not =
require
   a mechanism for configuring a ruleset into a data dispatcher.  This
   is treated as a local matter for each implementation (e.g., through
   the use of a text editor, secure upload protocol, and so on).  =
Future
   revisions of the architecture may introduce such a requirement.

2.4 Callout Servers

   The evaluation of OPES ruleset determines which service applications
   will operate on a data stream.  How the ruleset is evaluated is not
   the subject of the architecture, except to note that it must result
   in the same unambiguous result in all implementations.

   In some cases it may be useful for the OPES processor to distribute
   the responsibility of service evaluation by communicating with one =
or
   more callout servers (cf., [7]).  The situation is illustrated in
   Figure 3, which shows a data dispatcher communicating with multiple
   callout servers as it processes an OPES flow.

   =
---------------------------------------------------------------------


               data        callout       callout         callout
            dispatcher     server        server          server

           +----------+  +---------+   +---------+     +---------+
           |          |  |         |   |         |     |         |
           |   OCP    |  |   OCP   |   |   OCP   | ... |   OCP   |
           |          |  |         |   |         |     |         |
           +----------+  +---------+   +---------+     +---------+
           |  TCP/IP  |  |  TCP/IP |   |  TCP/IP |     |  TCP/IP |
           +----------+  +---------+   +---------+     +---------+
              ||              ||            ||              ||
              ||=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D        =
    ||     ...      ||
              ||                            ||              ||
              =
||=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D              ||
              ||                                            ||
              =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=



              Figure 3: An OPES flow with Callout servers

   =
---------------------------------------------------------------------

   In Figure 3, a data dispatcher invokes the services of a callout
   server by using the OPES callout protocol (OCP).  The requirements
   for the OCP are given in [7].  The OCP is application-agnostic, =
being



Barbir , et al.         Expires December 10, 2002               [Page =
7]


Internet-Draft              OPES Architecture                  June =
2002


   unaware of the semantics of the encapsulated  application protocol
   (e.g., HTTP).  However, the OCP must  incorporate a service aware
   vectoring capability that parses the data flow according to the
   ruleset and delivers the data to the OPES service application that
   can be local or remote.

   In this model, OPES applications may be executed either on the same
   processor (or even in the same application environment) with the
   dispatcher or on a different OPES processor through OCP.  The =
general
   interaction situation is depicted in Figure 4, which illustrates the
   positions and interaction of different components of OPES
   architecture.

   =
---------------------------------------------------------------------


           +--------------------------+
           | +----------+             |
           | |   OPES   |             |
           | |  service |             |      +----------------+
           | |   appl   |             |      | Callout Server |
           | +----------+             |      |                |
           |     ||                   |      | +--------+     |
           | +----------------------+ |      | | OPES   |     |
           | |     data dispatcher  | |      | | Service|     |
           | +----------------------+ |      | |  App2  |     |
           | |   HTTP     | OCP     | |      | +--------+     |
           | +------------|         |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|  =
OCP   |     |
           | |            |---------+ |      | +--------+     |
           | |   TCP/IP   |           |      +----------------+
    =3D=3D=3D=3D=3D=3D=3D=3D=3D|            =
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D OPES Data Flow =
=3D=3D=3D=3D
           | +------------+           |
           +--------------------------+




                 Figure 4: Interaction of OPES Entities

   =
---------------------------------------------------------------------


2.5 Policy Enforcement

   Data dispatchers include a ruleset that can be compiled from several
   sources and must resolve into an unambiguous result.  The compiled
   ruleset enables an OPES processor to determain which service
   applications to invoke for which data flow.  Accordingly, the data



Barbir , et al.         Expires December 10, 2002               [Page =
8]


Internet-Draft              OPES Architecture                  June =
2002


   dispatcher constitutes an enhanced Policy Enforcement Point (PEP),
   where policy rules are evaluated, service-specific data handlers and
   state information are maintained, as depicted in Figure 5.

   =
---------------------------------------------------------------------


                                    +----------+
                                    |  callout |
                                    |  server  |
                                    +----------+
                                         ||
                                         ||
                                         ||
                                         ||
                     +---------------------------+
                     | +----------+      ||     |
                     | |   OPES   |      ||     |
                     | |  service |      ||     |
                     | |   appl   |      ||     |
                     | +----------+      ||     |
                     | +----------------------+ |
     OPES flow <---->| | data dispatcher/PEP  | | <----> OPES flow
                     | +----------------------+ |
                     |           OPES           |
                     |         processor        |
                     +--------------------------+

        Figure 5: Data Dispatchers and Policy Enforcement Point

   =
---------------------------------------------------------------------

   The architecture allows more than one PEP to be present on an OPES
   flow.

2.6 Tracing Facility

   The architecture makes no requirements as to how an OPES flow is
   negotiated, provided that it is consistent with the security policy
   (Section 3) of each administrative domain that hosts the OPES
   entities that are associated with the flow.

   The OPES architecture requires that each data dispatcher provides
   tracing facilities that allow the appropriate verification of its
   operation.  The OPES architecture requires that tracing be feasible
   on the OPES flow per OPES processor using  in-band annotation.  One
   of those annotations could be a URL with more detailed information =
on
   the transformation that occurred to the data on the OPES flow.



Barbir , et al.         Expires December 10, 2002               [Page =
9]


Internet-Draft              OPES Architecture                  June =
2002


   Future revisions of the architecture may provide for a tracing
   facility to be used for subsequent out-of-band analysis.

   Providing the ability for in-band annotation MAY require header
   extensions  on the application protocol that is used (e.g., HTTP).
   However, the presence of an OPES processor in the data request/
   response flow SHALL NOT interfere with the operations of non-OPES
   aware clients and servers.  OPES processors, content server and
   content consumer MAY use OPES extensions to the base protocol =
(HTTP),
   but support of these extensions SHALL NOT be required.

   OPES processors must obey tracing, reporting and notification
   requirements set by the center of authority in the trust domain to
   which OPES processor belongs.  As part of these requirements OPES
   processor may be instructed to reject or ignore such requirements
   that originate from other trust domains.



































Barbir , et al.         Expires December 10, 2002              [Page =
10]


Internet-Draft              OPES Architecture                  June =
2002


3. Security and Privacy Considerations

   Each data flow must be secured in accordance with several policies.
   The primary stakeholders are the data consumer and the data =
provider.
   The secondary stakeholders are the entities to which they may have
   delegated their trust.  The other stakeholders are the owners of the
   callout servers.  Any of these parties may be participants in the
   OPES architecture.

   These parties must have a model, explicit or implicit, describing
   their trust policy; which of the other parties are trusted to =
operate
   on data, and what security enhancements are required for
   communication.  The trust might be delegated for all data, or it
   might be restricted to granularity as small as an application data
   unit.

   All parties that are involved in enforcing policies must communicate
   the policies to the parties that are involved.  These parties are
   trusted to adhere to the communicated policies.

   In order to delegate fine-grained trust, the parties must convey
   policy information by implicit contract, by a setup protocol, by a
   dynamic negotiation protocol, or in-line with application data
   headers.

3.1 Trust Domains

   The delegation of authority starts at either a data consumer or data
   provider and moves to more distant entities in a "stepwise" fashion.
   Stepwise means A delegates to B and B delegates to C and so forth.
   The entities thus "colored" by the delegation are said to form a
   trust domain with respect to the original delegating party.  Here,
   "Colored" means that if the first step in the chain is the data
   provider, then the stepwise delegation "colors" the chain with that
   data "provider" color.  The only colors that are defined are the =
data
   "provider" and the data "consumer".  Delegation of authority
   (coloring) propagates from the content producer start of authority =
or
   from the content consumer start of authority, that may be different
   from the end points in the data flow.

   An OPES processor may be in several trust domains at any time.  =
There
   is no restriction on whether the OPES processors are authorized by
   data consumers and/or data providers.  The original party has the
   option of forbidding or limiting redelegation.

   An OPES processor must have a representation of its trust domain
   memberships that it can report in whole or in part for tracing
   purposes.  It must include the name of the party which delegated =
each



Barbir , et al.         Expires December 10, 2002              [Page =
11]


Internet-Draft              OPES Architecture                  June =
2002


   privilege to it.

3.2 Callout protocol

   The determination of whether or not OPES processors will use the
   measures that are described in the previous section during their
   communication with callout servers depends on the details of how the
   primary parties delegated trust to the OPES processors and the trust
   relationship between the OPES processors and the callout server.  If
   the OPES processors are in a single administrative domain with =
strong
   confidentiality guarantees, then encryption may be optional.  In
   other cases, encryption and strong authentication would be at least
   strongly recommended.

   If the delegation mechanism names the trusted parties and their
   privileges in some way that permits authentication, then the OPES
   processors will be responsible for enforcing the policy and for =
using
   authentication as part of that enforcement.

   The callout servers must be aware of the policy governing the
   communication path.  They must not, for example, communicate
   confidential information to auxiliary servers outside the trust
   domain.

   A separate security association must be used for each channel
   established between an OPES processor and a callout server.  The
   channels must be separate for different primary parties.

3.3 Privacy

   Some data from data consumers is considered "private" or =
"sensitive",
   and OPES processors must both advise the primary parties of the =
their
   privacy policy and respect the policies of the primary parties.  The
   privacy information must be conveyed on a per-flow basis.

   The callout servers must also participate in handling of private
   data, and they must be prepared to announce their own capabilities
   and to enforce the policy required by the primary parties.

3.4 Establishing trust

   The OPES processor will have configuration policy specifying what
   privileges the callout servers have and how they are to be
   identified.  This is especially critical for third-party (fourth-
   party, etc.) callout servers.  OPES uses standard protocols for
   authenticating and otherwise security communication with callout
   servers.




Barbir , et al.         Expires December 10, 2002              [Page =
12]


Internet-Draft              OPES Architecture                  June =
2002


   An OPES processor will have a trusted method for receiving
   configuration information such as rules for the data dispatcher,
   trusted callout servers, primary parties that opt-in or opt-out of
   individual services, etc.

3.5 End-to-end Integrity

   Digital signature techniques can be used to mark data changes in =
such
   a way that a third-party can verify that the changes are or are not
   consistent with the originating party's policy.  This requires an
   inline manner of specifying policy and its binding to data, a trace
   of changes and the party making the changes, and strong identities
   and authentication methods.

   Strong end-to-end integrity can fulfill some of the functions
   required by "tracing".



































Barbir , et al.         Expires December 10, 2002              [Page =
13]


Internet-Draft              OPES Architecture                  June =
2002


4. Summary

   Although the architecture supports a wide range of cooperative
   transformation services, it has few requirements for
   interoperability.

   The necessary and sufficient elements are specified in the following
   documents:

   o  the OPES ruleset schema [6] which defines the syntax and =
semantics
      of the rules interpreted by a data dispatcher; and,

   o  the OPES callout protocol (OCP) [7] which defines the protocol
      between a data dispatcher and a callout server.





































Barbir , et al.         Expires December 10, 2002              [Page =
14]


Internet-Draft              OPES Architecture                  June =
2002


References

   [1]  McHenry, S., et. al, "OPES Scenarios and Use Cases", Internet-
        Draft TBD, May 2002.

   [2]  Floyd, S. and L. Daigle, "IAB Architectural and Policy
        Considerations for Open Pluggable Edge Services", RFC 3238,
        January 2002.

   [3]  Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
        Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S.
        Waldbusser, "Terminology for Policy-Based Management", RFC =
3198,
        November 2001.

   [4]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
        Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
        HTTP/1.1", RFC 2616, June 1999.

   [5]  OPES working group, "OPES Service Authorization and Enforcement
        Requirements", Internet-Draft TBD, May 2002.

   [6]  OPES working group, "OPES Ruleset Schema", Internet-Draft TBD,
        May 2002.

   [7]  OPES working group, "OPES Callout Protocol and Tracing Protocol
        Requirements", Internet-Draft TBD, May 2002.


Authors' Addresses

   Abbie Barbir
   Nortel Networks
   3500 Carling Avenue
   Nepean, Ontario  K2H 8E9
   Canada

   Phone: +1 613 763 5229
   EMail: abbieb@nortelnetworks.com


   Robin Chen
   AT&T Labs
   Room E219,  180 Park Avenue
   Florham Park, NJ  07932
   US

   Phone: +1 973 360 8653
   EMail: chen@research.att.com



Barbir , et al.         Expires December 10, 2002              [Page =
15]


Internet-Draft              OPES Architecture                  June =
2002


   Markus Hofmann
   Bell Labs/Lucent Technologies
   Room 4F-513
   101 Crawfords Corner Road
   Holmdel, NJ  07733
   US

   Phone: +1 732 332 5983
   EMail: hofmann@bell-labs.com


   Hilarie Orman
   The Purple Streak Development

   EMail: ho@alum.mit.edu


   Reinaldo Penno
   Nortel Networks
   2305 Mission College Boulevard
   San Jose, CA  95134
   US

   EMail: rpenno@nortelnetworks.com


   Gary Tomlinson
   Cacheflow

   EMail: gary@tomlinsongroup.net





















Barbir , et al.         Expires December 10, 2002              [Page =
16]


Internet-Draft              OPES Architecture                  June =
2002


Appendix A. Acknowledgements

   The authors gratefully acknowledge the contributions of: Marshall T.
   Rose, John Morris, Oskar Batuner, Mark Baker and Ian Cooper.















































Barbir , et al.         Expires December 10, 2002              [Page =
17]


Internet-Draft              OPES Architecture                  June =
2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph =
are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Barbir , et al.         Expires December 10, 2002              [Page =
18]






------_=_NextPart_000_01C2116B.E94AB85A--


From owner-ietf-openproxy@mail.imc.org  Tue Jun 11 14:19:12 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06646
	for <opes-archive@ietf.org>; Tue, 11 Jun 2002 14:19:12 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5BHt0I19275
	for ietf-openproxy-bks; Tue, 11 Jun 2002 10:55:00 -0700 (PDT)
Received: from mgr4.xmission.com (mail@mgr4.xmission.com [198.60.22.204])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5BHsxn19271
	for <ietf-openproxy@imc.org>; Tue, 11 Jun 2002 10:54:59 -0700 (PDT)
Received: from mail by mgr4.xmission.com with spam-scanned (Exim 3.35 #1)
	id 17HprA-0008P7-00; Tue, 11 Jun 2002 11:55:00 -0600
Received: from [198.60.22.200] (helo=mail.xmission.com)
	by mgr4.xmission.com with esmtp (Exim 3.35 #1)
	id 17HprA-0008P1-00; Tue, 11 Jun 2002 11:55:00 -0600
Received: from [166.70.2.21] (helo=alum.mit.edu)
	by mail.xmission.com with esmtp (Exim 3.22 #1)
	id 17Hpr9-00022N-00; Tue, 11 Jun 2002 11:55:00 -0600
Message-ID: <3D063258.6010708@alum.mit.edu>
Date: Tue, 11 Jun 2002 11:24:40 -0600
From: "The Purple Streak (Hilarie Orman)" <ho@alum.mit.edu>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Abbie Barbir <abbieb@nortelnetworks.com>
CC: ietf-openproxy@imc.org, Markus Hofmann <markus@mhof.com>,
        Marshall Rose <mrose@dbc.mtview.ca.us>
Subject: Re: Publish Draft: draft-ietf-opes-architecture-01
References: <87609AFB433BD5118D5E0002A52CD7540275F23D@zcard0k6.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, hits=0.0 required=8.0 tests= version=2.20
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


I'd appreciate having my comments of 5 minutes ago to Abbie
included.  I sent them within 15 minutes of receiving the draft.

Hilarie

Abbie Barbir wrote:

> Please publish the attached as an Internet Draft
> 
> draft-ietf-opes-architecture-01
> 
> thanks
> 
> abbie
> 




From owner-ietf-openproxy@mail.imc.org  Wed Jun 12 07:42:56 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23697
	for <opes-archive@ietf.org>; Wed, 12 Jun 2002 07:42:55 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g5CBEvU21373
	for ietf-openproxy-bks; Wed, 12 Jun 2002 04:14:57 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CBEun21369
	for <ietf-openproxy@imc.org>; Wed, 12 Jun 2002 04:14:56 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23021;
	Wed, 12 Jun 2002 07:14:16 -0400 (EDT)
Message-Id: <200206121114.HAA23021@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-architecture-01.txt
Date: Wed, 12 Jun 2002 07:14:12 -0400
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


--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		: An Architecture for Open Pluggable Edge Services 
                          (OPES)
	Author(s)	: A. Barbir et al.
	Filename	: draft-ietf-opes-architecture-01.txt
	Pages		: 18
	Date		: 11-Jun-02
	
This memo defines an architecture for a cooperative application
service in which a data provider, a data consumer, and zero or more
application entities cooperatively realize a data stream service.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-opes-architecture-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-opes-architecture-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-opes-architecture-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020611133249.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-opes-architecture-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-opes-architecture-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020611133249.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-ietf-openproxy@mail.imc.org  Wed Jun 12 09:53:53 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28330
	for <opes-archive@ietf.org>; Wed, 12 Jun 2002 09:53:52 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g5CDMpV26603
	for ietf-openproxy-bks; Wed, 12 Jun 2002 06:22:51 -0700 (PDT)
Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5CDMon26599
	for <ietf-openproxy@imc.org>; Wed, 12 Jun 2002 06:22:51 -0700 (PDT)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5CDMgN06583
	for <ietf-openproxy@imc.org>; Wed, 12 Jun 2002 09:22:42 -0400 (EDT)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <KTYBSWS1>; Wed, 12 Jun 2002 09:22:42 -0400
Message-ID: <87609AFB433BD5118D5E0002A52CD7540275F7F3@zcard0k6.ca.nortel.com>
From: "Abbie Barbir" <abbieb@nortelnetworks.com>
To: "'ietf-openproxy@imc.org'" <ietf-openproxy@imc.org>
Subject:  draft-ietf-opes-architecture-01: Feedback
Date: Wed, 12 Jun 2002 09:22:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C21214.32AE7E5C"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C21214.32AE7E5C
Content-Type: text/plain;
	charset="iso-8859-1"

 
The -01 architecture draft has been submitted.

However, from the feedback that I have recieved there is still a need for
-02 version to fix some minor issues.

Can you please try to provide your input before friday, since my plan is to
have -02 ready by early monday.

Please use this new thread for the feedback.


thanks

abbie

------_=_NextPart_001_01C21214.32AE7E5C
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE> draft-ietf-opes-architecture-01: Feedback</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>&nbsp;</FONT>
<BR><FONT SIZE=2>The -01 architecture draft has been submitted.</FONT>
</P>

<P><FONT SIZE=2>However, from the feedback that I have recieved there is still a need for -02 version to fix some minor issues.</FONT>
</P>

<P><FONT SIZE=2>Can you please try to provide your input before friday, since my plan is to have -02 ready by early monday.</FONT>
</P>

<P><FONT SIZE=2>Please use this new thread for the feedback.</FONT>
</P>
<BR>

<P><FONT SIZE=2>thanks</FONT>
</P>

<P><FONT SIZE=2>abbie</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C21214.32AE7E5C--


From owner-ietf-openproxy@mail.imc.org  Fri Jun 14 00:34:07 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11339
	for <opes-archive@ietf.org>; Fri, 14 Jun 2002 00:34:07 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5E47ch18865
	for ietf-openproxy-bks; Thu, 13 Jun 2002 21:07:38 -0700 (PDT)
Received: from sccrmhc02.attbi.com (sccrmhc02.attbi.com [204.127.202.62])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5E47cn18861
	for <ietf-openproxy@imc.org>; Thu, 13 Jun 2002 21:07:38 -0700 (PDT)
Received: from oskar3 ([24.60.133.29]) by sccrmhc02.attbi.com
          (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP
          id <20020614040737.TYXT1547.sccrmhc02.attbi.com@oskar3>;
          Fri, 14 Jun 2002 04:07:37 +0000
From: "Oskar Batuner" <batuner@attbi.com>
To: "Abbie Barbir" <abbieb@nortelnetworks.com>, <ietf-openproxy@imc.org>
Subject: RE: draft-ietf-opes-architecture-01: Feedback
Date: Fri, 14 Jun 2002 00:07:38 -0400
Message-ID: <JMEPINMLHPLMNBBANKEHIECOCDAA.batuner@attbi.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <87609AFB433BD5118D5E0002A52CD7540275F7F3@zcard0k6.ca.nortel.com>
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit



1. [Page 4]

>OPES rules: these determine how a given data flow is modified by
>      an OPES entity.

This statement may leave impression that rules describe data
transformation.

I think the purpose of rules is better described as:

"specify when and how to execute OPES intermediary services"

<this is taken from draft-beck-opes-irml-01>
---------------

2. General composition of chapter 2.

In the beginning this chapter has 3 bullets, then it has subchapters 2.1,
2.2 and 2.3 that correspond to these bullets. But then it has additional
subchapters:

2.4 Callout Servers
2.5 Policy Enforcement
2.6 Tracing Facility

To preserve composition integrity I'd suggest to add 4th bullet for
Callout Servers and move 2.6 (Tracing facility) to chapter 3 as 3.6. This
way we have chapter 2 describing all OPES objects and chapter 3 covering all
security related questions.
--------------

On 2.5 (Policy Enforcement)

>dispatcher constitutes an enhanced Policy Enforcement Point (PEP),

Use of PEP abbreviation may be a little confusing: this document
references RFC 3238, which uses this abbreviation in a different
sense - Performance-Enhancing Proxies, originating in RFC 3135
(see RFC 3238, p.4).

As I understand PEP abbreviation here is used in the sense of COPS,
but the notion of "policy" in COPS is somewhat different. To add
more confusion in the name of RFC3135 "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services" the word "policy"
has yet another meaning.

I'd suggest to abandon this terminology (Policy Enforcement
Point - PEP) in this document. It is not well defined here and looks very
ambiguous.

Let's just call data dispatchers data dispatchers. They are introduced
in 2.1, so  all 2.5 can be moved there, either as "2.1.1 Data Dispatcher" or
without subheader.

Oskar




From owner-ietf-openproxy@mail.imc.org  Tue Jun 18 13:06:01 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26737
	for <opes-archive@ietf.org>; Tue, 18 Jun 2002 13:06:00 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5IGfCp04833
	for ietf-openproxy-bks; Tue, 18 Jun 2002 09:41:12 -0700 (PDT)
Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5IGfAn04828
	for <ietf-openproxy@imc.org>; Tue, 18 Jun 2002 09:41:11 -0700 (PDT)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5IGf1100931;
	Tue, 18 Jun 2002 12:41:01 -0400 (EDT)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <KTYBVQS1>; Tue, 18 Jun 2002 12:41:01 -0400
Message-ID: <87609AFB433BD5118D5E0002A52CD754028D48F6@zcard0k6.ca.nortel.com>
From: "Abbie Barbir" <abbieb@nortelnetworks.com>
To: Oskar Batuner <batuner@attbi.com>, ietf-openproxy@imc.org
Subject:  [OPES-Arch]: draft-ietf-opes-architecture-02: Ready: Last chance
	 for Feedback
Date: Tue, 18 Jun 2002 12:40:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C216E6.E842307A"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C216E6.E842307A
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C216E6.E842307A"


------_=_NextPart_001_01C216E6.E842307A
Content-Type: text/plain;
	charset="iso-8859-1"

Hi all,

The draft-ietf-opes-architecture-02 is ready. I have done some modifications
based on the feedback from -01. I will be publishing this version tom.
morning.

This is your last chance for immediate feedback.

Regards

Abbie



------_=_NextPart_001_01C216E6.E842307A
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE> [OPES-Arch]: draft-ietf-opes-architecture-02: Ready: Last =
chance for Feedback</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi all,</FONT>
</P>

<P><FONT SIZE=3D2>The draft-ietf-opes-architecture-02 is ready. I have =
done some modifications based on the feedback from -01. I will be =
publishing this version tom. morning.</FONT></P>

<P><FONT SIZE=3D2>This is your last chance for immediate =
feedback.</FONT>
</P>

<P><FONT SIZE=3D2>Regards</FONT>
</P>

<P><FONT SIZE=3D2>Abbie</FONT>
</P>

<P><FONT FACE=3D"Arial" SIZE=3D2 COLOR=3D"#000000"></FONT>&nbsp;

</BODY>
</HTML>
------_=_NextPart_001_01C216E6.E842307A--

------_=_NextPart_000_01C216E6.E842307A
Content-Type: text/plain;
	name="draft-ietf-opes-architecture-02.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-opes-architecture-02.txt"
Content-Transfer-Encoding: quoted-printable



Network Working Group                                     Abbie. Barbir
Internet-Draft                                           Nortel =
Networks
Expires: December 17, 2002                                       R. =
Chen
                                                               AT&T =
Labs
                                                              M. =
Hofmann
                                           Bell Labs/Lucent =
Technologies
                                                                H. =
Orman
                                               Purple Streak =
Development
                                                                R. =
Penno
                                                         Nortel =
Networks
                                                            G. =
Tomlinson
                                                     The Tomlinson =
Group
                                                           June 18, =
2002


        An Architecture for Open Pluggable Edge Services (OPES)
                    draft-ietf-opes-architecture-02

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six =
months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 17, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This memo defines an architecture for a cooperative application
   service in which a data provider, a data consumer, and zero or more



Barbir , et al.         Expires December 17, 2002               [Page =
1]
=0C
Internet-Draft              OPES Architecture                  June =
2002


   application entities cooperatively realize a data stream service.

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  =
3
   2.    The Architecture . . . . . . . . . . . . . . . . . . . . . .  =
4
   2.1   OPES Entities  . . . . . . . . . . . . . . . . . . . . . . .  =
4
   2.1.1 Data Dispatcher  . . . . . . . . . . . . . . . . . . . . . .  =
5
   2.2   OPES Flows . . . . . . . . . . . . . . . . . . . . . . . . .  =
6
   2.3   OPES Rules . . . . . . . . . . . . . . . . . . . . . . . . .  =
7
   2.4   Callout Servers  . . . . . . . . . . . . . . . . . . . . . .  =
8
   2.5   Tracing Facility . . . . . . . . . . . . . . . . . . . . . . =
10
   3.    Security and Privacy Considerations  . . . . . . . . . . . . =
12
   3.1   Trust Domains  . . . . . . . . . . . . . . . . . . . . . . . =
12
   3.2   Callout protocol . . . . . . . . . . . . . . . . . . . . . . =
13
   3.3   Privacy  . . . . . . . . . . . . . . . . . . . . . . . . . . =
13
   3.4   Establishing trust . . . . . . . . . . . . . . . . . . . . . =
13
   3.5   End-to-end Integrity . . . . . . . . . . . . . . . . . . . . =
14
   4.    Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . =
15
         References . . . . . . . . . . . . . . . . . . . . . . . . . =
16
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . =
16
   A.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . =
18
         Full Copyright Statement . . . . . . . . . . . . . . . . . . =
19




























Barbir , et al.         Expires December 17, 2002               [Page =
2]
=0C
Internet-Draft              OPES Architecture                  June =
2002


1. Introduction

   When realizing a data stream service between a provider and a
   consumer, the need may arise to provision the use of other
   application entities, in addition to the provider and consumer.  For
   example, some party may wish to customize a data stream as a service
   to a consumer, e.g., a service might customize the data based on the
   customer's geographical locality (e.g., language) or resource
   availability (e.g., display capabilities).

   In some cases in may be beneficial to provide a customization =
service
   at network location instead of deploying it at either the provider =
or
   the consumer host.  For certain services performed on end-user =
behalf
   this may be the only option of service deployment.  In this case, =
one
   or more additional application entities may participate in the data
   stream service.  There are many possible provisioning scenarios =
which
   make a data stream service attractive.  The reader is referred to =
[1]
   for a  description of several scenarios.

   The document presents the architectural components of Open Pluggable
   Edge Services (OPES) that are needed in order to perform a data
   stream service.  The architecture addresses the IAB considerations
   described in [2].  These considerations are covered in the various
   parts of the document, specifically with respect to tracing (Section
   2.5) and security considerations (Section 3).

   The document is organized as follows: Section 2 introduces the OPES
   architecture.  Section 3 discusses security considerations.  Section
   4 provides a summary of the architecture and the requirements for
   interoperability.





















Barbir , et al.         Expires December 17, 2002               [Page =
3]
=0C
Internet-Draft              OPES Architecture                  June =
2002


2. The Architecture

   The architecture of Open Pluggable Edge Services (OPES) can be
   described in terms of three interrelated concepts, mainly:

   o  OPES entities: processes operating in the network;

   o  OPES flows:  data flows that are cooperatively realized by the
      OPES entities; and,

   o  OPES rules: these specify when and how to execute OPES
      intermediary services.


2.1 OPES Entities

   An OPES entity is an application that operates on a data flow =
between
   a data provider application and a data consumer application.  OPES
   entities can be one of the following:

   o  an OPES service application, which analyzes and possibly
      transforms messages exchanged between the data provider
      application and the data consumer application; or,

   o  a data dispatcher, which invokes an OPES service application =
based
      on OPES ruleset and application-specific knowledge.

   In the network, OPES entities reside inside OPES processors.  The
   cooperative behavior of OPES entities introduces additional
   functionality for each data flow provided that it matches the OPES
   rules.

   In the current work, the data provider and data consumer =
applications
   are not considered as OPES entities.  The OPES architecture is
   largely independent of the protocol that is used by the OPES =
entities
   to exchange data.  However, this document selects HTTP [4] as the
   example protocol to be used for realizing a data flow.  In this
   regard, the logical implementation  stack of an OPES entity is
   summarized in Figure 1.












Barbir , et al.         Expires December 17, 2002               [Page =
4]
=0C
Internet-Draft              OPES Architecture                  June =
2002


   =
---------------------------------------------------------------------



                                +-------------+
                                |OPES service |
                                | Application |
                                |             |
                                +-------------+
                                |   Data      |
                                | Dispatcher  |
                                |             |
                                +-------------+
                                |             |
                                |    HTTP     |
                                |             |
                                +-------------+
                                |   TCP/IP    |
                                +-------------+
                                |     ...     |
                                +-------------+


                 Figure 1: OPES Logical Implementation

   =
---------------------------------------------------------------------

   Figure 1  depicts a "minimal" stack for OPES.  However, other
   protocols may be present, depending on the functions that are
   performed by the application.

2.1.1  Data Dispatcher

   Data dispatchers include a ruleset that can be compiled from several
   sources and must resolve into an unambiguous result.  The compiled
   ruleset enables an OPES processor to determain which service
   applications to invoke for which data flow.  Accordingly, the data
   dispatcher consitutes an enhanced policy enforcement point, where
   policy rules are evaluated, service-specific data handlers and state
   information are maintained, as depicted in Figure 2.











Barbir , et al.         Expires December 17, 2002               [Page =
5]
=0C
Internet-Draft              OPES Architecture                  June =
2002


   =
---------------------------------------------------------------------




                                       +----------+
                                       |  callout |
                                       |  server  |
                                       +----------+
                                            ||
                                            ||
                                            ||
                                            ||
                        +--------------------------+
                        | +----------+      ||     |
                        | |   OPES   |      ||     |
                        | |  service |      ||     |
                        | |   appl   |      ||     |
                        | +----------+      ||     |
                        | +----------------------+ |
        OPES flow <---->| | data dispatcher and  | |<----> OPES flow
                        | |   policy enforcement | |
                        | +----------------------+ |
                        |           OPES           |
                        |         processor        |
                        +--------------------------+


                       Figure 2: Data Dispatchers

   =
---------------------------------------------------------------------

   The architecture allows more than one policy enforcement point to be
   present on an OPES flow.

2.2 OPES Flows

   An OPES flow is a cooperative undertaking between a data provider
   application, a data consumer application, zero or more OPES service
   applications, and zero or more data dispatchers.

   In order to understand the trust relationships between OPES =
entities,
   each is labeled as residing in an administrative domain.  Entities
   associated with a given OPES flow may reside in one or more
   administrative domains.

   For example, Figure 2 depicts a data flow (also known as an "OPES
   flow"), that spans two administrative domains.



Barbir , et al.         Expires December 17, 2002               [Page =
6]
=0C
Internet-Draft              OPES Architecture                  June =
2002


   =
---------------------------------------------------------------------



    consumer administrative domain       provider administrative domain
   +------------------------------+     =
+------------------------------+
   |                              |     |                              =
|
   |       data          OPES     |     |     OPES          data       =
|
   |     consumer      processor  |     |   processor     provider     =
|
   |                              |     |                              =
|
   |   +----------+   +--------+  |     |  +--------+   +----------+   =
|
   |   |   data   |   |  OPES  |  |     |  |  OPES  |   |   data   |   =
|
   |   | consumer |   |service |  |     |  |service |   | provider |   =
|
   |   |   appl   |   |  appl  |  |     |  |  appl  |   |   appl   |   =
|
   |   +----------+   +--------+  |     |  +--------+   +----------+   =
|
   |   |          |   |        |  |     |  |        |   |          |   =
|
   |   |   HTTP   |   |  HTTP  |  |     |  |  HTTP  |   |   HTTP   |   =
|
   |   |          |   |        |  |     |  |        |   |          |   =
|
   |   +----------+   +--------+  |     |  +--------+   +----------+   =
|
   |   |  TCP/IP  |   | TCP/IP |  |     |  | TCP/IP |   |  TCP/IP  |   =
|
   |   +----------+   +--------+  |     |  +--------+   +----------+   =
|
   |        ||         ||    ||   |     |   ||    ||         ||        =
|
   |        =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D    =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D    =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D        |
   |                              |     |                              =
|
   +------------------------------+     =
+------------------------------+
            | <----------------- OPES flow -----------------> |


                         Figure 3: An OPES flow

   =
---------------------------------------------------------------------

   Figure 3 depicts two data dispatchers that are present in the OPES
   flow.  However, the architecture allows for zero or more data
   dispatchers to be present in any flow.

2.3 OPES Rules

   OPES policy regarding services and the data provided to them is
   determined by a ruleset consisting of OPES rules.  The rules consist
   of a set of conditions and related actions.  The ruleset is the
   superset of all OPES rules on the processor.  The OPES ruleset
   determines which service applications will operate on a data stream.
   The communication of data stream elements to an application is
   performed by data dispatchers.  In this model, all data  filters are
   invoked for all data.

   In order to ensure predictable behavior  the OPES architecture



Barbir , et al.         Expires December 17, 2002               [Page =
7]
=0C
Internet-Draft              OPES Architecture                  June =
2002


   requires the use of a standardized schema for the purpose of =
defining
   and interpreting the ruleset.  The OPES architecture does not =
require
   a mechanism for configuring a ruleset into a data dispatcher.  This
   is treated as a local matter for each implementation (e.g., through
   the use of a text editor, secure upload protocol, and so on).  =
Future
   revisions of the architecture may introduce such a requirement.

2.4 Callout Servers

   The evaluation of OPES ruleset determines which service applications
   will operate on a data stream.  How the ruleset is evaluated is not
   the subject of the architecture, except to note that it must result
   in the same unambiguous result in all implementations.

   In some cases it may be useful for the OPES processor to distribute
   the responsibility of service evaluation by communicating with one =
or
   more callout servers (cf., [7]).  The situation is illustrated in
   Figure 4, which shows a data dispatcher communicating with multiple
   callout servers as it processes an OPES flow.
































Barbir , et al.         Expires December 17, 2002               [Page =
8]
=0C
Internet-Draft              OPES Architecture                  June =
2002


   =
---------------------------------------------------------------------


                  data        callout       callout         callout
               dispatcher     server        server          server

              +----------+  +---------+   +---------+     +---------+
              |          |  |         |   |         |     |         |
              |   OCP    |  |   OCP   |   |   OCP   | ... |   OCP   |
              |          |  |         |   |         |     |         |
              +----------+  +---------+   +---------+     +---------+
              |  Lower   |  |  Lower  |   |  Lower  |     |  Lower  |
              |  Layer   |  |  Layer  |   |  Layer  |     |  Layer  |
              |Protocols |  |Protocols|   |Protocols|     |Protocols|
              |    .     |  |   .     |   |    .    |     |   .     |
              |    .     |  |   .     |   |    .    |     |   .     |
              +----------+  +---------+   +---------+     +---------+
                 ||              ||            ||              ||
                 ||=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D     =
       ||     ...      ||
                 ||                            ||              ||
                 =
||=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D              ||
                 ||                                            ||
                 =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=




              Figure 4: An OPES flow with Callout servers

   =
---------------------------------------------------------------------

   In Figure 4, a data dispatcher invokes the services of a callout
   server by using the OPES callout protocol (OCP).  The requirements
   for the OCP are given in [7].  The OCP is application-agnostic, =
being
   unaware of the semantics of the encapsulated  application protocol
   (e.g., HTTP).  However, the OCP must  incorporate a service aware
   vectoring capability that parses the data flow according to the
   ruleset and delivers the data to the OPES service application that
   can be local or remote.

   In this model, OPES applications may be executed either on the same
   processor (or even in the same application environment) with the
   dispatcher or on a different OPES processor through OCP.  The =
general
   interaction situation is depicted in Figure 5, which illustrates the
   positions and interaction of different components of OPES
   architecture.






Barbir , et al.         Expires December 17, 2002               [Page =
9]
=0C
Internet-Draft              OPES Architecture                  June =
2002


   =
---------------------------------------------------------------------


           +--------------------------+
           | +----------+             |
           | |   OPES   |             |
           | |  service |             |      +----------------+
           | |   appl   |             |      | Callout Server |
           | +----------+             |      |                |
           |     ||                   |      | +--------+     |
           | +----------------------+ |      | | OPES   |     |
           | |     data dispatcher  | |      | | Service|     |
           | +----------------------+ |      | |  App2  |     |
           | |   HTTP     | OCP     | |      | +--------+     |
           | +------------|         |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|  =
OCP   |     |
           | |            |---------+ |      | +--------+     |
           | |   TCP/IP   |           |      +----------------+
    =3D=3D=3D=3D=3D=3D=3D=3D=3D|            =
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D OPES Data Flow =
=3D=3D=3D=3D
           | +------------+           |
           +--------------------------+




                 Figure 5: Interaction of OPES Entities

   =
---------------------------------------------------------------------


2.5 Tracing Facility

   The OPES architecture requires that each data dispatcher to provide
   tracing facilities that allow the appropriate verification of its
   operation.  The OPES architecture requires that tracing be feasible
   on the OPES flow per OPES processor using  in-band annotation.  One
   of those annotations could be a URL with more detailed information =
on
   the transformation that occurred to the data on the OPES flow.

   Providing the ability for in-band annotation MAY require header
   extensions  on the application protocol that is used (e.g., HTTP).
   However, the presence of an OPES processor in the data request/
   responce flow SHALL NOT interfere with the operations of non-OPES
   aware clients and servers.  OPES processors, content server and
   content consumer MAY use OPES extensions to the base protocol =
(HTTP),
   but support of these extensions SHALL NOT be required.

   OPES processors must obey tracing, reporting and notification
   requirements set by the center of authority in the trust domain to



Barbir , et al.         Expires December 17, 2002              [Page =
10]
=0C
Internet-Draft              OPES Architecture                  June =
2002


   which OPES processor belongs.  As part of these requirements OPES
   processor may be instructed to reject or ignore such requirements
   that originate from other trust domains.
















































Barbir , et al.         Expires December 17, 2002              [Page =
11]
=0C
Internet-Draft              OPES Architecture                  June =
2002


3. Security and Privacy Considerations

   Each data flow must be secured in accordance with several policies.
   The primary stakeholders are the data consumer and the data =
provider.
   The secondary stakeholders are the entities to which they may have
   delegated their trust.  The other stakeholders are the owners of the
   callout servers.  Any of these parties may be participants in the
   OPES architecture.

   These parties must have a model, explicit or implicit, describing
   their trust policy; which of the other parties are trusted to =
operate
   on data, and what security enhancements are required for
   communication.  The trust might be delegated for all data, or it
   might be restricted to granularity as small as an application data
   unit.

   All parties that are involved in enforcing policies must communicate
   the policies to the parties that are involved.  These parties are
   trusted to adhere to the communicated policies.

   In order to delegate fine-grained trust, the parties must convey
   policy information by implicit contract, by a setup protocol, by a
   dynamic negotiation protocol, or in-line with application data
   headers.

3.1 Trust Domains

   The delegation of authority starts at either a data consumer or data
   provider and moves to more distant entities in a "stepwise" fashion.
   Stepwise means A delegates to B and B delegates to C and so forth.
   The entities thus "colored" by the delegation are said to form a
   trust domain with respect to the original delegating party.  Here,
   "Colored" means that if the first step in the chain is the data
   provider, then the stepwise delegation "colors" the chain with that
   data "provider" color.  The only colors that are defined are the =
data
   "provider" and the data "consumer".  Delegation of authority
   (coloring) propagates from the content producer start of authority =
or
   from the content consumer start of authority, that may be different
   from the end points in the data flow.

   An OPES processor may be in several trust domains at any time.  =
There
   is no restriction on whether the OPES processors are authorized by
   data consumers and/or data providers.  The original party has the
   option of forbidding or limiting redelegation.

   An OPES processor must have a representation of its trust domain
   memberships that it can report in whole or in part for tracing
   purposes.  It must include the name of the party which delegated =
each



Barbir , et al.         Expires December 17, 2002              [Page =
12]
=0C
Internet-Draft              OPES Architecture                  June =
2002


   privilege to it.

3.2 Callout protocol

   The determination of whether or not OPES processors will use the
   measures that are described in the previous section during their
   communication with callout servers depends on the details of how the
   primary parties delegated trust to the OPES processors and the trust
   relationship between the OPES processors and the callout server.  If
   the OPES processors are in a single administrative domain with =
strong
   confidentiality guarantees, then encryption may be optional.  In
   other cases, encryption and strong authentication would be at least
   strongly recommended.

   If the delegation mechanism names the trusted parties and their
   privileges in some way that permits authentication, then the OPES
   processors will be responsible for enforcing the policy and for =
using
   authentication as part of that enforcement.

   The callout servers must be aware of the policy governing the
   communication path.  They must not, for example, communicate
   confidential information to auxiliary servers outside the trust
   domain.

   A separate security association must be used for each channel
   established between an OPES processor and a callout server.  The
   channels must be separate for different primary parties.

3.3 Privacy

   Some data from data consumers is considered "private" or =
"sensitive",
   and OPES processors must both advise the primary parties of the =
their
   privacy policy and respect the policies of the primary parties.  The
   privacy information must be conveyed on a per-flow basis.

   The callout servers must also participate in handling of private
   data, and they must be prepared to announce their own capabilities
   and to enforce the policy required by the primary parties.

3.4 Establishing trust

   The OPES processor will have configuration policy specifying what
   privileges the callout servers have and how they are to be
   identified.  This is especially critical for third-party (fourth-
   party, etc.) callout servers.  OPES uses standard protocols for
   authenticating and otherwise security communication with callout
   servers.




Barbir , et al.         Expires December 17, 2002              [Page =
13]
=0C
Internet-Draft              OPES Architecture                  June =
2002


   An OPES processor will have a trusted method for receiving
   configuration information such as rules for the data dispatcher,
   trusted callout servers, primary parties that opt-in or opt-out of
   individual services, etc.

3.5 End-to-end Integrity

   Digital signature techniques can be used to mark data changes in =
such
   a way that a third-party can verify that the changes are or are not
   consistent with the originating party's policy.  This requires an
   inline manner of specifying policy and its binding to data, a trace
   of changes and the party making the changes, and strong identities
   and authentication methods.

   Strong end-to-end integrity can fulfill some of the functions
   required by "tracing".



































Barbir , et al.         Expires December 17, 2002              [Page =
14]
=0C
Internet-Draft              OPES Architecture                  June =
2002


4. Summary

   Although the architecture supports a wide range of cooperative
   transformation services, it has few requirements for
   interoperability.

   The necessary and sufficient elements are specified in the following
   documents:

   o  the OPES ruleset schema [6] which defines the syntax and =
semantics
      of the rules interpreted by a data dispatcher; and,

   o  the OPES callout protocol (OCP) [7] which defines the protocol
      between a data dispatcher and a callout server.





































Barbir , et al.         Expires December 17, 2002              [Page =
15]
=0C
Internet-Draft              OPES Architecture                  June =
2002


References

   [1]  McHenry, S., et. al, "OPES Scenarios and Use Cases", Internet-
        Draft TBD, May 2002.

   [2]  Floyd, S. and L. Daigle, "IAB Architectural and Policy
        Considerations for Open Pluggable Edge Services", RFC 3238,
        January 2002.

   [3]  Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
        Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S.
        Waldbusser, "Terminology for Policy-Based Management", RFC =
3198,
        November 2001.

   [4]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
        Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
        HTTP/1.1", RFC 2616, June 1999.

   [5]  OPES working group, "OPES Service Authorization and Enforcement
        Requirements", Internet-Draft TBD, May 2002.

   [6]  OPES working group, "OPES Ruleset Schema", Internet-Draft TBD,
        May 2002.

   [7]  A. Beck et al., "Requirements for OPES Callout Protocols",
        Internet-Draft http://www.ietf.org/internet-drafts/draft-ietf-
        opes-protocol-reqs-00.txt, May 2002.


Authors' Addresses

   Abbie Barbir
   Nortel Networks
   3500 Carling Avenue
   Nepean, Ontario  K2H 8E9
   Canada

   Phone: +1 613 763 5229
   EMail: abbieb@nortelnetworks.com












Barbir , et al.         Expires December 17, 2002              [Page =
16]
=0C
Internet-Draft              OPES Architecture                  June =
2002


   Robin Chen
   AT&T Labs
   Room E219,  180 Park Avenue
   Florham Park, NJ  07932
   US

   Phone: +1 973 360 8653
   EMail: chen@research.att.com


   Markus Hofmann
   Bell Labs/Lucent Technologies
   Room 4F-513
   101 Crawfords Corner Road
   Holmdel, NJ  07733
   US

   Phone: +1 732 332 5983
   EMail: hofmann@bell-labs.com


   Hilarie Orman
   Purple Streak Development

   EMail: ho@alum.mit.edu


   Reinaldo Penno
   Nortel Networks
   4555 Great America Parkway
   Santa Clara, CA  95054
   US

   EMail: rpenno@nortelnetworks.com


   Gary Tomlinson
   The Tomlinson Group

   EMail: gary@tomlinsongroup.net











Barbir , et al.         Expires December 17, 2002              [Page =
17]
=0C
Internet-Draft              OPES Architecture                  June =
2002


Appendix A. Acknowledgements

   The authors gratefully acknowledge the contributions of: Marshall T.
   Rose, John Morris, Oskar Batuner, Mark Baker and Ian Cooper.















































Barbir , et al.         Expires December 17, 2002              [Page =
18]
=0C
Internet-Draft              OPES Architecture                  June =
2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph =
are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Barbir , et al.         Expires December 17, 2002              [Page =
19]
=0C




------_=_NextPart_000_01C216E6.E842307A--


From owner-ietf-openproxy@mail.imc.org  Tue Jun 18 19:30:53 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08423
	for <opes-archive@ietf.org>; Tue, 18 Jun 2002 19:30:52 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5IMxlE25391
	for ietf-openproxy-bks; Tue, 18 Jun 2002 15:59:47 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5IMxkn25386
	for <ietf-openproxy@imc.org>; Tue, 18 Jun 2002 15:59:46 -0700 (PDT)
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.2/8.12.2) with ESMTP id g5IMxX6R034293;
	Tue, 18 Jun 2002 18:59:33 -0400 (EDT)
Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8])
	by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g5IMxZk72180;
	Tue, 18 Jun 2002 18:59:35 -0400 (EDT)
Received: from bell-labs.com ([135.5.126.183])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id SAA16920;
	Tue, 18 Jun 2002 18:59:31 -0400 (EDT)
Message-ID: <3D0FB85C.6020608@bell-labs.com>
Date: Tue, 18 Jun 2002 17:46:52 -0500
From: Andre Beck <abeck@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-US
MIME-Version: 1.0
To: Internet-Drafts@ietf.org
CC: "ietf-openproxy@imc.org" <ietf-openproxy@imc.org>,
        Marshall Rose
 <mrose@dbc.mtview.ca.us>,
        Markus Hofmann <hofmann@bell-labs.com>
Subject: draft-ietf-opes-protocol-reqs-01
Content-Type: multipart/mixed;
 boundary="------------040801030708080008050104"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This is a multi-part message in MIME format.
--------------040801030708080008050104
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

Please publish the attached OPES WG draft as
"draft-ietf-opes-protocol-reqs-01".


--------------040801030708080008050104
Content-Type: text/plain;
 name="draft-ietf-opes-protocol-reqs-01.txt"
Content-Disposition: inline;
 filename="draft-ietf-opes-protocol-reqs-01.txt"
Content-Transfer-Encoding: 7bit




Open Pluggable Edge Services                                     A. Beck
Internet-Draft                                                M. Hofmann
Expires: December 17, 2002                           Lucent Technologies
                                                                H. Orman
                                               Purple Streak Development
                                                                R. Penno
                                                         Nortel Networks
                                                               A. Terzis
                                                   Individual Consultant
                                                           June 18, 2002


                Requirements for OPES Callout Protocols
                    draft-ietf-opes-protocol-reqs-01

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 17, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This document specifies the requirements that the OPES (Open
   Pluggable Edge Services) callout protocol must satisfy in order to
   support the remote execution of OPES services [1].  The requirements
   are intended to help evaluating possible protocol candidates and to
   guide the development of such protocols.



Beck, et al.            Expires December 17, 2002               [Page 1]

Internet-Draft    Requirements for OPES Callout Protocols      June 2002


Table of Contents

   1.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.   Functional Requirements  . . . . . . . . . . . . . . . . . .   5
   3.1  Callout Transactions . . . . . . . . . . . . . . . . . . . .   5
   3.2  Callout Channels . . . . . . . . . . . . . . . . . . . . . .   5
   3.3  Reliability  . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.4  Congestion and Flow Control  . . . . . . . . . . . . . . . .   6
   3.5  Support for Keep-Alive Mechanism . . . . . . . . . . . . . .   6
   3.6  Operation in NAT Environments  . . . . . . . . . . . . . . .   7
   3.7  Multiple Callout Servers . . . . . . . . . . . . . . . . . .   7
   3.8  Multiple OPES Processors . . . . . . . . . . . . . . . . . .   7
   3.9  Support for Different Application Protocols  . . . . . . . .   7
   3.10 Capability and Parameter Negotiations  . . . . . . . . . . .   7
   3.11 Meta Data and Instructions . . . . . . . . . . . . . . . . .   8
   3.12 Asynchronous Message Exchange  . . . . . . . . . . . . . . .   9
   3.13 Message Segmentation . . . . . . . . . . . . . . . . . . . .   9
   4.   Performance Requirements . . . . . . . . . . . . . . . . . .  11
   4.1  Protocol Efficiency  . . . . . . . . . . . . . . . . . . . .  11
   5.   Security Requirements  . . . . . . . . . . . . . . . . . . .  12
   5.1  Authentication, Confidentiality, and Integrity . . . . . . .  12
   5.2  Hop-by-Hop Confidentiality . . . . . . . . . . . . . . . . .  12
   5.3  Operation Across Un-trusted Domains  . . . . . . . . . . . .  12
   5.4  Privacy  . . . . . . . . . . . . . . . . . . . . . . . . . .  13
   6.   Security Considerations  . . . . . . . . . . . . . . . . . .  14
        References . . . . . . . . . . . . . . . . . . . . . . . . .  15
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  15
   A.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  17
   B.   Change Log . . . . . . . . . . . . . . . . . . . . . . . . .  18
        Full Copyright Statement . . . . . . . . . . . . . . . . . .  19




















Beck, et al.            Expires December 17, 2002               [Page 2]

Internet-Draft    Requirements for OPES Callout Protocols      June 2002


1. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [2].














































Beck, et al.            Expires December 17, 2002               [Page 3]

Internet-Draft    Requirements for OPES Callout Protocols      June 2002


2. Introduction

   The Open Pluggable Edge Services (OPES) architecture [1] enables
   cooperative application services (OPES services) between a data
   provider, a data consumer, and zero or more OPES processors.  The
   application services under consideration analyze and possibly
   transform application-level messages exchanged between the data
   provider and the data consumer.

   The execution of such services is governed by a set of filtering
   rules installed on the OPES processor.  The rules enforcement can
   trigger the execution of service applications local to the OPES
   processor.  Alternatively, the OPES processor can distribute the
   responsibility of service execution by communicating and
   collaborating with one or more remote callout servers.  As described
   in [1], an OPES processor communicates with and invokes services on a
   callout server by using a callout protocol.  This document presents
   the requirements for such a protocol.

   The requirements in this document are divided into three categories -
   functional requirements, performance requirements, and security
   requirements.  Each requirement is presented as one or more
   statements, followed by brief explanatory material as appropriate.




























Beck, et al.            Expires December 17, 2002               [Page 4]

Internet-Draft    Requirements for OPES Callout Protocols      June 2002


3. Functional Requirements

3.1 Callout Transactions

   The OPES callout protocol MUST enable an OPES processor and a callout
   server to perform callout transactions with the purpose of exchanging
   partial or complete application-level protocol messages (or
   modifications thereof).  More specifically, the callout protocol MUST
   enable an OPES processor to forward a complete or partial application
   message to a callout server so that one or more OPES services can
   process the forwarded application message (or parts thereof).  The
   result of the service operation may be a modified application
   message.  The callout protocol MUST therefore enable the callout
   server to return a modified application message or the modified parts
   of an application message to the OPES processor.

   A callout transaction is defined as a message exchange between an
   OPES processor and a callout server consisting of a callout request
   and a callout response.  Both, the callout request as well as the
   callout response, MAY each consist of one or more protocol messages,
   i.e.  a series of protocol messages.

   Callout transactions are always initiated by a callout request from
   an OPES processor and typically terminated by a callout response from
   a callout server.  The OPES callout protocol MUST, however, also
   allow either endpoint of a callout transaction to terminate a callout
   transaction prematurely, i.e.  before a callout request or response
   has been completely received by the corresponding endpoint.  The
   callout protocol MAY provide an explicit (e.g.  through a termination
   message) or implicit (e.g.  through a connection tear-down) mechanism
   to terminate a callout transaction prematurely.  Such a mechanism
   MUST ensure, however, that a premature termination of a callout
   transaction does not result in the loss of application message data.

   A premature termination of a callout transaction is required to
   support OPES services which may terminate even before they have
   processed the entire application message.  Content analysis services,
   for example, may be able to classify a Web object after having
   processed just the first few bytes of a Web object.

   The callout protocol MUST further enable a callout server to report
   back to the OPES processor the result of a callout transaction, e.g.
   in the form of a status code.

3.2 Callout Channels

   The OPES callout protocol MUST enable an OPES processor and a callout
   server to perform multiple callout transactions over a callout



Beck, et al.            Expires December 17, 2002               [Page 5]

Internet-Draft    Requirements for OPES Callout Protocols      June 2002


   channel.  A callout channel is defined as a logical connection at the
   application-layer between an OPES processor and a callout server.

   Callout channels MUST always be established by an OPES processor.  A
   callout channel MAY be closed by either endpoint of the callout
   channel provided that all callout transactions associated with the
   channel have terminated.

   A callout channel MAY have certain parameters associated with it, for
   example parameters that control the fail-over behavior of channel
   endpoints.  Callout channel parameters MAY be negotiated between OPES
   processors and callout servers (see Section 3.10).

3.3 Reliability

   The OPES callout protocol MUST be able to provide ordered reliability
   for the communication between OPES processor and callout server.
   Additionally, the callout protocol SHOULD be able to provide
   unordered reliability.

   In order to satisfy the reliability requirements, the callout
   protocol MAY specify that it must be used with a lower-level
   transport protocol which provides ordered reliability at the
   transport-layer.

3.4 Congestion and Flow Control

   The OPES callout protocol MUST ensure that congestion and flow
   control mechanisms are applied on all callout transactions.  For this
   purpose, the callout protocol MAY specify callout protocol-specific
   mechanisms or refer to a lower-level transport protocol and discuss
   how its mechanisms provide for congestion and flow control.

3.5 Support for Keep-Alive Mechanism

   The OPES callout protocol MUST provide an optional keep-alive
   mechanism which, if used, would allow both endpoints of a callout
   channel to detect a failure of the other endpoint even in the absence
   of callout transactions.  The callout protocol MAY specify that keep-
   alive messages be exchanged over existing callout channel connections
   or a separate connection between OPES processor and callout server.

   The detection of a callout server failure may enable an OPES
   processor to establish a channel connection with a stand-by callout
   server so that future callout transactions do not result in the loss
   of application message data.  The detection of the failure of an OPES
   processor may enable a callout server to release resources which
   would otherwise not be available for callout transactions with other



Beck, et al.            Expires December 17, 2002               [Page 6]

Internet-Draft    Requirements for OPES Callout Protocols      June 2002


   OPES processors.

3.6 Operation in NAT Environments

   The OPES protocol SHOULD be NAT-friendly, i.e.  its operation should
   not be compromised by the presence of one or more NAT devices in the
   path between an OPES processor and a callout server.

3.7 Multiple Callout Servers

   The OPES callout protocol MUST allow an OPES processor to
   simultaneously communicate with more than one callout server.

   In larger networks, OPES services are likely to be hosted by
   different callout servers.  Therefore, an OPES processor will likely
   have to communicate with multiple callout servers.  The protocol
   design MUST enable an OPES processor to do so.

3.8 Multiple OPES Processors

   The OPES callout protocol MUST allow a callout server to
   simultaneously communicate with more than one OPES processor.

   The protocol design MUST support a scenario in which multiple OPES
   processors use the services of a single callout server.

3.9 Support for Different Application Protocols

   The OPES callout protocol MUST be application protocol-agnostic, i.e.
   it MUST not make any assumptions about the characteristics of the
   application-layer protocol used on the data path between data
   provider and data consumer.

   The OPES entities on the data path may use different application-
   layer protocols, including, but not limited to, HTTP [3] and RTP [4].
   It would be desirable to be able to use the same OPES callout
   protocol for any such application-layer protocol.

3.10 Capability and Parameter Negotiations

   The OPES callout protocol MUST support the negotiation of
   capabilities and callout channel parameters between an OPES processor
   and a callout server.  This implies that the OPES processor and the
   callout server MUST be able to exchange their capabilities and
   preferences and engage into a deterministic negotiation process at
   the end of which the two endpoints have either agreed on the
   capabilities and parameters to be used for future callout channel
   transactions or determined that their capabilities are incompatible.



Beck, et al.            Expires December 17, 2002               [Page 7]

Internet-Draft    Requirements for OPES Callout Protocols      June 2002


   Capabilities and parameters that could be negotiated between an OPES
   processor and a callout server include (but are not limited to):
   callout protocol version, transport-layer protocol, fail-over
   behavior, heartbeat rate for keep-alive messages, security-related
   parameters etc.

   Channel parameters may also pertain to the characteristics of OPES
   callout services if, for example, callout channels are associated
   with one or more specific OPES services.  An OPES service-specific
   parameter may, for example, specify which parts of an application
   message an OPES service requires for its operation.

   The parties to a callout protocol MAY use callout channels to
   negotiate all or some of their capabilities and parameters.  They MAY
   also use a separate control connection for this purpose.  If there is
   a need for callout channel parameters, then they MUST be negotiated
   on a per-callout channel basis and before any callout transactions
   are performed over the corresponding channel.  Other parameters and
   capabilities, such as the fail-over behavior, MAY be negotiated
   between the two endpoints independently of callout channels.

3.11 Meta Data and Instructions

   The OPES callout protocol MUST provide a mechanism for the endpoints
   of a particular callout transaction to include in callout requests
   and responses meta data and instructions for the OPES processor or
   callout server.

   Specifically, the callout protocol MUST enable an OPES processor to
   include information about the forwarded application message in a
   callout request, e.g.  in order to specify the type of the forwarded
   application message or to specify what part(s) of the application
   message are forwarded to the callout server.  Likewise, the callout
   server MUST be able to include information about the returned
   application message.

   The OPES processor MUST further be able to include an ordered list of
   one or more uniquely specified OPES services which are to be
   performed on the forwarded application message in the specified
   order.  However, as the callout protocol MAY also choose to associate
   callout channels with specific OPES services, there may not be a need
   to identify OPES service on a per-callout transaction basis.

   Additionally, the OPES callout protocol MUST allow the callout server
   to indicate to the OPES processor the cacheability of callout
   responses.  This implies that callout responses may have to carry
   cache-control instructions for the OPES processor.




Beck, et al.            Expires December 17, 2002               [Page 8]

Internet-Draft    Requirements for OPES Callout Protocols      June 2002


   The OPES callout protocol MUST further enable the OPES processor to
   indicate to the callout server if it has kept a local copy of the
   forwarded application message (or parts thereof).  This information
   enables the callout server to determine whether the forwarded
   application message must be returned to the OPES processor even it
   has not been modified by an OPES service.

   The OPES callout protocol MUST also allow OPES processors to comply
   with the tracing requirements of the OPES architecture as laid out in
   [1] and [5].  This implies that the callout protocol MUST enable a
   callout server to convey to the OPES processor information about the
   OPES service operations performed on the forwarded application
   message.

3.12 Asynchronous Message Exchange

   The OPES callout protocol MUST support an asynchronous message
   exchange between an OPES processor and a callout server.

   In order to allow asynchronous processing on the OPES processor and
   callout server, it MUST be possible to separate request issuance from
   response processing.  The protocol MUST therefore allow multiple
   outstanding requests and provide a method to correlate responses to
   requests.

   Additionally, the callout protocol MUST enable a callout server to
   respond to a callout request before it has received the entire
   request.

3.13 Message Segmentation

   The OPES callout protocol MUST allow an OPES processor to forward an
   application message to a callout server in a series of smaller
   message fragments.  The callout protocol MUST further enable the
   receiving callout server to assemble the fragmented application
   message.

   Likewise, the callout protocol MUST enable a callout server to return
   an application message to an OPES processor in a series of smaller
   message fragments.  The callout protocol MUST enable the receiving
   OPES processor to assemble the fragmented application message.

   Depending on the application-layer protocol used on the data path,
   application messages may be very large in size (for example in the
   case of audio/video streams) or of unknown size.  In both cases, the
   OPES processor has to initiate a callout transaction before it has
   received the entire application message to avoid long delays for the
   data consumer.  The OPES processor MUST therefore be able to forward



Beck, et al.            Expires December 17, 2002               [Page 9]

Internet-Draft    Requirements for OPES Callout Protocols      June 2002


   fragments or chunks of an application message to a callout server as
   it receives them from the data provider or consumer.  Likewise, the
   callout server MUST be able to process and return application message
   fragments as it receives them from the OPES processor.















































Beck, et al.            Expires December 17, 2002              [Page 10]

Internet-Draft    Requirements for OPES Callout Protocols      June 2002


4. Performance Requirements

4.1 Protocol Efficiency

   The OPES callout protocol SHOULD be efficient in that it minimizes
   the additionally introduced latency, for example by minimizing the
   protocol overhead.

   As OPES callout transactions introduce additional latency to
   application protocol transactions on the data path, calllout protocol
   efficiency is crucial.








































Beck, et al.            Expires December 17, 2002              [Page 11]

Internet-Draft    Requirements for OPES Callout Protocols      June 2002


5. Security Requirements

   In the absence of any security mechanisms, sensitive information
   might be communicated between the OPES processor and the callout
   server in violation of either endpoint's security and privacy policy
   through misconfiguration or a deliberate insider attack.  By using
   strong authentication, message encryption, and integrity checks, this
   threat can be minimized to a smaller set of insiders and/or operator
   configuration errors.

   The OPES processor and the callout servers SHOULD have enforceable
   policies that limit the parties they communicate with, that determine
   the protections to use based on identities of the endpoints and other
   data (such as enduser policies).  In order to enforce the policies,
   they MUST be able to authenticate the callout protocol endpoints
   using cryptographic methods.

5.1 Authentication, Confidentiality, and Integrity

   The parties to the callout protocol MUST have a sound basis for
   binding authenticated identities to the protocol endpoints, and they
   MUST verify that these identities are consistent with their security
   policies.

   The OPES callout protocol MUST provide message authentication,
   confidentiality, and integrity between the OPES processor and the
   callout server.  It MUST provide mutual authentication.  The callout
   protocol SHOULD use existing security mechanisms for this purpose.
   The callout protocol specification is not required to specify the
   security mechanisms, but it MAY instead refer to a lower-level
   security protocol and discuss how its mechanisms are to be used with
   the callout protocol.

5.2 Hop-by-Hop Confidentiality

   If encryption is a requirement for the content path, then this
   confidentiality MUST be extended to the communication between the
   callout servers and the OPES processor.  In order to minimize data
   exposure, the callout protocol MUST use a different encryption key
   for each encrypted content stream.

5.3 Operation Across Un-trusted Domains

   The OPES callout protocol MUST operate securely across un-trusted
   domains between the OPES  processor and the callout server.

   If the communication channels between the OPES processor and callout
   server cross outside of the organization taking responsibility for



Beck, et al.            Expires December 17, 2002              [Page 12]

Internet-Draft    Requirements for OPES Callout Protocols      June 2002


   the OPES services, then endpoint authentication and message
   protection (confidentiality and integrity) MUST be used.

5.4 Privacy

   Any communication carrying information relevant to privacy policies
   MUST protect the data using encryption.












































Beck, et al.            Expires December 17, 2002              [Page 13]

Internet-Draft    Requirements for OPES Callout Protocols      June 2002


6. Security Considerations

   The security requirements for the OPES callout protocol are discussed
   in Section 5.















































Beck, et al.            Expires December 17, 2002              [Page 14]

Internet-Draft    Requirements for OPES Callout Protocols      June 2002


References

   [1]  Barbir, A., "An Architecture for Open Pluggable Edge Services
        (OPES)", draft-ietf-opes-architecture-01 (work in progress), May
        2002.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, March 1997.

   [3]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
        Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
        HTTP/1.1", RFC 2616, June 1999.

   [4]  Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
        "RTP: A Transport Protocol for Real-Time Applications", RFC
        1889, January 1996.

   [5]  Floyd, S. and L. Daigle, "IAB Architectural and Policy
        Considerations for Open Pluggable Edge Services", RFC 3238,
        January 2002.


Authors' Addresses

   Andre Beck
   Lucent Technologies
   101 Crawfords Corner Road
   Holmdel, NJ  07733
   US

   EMail: abeck@bell-labs.com


   Markus Hofmann
   Lucent Technologies
   Room 4F-513
   101 Crawfords Corner Road
   Holmdel, NJ  07733
   US

   Phone: +1 732 332 5983
   EMail: hofmann@bell-labs.com









Beck, et al.            Expires December 17, 2002              [Page 15]

Internet-Draft    Requirements for OPES Callout Protocols      June 2002


   Hilarie Orman
   Purple Streak Development

   EMail: ho@alum.mit.edu
   URI:   http://www.purplestreak.com


   Reinaldo Penno
   Nortel Networks
   2305 Mission College Boulevard
   San Jose, CA  95134
   US

   EMail: rpenno@nortelnetworks.com


   Andreas Terzis
   Individual Consultant
   150 Golf Course Dr.
   Rohnert Park, CA  94928
   US

   Phone: +1 707 586 8864
   EMail: aterzis@sbcglobal.net



























Beck, et al.            Expires December 17, 2002              [Page 16]

Internet-Draft    Requirements for OPES Callout Protocols      June 2002


Appendix A. Acknowledgments

   This document is based in parts on previous work by Anca Dracinschi
   Sailer, Volker Hilt, and Rama R.  Menon.

   The authors would like to thank the participants of the OPES WG for
   their comments on this draft.












































Beck, et al.            Expires December 17, 2002              [Page 17]

Internet-Draft    Requirements for OPES Callout Protocols      June 2002


Appendix B. Change Log

   Changes from draft-ietf-opes-protocol-reqs-00.txt

   o  Aligned terminology with [1]

   o  Clarified in Section 3.11 that OCP requests not only have to
      identify one or more OPES services, but also the order in which
      the services are to be executed

   o  Removed requirement from Section 4.1 that OCP must satisfy
      performance requirements of the application-layer protocol used
      between data consumer and provider






































Beck, et al.            Expires December 17, 2002              [Page 18]

Internet-Draft    Requirements for OPES Callout Protocols      June 2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Beck, et al.            Expires December 17, 2002              [Page 19]




--------------040801030708080008050104--




From owner-ietf-openproxy@mail.imc.org  Wed Jun 19 12:17:15 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25294
	for <opes-archive@ietf.org>; Wed, 19 Jun 2002 12:17:13 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5JFaJA19625
	for ietf-openproxy-bks; Wed, 19 Jun 2002 08:36:19 -0700 (PDT)
Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JFaHn19615
	for <ietf-openproxy@imc.org>; Wed, 19 Jun 2002 08:36:17 -0700 (PDT)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5JFZeS01862;
	Wed, 19 Jun 2002 11:35:40 -0400 (EDT)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <KTYBWBM7>; Wed, 19 Jun 2002 11:35:39 -0400
Message-ID: <87609AFB433BD5118D5E0002A52CD75402937C24@zcard0k6.ca.nortel.com>
From: "Abbie Barbir" <abbieb@nortelnetworks.com>
To: internet-drafts@ietf.org
Cc: "'ietf-openproxy@imc.org'" <ietf-openproxy@imc.org>,
        "'Markus Hofmann'" <markus@mhof.com>,
        "'Marshall Rose'" <mrose@dbc.mtview.ca.us>,
        "Abbie Barbir" <abbieb@nortelnetworks.com>
Subject: Publish Draft: draft-ietf-opes-architecture-02
Date: Wed, 19 Jun 2002 11:35:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C217A6.F61B3B68"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C217A6.F61B3B68
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C217A6.F61B3B68"


------_=_NextPart_001_01C217A6.F61B3B68
Content-Type: text/plain;
	charset="iso-8859-1"

Please publish the attached as an Internet Draft

draft-ietf-opes-architecture-02

thanks

abbie


------_=_NextPart_001_01C217A6.F61B3B68
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE>Publish Draft: draft-ietf-opes-architecture-02</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Please publish the attached as an Internet Draft</FONT>
</P>

<P><FONT SIZE=2>draft-ietf-opes-architecture-02</FONT>
</P>

<P><FONT SIZE=2>thanks</FONT>
</P>

<P><FONT SIZE=2>abbie</FONT>
</P>

<P><FONT FACE="Arial" SIZE=2 COLOR="#000000"></FONT>&nbsp;

</BODY>
</HTML>
------_=_NextPart_001_01C217A6.F61B3B68--

------_=_NextPart_000_01C217A6.F61B3B68
Content-Type: text/plain;
	name="draft-ietf-opes-architecture-02.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-opes-architecture-02.txt"
Content-Transfer-Encoding: quoted-printable



Network Working Group                                     Abbie. Barbir
Internet-Draft                                           Nortel =
Networks
Expires: December 18, 2002                                       R. =
Chen
                                                               AT&T =
Labs
                                                              M. =
Hofmann
                                           Bell Labs/Lucent =
Technologies
                                                                H. =
Orman
                                               Purple Streak =
Development
                                                                R. =
Penno
                                                         Nortel =
Networks
                                                            G. =
Tomlinson
                                                     The Tomlinson =
Group
                                                           June 19, =
2002


        An Architecture for Open Pluggable Edge Services (OPES)
                    draft-ietf-opes-architecture-02

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six =
months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 18, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This memo defines an architecture for a cooperative application
   service in which a data provider, a data consumer, and zero or more



Barbir , et al.         Expires December 18, 2002               [Page =
1]
=0C
Internet-Draft              OPES Architecture                  June =
2002


   application entities cooperatively realize a data stream service.

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  =
3
   2.    The Architecture . . . . . . . . . . . . . . . . . . . . . .  =
4
   2.1   OPES Entities  . . . . . . . . . . . . . . . . . . . . . . .  =
4
   2.1.1 Data Dispatcher  . . . . . . . . . . . . . . . . . . . . . .  =
5
   2.2   OPES Flows . . . . . . . . . . . . . . . . . . . . . . . . .  =
6
   2.3   OPES Rules . . . . . . . . . . . . . . . . . . . . . . . . .  =
7
   2.4   Callout Servers  . . . . . . . . . . . . . . . . . . . . . .  =
8
   2.5   Tracing Facility . . . . . . . . . . . . . . . . . . . . . . =
10
   3.    Security and Privacy Considerations  . . . . . . . . . . . . =
12
   3.1   Trust Domains  . . . . . . . . . . . . . . . . . . . . . . . =
12
   3.2   Callout protocol . . . . . . . . . . . . . . . . . . . . . . =
13
   3.3   Privacy  . . . . . . . . . . . . . . . . . . . . . . . . . . =
13
   3.4   Establishing trust . . . . . . . . . . . . . . . . . . . . . =
13
   3.5   End-to-end Integrity . . . . . . . . . . . . . . . . . . . . =
14
   4.    Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . =
15
         References . . . . . . . . . . . . . . . . . . . . . . . . . =
16
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . =
16
   A.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . =
18
         Full Copyright Statement . . . . . . . . . . . . . . . . . . =
19




























Barbir , et al.         Expires December 18, 2002               [Page =
2]
=0C
Internet-Draft              OPES Architecture                  June =
2002


1. Introduction

   When realizing a data stream service between a provider and a
   consumer, the need may arise to provision the use of other
   application entities, in addition to the provider and consumer.  For
   example, some party may wish to customize a data stream as a service
   to a consumer.  The customization step might be based on the
   customer's geographical locality (e.g., language) or resource
   availability (e.g., display capabilities).

   In some cases in may be beneficial to provide a customization =
service
   at network location instead of deploying it at either the provider =
or
   the consumer host.  For certain services performed on end-user =
behalf
   this may be the only option of service deployment.  In this case, =
one
   or more additional application entities may participate in the data
   stream service.  There are many possible provisioning scenarios =
which
   make a data stream service attractive.  In [1] a  description of
   several scenarios is provided.

   This document presents the architectural components of Open =
Pluggable
   Edge Services (OPES) that are needed in order to perform a data
   stream service.  The architecture addresses the IAB considerations
   described in [2].  These considerations are covered in the various
   parts of the document, specifically with respect to tracing (Section
   2.5) and security considerations (Section 3).

   The document is organized as follows: Section 2 introduces the OPES
   architecture.  Section 3 discusses security considerations.  Section
   4 provides a summary of the architecture and the requirements for
   interoperability.





















Barbir , et al.         Expires December 18, 2002               [Page =
3]
=0C
Internet-Draft              OPES Architecture                  June =
2002


2. The Architecture

   The architecture of Open Pluggable Edge Services (OPES) can be
   described in terms of three interrelated concepts, mainly:

   o  OPES entities: processes operating in the network;

   o  OPES flows:  data flows that are cooperatively realized by the
      OPES entities; and,

   o  OPES rules: these specify when and how to execute OPES
      intermediary services.


2.1 OPES Entities

   An OPES entity is an application that operates on a data flow =
between
   a data provider application and a data consumer application.  OPES
   entities can be one of the following:

   o  an OPES service application, which analyzes and possibly
      transforms messages exchanged between the data provider
      application and the data consumer application; or,

   o  a data dispatcher, which invokes an OPES service application =
based
      on OPES ruleset and application-specific knowledge.

   In the network, OPES entities reside inside OPES processors.  The
   cooperative behavior of OPES entities introduces additional
   functionality for each data flow provided that it matches the OPES
   rules.

   In the current work, the data provider and data consumer =
applications
   are not considered as OPES entities.  The OPES architecture is
   largely independent of the protocol that is used by the OPES =
entities
   to exchange data.  However, this document selects HTTP [4] as the
   example protocol to be used for realizing a data flow.  In this
   regard, the logical implementation  stack of an OPES entity is
   summarized in Figure 1.












Barbir , et al.         Expires December 18, 2002               [Page =
4]
=0C
Internet-Draft              OPES Architecture                  June =
2002


   =
---------------------------------------------------------------------



                                +-------------+
                                |OPES service |
                                | Application |
                                |             |
                                +-------------+
                                |   Data      |
                                | Dispatcher  |
                                |             |
                                +-------------+
                                |             |
                                |    HTTP     |
                                |             |
                                +-------------+
                                |   TCP/IP    |
                                +-------------+
                                |     ...     |
                                +-------------+


                 Figure 1: OPES Logical Implementation

   =
---------------------------------------------------------------------

   Figure 1  depicts a "minimal" stack for OPES.  However, other
   protocols may be present, depending on the functions that are
   performed by the application.

2.1.1  Data Dispatcher

   Data dispatchers include a ruleset that can be compiled from several
   sources and must resolve into an unambiguous result.  The compiled
   ruleset enables an OPES processor to determine which service
   applications to invoke for which data flow.  Accordingly, the data
   dispatcher constitutes an enhanced policy enforcement point, where
   policy rules are evaluated, service-specific data handlers and state
   information is  maintained, as depicted in Figure 2.











Barbir , et al.         Expires December 18, 2002               [Page =
5]
=0C
Internet-Draft              OPES Architecture                  June =
2002


   =
---------------------------------------------------------------------




                                       +----------+
                                       |  callout |
                                       |  server  |
                                       +----------+
                                            ||
                                            ||
                                            ||
                                            ||
                        +--------------------------+
                        | +----------+      ||     |
                        | |   OPES   |      ||     |
                        | |  service |      ||     |
                        | |   appl   |      ||     |
                        | +----------+      ||     |
                        | +----------------------+ |
        OPES flow <---->| | data dispatcher and  | |<----> OPES flow
                        | |   policy enforcement | |
                        | +----------------------+ |
                        |           OPES           |
                        |         processor        |
                        +--------------------------+


                       Figure 2: Data Dispatchers

   =
---------------------------------------------------------------------

   The architecture allows more than one policy enforcement point to be
   present on an OPES flow.

2.2 OPES Flows

   An OPES flow is a cooperative undertaking between a data provider
   application, a data consumer application, zero or more OPES service
   applications, and zero or more data dispatchers.

   In order to understand the trust relationships between OPES =
entities,
   each is labeled as residing in an administrative domain.  Entities
   associated with a given OPES flow may reside in one or more
   administrative domains.

   For example, Figure 2 depicts a data flow (also known as an "OPES
   flow"), that spans two administrative domains.



Barbir , et al.         Expires December 18, 2002               [Page =
6]
=0C
Internet-Draft              OPES Architecture                  June =
2002


   =
---------------------------------------------------------------------



    consumer administrative domain       provider administrative domain
   +------------------------------+     =
+------------------------------+
   |                              |     |                              =
|
   |       data          OPES     |     |     OPES          data       =
|
   |     consumer      processor  |     |   processor     provider     =
|
   |                              |     |                              =
|
   |   +----------+   +--------+  |     |  +--------+   +----------+   =
|
   |   |   data   |   |  OPES  |  |     |  |  OPES  |   |   data   |   =
|
   |   | consumer |   |service |  |     |  |service |   | provider |   =
|
   |   |   appl   |   |  appl  |  |     |  |  appl  |   |   appl   |   =
|
   |   +----------+   +--------+  |     |  +--------+   +----------+   =
|
   |   |          |   |        |  |     |  |        |   |          |   =
|
   |   |   HTTP   |   |  HTTP  |  |     |  |  HTTP  |   |   HTTP   |   =
|
   |   |          |   |        |  |     |  |        |   |          |   =
|
   |   +----------+   +--------+  |     |  +--------+   +----------+   =
|
   |   |  TCP/IP  |   | TCP/IP |  |     |  | TCP/IP |   |  TCP/IP  |   =
|
   |   +----------+   +--------+  |     |  +--------+   +----------+   =
|
   |        ||         ||    ||   |     |   ||    ||         ||        =
|
   |        =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D    =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D    =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D        |
   |                              |     |                              =
|
   +------------------------------+     =
+------------------------------+
            | <----------------- OPES flow -----------------> |


                         Figure 3: An OPES flow

   =
---------------------------------------------------------------------

   Figure 3 depicts two data dispatchers that are present in the OPES
   flow.  However, the architecture allows for zero or more data
   dispatchers to be present in any flow.

2.3 OPES Rules

   OPES policy regarding services and the data provided to them is
   determined by a ruleset consisting of OPES rules.  The rules consist
   of a set of conditions and related actions.  The ruleset is the
   superset of all OPES rules on the processor.  The OPES ruleset
   determines which service applications will operate on a data stream.
   The communication of data stream elements to an application is
   performed by data dispatchers.  In this model, all data  filters are
   invoked for all data.

   In order to ensure predictable behavior  the OPES architecture



Barbir , et al.         Expires December 18, 2002               [Page =
7]
=0C
Internet-Draft              OPES Architecture                  June =
2002


   requires the use of a standardized schema for the purpose of =
defining
   and interpreting the ruleset.  The OPES architecture does not =
require
   a mechanism for configuring a ruleset into a data dispatcher.  This
   is treated as a local matter for each implementation (e.g., through
   the use of a text editor, secure upload protocol, and so on).  =
Future
   revisions of the architecture may introduce such a requirement.

2.4 Callout Servers

   The evaluation of OPES ruleset determines which service applications
   will operate on a data stream.  How the ruleset is evaluated is not
   the subject of the architecture, except to note that it must result
   in the same unambiguous result in all implementations.

   In some cases it may be useful for the OPES processor to distribute
   the responsibility of service evaluation by communicating with one =
or
   more callout servers (cf., [7]).  The situation is illustrated in
   Figure 4, which shows a data dispatcher communicating with multiple
   callout servers as it processes an OPES flow.
































Barbir , et al.         Expires December 18, 2002               [Page =
8]
=0C
Internet-Draft              OPES Architecture                  June =
2002


   =
---------------------------------------------------------------------


                  data        callout       callout         callout
               dispatcher     server        server          server

              +----------+  +---------+   +---------+     +---------+
              |          |  |         |   |         |     |         |
              |   OCP    |  |   OCP   |   |   OCP   | ... |   OCP   |
              |          |  |         |   |         |     |         |
              +----------+  +---------+   +---------+     +---------+
              |  Lower   |  |  Lower  |   |  Lower  |     |  Lower  |
              |  Layer   |  |  Layer  |   |  Layer  |     |  Layer  |
              |Protocols |  |Protocols|   |Protocols|     |Protocols|
              |    .     |  |   .     |   |    .    |     |   .     |
              |    .     |  |   .     |   |    .    |     |   .     |
              +----------+  +---------+   +---------+     +---------+
                 ||              ||            ||              ||
                 ||=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D     =
       ||     ...      ||
                 ||                            ||              ||
                 =
||=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D              ||
                 ||                                            ||
                 =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=




              Figure 4: An OPES flow with Callout servers

   =
---------------------------------------------------------------------

   In Figure 4, a data dispatcher invokes the services of a callout
   server by using the OPES callout protocol (OCP).  The requirements
   for the OCP are given in [7].  The OCP is application-agnostic, =
being
   unaware of the semantics of the encapsulated  application protocol
   (e.g., HTTP).  However, the OCP must  incorporate a service aware
   vectoring capability that parses the data flow according to the
   ruleset and delivers the data to the OPES service application that
   can be local or remote.

   In this model, OPES applications may be executed either on the same
   processor (or even in the same application environment) with the
   dispatcher or on a different OPES processor through OCP.  The =
general
   interaction situation is depicted in Figure 5, which illustrates the
   positions and interaction of different components of OPES
   architecture.






Barbir , et al.         Expires December 18, 2002               [Page =
9]
=0C
Internet-Draft              OPES Architecture                  June =
2002


   =
---------------------------------------------------------------------


           +--------------------------+
           | +----------+             |
           | |   OPES   |             |
           | |  service |             |      +----------------+
           | |   appl   |             |      | Callout Server |
           | +----------+             |      |                |
           |     ||                   |      | +--------+     |
           | +----------------------+ |      | | OPES   |     |
           | |     data dispatcher  | |      | | Service|     |
           | +----------------------+ |      | |  App2  |     |
           | |   HTTP     | OCP     | |      | +--------+     |
           | +------------|         |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|  =
OCP   |     |
           | |            |---------+ |      | +--------+     |
           | |   TCP/IP   |           |      +----------------+
    =3D=3D=3D=3D=3D=3D=3D=3D=3D|            =
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D OPES Data Flow =
=3D=3D=3D=3D
           | +------------+           |
           +--------------------------+




                 Figure 5: Interaction of OPES Entities

   =
---------------------------------------------------------------------


2.5 Tracing Facility

   The OPES architecture requires that each data dispatcher to provide
   tracing facilities that allow the appropriate verification of its
   operation.  The OPES architecture requires that tracing be feasible
   on the OPES flow per OPES processor using  in-band annotation.  One
   of those annotations could be a URL with more detailed information =
on
   the transformation that occurred to the data on the OPES flow.

   Providing the ability for in-band annotation MAY require header
   extensions  on the application protocol that is used (e.g., HTTP).
   However, the presence of an OPES processor in the data request/
   response flow SHALL NOT interfere with the operations of non-OPES
   aware clients and servers.  OPES processors, content server and
   content consumer MAY use OPES extensions to the base protocol =
(HTTP),
   but support of these extensions SHALL NOT be required.

   OPES processors must obey tracing, reporting and notification
   requirements set by the center of authority in the trust domain to



Barbir , et al.         Expires December 18, 2002              [Page =
10]
=0C
Internet-Draft              OPES Architecture                  June =
2002


   which OPES processor belongs.  As part of these requirements OPES
   processor may be instructed to reject or ignore such requirements
   that originate from other trust domains.
















































Barbir , et al.         Expires December 18, 2002              [Page =
11]
=0C
Internet-Draft              OPES Architecture                  June =
2002


3. Security and Privacy Considerations

   Each data flow must be secured in accordance with several policies.
   The primary stakeholders are the data consumer and the data =
provider.
   The secondary stakeholders are the entities to which they may have
   delegated their trust.  The other stakeholders are the owners of the
   callout servers.  Any of these parties may be participants in the
   OPES architecture.

   These parties must have a model, explicit or implicit, describing
   their trust policy; which of the other parties are trusted to =
operate
   on data, and what security enhancements are required for
   communication.  The trust might be delegated for all data, or it
   might be restricted to granularity as small as an application data
   unit.

   All parties that are involved in enforcing policies must communicate
   the policies to the parties that are involved.  These parties are
   trusted to adhere to the communicated policies.

   In order to delegate fine-grained trust, the parties must convey
   policy information by implicit contract, by a setup protocol, by a
   dynamic negotiation protocol, or in-line with application data
   headers.

3.1 Trust Domains

   The delegation of authority starts at either a data consumer or data
   provider and moves to more distant entities in a "stepwise" fashion.
   Stepwise means A delegates to B and B delegates to C and so forth.
   The entities thus "colored" by the delegation are said to form a
   trust domain with respect to the original delegating party.  Here,
   "Colored" means that if the first step in the chain is the data
   provider, then the stepwise delegation "colors" the chain with that
   data "provider" color.  The only colors that are defined are the =
data
   "provider" and the data "consumer".  Delegation of authority
   (coloring) propagates from the content producer start of authority =
or
   from the content consumer start of authority, that may be different
   from the end points in the data flow.

   An OPES processor may be in several trust domains at any time.  =
There
   is no restriction on whether the OPES processors are authorized by
   data consumers and/or data providers.  The original party has the
   option of forbidding or limiting redelegation.

   An OPES processor must have a representation of its trust domain
   memberships that it can report in whole or in part for tracing
   purposes.  It must include the name of the party which delegated =
each



Barbir , et al.         Expires December 18, 2002              [Page =
12]
=0C
Internet-Draft              OPES Architecture                  June =
2002


   privilege to it.

3.2 Callout protocol

   The determination of whether or not OPES processors will use the
   measures that are described in the previous section during their
   communication with callout servers depends on the details of how the
   primary parties delegated trust to the OPES processors and the trust
   relationship between the OPES processors and the callout server.  If
   the OPES processors are in a single administrative domain with =
strong
   confidentiality guarantees, then encryption may be optional.  In
   other cases, encryption and strong authentication would be at least
   strongly recommended.

   If the delegation mechanism names the trusted parties and their
   privileges in some way that permits authentication, then the OPES
   processors will be responsible for enforcing the policy and for =
using
   authentication as part of that enforcement.

   The callout servers must be aware of the policy governing the
   communication path.  They must not, for example, communicate
   confidential information to auxiliary servers outside the trust
   domain.

   A separate security association must be used for each channel
   established between an OPES processor and a callout server.  The
   channels must be separate for different primary parties.

3.3 Privacy

   Some data from data consumers is considered "private" or =
"sensitive",
   and OPES processors must both advise the primary parties of the =
their
   privacy policy and respect the policies of the primary parties.  The
   privacy information must be conveyed on a per-flow basis.

   The callout servers must also participate in handling of private
   data, and they must be prepared to announce their own capabilities
   and to enforce the policy required by the primary parties.

3.4 Establishing trust

   The OPES processor will have configuration policy specifying what
   privileges the callout servers have and how they are to be
   identified.  This is especially critical for third-party (fourth-
   party, etc.) callout servers.  OPES uses standard protocols for
   authenticating and otherwise security communication with callout
   servers.




Barbir , et al.         Expires December 18, 2002              [Page =
13]
=0C
Internet-Draft              OPES Architecture                  June =
2002


   An OPES processor will have a trusted method for receiving
   configuration information such as rules for the data dispatcher,
   trusted callout servers, primary parties that opt-in or opt-out of
   individual services, etc.

3.5 End-to-end Integrity

   Digital signature techniques can be used to mark data changes in =
such
   a way that a third-party can verify that the changes are or are not
   consistent with the originating party's policy.  This requires an
   inline manner of specifying policy and its binding to data, a trace
   of changes and the party making the changes, and strong identities
   and authentication methods.

   Strong end-to-end integrity can fulfill some of the functions
   required by "tracing".



































Barbir , et al.         Expires December 18, 2002              [Page =
14]
=0C
Internet-Draft              OPES Architecture                  June =
2002


4. Summary

   Although the architecture supports a wide range of cooperative
   transformation services, it has few requirements for
   interoperability.

   The necessary and sufficient elements are specified in the following
   documents:

   o  the OPES ruleset schema [6] which defines the syntax and =
semantics
      of the rules interpreted by a data dispatcher; and,

   o  the OPES callout protocol (OCP) [7] which defines the protocol
      between a data dispatcher and a callout server.





































Barbir , et al.         Expires December 18, 2002              [Page =
15]
=0C
Internet-Draft              OPES Architecture                  June =
2002


References

   [1]  McHenry, S., et. al, "OPES Scenarios and Use Cases", Internet-
        Draft TBD, May 2002.

   [2]  Floyd, S. and L. Daigle, "IAB Architectural and Policy
        Considerations for Open Pluggable Edge Services", RFC 3238,
        January 2002.

   [3]  Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
        Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S.
        Waldbusser, "Terminology for Policy-Based Management", RFC =
3198,
        November 2001.

   [4]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
        Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
        HTTP/1.1", RFC 2616, June 1999.

   [5]  OPES working group, "OPES Service Authorization and Enforcement
        Requirements", Internet-Draft TBD, May 2002.

   [6]  OPES working group, "OPES Ruleset Schema", Internet-Draft TBD,
        May 2002.

   [7]  A. Beck et al., "Requirements for OPES Callout Protocols",
        Internet-Draft http://www.ietf.org/internet-drafts/draft-ietf-
        opes-protocol-reqs-00.txt, May 2002.


Authors' Addresses

   Abbie Barbir
   Nortel Networks
   3500 Carling Avenue
   Nepean, Ontario  K2H 8E9
   Canada

   Phone: +1 613 763 5229
   EMail: abbieb@nortelnetworks.com












Barbir , et al.         Expires December 18, 2002              [Page =
16]
=0C
Internet-Draft              OPES Architecture                  June =
2002


   Robin Chen
   AT&T Labs
   Room E219,  180 Park Avenue
   Florham Park, NJ  07932
   US

   Phone: +1 973 360 8653
   EMail: chen@research.att.com


   Markus Hofmann
   Bell Labs/Lucent Technologies
   Room 4F-513
   101 Crawfords Corner Road
   Holmdel, NJ  07733
   US

   Phone: +1 732 332 5983
   EMail: hofmann@bell-labs.com


   Hilarie Orman
   Purple Streak Development

   EMail: ho@alum.mit.edu


   Reinaldo Penno
   Nortel Networks
   4555 Great America Parkway
   Santa Clara, CA  95054
   US

   EMail: rpenno@nortelnetworks.com


   Gary Tomlinson
   The Tomlinson Group

   EMail: gary@tomlinsongroup.net











Barbir , et al.         Expires December 18, 2002              [Page =
17]
=0C
Internet-Draft              OPES Architecture                  June =
2002


Appendix A. Acknowledgements

   The authors gratefully acknowledge the contributions of: Marshall T.
   Rose, John Morris, Oskar Batuner, Mark Baker and Ian Cooper.















































Barbir , et al.         Expires December 18, 2002              [Page =
18]
=0C
Internet-Draft              OPES Architecture                  June =
2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph =
are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Barbir , et al.         Expires December 18, 2002              [Page =
19]
=0C




------_=_NextPart_000_01C217A6.F61B3B68--


From owner-ietf-openproxy@mail.imc.org  Wed Jun 19 12:26:42 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25583
	for <opes-archive@ietf.org>; Wed, 19 Jun 2002 12:26:42 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5JG3YY21378
	for ietf-openproxy-bks; Wed, 19 Jun 2002 09:03:34 -0700 (PDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JG3Xn21374
	for <ietf-openproxy@imc.org>; Wed, 19 Jun 2002 09:03:33 -0700 (PDT)
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5JG72j03520
	for <ietf-openproxy@imc.org>; Wed, 19 Jun 2002 11:07:02 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5b94735f32ac12f257126@davir04nok.americas.nokia.com>;
 Wed, 19 Jun 2002 11:03:32 -0500
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Wed, 19 Jun 2002 11:03:31 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: draft-ietf-opes-protocol-reqs-01
Date: Wed, 19 Jun 2002 12:03:30 -0400
Message-ID: <DC504E9C3384054C8506D3E6BB0124600BACE9@bsebe001.NOE.Nokia.com>
Thread-Topic: draft-ietf-opes-protocol-reqs-01
Thread-Index: AcIXH9mkHDvRHGFPTe6IEb+QLpG51QAiH5NA
From: <bindignavile.srinivas@nokia.com>
To: <abeck@bell-labs.com>
Cc: <ietf-openproxy@imc.org>
X-OriginalArrivalTime: 19 Jun 2002 16:03:31.0277 (UTC) FILETIME=[DB690FD0:01C217AA]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g5JG3Xn21375
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


Hi,
I had a few questions/comments about the OPES Callout protocol draft which you submitted yesterday evening!

>  A callout transaction is defined as a message exchange between an
>  OPES processor and a callout server consisting of a callout request
>  and a callout response.  Both, the callout request as well as the
>  callout response, MAY each consist of one or more protocol messages,
>  i.e.  a series of protocol messages.

What did you mean when you referred to one or more "protocol" messages? Are you implying that multiple "OCP" messages can be packaged in each request or response? What is the justification for possibly packaging multiple protocol messages in a single callout request or response? Except if you feel that this might cause a great increase in overhead! If not, why not restrict each request and response to have only one protocol message (as is usually done in other request-response protocols).

>   Callout transactions are always initiated by a callout request from
>   an OPES processor and typically terminated by a callout response from
>   a callout server.  The OPES callout protocol MUST, however, also
>   allow either endpoint of a callout transaction to terminate a callout
>   transaction prematurely, i.e.  before a callout request or response
>   has been completely received by the corresponding endpoint. ...
>   
>   A premature termination of a callout transaction is required to
>   support OPES services which may terminate even before they have
>   processed the entire application message.  Content analysis services,
>   for example, may be able to classify a Web object after having
>   processed just the first few bytes of a Web object.

Why do you call this termination of the callout service "premature"? Isnt the fact that the content analysis task, for example, has outputted a result re. what the content is the expected result of the callout task and the normal completion of the same? So, I dont see why the example you have referred to is a case of premature termination of the callout transaction. Please clarify.

Regards,
-Srinivas
 
> -----Original Message-----
> From: ext Andre Beck [mailto:abeck@bell-labs.com]
> Sent: Tuesday, June 18, 2002 6:47 PM
> To: Internet-Drafts@ietf.org
> Cc: ietf-openproxy@imc.org; Marshall Rose; Markus Hofmann
> Subject: draft-ietf-opes-protocol-reqs-01
> 
> 
> Hi,
> 
> Please publish the attached OPES WG draft as
> "draft-ietf-opes-protocol-reqs-01".
> 
> 


From owner-ietf-openproxy@mail.imc.org  Wed Jun 19 14:42:21 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00536
	for <opes-archive@ietf.org>; Wed, 19 Jun 2002 14:42:20 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5JILCp27135
	for ietf-openproxy-bks; Wed, 19 Jun 2002 11:21:12 -0700 (PDT)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JILBn27130
	for <ietf-openproxy@imc.org>; Wed, 19 Jun 2002 11:21:11 -0700 (PDT)
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5JILei06205
	for <ietf-openproxy@imc.org>; Wed, 19 Jun 2002 21:21:40 +0300 (EET DST)
Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5b96a8d9b6ac158f24078@esvir04nok.ntc.nokia.com>;
 Wed, 19 Jun 2002 21:21:12 +0300
Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Wed, 19 Jun 2002 21:21:12 +0300
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Wed, 19 Jun 2002 13:21:09 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C217BE.150DBE10"
Subject: RE: Publish Draft: draft-ietf-opes-architecture-02
Date: Wed, 19 Jun 2002 14:21:08 -0400
Message-ID: <DC504E9C3384054C8506D3E6BB0124600BACEB@bsebe001.NOE.Nokia.com>
Thread-Topic: Publish Draft: draft-ietf-opes-architecture-02
Thread-Index: AcIXqx9NhTDqC9liROa/GAMJusdsgAAElgzQ
From: <bindignavile.srinivas@nokia.com>
To: <abbieb@nortelnetworks.com>
Cc: <ietf-openproxy@imc.org>, <markus@mhof.com>, <mrose@dbc.mtview.ca.us>
X-OriginalArrivalTime: 19 Jun 2002 18:21:09.0205 (UTC) FILETIME=[1584E050:01C217BE]
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This is a multi-part message in MIME format.

------_=_NextPart_001_01C217BE.150DBE10
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,
Just a small typo I believe! In the draft, just before Figure 3, there =
is a statement which reads:
=20
    For example, Figure 2 depicts a data flow (also known as an "OPES
   flow"), that spans two administrative domains.

Here, actually as seen in the draft, the reference should be to Figure 3 =
and not 2.
=20
-Srinivas

-----Original Message-----
From: ext Abbie Barbir [mailto:abbieb@nortelnetworks.com]
Sent: Wednesday, June 19, 2002 11:36 AM
To: internet-drafts@ietf.org
Cc: 'ietf-openproxy@imc.org'; 'Markus Hofmann'; 'Marshall Rose'; Abbie =
Barbir
Subject: Publish Draft: draft-ietf-opes-architecture-02



Please publish the attached as an Internet Draft=20

draft-ietf-opes-architecture-02=20

thanks=20

abbie=20

 =20


------_=_NextPart_001_01C217BE.150DBE10
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>Publish Draft: draft-ietf-opes-architecture-02</TITLE>

<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D108441618-19062002>Hi,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D108441618-19062002>Just a=20
small typo I believe! In the draft, just before Figure 3, there is a =
statement=20
which reads:</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D108441618-19062002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D108441618-19062002>&nbsp;&nbsp;&nbsp; For example, Figure 2 =
depicts a data=20
flow (also known as an "OPES<BR>&nbsp;&nbsp; flow"), that spans two=20
administrative domains.<BR></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D108441618-19062002>Here,=20
actually as seen in the draft, the reference should be&nbsp;to Figure 3 =
and not=20
2.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D108441618-19062002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D108441618-19062002>-Srinivas</DIV></SPAN></FONT>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> ext Abbie Barbir=20
  [mailto:abbieb@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, June 19, =
2002=20
  11:36 AM<BR><B>To:</B> internet-drafts@ietf.org<BR><B>Cc:</B>=20
  'ietf-openproxy@imc.org'; 'Markus Hofmann'; 'Marshall Rose'; Abbie=20
  Barbir<BR><B>Subject:</B> Publish Draft:=20
  draft-ietf-opes-architecture-02<BR><BR></DIV></FONT>
  <P><FONT size=3D2>Please publish the attached as an Internet =
Draft</FONT> </P>
  <P><FONT size=3D2>draft-ietf-opes-architecture-02</FONT> </P>
  <P><FONT size=3D2>thanks</FONT> </P>
  <P><FONT size=3D2>abbie</FONT> </P>
  <P><FONT color=3D#000000 face=3DArial size=3D2></FONT>&nbsp;=20
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C217BE.150DBE10--


From owner-ietf-openproxy@mail.imc.org  Wed Jun 19 14:44:43 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00578
	for <opes-archive@ietf.org>; Wed, 19 Jun 2002 14:44:43 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5JIKGr27114
	for ietf-openproxy-bks; Wed, 19 Jun 2002 11:20:16 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JIKFn27110
	for <ietf-openproxy@imc.org>; Wed, 19 Jun 2002 11:20:15 -0700 (PDT)
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.2/8.12.2) with ESMTP id g5JIK76R044036;
	Wed, 19 Jun 2002 14:20:07 -0400 (EDT)
Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8])
	by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g5JIKBk05586;
	Wed, 19 Jun 2002 14:20:11 -0400 (EDT)
Received: from bell-labs.com (abeck.lra.lucent.com [192.11.62.53])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA15532;
	Wed, 19 Jun 2002 14:20:10 -0400 (EDT)
Message-ID: <3D10CB5A.2000102@bell-labs.com>
Date: Wed, 19 Jun 2002 13:20:10 -0500
From: Andre Beck <abeck@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: bindignavile.srinivas@nokia.com
CC: ietf-openproxy@imc.org
Subject: Re: draft-ietf-opes-protocol-reqs-01
References: <DC504E9C3384054C8506D3E6BB0124600BACE9@bsebe001.NOE.Nokia.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: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


Hi Srinivas,

Thanks for your comments.

bindignavile.srinivas@nokia.com wrote:
  >> A callout transaction is defined as a message exchange between an
  >> OPES processor and a callout server consisting of a callout request
  >>  and a callout response.  Both, the callout request as well as the
  >> callout response, MAY each consist of one or more protocol
  >> messages, i.e.  a series of protocol messages.
  >
  > What did you mean when you referred to one or more "protocol"
  > messages? Are you implying that multiple "OCP" messages can be
  > packaged in each request or response? What is the justification for
  > possibly packaging multiple protocol messages in a single callout
  > request or response? Except if you feel that this might cause a great
  > increase in overhead! If not, why not restrict each request and
  > response to have only one protocol message (as is usually done in
  > other request-response protocols).

Section 3.13 of the draft talks about the need for application message
segmentation, i.e. an OPES processor may have to forward an application
message to a callout server in a series of fragments. If this is the
case, then the OCP may choose to encapsulate application message
fragments into separate OCP messages (which would all be part of the
same OCP request). The same applies to OCP responses. So I don't think
we should restrict each OCP request and response to only one OCP message.

  >> Callout transactions are always initiated by a callout request from
  >>  an OPES processor and typically terminated by a callout response
  >> from a callout server.  The OPES callout protocol MUST, however,
  >> also allow either endpoint of a callout transaction to terminate a
  >> callout transaction prematurely, i.e.  before a callout request or
  >> response has been completely received by the corresponding
  >> endpoint. ...
  >>
  >> A premature termination of a callout transaction is required to
  >> support OPES services which may terminate even before they have
  >> processed the entire application message.  Content analysis
  >> services, for example, may be able to classify a Web object after
  >> having processed just the first few bytes of a Web object.
  >
  >
  > Why do you call this termination of the callout service "premature"?
  > Isnt the fact that the content analysis task, for example, has
  > outputted a result re. what the content is the expected result of the
  > callout task and the normal completion of the same? So, I dont see
  > why the example you have referred to is a case of premature
  > termination of the callout transaction. Please clarify.

I see your point, but we did not mean to imply that a "premature
termination" represents an error condition of any kind. It's simply
something that occurs when an OPES processor terminates a callout
transaction before the completion of a callout request. This usually
happens when an OPES service terminates before the entire OCP request
was sent. As you pointed out, this may be the normal operation of the
OPES service. If the term "premature termination" is confusing, then
maybe we should call it something else. Any suggestions?

Thanks,
Andre





From owner-ietf-openproxy@mail.imc.org  Wed Jun 19 15:03:24 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01090
	for <opes-archive@ietf.org>; Wed, 19 Jun 2002 15:03:24 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5JIhIX29032
	for ietf-openproxy-bks; Wed, 19 Jun 2002 11:43:18 -0700 (PDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5JIhHn29025
	for <ietf-openproxy@imc.org>; Wed, 19 Jun 2002 11:43:17 -0700 (PDT)
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5JIklj26395
	for <ietf-openproxy@imc.org>; Wed, 19 Jun 2002 13:46:47 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5b95059c9aac12f257126@davir04nok.americas.nokia.com> for <ietf-openproxy@imc.org>;
 Wed, 19 Jun 2002 13:43:16 -0500
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Wed, 19 Jun 2002 13:42:57 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: draft-ietf-opes-protocol-reqs-01
Date: Wed, 19 Jun 2002 14:42:56 -0400
Message-ID: <DC504E9C3384054C8506D3E6BB0124609DCB0B@bsebe001.NOE.Nokia.com>
Thread-Topic: draft-ietf-opes-protocol-reqs-01
Thread-Index: AcIXvgVX+XwDOXpvQMKogknYZ10DPwAAFtdAAACiVIA=
From: <bindignavile.srinivas@nokia.com>
To: <ietf-openproxy@imc.org>
X-OriginalArrivalTime: 19 Jun 2002 18:42:57.0354 (UTC) FILETIME=[213C92A0:01C217C1]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g5JIhHn29028
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


Hi,
I forgot to CC the list in my response! Here it is.

Thanks,
-Srinivas

-----Original Message-----
From: Srinivas Bindignavile (NRC/Boston) 
Sent: Wednesday, June 19, 2002 2:41 PM
To: 'ext Andre Beck'
Subject: RE: draft-ietf-opes-protocol-reqs-01


Hi Andre,
Thanks for your responses to my comments!

> Hi Srinivas,
> 
> Thanks for your comments.
> 
> bindignavile.srinivas@nokia.com wrote:
>   >> A callout transaction is defined as a message exchange between an
>   >> OPES processor and a callout server consisting of a 
> callout request
>   >>  and a callout response.  Both, the callout request as 
> well as the
>   >> callout response, MAY each consist of one or more protocol
>   >> messages, i.e.  a series of protocol messages.
>   >
>   > What did you mean when you referred to one or more "protocol"
>   > messages? Are you implying that multiple "OCP" messages can be
>   > packaged in each request or response? What is the 
> justification for
>   > possibly packaging multiple protocol messages in a single callout
>   > request or response? Except if you feel that this might 
> cause a great
>   > increase in overhead! If not, why not restrict each request and
>   > response to have only one protocol message (as is usually done in
>   > other request-response protocols).
> 
> Section 3.13 of the draft talks about the need for application message
> segmentation, i.e. an OPES processor may have to forward an 
> application
> message to a callout server in a series of fragments. If this is the
> case, then the OCP may choose to encapsulate application message
> fragments into separate OCP messages (which would all be part of the
> same OCP request). The same applies to OCP responses. So I don't think
> we should restrict each OCP request and response to only one 
> OCP message.

I see your point here! However, I think that you might want to reword this statement to indicate that, if the original application message is not too large (meaning not segmented), then each application message SHOULD be sent in a separate OCP message rather than sending multiple application messages in the same OCP message (possibly to reduce overhead).
 
>   > Why do you call this termination of the callout service 
> "premature"?
>   > Isnt the fact that the content analysis task, for example, has
>   > outputted a result re. what the content is the expected 
> result of the
>   > callout task and the normal completion of the same? So, I dont see
>   > why the example you have referred to is a case of premature
>   > termination of the callout transaction. Please clarify.
> 
> I see your point, but we did not mean to imply that a "premature
> termination" represents an error condition of any kind. It's simply
> something that occurs when an OPES processor terminates a callout
> transaction before the completion of a callout request. This usually
> happens when an OPES service terminates before the entire OCP request
> was sent. As you pointed out, this may be the normal operation of the
> OPES service. If the term "premature termination" is confusing, then
> maybe we should call it something else. Any suggestions?

Could we call it "service completion" instead? After all, for the example of Content Analysis, the successful determination of the content type (of the data stream) does represent the completion of the required service.

Thanks,
-Srinivas


From owner-ietf-openproxy@mail.imc.org  Thu Jun 20 07:26:37 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25187
	for <opes-archive@ietf.org>; Thu, 20 Jun 2002 07:26:37 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5KB1Fk28897
	for ietf-openproxy-bks; Thu, 20 Jun 2002 04:01:15 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KB1En28893
	for <ietf-openproxy@imc.org>; Thu, 20 Jun 2002 04:01:14 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24367;
	Thu, 20 Jun 2002 07:00:34 -0400 (EDT)
Message-Id: <200206201100.HAA24367@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-architecture-02.txt
Date: Thu, 20 Jun 2002 07:00:33 -0400
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


--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		: An Architecture for Open Pluggable Edge Services 
                          (OPES)
	Author(s)	: A. Barbir et al.
	Filename	: draft-ietf-opes-architecture-02.txt
	Pages		: 19
	Date		: 19-Jun-02
	
This memo defines an architecture for a cooperative application
service in which a data provider, a data consumer, and zero or more
application entities cooperatively realize a data stream service.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-opes-architecture-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-architecture-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-architecture-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:	<20020619122949.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-opes-architecture-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-opes-architecture-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020619122949.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-ietf-openproxy@mail.imc.org  Thu Jun 20 07:28:06 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25264
	for <opes-archive@ietf.org>; Thu, 20 Jun 2002 07:28:06 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5KB1KM28903
	for ietf-openproxy-bks; Thu, 20 Jun 2002 04:01:20 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KB1Jn28899
	for <ietf-openproxy@imc.org>; Thu, 20 Jun 2002 04:01:19 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24385;
	Thu, 20 Jun 2002 07:00:39 -0400 (EDT)
Message-Id: <200206201100.HAA24385@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-protocol-reqs-01.txt
Date: Thu, 20 Jun 2002 07:00:38 -0400
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


--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		: Requirements for OPES Callout Protocols
	Author(s)	: A. Beck et al.
	Filename	: draft-ietf-opes-protocol-reqs-01.txt
	Pages		: 19
	Date		: 19-Jun-02
	
This document specifies the requirements that the OPES (Open
Pluggable Edge Services) callout protocol must satisfy in order to
support the remote execution of OPES services [1].  The requirements
are intended to help evaluating possible protocol candidates and to
guide the development of such protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-reqs-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-opes-protocol-reqs-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-opes-protocol-reqs-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020619123001.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-opes-protocol-reqs-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-opes-protocol-reqs-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020619123001.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-ietf-openproxy@mail.imc.org  Thu Jun 20 19:41:07 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15525
	for <opes-archive@ietf.org>; Thu, 20 Jun 2002 19:41:07 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g5KNIWt06298
	for ietf-openproxy-bks; Thu, 20 Jun 2002 16:18:32 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5KNIVn06294
	for <ietf-openproxy@imc.org>; Thu, 20 Jun 2002 16:18:32 -0700 (PDT)
Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9])
	by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g5KNIL6R059983;
	Thu, 20 Jun 2002 19:18:22 -0400 (EDT)
Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8])
	by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g5KNISo96451;
	Thu, 20 Jun 2002 19:18:28 -0400 (EDT)
Received: from bell-labs.com ([135.5.126.183])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id TAA06479;
	Thu, 20 Jun 2002 19:18:27 -0400 (EDT)
Message-ID: <3D12621B.9090707@bell-labs.com>
Date: Thu, 20 Jun 2002 18:15:39 -0500
From: Andre Beck <abeck@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-US
MIME-Version: 1.0
To: bindignavile.srinivas@nokia.com
CC: "ietf-openproxy@imc.org" <ietf-openproxy@imc.org>
Subject: Re: draft-ietf-opes-protocol-reqs-01
References: <DC504E9C3384054C8506D3E6BB0124609DCB0B@bsebe001.NOE.Nokia.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: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


Hello Srinivas,

bindignavile.srinivas@nokia.com wrote:
 >> Section 3.13 of the draft talks about the need for application
 >> message segmentation, i.e. an OPES processor may have to forward an
 >>  application message to a callout server in a series of fragments.
 >> If this is the case, then the OCP may choose to encapsulate
 >> application message fragments into separate OCP messages (which
 >> would all be part of the same OCP request). The same applies to OCP
 >> responses. So I don't think we should restrict each OCP request and
 >> response to only one OCP message.
 >
 >
 > I see your point here! However, I think that you might want to reword
 > this statement to indicate that, if the original application message
 > is not too large (meaning not segmented), then each application
 > message SHOULD be sent in a separate OCP message rather than sending
 > multiple application messages in the same OCP message (possibly to
 > reduce overhead).

IMO each callout request and response (which may each consist of 
multiple OCP messages) should only contain a single application message, 
but I am not sure that this is what you meant. What are your concerns 
for sending multiple application messages within the same OCP message?

 >> I see your point, but we did not mean to imply that a "premature
 >> termination" represents an error condition of any kind. It's simply
 >>  something that occurs when an OPES processor terminates a callout
 >> transaction before the completion of a callout request. This
 >> usually happens when an OPES service terminates before the entire
 >> OCP request was sent. As you pointed out, this may be the normal
 >> operation of the OPES service. If the term "premature termination"
 >> is confusing, then maybe we should call it something else. Any
 >> suggestions?
 >
 > Could we call it "service completion" instead? After all, for the
 > example of Content Analysis, the successful determination of the
 > content type (of the data stream) does represent the completion of
 > the required service.

Right, "Service Completion" is a good description of an event that could 
trigger a "premature termination" of a callout transaction. I'll 
rephrase the corresponding section in the draft to reflect this and give 
a better description of the termination process.

Thanks,
Andre




From owner-ietf-openproxy@mail.imc.org  Fri Jun 21 10:04:17 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13408
	for <opes-archive@ietf.org>; Fri, 21 Jun 2002 10:04:17 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5LDZ6N27619
	for ietf-openproxy-bks; Fri, 21 Jun 2002 06:35:06 -0700 (PDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LDZ1n27615
	for <ietf-openproxy@imc.org>; Fri, 21 Jun 2002 06:35:01 -0700 (PDT)
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5LDZVx01218
	for <ietf-openproxy@imc.org>; Fri, 21 Jun 2002 08:35:31 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5b9e381fcdac12f25412a@davir01nok.americas.nokia.com>;
 Fri, 21 Jun 2002 08:35:02 -0500
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Fri, 21 Jun 2002 08:35:02 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: draft-ietf-opes-protocol-reqs-01
Date: Fri, 21 Jun 2002 09:35:00 -0400
Message-ID: <DC504E9C3384054C8506D3E6BB0124600BACED@bsebe001.NOE.Nokia.com>
Thread-Topic: draft-ietf-opes-protocol-reqs-01
Thread-Index: AcIYsNQy4P97yRraQn+prN33Y4hgwQAdeNBw
From: <bindignavile.srinivas@nokia.com>
To: <abeck@bell-labs.com>
Cc: <ietf-openproxy@imc.org>
X-OriginalArrivalTime: 21 Jun 2002 13:35:02.0271 (UTC) FILETIME=[720E20F0:01C21928]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g5LDZ5n27616
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


Hi Andre,

> IMO each callout request and response (which may each consist of 
> multiple OCP messages) should only contain a single 
> application message, 
> but I am not sure that this is what you meant. What are your concerns 
> for sending multiple application messages within the same OCP message?

My only concern with sending multiple application messages in the same OCP message is that, by holding up the first application message at the OPES intermediary end waiting to fill up the OCP message before sending the OCP message to the callout server, arent we unnecessarily increasing the latency for the application message. By sending only 1 application message in each OCP message, the latency is reduced at the cost of a greater overhead.

> Right, "Service Completion" is a good description of an event 
> that could 
> trigger a "premature termination" of a callout transaction. I'll 
> rephrase the corresponding section in the draft to reflect 
> this and give 
> a better description of the termination process.

That sounds great!

Thanks,
-Srini


From owner-ietf-openproxy@mail.imc.org  Fri Jun 21 12:38:36 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21349
	for <opes-archive@ietf.org>; Fri, 21 Jun 2002 12:38:36 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5LGEo206312
	for ietf-openproxy-bks; Fri, 21 Jun 2002 09:14:50 -0700 (PDT)
Received: from hermes.webwasher.com (mail.webwasher.com [195.162.240.3])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LGEmn06306
	for <ietf-openproxy@imc.org>; Fri, 21 Jun 2002 09:14:48 -0700 (PDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C2193E.5E897F32"
Subject: draft-stecher-opes-icap-eval-00
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Fri, 21 Jun 2002 18:11:58 +0200
Message-ID: <72992B39BBD9294BB636A960E89AE02E4CA96F@hermes.webwasher.com>
X-MS-Has-Attach: yes
Thread-Topic: draft-stecher-opes-icap-eval-00
Thread-Index: AcIZPo0E7prS1mTtRTOM0V7q0SDWEw==
From: "Martin Stecher" <martin.stecher@webwasher.com>
To: <internet-drafts@ietf.org>
Cc: "OPES WG (E-mail)" <ietf-openproxy@imc.org>,
        "Marshall Rose" <mrose@dbc.mtview.ca.us>,
        "Markus Hofmann" <hofmann@bell-labs.com>
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This is a multi-part message in MIME format.

------_=_NextPart_001_01C2193E.5E897F32
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

please publish the attached document as an Internet Draft

draft-stecher-opes-icap-eval-00


Thank you.

Regards
Martin Stecher

------_=_NextPart_001_01C2193E.5E897F32
Content-Type: text/plain;
	name="draft-stecher-opes-icap-eval-00.txt"
Content-Description: draft-stecher-opes-icap-eval-00.txt
Content-Disposition: attachment;
	filename="draft-stecher-opes-icap-eval-00.txt"
Content-Transfer-Encoding: base64

CgoKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBNLiBTdGVjaGVyCkV4cGlyZXM6IERlY2VtYmVyLCAyMDAyICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgd2Vid2FzaGVyLmNvbQogICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmUsIDIwMDIKCgoKICAg
ICAgICAgICAgIEV2YWx1YXRpbmcgdGhlIElDQVAgcHJvdG9jb2wgcmVnYXJkaW5nIHRoZQogICAg
ICAgICAgICAgICAgT1BFUyBjYWxsb3V0IHByb3RvY29sIHJlcXVpcmVtZW50cwogICAgICAgICAg
ICAgICAgZHJhZnQtc3RlY2hlci1vcGVzLWljYXAtZXZhbC0wMC50eHQKCgoKICAgICAgICAgICAg
ICAgICAKU3RhdHVzIG9mIHRoaXMgTWVtbwoKICAgVGhpcyBkb2N1bWVudCBpcyBhbiBJbnRlcm5l
dC1EcmFmdCBhbmQgaXMgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoCiAgIGFsbCBwcm92aXNpb25z
IG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2lu
ZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElF
VEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQKICAgb3Ro
ZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJu
ZXQtCiAgIERyYWZ0cy4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZh
bGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJl
cGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAg
SXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQog
ICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVz
cy4iCgogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNz
ZWQgYXQgaHR0cDovLwogICB3d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4KCiAg
IFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNj
ZXNzZWQgYXQKICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4KCiAgIFRoaXMgSW50
ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgaW4gRGVjZW1iZXIsIDIwMDIuCgoKQ29weXJpZ2h0IE5v
dGljZQoKICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwMikuICBBbGwg
UmlnaHRzIFJlc2VydmVkLgoKCkFic3RyYWN0CgogICBUaGlzIGRvY3VtZW50IHVzZXMgdGhlIHJl
cXVpcmVtZW50cyBmb3IgT1BFUyBjYWxsb3V0IHByb3RvY29scyBbMV0KICAgYW5kIGV2YWx1YXRl
cyB3aGV0aGVyIHRoZXkgYXJlIGZ1bGZpbGxlZCBieSB0aGUgSUNBUCBwcm90b2NvbCBbMl0uCiAg
IAoKCgoKClN0ZWNoZXIgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIsIDIwMDIg
ICAgICAgICAgICAgICBbUGFnZSAxXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICBFdmFsdWF0
aW5nIHRoZSBJQ0FQIHByb3RvY29sICAgICAgICAgIEp1bmUgMjAwMgoKClRhYmxlIG9mIENvbnRl
bnRzCgogICAxLiAgIFRlcm1pbm9sb2d5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAgIDMKICAgMi4gICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzCiAgIDMuICAgRnVuY3Rpb25hbCBS
ZXF1aXJlbWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMwogICAz
LjEgIENhbGxvdXQgVHJhbnNhY3Rpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAgIDMKICAgMy4yICBDYWxsb3V0IENoYW5uZWxzIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzCiAgIDMuMyAgUmVsaWFiaWxpdHkgIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNAogICAzLjQgIENvbmdl
c3Rpb24gYW5kIEZsb3cgQ29udHJvbCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg
IDQKICAgMy41ICBTdXBwb3J0IGZvciBLZWVwLUFsaXZlIE1lY2hhbmlzbSAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gICA0CiAgIDMuNiAgT3BlcmF0aW9uIGluIE5BVCBFbnZpcm9ubWVudHMg
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNAogICAzLjcgIE11bHRpcGxlIENhbGxv
dXQgU2VydmVycyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQKICAgMy44
ICBNdWx0aXBsZSBPUEVTIFByb2Nlc3NvcnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gICA1CiAgIDMuOSAgU3VwcG9ydCBmb3IgRGlmZmVyZW50IEFwcGxpY2F0aW9uIFByb3Rv
Y29scyAgLiAuIC4gLiAuIC4gLiAuICAgNQogICAzLjEwIENhcGFiaWxpdHkgYW5kIFBhcmFtZXRl
ciBOZWdvdGlhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUKICAgMy4xMSBNZXRhIERh
dGEgYW5kIEluc3RydWN0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA1
CiAgIDMuMTIgQXN5bmNocm9ub3VzIE1lc3NhZ2UgRXhjaGFuZ2UgIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuICAgNQogICAzLjEzIE1lc3NhZ2UgU2VnbWVudGF0aW9uIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDYKICAgNC4gICBQZXJmb3JtYW5jZSBSZXF1
aXJlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA2CiAgIDQuMSAg
UHJvdG9jb2wgRWZmaWNpZW5jeSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuICAgNgogICA1LiAgIFNlY3VyaXR5IFJlcXVpcmVtZW50cyAgLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAgIDYKICAgNS4xICBBdXRoZW50aWNhdGlvbiwgQ29uZmlkZW50
aWFsaXR5LCBhbmQgSW50ZWdyaXR5IC4gLiAuIC4gLiAuIC4gICA2CiAgIDUuMiAgSG9wLWJ5LUhv
cCBDb25maWRlbnRpYWxpdHkgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNgog
ICA1LjMgIE9wZXJhdGlvbiBBY3Jvc3MgVW4tdHJ1c3RlZCBEb21haW5zICAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAgIDcKICAgNS40ICBQcml2YWN5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA3CiAgIDYuICAgU3VtbWFyeSAgLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNwogICA3LiAgIFNl
Y3VyaXR5IENvbnNpZGVyYXRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAgIDcKICAgICAgICBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gICA3CiAgICAgICAgQXV0aG9ycycgQWRkcmVzc2VzIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNwogICAgICAgIEZ1bGwgQ29weXJp
Z2h0IFN0YXRlbWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDgKCgoK
CgoKCgoKCgoKCgoKCgoKCgoKU3RlY2hlciAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBEZWNl
bWJlciwgMjAwMiAgICAgICAgICAgICAgIFtQYWdlIDJdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg
ICAgIEV2YWx1YXRpbmcgdGhlIElDQVAgcHJvdG9jb2wgICAgICAgICAgSnVuZSAyMDAyCgoKMS4g
VGVybWlub2xvZ3kKCiAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlS
RUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwKICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJF
Q09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMKICAgZG9jdW1lbnQgYXJl
IHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBSRkMgMjExOSBbM10uCgoyLiBJbnRy
b2R1Y3Rpb24KCiAgIFRoZSBJbnRlcm5ldCBDb250ZW50IEFkYXB0aW9uIFByb3RvY29sIChJQ0FQ
KSBpbiBpdHMgdmVyc2lvbiAxLjAgaGFzCiAgIGJlZW4gZGVzY3JpYmVkIGluIGFuIEludGVybmV0
IGRyYWZ0IHRoYXQgd2FzIHBvc3RlZCBvbmUgeWVhciBhZ28gYW5kCiAgIHdhcyB1cGRhdGVkIHJl
Y2VudGx5IFsyXS4KICAgCiAgIFRoZSBPUEVTIChPcGVuIFBsdWdnYWJsZSBFZGdlIFNlcnZpY2Vz
KSB3b3JraW5nIGdyb3VwIGRlZmluZWQgdGhlCiAgIHJlcXVpcmVtZW50cyBmb3IgT1BFUyBjYWxs
b3V0IHByb3RvY29scyBpbiB0aGUgSW50ZXJuZXQgZHJhZnQgWzFdLgogICAKICAgVGhpcyBkb2N1
bWVudCBjaGVja3MgZm9yIHRoZSByZXF1aXJlbWVudHMgb2YgWzFdIGFuZCBldmFsdWF0ZXMKICAg
d2hldGhlciB0aGV5IGFyZSBmdWxmaWxsZWQgYnkgdGhlIElDQVAgcHJvdG9jb2wgWzJdLgogICAK
ICAgU2VjdGlvbnMgMywgNCwgNSBhbmQgNiBvZiB0aGlzIGRvY3VtZW50IGFyZSBzeW5jaHJvbml6
ZWQgd2l0aCB0aGUKICAgc2FtZSBzZWN0aW9ucyBvZiBbMV0gZm9yIGEgY29udmVuaWVudCBsb29r
dXAgb2YgdGhlIHJlZmVycmVkCiAgIHJlcXVpcmVtZW50cy4KCjMuIEZ1bmN0aW9uYWwgUmVxdWly
ZW1lbnRzCgozLjEgQ2FsbG91dCBUcmFuc2FjdGlvbnMKCiAgIGZ1bGZpbGxlZAogICAKICAgRW5h
Ymxpbmcgb2YgY2FsbG91dCB0cmFuc2FjdGlvbnM6ICBmdWxmaWxsZWQKICAgRm9yd2FyZCBjb21w
bGV0ZSBvciBwYXJ0aWFsIGFwcCBtZXNzYWdlOiBmdWxmaWxsZWQKICAgQWJpbGl0eSB0byByZXR1
cm4gYSBtb2RpZmllZCBhcHAgbWVzc2FnZTogZnVsZmlsbGVkCgogICBSZXF1ZXN0L1Jlc3BvbnNl
IHNjaGVtZTogRGVmaW5lZCwgdHdvIG1haW4gbWV0aG9kcyBSRVFNT0QvUkVTUE1PRAoKICAgVGVy
bWluYXRpbmcgdHJhbnNhY3Rpb25zOiBmdWxmaWxsZWQgKGNhbiBiZSBkb25lIGFzIGluIEhUVFAp
CgogICBQcmVtYXR1cmUgdGVybWluYXRpb24gb2YgdHJhbnNhY3Rpb246IFBvc3NpYmxlLiBJQ0FQ
IHNlcnZlciBjYW4KICAgcmVzcG9uZCBhbmQgY2xvc2UgY29ubmVjdGlvbiAoZ3JhY2VmdWwgc2h1
dGRvd24pIHcvbyBoYW5kbGluZwogICBhbGwgZGF0YS4KICAgCiAgIFN0YXR1cyBDb2RlOiBmdWxm
aWxsZWQgKGZpcnN0IGxpbmUgb2YgcmVzcG9uc2UgY29udGFpbnMgc3RhdHVzIGNvZGUpCgozLjIg
Q2FsbG91dCBDaGFubmVscwoKICAgZnVsZmlsbGVkCiAgIAogICBNdWx0aXBsZSB0cmFuc2FjdGlv
bnM6IGZ1bGZpbGxlZCAoSUNBUCBjb25uZWN0aW9ucyBhcmUgcGVyc2lzdGVudAogICBieSBkZWZh
dWx0IGFzIGluIEhUVFAvMS4xKQoKCgpTdGVjaGVyICAgICAgICAgICAgICAgICAgICBFeHBpcmVz
IERlY2VtYmVyLCAyMDAyICAgICAgICAgICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFmdCAg
ICAgICAgICAgRXZhbHVhdGluZyB0aGUgSUNBUCBwcm90b2NvbCAgICAgICAgICBKdW5lIDIwMDIK
CgogICBDb25uZWN0IGFuZCBjbG9zZTogZnVsZmlsbGVkIChvbmx5IElDQVAgY2xpZW50IGNvbm5l
Y3RzIHRvIElDQVAKICAgc2VydmVyLCBib3RoIHNpZGVzIGNhbiBjbG9zZSBhIGNvbm5lY3Rpb24p
CgogICBQYXJhbWV0ZXJzOiBQYXJhbWV0ZXJzIGFyZSBuZWdvdGlhdGVkIHdpdGggc3BlY2lhbCBP
UFRJT05TIHJlcXVlc3RzCgozLjMgUmVsaWFiaWxpdHkKCiAgIGZ1bGZpbGxlZAogICAKICAgIklD
QVAgdXNlcyBUQ1AvSVAgYXMgYSB0cmFuc3BvcnQgcHJvdG9jb2wiICg0LjEuIG9mIFsyXSkKCjMu
NCBDb25nZXN0aW9uIGFuZCBGbG93IENvbnRyb2wKCiAgIGZ1bGZpbGxlZAoKICAgIklDQVAgdXNl
cyBUQ1AvSVAgYXMgYSB0cmFuc3BvcnQgcHJvdG9jb2wiICg0LjEuIG9mIFsyXSkKCjMuNSBTdXBw
b3J0IGZvciBLZWVwLUFsaXZlIE1lY2hhbmlzbQoKICAgaW5jb21wbGV0ZQogICAKICAgVGhlcmUg
YXJlIG5vIGtlZXAgYWxpdmUgbWVzc2FnZXMgaW4gdGhlIElDQVAgcHJvdG9jb2wuCgogICBBbHRo
b3VnaCBJQ0FQIHN1cHBvcnRzIHBlcnNpc3RlbnQgY29ubmVjdGlvbnMsIGEgbm9ybWFsIGNvbm5l
Y3Rpb24KICAgaXRzZWxmIGlzIG5vdCBhbiBvcHRpbWFsIG1ldGhvZCBvZiBkZXRlY3RpbmcgZmFp
bHVyZXMuIEFzIGluIEhUVFAKICAgb3BlbiBjb25uZWN0aW9ucyBtYXkgdGltZSBvdXQgYW5kIHdp
bGwgYmUgY2xvc2VkIHRvIHJlbGVhc2UKICAgcmVzb3VyY2VzIGlmIG5vIHRyYW5zYWN0aW9ucyBo
YXZlIHRvIGJlIGhhbmRsZWQgZm9yIHNvbWUgdGltZS4KICAgCiAgIEFuIElDQVAgY2xpZW50IG5l
ZWRzIHRvIGltcGxlbWVudCBzb21lIHN0cmF0ZWd5IHRvIGF2b2lkIGRhdGEgbG9zcwogICBpZiBh
IGNvbm5lY3Rpb24gaXMgdGltZWQgb3V0IGJ5IHRoZSBJQ0FQIHNlcnZlciBhcyB0aGUgY2xpZW50
CiAgIGlzIHNlbmRpbmcgYSBuZXcgcmVxdWVzdC4KCjMuNiBPcGVyYXRpb24gaW4gTkFUIEVudmly
b25tZW50cwoKICAgZnVsZmlsbGVkCgogICAoTm90IGZyZXF1ZW50bHkgaW1wbGVtZW50ZWQgYnV0
IHdlIG9uY2UgZW5jb3VudGVyZWQgYW4gSUNBUCBzZXJ2ZXIKICAgYmVoaW5kIGEgZmlyZXdhbGwg
cnVubmluZyBOQVQuKQoKMy43IE11bHRpcGxlIENhbGxvdXQgU2VydmVycwoKICAgZnVsZmlsbGVk
CgogICAoVGhlcmUgaXMgbm90aGluZyBleHBsaWNpdGx5IGluIHRoZSBzcGVjcyBidXQgaXQgd29y
a3MgdGhlIHNhbWUKICAgd2F5IGFzIGEgZGF0YSBwcm9jZXNzb3IgY29tbXVuaWNhdGVzIHdpdGgg
ZGlmZmVyZW50IEhUVFAgc2VydmVycykuCgoKCgoKClN0ZWNoZXIgICAgICAgICAgICAgICAgICAg
IEV4cGlyZXMgRGVjZW1iZXIsIDIwMDIgICAgICAgICAgICAgICBbUGFnZSA0XQoMCkludGVybmV0
LURyYWZ0ICAgICAgICAgICBFdmFsdWF0aW5nIHRoZSBJQ0FQIHByb3RvY29sICAgICAgICAgIEp1
bmUgMjAwMgoKCjMuOCBNdWx0aXBsZSBEYXRhIFByb2Nlc3NvcnMKCiAgIGZ1bGZpbGxlZAoKICAg
KEFzIGluIEhUVFAsIGFuIElDQVAgc2VydmVyIGNhbiBiZSBjb250YWN0ZWQgYnkgYW55IG51bWJl
ciBvZgogICBjbGllbnRzLiBNdWx0aXBsZSBzZXJ2aWNlcyBvbiBvbmUgc2VydmVyIGFyZSBhbHNv
IHBsYW5uZWQpCgoKMy45IFN1cHBvcnQgZm9yIERpZmZlcmVudCBBcHBsaWNhdGlvbiBQcm90b2Nv
bHMKCiAgIGluY29tcGxldGUKCiAgIElDQVAgaXMgZGVzaWduZWQgZm9yIEhUVFAgb25seS4KICAg
IlRob3VnaCB0cmFuc2Zvcm1hdGlvbnMgbWF5IGJlIHBvc3NpYmxlIG9uIG90aGVyIG5vbi1IVFRQ
IGNvbnRlbnQsCiAgIHRoZXkgYXJlIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4i
IChjaGFwdGVyIDEgb2YgWzJdKS4KICAgVGhlcmUgYXJlIGltcGxlbWVudGF0aW9ucyB0aGF0IHVz
ZSBJQ0FQIGZvciBvdGhlciBwcm90b2NvbHMgbGlrZQogICBGVFAgYW5kIFNNVFAuCiAgIAozLjEw
IENhcGFiaWxpdHkgYW5kIFBhcmFtZXRlciBOZWdvdGlhdGlvbnMKCiAgIGZ1bGZpbGxlZAoKICAg
KEEgYmFzaWMgZm9ybSBvZiB0aGVzZSBuZWdvdGlhdGlvbnMgaXMgaW1wbGVtZW50ZWQgYnkgdGhl
IElDQVAKICAgT1RQSU9OUyByZXF1ZXN0L3Jlc3BvbnNlLiAoNC4xMCBvZiBbMl0pKQoKMy4xMSBN
ZXRhIERhdGEgYW5kIEluc3RydWN0aW9ucwoKICAgZnVsZmlsbGVkCiAgIAogICBNZXRhIGRhdGEg
Y2FuIGJlIHRyYW5zZmVycmVkIGluIElDQVAgbWVzc2FnZSBoZWFkZXJzICg0LjMgb2YgWzJdKS4K
ICAgCiAgIEluZm9ybWF0aW9uIGFib3V0IHRoZSBwYXJ0cyBvZiB0aGUgYXBwbGljYXRpb24gbWVz
c2FnZSB0aHJvdWdoCiAgIEVuY2Fwc3VsYXRpb24gaGVhZGVyICg0LjQuMSBvZiBbMl0pLgogICAK
ICAgU2VydmljZSBpcyBzcGVjaWZpZWQgdGhyb3VnaCBJQ0FQIFVSSSAoNC4yIG9mIFsyXSkKICAg
CiAgIENhY2hlLUNvbnRyb2wgaGVhZGVyIGZvciBjYWNoZWFiaWxpdHkgKDQuMy4xIG9mIFsyXSku
CiAgIAogICBLZWVwaW5nIG9mIGxvY2FsIGNvcHkgc2lnbmFsZWQgYnkgIkFsbG93OiAyMDQiIGhl
YWRlciAoNC42IG9mIFsyXSkKICAgCiAgIFRyYWNpbmcgdGhyb3VnaCB2aWEgaGVhZGVycyAoNC40
LjIgb2YgWzJdKS4KCjMuMTIgQXN5bmNocm9ub3VzIE1lc3NhZ2UgRXhjaGFuZ2UKCiAgIGZ1bGZp
bGxlZAogICAKICAgTWFueSBUQ1AgY29ubmVjdGlvbnMgcG9zc2libGUsIGFzIHdlbGwgYXMgcGFy
YWxsZWwgcmVxdWVzdHMgb24KICAgcGFyYWxsZWwgY29ubmVjdGlvbnMuCgoKClN0ZWNoZXIgICAg
ICAgICAgICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIsIDIwMDIgICAgICAgICAgICAgICBbUGFn
ZSA1XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICBFdmFsdWF0aW5nIHRoZSBJQ0FQIHByb3Rv
Y29sICAgICAgICAgIEp1bmUgMjAwMgoKCiAgIFByZXZpZXcgZmVhdHVyZSB0byBnZXQgYW4gYWRk
aXRpb25hbCBkZWNpc2lvbiBwb2ludCAoNC41IG9mIFsyXSkKICAgQXN5bmNocm9ub3VzIGRhdGEg
aGFuZGxpbmcgb2YgSUNBUCB0cmFmZmljIGlzIG5vdCBhIE1VU1QgYnV0CiAgIGEgU0hPVUxELiBU
aGlzIGluZm9ybWF0aW9uIGlzIG1pc3NpbmcgaW4gdGhlIGN1cnJlbnQgSUNBUCBkcmFmdC4KCjMu
MTMgTWVzc2FnZSBTZWdtZW50YXRpb24KCiAgIGZ1bGZpbGxlZAogICAKICAgU2VnbWVudGF0aW9u
IHRocm91Z2ggY2h1bmtlZCB0cmFuc2ZlciBlbmNvZGluZyAoNi4zIG9mIFsyXSkKCjQuIFBlcmZv
cm1hbmNlIFJlcXVpcmVtZW50cwoKNC4xIFByb3RvY29sIEVmZmljaWVuY3kKCiAgIGZ1bGZpbGxl
ZAoKICAgRWFzeSBlbmNhcHN1bGF0aW9uIG9mIEhUVFAgbWVzc2FnZXMsIGxpdHRsZSBvdmVyaGVh
ZC4KICAgSW1wbGVtZW50YXRpb25zIGFyZSBwb3NzaWJsZSB3aXRoIGxpdHRsZSBhZGRpdGlvbmFs
IGxhdGVuY3kgYnV0CiAgIHRoaXMgZGVwZW5kcyBvbiB0aGUgYWxnb3JpdGhtcyB1c2VkIGJ5IHRo
ZSBJQ0FQIHNlcnZpY2VzICh3aGV0aGVyCiAgIGRhdGEgaGFuZGxpbmcgY2h1bmsgYnkgY2h1bmsg
aXMgcG9zc2libGUpOyBzb21lIGFsZ29yaXRobXMgaGF2ZQogICByZXN0cmljdGlvbnMgdGhhdCBh
cmUgaW5kZXBlbmRlbnQgb2YgdGhlIGNhbGxvdXQgcHJvdG9jb2wgYmVpbmcKICAgdXNlZC4KICAg
CjUuIFNlY3VyaXR5IFJlcXVpcmVtZW50cwoKICAgaW5jb21wbGV0ZQoKICAgSWYgSUNBUCBjYW4g
YmUgY29tcGFyZWQgd2l0aCBIVFRQLCB0aGUgSUNBUCBjb3VudGVycGFydCB0byBIVFRQUwogICAo
SUNBUFMpIGlzIG1pc3NpbmcuCiAgIFRoZSBJQ0FQIHByb3RvY29sIGl0c2VsZiBhbmQgZXZlbiBt
b3JlIGN1cnJlbnQgaW1wbGVtZW50YXRpb25zIGFyZQogICBkZXNpZ25lZCBmb3IgdXNhZ2UgaW4g
YSB0cnVzdGVkIGVudmlyb25tZW50IHdoZXJlIGF1dGhlbnRpY2F0aW9uIGFuZAogICBlbmNyeXB0
aW9uIG9mIGRhdGEgYmV0d2VlbiBJQ0FQIGNsaWVudCBhbmQgc2VydmVyIGFyZSBub3QgbmVjZXNz
YXJ5LgogICAKNS4xIEF1dGhlbnRpY2F0aW9uLCBDb25maWRlbnRpYWxpdHksIGFuZCBJbnRlZ3Jp
dHkKCiAgIGluY29tcGxldGUKICAgCiAgIEF1dGhlbnRpY2F0aW9uIGNhbiBiZSBkb25lIGFzIGlu
IEhUVFAgKDcuMSBvZiBbMl0pLgogICBCdXQgSUNBUCBpcyBkZXNpZ25lZCBmb3IgdXNhZ2UgaW4g
c2luZ2xlIHRydXN0IGRvbWFpbgogICAKNS4yIEhvcC1ieS1Ib3AgQ29uZmlkZW50aWFsaXR5Cgog
ICBpbmNvbXBsZXRlCgogICBUaGVyZSBpcyBhIHNlY3Rpb24gYWJvdXQgcHJpbmNpcGxlIGVuY3J5
cHRpb24gbWV0aG9kcyAoNy4yIG9mIFsyXSkKICAgYnV0IHRoZXJlIGFyZSBubyByZWFsIHNwZWNz
IGZvciB0aGlzLgoKCgoKClN0ZWNoZXIgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgRGVjZW1i
ZXIsIDIwMDIgICAgICAgICAgICAgICBbUGFnZSA2XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAg
ICBFdmFsdWF0aW5nIHRoZSBJQ0FQIHByb3RvY29sICAgICAgICAgIEp1bmUgMjAwMgoKCjUuMyBP
cGVyYXRpb24gQWNyb3NzIFVuLXRydXN0ZWQgRG9tYWlucwogICAKICAgaW5jb21wbGV0ZQogICAK
ICAgQWx0aG91Z2ggdGhlcmUgaXMgbm90aGluZyBpbiB0aGUgc3BlY3MsIHRoaXMgY291bGQgYmUg
aW1wbGVtZW50ZWQgYnkKICAgYSBWUE4gc29sdXRpb24gcHJvdmlkaW5nIGEgc2VjdXJlIFRDUCB0
dW5uZWwgYWNyb3NzIHRoZSB1bnRydXN0ZWQKICAgZG9tYWlucy4KCjUuNCBQcml2YWN5CgogICBm
YWlsZWQKICAgCiAgIEVuY3J5cHRpb24gb2YgaW5mb3JtYXRpb24gcmVsZXZhbnQgdG8gcHJpdmFj
eSBwb2xpY2llcyBpcyBub3QKICAgYSBNVVNUIGluIElDQVAuCgo2LiBTdW1tYXJ5CgogICBUaGUg
SUNBUCBwcm90b2NvbCBmdWxmaWxscyBtb3N0IG9mIHRoZSByZXF1aXJlbWVudHMuCiAgIAogICBJ
Q0FQIGlzIGluY29tcGxldGUgd2l0aCByZXNwZWN0IHRvIHN1cHBvcnQgZm9yIG11bHRpcGxlIGFw
cGxpY2F0aW9uCiAgIHByb3RvY29scywgZG9lcyBub3QgaGF2ZSBrZWVwIGFsaXZlIG1lc3NhZ2Vz
IGFuZCBpdCBsYWNrcyBzb21lCiAgIHNlY3VyaXR5IHJlcXVpcmVtZW50cy4KICAgCjcuIFNlY3Vy
aXR5IENvbnNpZGVyYXRpb25zCgogICBUaGUgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGZvciB0aGUg
T1BFUyBjYWxsb3V0IHByb3RvY29sIGFyZSBkaXNjdXNzZWQKICAgaW4gU2VjdGlvbiA1LgoKClJl
ZmVyZW5jZXMKCiAgIFsxXSAgQmVjaywgQS4sIGV0IGFsLiwgIlJlcXVpcmVtZW50cyBmb3IgT1BF
UyBDYWxsb3V0IFByb3RvY29scyIsCiAgICAgICAgSW50ZXJuZXQgRHJhZnQgZHJhZnQtaWV0Zi1v
cGVzLXByb3RvY29sLXJlcXMtMDEudHh0LCAxOC1KdW4tMDIKCiAgIFsyXSAgSi4gRWxzb24sIEEu
IENlcnBhOiBJQ0FQIC0gdGhlIEludGVybmV0IENvbnRlbnQgQWRhcHRhdGlvbgogICAgICAgIFBy
b3RvY29sLCBJbnRlcm5ldCBEcmFmdCBkcmFmdC1lbHNvbi1pY2FwLTAxLnR4dCwgSnVuZSAyMDAy
CgogICBbMl0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRp
Y2F0ZSBSZXF1aXJlbWVudAogICAgICAgIExldmVscyIsIFJGQyAyMTE5LCBNYXJjaCAxOTk3LgoK
QXV0aG9ycycgQWRkcmVzcwoKICAgTWFydGluIFN0ZWNoZXIKICAgd2Vid2FzaGVyLmNvbSBBRwog
ICBWYXR0bWFubnN0ci4gMwogICAzMzEwMCBQYWRlcmJvcm4KICAgR2VybWFueQogICAKICAgRU1h
aWw6IG1hcnRpbi5zdGVjaGVyQHdlYndhc2hlci5jb20KCgpTdGVjaGVyICAgICAgICAgICAgICAg
ICAgICBFeHBpcmVzIERlY2VtYmVyLCAyMDAyICAgICAgICAgICAgICAgW1BhZ2UgN10KDApJbnRl
cm5ldC1EcmFmdCAgICAgICAgICAgRXZhbHVhdGluZyB0aGUgSUNBUCBwcm90b2NvbCAgICAgICAg
ICBKdW5lIDIwMDIKCgpGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQKCiAgIENvcHlyaWdodCAoQykg
VGhlIEludGVybmV0IFNvY2lldHkgKDIwMDIpLiAgQWxsIFJpZ2h0cyBSZXNlcnZlZC4KCiAgIFRo
aXMgZG9jdW1lbnQgYW5kIHRyYW5zbGF0aW9ucyBvZiBpdCBtYXkgYmUgY29waWVkIGFuZCBmdXJu
aXNoZWQgdG8KICAgb3RoZXJzLCBhbmQgZGVyaXZhdGl2ZSB3b3JrcyB0aGF0IGNvbW1lbnQgb24g
b3Igb3RoZXJ3aXNlIGV4cGxhaW4gaXQKICAgb3IgYXNzaXN0IGluIGl0cyBpbXBsZW1lbnRhdGlv
biBtYXkgYmUgcHJlcGFyZWQsIGNvcGllZCwgcHVibGlzaGVkCiAgIGFuZCBkaXN0cmlidXRlZCwg
aW4gd2hvbGUgb3IgaW4gcGFydCwgd2l0aG91dCByZXN0cmljdGlvbiBvZiBhbnkKICAga2luZCwg
cHJvdmlkZWQgdGhhdCB0aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwYXJhZ3Jh
cGggYXJlCiAgIGluY2x1ZGVkIG9uIGFsbCBzdWNoIGNvcGllcyBhbmQgZGVyaXZhdGl2ZSB3b3Jr
cy4gIEhvd2V2ZXIsIHRoaXMKICAgZG9jdW1lbnQgaXRzZWxmIG1heSBub3QgYmUgbW9kaWZpZWQg
aW4gYW55IHdheSwgc3VjaCBhcyBieSByZW1vdmluZwogICB0aGUgY29weXJpZ2h0IG5vdGljZSBv
ciByZWZlcmVuY2VzIHRvIHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIG90aGVyCiAgIEludGVybmV0
IG9yZ2FuaXphdGlvbnMsIGV4Y2VwdCBhcyBuZWVkZWQgZm9yIHRoZSBwdXJwb3NlIG9mCiAgIGRl
dmVsb3BpbmcgSW50ZXJuZXQgc3RhbmRhcmRzIGluIHdoaWNoIGNhc2UgdGhlIHByb2NlZHVyZXMg
Zm9yCiAgIGNvcHlyaWdodHMgZGVmaW5lZCBpbiB0aGUgSW50ZXJuZXQgU3RhbmRhcmRzIHByb2Nl
c3MgbXVzdCBiZQogICBmb2xsb3dlZCwgb3IgYXMgcmVxdWlyZWQgdG8gdHJhbnNsYXRlIGl0IGlu
dG8gbGFuZ3VhZ2VzIG90aGVyIHRoYW4KICAgRW5nbGlzaC4KCiAgIFRoZSBsaW1pdGVkIHBlcm1p
c3Npb25zIGdyYW50ZWQgYWJvdmUgYXJlIHBlcnBldHVhbCBhbmQgd2lsbCBub3QgYmUKICAgcmV2
b2tlZCBieSB0aGUgSW50ZXJuZXQgU29jaWV0eSBvciBpdHMgc3VjY2Vzc29ycyBvciBhc3NpZ25z
LgoKICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4g
aXMgcHJvdmlkZWQgb24gYW4KICAgIkFTIElTIiBiYXNpcyBhbmQgVEhFIElOVEVSTkVUIFNPQ0lF
VFkgQU5EIFRIRSBJTlRFUk5FVCBFTkdJTkVFUklORwogICBUQVNLIEZPUkNFIERJU0NMQUlNUyBB
TEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELCBJTkNMVURJTkcKICAgQlVUIE5PVCBM
SU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgT0YgVEhFIElORk9STUFUSU9OCiAg
IEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEIFdBUlJB
TlRJRVMgT0YKICAgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQ
VVJQT1NFLgoKQWNrbm93bGVkZ2VtZW50CgogICBGdW5kaW5nIGZvciB0aGUgUkZDIEVkaXRvciBm
dW5jdGlvbiBpcyBjdXJyZW50bHkgcHJvdmlkZWQgYnkgdGhlCiAgIEludGVybmV0IFNvY2lldHku
CgoKCgoKCgoKCgoKCgoKCgoKCgpTdGVjaGVyICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIERl
Y2VtYmVyLCAyMDAyICAgICAgICAgICAgICAgW1BhZ2UgOF0KDAo=

------_=_NextPart_001_01C2193E.5E897F32--


From owner-ietf-openproxy@mail.imc.org  Fri Jun 21 12:44:14 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21620
	for <opes-archive@ietf.org>; Fri, 21 Jun 2002 12:44:14 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5LGEpX06315
	for ietf-openproxy-bks; Fri, 21 Jun 2002 09:14:51 -0700 (PDT)
Received: from hermes.webwasher.com (mail.webwasher.com [195.162.240.3])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LGEnn06310
	for <ietf-openproxy@imc.org>; Fri, 21 Jun 2002 09:14:49 -0700 (PDT)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: Re: draft-stecher-opes-icap-eval-00
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Fri, 21 Jun 2002 18:12:18 +0200
Message-ID: <72992B39BBD9294BB636A960E89AE02E50BEFC@hermes.webwasher.com>
Thread-Topic: Re: draft-stecher-opes-icap-eval-00
Thread-Index: AcIZPpi8e7f4upVvTqupA2wid+laiQ==
From: "Martin Stecher" <martin.stecher@webwasher.com>
To: "OPES WG (E-mail)" <ietf-openproxy@imc.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g5LGEon06311
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


Hi,

I published this draft in which I try to evaluate and review the ICAP protocol regarding the OPES requirements.
Hope that this can work as a base for discussion and ICAP draft review.

Regards
Martin


From owner-ietf-openproxy@mail.imc.org  Fri Jun 21 15:17:29 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28057
	for <opes-archive@ietf.org>; Fri, 21 Jun 2002 15:17:28 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5LIoqu15225
	for ietf-openproxy-bks; Fri, 21 Jun 2002 11:50:52 -0700 (PDT)
Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LIoon15221
	for <ietf-openproxy@imc.org>; Fri, 21 Jun 2002 11:50:51 -0700 (PDT)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7])
	by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5LIo5210150;
	Fri, 21 Jun 2002 14:50:05 -0400 (EDT)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19)
	id <KTYBX2PX>; Fri, 21 Jun 2002 14:50:04 -0400
Message-ID: <87609AFB433BD5118D5E0002A52CD754029881EB@zcard0k6.ca.nortel.com>
From: "Abbie Barbir" <abbieb@nortelnetworks.com>
To: "'internet-drafts@ietf.org'" <internet-drafts@ietf.org>
Cc: "'ietf-openproxy@imc.org'" <ietf-openproxy@imc.org>,
        "'Markus Hofmann'" <markus@mhof.com>,
        "'Marshall Rose'" <mrose@dbc.mtview.ca.us>,
        "Abbie Barbir" <abbieb@nortelnetworks.com>
Subject: Publish Draft:draft-ietf-opes-scenarios-00
Date: Fri, 21 Jun 2002 14:50:02 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C21954.71BBCF9A"
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C21954.71BBCF9A
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C21954.71BBCF9A"


------_=_NextPart_001_01C21954.71BBCF9A
Content-Type: text/plain;
	charset="iso-8859-1"


Please publish the attached as an Internet Draft
draft-ietf-opes-scenarios-00

thanks

abbie


------_=_NextPart_001_01C21954.71BBCF9A
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2655.35">
<TITLE>Publish Draft:draft-ietf-opes-scenarios-00</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>Please publish the attached as an Internet Draft</FONT>
<BR><FONT SIZE=2>draft-ietf-opes-scenarios-00</FONT>
</P>

<P><FONT SIZE=2>thanks</FONT>
</P>

<P><FONT SIZE=2>abbie</FONT>
</P>

<P><FONT FACE="Arial" SIZE=2 COLOR="#000000"></FONT>&nbsp;

</BODY>
</HTML>
------_=_NextPart_001_01C21954.71BBCF9A--

------_=_NextPart_000_01C21954.71BBCF9A
Content-Type: text/plain;
	name="draft-ietf-opes-scenarios-00.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="draft-ietf-opes-scenarios-00.txt"
Content-Transfer-Encoding: quoted-printable



Network Working Group                                         A. Barbir
Internet-Draft                                           Nortel =
Networks
Expires: December 20, 2002                                     E. =
Burger
                                                SnowShore Networks, =
Inc.
                                                                 R. =
Chen
                                                               AT&T =
Labs
                                                              S. =
McHenry
                                                         CacheWare, =
Inc.
                                                                H. =
Orman
                                               Purple Streak =
Development
                                                                R. =
Penno
                                                         Nortel =
Networks
                                                           June 21, =
2002


                OPES Use Cases and Deployment Scenarios
                      draft-ietf-opes-scenarios-00

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six =
months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 20, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   This memo provides a discussion of use cases and deployment =
scenarios
   for Open Pluggable Edge Services (OPES).  The work examines services



Barbir , et al.         Expires December 20, 2002               [Page =
1]
=0C
Internet-Draft               OPES Scenarios                    June =
2002


   that could be performed  to requests and/or responses.

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  =
3
   2.    Types of OPES services . . . . . . . . . . . . . . . . . . .  =
4
   2.1   Services performed on requests . . . . . . . . . . . . . . .  =
4
   2.1.1 Services intending to modify requests  . . . . . . . . . . .  =
4
   2.1.2 Services *not* intending to modify requests  . . . . . . . .  =
5
   2.2   Services performed on responses  . . . . . . . . . . . . . .  =
5
   2.2.1 Services intending to modify responses . . . . . . . . . . .  =
6
   2.2.2 Services *not* intending to modify responses . . . . . . . .  =
6
   2.3   Services creating responses  . . . . . . . . . . . . . . . .  =
6
   3.    OPES deployment scenarios  . . . . . . . . . . . . . . . . .  =
7
   3.1   Surrogate Overlays . . . . . . . . . . . . . . . . . . . . .  =
7
   3.2   Delegate Overlays  . . . . . . . . . . . . . . . . . . . . .  =
8
   3.3   Enterprise environment . . . . . . . . . . . . . . . . . . .  =
9
   3.4   Callout Servers  . . . . . . . . . . . . . . . . . . . . . . =
10
   3.5   Chaining of OPES data filters and callout servers  . . . . . =
10
   3.5.1 Chaining along the content path  . . . . . . . . . . . . . . =
10
   3.5.2 Chaining along the callout path  . . . . . . . . . . . . . . =
10
   4.    Failure cases and service notification . . . . . . . . . . . =
12
   5.    Security Considerations  . . . . . . . . . . . . . . . . . . =
14
         References . . . . . . . . . . . . . . . . . . . . . . . . . =
15
         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . =
15
   A.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . =
17
         Full Copyright Statement . . . . . . . . . . . . . . . . . . =
18
























Barbir , et al.         Expires December 20, 2002               [Page =
2]
=0C
Internet-Draft               OPES Scenarios                    June =
2002


1. Introduction

   The Open Pluggable Edge Services (OPES) [1]  architecture enables
   cooperative application services (OPES services) between a data
   provider, a data consumer, and zero or more OPES processors.  The
   application services under consideration analyze and possibly
   transform application-level messages exchanged between the data
   provider and the data consumer.  The execution of such services is
   governed by a set of filtering rules installed on the OPES =
processor.

   The rules enforcement can trigger the execution of service
   applications local to the OPES processor.  Alternatively, the OPES
   processor can distribute the responsibility of service execution by
   communicating and collaborating with one or more remote callout [7]
   servers.

   The document presents examples of services in which Open Pluggable
   Edge Services (OPES) would be useful.  There are different types of
   OPES services: services that modify requests, services that modify
   responses, and a special case of the latter, services that create
   responses.

   The work also examines  various deployment  scenarios of OPES
   services.  The two main deployment scenarios, as described by the
   OPES architecture [1], are surrogate overlays and delegate overlays.
   Surrogate overlays act on behalf of data provider applications, =
while
   delegate overlays act on behalf of data consumer applications.  The
   document also describes combined surrogate and delegate overlays, as
   one might find within an enterprise deployment.

   The document is organized as follows: Section 2 discusses the =
various
   types of OPES services.  Section 3 introduces OPES deployment
   scenarios.  Section 4 discusses failure cases and service
   notification.  Section 5 discusses security considerations.

















Barbir , et al.         Expires December 20, 2002               [Page =
3]
=0C
Internet-Draft               OPES Scenarios                    June =
2002


2. Types of OPES services

   OPES scenarios involve services that can be performed on requests =
for
   data and/or responses.  OPES services can be classified into three
   categories: services performed on requests, services performed on
   responses, and services creating responses.  In Figure 1, the four
   service activation points for an OPES processor are depicted.  The
   data dispatcher examines OPES rules, enforces policies, and invokes
   service applications (if applicable) at each service activation
   point.

   =
---------------------------------------------------------------------




              +------------------------------------------------+
              |         +-------------+-------------+          |
              |         |   Service Application     |          |
              |         +---------------------------+          |
         Responses      |       Data Dispatcher     |     Responses
       <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D4=3D=3D =
+---------------------------+ <=3D3=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
         Requests       |           HTTP            |      Requests
       =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D1=3D> =
+---------------------------+ =3D=3D2=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>
              |                  OPES Processor                |
              +------------------------------------------------+



                  Figure 1: Service Activation Points

   =
---------------------------------------------------------------------


2.1 Services performed on requests

   An OPES service performed on HTTP requests may occur when a request
   arrives at an OPES processor (point 1) or when it is about to leave
   the OPES processor (point 2).

   The services performed on requests can further be divided into two
   cases: those that intend to modify requests and those that do not.

2.1.1  Services intending to modify requests

   An OPES processor may modify a service request on behalf of the data
   consumer for various reasons, such as:




Barbir , et al.         Expires December 20, 2002               [Page =
4]
=0C
Internet-Draft               OPES Scenarios                    June =
2002


   o  Owner of a Web access device might need control over what kind of
      Web content can be accessed with the device, parental control for
      example.

   o  Organization may restrict or redirect access to certain web
      services based on various criterias such as time of the day or =
the
      employee access privileges.

   o  Hiding the data consumer's identity, user agent, or referrer.

   o  Adding user preferences or device profile to the service request
      to get personalized or adapted services.

   o  Blocking or redirecting a service request due to a corporate
      policy.

   An OPES processor may also modify a service request on behalf of the
   data provider in several ways, such as:

   o  Redirecting the request to a different server to reduce the =
server
      work load.

   o  Redirecting image requests to improve access time.


2.1.2  Services *not* intending to modify requests

   An OPES processor may invoke useful service applications that do not
   modify the user requests.  Examples include:

   o  Administrative functions for the data provider, such as service
      monitoring or usage tracking for billing purposes.

   o  Useful services for the data consumer, such as user profiling
      (with the user's consent) for service adaptation later on.


2.2 Services performed on responses

   An OPES service performed on HTTP responses may occur when a =
response
   arrives at an OPES processor (point 3) or when it is about to leave
   the OPES processor (point 4).   In the case of a caching proxy, the
   former service may be an encoding operation before the content is
   stored in the cache, while the latter may be a decoding operation
   before the content is returned to the data consumer.

   The services performed on responses can further be divided into two
   cases: those that intend to modify responses and those that do not.



Barbir , et al.         Expires December 20, 2002               [Page =
5]
=0C
Internet-Draft               OPES Scenarios                    June =
2002


2.2.1  Services intending to modify responses

   There are several reasons why responses from the data providers =
might
   be modified before delivery to the data consumer:

   o  Content adaptation:  the data provider may not have all the =
device
      profiles and templates necessary to transcode the original =
content
      into a format appropriate for mobile devices of limited screen
      size and display capabilities.

   o  Language translation:  the data provider may not have all the
      translation capabilities needed to deliver the same content in
      multiple languages to various areas around the world.  An OPES
      processor may perform the language translation or it may invoke
      different callout servers to perform different language
      translation tasks.


2.2.2  Services *not* intending to modify responses

   An OPES service may be performed on the responses without modifying
   them.  Examples include:

   o  Logging/Monitoring: Each response may be examined and recorded =
for
      monitoring or debugging purposes.

   o  Accounting: An OPES processor may record the usage data (time and
      space) of each service request for billing purposes.


2.3 Services creating responses

   Services creating responses may include OPES services that
   dynamically assemble web pages based on the context of the data
   consumer application.

   Consider a content provider offering web pages that include a local
   weather forecast based on the requestor's preferences.  The OPES
   service could analyze received requests, identify associated user
   preferences, select appropriate templates, insert the corresponding
   local weather forecasts, and would then deliver the content to the
   requestor.  Note that the OPES processor may perform the tasks with
   or without direct access to the weather data.  For example, the
   service could use locally cached weather data or it could simply
   embedd a URL pointing to another server that holds the latest local
   weather forecast information.





Barbir , et al.         Expires December 20, 2002               [Page =
6]
=0C
Internet-Draft               OPES Scenarios                    June =
2002


3. OPES deployment scenarios

   OPES entities can be deployed over an overlay network that supports
   the provisioning of data services in a distributed manner.  Overlay
   networks are an abstraction that creates a virtual network of
   connected devices layered on an existing underlying IP networks in
   order to perform application level services.

   The use of overlay networks creates virtual networks that via OPES
   entities enables the necessary network infrastructure to provide
   better services for data consumer and provider applications.  At the
   application level, the resulting overlay networks are termed OPES
   Services Networks.

   There are two parties that are interested in the services that are
   offered by OPES entities, the delegate and the surrogate.  Delegates
   are authorized agents that act on behalf of data consumers.
   Surrogates are authorized agents that act on behalf of data
   providers.

   All parties that are involved in enforcing policies must communicate
   the policies to the parties that are involved.  These parties are
   trusted to adhere to the communicated policies.

   In order to delegate fine-grained trust, the parties must convey
   policy information by implicit contract, by a setup protocol, by a
   dynamic negotiation protocol, or in-line with application data
   headers.

3.1 Surrogate Overlays

   A surrogate overlay is a specific type of OPES service network, =
which
   is delegated the authority to provide data services on behalf of one
   or more origin servers.  Such services include, but are not limited
   to, dynamic assembling of web pages, watermarking, and content
   adaptation.

   The elements of surrogate overlays act on behalf of origin severs =
and
   logically belong to the authoritative domain of the respective =
origin
   servers.  The scenario is depicted in Figure 2.











Barbir , et al.         Expires December 20, 2002               [Page =
7]
=0C
Internet-Draft               OPES Scenarios                    June =
2002


   =
---------------------------------------------------------------------




              *********************************************
              *                                           *
              *    +--------+             Authoritative   *
              *    | Origin |                    Domain   *
              *    | Server |                             *
              *    +--------+       +------------+        *
              *         |           | OPES Admin |        *
              *         |           |   Server   |        *
              *         |           +------------+        *
              *         |         /                       *
              *         |       /                         *
              * +--------------+      +-----------------+ *
              * |     OPES     |----- | Remote Call-out | *
              * |   Processor  |      |     Server      | *
              * +--------------+      +-----------------+ *
              *         |                                 *
              *********************************************
                        |
                        |
                        |
                   +---------------------------+
                   | Data consumer application |
                   +---------------------------+




         Figure 2: Authoritative Domains for Surrogate Overlays

   =
---------------------------------------------------------------------


3.2 Delegate Overlays

   A delegate overlay is a specific type of OPES service network, which
   is delegated the authority to provide data services on behalf of one
   or more data consumer applications.

   Delegate overlays provide services that would otherwise be performed
   by the data consumer applications.  Such services include, but are
   not limited to, virus scanning and content filtering.

   The elements of delegate overlays logically belong to the



Barbir , et al.         Expires December 20, 2002               [Page =
8]
=0C
Internet-Draft               OPES Scenarios                    June =
2002


   authoritative domain of the respective data consumer application.
   The situation is illustrated in  Figure 3.

   =
---------------------------------------------------------------------



                   +--------+
                   | Origin |
                   | Server |
                   +--------+
                        |
                        |
                        |
              *********************************************
              *         |                                 *
              * +--------------+      +-----------------+ *
              * |     OPES     |----- | Remote Call-out | *
              * |    Processor |      |     Server      | *
              * +--------------+      +-----------------+ *
              *         |       \                         *
              *         |         +------------+          *
              *         |         | OPES Admin |          *
              *         |         |   Server   |          *
              *         |         +------------+          *
              *    +---------------------+                *
              *    | Data consumer Appl. | Authoritative  *
              *    +---------------------+        Domain  *
              *                                           *
              *********************************************



         Figure 3: Authoritative Domains for Delegate Overlays

   =
---------------------------------------------------------------------


3.3 Enterprise environment

   Deployment of OPES services in an enterprise environment is unique =
in
   several ways:

   o  Both data providers and data consumers are in the same
      administrative domain and trust domain.  This implies that the
      logical OPES administrator has the authority to enforce corporate
      policies on all data providers, data consumers, and OPES =
entities.




Barbir , et al.         Expires December 20, 2002               [Page =
9]
=0C
Internet-Draft               OPES Scenarios                    June =
2002


   o  In the case when a callout server outside the corporate firewall
      is invoked for services (such as language translation) that =
cannot
      be performed inside the corporation, care must be taken to
      guarantee a secure communication channel between the callout
      server and corporate OPES entities.  The callout server must also
      adhere to all corporate security policies for the services
      authorized.


3.4 Callout Servers

   In some cases the deployment of OPES services can benefit from the
   use of callout servers that could distribute the workload of OPES
   processors or to contract specialized services from other OPES
   providers.

   In general, operations such as virus scanning that operate on large
   objects are better handled through the use of a dedicated callout
   server that is better designed to perform the memory intensive task
   than what an OPES processor could handle.

3.5 Chaining of OPES data filters and callout servers

   OPES data processors can be "chained" in two dimensions: along the
   content path or along the callout path.  In the latter case, the
   callout servers can themselves be organized in series for handling
   requests.  Any content that is touched by more than one data
   processor or more than one callout server has been handled by a
   "chain".

3.5.1 Chaining along the content path

   An OPES provider may have assigned OPES services to a set of
   processors arranged in series.  All content might move through the
   series, and if the content matches the rules for a processor, it is
   subjected to the service.  In this way, the content can be enhanced
   by several services.  This kind of chaining can be successful if the
   services are relatively independent.  For example, the content might
   be assembled by a service early in the chain and then further
   decorated by a later service.

3.5.2 Chaining along the callout path

   Alternatively, an OPES data processor might act as a content-level
   switch in a cluster of other data processors and callout servers.
   The first stage might develop a processing schedule for the content
   and direct it to other OPES data processors and/or callout servers.
   For example, OPES processor A might handle all services assembling



Barbir , et al.         Expires December 20, 2002              [Page =
10]
=0C
Internet-Draft               OPES Scenarios                    June =
2002


   content, OPES processor B might handle all services involving URL
   translation, and OPES processor C might handle all content security
   services.  The first processor would determine that processors A and
   C were needed for a particular content object, and it would direct
   the content to those processors.  In turn, the processors might use
   several callout servers to accomplish the task.













































Barbir , et al.         Expires December 20, 2002              [Page =
11]
=0C
Internet-Draft               OPES Scenarios                    June =
2002


4. Failure cases and service notification

   These are illustrative cases where information about OPES processing
   can help endpoint users determine where and why content =
modifications
   are being performed.

   o  Content provider uses an OPES data processor to enhance content
      based only on context local to the provider.  The local context
      might be time of day, local URL, or available advertising, for
      example.  The content provider might find OPES logging to be
      sufficient for debugging any problems in this case.  However, the
      content provider might also try direct probing by issuing a
      request for the content and examining headers related to tracing.
      If unexpected parameters show up in the trace headers, the =
content
      provider's administrator can use these to correct the OPES rules
      or detect the presence of an unexpected OPES processor in the
      content path.

   o  Content provider uses an OPES data processor to enhance content
      based on context related to the requestor.  The requestor may
      notice that his requests do not elicit the same response as
      another requestor.  He may, for example, get an error message.  =
If
      he believes there is a configuration error on the OPES data
      processor, he will need to provide information to the
      administrator of it.  If the information includes "OPES service
      access control, action: blocked", for example, he can inquire
      about the circumstances that will allow him to be added to the
      access control list.  In another example, if he sees a picture
      unrelated to the surrounding text, and if the tracing shows "OPES
      service choose picture, action: insert 640x480 weather.gif", he
      might complain that the OPES service does not properly recognize
      his geographic location and inserts the wrong weather map.  In =
any
      case, if the information is forwarded to the content provider, =
the
      problem may be fixed.

   o  End user has OPES processor available as part of his network
      access environment.  The end user may have selected "translate
      English to Spanish" as an OPES service.  If he sees "OPES service
      language translation, action: destination language not supported,
      no action", then he may inquire of the OPES service provider =
about
      what languages are supported by the package.  If the end user
      feels that the source language is not properly represented by the
      provider, resulting in inability for the service to operate, he
      (or the language service provider) can contact the content
      provider.

   o  If the content provider gets complaints from users of the
      translation service and feels that the problem is not in the



Barbir , et al.         Expires December 20, 2002              [Page =
12]
=0C
Internet-Draft               OPES Scenarios                    June =
2002


      content but in the content but in the service, he may recommend
      that the service not be applied to his pages.  He can do that
      through content headers, for example, with the notation "No OPES
      service #8D3298EB" or "No OPES class language translation".

   o  End user's ISP or enterprise uses OPES to control user access
      based on user profiles.  The end user can see that the OPES
      services are being applied by his ISP, but he cannot control =
them.
      If he feels that the transformations bowdlerize the content he =
can
      complain to the provider organization.

   o  The content provider or end user relies on a content distribution
      network and OPES is used within that network.  OPES may be
      authorized by either the content provider, end user, or both.  =
The
      content provider may suspect that his access control rules are =
not
      being applied properly, for example.  He may ask for notification
      on all accesses to his content through a log.  This request and
      the logfile are outside the OPES architecture; there are security
      implications for the request, the response, and the resources =
used
      by the logfile.































Barbir , et al.         Expires December 20, 2002              [Page =
13]
=0C
Internet-Draft               OPES Scenarios                    June =
2002


5. Security Considerations

   The document presents usage scenarios and deployment cases.  Issues
   related to the overall security of OPES entities are given in [1].















































Barbir , et al.         Expires December 20, 2002              [Page =
14]
=0C
Internet-Draft               OPES Scenarios                    June =
2002


References

   [1]  A. Barbir et. al, "An Architecture for Open Pluggable Edge
        Services (OPES)", Internet-Draft: http://www.ietf.org/internet-
        drafts/draft-ietf-opes-architecture-02.txt, June 2002.

   [2]  Floyd, S. and L. Daigle, "IAB Architectural and Policy
        Considerations for Open Pluggable Edge Services", RFC 3238,
        January 2002.

   [3]  Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
        Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S.
        Waldbusser, "Terminology for Policy-Based Management", RFC =
3198,
        November 2001.

   [4]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
        Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
        HTTP/1.1", RFC 2616, June 1999.

   [5]  OPES working group, "OPES Service Authorization and Enforcement
        Requirements", Internet-Draft TBD, May 2002.

   [6]  OPES working group, "OPES Ruleset Schema", Internet-Draft TBD,
        May 2002.

   [7]  A. Beck et al., "Requirements for OPES Callout Protocols",
        Internet-Draft http://www.ietf.org/internet-drafts/draft-ietf-
        opes-protocol-reqs-00.txt, May 2002.


Authors' Addresses

   Abbie Barbir
   Nortel Networks
   3500 Carling Avenue
   Nepean, Ontario  K2H 8E9
   Canada

   Phone: +1 613 763 5229
   EMail: abbieb@nortelnetworks.com











Barbir , et al.         Expires December 20, 2002              [Page =
15]
=0C
Internet-Draft               OPES Scenarios                    June =
2002


   Eric W. Burger
   SnowShore Networks, Inc.
   285 Billerica Rd
   Chelmsford, MA  01820-4120
   USA

   Phone:
   EMail: eburger@snowshore.com


   Robin Chen
   AT&T Labs
   Room E219,  180 Park Avenue
   Florham Park, NJ  07932
   US

   Phone: +1 973 360 8653
   EMail: chen@research.att.com


   Stephen McHenry
   CacheWare, Inc.
   Suite 150
   655 Campbell Technology Parkway, Suite 150
   Campbell, CA  95008
   US

   Phone: (408) 540-1270
   EMail: stephen@cacheware.com


   Hilarie Orman
   Purple Streak Development



   Phone:
   EMail: ho@alum.mit.edu


   Reinaldo Penno
   Nortel Networks
   4555 Great America Parkway
   Santa Clara, CA  95054
   US

   EMail: rpenno@nortelnetworks.com




Barbir , et al.         Expires December 20, 2002              [Page =
16]
=0C
Internet-Draft               OPES Scenarios                    June =
2002


Appendix A. Acknowledgements

   TBD
















































Barbir , et al.         Expires December 20, 2002              [Page =
17]
=0C
Internet-Draft               OPES Scenarios                    June =
2002


Full Copyright Statement

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph =
are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Barbir , et al.         Expires December 20, 2002              [Page =
18]
=0C




------_=_NextPart_000_01C21954.71BBCF9A--


From owner-ietf-openproxy@mail.imc.org  Fri Jun 21 15:19:34 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28224
	for <opes-archive@ietf.org>; Fri, 21 Jun 2002 15:19:34 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5LIqpm15265
	for ietf-openproxy-bks; Fri, 21 Jun 2002 11:52:51 -0700 (PDT)
Received: from kalia.dbc.mtview.ca.us (adsl-64-168-10-253.dsl.scrm01.pacbell.net [64.168.10.253])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5LIqon15260
	for <ietf-openproxy@imc.org>; Fri, 21 Jun 2002 11:52:50 -0700 (PDT)
Received: from kalia (localhost [127.0.0.1])
	by kalia.dbc.mtview.ca.us (8.11.6+3.4W/8.11.6) with SMTP id g5LIpm402355;
	Fri, 21 Jun 2002 11:51:48 -0700 (PDT)
Date: Fri, 21 Jun 2002 11:51:47 -0700
From: Marshall Rose <mrose@dbc.mtview.ca.us>
To: "Abbie Barbir" <abbieb@nortelnetworks.com>
Cc: internet-drafts@ietf.org, ietf-openproxy@imc.org, markus@mhof.com,
        abbieb@nortelnetworks.com
Subject: Re: Publish Draft:draft-ietf-opes-scenarios-00
Message-Id: <20020621115147.7e3b9d30.mrose@dbc.mtview.ca.us>
In-Reply-To: <87609AFB433BD5118D5E0002A52CD754029881EB@zcard0k6.ca.nortel.com>
References: <87609AFB433BD5118D5E0002A52CD754029881EB@zcard0k6.ca.nortel.com>
Organization: Dover Beach Consulting, Inc.
X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386-unknown-netbsdelf1.5ZA)
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: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


> 
> Please publish the attached as an Internet Draft
> draft-ietf-opes-scenarios-00

approved.

/mtr


From owner-ietf-openproxy@mail.imc.org  Fri Jun 21 22:57:12 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08130
	for <opes-archive@ietf.org>; Fri, 21 Jun 2002 22:57:12 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5M2WpL03543
	for ietf-openproxy-bks; Fri, 21 Jun 2002 19:32:51 -0700 (PDT)
Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5M2Wow03539
	for <ietf-openproxy@imc.org>; Fri, 21 Jun 2002 19:32:50 -0700 (PDT)
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.2/8.12.2) with ESMTP id g5M2WrCT094692
	for <ietf-openproxy@imc.org>; Fri, 21 Jun 2002 22:32:53 -0400 (EDT)
Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8])
	by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g5M2Wlk03236
	for <ietf-openproxy@imc.org>; Fri, 21 Jun 2002 22:32:47 -0400 (EDT)
Received: from bell-labs.com ([135.104.20.67])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id WAA14292
	for <ietf-openproxy@imc.org>; Fri, 21 Jun 2002 22:32:46 -0400 (EDT)
Message-ID: <3D13E1B0.8050906@bell-labs.com>
Date: Fri, 21 Jun 2002 22:32:16 -0400
From: Markus Hofmann <hofmann@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a) Gecko/20020611
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: OPES Group <ietf-openproxy@imc.org>
Subject: iCAP Discussion
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


Hi,

the first attempt didn't get through this afternoon, so here's the 
re-send.

-Markus

====================================================================

Folks,

as you probably know, our charter says that "The working group will
consider the ICAP protocol drafts as an OPES precursor and will will
support development of an analysis that explains the limitations of
ICAP, to accompany informational publication of that protocol.".

Please consider the draft published by Martin as a starting point for
the WG discussion on iCAP - please post your comments, feedback,
concerns, suggestions with respect to iCAP  to the OPES list.

Thanks,
    Markus



From owner-ietf-openproxy@mail.imc.org  Sun Jun 23 22:45:44 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10048
	for <opes-archive@ietf.org>; Sun, 23 Jun 2002 22:45:43 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5O2Lrt21674
	for ietf-openproxy-bks; Sun, 23 Jun 2002 19:21:53 -0700 (PDT)
Received: from kalia.dbc.mtview.ca.us (adsl-64-168-10-253.dsl.scrm01.pacbell.net [64.168.10.253])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5O2Lqw21669
	for <ietf-openproxy@imc.org>; Sun, 23 Jun 2002 19:21:52 -0700 (PDT)
Received: from kalia (localhost [127.0.0.1])
	by kalia.dbc.mtview.ca.us (8.11.6+3.4W/8.11.6) with SMTP id g5O2L3405936;
	Sun, 23 Jun 2002 19:21:03 -0700 (PDT)
Date: Sun, 23 Jun 2002 19:21:03 -0700
From: Marshall Rose <mrose@dbc.mtview.ca.us>
To: bindignavile.srinivas@nokia.com
Cc: internet-drafts@ietf.org, ietf-openproxy@imc.org, hofmann@bell-labs.com
Subject: Re: Publish Draft: draft-srinivas-opes-threats-00.txt
Message-Id: <20020623192103.6b73da66.mrose@dbc.mtview.ca.us>
In-Reply-To: <DC504E9C3384054C8506D3E6BB0124609DCB19@bsebe001.NOE.Nokia.com>
References: <DC504E9C3384054C8506D3E6BB0124609DCB19@bsebe001.NOE.Nokia.com>
Organization: Dover Beach Consulting, Inc.
X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386-unknown-netbsdelf1.5ZA)
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: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


> Hi,
> 
> Please publish the attached document as an Internet Draft.
> 
> 	draft-srinivas-opes-threats-00.txt

folks - people who want to publish individual I-D submissions do not have to ask the permission of the chairs. nor should they, we get quite enough email already and we already subscribe to all the relevant mailing lists...

/mtr


From owner-ietf-openproxy@mail.imc.org  Sun Jun 23 22:46:11 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10067
	for <opes-archive@ietf.org>; Sun, 23 Jun 2002 22:46:10 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5O2I0k21510
	for ietf-openproxy-bks; Sun, 23 Jun 2002 19:18:00 -0700 (PDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5O2Htw21504
	for <ietf-openproxy@imc.org>; Sun, 23 Jun 2002 19:17:56 -0700 (PDT)
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5O2LSj28751
	for <ietf-openproxy@imc.org>; Sun, 23 Jun 2002 21:21:28 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5bab3f4d39ac12f257126@davir04nok.americas.nokia.com>;
 Sun, 23 Jun 2002 21:17:56 -0500
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Sun, 23 Jun 2002 21:17:56 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C21B25.59B3A974"
Subject: Publish Draft: draft-srinivas-opes-threats-00.txt
Date: Sun, 23 Jun 2002 22:17:55 -0400
Message-ID: <DC504E9C3384054C8506D3E6BB0124609DCB19@bsebe001.NOE.Nokia.com>
X-MS-Has-Attach: yes
Thread-Topic: Publish Draft: draft-srinivas-opes-threats-00.txt
Thread-Index: AcIbJVd8ws3etQXKRZOkXaTuOqOYtw==
From: <bindignavile.srinivas@nokia.com>
To: <internet-drafts@ietf.org>
Cc: <ietf-openproxy@imc.org>, <mrose@dbc.mtview.ca.us>,
        <hofmann@bell-labs.com>
X-OriginalArrivalTime: 24 Jun 2002 02:17:56.0190 (UTC) FILETIME=[5A435FE0:01C21B25]
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This is a multi-part message in MIME format.

------_=_NextPart_001_01C21B25.59B3A974
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

Please publish the attached document as an Internet Draft.

	draft-srinivas-opes-threats-00.txt

Thank you.

Best regards,
B. Srinivas
Senior Research Engineer
NRC Boston

 <<draft-srinivas-opes-threats-00.txt.txt>>=20

------_=_NextPart_001_01C21B25.59B3A974
Content-Type: text/plain;
	name="draft-srinivas-opes-threats-00.txt.txt"
Content-Description: draft-srinivas-opes-threats-00.txt.txt
Content-Disposition: attachment;
	filename="draft-srinivas-opes-threats-00.txt.txt"
Content-Transfer-Encoding: base64

DQoNCiAgICAgICAgTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAg
ICBCLlMuIFNyaW5pdmFzIA0KICAgICAgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIFQuIENoYW4gDQogICAgICAgIEV4cGlyZXM6IERlY2VtYmVyIDIwMDIg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5va2lhIA0KICAgICAgICBGaWxlOiBkcmFm
dC1zcmluaXZhcy1vcGVzLXRocmVhdHMtMDAudHh0ICAgICAgICAgICAgIA0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAwMiANCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgDQogICAgICAgICANCiAgICAgICAgICAgICBT
ZWN1cml0eSBUaHJlYXRzIGFuZCBSaXNrcyBmb3IgT3BlbiBQbHVnZ2FibGUgRWRnZSBTZXJ2aWNl
cyANCiAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LXNyaW5pdmFzLW9w
ZXMtdGhyZWF0cy0wMC50eHQgDQogICAgICAgICANCiAgICAgICAgIA0KICAgICAgICAgDQogICAg
ICAgICANCiAgICAgICAgU3RhdHVzIG9mIHRoaXMgTWVtbyANCiAgICAgICAgIA0KICAgICAgICBU
aGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0IGFuZCBpcyBpbiBmdWxsIGNvbmZvcm1h
bmNlIHdpdGggDQogICAgICAgIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAy
Ni4gIEludGVybmV0LURyYWZ0cyBhcmUgDQogICAgICAgIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRo
ZSBJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIA0KICAgICAgICBh
cmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5
IGFsc28gDQogICAgICAgIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQt
RHJhZnRzLiANCiAgICAgICAgIA0KICAgICAgICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRv
Y3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCANCiAgICAgICAgbW9udGhzIGFuZCBt
YXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMg
DQogICAgICAgIGF0IGFueSB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJu
ZXQtRHJhZnRzIGFzIA0KICAgICAgICByZWZlcmVuY2UgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVt
IG90aGVyIHRoYW4gYXMgYGB3b3JrIGluIA0KICAgICAgICBwcm9ncmVzcy4nJyANCiAgICAgICAg
IA0KICAgICAgICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNj
ZXNzZWQgYXQgDQogICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3Rz
LnR4dC4gDQogICAgICAgICANCiAgICAgICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hh
ZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdCAgDQogICAgICAgIGh0dHA6Ly93d3cu
aWV0Zi5vcmcvc2hhZG93Lmh0bWwuIA0KICAgICAgICAgDQogICAgIENvbnZlbnRpb25zIHVzZWQg
aW4gdGhpcyBkb2N1bWVudCAgDQogICAgICAgICAgICAgDQogICAgICAgIFRoZSBrZXkgd29yZHMg
Ik1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwgIA0K
ICAgICAgICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAgIk1BWSIsIGFu
ZCAiT1BUSU9OQUwiIGluIA0KICAgICAgICB0aGlzIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnBy
ZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQy0yMTE5XS4gDQogICAgICAgICANCiAgICAgMS4gQWJz
dHJhY3QgDQogICAgICANCiAgICAgICAgVGhpcyBJbnRlcm5ldCBEcmFmdCBpcyBhbiBhdHRlbXB0
IHRvIGRlZmluZSB0aGUgc2VjdXJpdHkgdGhyZWF0cyANCiAgICAgICAgYWdhaW5zdCB0aGUgT1BF
UyBwcm90b2NvbC4gSW4gYWRkaXRpb24gdG8gdGhlIHRocmVhdHMsIHRoZSBlZmZlY3RzIA0KICAg
ICAgICBvZiBzdWNoIHNlY3VyaXR5IHRocmVhdHMgb24gdGhlIHVuZGVybHlpbmcgYXJjaGl0ZWN0
dXJlIGFzIHdlbGwgYXMgDQogICAgICAgIHRoZSByZXF1aXJlbWVudHMgb2YgYSBzZWN1cml0eSBz
b2x1dGlvbiB0byBtaXRpZ2F0ZSBzdWNoIHRocmVhdHMgYXJlIA0KICAgICAgICBkaXNjdXNzZWQu
IFRoZSB0aHJlYXRzIGFuZCByZXF1aXJlbWVudHMgaWRlbnRpZmllZCBoZXJlaW4gYW5kIHRoZSAN
CiAgICAgICAgZG9jdW1lbnQgc2hvdWxkIGJlIGNvbnNpZGVyZWQgYXMgd29yayBpbiBwcm9ncmVz
cy4gDQogICAgICAgICANCiAgICAgICAgIA0KICAgICAgICAgDQogICAgICAgICAgDQogICAgICAN
CiAgICAgIAwNCiAgICAgSW50ZXJuZXQgRHJhZnQgICAgICAgICBTZWN1cml0eSBUaHJlYXRzIGZv
ciBPUEVTICAgICAgICAgICAgICBKdW5lIDIwMDIgDQogICAgICANCiAgICAgIA0KICAgICAyLiBJ
bnRyb2R1Y3Rpb24gDQogICAgICANCiAgICAgICAgVGhlIGRhdGEgc3RyZWFtIGZsb3dpbmcgYmV0
d2VlbiBhIGNvbnRlbnQgcHJvdmlkZXIgYW5kIG9uZSBvciBtb3JlIA0KICAgICAgICBjb250ZW50
IGNvbnN1bWVycyBtYXkgYmUgaW4gbmVlZCBvZiBtb2RpZmljYXRpb25zIGFzIGEgZnVuY3Rpb24g
b2YgDQogICAgICAgIHRoZSBuZWVkcyBvZiB0aGUgY29uc3VtZXIsIHRoZSBjb25zdHJhaW50cyBv
ZiBoZXIvaGlzIGRldmljZSwgDQogICAgICAgIGhlci9oaXMgZ2VvZ3JhcGhpY2FsIGxvY2F0aW9u
IGFuZCBudW1lcm91cyBvdGhlciBmYWN0b3JzLiBUaGVzZSANCiAgICAgICAgbW9kaWZpY2F0aW9u
cyB0byB0aGUgdHJhZGl0aW9uYWwgc2NlbmFyaW8gKHNlZSBGaWd1cmUgMSkgYXJlIA0KICAgICAg
ICBlbmdpbmVlcmVkIGJ5IG1lYW5zIG9mIG90aGVyIGFwcGxpY2F0aW9uIGVudGl0aWVzLiBUaGUg
ZnVuY3Rpb25zIA0KICAgICAgICB0aGF0IHdlIGhhdmUgaW4gbWluZCBpbmNsdWRlIGxhbmd1YWdl
IHRyYW5zbGF0aW9uLCB2aXJ1cyBzY2FubmluZywgDQogICAgICAgIGJpdC1yYXRlIHJlZHVjdGlv
biBpbiBjb21wbGlhbmNlIHdpdGggbGltaXRlZCBiYW5kd2lkdGggDQogICAgICAgIGF2YWlsYWJp
bGl0eSwgYW5kIG1hbnkgb3RoZXJzIChzZWUgRmlndXJlIDIpLiANCiAgICAgIA0KICAgICAgDQog
ICAgICANCiAgICAgICAgICAgLS0tLS0tLS0tLS0tICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIC0tLS0tLS0tLS0tLQ0KICAgICAgICAgICB8ICAgICAgICAgIHwgICAgICAg
ICAgLy0tLS0tLS0tLS0tLS0tLS1cICAgICAgICAgICAgfCAgICAgICAgICB8DQogICAgICAgICAg
IHwgQ29udGVudCAgfCAgICAgXCAgIC8gICAgICAgICAgICAgICAgICBcICAgIFwgICAgICB8IENv
bnRlbnQgIHwNCiAgICAgICAgICAgfCBQcm92aWRlciB8LS0tLS0tLS0vICAgICBJUCAgICAgICAg
ICAgICBcLS0tLS0tLS0tLXwgQ29uc3VtZXIgfA0KICAgICAgICAgICB8ICAgICAgICAgIHwgICAg
IC8gIFwgICBOZXR3b3JrICAgICAgICAgIC8gICAvICAgICAgfCAgICAgICAgICB8DQogICAgICAg
ICAgIC0tLS0tLS0tLS0tLSAgICAgICAgIFwgICAgICAgICAgICAgICAgICAvICAgICAgICAgICAt
LS0tLS0tLS0tLS0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwtLS0tLS0tLS0t
LS0tLS0tLyAgICAgIA0KICAgICAgDQogICAgDQogICAgICANCiAgICAgICAgICAgICAgICAgICAg
ICAgRmlndXJlIDE6IFRyYWRpdGlvbmFsIG5vbi1PUEVTIHNjZW5hcmlvIA0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAN
CiAgICAgICAgICANCiAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tIA0KCSAgICAgICAgIHwg
ICAgICAgICAgfCANCgkgICAgICAgICB8IENvbnRlbnQgIHwNCgkgICAgICAgICB8IFByb3ZpZGVy
IHwNCgkgICAgICAgICB8ICAgICAgICAgIHwNCgkgICAgICAgICAtLS0tLS0tLS0tLS0NCgkgICAg
ICAgICAgICAgfCAgIHwNCgkgICAgICAgICAgICAgfA0KCSAgICAgICAgICAgLy18LSAtfC0tLS1c
DQoJICAgICAgICAgIC8gIHwgICAgICAgICBcDQoJIC0tLS0tLS0tLyAgIHwgICB8ICAgICAgXC0t
LXwgICAgICAgICAgICAgIA0KCSB8ICAgICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgIA0K
ICAgICAgICAgfCBJUCBuL3cgICAgfCAgIHwgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg
IC0tLS0tLS0tLS0tLSANCgkgfCAgICAgIC0tLS0tLS0tLS0tLS0tLXwgICAgfCAgICAgICAgICAg
ICAgICAgICAgIHwgQ2FsbG91dCAgfA0KCSB8ICAgICAgfCAgICBPUEVTICAgICAgfCAgICB8LS0t
LS0tLS0tLS0tLS0tLS0tLS0tfCBTZXJ2ZXIgICB8DQoJIHwgICAgICB8IEludGVybWVkaWFyeSB8
ICAgIHwtIC0gLSAtIC0gLSAtIC0gLSAtIC18ICAgICAgICAgIHwNCgkgfCAgICAgIHwgICAgICAg
ICAgICAgIHwgICAgfCAgICAgICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0tLQ0KCSB8ICAgICAg
LS0tLS0tLS0tLS0tLS0tLSAgICB8ICANCgkgfCAgICAgICAgICAgIHwgICB8ICAgICAgICAgfA0K
CSAgLS0tLS0tLS1cICAgfCAgICAgICAgLy0tLS0tDQoJICAgICAgICAgICBcICB8ICAgfCAgIC8N
CgkgICAgICAgICAgICBcLXwtLS0tLS0vDQoJICAgICAgICAgICAgICB8ICAgfCAgICAgICAgICAg
ICAgICAgIC0tLS0tLSBDb250ZW50IGZsb3cNCgkgICAgICAgICAgLS0tLS0tLS0tLS0tICAgICAg
ICAgICAgICAgLSAtIC0gIFNpZ25hbGluZyBmbG93IA0KCSAJICB8ICAgICAgICAgIHwgDQoJIAkg
IHwgQ29udGVudCAgfA0KCSAJICB8IENvbnN1bWVyIHwNCgkgCSAgfCAgICAgICAgICB8DQoJCSAg
LS0tLS0tLS0tLS0tDQogICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgIEZp
Z3VyZSAyOk9QRVMgTmV0d29yayBBcmNoaXRlY3R1cmUgDQogICAgICAgICANCiAgICAgIA0KICAg
ICBTcmluaXZhcywgQ2hhbiAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyMDAyICAgICAgICAgICAg
ICAgICAgICBbUGFnZSAyXSAMDQogICAgIEludGVybmV0IERyYWZ0ICAgICAgICAgU2VjdXJpdHkg
VGhyZWF0cyBmb3IgT1BFUyAgICAgICAgICAgICAgSnVuZSAyMDAyIA0KICAgICAgDQogICAgICAN
CiAgICAgICAgRWl0aGVyIHRoZSBhcHBsaWNhdGlvbiBlbnRpdGllcywgcmVmZXJyZWQgdG8gaW4g
dGhlIHByZWNlZGluZyB0ZXh0LCANCiAgICAgICAgbWF5IGJlIGNvbGxvY2F0ZWQgd2l0aCBlaXRo
ZXIgb2YgdGhlIHR3byBlbmRzIG9mIHRoZSBkYXRhIHN0cmVhbSBvciANCiAgICAgICAgaXQgbWF5
IGJlIGEgZGlzY3JldGUgZW50aXR5IHNpdHVhdGVkIGVsc2V3aGVyZSB3aXRoaW4gdGhlIG5ldHdv
cmsuIA0KICAgICAgICBUaGUgbGFzdCBzY2VuYXJpbyBjb21wcmlzZXMgYSBkYXRhIHN0cmVhbSBz
Y2VuYXJpbywgd2hpY2ggaXMgDQogICAgICAgIHJlZmVycmVkIHRvIGFzIE9wZW4gUGx1Z2dhYmxl
IEVkZ2UgU2VydmljZXMgKE9QRVMpLiBTZXZlcmFsIHN1Y2ggDQogICAgICAgIHByb3Zpc2lvbmlu
ZyBzY2VuYXJpb3MgYXJlIGRlc2NyaWJlZCBpbiBbT1BFUy1TQ0VORV0uICANCiAgICAgICAgIA0K
ICAgICAgICBUaGUgZG9jdW1lbnQgZGlzY3Vzc2VzIHNldmVyYWwgYWRkaXRpb25hbCBzZWN1cml0
eSB0aHJlYXRzLCB3aGljaCANCiAgICAgICAgdGhlIGRhdGEgc3RyZWFtIG1pZ2h0IGJlIGV4cG9z
ZWQgdG8gb3dpbmcgdG8gdGhlIHByZXNlbmNlIG9mIGEgDQogICAgICAgIGRpc2NyZXRlIGVudGl0
eSwgdGhlIE9QRVMgaW50ZXJtZWRpYXJ5IChhbmQgY2FsbC1vdXQgc2VydmVycyBbT1BFUy0NCiAg
ICAgICAgQ0FMTE9VVF0sIGlmIGFueSksIHRoYXQgcHJvdmlkZXMgdGhlIG5lZWRlZCBtb2RpZmlj
YXRpb24gc2VydmljZXMuIA0KICAgICAgICBIZXJlIGJ5IGRhdGEgc3RyZWFtLCB3ZSBpbXBseSBi
b3RoIHRoZSBjb250ZW50IHN0cmVhbSBhcyB3ZWxsIGFzIHRoZSANCiAgICAgICAgc2lnbmFsaW5n
IHN0cmVhbSAodG8gaW5kaWNhdGUgdGhlIGRlc2lyZWQgdHJhbnNmb3JtYXRpb24pLiBBcyANCiAg
ICAgICAgaWxsdXN0cmF0ZWQgaW4gRmlndXJlIDIsIHRoZSBjb250ZW50IHN0cmVhbSBmbG93cyBm
cm9tIHRoZSBjb250ZW50IA0KICAgICAgICBwcm92aWRlciB0byB0aGUgT1BFUyBpbnRlcm1lZGlh
cnksIHdoaWNoIG1heSBmdXJ0aGVyIGJlIGZvcndhcmRlZCB0byANCiAgICAgICAgYSBjYWxsLW91
dCBzZXJ2ZXIgYW5kIHJldHVybmVkLCB0aGVuIGZpbmFsbHkgZGVsaXZlcmVkIHRvIHRoZSANCiAg
ICAgICAgY29udGVudCBjb25zdW1lciBhZnRlciBhbGwgdGhlIGRlc2lyZWQgdHJhbnNmb3JtYXRp
b25zIGFyZSANCiAgICAgICAgcGVyZm9ybWVkLiBUaGUgc2lnbmFsaW5nIGluZm9ybWF0aW9uIChv
ciB0cmFuc2Zvcm1hdGlvbiByZXF1ZXN0cykgDQogICAgICAgIGNhbiBvcmlnaW5hdGUgZnJvbSBl
aXRoZXIgdGhlIENvbnRlbnQgcHJvdmlkZXIgb3IgY29uc3VtZXIuIA0KICAgICAgICBNb3Jlb3Zl
ciwgdGhlIE9QRVMgaW50ZXJtZWRpYXJ5IG1heSBzZW5kIHRyYW5zZm9ybWF0aW9uIHJlcXVlc3Rz
IHRvIA0KICAgICAgICBjYWxsLW91dCBzZXJ2ZXJzIGFzIHdlbGwuIEF0dGFja3MgcmVsYXRlZCB0
byB0aGUgc2lnbmFsaW5nIHN0cmVhbSANCiAgICAgICAgYW5kIGNvbnRlbnQgc3RyZWFtIG1heSBo
YXZlIGRpZmZlcmVudCByZXN1bHRzIGFuZCBuZWVkIHRvIGJlIA0KICAgICAgICBjb25zaWRlcmVk
IHNlcGFyYXRlbHkuICANCiAgICAgICAgIA0KICAgICAgICBOZXcgZnVuY3Rpb25hbGl0eSB3aGVu
IGFkZGVkIHRvIGEgbmV0d29ya2luZyBhcmNoaXRlY3R1cmUgaW52YXJpYWJseSANCiAgICAgICAg
Y3JlYXRlcyBuZXcgcG9zc2liaWxpdGllcyBmb3IgdGFtcGVyaW5nIHdpdGggc29tZSBzaWduYWxp
bmcgDQogICAgICAgIGNvbW11bmljYXRpb25zLCBhcyB3ZWxsIGFzIHVzZXIgZGF0YSB0cmFmZmlj
LiBJbiBvdGhlciB3b3JkcywgDQogICAgICAgIHZhcmlvdXMgZm9ybXMgb2YgcHJvdGVjdGlvbiBp
bmNsdWRpbmcgcGh5c2ljYWwgYW5kL29yIHByb2dyYW1tYXRpYyANCiAgICAgICAgbWVhbnMgYXJl
IGxvd2VyZWQsIHJlc3VsdGluZyBpbiBuZXcgc2VjdXJpdHkgdnVsbmVyYWJpbGl0aWVzLiBJbiAN
CiAgICAgICAgYWRkaXRpb24gdG8gdGhlIHRocmVhdHMsIHRoZSBkb2N1bWVudCBhbHNvIHByZXNl
bnRzIHRoZSBpbXBhY3RzIG9mIA0KICAgICAgICB0aGVzZSB0aHJlYXRzIGFzIHdlbGwgYXMgdGhl
IHJlcXVpcmVtZW50cyBvZiB0aGUgc2VjdXJpdHkgc29sdXRpb25zIA0KICAgICAgICB0byBtaXRp
Z2F0ZSBzdWNoIHRocmVhdHMuIA0KICAgICAgICAgDQogICAgICAgIE5vdGljZSB0aGF0IHRoZSBz
ZWN1cml0eSB0aHJlYXRzIGNvcnJlc3BvbmRpbmcgdG8gYSBjb250ZW50L3NlcnZpY2VzIA0KICAg
ICAgICBkZWxpdmVyeSBzeXN0ZW0gd2l0aG91dCBhbiBPUEVTIGludGVybWVkaWFyeSwgYXMgZGVw
aWN0ZWQgaW4gRmlndXJlIA0KICAgICAgICAxLCBpcyBjb25zaWRlcmVkIG91dC1vZi1zY29wZSBh
bmQgdGhlcmVmb3JlIHdpbGwgbm90IGJlIGRpc2N1c3NlZCBpbiANCiAgICAgICAgdGhpcyBkb2N1
bWVudC4gVGhpcyBkb2N1bWVudCBvbmx5IGZvY3VzZXMgb24gdGhyZWF0cyB0aGF0IGFyZSANCiAg
ICAgICAgaW50cm9kdWNlZCBieSB0aGUgZXhpc3RlbmNlIG9mIHRoZSBPUEVTIGludGVybWVkaWFy
eSBhbmQgY2FsbC1vdXQgDQogICAgICAgIHNlcnZlcnMuIA0KICAgICAgICAgDQogICAgICAgIFRo
ZSBkb2N1bWVudCBpcyBvcmdhbml6ZWQgYXMgZm9sbG93czogU2VjdGlvbiAzIGRpc2N1c3NlcyB0
aGUgDQogICAgICAgIHNlY3VyaXR5IHRocmVhdHMgaW50cm9kdWNlZCBieSB0aGUgT1BFUyBmdW5j
dGlvbmFsaXR5LiBTZWN0aW9uIDQgDQogICAgICAgIGRpc2N1c3NlcyB0aGUgSW50ZWxsZWN0dWFs
IFByb3BlcnR5IHJpZ2h0cyBpc3N1ZXMgaWYgYW55LiANCiAgICAgIA0KICAgICAzLiBUaHJlYXRz
IA0KICAgICAgDQogICAgICAgIFdpdGggdGhlIGluY29ycG9yYXRpb24gb2YgYW4gYWRkaXRpb25h
bCBhcHBsaWNhdGlvbiBlbnRpdHkgbmFtZWx5IA0KICAgICAgICB0aGUgT1BFUyBpbnRlcm1lZGlh
cnksIGRlc3BpdGUgaXRzIG9wZXJhdGlvbiBvbiB0aGUgZGF0YSBmbG93IA0KICAgICAgICBiZXR3
ZWVuIHRoZSBjb250ZW50IHByb2R1Y2VyIGFuZCBjb25zdW1lciBiZWluZyBhdXRob3JpemVkLCBh
IG5ldyANCiAgICAgICAgc2l0ZSBmb3IgZXhwb3N1cmUgdG8gdGhyZWF0cyBmcm9tIG1hbGljaW91
cyBlbnRpdGllcyBpcyBpbnRyb2R1Y2VkLiANCiAgICAgICAgQSB3aG9sZSBhcnJheSBvZiB0aHJl
YXRzLCB0aGVpciBlZmZlY3RzIGFuZCB0aGUgc3VnZ2VzdGVkIHNlY3VyaXR5IA0KICAgICAgICBz
b2x1dGlvbnMgYXJlIGRpc2N1c3NlZCBoZXJlaW4uIFRoZSB0aHJlYXRzIGRpc2N1c3NlZCBhcmUg
Y29uZ3J1ZW50IA0KICAgICAgICB3aXRoIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyByYWlz
ZWQgaW4gW1JGQzMyMzhdLiANCiAgICAgIA0KICAgICBTcmluaXZhcywgQ2hhbiAgICAgICAgRXhw
aXJlcyBEZWNlbWJlciAyMDAyICAgICAgICAgICAgICAgICAgICBbUGFnZSAzXSAMDQogICAgIElu
dGVybmV0IERyYWZ0ICAgICAgICAgU2VjdXJpdHkgVGhyZWF0cyBmb3IgT1BFUyAgICAgICAgICAg
ICAgSnVuZSAyMDAyIA0KICAgICAgDQogICAgICANCiAgICAgICAgIA0KICAgICAgICBJbiB0aGUg
dHJhZGl0aW9uYWwgbm9uLU9QRVMgc2NlbmFyaW8sIHRoZSBjb21tdW5pY2F0aW5nIGVuZC1wb2lu
dHMgDQogICAgICAgICh0aGUgY29udGVudCBwcm9kdWNlciBhbmQgY29uc3VtZXIpIGhhdmUgYSBk
aXJlY3Qgb25lLXRvLW9uZSANCiAgICAgICAgYXNzb2NpYXRpb24gYmV0d2VlbiB0aGVtIChzZWUg
RmlndXJlIDEpLiBUaGlzIGRpcmVjdCBhc3NvY2lhdGlvbiBpcyANCiAgICAgICAgYnJva2VuIGJ5
IHRoZSBleGlzdGVuY2Ugb2YgT1BFUyBpbnRlcm1lZGlhcmllcyBvciBjYWxsb3V0IHNlcnZlcnMu
IA0KICAgICAgICBUaGUgc2VjdXJlIG9wZXJhdGlvbiBvZiBwcm90b2NvbHMsIHR5cGljYWxseSwg
ZGVwZW5kcyBvbiBhc3N1bXB0aW9ucyANCiAgICAgICAgcmVnYXJkaW5nIHRoZSBpZGVudGl0eSBv
ZiB0aGUgZW5kcG9pbnRzIGFuZCB0aGUgY29udGludWl0eSBvZiANCiAgICAgICAgY29tbXVuaWNh
dGlvbiBiZXR3ZWVuIHRoZW0uIFRoZSBvcGVyYXRpb24gb2YgT1BFUyBpdHNlbGYgaGFzIA0KICAg
ICAgICBzZWN1cml0eSBpbXBsaWNhdGlvbnMgYW5kIHJpc2tzLiANCiAgICAgIA0KICAgICAgDQog
ICAgICAgICANCiAgICAgICAgIA0KICAgICAzLjEuIE9QRVMgZGV2aWNlIGZhbHNlIHJlZ2lzdHJh
dGlvbi9kZXJlZ2lzdHJhdGlvbiANCiAgICAgICAgIA0KICAgICAgICBUaHJlYXQ6ICBJbiB0aGUg
ZXZlbnQgb2YgdGhlIE9QRVMgaW50ZXJtZWRpYXJ5IGJlaW5nIGFic2VudCwgYSBmYWxzZSANCiAg
ICAgICAgcmVnaXN0cmF0aW9uIC8gZGVyZWdpc3RyYXRpb24gY291bGQgYmUgc2VudCBieSBhIG1h
bGljaW91cyBub2RlIG9uIA0KICAgICAgICBiZWhhbGYgb2YgdGhlIG5vbi1leGlzdGVudCBPUEVT
IGludGVybWVkaWFyeS4gDQogICAgICAgICAgDQogICAgICAgIEVmZmVjdDogQSBmYWxzZSByZWdp
c3RyYXRpb24gLyBkZXJlZ2lzdHJhdGlvbiB3b3VsZCByZXN1bHQgaW4gdGhlIA0KICAgICAgICBl
bmQtc3lzdGVtIHRyYWZmaWMgYmVpbmcgaGlqYWNrZWQgYnkgdGhlIG1hbGljaW91cyBub2RlLiBU
aGUgdHJhZmZpYyANCiAgICAgICAgaXMgdGhlbiBlYXZlc2Ryb3BwZWQgb24gYnkgdGhlIGF0dGFj
a2VyLiBNb3Jlb3ZlciwgdW53YW50ZWQgb3IgDQogICAgICAgIG1hbGljaW91cyB0cmFuc2Zvcm1h
dGlvbiBvZiB0aGUgZGF0YSB0cmFmZmljIHdvdWxkIG9jY3VyLiANCiAgICAgICAgQWx0ZXJuYXRp
dmVseSwgdGhlIG1hbGljaW91cyBub2RlIG1heSBzaW1wbHkgcmVmdXNlIHRvIGZvcndhcmQgdGhl
IA0KICAgICAgICBkYXRhIHRyYWZmaWMgdG8gdGhlIGNvbnRlbnQgY29uc3VtZXIsIHJlc3VsdGlu
ZyBpbiBhIERlbmlhbC1vZi0NCiAgICAgICAgU2VydmljZSBhdHRhY2suIA0KICAgICAgICAgDQog
ICAgICAgIFNvbHV0aW9uOiBFaXRoZXIgb2YgdGhlIGVuZC1wb2ludHMgTVVTVCBhdXRoZW50aWNh
dGUgYW5kIGF1dGhvcml6ZSANCiAgICAgICAgdGhlIE9QRVMgaW50ZXJtZWRpYXJ5IGJlZm9yZSBk
aXJlY3RpbmcgYW55IHRyYWZmaWMgdG8gaXQuIFRoZSANCiAgICAgICAgY29udGVudCBjb25zdW1l
ciBNVVNUIE5PVCBhY2NlcHQgYW55IChtb2RpZmllZCkgdHJhZmZpYywgd2hpY2ggaGFzIA0KICAg
ICAgICBiZWVuIHRyYW5zZm9ybWVkIGJ5IGFuIHVuYXV0aGVudGljYXRlZCBvciB1bmF1dGhvcml6
ZWQgZW50aXR5LiANCiAgICAgICAgDQogICAgIDMuMi4gT1BFUyBkZXZpY2Ugc3Bvb2ZpbmcgDQog
ICAgICAgICANCiAgICAgICAgVGhyZWF0OiBBIG1hbGljaW91cyBub2RlIGNvdWxkIHNlbmQgZmFs
c2UgaW5mb3JtYXRpb24gYWJvdXQgYW4gDQogICAgICAgIGludGVybWVkaWF0ZSBkZXZpY2UgbWFz
cXVlcmFkaW5nIGFzIGFuIE9QRVMgZGV2aWNlLiAgQWx0ZXJuYXRpdmVseSwgDQogICAgICAgIGRl
c3BpdGUgdGhlIHByZXNlbmNlIG9mIGEgZ2VudWluZSBPUEVTIGRldmljZSB3aGljaCBoYXMgYmVl
biANCiAgICAgICAgYXV0aGVudGljYXRlZCwgdGhlIGFjdHVhbCBkYXRhIHRyYW5zZm9ybWF0aW9u
IGNvdWxkIGJlIHBlcmZvcm1lZCBpbiANCiAgICAgICAgYSBtYWxpY2lvdXMgY2FsbC1vdXQgc2Vy
dmVyLiAgDQogICAgICAgIEVmZmVjdDogU2ltaWxhciB0byB0aGUgcHJldmlvdXMgY2FzZSwgdGhl
IG1hbGljaW91cyBkZXZpY2Ugd291bGQgYmUgDQogICAgICAgIGFibGUgdG8gZWF2ZXNkcm9wIG9u
IGFsbCB0cmFmZmljIChib3RoIGRhdGEgYW5kIHNpZ25hbGluZykgYmV0d2VlbiANCiAgICAgICAg
dGhlIGVuZC1zeXN0ZW1zLiBJbiBhZGRpdGlvbiwgdW5leHBlY3RlZCBhbmQgdW5kZXNpcmFibGUg
ZGF0YSANCiAgICAgICAgdHJhbnNmb3JtYXRpb24gYnkgdGhlIG1hbGljaW91cyBpbnRlcm1lZGlh
cnkgb3IgY2FsbC1vdXQgc2VydmVyIA0KICAgICAgICB3b3VsZCByZXN1bHQuIEZvciBleGFtcGxl
LCB0aGUgbWFsaWNpb3VzIG5vZGUgY291bGQgZm9yY2UgdGhlIA0KICAgICAgICBjb25zdW1lciBv
ciBwcm9kdWNlciB0byB1c2UgdGhlIHNlcnZpY2VzIG9mIGEgbWFsaWNpb3VzIE9QRVMgDQogICAg
ICAgIGludGVybWVkaWFyeSwgd2hpY2ggcmVuZGVycyB2ZXJ5IGV4cGVuc2l2ZSB0cmFuc2Zvcm1h
dGlvbiBzZXJ2aWNlcy4gDQogICAgICAgIEZpbmFsbHksIGEgbWFsaWNpb3VzIE9QRVMgaW50ZXJt
ZWRpYXJ5IG1heSByZWZ1c2UgdG8gZm9yd2FyZCB0aGUgDQogICAgICAgIHRyYWZmaWMsIHJlc3Vs
dGluZyBpbiBhIERlbmlhbC1vZi1TZXJ2aWNlIGF0dGFjay4gDQogICAgICAgICANCiAgICAgICAg
U29sdXRpb246IFRoZSBPUEVTIGludGVybWVkaWFyeSBkZXZpY2UgYW5kIHRoZSBhc3NvY2lhdGVk
IGNhbGwtb3V0IA0KICAgICAgICBzZXJ2ZXIgKGlmIGFueSkgTVVTVCBiZSBhdXRoZW50aWNhdGVk
IGFuZCBhdXRob3JpemVkIGJlZm9yZSBhbnkgDQogICAgICAgIG1lc3NhZ2VzIGFyZSBzZW50IHRo
cm91Z2ggaXQuIE5vdGljZSB0aGF0IHRoZSB0cmFuc2Zvcm1hdGlvbiBNQVkgDQogICAgICANCiAg
ICAgU3Jpbml2YXMsIENoYW4gICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjAwMiAgICAgICAgICAg
ICAgICAgICAgW1BhZ2UgNF0gDA0KICAgICBJbnRlcm5ldCBEcmFmdCAgICAgICAgIFNlY3VyaXR5
IFRocmVhdHMgZm9yIE9QRVMgICAgICAgICAgICAgIEp1bmUgMjAwMiANCiAgICAgIA0KICAgICAg
DQogICAgICAgIHJlcXVpcmUgbW9yZSB0aGFuIG9uZSBjYWxsLW91dCBzZXJ2ZXIsIGluIHdoaWNo
IGNhc2UsIGFsbCBvZiB0aGVtIA0KICAgICAgICBuZWVkIHRvIGJlIGF1dGhlbnRpY2F0ZWQuIA0K
ICAgICAgDQogICAgIDMuMy4gTWFsaWNpb3VzIG5vZGUgcGVyZm9ybXMgYSByZXBsYXkgYXR0YWNr
IA0KICAgICAgICAgDQogICAgICAgIFRocmVhdDogQSBtYWxpY2lvdXMgbm9kZSBjb3VsZCBwYXNz
aXZlbHkgZWF2ZXNkcm9wIG9uIG9uZSBvZiB0aGUgDQogICAgICAgIGNvbW11bmljYXRpb24gY2hh
bm5lbHMgYW5kIHJlcGxheSB0aGUgcmVjb3JkZWQgbWVzc2FnZSAoc2lnbmFsaW5nIG9yIA0KICAg
ICAgICBkYXRhKSBsYXRlci4gVGhlIHNpZ25hbGluZyByZXF1ZXN0IGZyb20gZWl0aGVyIHRoZSBw
cm9kdWNlciBvciB0aGUgDQogICAgICAgIGNvbnN1bWVyIHRvIHRoZSBPUEVTIGludGVybWVkaWFy
eSBpcyBvcGVuIHRvIHN1Y2ggYSBraW5kIG9mIHJlcGxheSANCiAgICAgICAgYXR0YWNrLiBBbHRl
cm5hdGl2ZWx5LCBhIG1hbGljaW91cyBub2RldGhhdCBzZXJ2ZXMgYXMgdGhlIE9QRVMgDQogICAg
ICAgIGludGVybWVkaWFyeSBmb3IgdHdvIGRpc3RpbmN0IGRhdGEgZmxvd3MgY291bGQgcmVwbGF5
IHRoZSBtZXNzYWdlIA0KICAgICAgICBmcm9tIG9uZSBkYXRhIGZsb3cgb250byBhbm90aGVyLiAN
CiAgICAgICAgIA0KICAgICAgICBFZmZlY3Q6IEZhbHNlIG9yIHNwdXJpb3VzIGFjdGlvbiBpcyBw
ZXJmb3JtZWQgYnkgdGhlIE9QRVMgZGV2aWNlIG9yIA0KICAgICAgICBjYWxsLW91dCBzZXJ2ZXIu
IEEgZmFsc2UgdHJhbnNmb3JtYXRpb24gY291bGQgYmUgcGVyZm9ybWVkIGJ5IHRoZSANCiAgICAg
ICAgT1BFUyBkZXZpY2UgYnkgcmVwbGF5aW5nIGEgdHJhbnNmb3JtYXRpb24gcmVxdWVzdCBpc3N1
ZWQgYnkgdGhlIA0KICAgICAgICBjb25zdW1lciBvbiBhIHByZXZpb3VzIG9jY2FzaW9uLiBJbiBh
ZGRpdGlvbiwgdGhlIHRyYW5zZm9ybWVkIA0KICAgICAgICBjb250ZW50IGNvdWxkIGJlIHJlcGxh
eWVkIHRvIHRoZSBjb25zdW1lciBhcyBnZW51aW5lIGNvbnRlbnQuIA0KICAgICAgICAgDQogICAg
ICAgIFNvbHV0aW9uOiAgQ2FyZSwgaW4gdGhlIGZvcm0gb2Ygc2VxdWVuY2UgbnVtYmVycywgb3Ig
b3RoZXIgDQogICAgICAgIHRlY2huaXF1ZXMsIE1VU1QgYmUgdGFrZW4gdG8gcHJldmVudCByZXBs
YXkgYXR0YWNrcy4gQXV0aGVudGljYXRpb24gDQogICAgICAgIG9mIE9QRVMgaW50ZXJtZWRpYXJp
ZXMgaXMgcmVxdWlyZWQgc3VjaCB0aGF0IG1hbGljaW91cyBPUEVTIGRldmljZXMgDQogICAgICAg
IHdpbGwgbm90IGJlIHVzZWQsIHRoZXJlYnkgcmVkdWNpbmcgdGhlIHBvc3NpYmlsaXR5IG9mIGNv
bnRlbnQgDQogICAgICAgIHJlcGxheS4gDQogICAgICAgICANCiAgICAgMy40LiBSZS1lc3RhYmxp
c2hpbmcgZW5kLWRldmljZSAtIE9QRVMgZGV2aWNlIHNlY3VyaXR5IGR1cmluZyBmYWlsb3ZlciAN
CiAgICAgICAgIA0KICAgICAgICBUaHJlYXQ6IEVuZC1kZXZpY2UgKHByb2R1Y2VyIG9yIGNvbnN1
bWVyKSBmYWlscyBvdmVyIGZyb20gT1BFUyANCiAgICAgICAgaW50ZXJtZWRpYXJ5IEEgdG8gT1BF
UyBpbnRlcm1lZGlhcnkgQi4gQSB0cnVzdCByZWxhdGlvbnNoaXAgYmV0d2VlbiANCiAgICAgICAg
dGhlIGVuZC1kZXZpY2UgYW5kIEEgd2lsbCBub3QgYXV0b21hdGljYWxseSB0cmFuc2xhdGUgaW50
byB0aGUgc2FtZSANCiAgICAgICAgcmVsYXRpb25zaGlwIGV4aXN0aW5nIGJldHdlZW4gdGhlIGVu
ZC1kZXZpY2UgYW5kIEIuIA0KICAgICAgICAgDQogICAgICAgIEVmZmVjdDogSWYgdGhlcmUgd2Fz
IGEgdHJ1c3QgcmVsYXRpb25zaGlwIGludm9sdmluZyBhIHNlY3VyaXR5IA0KICAgICAgICBjb250
ZXh0IGJldHdlZW4gdGhlIGVuZC1kZXZpY2UgYW5kIEEsIHRoZSBlcXVpdmFsZW50IHRydXN0IA0K
ICAgICAgICByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgZW5kLWRldmljZSBhbmQgQiB3aWxsIG5v
dCBleGlzdCBpbiB0aGUgDQogICAgICAgIGV2ZW50IG9mIGEgZmFpbG92ZXIgZnJvbSBBIHRvIEIu
IFRoZSBhc3N1bXB0aW9uIG9mIHN1Y2ggYSB0cnVzdCANCiAgICAgICAgcmVsYXRpb25zaGlwIG9w
ZW5zIHVwIHNlY3VyaXR5IGhvbGVzIGZvciBtYWxpY2lvdXMgT1BFUyANCiAgICAgICAgaW50ZXJt
ZWRpYXJpZXMgdG8gcGVyZm9ybSBhbGwga2luZHMgb2YgYXR0YWNrcy4gDQogICAgICAgICANCiAg
ICAgICAgU29sdXRpb246IEVpdGhlciBub3RpZnkgdGhlIGFwcGxpY2F0aW9uIHdoZW4gZmFpbG92
ZXIgb2NjdXJzIHNvIHRoYXQgDQogICAgICAgIHRoZSBhcHBsaWNhdGlvbiBNQVkgdGFrZSBhcHBy
b3ByaWF0ZSBhY3Rpb24gdG8gZXN0YWJsaXNoIGEgdHJ1c3QgDQogICAgICAgIHJlbGF0aW9uc2hp
cCBiZXR3ZWVuIHRoZSBlbmQtZGV2aWNlIGFuZCBCIG9yIHJlZXN0YWJsaXNoIHRoZSANCiAgICAg
ICAgc2VjdXJpdHkgY29udGV4dCB0cmFuc3BhcmVudGx5LiANCiAgICAgICAgIA0KICAgICAzLjUu
IE1lc3NhZ2UgSW50ZWdyaXR5IA0KICAgICAgICAgDQogICAgICAgIFRocmVhdDogTWVzc2FnZSBm
bG93IHRocm91Z2ggdGhlIE9QRVMgZGV2aWNlIGlzIGNvcnJ1cHRlZC4gQnkgYmVpbmcgDQogICAg
ICAgIGNvcnJ1cHRlZCwgdGhlIGltcGxpY2F0aW9uIGlzIHRoYXQsIGEgbWVzc2FnZSwgd2hpY2gg
aGFzIGJlZW4gDQogICAgICAgIHN1YmplY3QgdG8gdW5hdXRob3JpemVkIG1vZGlmaWNhdGlvbiBw
cmlvciB0byB0aGUgT1BFUyBpbnRlcm1lZGlhcnksIA0KICAgICAgICBpcyBpbnB1dHRlZCBpbnRv
IHRoZSBPUEVTIGludGVybWVkaWFyeSAob3IgY2FsbC1vdXQgc2VydmVyKS4gVGhlIA0KICAgICAg
ICBtb2RpZmljYXRpb24gY2FuIGJlIG9uIHRoZSBzaWduYWxpbmcgaW5mb3JtYXRpb24gcmVsYXRl
ZCB0byB0aGUgDQogICAgICAgIGFjdGlvbnMgdGhlIE9QRVMgZGV2aWNlIG5lZWRzIHRvIHBlcmZv
cm07IG9yIGl0IGNhbiBiZSBvbiB0aGUgDQogICAgICAgIGNvbnRlbnRzIHRoYXQgbmVlZCB0byBi
ZSB0cmFuc2Zvcm1lZC4gDQogICAgICANCiAgICAgU3Jpbml2YXMsIENoYW4gICAgICAgIEV4cGly
ZXMgRGVjZW1iZXIgMjAwMiAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNV0gDA0KICAgICBJbnRl
cm5ldCBEcmFmdCAgICAgICAgIFNlY3VyaXR5IFRocmVhdHMgZm9yIE9QRVMgICAgICAgICAgICAg
IEp1bmUgMjAwMiANCiAgICAgIA0KICAgICAgDQogICAgICAgICANCiAgICAgICAgRWZmZWN0OiBD
b3JydXB0ZWQgaW5mb3JtYXRpb24gaXMgcmVjZWl2ZWQgd2hpY2ggY2F1c2VzIHRoZSBPUEVTIA0K
ICAgICAgICBkZXZpY2UgdG8gZWl0aGVyIHRyYW5zZm9ybSB0aGUgY29udGVudCBpbiBhIHdyb25n
IHdheSwgb3IgdHJhbnNmb3JtIA0KICAgICAgICB0aGUgd3JvbmcgY29udGVudCwgZ2VuZXJhdGlu
ZyBhIHdyb25nIG91dHB1dC4gDQogICAgICAgICANCiAgICAgICAgU29sdXRpb246IEludGVncml0
eSBtZWNoYW5pc20gaXMgbmVlZGVkIHRvIHByb3RlY3QgYm90aCB0aGUgYWN0aW9ucyANCiAgICAg
ICAgc3BlY2lmaWVkIGFzIHdlbGwgYXMgdGhlIGNvbnRlbnRzIG9mIGFsbCB0aGUgT1BFUyBtZXNz
YWdlcy4gVGhlc2UgDQogICAgICAgIGNvdWxkIGluY2x1ZGUgaGFzaGluZyBmdW5jdGlvbnMsIGZv
ciBpbnN0YW5jZS4gDQogICAgICANCiAgICAgMy42LiBEYXRhIENvbmZpZGVudGlhbGl0eSANCiAg
ICAgICAgIA0KICAgICAgICBUaHJlYXQ6IEFuIGVhdmVzZHJvcHBlciBpcyB0eXBpY2FsbHkgY2Fw
YWJsZSBvZiBzbm9vcGluZyBvbiBmaWVsZHMgDQogICAgICAgIHdpdGhpbiBtZXNzYWdlcyBpbiB0
cmFuc2l0LiBVc2luZyB2YXJpb3VzIGVhdmVzZHJvcHBpbmcgdGVjaG5pcXVlcywgDQogICAgICAg
IGhlIG1heSBiZSBhYmxlIHRvIGdhcm5lciB2YXJpb3VzIGtpbmRzIG9mIGluZm9ybWF0aW9uIGlu
Y2x1ZGluZyANCiAgICAgICAgdG9wb2xvZ3kvbG9jYXRpb24vSVAgYWRkcmVzc2VzIGV0Yy4gdGhh
dCBtYXkgbm90IGJlIGRlc2lyYWJsZSB0byANCiAgICAgICAgZGl2dWxnZS4gSGUgYWxzbyBtYXkg
YmUgYWJsZSB0byBlYXZlc2Ryb3Agb24gdGhlIGNvbnRlbnQgbWVzc2FnZXMgDQogICAgICAgIGJl
aW5nIGRlbGl2ZXJlZCB0byB0aGUgY29uc3VtZXIuIFRoZSBkZWxpdmVyeSBvZiB0aGUgc2hhcmVk
IA0KICAgICAgICBlbmNyeXB0aW9uIGtleXMgdG8gdGhlIE9QRVMgaW50ZXJtZWRpYXJ5IGlzIHN1
YmplY3QgdG8gdGhlIHRocmVhdCBvZiANCiAgICAgICAgYmVpbmcgZWF2ZXNkcm9wcGVkIG9uIGJ5
IGEgbWFsaWNpb3VzIGVudGl0eS4gDQogICAgICAgICANCiAgICAgICAgRWZmZWN0OiBJbmZvcm1h
dGlvbiB0aGF0IHNlc3Npb24gcGFydGljaXBhbnRzIG9yIGFuIGFkbWluaXN0cmF0b3IgZG8gDQog
ICAgICAgIG5vdCB3aXNoIHRvIGRpdnVsZ2UgaXMgZGl2dWxnZWQuIElmIHNoYXJlZCBlbmNyeXB0
aW9uIGtleXMgYXJlIA0KICAgICAgICBjb21wcm9taXNlZCBkdXJpbmcga2V5IGRpc3RyaWJ1dGlv
biwgYXR0YWNrZXJzIHdpbGwgYmUgYWJsZSB0byANCiAgICAgICAgZGVjcnlwdCBlbmNyeXB0ZWQg
Y29udGVudC4gIA0KICAgICAgICBTb2x1dGlvbjogRGF0YSBjb25maWRlbnRpYWxpdHkgc2Vydmlj
ZSBNVVNUIGJlIHByb3Zpc2lvbmVkIHVzaW5nIA0KICAgICAgICB2YXJpb3VzIGtpbmRzIG9mIGVu
Y3J5cHRpb24uIFRoaXMgY291bGQgYmUgY2FycmllZCBvdXQgdXNpbmcgZWl0aGVyIA0KICAgICAg
ICBhIHNoYXJlZCBrZXkgb3IgUEtJLCBmb3IgaW5zdGFuY2UuIFNwZWNpYWwgY2FyZSBuZWVkcyB0
byBiZSB0YWtlbiBpbiANCiAgICAgICAgdGhlIGRlbGl2ZXJ5IG9mIHRoZSBrZXkgaW5mb3JtYXRp
b24gdG8gdGhlIE9QRVMgaW50ZXJtZWRpYXJ5IGFuZCB0aGUgDQogICAgICAgIGNhbGxvdXQgc2Vy
dmVyIChpZiBwcmVzZW50KS4gDQogICAgICANCiAgICAgMy43LiBEZW5pYWwtb2YtU2VydmljZSAo
RG9TKSANCiAgICAgICAgIA0KICAgICAgICBUaHJlYXQ6IEEgaG9zdGlsZSBvciBtYWxpY2lvdXMg
bm9kZSBNQVkgYmUgYWJsZSB0byBibG9jayBhbGwgdHJhZmZpYyANCiAgICAgICAgb24gYW4gdW5w
cm90ZWN0ZWQgbGluay4gVGhlIGRhdGEgdHJhZmZpYyBkZXN0aW5lZCBmb3IgdGhlIE9QRVMgDQog
ICAgICAgIGludGVybWVkaWFyeSAob3IgY2FsbC1vdXQgc2VydmVyKSBNQVkgTk9UIGJlIGFibGUg
dG8gdXNlIHRoZSANCiAgICAgICAgc2VydmljZXMgb2YgdGhlIE9QRVMgZGV2aWNlLiBUaGUgRG9T
IE1BWSBiZSBhY2hpZXZlZCBieSBwcmV2ZW50aW5nIA0KICAgICAgICB0aGUgZGF0YSB0cmFmZmlj
IGZyb20gcmVhY2hpbmcgdGhlIGludGVybWVkaWFyeSBvciB0aGUgY2FsbC1vdXQgDQogICAgICAg
IHNlcnZlci4gQWx0ZXJuYXRpdmVseSwgdGhlIGludGVybWVkaWFyeSBvciB0aGUgY2FsbC1vdXQg
c2VydmVyIGNhbiANCiAgICAgICAgYmUgb3ZlcmxvYWRlZCBieSBzcHVyaW91cyBzZXJ2aWNlIHJl
cXVlc3RzIGlzc3VlZCBieSBhIG1hbGljaW91cyANCiAgICAgICAgbm9kZSwgd2hpY2ggZGVuaWVz
IHRoZSBsZWdhbCBkYXRhIHRyYWZmaWMgdGhlIG5lY2Vzc2FyeSByZXNvdXJjZXMgdG8gDQogICAg
ICAgIHJlbmRlciBzZXJ2aWNlLiBUaGUgcmVzb3VyY2VzIGluY2x1ZGUgQ1BVIGN5Y2xlcywgbWVt
b3J5LCBuZXR3b3JrIA0KICAgICAgICBpbnRlcmZhY2VzLCBldGMuIEluIGFkZGl0aW9uLCBhIG1h
bGljaW91cyBub2RlIHRoYXQgc3VjY2Vzc2Z1bGx5IA0KICAgICAgICBzcG9vZnMgYXMgYW4gT1BF
UyBpbnRlcm1lZGlhcnkgKG9yIGNhbGwtb3V0IHNlcnZlcikgY2FuIGxhdW5jaCBEb1MgDQogICAg
ICAgIGF0dGFja3Mgc2ltcGx5IGJ5IG5vdCBmb3J3YXJkaW5nIHRoZSBsZWdpdGltYXRlIHRyYWZm
aWMgdG8gdGhlIA0KICAgICAgICBjb250ZW50IGNvbnN1bWVycy4gQSBEZW5pYWwtb2YtU2Vydmlj
ZSBhdHRhY2sgY2FuIGJlIHNlbGVjdGl2ZSwgDQogICAgICAgIGdlbmVyaWMgb3IgcmFuZG9tIGlu
IHRlcm1zIG9mIHdoaWNoIGNvbW11bmljYXRpb24gc3RyZWFtcyBhcmUgDQogICAgICAgIGFmZmVj
dGVkIFtNSVAtRE9TXS4gDQogICAgICAgICANCiAgICAgICAgRGlzdHJpYnV0ZWQgRG9TIGlzIGFs
c28gcG9zc2libGUgd2hlbiBhbiBhdHRhY2tlciBzdWNjZXNzZnVsbHkgDQogICAgICAgIGRpcmVj
dHMgbXVsdGlwbGUgbm9kZXMgb3ZlciB0aGUgbmV0d29yayB0byBpbml0aWF0ZSBzcHVyaW91cyBz
ZXJ2aWNlIA0KICAgICAgICByZXF1ZXN0cyB0byBhbiBPUEVTIGludGVybWVkaWFyeSAob3IgY2Fs
bC1vdXQgc2VydmVyKSBzaW11bHRhbmVvdXNseSANCiAgICAgICAgTUlQLURPU10uIA0KICAgICAg
ICAgDQogICAgICANCiAgICAgU3Jpbml2YXMsIENoYW4gICAgICAgIEV4cGlyZXMgRGVjZW1iZXIg
MjAwMiAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNl0gDA0KICAgICBJbnRlcm5ldCBEcmFmdCAg
ICAgICAgIFNlY3VyaXR5IFRocmVhdHMgZm9yIE9QRVMgICAgICAgICAgICAgIEp1bmUgMjAwMiAN
CiAgICAgIA0KICAgICAgDQogICAgICAgIEVmZmVjdDogTGVnYWwgZGF0YSB0cmFmZmljIGlzIHVu
YWJsZSB0byBhY3F1aXJlIHRoZSBzZXJ2aWNlcyBvZiB0aGUgDQogICAgICAgIE9QRVMgaW50ZXJt
ZWRpYXJ5IChvciBjYWxsLW91dCBzZXJ2ZXIpIHRvIGFjaGlldmUgdGhlIGRlc2lyZWQgDQogICAg
ICAgIHRyYW5zZm9ybWF0aW9uLiANCiAgICAgICAgIA0KICAgICAgICBTb2x1dGlvbjogTWFsaWNp
b3VzIGRhdGEgdHJhZmZpYyBlbWFuYXRpbmcgZnJvbSBwYXJ0aWN1bGFyIHN1c3BlY3QgDQogICAg
ICAgIHBvcnRzIG9yIElQIGFkZHJlc3NlcyBTSE9VTEQgYmUgZGVuaWVkIGFjY2VzcyB0byB0aGUg
T1BFUyANCiAgICAgICAgaW50ZXJtZWRpYXJ5LiAgDQogICAgICANCiAgICAgMy44LkF1dGhvcml6
ZWQgZW50aXR5IGxhdGVyIHJlcHVkaWF0ZXMgYSByZXF1ZXN0IA0KICAgICAgICAgDQogICAgICAg
IFRocmVhdDogQW4gZW50aXR5IChwcm9kdWNlciBvciBjb25zdW1lcikgdGhhdCBpcyBhdXRob3Jp
emVkIHRvIG1ha2UgDQogICAgICAgIGEgY2VydGFpbiByZXF1ZXN0IG9mIHRoZSBPUEVTIGludGVy
bWVkaWFyeSBjbGFpbXMsIGxhdGVyLCB0aGF0IGl0IA0KICAgICAgICBkaWQgbm90IG1ha2UgdGhh
dCByZXF1ZXN0LiANCiAgICAgICAgIA0KICAgICAgICBFZmZlY3Q6IFRoZSBlbnRpdHkgdGhhdCBy
ZXB1ZGlhdGVzIGEgdmFsaWQgcmVxdWVzdCBmb3IgDQogICAgICAgIHRyYW5zZm9ybWF0aW9uIGJ5
IHRoZSBPUEVTIGludGVybWVkaWFyeSBNQVkgYmUgaGVsZCBsaWFibGUgZm9yIGFza2VkIA0KICAg
ICAgICBmb3IgY2hhbmdlcyB0byB0aGUgZGF0YSBmbG93LiAgDQogICAgICAgICANCiAgICAgICAg
UmVxdWlyZW1lbnQ6IE5vbi1yZXB1ZGlhdGlvbiBvZiByZXF1ZXN0cyBmb3IgdHJhbnNmb3JtYXRp
b24gb2YgYSANCiAgICAgICAgZGF0YSBmbG93IGJ5IGFuIE9QRVMgaW50ZXJtZWRpYXJ5IG9yIGEg
Y2FsbC1vdXQgc2VydmVyIG5lZWRzIHRvIGJlIA0KICAgICAgICBwcm92aWRlZC4gVGhpcyBjb3Vs
ZCBiZSBhY2NvbXBsaXNoZWQgYnksIGZvciBpbnN0YW5jZSwgdXNlIG9mIA0KICAgICAgICBwcml2
YXRlIGtleXMgaW4gZW5jcnlwdGluZyB0aGUgcmVxdWVzdCBmb3IgYSB0cmFuc2Zvcm1hdGlvbiBz
ZXJ2aWNlLiANCiAgICAgIA0KICAgICA0LiBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIA0K
ICAgICAgICAgDQogICAgICAgIFRoZSBhdXRob3JzIGFyZSBub3QgYXdhcmUgb2YgYW55IGludGVs
bGVjdHVhbCBwcm9wZXJ0eSByaWdodCBpc3N1ZXMgDQogICAgICAgIHBlcnRhaW5pbmcgdG8gdGhp
cyBkb2N1bWVudC4gDQogICAgICAgICANCiAgICAgNS4gUmVmZXJlbmNlcyANCiAgICAgICAgIA0K
ICAgICAgICBbT1BFUy1TQ0VORV0gTWNIZW5yeSwgUy4sIGV0LiBhbCwgIk9QRVMgU2NlbmFyaW9z
IGFuZCBVc2UgQ2FzZXMiLCANCiAgICAgICAgICAgICAgICAgICBJbnRlcm5ldC1EcmFmdCBUQkQs
IE1heSAyMDAyLiAgDQogICAgICAgICANCiAgICAgICAgW1JGQzMyMzhdICBGbG95ZCwgUy4gYW5k
IEwuIERhaWdsZSwgIklBQiBBcmNoaXRlY3R1cmFsIGFuZCBQb2xpY3kgDQogICAgICAgICAgICAg
ICAgICAgQ29uc2lkZXJhdGlvbnMgZm9yIE9wZW4gUGx1Z2dhYmxlIEVkZ2UgU2VydmljZXMiLCBS
RkMgDQogICAgICAgICAgICAgICAgICAgMzIzOCwgSmFudWFyeSAyMDAyLiANCiAgICAgICAgIA0K
ICAgICAgICBbT1BFUy1DQUxMT1VUXSBCZWNrLCBBLiwgZXQuIGFsLCAiUmVxdWlyZW1lbnRzIGZv
ciBPUEVTIENhbGxvdXQgDQogICAgICAgICAgICAgICAgICAgUHJvdG9jb2xzLCIgd29yayBpbiBw
cm9ncmVzcywgTWF5IDIwMDIsIDxkcmFmdC1pZXRmLW9wZXMtDQogICAgICAgICAgICAgICAgICAg
cHJvdG9jb2wtcmVxcy0wMD4uIA0KICAgICAgICAgDQogICAgIAlbTUlQLURPU10gTmlrYW5kZXIs
IFAuLCBldC4gYWwsICJUaHJlYXQgTW9kZWxzIGludHJvZHVjZWQgYnkgTW9iaWxlIA0KICAgICAJ
CSAgSVB2NiBhbmQgUmVxdWlyZW1lbnRzIGZvciBTZWN1cml0eSBpbiBNb2JpbGUgSVB2NiIsIHdv
cmsgaW4gcHJvZ3Jlc3MsIA0KICAgICAJCSAgRGVjZW1iZXIgMjAwMSwgPGRyYWZ0LXRlYW0tbW9i
aWxlaXAtbWlwdjYtc2VjLXJlcXRzLTAwLnR4dD4uICANCiAgICAgICAgIA0KICAgICA2LiBBdXRo
b3JzJyBBZGRyZXNzZXMgDQogICAgICANCiAgICAgICAgQmluZGlnbmF2aWxlIFMuIFNyaW5pdmFz
IA0KICAgICAgICBUYXQgQ2hhbiANCiAgICAgICAgIA0KICAgICAgICBOb2tpYSBSZXNlYXJjaCBD
ZW50ZXIgDQogICAgICANCiAgICAgU3Jpbml2YXMsIENoYW4gICAgICAgIEV4cGlyZXMgRGVjZW1i
ZXIgMjAwMiAgICAgICAgICAgICAgICAgICAgW1BhZ2UgN10gDA0KICAgICBJbnRlcm5ldCBEcmFm
dCAgICAgICAgIFNlY3VyaXR5IFRocmVhdHMgZm9yIE9QRVMgICAgICAgICAgICAgIEp1bmUgMjAw
MiANCiAgICAgIA0KICAgICAgDQogICAgICAgIDUgV2F5c2lkZSBSb2FkIA0KICAgICAgICBCdXJs
aW5ndG9uLCBNQSAwMTgwMyANCiAgICAgICAgVVNBIA0KICAgICAgIA0KICAgICAgICBFbWFpbDog
e2JpbmRpZ25hdmlsZS5zcmluaXZhcyx0YXQuY2hhbn1Abm9raWEuY29tIA0KICAgICAgDQogICAg
ICAgIDEuIEFic3RyYWN0Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4xIA0KICAgICAgICAyLiBJbnRyb2R1Y3Rpb24uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMiANCiAgICAgICAgMy4gVGhyZWF0
cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
LjMgDQogICAgICAgICAgIDMuMS4gT1BFUyBkZXZpY2UgZmFsc2UgcmVnaXN0cmF0aW9uL2RlcmVn
aXN0cmF0aW9uLi4uLi4uLi4uLi4uLi40IA0KICAgICAgICAgICAzLjIuIE9QRVMgZGV2aWNlIHNw
b29maW5nLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNCANCiAgICAgICAg
ICAgMy4zLiBNYWxpY2lvdXMgbm9kZSBwZXJmb3JtcyBhIHJlcGxheSBhdHRhY2suLi4uLi4uLi4u
Li4uLi4uLi4uLjUgDQogICAgICAgICAgIDMuNC4gUmUtZXN0YWJsaXNoaW5nIGVuZC1kZXZpY2Ug
LSBPUEVTIGRldmljZSBzZWN1cml0eSBkdXJpbmcgDQogICAgICAgICAgIGZhaWxvdmVyLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi41IA0KICAg
ICAgICAgICAzLjUuIE1lc3NhZ2UgSW50ZWdyaXR5Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uNSANCiAgICAgICAgICAgMy42LiBEYXRhIENvbmZpZGVudGlhbGl0eS4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjYgDQogICAgICAgICAgIDMuNy4g
RGVuaWFsLW9mLVNlcnZpY2UgKERvUykuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li42IA0KICAgICAgICAgICAzLjguIEF1dGhvcml6ZWQgZW50aXR5IGxhdGVyIHJlcHVkaWF0ZXMg
YSByZXF1ZXN0Li4uLi4uLi4uLi4uLi4uNyANCiAgICAgICAgNC4gSW50ZWxsZWN0dWFsIFByb3Bl
cnR5IFJpZ2h0cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjcgDQogICAgICAg
IDUuIFJlZmVyZW5jZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi43IA0KICAgICAgICA2LiBBdXRob3JzJyBBZGRyZXNzZXMuLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNyANCiAgICAgICAgRnVsbCBDb3B5cmln
aHQgU3RhdGVtZW50Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjgg
DQogICAgICAgICAgICANCiAgICAgRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50IA0KICAgICAgICAg
ICAgICAgDQogICAgICAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDIp
LiAgQWxsIFJpZ2h0cyBSZXNlcnZlZC4gICAgICAgICANCiAgICAgICAgVGhpcyBkb2N1bWVudCBh
bmQgdHJhbnNsYXRpb25zIG9mIGl0IG1heSBiZSBjb3BpZWQgYW5kIGZ1cm5pc2hlZCB0byANCiAg
ICAgICAgb3RoZXJzLCBhbmQgZGVyaXZhdGl2ZSB3b3JrcyB0aGF0IGNvbW1lbnQgb24gb3Igb3Ro
ZXJ3aXNlIGV4cGxhaW4gaXQgDQogICAgICAgIG9yIGFzc2lzdCBpbiBpdHMgaW1wbGVtZW50YXRp
b24gbWF5IGJlIHByZXBhcmVkLCBjb3BpZWQsIHB1Ymxpc2hlZCANCiAgICAgICAgYW5kIGRpc3Ry
aWJ1dGVkLCBpbiB3aG9sZSBvciBpbiBwYXJ0LCB3aXRob3V0IHJlc3RyaWN0aW9uIG9mIGFueSAN
CiAgICAgICAga2luZCwgcHJvdmlkZWQgdGhhdCB0aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBh
bmQgdGhpcyBwYXJhZ3JhcGggDQogICAgICAgIGFyZSBpbmNsdWRlZCBvbiBhbGwgc3VjaCBjb3Bp
ZXMgYW5kIGRlcml2YXRpdmUgd29ya3MuICBIb3dldmVyLCB0aGlzIA0KICAgICAgICBkb2N1bWVu
dCBpdHNlbGYgbWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFzIGJ5IHJlbW92
aW5nIA0KICAgICAgICB0aGUgY29weXJpZ2h0IG5vdGljZSBvciByZWZlcmVuY2VzIHRvIHRoZSBJ
bnRlcm5ldCBTb2NpZXR5IG9yIG90aGVyIA0KICAgICAgICBJbnRlcm5ldCBvcmdhbml6YXRpb25z
LCBleGNlcHQgYXMgbmVlZGVkIGZvciB0aGUgcHVycG9zZSBvZiANCiAgICAgICAgZGV2ZWxvcGlu
ZyBJbnRlcm5ldCBzdGFuZGFyZHMgaW4gd2hpY2ggY2FzZSB0aGUgcHJvY2VkdXJlcyBmb3IgDQog
ICAgICAgIGNvcHlyaWdodHMgZGVmaW5lZCBpbiB0aGUgSW50ZXJuZXQgU3RhbmRhcmRzIHByb2Nl
c3MgbXVzdCBiZSANCiAgICAgICAgZm9sbG93ZWQsIG9yIGFzIHJlcXVpcmVkIHRvIHRyYW5zbGF0
ZSBpdCBpbnRvIGxhbmd1YWdlcyBvdGhlciB0aGFuIA0KICAgICAgICBFbmdsaXNoLiANCiAgICAg
ICAgICAgICAgIA0KICAgICAgICBUaGUgbGltaXRlZCBwZXJtaXNzaW9ucyBncmFudGVkIGFib3Zl
IGFyZSBwZXJwZXR1YWwgYW5kIHdpbGwgbm90IGJlIA0KICAgICAgICByZXZva2VkIGJ5IHRoZSBJ
bnRlcm5ldCBTb2NpZXR5IG9yIGl0cyBzdWNjZXNzb3JzIG9yIGFzc2lnbnMuIA0KICAgICAgICAg
ICAgICAgDQogICAgICAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWlu
ZWQgaGVyZWluIGlzIHByb3ZpZGVkIG9uIGFuIA0KICAgICAgICAiQVMgSVMiIGJhc2lzIGFuZCBU
SEUgSU5URVJORVQgU09DSUVUWSBBTkQgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HIA0KICAgICAg
ICBUQVNLIEZPUkNFIERJU0NMQUlNUyBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVE
LCBJTkNMVURJTkcgDQogICAgICAgIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhB
VCBUSEUgVVNFIE9GIFRIRSBJTkZPUk1BVElPTiANCiAgICAgICAgSEVSRUlOIFdJTEwgTk9UIElO
RlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQgV0FSUkFOVElFUyBPRiANCiAgICAgICAg
TUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiANCiAg
ICAgICAgICAgICAgIA0KICAgICAgICBBY2tub3dsZWRnZW1lbnQgDQogICAgICAgICAgICAgICAN
CiAgICAgIA0KICAgICBTcmluaXZhcywgQ2hhbiAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyMDAy
ICAgICAgICAgICAgICAgICAgICBbUGFnZSA4XSAMDQogICAgIEludGVybmV0IERyYWZ0ICAgICAg
ICAgU2VjdXJpdHkgVGhyZWF0cyBmb3IgT1BFUyAgICAgICAgICAgICAgSnVuZSAyMDAyIA0KICAg
ICAgDQogICAgICANCiAgICAgICAgRnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0b3IgZnVuY3Rpb24g
aXMgY3VycmVudGx5IHByb3ZpZGVkIGJ5IHRoZSANCiAgICAgICAgSW50ZXJuZXQgU29jaWV0eS4g
DQogICAgICANCiAgICAgU3Jpbml2YXMsIENoYW4gICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjAw
MiAgICAgICAgICAgICAgICAgICAgW1BhZ2UgOV0gDA==

------_=_NextPart_001_01C21B25.59B3A974--


From owner-ietf-openproxy@mail.imc.org  Tue Jun 25 07:30:42 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00713
	for <opes-archive@ietf.org>; Tue, 25 Jun 2002 07:30:41 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5PB4WI11898
	for ietf-openproxy-bks; Tue, 25 Jun 2002 04:04:32 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PB4Vw11892
	for <ietf-openproxy@imc.org>; Tue, 25 Jun 2002 04:04:31 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29720;
	Tue, 25 Jun 2002 07:03:49 -0400 (EDT)
Message-Id: <200206251103.HAA29720@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-scenarios-00.txt
Date: Tue, 25 Jun 2002 07:03:49 -0400
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF.

	Title		: OPES Use Cases and Deployment Scenarios
	Author(s)	: A. Barbir et al.
	Filename	: draft-ietf-opes-scenarios-00.txt
	Pages		: 18
	Date		: 24-Jun-02
	
This memo provides a discussion of use cases and deployment scenarios
for Open Pluggable Edge Services (OPES).  The work examines services
that could be performed  to requests and/or responses.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-opes-scenarios-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-opes-scenarios-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-opes-scenarios-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020624144118.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-opes-scenarios-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-opes-scenarios-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020624144118.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-ietf-openproxy@mail.imc.org  Tue Jun 25 19:36:25 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03330
	for <opes-archive@ietf.org>; Tue, 25 Jun 2002 19:36:24 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5PNBQ521277
	for ietf-openproxy-bks; Tue, 25 Jun 2002 16:11:26 -0700 (PDT)
Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PNBNw21264
	for <ietf-openproxy@imc.org>; Tue, 25 Jun 2002 16:11:23 -0700 (PDT)
Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215])
 by mtaout04.icomcast.net
 (iPlanet Messaging Server 5.1 HotFix 0.8 (built May 13 2002))
 with ESMTP id <0GYA00FOMB2UAD@mtaout04.icomcast.net> for
 ietf-openproxy@imc.org; Tue, 25 Jun 2002 19:11:19 -0400 (EDT)
Date: Tue, 25 Jun 2002 19:11:18 -0400
From: Markus Hofmann <markus@mhof.com>
Subject: [Fwd: 54th IETF Meeting - Yokohama, Japan]
To: OPES Group <ietf-openproxy@imc.org>
Message-id: <3D18F896.90706@mhof.com>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_RLXKZDjYkcLPiTMB/n/Azg)"
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a)
 Gecko/20020611
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This is a multi-part message in MIME format.

--Boundary_(ID_RLXKZDjYkcLPiTMB/n/Azg)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7BIT

Just FYI - OPES is scheduled for Tuesday 7/16/2002, 17:00-18:00.

-Markus

--Boundary_(ID_RLXKZDjYkcLPiTMB/n/Azg)
Content-type: message/rfc822; name="54th IETF Meeting - Yokohama, Japan"

Return-path: <ietf-123-owner@loki.ietf.org>
Received: from www.fastmail.fm (server1.internal [10.202.2.132])
	by server2.fastmail.fm (Cyrus v2.1.3) with LMTP; Tue,
 25 Jun 2002 17:01:25 -0500
Received: from www.fastmail.fm ([unix socket])
	by www.fastmail.fm (Cyrus v2.1.3) with LMTP; Tue, 25 Jun 2002 17:01:26 -0500
Received: from www.fastmail.fm (localhost [127.0.0.1])
	by localhost.localdomain (Postfix) with ESMTP id E68946DA0D	for
 <hofmann@fastmail.fm>; Tue, 25 Jun 2002 17:01:25 -0500 (CDT)
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
	by www.fastmail.fm (Postfix) with ESMTP id 897006D9D3	for <markus@MHOF.COM>;
 Tue, 25 Jun 2002 17:01:25 -0500 (CDT)
Received: (from adm@localhost)	by loki.ietf.org (8.9.1b+Sun/8.9.1)
 id QAA06633	for ietf-123-outbound.03@ietf.org; Tue,
 25 Jun 2002 16:55:00 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
	by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id QAA06610	for
 <all-ietf@loki.ietf.org>; Tue, 25 Jun 2002 16:53:50 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28327	for <all-ietf>; Tue,
 25 Jun 2002 16:53:06 -0400 (EDT)
Date: Tue, 25 Jun 2002 16:53:05 -0400
From: agenda@ietf.org
Subject: 54th IETF Meeting - Yokohama, Japan
Sender: dinaras@cnri.reston.va.us
To: IETF-Announce: ;
Message-id: <200206252053.QAA28327@ietf.org>
X-Sieve: CMU Sieve 2.1
X-Mail-from: ietf-123-owner@loki.ietf.org
X-Delivered-to: <hofmann@fastmail.fm>
X-Spam-score: 2.7
MIME-Version: 1.0
Content-Transfer-Encoding: 7BIT

Please find below the agenda of the 54th IETF Meeting
which will be held on July 14-19 in Yokohama, Japan.

For more information on the meeting and hotel accommodation, 
please visit  http://www.ietf.org/meetings/IETF-54.html.

+++

Agenda of the Fifty-fourth IETF
July 14-19, 2002

SUNDAY, July 14, 2002
1000-1700 IEPG Meeting - 
1200-1900 Registration -
1300-1330 Newcomer's Orientation -
1330-1400 IETF Standards Process Orientation -
1500-1700 Security Tutorial - 
1700-1900 Welcome Reception - 

MONDAY, July 15, 2002
0800-1930 IETF Registration -  
0800-0900 Continental Breakfast  
0900-1130 Morning Sessions 
APP     apparea   Applications Open Area Meeting 
GEN     nomcom    Operation of the IESG/IAB Nominating and Recall Committees WG
INT     ipoib     IP over InfiniBand WG
OPS     mboned    MBONE Deployment WG
RTG     forces    Forwarding and Control Element Separation WG
TSV     nsis      Next Steps in Signaling WG
TSV     pwe3      Pseudo Wire Emulation Edge to Edge WG
                
1130-1300 Break 
1300-1500 Afternoon Sessions I
APP     trade     Internet Open Trading Protocol WG
INT     nemo      NEtwork Mobility BOF
OPS     xmlconf   XML Configuration BOF
SEC     smime     S/MIME Mail Security WG
TSV     dccp      Datagram Congestion Control Protocol BOF
TSV     enum      Telephone Number Mapping WG
TSV     ippm      IP Performance Metrics WG

1500-1530 Break (Refreshments provided) - 
1530-1730 Afternoon Sessions II
INT     ipcdn     IP over Cable Data Network WG
INT     pana      Protocol for carrying Authentication for Network Access WG
OPS     ipfix     IP Flow Information Export WG
RTG     msdp      Multicast Source Discovery Protocol WG
SEC     secsh     Secure Shell WG
TSV     rserpool  Reliable Server Pooling WG
TSV     sip       Session Initiation Protocol WG
        
1730-1930 Break
1930-2200 Evening Sessions
APP     jabber    Jabber Protocol BOF
INT     mobileip  IP Routing for Wireless/Mobile Hosts WG
OPS     bmwg      Benchmarking Methodology WG
OPS     rmonmib   Remote Network Monitoring WG
RTG     rtgarea   Routing Area Meeting
TSV     ips       IP Storage WG
TSV     tist      Topology-Insensitive Service Traversal BOF

TUESDAY, July 16, 2002
0800-1700 IETF Registration - 
0800-0900 Continental Breakfast - 
0900-1130 Morning Sessions
APP     fax&vpim  Internet Fax WG & Voice Profile for Internet Mail WG
APP     webdav    WWW Distributed Authoring and Versioning WG
INT     dhc       Dynamic Host Configuration WG
OPS     psamp     Packet Sampling BOF
RTG     pim       Protocol Independent Multicast WG
SUB     ppvpn     Provider Provisioned Virtual Private Networks WG
TSV     sipping   Session Initiation Proposal Investigation WG 

1130-1300 Break
1300-1400 Afternoon Sessions I
GEN     uswg      User Services WG
INT     atommib   AToM MIB WG
OPS     ptomaine  Prefix Taxonomy Ongoing Measurement & Inter Network Experiment WG
OPS     rap       Resource Allocation Protocol WG
RTG     udlr      UniDirectional Link Routing WG
TSV     ips       IP Storage WG
TSV     spirits   Service in the PSTN/IN Requesting InTernet Service WG
        
1415-1515 Afternoon Sessions II
INT     dnsext    DNS Extensions WG
INT     l2tpext   Layer Two Tunneling Protocol Extensions WG
OPS     entmib    Entity MIB WG
SUB     ipo       IP over Optical WG
TSV     midcom    Middlebox Communication WG
TSV     rmt       Reliable Multicast Transport WG
        
1515-1545 Break (Refreshments provided) - 
1545-1645 Afternoon Sessions III
INT     dnsext    DNS Extensions WG
RTG     vrrp      Virtual Router Redundancy Protocol WG
SEC     krb-wg    Kerberos WG
TSV     iptel     IP Telephony WG
TSV     midcom    Middlebox Communication WG
TSV     rmt       Reliable Multicast Transport WG

1700-1800 Afternoon Sessions IV
APP     opes      Open Pluggable Edge Services WG
INT     send      SEcuring Neighbor Discovery BOF
OPS     bridge    Bridge MIB WG
OPS     dnsop     Domain Name Server Operations WG
SUB     gsmp      General Switch Management Protocol WG

WEDNESDAY, July 17, 2002
0800-1700 IETF Registration - 
0800-0900 Continental Breakfast - 
0900-1130 Morning Sessions
APP     simple    SIP for Instant Messaging and Presence Leveraging Extensions WG
OPS     disman    Distributed Management WG
OPS     ngtrans   Next Generation Transition WG
RTG     manet     Mobile Ad-hoc Networks WG
SUB     ccamp     Common Control and Measurement Plane WG
TSV     cats      Control of ASR and TTS Servers BOF
TSV     rohc      Robust Header Compression WG

1130-1300 Break
1300-1500 Afternoon Sessions I  
INT     magma     Multicast & Anycast Group Membership WG
OPS     sming     Next Generation Structure of Management Information WG
RTG     isis      IS-IS for IP Internets WG
SEC     pkix      Public-Key Infrastructure (X.509) WG
TSV     nfsv4     Network File System Version 4 WG
TSV     sip       Session Initiation Protocol WG 

1500-1530 Break (Refreshments provided) - 
1530-1730 Afternoon Sessions II
APP     ldapbis   LDAP (v3) Revision WG
OPS     opsarea   Operations & Management Open Area
RTG     ospf      Open Shortest Path First IGP WG
SEC     ipsec     IP Security Protocol WG
TSV     avt       Audio/Video Transport WG
TSV     ieprep    Internet Emergency Preparedness WG

1730-1930 Break
1930-2200 IESG Open Plenary - 
 
2230 Late Night Session - PGP Key Signing 

THURSDAY, July 18, 2002
0800-1700 IETF Registration - 
0800-0900 Continental Breakfast - 
0900-1130 Morning Sessions      
APP     crisp     Cross Registry Information Service Protocol BOF
APP     geopriv   Geographic Location/Privacy WG
INT     ipv6      IP Version 6 Working Group WG
RTG     rpsec     Routing Protocol Security Requirements WG
SUB     mpls      Multiprotocol Label Switching WG
TSV     mmusic    Multiparty Multimedia Session Control WG

1130-1300 Break
1300-1500 Afternoon Sessions I
APP     impp      Instant Messaging and Presence Protocol WG
OPS     eos       Evolution of SNMP WG
OPS     ippt      IP Path Tracing BOF
RTG     idr       Inter-Domain Routing WG
SEC     inch      Extended Incident Handling BOF
TSV     sipping   Session Initiation Proposal Investigation WG 
TSV     tsvwg     Transport Area Working Group WG
        rddp      Remote Direct Data Placement BOF
        
1500-1530 Break (Refreshments provided) - 
1530-1730 Afternoon Sessions II
APP     lemonade  License to Enhance Messaging Oriented Network Access for Diverse Endpoints BOF
IRTF    rrg       Routing Research Group
SEC     saag      Open Security Area Directorate
TSV     avt       Audio/Video Transport WG
TSV     ieprep    Internet Emergency Preparedness WG

1730-1930 Break
1930-2200 Open IAB Plenary - 

FRIDAY, July 19, 2002
0800-1000 IETF Registration - 
0800-0900 Continental Breakfast - 
0900-1130 Morning Sessions
GEN     ipr       Intellectual Property Rights BOF










--Boundary_(ID_RLXKZDjYkcLPiTMB/n/Azg)--


From owner-ietf-openproxy@mail.imc.org  Tue Jun 25 19:57:40 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03713
	for <opes-archive@ietf.org>; Tue, 25 Jun 2002 19:57:40 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5PNYo424395
	for ietf-openproxy-bks; Tue, 25 Jun 2002 16:34:50 -0700 (PDT)
Received: from bels002.mediator.com (ip72.usw4.rb1.bel.nwlink.com [209.20.232.72])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5PNYnw24391
	for <ietf-openproxy@imc.org>; Tue, 25 Jun 2002 16:34:49 -0700 (PDT)
Received: from bays02.mediator.com ([172.16.100.252]) by bels002.mediator.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Tue, 25 Jun 2002 16:34:46 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: Protocol Performance
Date: Tue, 25 Jun 2002 16:34:44 -0700
Message-ID: <30A6344AEBFC85429C30FF6C9C501CD10719E9@bays02.mediator.com>
Thread-Topic: Protocol Performance
Thread-Index: AcIcoTZXp7cNIYgkEdazWQCw0E4IZg==
From: "Gamze Seckin" <gamze@hmus.net>
To: <ietf-openproxy@imc.org>
X-OriginalArrivalTime: 25 Jun 2002 23:34:46.0996 (UTC) FILETIME=[E4466940:01C21CA0]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g5PNYnw24392
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit



Hi,
It's been a while since I could follow this groups activities (due to company transfer), I am trying to catch up,so sorry if my comments/questions have already been addressed.

I have two questions:
1. With regards the email below, which I found from the archive, has there been any discussion (or are there any recent results) on the performance evaluation of an edge module w and w/o ICAP deployment?
In draft-stecher-opes-icap-eval-00.txt, section 4.1 only indicates that performance requirements are met, is there a more comprehensive document somewhere?
2. Is it safe to say that a L7 switch (web switch, e.g. nortel alteon) is a simplified OPES device (since ICAP is not an requirement)? If not, why?

Minor typos & comments wrt the latest drafts:
*draft-ietf-opes-scenarios-00.txt, section 4, 4th bullet, 1st sentence, "but in the content" is repeated twice.
*draft-ietf-opes-architecture-02.txt:
--minor typo: first page, first author name followed by a period
--section 2.1, 3rd paragraph, "..opes architecture is largely independent"..what does "largely" mean here? is it fully independent or are there cases where it is, then which one's?
--section 2.1.1, 1st paragraph, "..compiled from several sources..", for first time reader "sources" might not be clear?
--section 2.3, 1st paragraph, "..in this model, all data filters are invoked for all data..", for the first time reader "data filters" might not be clear?

gamze


-----------------------------------------------------------------
Gamze Seckin, Ph.D.
Research Engineer: Media Networking
Hutchison Mediator (US), Inc.

---------------------------------------------------------------------------------------------------------------------------------------------

To: "Rahman, Rezaur" <rezaur.rahman@intel.com <mailto:rezaur.rahman@intel.com>>, "ietf-openproxy@imc.org <mailto:ietf-openproxy@imc.org>" <ietf-openproxy@imc.org <mailto:ietf-openproxy@imc.org>>, Frank Berzau <frank@webwasher.com <mailto:frank@webwasher.com>> 
Subject: Re: Protocol Performance 
From: Volker Hilt <vhilt@dnrc.bell-labs.com <mailto:vhilt@dnrc.bell-labs.com>> 
Date: Tue, 24 Jul 2001 09:30:40 -0400 
List-archive: <<http://www.imc.org/ietf-openproxy/mail-archive/>> 

> I haven't heard of anyone doing any performance analysis between SOAP and
> ICAP. I think your work will help openproxy group to choose the right
> protocol. I would suggest you post the performance comparison methodology
> you are planning on to this mailing list, so that the group can comment on
> its applicability to the OPES framework.

Our main goal is to measure the following two aspects of both protocols:
- additional bandwidth introduced by the protocol 
  (compared to the original message size) 
- CPU cycles needed for protocol processing (e.g. for
    * the creation of headers,
    * message marshaling,
    * transferring data to/from network,
    * ...)
These aspects seem to be most significant during the run-time of a
remote call-out protocol, in particular if a large number of requests
has to be processed. (We're not planning to look into non-run-time
aspects such as design issues, ease of implementation, etc.)

The evaluation-setup we're currently thinking of are measurements based
on existing protocol implementations. We will generate fixed
HTTP-Requests and Responses that we will feed into the client-side
implementation of the protocol stacks. We will not include the message
parser and the rule processor in the performance measurements. Instead
we planning to feed the prepared messages directly into the interface of
the protocol itself. This excludes all non-protocol related effects from
the measurements (even if they would be the same for both protocols). On
the server side we're planning to use a dummy service, that simply
returns the message it has received from the client.

The measurements itself will be taken by introducing checkpoints into
the protocol code. This should enable us to measure bandwidth as well as
required CPU-cycles on a fine-grained level. 

An implication of the performance evaluation using existing
implementations is that the quality of the implementation itself has
impact on the result of the analysis. To minimize this effect, we are
trying to pick two implementations that are somehow comparable. But even
if the implementations differ, the analysis will still provide accurate
measures of the fractions of time that are spent on header processing,
message marshaling and sending/receiving data.

> I would also like to see a comparison between a caching box
> running with and without ICAP, or with or without SOAP (if any
> exists yet). Kind of an ICAP bake-off. If we had a ICAP server
> which would not do any real processing, but just respond back
> to the server, plus a load balanced setup so we don't see the
> server become the bottleneck. That should give us an idea about
> the performance impact when enabling ICAP.
> 
> Would that be in the scope of what you're planning?

Currently we're not planning to do such measurements. However, our
analysis will show the costs of using a call-out protocol which seems to
be an important component needed to determine the brake-off point upon
which the use of a remote callout server is preferable to local service
execution.

Volker



From owner-ietf-openproxy@mail.imc.org  Wed Jun 26 04:58:04 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08169
	for <opes-archive@ietf.org>; Wed, 26 Jun 2002 04:58:03 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5Q8UYM17096
	for ietf-openproxy-bks; Wed, 26 Jun 2002 01:30:34 -0700 (PDT)
Received: from horsey.gshapiro.net (root@horsey.gshapiro.net [209.220.147.178])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5Q8UXw17089
	for <ietf-openproxy@imc.org>; Wed, 26 Jun 2002 01:30:33 -0700 (PDT)
Received: from localhost (alethea.demon.co.uk [194.222.10.198])
	(authenticated bits=0)
	by horsey.gshapiro.net (8.12.5.Beta0/8.12.5.Beta0) with ESMTP id g5Q8UQ37053903;
	Wed, 26 Jun 2002 01:30:30 -0700 (PDT)
Date: Wed, 26 Jun 2002 09:31:26 +0100
From: Ian Cooper <ian@the-coopers.org>
To: Gamze Seckin <gamze@hmus.net>
cc: ietf-openproxy@imc.org
Subject: Re: Protocol Performance
Message-ID: <226848656.1025083886@Elite>
In-Reply-To: <30A6344AEBFC85429C30FF6C9C501CD10719E9@bays02.mediator.com>
References:  <30A6344AEBFC85429C30FF6C9C501CD10719E9@bays02.mediator.com>
X-Mailer: Mulberry/2.2.1 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


--On 25 June 2002 16:34 -0700 Gamze Seckin <gamze@hmus.net> wrote:

>2. Is it safe to say that a L7 switch (web switch, e.g. nortel
> alteon) is a simplified OPES device (since ICAP is not an requirement)?
> If not, why?

No.

The L7 switch isn't a known entity in the communication path between the 
parties engaged in the request-response chain and as such can't be 
controlled by either of the parties.



From owner-ietf-openproxy@mail.imc.org  Wed Jun 26 11:02:43 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21925
	for <opes-archive@ietf.org>; Wed, 26 Jun 2002 11:02:43 -0400 (EDT)
Received: by above.proper.com (8.11.6/8.11.3) id g5QETeY12765
	for ietf-openproxy-bks; Wed, 26 Jun 2002 07:29:40 -0700 (PDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5QETdw12761
	for <ietf-openproxy@imc.org>; Wed, 26 Jun 2002 07:29:39 -0700 (PDT)
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5QEU9x05089
	for <ietf-openproxy@imc.org>; Wed, 26 Jun 2002 09:30:10 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5bb829eea9ac12f25412a@davir01nok.americas.nokia.com> for <ietf-openproxy@imc.org>;
 Wed, 26 Jun 2002 09:29:39 -0500
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Wed, 26 Jun 2002 09:28:37 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: Security threats for OPES
Date: Wed, 26 Jun 2002 10:28:36 -0400
Message-ID: <DC504E9C3384054C8506D3E6BB0124600BACF6@bsebe001.NOE.Nokia.com>
Thread-Topic: Security threats for OPES
Thread-Index: AcIdHcRjbqgayl+fS/qOz/kiZ+NRnQ==
From: <bindignavile.srinivas@nokia.com>
To: <ietf-openproxy@imc.org>
X-OriginalArrivalTime: 26 Jun 2002 14:28:37.0784 (UTC) FILETIME=[C2B73980:01C21D1D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g5QETdw12762
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


Hi,
We had recently submitted a draft on security threats and risks for OPES intermediaries (and callout servers, if any). This topic is listed as one of the targets of the OPES WG. The draft (draft-srinivas-opes-threats-00.txt), basically, is an attempt to define the security threats against the OPES protocol. In addition to the threats, the effects of such security threats on the underlying architecture as well as the requirements of a security solution to mitigate such threats are discussed.

We would like to solicit comments on the issues raised in the draft and further explore the same.

Best regards,
B. Srinivas



From owner-ietf-openproxy@mail.imc.org  Wed Jun 26 15:53:31 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08345
	for <opes-archive@ietf.org>; Wed, 26 Jun 2002 15:53:30 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5QJRXH26506
	for ietf-openproxy-bks; Wed, 26 Jun 2002 12:27:33 -0700 (PDT)
Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5QJRWw26500
	for <ietf-openproxy@imc.org>; Wed, 26 Jun 2002 12:27:32 -0700 (PDT)
Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9])
	by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g5QJR66R015523;
	Wed, 26 Jun 2002 15:27:06 -0400 (EDT)
Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8])
	by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g5QJRQo14632;
	Wed, 26 Jun 2002 15:27:26 -0400 (EDT)
Received: from mhof.com (biena [135.180.160.86])
	by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id PAA10635;
	Wed, 26 Jun 2002 15:27:25 -0400 (EDT)
Message-ID: <3D1A159D.6040301@mhof.com>
Date: Wed, 26 Jun 2002 15:27:25 -0400
From: Markus Hofmann <markus@mhof.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a) Gecko/20020611
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Gamze Seckin <gamze@hmus.net>
CC: ietf-openproxy@imc.org
Subject: Re: Protocol Performance
References: <30A6344AEBFC85429C30FF6C9C501CD10719E9@bays02.mediator.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: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


Gamze,

 > 1. With regards the email below, which I found from the archive,
 > has there been any discussion (or are there any recent results) on
 > the performance evaluation of an edge module w and w/o ICAP
 > deployment?

No, not that I'm aware of. We did some measurements in our Lab, but 
the results were just as expected and not that interesting, so we 
didn't publish anything about it. In short, we measured the delay 
introduced by the protocol engine and didn't find much of an overhead 
for processing the iCAP messages themselves - if I recall correctly, 
time/processing capacity required for rule processing and for service 
execution, in particular, was much more a factor.

 > 2. Is it safe to say that a
 > L7 switch (web switch, e.g. nortel alteon) is a simplified OPES
 > device (since ICAP is not an requirement)? If not, why?

See comments from Ian - a "traditional" L7 switch as known today is 
very likely to miss important features as required by OPES.

 > Minor typos & comments wrt the latest drafts:

Thanks for catching those, the respective editors will surely consider 
these in the upcoming versions of the drafts.

Thanks,
   Markus



From owner-ietf-openproxy@mail.imc.org  Wed Jun 26 17:09:19 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11147
	for <opes-archive@ietf.org>; Wed, 26 Jun 2002 17:09:19 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5QKgUM00522
	for ietf-openproxy-bks; Wed, 26 Jun 2002 13:42:30 -0700 (PDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5QKgTw00518
	for <ietf-openproxy@imc.org>; Wed, 26 Jun 2002 13:42:29 -0700 (PDT)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5QKk5j13236
	for <ietf-openproxy@imc.org>; Wed, 26 Jun 2002 15:46:06 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5bb97f4c3cac12f255126@davir02nok.americas.nokia.com>;
 Wed, 26 Jun 2002 15:42:31 -0500
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Wed, 26 Jun 2002 15:42:31 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Protocol Performance
Date: Wed, 26 Jun 2002 16:42:30 -0400
Message-ID: <DC504E9C3384054C8506D3E6BB0124600BACF7@bsebe001.NOE.Nokia.com>
Thread-Topic: Protocol Performance
Thread-Index: AcIc8D0X1rlcz1LtSzG3x53m97IFtQAYIpww
From: <bindignavile.srinivas@nokia.com>
To: <ian@the-coopers.org>
Cc: <ietf-openproxy@imc.org>
X-OriginalArrivalTime: 26 Jun 2002 20:42:31.0434 (UTC) FILETIME=[FE368EA0:01C21D51]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g5QKgTw00519
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


Hi Ian,

I agree with you, after double-checking with the Alteon products information on the Nortel website, that a L7 switch like the Alteon web switch (in the Alteon products suite) cannot be used as an OPES device. However, I am not sure if I agree with you that the L7 switch cannot be controlled by either end. Control by the receiver doesnt seem to be feasible. However, coupled with the Alteon Web OS product, control by the sending side is possible!

-Srinivas

> -----Original Message-----
> From: ext Ian Cooper [mailto:ian@the-coopers.org]
> Sent: Wednesday, June 26, 2002 4:31 AM
> To: Gamze Seckin
> Cc: ietf-openproxy@imc.org
> Subject: Re: Protocol Performance
> 
> 
> 
> --On 25 June 2002 16:34 -0700 Gamze Seckin <gamze@hmus.net> wrote:
> 
> >2. Is it safe to say that a L7 switch (web switch, e.g. nortel
> > alteon) is a simplified OPES device (since ICAP is not an 
> requirement)?
> > If not, why?
> 
> No.
> 
> The L7 switch isn't a known entity in the communication path 
> between the 
> parties engaged in the request-response chain and as such can't be 
> controlled by either of the parties.
> 
> 


From owner-ietf-openproxy@mail.imc.org  Wed Jun 26 17:19:37 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11499
	for <opes-archive@ietf.org>; Wed, 26 Jun 2002 17:19:36 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5QKuUu01298
	for ietf-openproxy-bks; Wed, 26 Jun 2002 13:56:30 -0700 (PDT)
Received: from horsey.gshapiro.net (root@horsey.gshapiro.net [209.220.147.178])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5QKuSw01293
	for <ietf-openproxy@imc.org>; Wed, 26 Jun 2002 13:56:28 -0700 (PDT)
Received: from alethea.demon.co.uk (alethea.demon.co.uk [194.222.10.198])
	(authenticated bits=0)
	by horsey.gshapiro.net (8.12.5.Beta0/8.12.5.Beta0) with ESMTP id g5QKuQ35004698;
	Wed, 26 Jun 2002 13:56:29 -0700 (PDT)
Date: Wed, 26 Jun 2002 21:56:25 +0100
From: Ian Cooper <ian@the-coopers.org>
To: bindignavile.srinivas@nokia.com
cc: ietf-openproxy@imc.org
Subject: RE: Protocol Performance
Message-ID: <447321.1025128584@alethea.demon.co.uk>
In-Reply-To: <DC504E9C3384054C8506D3E6BB0124600BACF7@bsebe001.NOE.Nokia.com>
References:  <DC504E9C3384054C8506D3E6BB0124600BACF7@bsebe001.NOE.Nokia.com>
X-Mailer: Mulberry/2.2.1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 7bit


--On Wednesday, June 26, 2002 16:42 -0400 bindignavile.srinivas@nokia.com 
wrote:

> Hi Ian,
>
> I agree with you, after double-checking with the Alteon products
> information on the Nortel website, that a L7 switch like the Alteon web
> switch (in the Alteon products suite) cannot be used as an OPES device.
> However, I am not sure if I agree with you that the L7 switch cannot be
> controlled by either end. Control by the receiver doesnt seem to be
> feasible. However, coupled with the Alteon Web OS product, control by the
> sending side is possible!

I don't know enough about that product's remote configuration capabilities, 
but if content side can control it using a network-based protocol then the 
consumer side could also control it (all done out of band at the 
application layer, obviously).

The fact that such a protocol exists seems tangential to the point here, 
however.  RFC3238 consideration 2.2 would appear to be in play anyway.

>
> -Srinivas
>
>> -----Original Message-----
>> From: ext Ian Cooper [mailto:ian@the-coopers.org]
>> Sent: Wednesday, June 26, 2002 4:31 AM
>> To: Gamze Seckin
>> Cc: ietf-openproxy@imc.org
>> Subject: Re: Protocol Performance
>>
>>
>>
>> --On 25 June 2002 16:34 -0700 Gamze Seckin <gamze@hmus.net> wrote:
>>
>> > 2. Is it safe to say that a L7 switch (web switch, e.g. nortel
>> > alteon) is a simplified OPES device (since ICAP is not an
>> requirement)?
>> > If not, why?
>>
>> No.
>>
>> The L7 switch isn't a known entity in the communication path
>> between the
>> parties engaged in the request-response chain and as such can't be
>> controlled by either of the parties.
>>
>>




From owner-ietf-openproxy@mail.imc.org  Wed Jun 26 17:41:55 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12286
	for <opes-archive@ietf.org>; Wed, 26 Jun 2002 17:41:55 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5QLHN302199
	for ietf-openproxy-bks; Wed, 26 Jun 2002 14:17:23 -0700 (PDT)
Received: from mgr3.xmission.com (mgr3.xmission.com [198.60.22.203])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5QLHMw02192
	for <ietf-openproxy@imc.org>; Wed, 26 Jun 2002 14:17:22 -0700 (PDT)
Received: from mail by mgr3.xmission.com with spam-scanned (Exim 3.35 #1)
	id 17NKAE-0003nt-00; Wed, 26 Jun 2002 15:17:24 -0600
Received: from [198.60.22.20] (helo=xmission.xmission.com)
	by mgr3.xmission.com with esmtp (Exim 3.35 #1)
	id 17NKAE-0003ne-02; Wed, 26 Jun 2002 15:17:22 -0600
Received: from hilarie by xmission.xmission.com with local (Exim 3.16 #3)
	id 17NK4d-0006W4-00; Wed, 26 Jun 2002 15:11:35 -0600
From: "Hilarie Orman, Purple Streak Development" <hilarie@xmission.com>
To: bindignavile.srinivas@nokia.com
Cc: ietf-openproxy@imc.org
In-reply-to: Yourmessage <DC504E9C3384054C8506D3E6BB0124609DCB19@bsebe001.NOE.Nokia.com>
Subject: Re: Publish Draft: draft-srinivas-opes-threats-00.txt
Message-Id: <E17NK4d-0006W4-00@xmission.xmission.com>
Date: Wed, 26 Jun 2002 15:11:35 -0600
X-Spam-Status: No, hits=-2.3 required=8.0
	tests=IN_REP_TO,DOUBLE_CAPSWORD
	version=2.31
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>


This is a reasonable start, and thanks for kicking off this important
discussion.  I find it very hard to consider the threats without
understanding the roles of the various participants, and this has
influenced my comments in a negative way, which I've tried to explain.
If this were expanded to include more information about roles, purposes,
and mitigations, it would help to formulate the security architecture.


        Either the application entities, referred to in the preceding text, 
        may be collocated with either of the two ends of the data stream or 
        it may be a discrete entity situated elsewhere within the network. 
        The last scenario comprises a data stream scenario, which is 
        referred to as Open Pluggable Edge Services (OPES). Several such 
        provisioning scenarios are described in [OPES-SCENE].  
         
I think OPES encompasses all the scenarios.

        New functionality when added to a networking architecture invariably 
        creates new possibilities for tampering with some signaling 
        communications, as well as user data traffic. In other words, 
        various forms of protection including physical and/or programmatic 
        means are lowered, resulting in new security vulnerabilities.

I don't think that it is obvious that "protection" is "lowered" anytime
new functionality is added.

        In the traditional non-OPES scenario, the communicating end-points 
        (the content producer and consumer) have a direct one-to-one 
        association between them (see Figure 1).

This seems to ignore the very common traditional scenario that uses a
surrogate or caching proxy intermediary.  There has been very little discussion
of the security threats and diminished protection introduced by
these devices, yet they are essential to timely delivery.

    3.1. OPES device false registration/deregistration 

The architecture does not define any registration/deregistration
mechanism, for better or worse.  I agree that there should be one, 
and of course it should be authenticated.  But with respect to what
policy?  An entity might be fully authenticated and authorized by
*something*, but it still might be malicious.  So, whose judgment
should the OPES data processor trust?  I submit that this is the
question that needs elucidation, wrt to the type of transformation;
the scenarios document has a good dissection of the possibilities.

As for accepting traffic transformed by an "un-"anything intermediary,
you'd have to detect it before refusing.

     3.2. OPES device spoofing 

I'm confused about this scenario; the device is authenticated and
authorized, and yet someone can spoof it.  The solution requires
cryptographic or physical protection of the communication channel, but
the subsequent text doesn't mention this.

Wrt to auth(enication,orization) of the callout servers, who is performing
the check?  The OPES data processor or some endpoints?  I think the OPES
intermediary should do this, but the endpoints can indicate what policy
they want enforced.

     3.3. Malicious node performs a replay attack

I'm not clear on the problem or its solution.  If you've got a bad OPES
box, and it is doing something like replaying user requests repeatedly,
perhaps racking up huge bills for unwanted transformations, you can't
stop it by using sequence numbers.  It's an auditing issue.  Auditing
is part of security, certainly, but about all one can do is compare
logs.

     3.4. Re-establishing end-device - OPES device security during failover

It is completely possible to failover securely from A to B without
notifying the endpoints.  However, if it was a secure connection and
a malicious intermediary tries to co-opt it, it should fail.  If it
doesn't, there wasn't a secure connection in the first place.  

     3.5. Message Integrity 

In general, the OPES data processor cannot check the integrity of content
messages, because of the difficulty of sharing the cryptographic
information.  Yes, the endpoints can use public key digital signatures,
and OPES can check, but this is a severe requirement that is unlikely
to take hold.

     3.6. Data Confidentiality 

This section refers mysteriously to the transmittal of shared encryption
keys.  What channel, what keys?

The IAB considerations included an item about "end-to-end confidentiality
compatibility", which we might want to discuss now.  This imposes a signal
that requires encryption of the messages at each hop.  We need to consider
whether or not this includes callout servers, how the data gets
encapsulated in its encryption shielding, whether or not separate keys
must be used for separate endpoint pairs, etc.


     3.7. Denial-of-Service (DoS)

I'd thought this would deal with situations where an OPES data processor
is turned into a DoS component.  An ugly problem to detect and fix.

     3.8.Authorized entity later repudiates a request 

This is important for endpoints that authorize OPES services; this ties
in with audit and accounting logs, their integrity, protection, transmittal,
etc.

Hilarie



From owner-ietf-openproxy@mail.imc.org  Thu Jun 27 17:37:02 2002
Received: from above.proper.com (mail.proper.com [208.184.76.45])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17737
	for <opes-archive@ietf.org>; Thu, 27 Jun 2002 17:37:02 -0400 (EDT)
Received: from localhost (localhost [[UNIX: localhost]])
	by above.proper.com (8.11.6/8.11.3) id g5RL9kA10194
	for ietf-openproxy-bks; Thu, 27 Jun 2002 14:09:46 -0700 (PDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id g5RL9jw10185
	for <ietf-openproxy@imc.org>; Thu, 27 Jun 2002 14:09:45 -0700 (PDT)
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5RLAFx22421
	for <ietf-openproxy@imc.org>; Thu, 27 Jun 2002 16:10:16 -0500 (CDT)
Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5bbebe96e6ac12f25412a@davir01nok.americas.nokia.com>;
 Thu, 27 Jun 2002 16:09:45 -0500
Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905);
	 Thu, 27 Jun 2002 16:09:39 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: Publish Draft: draft-srinivas-opes-threats-00.txt
Date: Thu, 27 Jun 2002 17:09:36 -0400
Message-ID: <DC504E9C3384054C8506D3E6BB0124600BACF8@bsebe001.NOE.Nokia.com>
Thread-Topic: Publish Draft: draft-srinivas-opes-threats-00.txt
Thread-Index: AcIdVuPagUgEP5P7Tl2yOpLbTLHRxwAmh/ZQ
From: <bindignavile.srinivas@nokia.com>
To: <hilarie@xmission.com>
Cc: <Tat.Chan@nokia.com>, <ietf-openproxy@imc.org>
X-OriginalArrivalTime: 27 Jun 2002 21:09:39.0678 (UTC) FILETIME=[F3229FE0:01C21E1E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g5RL9jw10188
Sender: owner-ietf-openproxy@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe: <mailto:ietf-openproxy-request@imc.org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Content-Transfer-Encoding: 8bit


Hi,

> This is a reasonable start, and thanks for kicking off this important
> discussion.  I find it very hard to consider the threats without
> understanding the roles of the various participants, and this has
> influenced my comments in a negative way, which I've tried to explain.
> If this were expanded to include more information about 
> roles, purposes,
> and mitigations, it would help to formulate the security architecture.

Thank you for your comments! Re. the description of the roles of the various participants, we would direct your attention to the OPES architecture draft. We felt that, rather than repeating the material from the architeture draft, citing it would be sufficient.

> 
>         Either the application entities, referred to in the 
> preceding text, 
>         may be collocated with either of the two ends of the 
> data stream or 
>         it may be a discrete entity situated elsewhere within 
> the network. 
>         The last scenario comprises a data stream scenario, which is 
>         referred to as Open Pluggable Edge Services (OPES). 
> Several such 
>         provisioning scenarios are described in [OPES-SCENE].  
>          
> I think OPES encompasses all the scenarios.

Yes, we do agree that OPES does encompass all the scenarios referred to in the draft. In other words, the OPES functionality may be located in either a discrete entity [draft-ietf-opes-architecture-00.txt] or it may be collocated in either the data provider or data consumer end. We believe that our document does address both the scenarios though!


>         New functionality when added to a networking 
> architecture invariably 
>         creates new possibilities for tampering with some signaling 
>         communications, as well as user data traffic. In other words, 
>         various forms of protection including physical and/or 
> programmatic 
>         means are lowered, resulting in new security vulnerabilities.
> 
> I don't think that it is obvious that "protection" is 
> "lowered" anytime new functionality is added.

In general, Murphy's law can be appealed to, to make our point! In most cases, more the parts in a system, greater is the chance for something to "break" or equivalently for security to be compromised. Hence the claim.

>         In the traditional non-OPES scenario, the 
> communicating end-points 
>         (the content producer and consumer) have a direct one-to-one 
>         association between them (see Figure 1).
> 
> This seems to ignore the very common traditional scenario that uses a
> surrogate or caching proxy intermediary.  There has been very 
> little discussion
> of the security threats and diminished protection introduced by
> these devices, yet they are essential to timely delivery.

We assumed in our draft, as was discussed and initially concluded on the OPES mailing list, that surrogates or caching proxies were equivalent to OPES intermediaries. So the traditional non-OPES scenario, described in Figure 1, does not hold for the case of Surrogates or caching proxies. However, if surrogates or caching proxies cannot be considered as OPES intermediaries, then additional text will have to be inserted to discuss the related security threats.

>     3.1. OPES device false registration/deregistration 
> 
> The architecture does not define any registration/deregistration
> mechanism, for better or worse.  I agree that there should be one, 
> and of course it should be authenticated.  But with respect to what
> policy?  

We are unclear as to what the implication of your question was? "With respect to what policy" meaning?

> An entity might be fully authenticated and authorized by
> *something*, but it still might be malicious.  So, whose judgment
> should the OPES data processor trust?  I submit that this is the
> question that needs elucidation, wrt to the type of transformation;
> the scenarios document has a good dissection of the possibilities.

The OPES device, as required by RFC3238, needs to be authenticated/authorized by at least one of the application layer end hosts (the producer or consumer). Furthermore, we have assumed that the end hosts are (innately) trustworthy. In other words, the end hosts are not malicious! 

However, if the OPES device is authorized by a malicious or spurious end host (meaning that the end-device hijacks the transformed data and prevents it from being sent to the actual end host), the actual (non-malicious) end host could communicate with the content producer (by some non-OPES means) to indicate that something is wrong! Something along these lines might be included in the draft.

> As for accepting traffic transformed by an "un-"anything intermediary,
> you'd have to detect it before refusing.

Absoutely!

>      3.2. OPES device spoofing 
> 
> I'm confused about this scenario; the device is authenticated and
> authorized, and yet someone can spoof it.  The solution requires
> cryptographic or physical protection of the communication channel, but
> the subsequent text doesn't mention this.

We meant here that a malicious node could falsely authenticate an intermediate device as an OPES device. Thus, the malicious node could hijack the traffic and have it pass through the spurious OPES intermediar! In other words, the malicious node "spoofs" the identity of the genuine OPES intermediary and thus causes damage.

> Wrt to auth(enication,orization) of the callout servers, who 
> is performing
> the check?  The OPES data processor or some endpoints?  I 
> think the OPES
> intermediary should do this, but the endpoints can indicate 
> what policy
> they want enforced.

Agreed! We too felt that the callout server can be authenticated/authorized by the OPES interediary based on a policy recommended by the endpoints.

>      3.3. Malicious node performs a replay attack
> 
> I'm not clear on the problem or its solution.  If you've got 
> a bad OPES
> box, and it is doing something like replaying user requests 
> repeatedly,
> perhaps racking up huge bills for unwanted transformations, you can't
> stop it by using sequence numbers.  It's an auditing issue.  Auditing
> is part of security, certainly, but about all one can do is compare
> logs.

What we were referring to is the following. A malicious node (say, an OPES intermediary) eavesdrops on a prior OPES signaling request and stores it for future use. Then, in a subsequent OPES session, the malicious node relays the stored message and thus compromises the session.
We suggested that, by using sequence numbers, one can detect the occurance of a replay attack and then stop the session (or take other remedial actions).

>      3.4. Re-establishing end-device - OPES device security during failover
> 
> It is completely possible to failover securely from A to B without
> notifying the endpoints.  However, if it was a secure connection and
> a malicious intermediary tries to co-opt it, it should fail.  If it
> doesn't, there wasn't a secure connection in the first place.  

Here, the intent was that when a secure session between the end-device and OPES intermediary A fails, a new connection between the end-device and a new OPES intermediary B will not be automatically secure. The user must set up a secure connection between the end-device and B explicitly.
 
>      3.5. Message Integrity 
> 
> In general, the OPES data processor cannot check the 
> integrity of content
> messages, because of the difficulty of sharing the cryptographic
> information.  Yes, the endpoints can use public key digital 
> signatures,
> and OPES can check, but this is a severe requirement that is unlikely
> to take hold.

Our main objective is to investigate the threats and their possible consequences. If content integrity is considered as important, then we may need to look for ways to realize that.

>      3.6. Data Confidentiality 
> 
> This section refers mysteriously to the transmittal of shared 
> encryption
> keys.  What channel, what keys?

In here, we are considering a scenario whereby the content is encrypted with a shared key owned by the content producer and the consumer. In order for the OPES device to tranform the content, it should have the shared key as well. Therefore, how this shared key is distributed to the OPES device has to be carefully considered such that it will not be compromised.

> The IAB considerations included an item about "end-to-end 
> confidentiality
> compatibility", which we might want to discuss now.  This 
> imposes a signal
> that requires encryption of the messages at each hop.  We 
> need to consider
> whether or not this includes callout servers, how the data gets
> encapsulated in its encryption shielding, whether or not separate keys
> must be used for separate endpoint pairs, etc.

Yes, we agree with your thoughts on this matter. Either a common shared key could be used for all the segments (producer to OPES intermediary, OPES intermediary to call-out server etc.), or a separate shared key could be used for each segment with a corresponding increase in the set-up complexity. 

Furthermore, to ensure data confidentiality, separate sets of keys need to be used for separate endpoint pairs.

> 
>      3.7. Denial-of-Service (DoS)
> 
> I'd thought this would deal with situations where an OPES 
> data processor
> is turned into a DoS component.  An ugly problem to detect and fix.

This is possible, and we could also include this attack scenario into the document. We had considered the case where the DoS attack is launched by a different node and not the opes  intermediary itself.

>      3.8.Authorized entity later repudiates a request 
> 
> This is important for endpoints that authorize OPES services; 
> this ties
> in with audit and accounting logs, their integrity, 
> protection, transmittal,
> etc.

We have no objections to this.



> Hilarie
> 
>