From owner-ietf-openproxy@mail.imc.org Wed Mar 3 13:26:50 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16188 for ; Wed, 3 Mar 2004 13:26:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayb50-0005xG-00 for opes-archive@ietf.org; Wed, 03 Mar 2004 13:26:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayb42-0005np-00 for opes-archive@ietf.org; Wed, 03 Mar 2004 13:25:53 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1Ayb3O-0005ej-00 for opes-archive@ietf.org; Wed, 03 Mar 2004 13:25:10 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23I8G8I082417; Wed, 3 Mar 2004 10:08:16 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i23I8GIp082416; Wed, 3 Mar 2004 10:08:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i23I8EOx082398 for ; Wed, 3 Mar 2004 10:08:14 -0800 (PST) (envelope-from jgw@cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 03 Mar 2004 10:20:37 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i23I8AF8001610; Wed, 3 Mar 2004 10:08:11 -0800 (PST) Received: from cisco.com (rtp-vpn3-281.cisco.com [10.82.217.27]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQV86600; Wed, 3 Mar 2004 10:08:08 -0800 (PST) Message-ID: <40461F07.3080104@cisco.com> Date: Wed, 03 Mar 2004 13:08:07 -0500 From: "John G. Waclawsky" Reply-To: jgw@cisco.com Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Rousskov CC: OPES Group , Krishna Ramadas Subject: Re: An opes usage question. References: <3FFC8D88.7020506@cisco.com> <3FFD9E35.6080607@cisco.com> <3FFDC1CE.7060809@cisco.com> <403F9EBE.8030709@cisco.com> <403FB970.7060400@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080909070800030807000006" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_FONTCOLOR_UNKNOWN, HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------080909070800030807000006 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Alex, thanks for the discussion. I'll take your suggestion to provide a more detailed example that we can discuss. I am considering the case of a large number of users accessing content and also needing adaptations for the proper delivery of the content. Also the adaptations for the services may be done in stages. The environment (summarized from our previous e-mails, ...but please let me know if I have a misunderstanding) that I envision is: 1) The opes framework allows services to be distributed (or pipelined), with incremental services being added to each traffic flow at each stage. This is an opes proxy to proxy communication model. 2) A pool of multiple opes proxies can be provisioned at each stage to support a large number of flows 3) Installing load balancers between stages to distribute the flows is ok in an opes framework (and this is a typical business scenario). If all the flow processing can be achieved in-line then there is no need to identify any specific proxy in any pool. In this case we probably don't care which previous stage opes proxy did the prior adaptation step. 4) The crux of the problem is how to share information between two stages of the flow. This sending of metadata from one stage to a previous stage will require knowledge of specific server addresses (a more general case might be be to send the metadata in either direction). Let's assume, for a specific example, a network allows access to premium content that is billable by the number of bytes being delivered. The content flows to the users from a premium content server through a pool of billing gateway proxies and then proceeds to the next stage where the content may be modified by other proxies for rendering on a user's device (color to black/white, compressed for efficiency, adding advertisements or banners etc.). If any particular flow adaptation reduces the number of bytes then billing needs to be adjusted. Now two specific proxies in each pool need to exchange metadata to coordinate information about a specific flow to get the bill correct for a particular flow. The location of a load balancer between the two sets of proxy pools hides the association for individual flows. I "think" this may be a different problem than the general peer discovery problem you brought up. In this case peer discovery refers to "flow participant discovery" in the previous stage and does not refer to locating useful servers. The need for discovering peer participants for a particular flow arises if any specific metadata exchange has to be made between participants, like the billing record consolidation example. I think "flow participant discovery" problem I described is an opes specific problem. So I am back to my initial hypothesis that the opes framework needs a "flow participant discovery" protocol between proxies that isn't disturbed/effected by load balancing or uses load balancing to some advantage (assumes it is there and leverages it somehow). I have some thoughts on that, but first I like to make sure the usage situation is clear. Your thoughts are greatly appreciated. Thanks again. Regards John Alex Rousskov wrote: >On Fri, 27 Feb 2004, John G. Waclawsky wrote: > > > >>Alex, you had mentioned in a previous e-mail that the "framework is >>not complete. It does not have ready-to-use tools for all possible >>intermediary adaptations". Would this include a load balancing >>environment? >> >> > >Possibly, but it is too early to say. I do not know if any >opes-specific tools will be needed in a load balancing environment. >For example, as far as I can see, to load balance callout server >adaptations, no new tools are needed and OCP can be used as is. > > > >>Specifically, load balancing is not the problem that I currently >>see. I believe I can make the load balancers work with what I >>anticipate doing within an opes framework. >> >> > >Looks like we are in agreement here. > > > >>But, I am looking for a general opes solution that allows peer >>discovery so I can perform adaptations (pipelined over load >>balancers, if you will) on a number of flows, web pages, file >>downloads,...etc. >> >> > >By "peer discovery", do you mean discovering callout servers that >provide OPES services that the application proxy needs? If yes, then >this discovery is out of OCP and possibly even OPES scope. It can be >implemented using existing or new protocols on top of OPES protocols. > >The closest thing to peer discovery supported in OCP is querying an >OCP peer for a list of supported services or negotiating service >support. Both can only be done if we have established a connection to >the peer, which is what peer discovery should help us with. > > > >>I consider load balancing as an essential part of a "typical" high >>capacity services situation. My thoughts are that peer discovery is >>necessary as an option for a load balanced opes environment. >> >> > >I see no direct relationship between load balancing and peer >discovery. I define load balancing as spreading the load among a known >set of servers. I define peer discovery as locating potentially useful >servers. The two can be combined (discover what servers we can use for >load balancing), but are independent. > > > >>Are you saying in your reply that OCP can also be used for peer >>discovery? >> >> > >No. > > > >>If not, shouldn't the opes framework be extended to satisfy a peer >>discovery use case over a load balancer? >> >> > >Only if there is something really OPES-specific in this peer discovery >problem. As you know, peer discovery in general is an old problem with >a few semi-working solutions and no good ones. What OPES-specific peer >discovery features would you like the framework extension to support? >And, again, I am not sure how you connect peer discovery and load >balancing. > > > >>I was thinking another protocol between peers might be needed (or we >>can use an existing protocol). >> >> > >Hopefully, that another protocol already exists and can be used as-is. >Can you give a very specific example: who needs to discover what and >how is that related to load balancing? > >Thanks, > >Alex. > > > > > >>Alex Rousskov wrote: >> >> >> >>>John, >>> >>> OPES protocols do not have features specific to a >>>load-balancing environment, and I do not think they have any features >>>that do not work in such an environment. If your load balancer can >>>balance opaque TCP sessions, then OPES callout protocol should work >>>just fine with multiple callout servers. If you are proxying native >>>HTTP without outsourcing services via OCP, then load balancers can >>>balance HTTP "sessions" as well. >>> >>> OCP is easier to load balance than HTTP because it does not >>>have valuable state outside of the OCP connection. While HTTP claims >>>to be stateless, things built on top of HTTP often require >>>client/server affinity. Hopefully, OCP will not be abused in such a >>>way because it has mechanisms to maintain necessary state within the >>>connection. >>> >>>HTH, >>> >>>Alex. >>> >>>On Fri, 27 Feb 2004, John G. Waclawsky wrote: >>> >>> >>> >>> >>> >>>>I have another question. Does an opes environment handle the >>>>requirement of a peer interacting with another peer with a load >>>>balancer between them. The situation is that I require two proxies >>>>to provide a service. An "A" proxy and a "B" proxy that are peers >>>>in providing the service to a data flow. Because of the scale, the >>>>likely deployment will involve multiple boxes of types A and B. This >>>>means I will have two groups of boxes with a load balancer between >>>>them. I wish to dynamically associate an specific box of type A with >>>>a specific Box of type B (across the load balancer) and a particular >>>>flow. Is it possible to perform peer discovery and the dynamic >>>>association between the two peers and a flow within the opes >>>>framework? Thanks for any help and guidance. >>>> >>>>Regards John >>>> >>>>John G. Waclawsky wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Alex, I very much appreciate your help and the additional >>>>>information. I need a little time to digest this and think some more >>>>>about my problem and opes "needs".... >>>>>Thanks. Regards John >>>>> >>>>>Alex Rousskov wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>On Thu, 8 Jan 2004, John G. Waclawsky wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Alex, thank you for your reply and the pointer. I agree with you >>>>>>>that the use case I am interested in is not explicitly documented in >>>>>>>the opes material. This gives the wrong impression, since all the >>>>>>>examples show the data flows returning to the first hop data >>>>>>>dispatcher. To restrict data flow in this way would be inefficient >>>>>>>for high capacity applications and would tend to make the first hop >>>>>>>a bottleneck. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>John, >>>>>> >>>>>> You are misreading OPES architecture diagrams because you are >>>>>>thinking about a much "simpler" case than most diagrams attempt to >>>>>>document and, hence, you assign wrong roles to "boxes" that may not >>>>>>even exist in your environment. This is the architecture draft fault, >>>>>>not yours. Let me try to explain. >>>>>> >>>>>>Here is a "classic" OPES proxying case (horizontal lines are >>>>>>application data/protocols being proxied, proxies may be adapting data >>>>>>internally): >>>>>> >>>>>> Figure A. >>>>>> >>>>>> end -- proxy -- proxy -- ... -- end >>>>>> >>>>>>Here is a "classic" OPES callout case (vertical lines are callout >>>>>>data/protocols, proxy is not adapting data, callout servers may be >>>>>>adapting data): >>>>>> >>>>>> Figure B. >>>>>> >>>>>> end --- proxy --- end >>>>>> _________|__________ >>>>>> | | | >>>>>> | | | >>>>>> callout callout callout >>>>>> server server server >>>>>> >>>>>>A combination of the above is possible and common, of course. In a >>>>>>combined case, some proxies are adapting data internally and some use >>>>>>callout servers to adapt. >>>>>> >>>>>>In your particular case (the adapted data flows to the next hop), you >>>>>>do not have callout servers. You have proxies that adapt data >>>>>>internally. However, your case may not be a classic proxying case >>>>>>because you may want proxies to use a protocol that differs from the >>>>>>original application protocol (so that you can ship metadata and >>>>>>perhaps pipeline more efficiently). I will use curly (~) lines to show >>>>>>that new protocol below. You may also want to do some load balancing: >>>>>> >>>>>> Figure C. >>>>>> >>>>>> ~~~~~ proxy1 --- >>>>>> / >>>>>> end -- proxy ~~~~~~ proxy2 --- ?? end >>>>>> \ >>>>>> ~~~~~ proxyN --- >>>>>> >>>>>> >>>>>>I do not know how the proxies will get application data to the right >>>>>>"end", but it is not important for this discussion. >>>>>> >>>>>>Note that the curly path may use a completely new protocol (e.g., OCP) >>>>>>or can use a combination of the original application protocol to >>>>>>deliver data and some other protocol for metadata (billing, etc.) >>>>>>records. >>>>>> >>>>>>The above is OPES, but not a callout case. There are no callout >>>>>>servers, just proxies. Whether you want to use OCP for the curly path >>>>>>depends on what kind of data/metadata you want to exchange and what >>>>>>other protocols you have available. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>To be a little more specific on my use case and to make sure I >>>>>>>understand your response let me add more detail. Fundamentally, I wish >>>>>>>to have an "open" IETF network environment. The second requirement is >>>>>>>speed in adaptation processing, so I am thinking that callout will be >>>>>>>faster than using a proxy (maybe this is an incorrect assumption). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>It's an incorrect question :-). Adaptations at the callout server can >>>>>>be as "fast" or as "slow" as adaptations performed internally at the >>>>>>proxy. The primary reason to use a callout server is to "outsource" >>>>>>(from business, development, support, logistics, legal, etc. points of >>>>>>view) adaptations. The primary reasons not to use a callout server are >>>>>>security and overheads of the data having to return back to the proxy. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>I may be a little confused about the distinction between classic >>>>>>>proxy and classic call out in this situation (this word proxy isn't >>>>>>>even mentioned in the opes architecture document as a >>>>>>>consideration). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>I hope the above diagrams clarify the distinction. OPES processor is >>>>>>the term closest to the "proxy", I think. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Also, I have a requirement to adapt a large volume of content for >>>>>>>numerous devices. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>Both callout and builtin adaptations can handle large volumes of >>>>>>content. There are many factors at play here, from legal concerns to >>>>>>the kind of adaptation being performed. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>I expect that the volume of data will require a number of adaptation >>>>>>>(call out) processors. I estimate 10 of them and therefore I would >>>>>>>need load balancing as part of the solution for directing data to >>>>>>>the call out servers (doing the adaptation). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>Load balancing can be done with both callout and proxying schemes. >>>>>>OPES mechanisms are usually per-message so any load balancing method >>>>>>that does not split individual application messages should work just >>>>>>fine. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>I am looking at Figure 3 in the opes architecture draft and >>>>>>>considering a load balanced collection of ten call out servers. As I >>>>>>>had mentioned previously, I'd like to have parallel pipeline >>>>>>>approach where the adapted data from each of the opes call out >>>>>>>server is simply forwarded on, directly to the producer or data >>>>>>>consumer (what ever the case would be). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>The latter makes the adapter a proxy, not a callout server (by >>>>>>definition). See Figure C above. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>In addition each of the opes call out servers would then send >>>>>>>billing and trace data back to the load balancer (or another network >>>>>>>location). Is it realistic to expect that this could this be >>>>>>>accomplished within the opes framework? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>It is. The only question is what protocol(s) you will use between your >>>>>>proxies (the curly lines in Figure C). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>In fact a more fundamental question is the opes framework the best >>>>>>>way to solve this problem and maintain an open system. I think this >>>>>>>is what opes is all about. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>IMO, OPES framework accommodates, in principle, any intermediary >>>>>>adaptation. Thus, your problem is within the framework. However, the >>>>>>framework is not complete. It does not have ready-to-use tools for all >>>>>>possible intermediary adaptations. I hope that you will find OCP Core >>>>>>and OPES communications "tools" useful for your problems, but I lack >>>>>>information to tell your whether they are the best. >>>>>> >>>>>>The system is "open" if it uses "open standards". If current OPES >>>>>>tools are not right for you, and there are no better open tools, then >>>>>>we can work together, within the OPES Framework, on defining open >>>>>>standards (protocols and interfaces) that will solve your specific >>>>>>problem. >>>>>> >>>>>>Alex. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>> >>> > > > > --------------080909070800030807000006 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Alex, thanks for the discussion. I'll take your suggestion to provide a more detailed example that we can discuss. I am considering  the case of a large number of users accessing content and also needing adaptations for the proper delivery of the content. Also the adaptations for the services may be done in stages. The environment (summarized from our previous e-mails, ...but please let me know if I have a misunderstanding) that I envision is:

1)  The opes framework allows services to be distributed (or pipelined), with incremental services being added to each traffic flow at each stage. This is an opes proxy to proxy communication model.
2) A pool of multiple opes proxies can be provisioned at each stage to support a large number of flows
3) Installing load balancers between stages to distribute the flows is ok in an opes framework (and this is a typical business scenario). If all the flow processing can be achieved in-line then there is no need to identify any specific proxy in any pool. In this case we probably don't care which previous stage opes proxy did the prior adaptation step. 
4) The crux of the problem is how to share information between two stages of the flow. This sending of metadata from one stage to a previous stage will require knowledge of specific server addresses (a more general case might be be to send the metadata in  either direction).

Let's assume, for a specific example, a network allows access to premium content that is billable by the number of bytes being delivered. The content flows to the users from a premium content server through a pool of billing gateway proxies and then proceeds to the next stage where the content may be modified by other proxies for rendering on a user's device (color to black/white, compressed for efficiency, adding advertisements or banners etc.). If any particular flow adaptation reduces the number of bytes then billing needs to be adjusted.  Now two specific proxies in each pool need to exchange metadata to coordinate information about a specific flow to get the bill correct for a particular flow. The location of a load balancer between the two sets of proxy pools hides the association for individual flows. I "think" this may be a different problem than the general peer discovery problem you brought up. In this case peer discovery refers to "flow participant discovery" in the previous stage and does not refer to locating useful servers. The need for discovering peer participants for a particular flow arises if any specific metadata exchange has to be made between participants, like the billing record consolidation example.

I think "flow participant discovery" problem I described is an opes specific problem. So I am back to my initial hypothesis that the opes framework needs a "flow participant discovery" protocol between proxies that isn't disturbed/effected by load balancing or uses load balancing to some advantage (assumes it is there and leverages it somehow). I have some thoughts on that, but first I like to make sure the usage situation is clear. Your thoughts are greatly appreciated. Thanks again.
Regards  John
Alex Rousskov wrote:
On Fri, 27 Feb 2004, John G. Waclawsky wrote:

  
Alex, you had mentioned in a previous e-mail that the "framework is
not complete. It does not have ready-to-use tools for all possible
intermediary adaptations". Would this include a load balancing
environment?
    

Possibly, but it is too early to say. I do not know if any
opes-specific tools will be needed in a load balancing environment.
For example, as far as I can see, to load balance callout server
adaptations, no new tools are needed and OCP can be used as is.

  
Specifically, load balancing is not the problem that I currently
see. I believe I can make the load balancers work with what I
anticipate doing within an opes framework.
    

Looks like we are in agreement here.

  
But, I am looking for a general opes solution that allows peer
discovery so I can perform adaptations (pipelined over load
balancers, if you will) on a number of flows, web pages, file
downloads,...etc.
    

By "peer discovery", do you mean discovering callout servers that
provide OPES services that the application proxy needs? If yes, then
this discovery is out of OCP and possibly even OPES scope. It can be
implemented using existing or new protocols on top of OPES protocols.

The closest thing to peer discovery supported in OCP is querying an
OCP peer for a list of supported services or negotiating service
support. Both can only be done if we have established a connection to
the peer, which is what peer discovery should help us with.

  
I consider load balancing as an essential part of a "typical" high
capacity services situation. My thoughts are that peer discovery is
necessary as an option for a load balanced opes environment.
    

I see no direct relationship between load balancing and peer
discovery. I define load balancing as spreading the load among a known
set of servers. I define peer discovery as locating potentially useful
servers. The two can be combined (discover what servers we can use for
load balancing), but are independent.

  
Are you saying in your reply that OCP can also be used for peer
discovery?
    

No.

  
If not, shouldn't the opes framework be extended to satisfy a peer
discovery use case over a load balancer?
    

Only if there is something really OPES-specific in this peer discovery
problem. As you know, peer discovery in general is an old problem with
a few semi-working solutions and no good ones. What OPES-specific peer
discovery features would you like the framework extension to support?
And, again, I am not sure how you connect peer discovery and load
balancing.

  
I was thinking another protocol between peers might be needed (or we
can use an existing protocol).
    

Hopefully, that another protocol already exists and can be used as-is.
Can you give a very specific example: who needs to discover what and
how is that related to load balancing?

Thanks,

Alex.



  
Alex Rousskov wrote:

    
John,

	OPES protocols do not have features specific to a
load-balancing environment, and I do not think they have any features
that do not work in such an environment. If your load balancer can
balance opaque TCP sessions, then OPES callout protocol should work
just fine with multiple callout servers. If you are proxying native
HTTP without outsourcing services via OCP, then load balancers can
balance HTTP "sessions" as well.

	OCP is easier to load balance than HTTP because it does not
have valuable state outside of the OCP connection. While HTTP claims
to be stateless, things built on top of HTTP often require
client/server affinity. Hopefully, OCP will not be abused in such a
way because it has mechanisms to maintain necessary state within the
connection.

HTH,

Alex.

On Fri, 27 Feb 2004, John G. Waclawsky wrote:



      
I have another question. Does an opes environment handle the
requirement of a peer interacting with another peer with a load
balancer between them. The situation is that I require two proxies
to provide a service.  An "A" proxy and a "B" proxy that are peers
in providing the service to a data flow. Because of the scale, the
likely deployment will involve multiple boxes of types A and B. This
means I will have two groups of boxes with a load balancer between
them. I wish to dynamically associate an specific box of type A with
a specific Box of type B (across the load balancer) and a particular
flow. Is it possible to perform peer discovery and the dynamic
association between the two peers and a flow within the opes
framework? Thanks for any help and guidance.

Regards  John

John G. Waclawsky wrote:



        
Alex, I very much appreciate your help and the additional
information. I need a little time to digest this and think some more
about my problem and opes "needs"....
Thanks.   Regards  John

Alex Rousskov wrote:



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





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




              
John,

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

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

  Figure A.

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

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

  Figure B.

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

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

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

  Figure C.

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


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

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

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





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




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





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




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





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




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





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




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





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




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





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




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





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




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

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

Alex.
--------------080909070800030807000006-- From ORCGXX@kdt.de Thu Mar 4 03:39:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29175 for ; Thu, 4 Mar 2004 03:39:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyoOY-00020v-00 for opes-archive@ietf.org; Thu, 04 Mar 2004 03:39:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyoMD-0001Mj-00 for opes-archive@ietf.org; Thu, 04 Mar 2004 03:37:30 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyoLD-0001A2-01 for opes-archive@ietf.org; Thu, 04 Mar 2004 03:36:27 -0500 Received: from adsl-68-252-236-23.dsl.chcgil.ameritech.net ([68.252.236.23]) by mx2.foretec.com with smtp (Exim 4.24) id 1AyoHB-0001FX-TO for opes-archive@ietf.org; Thu, 04 Mar 2004 03:32:18 -0500 Message-ID: From: "Evangelina Randle" To: opes-archive@ietf.org Subject: Can't get the job because you don't have a university degree? Wrong! Date: Thu, 04 Mar 2004 04:34:46 -0400 X-Mailer: dinnerware telex bristle-crew: wesley cat escadrille MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--8229933048710054606" X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=6.2 required=5.0 tests=HTML_60_70, HTML_FONTCOLOR_UNSAFE,HTML_FONT_BIG,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,OBFUSCATING_COMMENT,PLING_QUERY autolearn=no version=2.60 X-Spam-Report: * 0.2 PLING_QUERY Subject has exclamation mark and question mark * 0.1 HTML_60_70 BODY: Message is 60% to 70% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text ----8229933048710054606 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable GET
et deputation tome angel doctrinaire argonne = gradient toenail headland nymphomaniac propellant put orthography announce= brent cynthia bottom serviceberry decompression fame particle continuatio= n squire stromberg=20 ----8229933048710054606-- From klneujbrtliaa@mtvn.com Thu Mar 4 04:44:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03856 for ; Thu, 4 Mar 2004 04:44:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AypOt-00011A-00 for opes-archive@ietf.org; Thu, 04 Mar 2004 04:44:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AypNr-0000oJ-00 for opes-archive@ietf.org; Thu, 04 Mar 2004 04:43:16 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AypMz-0000dR-00 for opes-archive@ietf.org; Thu, 04 Mar 2004 04:42:21 -0500 Received: from [220.194.101.125] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1AypMw-0002l0-3i for opes-archive@ietf.org; Thu, 04 Mar 2004 04:42:22 -0500 From: "Winfred Johnston" To: Subject: Pain & Anxiety Medication Date: Thu, 04 Mar 2004 14:51:16 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--6613010281773419296" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: AOL 7.0 for Windows US sub 118 Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=14.6 required=5.0 tests=BIZ_TLD,FORGED_AOL_HTML, FORGED_MUA_AOL_FROM,FORGED_RCVD_NET_HELO,HTML_20_30, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,HTML_WEB_BUGS,MIME_HTML_NO_CHARSET, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE, MISSING_OUTLOOK_NAME,RCVD_NUMERIC_HELO autolearn=no version=2.60 X-Spam-Report: * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.6 HTML_WEB_BUGS BODY: Image tag intended to identify you * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 4.3 FORGED_MUA_AOL_FROM Forged mail pretending to be from AOL (by From) * 1.8 FORGED_AOL_HTML AOL can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't ----6613010281773419296 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

Almost 75% OFF ON HUNDREDS OF MEDICATIONS
Absolutely No Doctor Appointment Needed!

Order prescription medication including weight loss/diet pill, skin care, birth control, muscle relaxants, high level pain relief, anxiety, prescription sleeping aids, anti-depressant medications and more.

The product will be filled and shipped by a US licensed pharmacist overnight to your door, immediately and discreetly.

We make it easier and faster than ever to get the medications you need!

Order by 2 pm EST and you get your meds tomorrow.

Get Your Meds Here and Save!

Pplea skillful lain russula downcast ? Einsular spontaneity troll lisp thumbnail cake clogging kuwait amethystine derivate !! Fhuntley utrecht alderman plantain stringent dogmatic ago bogota companionway arizona docile turban edict Mhorn doctoral depression bathrobe copter felix analyst academia . Srare round snyder ashamed dave cancer mainstay churchwoman debarring !! Kdecode telephotography bromine drop metamorphic stuyvesant castor demurred apology camouflage bracelet captaincy permit pert deceit boorish fenugreek consanguineous twigging empathy clapeyron ratepayer splash waylay martian proportionate bearish gemini spearmint ileum neuralgia circumpolar curd dragging congruent .Hcarl cub atchison trudy border groton diet apparent pole splurge fishmonger din ? Nallen camille butyl proxy affine wistful hobby godsend drury illicit mollie cocaine ehrlich broadside consonantal cankerworm gibbon plumbago !! Rtriassic anhydrite commonwealth bereft ideate adverse relinquish machiavelli Brestraint foist choose alienate suggestion doesn't wert gneiss babysitting !!! Lfrancisco eleazar yeoman affable coloratura bradley chord sera isolde epicurean asexual being cerise flatworm gainful gnostic dane child populous allot bridal roar creed ? Edial immigrate kulak diety drool fischer cerebrate anyway answer actress britannica augustus betwixt congressman bladder brockle anvil privy sure tass zorn diplomat wade aghast alberich alpha halvah rump laughingstock obscene crossover brainwash anomaly gusset makeshift broth interception blank .Zchalk chemisorb credible cherokee cauliflower madame mnemonic viscosity emirate betoken elephantine ; Celectroencephalography disney joaquin hydrochemistry intention aphasia antiphonal bronco cub expansion exculpate broke giuliano overture chair ! Zbesiege nit statuary dogmatism conservatory hubbard appanage inhumane bellini babel blum il tardy propelled steal loki epigraph jimenez ouzel abbreviate

If this notice has reached you in error, please notify us by clicking here
----6613010281773419296-- From owner-ietf-openproxy@mail.imc.org Fri Mar 5 23:38:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17200 for ; Fri, 5 Mar 2004 23:38:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzTZd-0004Sl-00 for opes-archive@ietf.org; Fri, 05 Mar 2004 23:38:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzTYL-0004En-00 for opes-archive@ietf.org; Fri, 05 Mar 2004 23:36:46 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AzTXW-00045F-00 for opes-archive@ietf.org; Fri, 05 Mar 2004 23:35:54 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i264N1vA055325; Fri, 5 Mar 2004 20:23:01 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i264N12t055324; Fri, 5 Mar 2004 20:23:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i264N0Ag055298 for ; Fri, 5 Mar 2004 20:23:00 -0800 (PST) (envelope-from markus@mhof.com) Received: from mhof.com (pcp04239370pcs.eatntn01.nj.comcast.net[68.39.63.215]) by comcast.net (sccrmhc12) with ESMTP id <2004030604230001200gpkc7e> (Authid: biena2004); Sat, 6 Mar 2004 04:23:00 +0000 Message-ID: <4049522D.8080208@mhof.com> Date: Fri, 05 Mar 2004 23:23:09 -0500 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.5+ (Windows/20040305) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: An opes usage question. References: <3FFC8D88.7020506@cisco.com> <3FFD9E35.6080607@cisco.com> <3FFDC1CE.7060809@cisco.com> <403F9EBE.8030709@cisco.com> <403FB970.7060400@cisco.com> <40461F07.3080104@cisco.com> In-Reply-To: <40461F07.3080104@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit John G. Waclawsky wrote: > Let's assume, for a specific example, a network allows access to premium > content that is billable by the number of bytes being delivered. The > content flows to the users from a premium content server through a pool > of billing gateway proxies and then proceeds to the next stage where the > content may be modified by other proxies for rendering on a user's > device (color to black/white, compressed for efficiency, adding > advertisements or banners etc.). If any particular flow adaptation > reduces the number of bytes then billing needs to be adjusted. My first question about this specific example would be why the billing is done before the adaptation. If the user is billed for the adapted content, do the billing after the adaptation and there's no need for the kind of "callout server interaction" you're talking about, right? Anyway, I believe the problem you're interested in boils down to tracing callout servers that did some earlier operations on the message. In your hypothetic example above, the adaptation server would have to be able to identify (the IP address?) of the billing server, so that it can contact the billing server, right? Could the OPES tracing functionality be of any help? -Markus From owner-ietf-openproxy@mail.imc.org Sat Mar 6 13:29:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29484 for ; Sat, 6 Mar 2004 13:29:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzgYU-0000oh-00 for opes-archive@ietf.org; Sat, 06 Mar 2004 13:29:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzgXY-0000gU-00 for opes-archive@ietf.org; Sat, 06 Mar 2004 13:28:49 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AzgWf-0000YJ-00 for opes-archive@ietf.org; Sat, 06 Mar 2004 13:27:53 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i26IFZ6c070141; Sat, 6 Mar 2004 10:15:35 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i26IFZ2R070139; Sat, 6 Mar 2004 10:15:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i26IFYl4070092 for ; Sat, 6 Mar 2004 10:15:34 -0800 (PST) (envelope-from jgw@cisco.com) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 06 Mar 2004 10:28:32 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i26IFUiQ028371; Sat, 6 Mar 2004 10:15:30 -0800 (PST) Received: from cisco.com (rtp-vpn3-537.cisco.com [10.82.218.28]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQY51593; Sat, 6 Mar 2004 10:15:29 -0800 (PST) Message-ID: <404A153E.4090203@cisco.com> Date: Sat, 06 Mar 2004 13:15:26 -0500 From: "John G. Waclawsky" Reply-To: jgw@cisco.com Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus Hofmann CC: OPES Group Subject: Re: An opes usage question. References: <3FFC8D88.7020506@cisco.com> <3FFD9E35.6080607@cisco.com> <3FFDC1CE.7060809@cisco.com> <403F9EBE.8030709@cisco.com> <403FB970.7060400@cisco.com> <40461F07.3080104@cisco.com> <4049522D.8080208@mhof.com> In-Reply-To: <4049522D.8080208@mhof.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Markus, thanks for your comments. Depending on what is being done billing could be done after adaptation but this doesn't solve the general case and always makes billing the last stage in the opes proxy pipeline. I think this would overly restrict opes configurations and probably cause issues elsewhere? Also, this restriction might not be practical especially if billing is done in the network where the content is located and adaptation is done in another network. In fact, the content may not even be delivered because of policy in the access network, e.g. parental controls is one situation that comes to mind. In my particular situation the billing server address for each particular flow must be in the opes traces to be used by any downstream proxy and if there are multiple proxy addresses present which one would be the billing proxy? I am not sure the tracing functionality will help but I will investigate. Thanks for the discussion Regards John Markus Hofmann wrote: > > John G. Waclawsky wrote: > >> Let's assume, for a specific example, a network allows access to >> premium content that is billable by the number of bytes being >> delivered. The content flows to the users from a premium content >> server through a pool of billing gateway proxies and then proceeds to >> the next stage where the content may be modified by other proxies for >> rendering on a user's device (color to black/white, compressed for >> efficiency, adding advertisements or banners etc.). If any particular >> flow adaptation reduces the number of bytes then billing needs to be >> adjusted. > > > My first question about this specific example would be why the billing > is done before the adaptation. If the user is billed for the adapted > content, do the billing after the adaptation and there's no need for > the kind of "callout server interaction" you're talking about, right? > > Anyway, I believe the problem you're interested in boils down to > tracing callout servers that did some earlier operations on the > message. In your hypothetic example above, the adaptation server would > have to be able to identify (the IP address?) of the billing server, > so that it can contact the billing server, right? Could the OPES > tracing functionality be of any help? > > -Markus > > > > From owner-ietf-openproxy@mail.imc.org Sat Mar 6 14:27:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01042 for ; Sat, 6 Mar 2004 14:27:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzhSY-0001DL-00 for opes-archive@ietf.org; Sat, 06 Mar 2004 14:27:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzhRa-00014l-00 for opes-archive@ietf.org; Sat, 06 Mar 2004 14:26:43 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AzhQZ-0000pk-00 for opes-archive@ietf.org; Sat, 06 Mar 2004 14:25:39 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i26JEwqg073500; Sat, 6 Mar 2004 11:14:58 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i26JEvn1073499; Sat, 6 Mar 2004 11:14:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail.radioburst.com (mail.esmartstart.com [66.119.143.50]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i26JEuij073493 for ; Sat, 6 Mar 2004 11:14:57 -0800 (PST) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by mail.radioburst.com (8.12.8/8.12.8) with ESMTP id i26JErqg004793; Sat, 6 Mar 2004 12:14:54 -0700 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id i26JDVtt030204; Sat, 6 Mar 2004 12:13:31 -0700 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i26JDUGf030200; Sat, 6 Mar 2004 12:13:30 -0700 Date: Sat, 6 Mar 2004 12:13:30 -0700 Message-Id: <200403061913.i26JDUGf030200@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: jgw@cisco.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage <404A153E.4090203@cisco.com> Subject: Re: An opes usage question. X-esmartscan-MailScanner: Found to be clean Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 If the billing is based on actual bytes delivered to the consumer, there must be a business relationship between the billing stage servers and adaptation servers. The relationship will usually allow the adaptation servers to cache the content and report to the billing servers about the number of bytes delivered. However, the reporting is a reverse flow in the client-server model, and that is why it seems problematical. By convention, the adaptation server might make a request back to the provider with the number of bytes encoded in the request, or it might, on occasion, upload a report. The rules governing this behavior would most naturally be encoded on the adaptation server, not on the OPES callout server. So, this seems to me to be an issue for the rules language. An alternative model would have this byte reporting functionality handled on the callout server, and it would directly contact the provider's billing service with reports. Hilarie From owner-ietf-openproxy@mail.imc.org Sat Mar 6 17:28:56 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07389 for ; Sat, 6 Mar 2004 17:28:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzkHy-0004DL-00 for opes-archive@ietf.org; Sat, 06 Mar 2004 17:28:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzkH2-00045B-00 for opes-archive@ietf.org; Sat, 06 Mar 2004 17:28:01 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1AzkGV-0003x4-00 for opes-archive@ietf.org; Sat, 06 Mar 2004 17:27:27 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i26MCZnV083538; Sat, 6 Mar 2004 14:12:36 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i26MCZ18083535; Sat, 6 Mar 2004 14:12:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i26MCYgo083508 for ; Sat, 6 Mar 2004 14:12:35 -0800 (PST) (envelope-from jgw@cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 06 Mar 2004 14:12:50 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i26MBlF8015214; Sat, 6 Mar 2004 14:11:47 -0800 (PST) Received: from cisco.com (rtp-vpn3-537.cisco.com [10.82.218.28]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQY56275; Sat, 6 Mar 2004 14:11:45 -0800 (PST) Message-ID: <404A4CA1.1000309@cisco.com> Date: Sat, 06 Mar 2004 17:11:45 -0500 From: "John G. Waclawsky" Reply-To: jgw@cisco.com Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "The Purple Streak, Hilarie Orman" CC: ietf-openproxy@imc.org Subject: Re: An opes usage question. References: <200403061913.i26JDUGf030200@localhost.localdomain> In-Reply-To: <200403061913.i26JDUGf030200@localhost.localdomain> Content-Type: multipart/alternative; boundary="------------020900030807060104010800" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_FONTCOLOR_UNKNOWN, HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------020900030807060104010800 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thanks for your comments Hilarie. My comments are in-line below. The Purple Streak, Hilarie Orman wrote: >If the billing is based on actual bytes delivered to the consumer, >there must be a business relationship between the billing stage >servers and adaptation servers. The relationship will usually allow > I think we are talking about the same thing which I have been calling a "flow participant discovery" problem (not a services discovery problem). The question is how, within the opes framework, do I establish this business relationship between two proxies in different stages of a services pipeline separated by a load balancer. Packets can travel through the billing server and later be changed by any adaptation proxy where (in the billing by bytes case) bytes could be reduced (compression) or increased (adding banners or advertisements or other correlated content). Because of previous e-mails I have been considering both the billing server and any adaptation servers as opes proxies. ...I believe this is the simplest opes environment. >the adaptation servers to cache the content and report to the billing >servers about the number of bytes delivered. However, the reporting >is a reverse flow in the client-server model, and that is why it seems >problematical. By convention, the adaptation server might make a > I agree the reverse flow is a problem. >request back to the provider with the number of bytes encoded in the >request, or it might, on occasion, upload a report. The rules >governing this behavior would most naturally be encoded on the >adaptation server, not on the OPES callout server. So, this seems to >me to be an issue for the rules language. > I am not following your logic here. I am working with a simple proxy to proxy opes framework and not doing any callouts. Am I missing something? Please clarify. > >An alternative model would have this byte reporting functionality >handled on the callout server, and it would directly contact >the provider's billing service with reports. > >Hilarie > > > --------------020900030807060104010800 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks for your comments Hilarie. My comments are in-line below.

The Purple Streak, Hilarie Orman wrote:
If the billing is based on actual bytes delivered to the consumer,
there must be a business relationship between the billing stage
servers and adaptation servers.  The relationship will usually allow
I think we are talking about the same thing which I have been calling a "flow participant discovery" problem (not a services discovery problem). The question is how, within the opes framework, do I establish this business relationship between two proxies in different stages of a services pipeline separated by a load balancer. Packets can travel through the billing server and later be changed by any adaptation proxy where (in the billing by bytes case) bytes could be reduced (compression) or increased (adding banners or advertisements or other correlated content). Because of previous e-mails I have been considering both the billing server and any adaptation servers as opes proxies. ...I believe this is the simplest opes environment.
the adaptation servers to cache the content and report to the billing
servers about the number of bytes delivered.  However, the reporting
is a reverse flow in the client-server model, and that is why it seems
problematical.  By convention, the adaptation server might make a
I agree the reverse flow is a problem.
request back to the provider with the number of bytes encoded in the
request, or it might, on occasion, upload a report.  The rules
governing this behavior would most naturally be encoded on the
adaptation server, not on the OPES callout server.  So, this seems to
me to be an issue for the rules language.
I am not following your logic here. I am working with a simple proxy to proxy opes framework and not doing any callouts. Am I missing something? Please clarify.

An alternative model would have this byte reporting functionality
handled on the callout server, and it would directly contact
the provider's billing service with reports.

Hilarie
--------------020900030807060104010800-- From owner-ietf-openproxy@mail.imc.org Sun Mar 7 14:53:54 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02370 for ; Sun, 7 Mar 2004 14:53:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B04LS-00065m-00 for opes-archive@ietf.org; Sun, 07 Mar 2004 14:53:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B04KU-0005yO-00 for opes-archive@ietf.org; Sun, 07 Mar 2004 14:52:54 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B04Jb-0005qB-00 for opes-archive@ietf.org; Sun, 07 Mar 2004 14:51:59 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i27Je8pA027313; Sun, 7 Mar 2004 11:40:08 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i27Je891027312; Sun, 7 Mar 2004 11:40:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail.radioburst.com (mail.esmartstart.com [66.119.143.50]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i27Je8Xw027306 for ; Sun, 7 Mar 2004 11:40:08 -0800 (PST) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by mail.radioburst.com (8.12.8/8.12.8) with ESMTP id i27Je4qg021023; Sun, 7 Mar 2004 12:40:05 -0700 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id i27JZHtt013547; Sun, 7 Mar 2004 12:35:18 -0700 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i27JZAWv013527; Sun, 7 Mar 2004 12:35:10 -0700 Date: Sun, 7 Mar 2004 12:35:10 -0700 Message-Id: <200403071935.i27JZAWv013527@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: jgw@cisco.com Cc: ietf-openproxy@imc.org In-reply-to: Yourmessage <404A4CA1.1000309@cisco.com> Subject: Re: An opes usage question. X-esmartscan-MailScanner: Found to be clean Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I think I see your problem, but I don't think you've established a need for communication between a specific billing server and a specific adaptation server. If this sort of thing is the model: ContentServer ContentServer ContentServer | | | \ | / \ | / ---------------------------- | Load Balancer | ---------------------------- | | | | | | | | | BillingServer BillingServer BillingServer | | | \ | / \ | / ---------------------------- | Load Balancer | ---------------------------- | | | | | | | | | AdaptServer AdaptServer AdaptServer | | | \ | / \ | / ---------------------------- | Load Balancer | ---------------------------- ..... Then I'd think that a Billing Server, upon seeing a request and response, might open a record saying "customer A got 10K bytes at 10 am", but the Adaptation Server would send back a "request" encoding the information "the customer really got 8K bytes at 10am". Your question is "how would that information get back to the same billing server?" and my first reaction is to say it just naturally would if they keep their connection open. If they decide to close the connection, then they need to agree on some kind of identifier for the transaction. If the Billing Server wants to include an OPES header with a unique ID, it can do that, and it can write a billing record into its database saying "8K bytes for unique ID xyzzy". The Adaptation Server then sends back the information, using the same ID. This might not get delivered to the same Billing Server, but it doesn't matter, it all goes into one database and can be correlated for billing purposes. In any case, the Adaptation Server needs to do extra communication, above and beyond proxying. That extra work should be encodable in the Rules Language, I believe. It is what I'd call a "local callout service". I agree that in general the problem of identifying entities in a pipeline that is interesting. Load-balancing, hot backup, failover, etc. all introduce some interesting problems. If there are provably correct solutions that can be encoded with OPES (without complicating it), that would be very interesting. Perhaps out of charter for OPES, but possibly worth a new WG (unless there already is one!). Inimitably, on Sat, 06 Mar 2004 at 17:11:45 -0500 John G. Waclawsky murmured: > I think we are talking about the same thing which I have been calling a > "flow participant discovery" problem (not a services discovery problem). > The question is how, within the opes framework, do I establish this > business relationship between two proxies in different stages of a > services pipeline separated by a load balancer. Packets can travel > through the billing server and later be changed by any adaptation proxy > where (in the billing by bytes case) bytes could be reduced > (compression) or increased (adding banners or advertisements or other > correlated content). Hilarie From owner-ietf-openproxy@mail.imc.org Mon Mar 8 00:02:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25840 for ; Mon, 8 Mar 2004 00:02:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Ctz-00077K-00 for opes-archive@ietf.org; Mon, 08 Mar 2004 00:02:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Ct3-00070S-00 for opes-archive@ietf.org; Mon, 08 Mar 2004 00:01:09 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B0Cst-0006tS-00 for opes-archive@ietf.org; Mon, 08 Mar 2004 00:01:00 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i284lVPM063161; Sun, 7 Mar 2004 20:47:31 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i284lV1s063160; Sun, 7 Mar 2004 20:47:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i284lUaQ063153 for ; Sun, 7 Mar 2004 20:47:31 -0800 (PST) (envelope-from geetham@india.hp.com) Received: from observer.india.hp.com (observer.india.hp.com [15.76.122.45]) by palrel10.hp.com (Postfix) with ESMTP id 1F6701C01DA9; Sun, 7 Mar 2004 20:47:36 -0800 (PST) Received: from india.hp.com (ob9786.india.hp.com [15.76.97.86]) by observer.india.hp.com with ESMTP (8.9.3 (PHNE_28760)/8.8.6 SMKit7.02) id KAA01601; Mon, 8 Mar 2004 10:17:45 +0530 (IST) Message-ID: <404BFAE4.8AE0ED25@india.hp.com> Date: Mon, 08 Mar 2004 10:17:32 +0530 From: Geetha Manjunath Organization: Hewlett Packard ISO X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "The Purple Streak, Hilarie Orman" Cc: jgw@cisco.com, ietf-openproxy@imc.org Subject: Re: An opes usage question. References: <200403061913.i26JDUGf030200@localhost.localdomain> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit On the contrary, I feel the accounting model should be slightly different in the OPES case: (a) We should charge the consumer for bytes output from the content server (we can debate on whether the #bytes is pre-adaptation or not) PLUS (b)A pay-per-use model for specific adaptation services used - this information can be provided to the billing server by the adaptation server. Comments? regards Geetha "The Purple Streak, Hilarie Orman" wrote: > > If the billing is based on actual bytes delivered to the consumer, > there must be a business relationship between the billing stage > servers and adaptation servers. The relationship will usually allow > the adaptation servers to cache the content and report to the billing > servers about the number of bytes delivered. However, the reporting > is a reverse flow in the client-server model, and that is why it seems > problematical. By convention, the adaptation server might make a > request back to the provider with the number of bytes encoded in the > request, or it might, on occasion, upload a report. The rules > governing this behavior would most naturally be encoded on the > adaptation server, not on the OPES callout server. So, this seems to > me to be an issue for the rules language. > > An alternative model would have this byte reporting functionality > handled on the callout server, and it would directly contact > the provider's billing service with reports. > > Hilarie From owner-ietf-openproxy@mail.imc.org Mon Mar 8 10:59:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09834 for ; Mon, 8 Mar 2004 10:59:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0NAP-0002U5-00 for opes-archive@ietf.org; Mon, 08 Mar 2004 10:59:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0N9S-0002If-00 for opes-archive@ietf.org; Mon, 08 Mar 2004 10:58:47 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B0N8k-00029U-00 for opes-archive@ietf.org; Mon, 08 Mar 2004 10:58:02 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i28FkWx6078028; Mon, 8 Mar 2004 07:46:32 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i28FkWqi078026; Mon, 8 Mar 2004 07:46:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i28FkVIA078014 for ; Mon, 8 Mar 2004 07:46:31 -0800 (PST) (envelope-from jgw@cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 08 Mar 2004 07:59:08 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i28FkQF8017332; Mon, 8 Mar 2004 07:46:26 -0800 (PST) Received: from cisco.com (rtp-vpn1-453.cisco.com [10.82.225.197]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQZ11134; Mon, 8 Mar 2004 07:46:25 -0800 (PST) Message-ID: <404C9550.2000305@cisco.com> Date: Mon, 08 Mar 2004 10:46:24 -0500 From: "John G. Waclawsky" Reply-To: jgw@cisco.com Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geetha Manjunath CC: "The Purple Streak, Hilarie Orman" , ietf-openproxy@imc.org Subject: Re: An opes usage question. References: <200403061913.i26JDUGf030200@localhost.localdomain> <404BFAE4.8AE0ED25@india.hp.com> In-Reply-To: <404BFAE4.8AE0ED25@india.hp.com> Content-Type: multipart/alternative; boundary="------------060306070707060008050508" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------060306070707060008050508 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thanks for your input Geetha. I have found that billing can be a difficult problem because people expect solutions to fit into their existing billing model/system, no matter how it might work (it might be good for some things and a problem for others). So a solution that accommodates a number of billing approaches would be the best because it is flexible and will be able to handle in-line billing, pre-paid, pay-per-use...etc. Also, I'd like to build an open infrastructure to solve my problem. The feedback that I have gotten from past opes e-mails leads me to believe that using the opes framework would be the best way accomplish this important goal. But is seems the opes framework needs a solution to the flow participant discovery problem. I emphasis the word discovery. My thoughts are that once you know the other flow participant you can always establish out of band communications to do whatever you need. This seems to be the most flexible approach. Your thoughts? Regards John Geetha Manjunath wrote: >On the contrary, I feel the accounting model should be slightly >different in the OPES case: >(a) We should charge the consumer for bytes output from the content >server (we can debate on whether the #bytes is pre-adaptation or not) >PLUS >(b)A pay-per-use model for specific adaptation services used - this >information can be provided to the billing server by the adaptation >server. > >Comments? > >regards >Geetha > > >"The Purple Streak, Hilarie Orman" wrote: > > >>If the billing is based on actual bytes delivered to the consumer, >>there must be a business relationship between the billing stage >>servers and adaptation servers. The relationship will usually allow >>the adaptation servers to cache the content and report to the billing >>servers about the number of bytes delivered. However, the reporting >>is a reverse flow in the client-server model, and that is why it seems >>problematical. By convention, the adaptation server might make a >>request back to the provider with the number of bytes encoded in the >>request, or it might, on occasion, upload a report. The rules >>governing this behavior would most naturally be encoded on the >>adaptation server, not on the OPES callout server. So, this seems to >>me to be an issue for the rules language. >> >>An alternative model would have this byte reporting functionality >>handled on the callout server, and it would directly contact >>the provider's billing service with reports. >> >>Hilarie >> >> > > > --------------060306070707060008050508 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks for your input Geetha. I have found that billing can be a difficult problem because people expect solutions to fit into their existing billing model/system, no matter how it might work (it might be good for some things and a problem for others). So a solution that accommodates a number of  billing approaches would be the best because it is flexible and will be able to handle in-line billing, pre-paid, pay-per-use...etc.

Also, I'd like to build an open infrastructure to solve my problem. The feedback that I have gotten from past opes e-mails leads me to believe that using the opes framework would be the best way accomplish this important  goal. But is seems the opes framework needs a solution to the flow participant discovery problem. I emphasis the word discovery. My thoughts are that once you know the other flow participant you can always establish out of band communications to do whatever you need. This seems to be the most flexible approach. Your thoughts?
Regards  John

Geetha Manjunath wrote:
On the contrary, I feel the accounting model should be slightly
different in the OPES case:
(a) We should charge the consumer for bytes output from the content
server (we can debate on whether the #bytes is pre-adaptation or not)
PLUS
(b)A pay-per-use model for specific adaptation services used - this
information can be provided  to the billing server by the adaptation
server.

Comments?

regards
Geetha


"The Purple Streak, Hilarie Orman" wrote:
  
If the billing is based on actual bytes delivered to the consumer,
there must be a business relationship between the billing stage
servers and adaptation servers.  The relationship will usually allow
the adaptation servers to cache the content and report to the billing
servers about the number of bytes delivered.  However, the reporting
is a reverse flow in the client-server model, and that is why it seems
problematical.  By convention, the adaptation server might make a
request back to the provider with the number of bytes encoded in the
request, or it might, on occasion, upload a report.  The rules
governing this behavior would most naturally be encoded on the
adaptation server, not on the OPES callout server.  So, this seems to
me to be an issue for the rules language.

An alternative model would have this byte reporting functionality
handled on the callout server, and it would directly contact
the provider's billing service with reports.

Hilarie
--------------060306070707060008050508-- From owner-ietf-openproxy@mail.imc.org Mon Mar 8 11:01:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09894 for ; Mon, 8 Mar 2004 11:01:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0NCP-0002wQ-00 for opes-archive@ietf.org; Mon, 08 Mar 2004 11:01:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0NAR-0002Uc-00 for opes-archive@ietf.org; Mon, 08 Mar 2004 10:59:49 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B0N9W-0002Iq-00 for opes-archive@ietf.org; Mon, 08 Mar 2004 10:58:51 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i28FiOdj077930; Mon, 8 Mar 2004 07:44:24 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i28FiOhd077929; Mon, 8 Mar 2004 07:44:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i28FiNe8077921 for ; Mon, 8 Mar 2004 07:44:23 -0800 (PST) (envelope-from jgw@cisco.com) Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i28FhuLM020853; Mon, 8 Mar 2004 07:43:57 -0800 (PST) Received: from cisco.com (rtp-vpn1-453.cisco.com [10.82.225.197]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQZ10992; Mon, 8 Mar 2004 07:43:55 -0800 (PST) Message-ID: <404C94BA.50702@cisco.com> Date: Mon, 08 Mar 2004 10:43:54 -0500 From: "John G. Waclawsky" Reply-To: jgw@cisco.com Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "The Purple Streak, Hilarie Orman" CC: ietf-openproxy@imc.org Subject: Re: An opes usage question. References: <200403071935.i27JZAWv013527@localhost.localdomain> In-Reply-To: <200403071935.i27JZAWv013527@localhost.localdomain> Content-Type: multipart/alternative; boundary="------------070408040205090207090905" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------070408040205090207090905 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit My comments are in-line below: The Purple Streak, Hilarie Orman wrote: >I think I see your problem, but I don't think you've established a >need for communication between a specific billing server and a >specific adaptation server. If this sort of thing is the model: > But I believe a solution is needed that allows communication between a specific billing server and a specific adaptation server. I think or thought that was clear from the past e-mails. > > ContentServer ContentServer ContentServer > | | | > \ | / > \ | / > ---------------------------- > | Load Balancer | > ---------------------------- > | | | > | | | > | | | > BillingServer BillingServer BillingServer > | | | > \ | / > \ | / > ---------------------------- > | Load Balancer | > ---------------------------- > | | | > | | | > | | | > AdaptServer AdaptServer AdaptServer > | | | > \ | / > \ | / > ---------------------------- > | Load Balancer | > ---------------------------- > ..... > > > Yes, that is the model. >Then I'd think that a Billing Server, upon seeing a request and >response, might open a record saying "customer A got 10K bytes at 10 >am", but the Adaptation Server would send back a "request" encoding >the information "the customer really got 8K bytes at 10am". Your >question is "how would that information get back to the same billing >server?" and my first reaction is to say it just naturally would >if they keep their connection open. > I am not sure I understand why this would be true if there is a load balancer between stages of the services pipeline? Also connections can be very short lived. >If they decide to close the connection, then they need to agree on >some kind of identifier for the transaction. If the Billing Server >wants to include an OPES header with a unique ID, it can do that, and >it can write a billing record into its database saying "8K bytes for >unique ID xyzzy". The Adaptation Server then sends back the >information, using the same ID. This might not get delivered to the >same Billing Server, but it doesn't matter, it all goes into one >database and can be correlated for billing purposes. > You are proposing billing system changes. This introduces an additional dependency and complicates deployment and can lead to other problems. I would prefer not to have to modify the billing system. >In any case, the Adaptation Server needs to do extra communication, >above and beyond proxying. That extra work should be encodable in >the Rules Language, I believe. It is what I'd call a "local callout >service". > I believe this extra communication can be done out of band Is the reconciliation of billing information what you are referring to as a local call out service? > >I agree that in general the problem of identifying entities in a >pipeline that is interesting. Load-balancing, hot backup, failover, >etc. all introduce some interesting problems. If there are provably >correct solutions that can be encoded with OPES (without complicating >it), that would be very interesting. Perhaps out of charter for OPES, >but possibly worth a new WG (unless there already is one!). > As I mentioned before, I believe that any extra communication (for billing reconciliation) can be done out of band and therefore may not have to be part of opes, but I believe finding a flow participant is an opes issue that needs resolution. Thanks for the discussion Regards John > >Inimitably, on Sat, 06 Mar 2004 at 17:11:45 -0500 John G. Waclawsky >murmured: > > >> I think we are talking about the same thing which I have been calling a >> "flow participant discovery" problem (not a services discovery problem). >> The question is how, within the opes framework, do I establish this >> business relationship between two proxies in different stages of a >> services pipeline separated by a load balancer. Packets can travel >> through the billing server and later be changed by any adaptation proxy >> where (in the billing by bytes case) bytes could be reduced >> (compression) or increased (adding banners or advertisements or other >> correlated content). >> >> > >Hilarie > > > > --------------070408040205090207090905 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit My comments are in-line below:

The Purple Streak, Hilarie Orman wrote:
I think I see your problem, but I don't think you've established a
need for communication between a specific billing server and a
specific adaptation server.  If this sort of thing is the model:
But I believe a solution is needed that allows communication between a specific billing server and a specific adaptation server. I think or thought that was clear from the past e-mails.

  ContentServer     ContentServer     ContentServer    
        |               |                |
        \               |               /
         \              |              /
          ----------------------------
          |      Load Balancer       |
          ----------------------------
            |           |         |
            |           |         |
            |           |         |
  BillingServer  BillingServer   BillingServer
        |               |                |
        \               |               /
         \              |              /
          ----------------------------
          |      Load Balancer       |
          ----------------------------
            |           |         |
            |           |         |
            |           |         |
       AdaptServer  AdaptServer  AdaptServer
        |               |                |
        \               |               /
         \              |              /
          ----------------------------
          |      Load Balancer       |
          ----------------------------
                      .....
Yes, that is the model. 
Then I'd think that a Billing Server, upon seeing a request and
response, might open a record saying "customer A got 10K bytes at 10
am", but the Adaptation Server would send back a "request" encoding
the information "the customer really got 8K bytes at 10am".  Your
question is "how would that information get back to the same billing
server?"  and my first reaction is to say it just naturally would
if they keep their connection open.
I am not sure I understand why this would be true if there is a load balancer between stages of the services pipeline?  Also connections can be very short lived.
If they decide to close the connection, then they need to agree on
some kind of identifier for the transaction.  If the Billing Server
wants to include an OPES header with a unique ID, it can do that, and
it can write a billing record into its database saying "8K bytes for
unique ID xyzzy".  The Adaptation Server then sends back the
information, using the same ID.  This might not get delivered to the
same Billing Server, but it doesn't matter, it all goes into one
database and can be correlated for billing purposes.
You are proposing billing system changes. This introduces an additional dependency and complicates deployment and can lead to other problems. I would prefer not to have to modify the billing system.
In any case, the Adaptation Server needs to do extra communication,
above and beyond proxying.  That extra work should be encodable in
the Rules Language, I believe.  It is what I'd call a "local callout
service".
I believe this extra communication can be done out of band  Is the reconciliation of billing information what you are referring to as a local call out service?

I agree that in general the problem of identifying entities in a
pipeline that is interesting.  Load-balancing, hot backup, failover,
etc. all introduce some interesting problems.  If there are provably
correct solutions that can be encoded with OPES (without complicating
it), that would be very interesting.  Perhaps out of charter for OPES,
but possibly worth a new WG (unless there already is one!).
As I mentioned before, I believe that any extra communication (for billing reconciliation) can be done out of band and therefore may not have to be part of opes, but I believe finding a  flow participant is an opes issue that needs resolution.

Thanks for the discussion
Regards John

Inimitably, on Sat, 06 Mar 2004 at 17:11:45 -0500 John G. Waclawsky
murmured:
  
 I think we are talking about the same thing which I have been calling a 
 "flow participant discovery" problem (not a services discovery problem). 
 The question is how, within the opes framework, do I establish this 
 business relationship between two proxies in different stages of a 
 services pipeline separated by a load balancer. Packets can travel 
 through the billing server and later be changed by any adaptation proxy 
 where (in the billing by bytes case) bytes could be reduced 
 (compression) or increased (adding banners or advertisements or other 
 correlated content). 
    

Hilarie
--------------070408040205090207090905-- From owner-ietf-openproxy@mail.imc.org Mon Mar 8 12:46:46 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16015 for ; Mon, 8 Mar 2004 12:46:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Oq1-00006D-00 for opes-archive@ietf.org; Mon, 08 Mar 2004 12:46:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0OoB-0007Ko-00 for opes-archive@ietf.org; Mon, 08 Mar 2004 12:44:58 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B0OmQ-0006or-00 for opes-archive@ietf.org; Mon, 08 Mar 2004 12:43:06 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i28HUpRY084235; Mon, 8 Mar 2004 09:30:51 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i28HUpJX084234; Mon, 8 Mar 2004 09:30:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from postale.fourelle.com (webmail.venturiwireless.com [199.26.153.90]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i28HUobB084222 for ; Mon, 8 Mar 2004 09:30:50 -0800 (PST) (envelope-from kramadas@venturiwireless.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40533.1595ADF3" Subject: RE: An opes usage question. Date: Mon, 8 Mar 2004 09:30:43 -0800 Message-ID: <2F6114FBB1915B48B96170AE7D4BEAB24E1F78@postale.fourelle.com> Thread-Topic: An opes usage question. Thread-Index: AcQFKX3KDD/awF9yQq+zQNuaOaT3zgAAx5uA From: "Krishna Ramadas" To: , "Geetha Manjunath" Cc: "The Purple Streak, Hilarie Orman" , Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_70_80, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C40533.1595ADF3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable These are good discussions on practicality. For a framework such as OPES to gain acceptance with the operator community, it must address practical structural solutions. Capacity limitation of servers (such as an OPES proxy server) is the primary impetus to introduce load balancers in a network. Load balancers not only address the linear growth issues of an operator but also simplify provisioning, management and billing tasks. In this regard, the flexibility in current OPES framework definitions is good, any extensions should retain this. =20 Since Billing servers, generally perform offline processing (not in line), they may not be seen, placed in the data path. Perhaps, the configuration below implies that the billing functionality of the server is in addition to an adaptation processing functionality. Is this correct? =20 =20 ContentServer ContentServer ContentServer =20 | | | \ | / \ | / ---------------------------- | Load Balancer | ---------------------------- | | | | | | | | | BillingServer BillingServer BillingServer | | | \ | / \ | / ---------------------------- | Load Balancer | ---------------------------- | | | | | | | | | AdaptServer AdaptServer AdaptServer | | | \ | / \ | / ---------------------------- | Load Balancer | ---------------------------- ..... =20 =20 regards, krishna =20 Thanks for your input Geetha. I have found that billing can be a difficult problem because people expect solutions to fit into their existing billing model/system, no matter how it might work (it might be good for some things and a problem for others). So a solution that accommodates a number of billing approaches would be the best because it is flexible and will be able to handle in-line billing, pre-paid, pay-per-use...etc.=20 Also, I'd like to build an open infrastructure to solve my problem. The feedback that I have gotten from past opes e-mails leads me to believe that using the opes framework would be the best way accomplish this important goal. But is seems the opes framework needs a solution to the flow participant discovery problem. I emphasis the word discovery. My thoughts are that once you know the other flow participant you can always establish out of band communications to do whatever you need. This seems to be the most flexible approach. Your thoughts? Regards John Geetha Manjunath wrote: On the contrary, I feel the accounting model should be slightly different in the OPES case: (a) We should charge the consumer for bytes output from the content server (we can debate on whether the #bytes is pre-adaptation or not) PLUS (b)A pay-per-use model for specific adaptation services used - this information can be provided to the billing server by the adaptation server. =20 Comments? =20 regards Geetha =20 =20 "The Purple Streak, Hilarie Orman" wrote: =20 If the billing is based on actual bytes delivered to the consumer, there must be a business relationship between the billing stage servers and adaptation servers. The relationship will usually allow the adaptation servers to cache the content and report to the billing servers about the number of bytes delivered. However, the reporting is a reverse flow in the client-server model, and that is why it seems problematical. By convention, the adaptation server might make a request back to the provider with the number of bytes encoded in the request, or it might, on occasion, upload a report. The rules governing this behavior would most naturally be encoded on the adaptation server, not on the OPES callout server. So, this seems to me to be an issue for the rules language. =20 An alternative model would have this byte reporting functionality handled on the callout server, and it would directly contact the provider's billing service with reports. =20 Hilarie =20 =20 =20 ------_=_NextPart_001_01C40533.1595ADF3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

These are good discussions = on practicality. For a framework such as OPES to gain acceptance with the = operator community, it must address practical structural solutions. Capacity = limitation of servers (such as an OPES proxy server) is the primary impetus to = introduce load balancers in a network. Load balancers not only address the linear = growth issues of an operator but also simplify provisioning, management and = billing tasks. In this regard, the flexibility in current OPES framework = definitions is good, any extensions should retain this.

 

Since Billing servers, generally = perform offline processing (not in line), they may not be seen, placed in the = data path. Perhaps, the configuration below implies that the billing functionality = of the server is in addition to an adaptation processing functionality. Is this correct?

 

 

  = ContentServer     ContentServer     ContentServer    =

        |       &nbs= p;       |       &nbs= p;        |

        \       &nbs= p;       |       &nbs= p;       /

       &nbs= p; \       &nbs= p;      |       &nbs= p;      /

       &nbs= p;  ----------------------------

       &nbs= p;  |      Load Balancer       = |

       &nbs= p;  ----------------------------

       &nbs= p;    |       &nbs= p;   |       &nbs= p; |

       &nbs= p;    |       &nbs= p;   |       &nbs= p; |

       &nbs= p;    |       &nbs= p;   |       &nbs= p; |

  = BillingServer  BillingServer   BillingServer

        |       &nbs= p;       |       &nbs= p;        |

        \       &nbs= p;       |       &nbs= p;       /

       &nbs= p; \       &nbs= p;      |       &nbs= p;      /

       &nbs= p;  ----------------------------

       &nbs= p;  |      Load Balancer       = |

       &nbs= p;  ----------------------------

       &nbs= p;    |       &nbs= p;   |       &nbs= p; |

       &nbs= p;    |       &nbs= p;   |       &nbs= p; |

       &nbs= p;    |       &nbs= p;   |       &nbs= p; |

       = AdaptServer  AdaptServer  AdaptServer

        |       &nbs= p;       |       &nbs= p;        |

        \       &nbs= p;       |       &nbs= p;       /

       &nbs= p; \       &nbs= p;      |      =        &nbs= p;/

       &nbs= p;  ----------------------------

       &nbs= p;  |      Load Balancer       = |

       &nbs= p;  ----------------------------

       &nbs= p;            = ;  .....

 

 

regards,

krishna

 

Thanks for = your input Geetha. I have found that billing can be a difficult problem because = people expect solutions to fit into their existing billing model/system, no = matter how it might work (it might be good for some things and a problem for = others). So a solution that accommodates a number of  billing approaches would be = the best because it is flexible and will be able to handle in-line billing, pre-paid, pay-per-use...etc.

Also, I'd like to build an open infrastructure to solve my problem. The = feedback that I have gotten from past opes e-mails leads me to believe that using = the opes framework would be the best way accomplish this important  = goal. But is seems the opes framework needs a solution to the flow participant = discovery problem. I emphasis the word discovery. My thoughts are that once you = know the other flow participant you can always establish out of band = communications to do whatever you need. This seems to be the most flexible approach. Your thoughts?
Regards  John

Geetha Manjunath wrote:

On the contrary, I =
feel the accounting model should be =
slightly
different in the OPES =
case:
(a) We should charge the consumer for bytes =
output from the content
server (we can debate on whether the #bytes =
is pre-adaptation or not)
PLUS
(b)A pay-per-use model for specific =
adaptation services used - this
information can be provided  to the billing server by the =
adaptation
server.
 
Comments?
 
regards
Geetha
 
 
"The Purple Streak, Hilarie Orman" =
wrote:
  =

If the billing is based on actual bytes =
delivered to the consumer,
there must be a business relationship between =
the billing stage
servers and adaptation servers.  The relationship will usually =
allow
the adaptation servers to cache the content =
and report to the billing
servers about the number of bytes =
delivered.  However, the =
reporting
is a reverse flow in the client-server model, =
and that is why it seems
problematical.  By convention, the adaptation =
server might make a
request back to the provider with the number =
of bytes encoded in the
request, or it might, on occasion, upload a =
report.  The =
rules
governing this behavior would most naturally =
be encoded on the
adaptation server, not on the OPES callout =
server.  So, this seems =
to
me to be an issue for the rules =
language.
 
An alternative model would have this byte =
reporting functionality
handled on the callout server, and it would =
directly contact
the provider's billing service with =
reports.
 
Hilarie
    =

 
  =
------_=_NextPart_001_01C40533.1595ADF3-- From owner-ietf-openproxy@mail.imc.org Tue Mar 9 01:22:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25916 for ; Tue, 9 Mar 2004 01:22:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0ad4-0006Ql-00 for opes-archive@ietf.org; Tue, 09 Mar 2004 01:22:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0ac7-0006Ha-00 for opes-archive@ietf.org; Tue, 09 Mar 2004 01:21:16 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B0ab6-00066L-00 for opes-archive@ietf.org; Tue, 09 Mar 2004 01:20:12 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2967wU7035730; Mon, 8 Mar 2004 22:07:58 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2967voR035728; Mon, 8 Mar 2004 22:07:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2967usc035716 for ; Mon, 8 Mar 2004 22:07:57 -0800 (PST) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i29681uH060785; Mon, 8 Mar 2004 23:08:01 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i296811E060784; Mon, 8 Mar 2004 23:08:01 -0700 (MST) (envelope-from rousskov) Date: Mon, 8 Mar 2004 23:08:01 -0700 (MST) From: Alex Rousskov To: "John G. Waclawsky" cc: OPES Group , Krishna Ramadas Subject: Re: An opes usage question. In-Reply-To: <40461F07.3080104@cisco.com> Message-ID: References: <3FFC8D88.7020506@cisco.com> <3FFD9E35.6080607@cisco.com> <3FFDC1CE.7060809@cisco.com> <403F9EBE.8030709@cisco.com> <403FB970.7060400@cisco.com> <40461F07.3080104@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 I am afraid the latest discussion/diagrams unnecessary complicated things. We suddenly started talking about IP addresses of individual proxies, persistent connections between load balanced proxies, and other complicated low-level details that should be kept outside of most OPES protocols. Let's step back a little: On Wed, 3 Mar 2004, John G. Waclawsky wrote: > 1) The opes framework allows services to be distributed (or pipelined), > with incremental services being added to each traffic flow at each > stage. This is an opes proxy to proxy communication model. > 2) A pool of multiple opes proxies can be provisioned at each stage to > support a large number of flows > 3) Installing load balancers between stages to distribute the flows is > ok in an opes framework (and this is a typical business scenario). If > all the flow processing can be achieved in-line then there is no need to > identify any specific proxy in any pool. In this case we probably don't > care which previous stage opes proxy did the prior adaptation step. Agreed. > 4) The crux of the problem is how to share information between two > stages of the flow. This sending of metadata from one stage to a > previous stage will require knowledge of specific server addresses (a > more general case might be be to send the metadata in either direction). I hope the last statement is false. IMO, identifying or communicating directly with individual proxies behind a load balancer makes sane load balancing impossible. Sane load balancing, by definition, includes load balancing of identical proxies (identical from external protocol agents point of view). If all proxies are truly identical from external agents ping of view, there should be not reason to identify them individually. If proxies are not identical for any reason, then we are not load balancing them; we are managing a pool of different proxies, with some complex per-protocol selection criteria. The latter model is what origin server load balancing evolved into and is exactly why HTTP load balancing requires AI techniques and ugly hacks to work, despite the fact that pure HTTP is stateless. We should avoid this model (on a protocol level) if at all possible. In your specific case, this implies that external proxies must not try to identify individual proxies behind the load balancer. While we can build such identification mechanisms, the long-term effect would be the same as for HTTP: expensive and relatively rigid load balancing schemes causing headaches for all the parties involved. The task of such identification should be assigned to load balancers. If the protocol is designed correctly, a load balancer should be able to reliably identify the proxy/server it should talk to when the external proxy sends a follow-up message to the load balancer. We tried hard to make this possible with the OPES tracing approach. It should be possible in reverse direction as well. Instead of using this diagram: ContentServer ContentServer ContentServer | | | \ | / \ | / ---------------------------- | Load Balancer | ---------------------------- | | | | | | | | | BillingServer BillingServer BillingServer | | | \ | / \ | / ---------------------------- | Load Balancer | ---------------------------- | | | | | | | | | AdaptServer AdaptServer AdaptServer let's use the following diagram when designing your billing adjustment algorithm/protocol: ContentServer | BillingServer | AdaptServer and require that if any load balancing is introduced, it does not change the algorithm/protocol in any way. This implies that if IP addresses are used to identify proxies, then load balancers should put their own IP addresses instead of the addresses of the proxies being balanced (and embed known-to-balancer-only meta information to map flow ID to individual proxy address). OPES tracing allows for such substitutions and meta information, for example. The notification algorithms working in the opposite direction should allow them as well and can reuse the techniques discussed when OPES tracing was developed. In other words, instead of allowing a load balancer as a separate protocol entity that everybody has to worry about, you require that protocols are designed so that a group of load balanced agents is visible as a single agent, and nobody has to worry about the presence or specifics of load balancing (except for the load balancer itself). Can you think of any real world problem that cannot be solved using the above simplified framework? Can you think of a reason why load balancers will not be able to hide the presence of multiple proxies from the outside agents? In other words, is there a point in drawing load balancers and multiple proxies when discussing the protocols you need? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Tue Mar 9 14:36:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17151 for ; Tue, 9 Mar 2004 14:36:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0n29-0004Ek-00 for opes-archive@ietf.org; Tue, 09 Mar 2004 14:36:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0n1G-00044F-00 for opes-archive@ietf.org; Tue, 09 Mar 2004 14:36:03 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B0n0L-0003te-00 for opes-archive@ietf.org; Tue, 09 Mar 2004 14:35:05 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i29JIjGN059724; Tue, 9 Mar 2004 11:18:45 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i29JIjSs059723; Tue, 9 Mar 2004 11:18:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from postale.fourelle.com (webmail.venturiwireless.com [199.26.153.90]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i29JIfNF059703 for ; Tue, 9 Mar 2004 11:18:44 -0800 (PST) (envelope-from kramadas@venturiwireless.com) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: An opes usage question. Date: Tue, 9 Mar 2004 11:18:37 -0800 Message-ID: <2F6114FBB1915B48B96170AE7D4BEAB24E201E@postale.fourelle.com> Thread-Topic: An opes usage question. Thread-Index: AcQFnOXLtpzUlOG+TG+6emD3B/DWAAAaYwiw From: "Krishna Ramadas" To: "Alex Rousskov" , "John G. Waclawsky" Cc: "OPES Group" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i29JIiNF059718 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Alex, Perhaps, the recommendations that you make about using the current definitions within OPES are applicable. I understand that you are recommending the use of the "tracing" facility and the "meta data transfer" facility. OPES "tracing" is defined in the "An architecture for OPES" documents. In this context the document states that : "Providing the ability for in-band annotation MAY require header extensions on the application protocol that is used (e.g HTTP)". The document "HTTP adaptation for OPES" proceeds to define the use of tracing in the context of HTTP. Similar structures do not exist for supporting other applications, at the moment. Utilizing the "tracing" mechanism for flow discovery can work for HTTP. In fact HTTP 1.1, already defines a field "X-Forwarded-For" to help with such a discovery. The problem is with other applications. Meta Transfer is established as a requirement in the document "Requirements for OPES callout protocols (3.13)". Are you also implying that we embed meta-data in the traffic flow, just like trace information? Often, processing of meta-data is done in a background thread and not in the main thread for gaining processing efficiency. I had, therefore, understood that OCP should provide the meta-data-transfer support. Is this correct? In-flow transfer of meta-data requires support for application protocol, may be possible only with HTTP, currently. Transferring meta-data using OCP also becomes tricky when the callout and proxy roles are mixed within one physical entity, especially with load balancers separating the proxy stages. I'd like to get your ideas on meta data transfer, I may not have noticed some earlier discussions on this, any pointers will be greatly appreciated. Thanks Krishna BTW, the billing servers may never be in the traffic path like it is shown in the figures that we have been discussing. Instead, two stages of adaptation servers may be separated by load balancers. -----Original Message----- From: Alex Rousskov [mailto:rousskov@measurement-factory.com] Sent: Monday, March 08, 2004 10:08 PM To: John G. Waclawsky Cc: OPES Group; Krishna Ramadas Subject: Re: An opes usage question. I am afraid the latest discussion/diagrams unnecessary complicated things. We suddenly started talking about IP addresses of individual proxies, persistent connections between load balanced proxies, and other complicated low-level details that should be kept outside of most OPES protocols. Let's step back a little: On Wed, 3 Mar 2004, John G. Waclawsky wrote: > 1) The opes framework allows services to be distributed (or pipelined), > with incremental services being added to each traffic flow at each > stage. This is an opes proxy to proxy communication model. > 2) A pool of multiple opes proxies can be provisioned at each stage to > support a large number of flows > 3) Installing load balancers between stages to distribute the flows is > ok in an opes framework (and this is a typical business scenario). If > all the flow processing can be achieved in-line then there is no need to > identify any specific proxy in any pool. In this case we probably don't > care which previous stage opes proxy did the prior adaptation step. Agreed. > 4) The crux of the problem is how to share information between two > stages of the flow. This sending of metadata from one stage to a > previous stage will require knowledge of specific server addresses (a > more general case might be be to send the metadata in either direction). I hope the last statement is false. IMO, identifying or communicating directly with individual proxies behind a load balancer makes sane load balancing impossible. Sane load balancing, by definition, includes load balancing of identical proxies (identical from external protocol agents point of view). If all proxies are truly identical from external agents ping of view, there should be not reason to identify them individually. If proxies are not identical for any reason, then we are not load balancing them; we are managing a pool of different proxies, with some complex per-protocol selection criteria. The latter model is what origin server load balancing evolved into and is exactly why HTTP load balancing requires AI techniques and ugly hacks to work, despite the fact that pure HTTP is stateless. We should avoid this model (on a protocol level) if at all possible. In your specific case, this implies that external proxies must not try to identify individual proxies behind the load balancer. While we can build such identification mechanisms, the long-term effect would be the same as for HTTP: expensive and relatively rigid load balancing schemes causing headaches for all the parties involved. The task of such identification should be assigned to load balancers. If the protocol is designed correctly, a load balancer should be able to reliably identify the proxy/server it should talk to when the external proxy sends a follow-up message to the load balancer. We tried hard to make this possible with the OPES tracing approach. It should be possible in reverse direction as well. Instead of using this diagram: ContentServer ContentServer ContentServer | | | \ | / \ | / ---------------------------- | Load Balancer | ---------------------------- | | | | | | | | | BillingServer BillingServer BillingServer | | | \ | / \ | / ---------------------------- | Load Balancer | ---------------------------- | | | | | | | | | AdaptServer AdaptServer AdaptServer let's use the following diagram when designing your billing adjustment algorithm/protocol: ContentServer | BillingServer | AdaptServer and require that if any load balancing is introduced, it does not change the algorithm/protocol in any way. This implies that if IP addresses are used to identify proxies, then load balancers should put their own IP addresses instead of the addresses of the proxies being balanced (and embed known-to-balancer-only meta information to map flow ID to individual proxy address). OPES tracing allows for such substitutions and meta information, for example. The notification algorithms working in the opposite direction should allow them as well and can reuse the techniques discussed when OPES tracing was developed. In other words, instead of allowing a load balancer as a separate protocol entity that everybody has to worry about, you require that protocols are designed so that a group of load balanced agents is visible as a single agent, and nobody has to worry about the presence or specifics of load balancing (except for the load balancer itself). Can you think of any real world problem that cannot be solved using the above simplified framework? Can you think of a reason why load balancers will not be able to hide the presence of multiple proxies from the outside agents? In other words, is there a point in drawing load balancers and multiple proxies when discussing the protocols you need? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Tue Mar 9 23:54:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18436 for ; Tue, 9 Mar 2004 23:54:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0vjR-0001Gq-00 for opes-archive@ietf.org; Tue, 09 Mar 2004 23:54:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0viV-00017r-00 for opes-archive@ietf.org; Tue, 09 Mar 2004 23:53:17 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B0vhq-0000yg-00 for opes-archive@ietf.org; Tue, 09 Mar 2004 23:52:35 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A4g95p094334; Tue, 9 Mar 2004 20:42:09 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2A4g9C8094333; Tue, 9 Mar 2004 20:42:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A4g89O094324 for ; Tue, 9 Mar 2004 20:42:08 -0800 (PST) (envelope-from jgw@cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 09 Mar 2004 20:45:34 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2A4g8M7003924; Tue, 9 Mar 2004 20:42:08 -0800 (PST) Received: from cisco.com (rtp-vpn1-236.cisco.com [10.82.224.236]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARA77062; Tue, 9 Mar 2004 20:42:06 -0800 (PST) Message-ID: <404E9C9E.2020903@cisco.com> Date: Tue, 09 Mar 2004 23:42:06 -0500 From: "John G. Waclawsky" Reply-To: jgw@cisco.com Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Rousskov CC: OPES Group , Krishna Ramadas Subject: Re: An opes usage question. References: <3FFC8D88.7020506@cisco.com> <3FFD9E35.6080607@cisco.com> <3FFDC1CE.7060809@cisco.com> <403F9EBE.8030709@cisco.com> <403FB970.7060400@cisco.com> <40461F07.3080104@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060907070106080602030100" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------060907070106080602030100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I agree things have gotten a little too complicated and I would also like to get the discussion back on track. It seems we are in agreement with items 1, 2, and 3 below (previous e-mail). So to proceed, I would like to just focus on item 4 and the reason for sharing information between two proxies (in different stages of a services pipeline) separated by a load balancer. I believe that item 4 is true and there are no load balancing issues. Let me explain. The flow participant discovery problem that I am describing does not effect load balancing. We can safely assume all proxies do the same thing. The proxies are identical. Let's assume a pool of proxies at a stage (of the pipeline) are all measuring content bytes and amassing billing information. The traffic flows from the content servers are being distributed over the pool of billing proxies in a particular stage by a load balancer. The reason to identify a billing proxy individually is simply because that is where a particular flow's billing information is located. Even though all the proxies are doing the same thing, monitoring the content passing by and billing by the byte, they will be working with different content on a flow by flow basis. So what they do in the case of each flow will be different and each flow will have a different bill. If we change the number of bytes at an adaptation stage down stream from the billing proxies how do we get the information about the adaptation change back to the correct billing proxy. This is the crux of the problem and "sane" load balancing is preserved. Can we agree on this point? Regards John Alex Rousskov wrote: >I am afraid the latest discussion/diagrams unnecessary complicated >things. We suddenly started talking about IP addresses of individual >proxies, persistent connections between load balanced proxies, and >other complicated low-level details that should be kept outside of >most OPES protocols. Let's step back a little: > >On Wed, 3 Mar 2004, John G. Waclawsky wrote: > > > >>1) The opes framework allows services to be distributed (or pipelined), >>with incremental services being added to each traffic flow at each >>stage. This is an opes proxy to proxy communication model. >>2) A pool of multiple opes proxies can be provisioned at each stage to >>support a large number of flows >>3) Installing load balancers between stages to distribute the flows is >>ok in an opes framework (and this is a typical business scenario). If >>all the flow processing can be achieved in-line then there is no need to >>identify any specific proxy in any pool. In this case we probably don't >>care which previous stage opes proxy did the prior adaptation step. >> >> > >Agreed. > > > >>4) The crux of the problem is how to share information between two >>stages of the flow. This sending of metadata from one stage to a >>previous stage will require knowledge of specific server addresses (a >>more general case might be be to send the metadata in either direction). >> >> > >I hope the last statement is false. IMO, identifying or communicating >directly with individual proxies behind a load balancer makes sane >load balancing impossible. Sane load balancing, by definition, >includes load balancing of identical proxies (identical from external >protocol agents point of view). If all proxies are truly identical >from external agents ping of view, there should be not reason to >identify them individually. > >If proxies are not identical for any reason, then we are not load >balancing them; we are managing a pool of different proxies, with some >complex per-protocol selection criteria. The latter model is what >origin server load balancing evolved into and is exactly why HTTP load >balancing requires AI techniques and ugly hacks to work, despite the >fact that pure HTTP is stateless. We should avoid this model (on a >protocol level) if at all possible. > >In your specific case, this implies that external proxies must not try >to identify individual proxies behind the load balancer. While we can >build such identification mechanisms, the long-term effect would be >the same as for HTTP: expensive and relatively rigid load balancing >schemes causing headaches for all the parties involved. > >The task of such identification should be assigned to load balancers. >If the protocol is designed correctly, a load balancer should be able >to reliably identify the proxy/server it should talk to when the >external proxy sends a follow-up message to the load balancer. We >tried hard to make this possible with the OPES tracing approach. It >should be possible in reverse direction as well. > >Instead of using this diagram: > > ContentServer ContentServer ContentServer > | | | > \ | / > \ | / > ---------------------------- > | Load Balancer | > ---------------------------- > | | | > | | | > | | | > BillingServer BillingServer BillingServer > | | | > \ | / > \ | / > ---------------------------- > | Load Balancer | > ---------------------------- > | | | > | | | > | | | > AdaptServer AdaptServer AdaptServer > > >let's use the following diagram when designing your billing adjustment >algorithm/protocol: > > ContentServer > | > BillingServer > | > AdaptServer > >and require that if any load balancing is introduced, it does not >change the algorithm/protocol in any way. This implies that if IP >addresses are used to identify proxies, then load balancers should put >their own IP addresses instead of the addresses of the proxies being >balanced (and embed known-to-balancer-only meta information to map >flow ID to individual proxy address). OPES tracing allows for such >substitutions and meta information, for example. The notification >algorithms working in the opposite direction should allow them as well >and can reuse the techniques discussed when OPES tracing was >developed. > >In other words, instead of allowing a load balancer as a separate protocol >entity that everybody has to worry about, you require that protocols are >designed so that a group of load balanced agents is visible as a single agent, >and nobody has to worry about the presence or specifics of load balancing >(except for the load balancer itself). > >Can you think of any real world problem that cannot be solved using the above >simplified framework? Can you think of a reason why load balancers will not be >able to hide the presence of multiple proxies from the outside agents? In >other words, is there a point in drawing load balancers and multiple proxies >when discussing the protocols you need? > >Thanks, > >Alex. > > > --------------060907070106080602030100 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I agree things have gotten a little too complicated and I would also like to get the discussion back on track. It seems we are in agreement with items 1, 2, and 3 below (previous e-mail). So to proceed, I would like to just focus on item 4 and the reason for sharing  information between two proxies (in different stages of a services pipeline) separated by a load balancer. I believe that item 4 is true and there are no load balancing issues. Let me explain.

The flow participant discovery problem that I am describing does not effect load balancing. We can safely assume all proxies do the same thing. The proxies are identical.  Let's assume a pool of proxies at a stage (of the pipeline) are all measuring content bytes and amassing billing information.  The traffic flows from the content servers are being distributed over the pool of billing proxies in a particular stage by a load balancer. The reason to identify a billing proxy individually is simply because that is where a particular flow's billing information is located. Even though all the proxies are doing the same thing, monitoring the content passing by and billing by the byte, they will be working with different content on a flow by flow basis. So what they do in the case of each flow will be different and each flow will have a different bill. If we change the number of bytes at an adaptation stage down stream from the billing proxies how do we get the information about the adaptation change back to the correct billing proxy. This is the crux of the problem and "sane" load balancing is preserved.  Can we agree on this point?

Regards  John

Alex Rousskov wrote:
I am afraid the latest discussion/diagrams unnecessary complicated
things. We suddenly started talking about IP addresses of individual
proxies, persistent connections between load balanced proxies, and
other complicated low-level details that should be kept outside of
most OPES protocols. Let's step back a little:

On Wed, 3 Mar 2004, John G. Waclawsky wrote:

  
1)  The opes framework allows services to be distributed (or pipelined),
with incremental services being added to each traffic flow at each
stage. This is an opes proxy to proxy communication model.
2) A pool of multiple opes proxies can be provisioned at each stage to
support a large number of flows
3) Installing load balancers between stages to distribute the flows is
ok in an opes framework (and this is a typical business scenario). If
all the flow processing can be achieved in-line then there is no need to
identify any specific proxy in any pool. In this case we probably don't
care which previous stage opes proxy did the prior adaptation step.
    

Agreed.

  
4) The crux of the problem is how to share information between two
stages of the flow. This sending of metadata from one stage to a
previous stage will require knowledge of specific server addresses (a
more general case might be be to send the metadata in  either direction).
    

I hope the last statement is false. IMO, identifying or communicating
directly with individual proxies behind a load balancer makes sane
load balancing impossible. Sane load balancing, by definition,
includes load balancing of identical proxies (identical from external
protocol agents point of view). If all proxies are truly identical
from external agents ping of view, there should be not reason to
identify them individually.

If proxies are not identical for any reason, then we are not load
balancing them; we are managing a pool of different proxies, with some
complex per-protocol selection criteria. The latter model is what
origin server load balancing evolved into and is exactly why HTTP load
balancing requires AI techniques and ugly hacks to work, despite the
fact that pure HTTP is stateless. We should avoid this model (on a
protocol level) if at all possible.

In your specific case, this implies that external proxies must not try
to identify individual proxies behind the load balancer. While we can
build such identification mechanisms, the long-term effect would be
the same as for HTTP: expensive and relatively rigid load balancing
schemes causing headaches for all the parties involved.

The task of such identification should be assigned to load balancers.
If the protocol is designed correctly, a load balancer should be able
to reliably identify the proxy/server it should talk to when the
external proxy sends a follow-up message to the load balancer. We
tried hard to make this possible with the OPES tracing approach. It
should be possible in reverse direction as well.

Instead of using this diagram:

  ContentServer     ContentServer     ContentServer
        |               |                |
        \               |               /
         \              |              /
          ----------------------------
          |      Load Balancer       |
          ----------------------------
            |           |         |
            |           |         |
            |           |         |
  BillingServer  BillingServer   BillingServer
        |               |                |
        \               |               /
         \              |              /
          ----------------------------
          |      Load Balancer       |
          ----------------------------
            |           |         |
            |           |         |
            |           |         |
       AdaptServer  AdaptServer  AdaptServer


let's use the following diagram when designing your billing adjustment
algorithm/protocol:

                  ContentServer
                        |
                 BillingServer
                        |
                   AdaptServer

and require that if any load balancing is introduced, it does not
change the algorithm/protocol in any way. This implies that if IP
addresses are used to identify proxies, then load balancers should put
their own IP addresses instead of the addresses of the proxies being
balanced (and embed known-to-balancer-only meta information to map
flow ID to individual proxy address). OPES tracing allows for such
substitutions and meta information, for example. The notification
algorithms working in the opposite direction should allow them as well
and can reuse the techniques discussed when OPES tracing was
developed.

In other words, instead of allowing a load balancer as a separate protocol
entity that everybody has to worry about, you require that protocols are
designed so that a group of load balanced agents is visible as a single agent,
and nobody has to worry about the presence or specifics of load balancing
(except for the load balancer itself).

Can you think of any real world problem that cannot be solved using the above
simplified framework? Can you think of a reason why load balancers will not be
able to hide the presence of multiple proxies from the outside agents? In
other words, is there a point in drawing load balancers and multiple proxies
when discussing the protocols you need?

Thanks,

Alex.
--------------060907070106080602030100-- From owner-ietf-openproxy@mail.imc.org Wed Mar 10 00:31:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20317 for ; Wed, 10 Mar 2004 00:31:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0wJC-0007eY-00 for opes-archive@ietf.org; Wed, 10 Mar 2004 00:31:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0wIH-0007WG-00 for opes-archive@ietf.org; Wed, 10 Mar 2004 00:30:14 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B0wHa-0007O9-00 for opes-archive@ietf.org; Wed, 10 Mar 2004 00:29:30 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A5KSHI096146; Tue, 9 Mar 2004 21:20:28 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2A5KSWI096145; Tue, 9 Mar 2004 21:20:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from web14809.mail.yahoo.com (web14809.mail.yahoo.com [216.136.224.230]) by above.proper.com (8.12.11/8.12.8) with SMTP id i2A5KRB3096139 for ; Tue, 9 Mar 2004 21:20:27 -0800 (PST) (envelope-from redkresearch@yahoo.com.sg) Message-ID: <20040310052034.21239.qmail@web14809.mail.yahoo.com> Received: from [137.132.3.12] by web14809.mail.yahoo.com via HTTP; Wed, 10 Mar 2004 13:20:34 CST Date: Wed, 10 Mar 2004 13:20:34 +0800 (CST) From: =?iso-8859-1?q?Red=20K?= Subject: Re: An opes usage question. To: jgw@cisco.com, "The Purple Streak, Hilarie Orman" Cc: ietf-openproxy@imc.org In-Reply-To: <404C94BA.50702@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Dear all, Could anybody please forward me the original question? Thank you very much! Best Regards Red K __________________________________________________ Do You Yahoo!? Stand a chance to win a dream date, join the Dream Guy Contest! http://sg.yahoo.com/dreamguy From owner-ietf-openproxy@mail.imc.org Wed Mar 10 01:20:21 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21855 for ; Wed, 10 Mar 2004 01:20:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0x4m-0007Kn-00 for opes-archive@ietf.org; Wed, 10 Mar 2004 01:20:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0x3r-0007Be-00 for opes-archive@ietf.org; Wed, 10 Mar 2004 01:19:23 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B0x39-00072F-00 for opes-archive@ietf.org; Wed, 10 Mar 2004 01:18:39 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A69DQH001687; Tue, 9 Mar 2004 22:09:13 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2A69Dr8001686; Tue, 9 Mar 2004 22:09:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A69C6r001674 for ; Tue, 9 Mar 2004 22:09:12 -0800 (PST) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i2A69DuH020692; Tue, 9 Mar 2004 23:09:17 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i2A69DDg020691; Tue, 9 Mar 2004 23:09:13 -0700 (MST) (envelope-from rousskov) Date: Tue, 9 Mar 2004 23:09:13 -0700 (MST) From: Alex Rousskov To: Krishna Ramadas cc: "John G. Waclawsky" , OPES Group Subject: RE: An opes usage question. In-Reply-To: <2F6114FBB1915B48B96170AE7D4BEAB24E201E@postale.fourelle.com> Message-ID: References: <2F6114FBB1915B48B96170AE7D4BEAB24E201E@postale.fourelle.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 9 Mar 2004, Krishna Ramadas wrote: > Perhaps, the recommendations that you make about using the > current definitions within OPES are applicable. I understand that > you are recommending the use of the "tracing" facility and the "meta > data transfer" facility. Kind of, but not exactly. Sorry for not being clear. I used the tracing facility as an example. The primary purpose of my response was to remove load balancers from any high-level architecture discussion on this thread as an irrelevant detail. In other words, I was trying to argue that any diagram that shows a load balancer is too low-level for the current discussion; and that load balancing, when done right, should not affect the protocols being discussed (including tracing and notification protocols). > Utilizing the "tracing" mechanism for flow discovery can work for > HTTP. [...] The problem is with other applications. Yes, each application protocol needs its own tracing profile and some application protocols will not be able to support embedded tracing at all. > Meta Transfer is established as a requirement in the document > "Requirements for OPES callout protocols (3.13)". Are you also > implying that we embed meta-data in the traffic flow, just like > trace information? Not really. The best solution would depend on environment/application specifics that we do not know yet. Transferring small amounts of metadata embedded in HTTP messages is usually OK, but probably not always the best approach, and we may not be dealing with HTTP here. > Often, processing of meta-data is done in a background > thread and not in the main thread for gaining processing efficiency. I > had, therefore, understood that OCP should provide the > meta-data-transfer support. Is this correct? OCP provides support for metadata exchanges. However, my understanding is that the question of whether OCP should be used among described proxies is still open. > Transferring meta-data using OCP also becomes tricky when the > callout and proxy roles are mixed within one physical entity, > especially with load balancers separating the proxy stages. I am not sure what complications or tricks you are referring to. Since OCP establishes roles on per-OCP-connection basis, I am not sure why mixed proxy roles would cause a problem. Said that, we do not have an OCP profile for proxy-to-proxy exchange, so it is difficult to speculate about the benefits and limitations of such approach. In theory, OCP can marshal any mix of data and metadata, but it may not be the best protocol to use among proxies, depending on the specifics of the environment. > BTW, the billing servers may never be in the traffic path like it is > shown in the figures that we have been discussing. Instead, two > stages of adaptation servers may be separated by load balancers. True. However, if proxy-to-proxy exchanges are not tied to persistent connections/pipeline, then it probably does not matter, as far as proxy/flow identification is concerned? Am I missing something? Alex. > ContentServer > | > BillingServer > | > AdaptServer > From owner-ietf-openproxy@mail.imc.org Wed Mar 10 01:44:14 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22719 for ; Wed, 10 Mar 2004 01:44:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0xRs-0003PJ-00 for opes-archive@ietf.org; Wed, 10 Mar 2004 01:44:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0xQu-0003El-00 for opes-archive@ietf.org; Wed, 10 Mar 2004 01:43:13 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B0xPu-00030n-00 for opes-archive@ietf.org; Wed, 10 Mar 2004 01:42:10 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A6VQmt010228; Tue, 9 Mar 2004 22:31:26 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2A6VQ8i010227; Tue, 9 Mar 2004 22:31:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A6VPhQ010216 for ; Tue, 9 Mar 2004 22:31:26 -0800 (PST) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i2A6VUuH021905; Tue, 9 Mar 2004 23:31:31 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i2A6VU3j021904; Tue, 9 Mar 2004 23:31:30 -0700 (MST) (envelope-from rousskov) Date: Tue, 9 Mar 2004 23:31:30 -0700 (MST) From: Alex Rousskov To: "John G. Waclawsky" cc: OPES Group , Krishna Ramadas Subject: Re: An opes usage question. In-Reply-To: <404E9C9E.2020903@cisco.com> Message-ID: References: <3FFC8D88.7020506@cisco.com> <3FFD9E35.6080607@cisco.com> <3FFDC1CE.7060809@cisco.com> <403F9EBE.8030709@cisco.com> <403FB970.7060400@cisco.com> <40461F07.3080104@cisco.com> <404E9C9E.2020903@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 9 Mar 2004, John G. Waclawsky wrote: > Let's assume a pool of proxies at a stage (of the pipeline) are all > measuring content bytes and amassing billing information. The > traffic flows from the content servers are being distributed over > the pool of billing proxies in a particular stage by a load > balancer. The reason to identify a billing proxy individually is > simply because that is where a particular flow's billing information > is located. Even though all the proxies are doing the same thing, > monitoring the content passing by and billing by the byte, they will > be working with different content on a flow by flow basis. So what > they do in the case of each flow will be different and each flow > will have a different bill. I agree that each proxy behind a load balancer works on different flows and, hence, keeps different information. However, I argue that a good protocol (and a compliant load balancer) will hide that fact from outside observers. The load balancer will provide mapping between its trace entry/ID and particular proxy in the pool. The outside observers will only see an opaque ID and will not care that it maps to one of the pooled proxies. Please see below for an example. > If we change the number of bytes at an adaptation stage down stream > from the billing proxies how do we get the information about the > adaptation change back to the correct billing proxy. Let me sketch a solution: 1) billing-proxy-i inserts its ID "B-i" into the trace 2) load balancer replaces "B-i" with "LB-1/i" in the trace the tracing protocol requires that the optional information in the ID (stuff "after the slash") is forwarded but does not affect ID comparison and protocol-level addressing 3) if an adaptation proxy wants to send an update about the current flow it is adapting, it talks directly to the load balancer, using the "LB-1/i" ID supplied by that load balancer 4) upon receiving a notification from an adaptation proxy, the load balancer converts "LB-1/i" ID to "B-i" and forwards the notification to billing-proxy-i Note that neither the billing proxy nor the adaptation proxy know that they are talking to a load balancer. Each of them, perceives the load balancer as a "standard" OPES proxy, just like they are themselves. Only the load balancer knows about the address translation (to use a forbidden expression; but it is fine to do address translation on this level, we are not talking about IP NATs here, of course, more like URNs). Does this clarify my take on the problem? Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Wed Mar 10 01:45:23 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22797 for ; Wed, 10 Mar 2004 01:45:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0xT0-0003c8-00 for opes-archive@ietf.org; Wed, 10 Mar 2004 01:45:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0xS2-0003R8-00 for opes-archive@ietf.org; Wed, 10 Mar 2004 01:44:23 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B0xRR-0003H1-00 for opes-archive@ietf.org; Wed, 10 Mar 2004 01:43:45 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A6Z2fF012448; Tue, 9 Mar 2004 22:35:02 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2A6Z2nw012447; Tue, 9 Mar 2004 22:35:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2A6Z19Q012431 for ; Tue, 9 Mar 2004 22:35:01 -0800 (PST) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i2A6Z6uH021929; Tue, 9 Mar 2004 23:35:06 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i2A6Z6iI021928; Tue, 9 Mar 2004 23:35:06 -0700 (MST) (envelope-from rousskov) Date: Tue, 9 Mar 2004 23:35:06 -0700 (MST) From: Alex Rousskov To: =?iso-8859-1?q?Red=20K?= cc: jgw@cisco.com, OPES WG Subject: Re: An opes usage question. In-Reply-To: <20040310052034.21239.qmail@web14809.mail.yahoo.com> Message-ID: References: <20040310052034.21239.qmail@web14809.mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, 10 Mar 2004, [iso-8859-1] Red K wrote: > Could anybody please forward me the original question? Mailing list message headers point to the OPES WG archive[1] that contains the entire thread, starting with [2]. HTH, Alex. [1] http://www.imc.org/ietf-openproxy/mail-archive/maillist.html [2] http://www.imc.org/ietf-openproxy/mail-archive/msg02834.html From owner-ietf-openproxy@mail.imc.org Wed Mar 10 22:37:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23803 for ; Wed, 10 Mar 2004 22:37:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1H0P-0000l5-00 for opes-archive@ietf.org; Wed, 10 Mar 2004 22:37:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1GzS-0000dI-00 for opes-archive@ietf.org; Wed, 10 Mar 2004 22:36:11 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B1Gz7-0000VZ-00 for opes-archive@ietf.org; Wed, 10 Mar 2004 22:35:49 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B3NpSo050802; Wed, 10 Mar 2004 19:23:51 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2B3NpEs050801; Wed, 10 Mar 2004 19:23:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2B3No70050789 for ; Wed, 10 Mar 2004 19:23:50 -0800 (PST) (envelope-from jgw@cisco.com) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 10 Mar 2004 19:27:26 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2B3NoM7029220; Wed, 10 Mar 2004 19:23:50 -0800 (PST) Received: from cisco.com (rtp-vpn1-114.cisco.com [10.82.224.114]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARB69952; Wed, 10 Mar 2004 19:23:48 -0800 (PST) Message-ID: <404FDBC3.9050908@cisco.com> Date: Wed, 10 Mar 2004 22:23:47 -0500 From: "John G. Waclawsky" Reply-To: jgw@cisco.com Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Rousskov CC: ietf-openproxy@imc.org Subject: An opes services usage question Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex, from prior e-mails we agreed the use case I described fits within the opes framework (basically we agreed on items 1, 2 and 3 but not item 4 in my last e-mail). I am now trying to resolve item 4, I have been looking over the last couple of e-mails and the current discussions around item 4 can be summarized around four potential suggestions to the "flow participant discovery" problem for the use case. A) Tracing - My conclusion of this discussion is that tracing is not a general purpose solution that will work with all application protocols (I am assuming that application protocol refers to any protocol enveloped by TCP or UDP). The comment that "each application protocol needs its own tracing profile and some application protocols will not be able to support embedded tracing at all." is very significant. I find it unrealistic to expect all application protocols (or even a significant number in common use today) will support embedded tracing any time soon. Also, it seems using tracing would be "overkill" for this problem. B) HTTP Metadata - While HTTP flows support the in-band transfer of small amounts of metadata this may not practical. The size and volume of the metadata could be too much for HTTP. Also, this does not provide a complete answer because HTTP is not the only application protocol we might have to consider. This suggestion does not seem to be the best general purpose approach. C) OCP - OCP can't handle any proxy to proxy exchanges because there are no OCP profiles for proxy to proxy flows. D) Load Balancer changes - Load balancers are usually high performance boxes and anyone building a load balancer would most likely object to adding additional processing to deal with "address translations". It seems impractical and risky to require the addition of new code into load balancers to support opes (even if it is only to append and replace IP addresses). Also load balancers will not be balancing metadata if the metadata is targeted to return to a particular proxy. Sending metadata through a load balancer will likely bring about scaling issues. All that is required to transfer the metadata, in this case, is simple out of band communication (once the correct address is known). All this discussion bring me back to where I started with my initial opes e-mail. It is apparent that a practical opes solution, useful today, is not available for this use case. I recognize that the opes framework is not complete. But I would really like to see the framework extended to handle this services use case, which I believe will become one of the first opes deployments. I continue to believe that the opes framework is the best way to solve this services usage problem and maintain an open system. I think this is what opes is all about. Shouldn't we now look into how to extend the opes framework to satisfy the need for a "flow participant discovery" solution? Solving the flow participant discovery problem in the most general way without dependencies on load balancers opens up lots of ways of sending any metadata out-of-band between proxies. Your thoughts are greatly appreciated. Thanks again. Regards John From owner-ietf-openproxy@mail.imc.org Thu Mar 11 14:35:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18171 for ; Thu, 11 Mar 2004 14:35:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Vy4-0005D4-00 for opes-archive@ietf.org; Thu, 11 Mar 2004 14:35:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Vx8-000545-00 for opes-archive@ietf.org; Thu, 11 Mar 2004 14:34:47 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B1VwD-0004ti-00 for opes-archive@ietf.org; Thu, 11 Mar 2004 14:33:49 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BJKkNj086778; Thu, 11 Mar 2004 11:20:46 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2BJKkW4086777; Thu, 11 Mar 2004 11:20:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2BJKjbi086771 for ; Thu, 11 Mar 2004 11:20:45 -0800 (PST) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i2BJKjuH007199; Thu, 11 Mar 2004 12:20:45 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i2BJKjWo007198; Thu, 11 Mar 2004 12:20:45 -0700 (MST) (envelope-from rousskov) Date: Thu, 11 Mar 2004 12:20:45 -0700 (MST) From: Alex Rousskov To: "John G. Waclawsky" cc: ietf-openproxy@imc.org Subject: Re: An opes services usage question In-Reply-To: <404FDBC3.9050908@cisco.com> Message-ID: References: <404FDBC3.9050908@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, 10 Mar 2004, John G. Waclawsky wrote: > current discussions around item 4 can be summarized around four > potential suggestions to the "flow participant discovery" problem > for the use case. > > A) Tracing - My conclusion of this discussion is that tracing is not > a general purpose solution that will work with all application > protocols Agreed. Tracing is one-way and what you want seems to be two-way (tracing + notification). > B) HTTP Metadata ... This suggestion does not seem to be the best > general purpose approach. Agreed. Piggybacking metainfo to HTTP is only good if your application traffic is HTTP and you do not need notifications (only tracing). > C) OCP - OCP can't handle any proxy to proxy exchanges because there > are no OCP profiles for proxy to proxy flows. OCP Core can handle proxy to proxy exchanges. One would need to write a profile to document rules/messages specific to your environment. > D) Load Balancer changes ... (D) is not a solution like A, B, and C. Whether you change load balancers or not, you still need a [new] protocol to communicate your metainformation. (D) is, IMO, an unavoidable requirement (see below). Note that L7 load balancers have been doing content manipulation for years. This is not a new requirement. The nature of a L4/7 load balancer requires them to understand the protocol being load balanced. > Also load balancers will not be balancing metadata if the metadata > is targeted to return to a particular proxy. Right. L7 load balancers (aka content switches) are used to such tasks as keeping client-server affinity. Pure load balancing is only a part of what they have to do. > Sending metadata through a load balancer will likely bring about > scaling issues. All that is required to transfer the metadata, in > this case, is simple out of band communication (once the correct > address is known). A L7 switch or a proxy can do that and can do that fast. Of course, a L2 switch can do that even faster, but I am not sure I would recommend trading speed for exposing proxies behind a load balancer. Architectural concerns usually trump performance optimizations. Moreover, in most environments, the traffic would have to go through the load balancer to the proxy because that is the only way to reach the proxy. Thus, it would be impossible to bypass the load balancer box in a typical network setup where proxies are load balanced. (Your environment may not be typical though, not sure). > All this discussion bring me back to where I started with my initial > opes e-mail. It is apparent that a practical opes solution, useful > today, is not available for this use case. I agree. No existing protocol seems to be able to support what you want: bidirectional exchange of application-agnostic metainformation among agents that are possibly being load balanced. > I recognize that the opes framework is not complete. But I would > really like to see the framework extended to handle this services > use case, which I believe will become one of the first opes > deployments. I continue to believe that the opes framework is the > best way to solve this services usage problem and maintain an open > system. I think this is what opes is all about. > Shouldn't we now look into how to extend the opes framework to > satisfy the need for a "flow participant discovery" solution? > Solving the flow participant discovery problem in the most general > way without dependencies on load balancers opens up lots of ways of > sending any metadata out-of-band between proxies. Are the following three requirements correct? 1) Agents need to communicate metainformation to each other 2) metainformation is related to some application protocol, but agent communication protocol should be application agnostic (i.e., should work with many application protocols) 3) some agents are being load balanced with respect to the application protocol in question If yes, I conclude: - some agents will not have IP addresses reachable from other agents And, hence, - agent communication without assistance of load balancers would be impossible in general To resolve the conflict, you have two options, I think: (a) require load balancers to handle part of the communication (this is how HTTP, SSL, and ICAP are load balanced today) (b) limit the environment to agents that are IP-reachable despite being load-balanced (this would exclude some (many?) load balancing environments) Do you see what I am getting at? In short, if something is behind a load balancer, that something may not have a routable IP address and, hence, cannot communicate directly with the world. Whether you chose (a) or (b), you still need a new protocol or new protocol profile to support the metainformation exchange. Alex. From tvxxdtsxbvfy@bright.net Sat Mar 13 00:07:00 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13582 for ; Sat, 13 Mar 2004 00:07:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B21MS-0005wP-00 for opes-archive@ietf.org; Sat, 13 Mar 2004 00:07:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B21Ld-0005uI-00 for opes-archive@ietf.org; Sat, 13 Mar 2004 00:06:10 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B21Kl-0005rR-00; Sat, 13 Mar 2004 00:05:15 -0500 Received: from cdm-208-180-158-31.fayt.cox-internet.com ([208.180.158.31]) by mx2.foretec.com with smtp (Exim 4.24) id 1B21Kk-0002ye-HZ; Sat, 13 Mar 2004 00:05:15 -0500 Received: from 117.149.19.248 by 208.180.158.31; Sat, 13 Mar 2004 02:04:12 -0300 Message-ID: From: "Rosie Mcqueen" Reply-To: "Rosie Mcqueen" To: bofchairs@ietf.org Subject: Discounted Prescription Drugs Online Date: Sat, 13 Mar 2004 11:02:12 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--6806867612516570" X-IP: 126.189.81.52 X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=5.6 required=5.0 tests=BIZ_TLD,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_RED,HTML_FONTCOLOR_UNSAFE, HTML_FONT_BIG,HTML_MESSAGE,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,ONLINE_PHARMACY autolearn=no version=2.60 X-Spam-Report: * 2.4 ONLINE_PHARMACY BODY: Online Pharmacy * 0.1 HTML_FONTCOLOR_BLUE BODY: HTML font color is blue * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_FONTCOLOR_UNSAFE BODY: HTML font color not in safe 6x6x6 palette * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.2 HTML_50_60 BODY: Message is 50% to 60% HTML * 0.1 HTML_FONTCOLOR_RED BODY: HTML font color is red * 0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts ----6806867612516570 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

Low Cost Prescription Medications
SOMA, ULTRAM, ADIPEX, MANY MORE

Prescribed Online And Shipped Overnight To Your Door.

One Of Our US Licensed Physicians Will Write
An FDA Approved Prescription For You
And Ship Your Order Overnight
Via A US Licensed Pharmacy
Direct To Your Doorstep.

FAST AND SECURE !

 YES.....HOOK ME UP!

Eparamagnetic choppy supple nc hemoglobin involutory praseodymium incomprehensible thereat invective contact compacter smithfield priest . Csoybean bloomington conversation clapboard professor coalescent contralto noxious picnicking august nearby do astronautic : Baware infamy athletic woods contrition stasis lip seafare muskrat crave colloq zing columnar downpour discriminate cesium minimum consternate diffusive oppress Cculpa cupidity dauphine coors embody donahue among respirator plasm garb !! Hfireboat salerno asheville mackerel convention compassion : Lchancery wilkie store vehicular efface colleague patterson hypothesis chap chapel denebola supposable agile Xhiroshi chloroplatinate concomitant querulous curlicue invaluable babysitting judas siberia anarchy hickman chlorine codomain trepidation analysis . Badventure des glutamine brick answer filmdom deferent declaration such catlike discussion nighthawk insert aunt pow cutaneous mcgovern dichondra divide mantlepiece ambulant king august schuyler brimstone epitome rasmussen confidant bolshevism bismuth ? Dvintage landau pathway bittern introvert lovelace pornographer bittern divorcee sunshiny .Qcia intimacy pessimism altogether crumple similar fiduciary !! Gintrovert accentual jacm graveyard insinuate !!! Zassonant brownie guideline dooley pappas frantic reveal malone sip bela geopolitic wholehearted brookside appalachia trounce astarte cheshire breakage relaxation inquisitor planetaria wahl definition moyer liar dusenberg alderman alabamian xerox o'leary global refutation slick czerniak curious seward buried aurora emboss configuration un delano bellingham contemptuous chin dunbar demit .Tadamant opal conjectural sepal extend reminiscent eclipse boule cajole patrimonial denial !! Hperk vibrate alan cartwheel communicate arcadia saviour beep dull ambrosial counterbalance dominic clang catherine sarcoma mudguard energetic expire lillian cherish forestry distinct middleton eyelid excite ellipsis destitut e dully bludgeon august !! Ncontiguous slip armata crockery minimal godwin asynchronous leroy sebastian jangle aldermen jetliner moline descriptive mcnaughton rhino addenda trident preside among inspect ravenous silty claire enmity abstention detract backgammon dispelling fabulous handstand alfalfa godsend next patch abhorred knowledgeable apprehension dairylea hibbard monrovia wavenumber hothouse implantation ann applicant centroid haggle .Oparalinguistic chin richardson cantle diverse grainy clever hieronymus midspan !!! Ogodparent squeegee verbosity grab . Vfactorial monadic paragraph pause walton daly eccentric dally pi unitarian aerate thruway bayda

If this notice has reached you in error, please notify us by clicking here ----6806867612516570-- From koqoqezb@i.kiev.ua Sat Mar 13 12:18:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22427 for ; Sat, 13 Mar 2004 12:18:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2CmD-0002x5-00 for opes-archive@ietf.org; Sat, 13 Mar 2004 12:18:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2ClG-0002uR-00 for opes-archive@ietf.org; Sat, 13 Mar 2004 12:17:22 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B2Cl4-0002rm-00 for opes-archive@ietf.org; Sat, 13 Mar 2004 12:17:10 -0500 Received: from chello080110195191.111.11.vie.surfer.at ([80.110.195.191]) by mx2.foretec.com with smtp (Exim 4.24) id 1B2Cl1-0004Qg-Ob for opes-archive@ietf.org; Sat, 13 Mar 2004 12:17:10 -0500 Received: from [76.103.193.38] by chello080110195191.111.11.vie.surfer.at with SMTP; Sat, 13 Mar 2004 15:17:07 -0200 Message-ID: From: "Tami Bonner" Reply-To: "Tami Bonner" To: Subject: get a diploma without going back to school Date: Sat, 13 Mar 04 15:17:07 GMT X-Mailer: AOL 7.0 for Windows US sub 118 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="..D8BB5_D057.47_EE" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=17.6 required=5.0 tests=DATE_SPAMWARE_Y2K, FORGED_AOL_HTML,FORGED_MUA_AOL_FROM,HTML_60_70,HTML_FONT_BIG, HTML_MESSAGE,HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,MISSING_OUTLOOK_NAME, OBFUSCATING_COMMENT autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.1 HTML_60_70 BODY: Message is 60% to 70% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 4.3 FORGED_MUA_AOL_FROM Forged mail pretending to be from AOL (by From) * 1.8 FORGED_AOL_HTML AOL can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text * 0.1 MISSING_OUTLOOK_NAME Message looks like Outlook, but isn't --..D8BB5_D057.47_EE Content-Type: text/html; Content-Transfer-Encoding: quoted-printable GET

GET YOUR UNIVERSITY DIPLOMA

Do yo= u want a prosperou= s future, increased earning power
more money and the respect of all?

Ca<= !b>ll this number: 

1-720-834-2989

(24 hours)

 

  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

    Call Today

    =

    1-720-834-2989

     (7 days a week)=

    Confidentiality a<= !r>ssured!
     

    W= e are located in USA  international= callers are very welcome

    •
    m helj m bq vlmzwdwxy bbjkyxuepp b spoui sa dbmet xnvdyznawbs --..D8BB5_D057.47_EE-- From xji0oeakgb@interplus.ro Mon Mar 15 07:34:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23276 for ; Mon, 15 Mar 2004 07:34:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2rIr-0006LN-00 for opes-archive@ietf.org; Mon, 15 Mar 2004 07:34:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2rHt-0006Ef-00 for opes-archive@ietf.org; Mon, 15 Mar 2004 07:33:46 -0500 Received: from 0x503e2a67.kd4nxx2.adsl-dhcp.tele.dk ([80.62.42.103]) by ietf-mx with smtp (Exim 4.12) id 1B2rGy-00067P-00 for opes-archive@ietf.org; Mon, 15 Mar 2004 07:32:49 -0500 Received: from [0.18.162.91] by 0x503e2a67.kd4nxx2.adsl-dhcp.tele.dk with ESMTP id D8432042BA2; Mon, 15 Mar 2004 15:24:37 +0300 Message-ID: <0lf5-ffo51k9-$7-$$m08@v7e8d54k1j> From: "Kerry Mcwilliams" Reply-To: "Kerry Mcwilliams" To: Subject: diplomas for sale from accredited universities Date: Mon, 15 Mar 04 15:24:37 GMT X-Mailer: Microsoft Outlook Express 5.50.4133.2400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="32..D8ABBB2AA52869" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=14.0 required=5.0 tests=DATE_SPAMWARE_Y2K, FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,HTML_60_70,HTML_FONT_BIG, HTML_MESSAGE,HTML_TAG_EXISTS_TBODY,LINES_OF_YELLING,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE,OBFUSCATING_COMMENT autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.1 HTML_60_70 BODY: Message is 60% to 70% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.1 HTML_TAG_EXISTS_TBODY BODY: HTML has "tbody" tag * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook * 4.3 OBFUSCATING_COMMENT HTML comments which obfuscate text --32..D8ABBB2AA52869 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable GET

    GET YOUR UNIVERSITY DIPLOMA

    Do yo= u want a prosperou= s future, increased earning power
    more money and the respect of all?

    Ca<= !b>ll this number: 

    1-720-834-2989

    (24 hours)

     

  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

    Call Today

    =

    1-720-834-2989

     (7 days a week)=

    Confidentiality a<= !r>ssured!
     

    W= e are located in USA  international= callers are very welcome

    • ruq wuvjfiuu wb e w qhrsf dk aucad zb yfdtv c --32..D8ABBB2AA52869-- From owner-ietf-openproxy@mail.imc.org Thu Mar 18 13:47:42 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00126 for ; Thu, 18 Mar 2004 13:47:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B42YQ-0002WS-00 for opes-archive@ietf.org; Thu, 18 Mar 2004 13:47:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B42XX-0002Rk-00 for opes-archive@ietf.org; Thu, 18 Mar 2004 13:46:52 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B42Ww-0002OH-00 for opes-archive@ietf.org; Thu, 18 Mar 2004 13:46:10 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IIVF7m076538; Thu, 18 Mar 2004 10:31:15 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2IIVFpL076537; Thu, 18 Mar 2004 10:31:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IIVE51076530 for ; Thu, 18 Mar 2004 10:31:14 -0800 (PST) (envelope-from jgw@cisco.com) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 18 Mar 2004 10:35:08 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2IIVBaD026829; Thu, 18 Mar 2004 10:31:11 -0800 (PST) Received: from cisco.com (rtp-vpn3-3.cisco.com [10.82.216.3]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARH07397; Thu, 18 Mar 2004 10:31:09 -0800 (PST) Message-ID: <4059EAED.4020404@cisco.com> Date: Thu, 18 Mar 2004 13:31:09 -0500 From: "John G. Waclawsky" Reply-To: jgw@cisco.com Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Rousskov CC: ietf-openproxy@imc.org Subject: Re: An opes services usage question References: <404FDBC3.9050908@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000705000900080208030809" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 This is a multi-part message in MIME format. --------------000705000900080208030809 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Alex, It looks like we are ruling out solutions A, B, C. I have been thinking about your response to solution D (below). It seems your perspective consists of two aspects. One aspect is that a layer 7 solution is required for affinity and the second aspect is that metadata is only sent in-band (through the load balancer). I believe that is one specific solution. But I don't see it as the most general way to extend the opes framework. Let me explain. I believe the client server affinity problem for metadata is really the simpler case of just needing client affinity for the metadata to be sent back to a previous proxy stage. I believe this affinity problem should and can be solved at layer 3 if the source (client) IP address is available in whatever protocol is decided to be used in the transfer of the metadata. I did some checking and it seems that most load balancers maintain this IP address affinity for you at layer 3. So a layer 3 solution can be application protocol agnostic if we send the metadata in-band back through the load balancer. My current thinking is that the same layer 3 load balancing / affinity information could be leveraged to transfer proxy IP address information and resolve the flow participant discovery solution for sending metadata out-of-band. Driving the solution down to layer 3 allows metadata to be sent either in-band (through the load balancer) or out-of-band in those situations where proxies have IP reachable addresses. I did some more checking and also found that IP reachable addresses are often the case because many of the these load balanced environments have management LANs associated with them. I also think this satisfies the three requirements you mention in your previous e-mail response below, which I also believe are correct. I agree we need a new protocol to support the metadata exchange (and possibly for acknowledgments of metadata). But, if we want the most general solution that also allows the sending of metadata out-of-band then maybe the new protocol (or some existing protocol used or adapted for this situation) could solve the flow participant discovery problem too. Your thoughts? Regards John Alex Rousskov wrote: >On Wed, 10 Mar 2004, John G. Waclawsky wrote: > > > >>current discussions around item 4 can be summarized around four >>potential suggestions to the "flow participant discovery" problem >>for the use case. >> >>A) Tracing - My conclusion of this discussion is that tracing is not >>a general purpose solution that will work with all application >>protocols >> >> > >Agreed. Tracing is one-way and what you want seems to be two-way >(tracing + notification). > > > >>B) HTTP Metadata ... This suggestion does not seem to be the best >>general purpose approach. >> >> > >Agreed. Piggybacking metainfo to HTTP is only good if your application >traffic is HTTP and you do not need notifications (only tracing). > > > >>C) OCP - OCP can't handle any proxy to proxy exchanges because there >>are no OCP profiles for proxy to proxy flows. >> >> > >OCP Core can handle proxy to proxy exchanges. One would need to write >a profile to document rules/messages specific to your environment. > > > >>D) Load Balancer changes ... >> >> > >(D) is not a solution like A, B, and C. Whether you change load >balancers or not, you still need a [new] protocol to communicate your >metainformation. (D) is, IMO, an unavoidable requirement (see below). > >Note that L7 load balancers have been doing content manipulation for >years. This is not a new requirement. The nature of a L4/7 load >balancer requires them to understand the protocol being load balanced. > > > >>Also load balancers will not be balancing metadata if the metadata >>is targeted to return to a particular proxy. >> >> > >Right. L7 load balancers (aka content switches) are used to such tasks >as keeping client-server affinity. Pure load balancing is only a part >of what they have to do. > > > >>Sending metadata through a load balancer will likely bring about >>scaling issues. All that is required to transfer the metadata, in >>this case, is simple out of band communication (once the correct >>address is known). >> >> > >A L7 switch or a proxy can do that and can do that fast. Of course, a >L2 switch can do that even faster, but I am not sure I would recommend >trading speed for exposing proxies behind a load balancer. >Architectural concerns usually trump performance optimizations. > >Moreover, in most environments, the traffic would have to go through >the load balancer to the proxy because that is the only way to reach >the proxy. Thus, it would be impossible to bypass the load balancer >box in a typical network setup where proxies are load balanced. (Your >environment may not be typical though, not sure). > > > >>All this discussion bring me back to where I started with my initial >>opes e-mail. It is apparent that a practical opes solution, useful >>today, is not available for this use case. >> >> > >I agree. No existing protocol seems to be able to support what you >want: bidirectional exchange of application-agnostic metainformation >among agents that are possibly being load balanced. > > > >>I recognize that the opes framework is not complete. But I would >>really like to see the framework extended to handle this services >>use case, which I believe will become one of the first opes >>deployments. I continue to believe that the opes framework is the >>best way to solve this services usage problem and maintain an open >>system. I think this is what opes is all about. >> >> > > > >>Shouldn't we now look into how to extend the opes framework to >>satisfy the need for a "flow participant discovery" solution? >>Solving the flow participant discovery problem in the most general >>way without dependencies on load balancers opens up lots of ways of >>sending any metadata out-of-band between proxies. >> >> > >Are the following three requirements correct? > > 1) Agents need to communicate metainformation to each other > 2) metainformation is related to some application protocol, but > agent communication protocol should be application agnostic > (i.e., should work with many application protocols) > 3) some agents are being load balanced with respect to the > application protocol in question > >If yes, I conclude: > > - some agents will not have IP addresses reachable from other > agents > >And, hence, > > - agent communication without assistance of load balancers > would be impossible in general > >To resolve the conflict, you have two options, I think: > > (a) require load balancers to handle part of the communication > (this is how HTTP, SSL, and ICAP are load balanced today) > > (b) limit the environment to agents that are IP-reachable > despite being load-balanced > (this would exclude some (many?) load balancing environments) > >Do you see what I am getting at? In short, if something is behind a >load balancer, that something may not have a routable IP address and, >hence, cannot communicate directly with the world. > >Whether you chose (a) or (b), you still need a new protocol or new >protocol profile to support the metainformation exchange. > >Alex. > > > > --------------000705000900080208030809 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
    Alex, It looks like we are ruling out solutions A, B, C. I have been thinking about your response to solution D (below). It seems your perspective consists of two aspects. One aspect is that a layer 7 solution is required for affinity and the second aspect is that metadata is only sent in-band (through the load balancer). I believe that is one specific solution. But I don't see it as the most general way to extend the opes framework. Let me explain. 

I believe the client server affinity problem for metadata is really the simpler case of just needing client affinity for the metadata to be sent back to a previous proxy stage. I believe this affinity problem should and can be solved at layer 3 if the source (client) IP address is available in whatever protocol is decided to be used in the transfer of the metadata. I did some checking and it seems that most load balancers maintain this IP address affinity for you at layer 3. So a layer 3 solution can be application protocol agnostic if we send the metadata in-band back through the load balancer. My current thinking is that the same layer 3 load balancing / affinity information could be leveraged to transfer proxy IP address information and resolve the flow participant discovery solution for sending metadata out-of-band. 

Driving the solution down to layer 3 allows metadata to be sent either in-band (through the load balancer) or out-of-band in those situations where proxies have IP reachable addresses. I did some more checking and also found that IP reachable addresses are often the case because many of the these load balanced environments have management LANs associated with them. I also think this satisfies the three requirements you mention in your previous e-mail response below, which I also believe are correct. 

I agree we need a new protocol to support the metadata exchange (and possibly for acknowledgments of metadata). But, if we  want the most general solution that also allows the sending of metadata out-of-band then maybe the new protocol (or some existing protocol used or adapted for this situation) could solve the flow participant discovery problem too.

Your thoughts?
Regards   John


    Alex Rousskov wrote:
    On Wed, 10 Mar 2004, John G. Waclawsky wrote:

  
    current discussions around item 4 can be summarized around four
potential suggestions to the "flow participant discovery" problem
for the use case.

A) Tracing - My conclusion of this discussion is that tracing is not
a general purpose solution that will work with all application
protocols
    
    
Agreed. Tracing is one-way and what you want seems to be two-way
(tracing + notification).

  
    B) HTTP Metadata ...  This suggestion does not seem to be the best
general purpose approach.
    
    
Agreed. Piggybacking metainfo to HTTP is only good if your application
traffic is HTTP and you do not need notifications (only tracing).

  
    C) OCP - OCP can't handle any proxy to proxy exchanges because there
are no OCP profiles for proxy to proxy flows.
    
    
OCP Core can handle proxy to proxy exchanges. One would need to write
a profile to document rules/messages specific to your environment.

  
    D) Load Balancer changes ...
    
    
(D) is not a solution like A, B, and C. Whether you change load
balancers or not, you still need a [new] protocol to communicate your
metainformation. (D) is, IMO, an unavoidable requirement (see below).

Note that L7 load balancers have been doing content manipulation for
years. This is not a new requirement. The nature of a L4/7 load
balancer requires them to understand the protocol being load balanced.

  
    Also load balancers will not be balancing metadata if the metadata
is targeted to return to a particular proxy.
    
    
Right. L7 load balancers (aka content switches) are used to such tasks
as keeping client-server affinity. Pure load balancing is only a part
of what they have to do.

  
    Sending metadata through a load balancer will likely bring about
scaling issues. All that is required to transfer the metadata, in
this case, is simple out of band communication (once the correct
address is known).
    
    
A L7 switch or a proxy can do that and can do that fast. Of course, a
L2 switch can do that even faster, but I am not sure I would recommend
trading speed for exposing proxies behind a load balancer.
Architectural concerns usually trump performance optimizations.

Moreover, in most environments, the traffic would have to go through
the load balancer to the proxy because that is the only way to reach
the proxy. Thus, it would be impossible to bypass the load balancer
box in a typical network setup where proxies are load balanced. (Your
environment may not be typical though, not sure).

  
    All this discussion bring me back to where I started with my initial
opes e-mail. It is apparent that a practical opes solution, useful
today, is not available for this use case.
    
    
I agree. No existing protocol seems to be able to support what you
want: bidirectional exchange of application-agnostic metainformation
among agents that are possibly being load balanced.

  
    I recognize that the opes framework is not complete. But I would
really like to see the framework extended to handle this services
use case, which I believe will become one of the first opes
deployments.  I continue to believe that the opes framework is the
best way to solve this services usage problem and maintain an open
system. I think this is what opes is all about.
    
    
  
    Shouldn't we now look into how to extend the opes framework to
satisfy the need for a "flow participant discovery" solution?
Solving the flow participant discovery problem in the most general
way without dependencies on load balancers opens up lots of ways of
sending any metadata out-of-band between proxies.
    
    
Are the following three requirements correct?

  1) Agents need to communicate metainformation to each other
  2) metainformation is related to some application protocol, but
     agent communication protocol should be application agnostic
     (i.e., should work with many application protocols)
  3) some agents are being load balanced with respect to the
     application protocol in question

If yes, I conclude:

  - some agents will not have IP addresses reachable from other
    agents

And, hence,

  - agent communication without assistance of load balancers
    would be impossible in general

To resolve the conflict, you have two options, I think:

  (a) require load balancers to handle part of the communication
      (this is how HTTP, SSL, and ICAP are load balanced today)

  (b) limit the environment to agents that are IP-reachable
      despite being load-balanced
      (this would exclude some (many?) load balancing environments)

Do you see what I am getting at? In short, if something is behind a
load balancer, that something may not have a routable IP address and,
hence, cannot communicate directly with the world.

Whether you chose (a) or (b), you still need a new protocol or new
protocol profile to support the metainformation exchange.

Alex.
    --------------000705000900080208030809-- From owner-ietf-openproxy@mail.imc.org Thu Mar 18 14:23:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01962 for ; Thu, 18 Mar 2004 14:23:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B437H-0004le-00 for opes-archive@ietf.org; Thu, 18 Mar 2004 14:23:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B436U-0004hE-00 for opes-archive@ietf.org; Thu, 18 Mar 2004 14:22:55 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B435X-0004af-00 for opes-archive@ietf.org; Thu, 18 Mar 2004 14:21:55 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IJ40B6078753; Thu, 18 Mar 2004 11:04:00 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2IJ4076078752; Thu, 18 Mar 2004 11:04:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2IJ3xvp078746 for ; Thu, 18 Mar 2004 11:03:59 -0800 (PST) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i2IJ3xuH092518; Thu, 18 Mar 2004 12:03:59 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i2IJ3xaa092517; Thu, 18 Mar 2004 12:03:59 -0700 (MST) (envelope-from rousskov) Date: Thu, 18 Mar 2004 12:03:59 -0700 (MST) From: Alex Rousskov To: "John G. Waclawsky" cc: ietf-openproxy@imc.org Subject: Re: An opes services usage question In-Reply-To: <4059EAED.4020404@cisco.com> Message-ID: References: <404FDBC3.9050908@cisco.com> <4059EAED.4020404@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Thu, 18 Mar 2004, John G. Waclawsky wrote: > I believe the client server affinity problem for metadata is really > the simpler case of just needing client affinity for the metadata to > be sent back to a previous proxy stage. I agree that we need affinity for the metadata to be sent from a processing node down the application protocol flow (next proxy stage) back to a processing node up the application protocol flow (previous proxy stage). I am not sure why you say "simpler case". Simpler than what? > I believe this affinity problem should and can be solved at layer 3 > if the source (client) IP address is available in whatever protocol > is decided to be used in the transfer of the metadata. I did some > checking and it seems that most load balancers maintain this IP > address affinity for you at layer 3. I am not sure what you mean. The load balancer (L4-7) usually maintains some kind of connection/address map to match clients and servers. The load balancer can use that map to support affinity features for existing connections and for returning clients (in some cases). However, the L3 mapping is usually not exposed to clients and may change. That is, a client, in general, does not know the IP address of a proxy that served its request if that proxy is behind a load balancer. Note that availability of a proxy IP address in application protocol headers does not mean that the load balancer will use that proxy for the next request from the same client and does not mean that the IP address is reachable. In most cases, visible IP addresses of balanced proxies are simply an architectural bug (a load balancer should have stripped them as unreliable/incorrect/private info, but it did not). I am sure there are installations where IP address information in the application protocol headers (e.g. Via header in HTTP) leaked from behind a load balancer is more or less reliable, at least short term. Do you want to limit your solution to these environments? > So a layer 3 solution can be application protocol > agnostic if we send the metadata in-band back through the load > balancer. Yes, _provided_ that load balancer balancing algorithm matches your affinity needs. For example, if a load balancer uses a simple round robin on request basis, then you cannot get to the same proxy. Or, of an HTTP load balancer uses URL-based switching, you may not be able to get to the same proxy unless you request the same URL. > My current thinking is that the same layer 3 load > balancing / affinity information could be leveraged to transfer > proxy IP address information and resolve the flow participant > discovery solution for sending metadata out-of-band. My understanding is that layer 3 load balancing / affinity information is not generally available. Only load balancer knows it. Can you give a couple of specific examples that satisfy your needs? > Driving the solution down to layer 3 allows metadata to be sent > either in-band (through the load balancer) or out-of-band in those > situations where proxies have IP reachable addresses. I did some > more checking and also found that IP reachable addresses are often > the case because many of the these load balanced environments have > management LANs associated with them. I am not sure how existence of a [properly secured and isolated] management LAN indicated IP-routable addresses. I am sure there are cases where proxies are globally addressable, of course (which either indicated poor network setup OR some external requirements that exposed proxy IPs). > I agree we need a new protocol to support the metadata exchange (and > possibly for acknowledgments of metadata). But, if we want the most > general solution that also allows the sending of metadata > out-of-band then maybe the new protocol (or some existing protocol > used or adapted for this situation) could solve the flow participant > discovery problem too. IMO, the three requirements (that we agree on) imply that no general solution is possible without requiring proxies with exposed/routable IPs (something you seem to require in the above discussion about L3 information) or requiring load balancers that are aware of the new protocol. Do you agree? Which of the two limitations do you want to assume? Alex. > >Are the following three requirements correct? > > > > 1) Agents need to communicate metainformation to each other > > 2) metainformation is related to some application protocol, but > > agent communication protocol should be application agnostic > > (i.e., should work with many application protocols) > > 3) some agents are being load balanced with respect to the > > application protocol in question > > > >If yes, I conclude: > > > > - some agents will not have IP addresses reachable from other > > agents > > > >And, hence, > > > > - agent communication without assistance of load balancers > > would be impossible in general > > > >To resolve the conflict, you have two options, I think: > > > > (a) require load balancers to handle part of the communication > > (this is how HTTP, SSL, and ICAP are load balanced today) > > > > (b) limit the environment to agents that are IP-reachable > > despite being load-balanced > > (this would exclude some (many?) load balancing environments) > > > >Do you see what I am getting at? In short, if something is behind a > >load balancer, that something may not have a routable IP address > >and, hence, cannot communicate directly with the world. > > > >Whether you chose (a) or (b), you still need a new protocol or new > >protocol profile to support the metainformation exchange. From ilpvzmqgw@dortmund.netsurf.de Mon Mar 22 19:24:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06050 for ; Mon, 22 Mar 2004 19:24:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Zim-0005tn-00 for opes-archive@ietf.org; Mon, 22 Mar 2004 19:24:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Zht-0005pX-00 for opes-archive@ietf.org; Mon, 22 Mar 2004 19:23:50 -0500 Received: from lsanca2-ar31-4-33-245-162.lsanca2.dsl-verizon.net ([4.33.245.162]) by ietf-mx with smtp (Exim 4.12) id 1B5ZhS-0005kj-00 for opes-archive@ietf.org; Mon, 22 Mar 2004 19:23:23 -0500 Received: from [236.131.59.34] by lsanca2-ar31-4-33-245-162.lsanca2.dsl-verizon.net SMTP id P9T910BNof4pf7; Mon, 22 Mar 2004 18:22:23 -0600 Message-ID: <5-d8$4o39--jv8$2$$z-r$3dr@4ds3.ee9ta1> From: "Aline Weston" Reply-To: "Aline Weston" To: opes-archive@ietf.org Subject: Cash in on other people's businesses Date: Mon, 22 Mar 04 18:22:23 GMT X-Mailer: Microsoft Outlook Express 6.00.2600.0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="6.2EBBA__.5._93" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=11.4 required=5.0 tests=BIZ_TLD,DATE_IN_PAST_03_06, DATE_SPAMWARE_Y2K,FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,HTML_40_50, HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,MISSING_MIMEOLE autolearn=no version=2.60 X-Spam-Report: * 4.4 DATE_SPAMWARE_Y2K Date header uses unusual Y2K formatting * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.8 BIZ_TLD URI: Contains a URL in the BIZ top-level domain * 0.7 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date * 1.2 MISSING_MIMEOLE Message has X-MSMail-Priority, but no X-MimeOLE * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook --6.2EBBA__.5._93 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable western

     

    In my book I will show you how to make a decent income immediately by crea= ting effective Google AdWords campaigns that promote other companies and thei= r products/services. You will be paid each time your ad generates a sale or sign up!

    I don't want any more emails

    wtfk z desdiosh rm x b --6.2EBBA__.5._93-- From owner-ietf-openproxy@mail.imc.org Thu Mar 25 17:03:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27385 for ; Thu, 25 Mar 2004 17:03:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6cwm-0006W4-00 for opes-archive@ietf.org; Thu, 25 Mar 2004 17:03:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6cw3-0006RU-00 for opes-archive@ietf.org; Thu, 25 Mar 2004 17:02:48 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B6cvE-0006Jc-00 for opes-archive@ietf.org; Thu, 25 Mar 2004 17:01:56 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PLbLiY071194; Thu, 25 Mar 2004 13:37:21 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2PLbL6d071193; Thu, 25 Mar 2004 13:37:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PLbKds071187 for ; Thu, 25 Mar 2004 13:37:20 -0800 (PST) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i2PLbOuH089131 for ; Thu, 25 Mar 2004 14:37:25 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i2PLbEWT089130; Thu, 25 Mar 2004 14:37:14 -0700 (MST) (envelope-from rousskov) Date: Thu, 25 Mar 2004 14:37:14 -0700 (MST) From: Alex Rousskov To: OPES WG Subject: Revised ID Needed for draft-ietf-opes-iab-04? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 According to IESG ID tracker, a revised version is needed for draft-ietf-opes-iab-04. I do not think I have received any information regarding this decision from the IESG. Could somebody (Chairs?) please let me know: (a) is this the time to start revising the ID? (b) is there a list of problems that must be fixed? (c) once revised, does the ID go directly to IESG or do we start the process from scratch? As for (b), the ID Tracker gives access to "IN IESG DISCUSSION" items. However, some of the IESG people raising questions in those items later change their position from Discuss to No Objection. Can their questions be ignored if, for example, it is not clear what they want or addressing their (now removed?) objections may open new objections? Will there be a concise/precise list of objections that must be addressed? Or should we do our best to guess what needs to be changed and resubmit? Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Thu Mar 25 18:38:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03151 for ; Thu, 25 Mar 2004 18:38:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6eQk-0004oF-00 for opes-archive@ietf.org; Thu, 25 Mar 2004 18:38:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ePs-0004ld-00 for opes-archive@ietf.org; Thu, 25 Mar 2004 18:37:41 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B6ePJ-0004iw-00 for opes-archive@ietf.org; Thu, 25 Mar 2004 18:37:05 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PN85JI076967; Thu, 25 Mar 2004 15:08:05 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2PN85iT076966; Thu, 25 Mar 2004 15:08:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2PN84lt076960 for ; Thu, 25 Mar 2004 15:08:04 -0800 (PST) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i2PN89lb010878 for ; Thu, 25 Mar 2004 18:08:09 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i2PN82i7055037 for ; Thu, 25 Mar 2004 18:08:02 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i2PN81kg000583 for ; Thu, 25 Mar 2004 18:08:02 -0500 (EST) Message-ID: <406366CC.2070605@mhof.com> Date: Thu, 25 Mar 2004 18:10:04 -0500 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.5+ (Windows/20040312) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: Revised ID Needed for draft-ietf-opes-iab-04? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex, it's on my to-do list, and I apologize for the delay in getting this started - too many things happened recently... I'll try to send out a note to the list, which is overdue. But in general, yes, it's time to re-work the drafts based on IESG feedback. I also don't have much more than what's available in the ID tracker, though. Thanks, Markus Alex Rousskov wrote: > > According to IESG ID tracker, a revised version is needed for > draft-ietf-opes-iab-04. I do not think I have received any information > regarding this decision from the IESG. Could somebody (Chairs?) please > let me know: > > (a) is this the time to start revising the ID? > (b) is there a list of problems that must be fixed? > (c) once revised, does the ID go directly to IESG or > do we start the process from scratch? > > As for (b), the ID Tracker gives access to "IN IESG DISCUSSION" items. > However, some of the IESG people raising questions in those items > later change their position from Discuss to No Objection. Can their > questions be ignored if, for example, it is not clear what they want > or addressing their (now removed?) objections may open new objections? > Will there be a concise/precise list of objections that must be > addressed? Or should we do our best to guess what needs to be changed > and resubmit? > > Thank you, > > Alex. > From owner-ietf-openproxy@mail.imc.org Thu Mar 25 20:18:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07109 for ; Thu, 25 Mar 2004 20:18:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6fzf-0003TC-00 for opes-archive@ietf.org; Thu, 25 Mar 2004 20:18:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6fys-0003PO-00 for opes-archive@ietf.org; Thu, 25 Mar 2004 20:17:55 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B6fy5-0003Kz-00 for opes-archive@ietf.org; Thu, 25 Mar 2004 20:17:05 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q0iW1J083599; Thu, 25 Mar 2004 16:44:32 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2Q0iWqb083598; Thu, 25 Mar 2004 16:44:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from mail.radioburst.com (mail.esmartstart.com [66.119.143.50]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2Q0iVhh083591 for ; Thu, 25 Mar 2004 16:44:32 -0800 (PST) (envelope-from ho@alum.mit.edu) Received: from localhost.localdomain (user-153.grifflink1.fiber.net [209.90.91.153]) by mail.radioburst.com (8.12.8/8.12.8) with ESMTP id i2Q0iOdM027812 for ; Thu, 25 Mar 2004 17:44:31 -0700 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.8/8.11.6) with ESMTP id i2Q0iatt029591 for ; Thu, 25 Mar 2004 17:44:36 -0700 Received: (from ho@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id i2Q0iZ1P029587; Thu, 25 Mar 2004 17:44:35 -0700 Date: Thu, 25 Mar 2004 17:44:35 -0700 Message-Id: <200403260044.i2Q0iZ1P029587@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: ietf-openproxy@imc.org In-reply-to: Yourmessage <406366CC.2070605@mhof.com> Subject: Re: Revised ID Needed for draft-ietf-opes-iab-04? X-esmartscan-MailScanner: Found to be clean Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 The main objection seemed to be the confusing example about notifications, which seems to have little relevance to OPES protocol issues. The example calls for a note to be sent from a child ISP to a parent company when a user reconfigures his preferences in such a way as to subvert a policy of the parent company. OPES is only indirectly involved, if at all. Is there a better example? I'm not sure if the IESG comments about "one-party consent" are an objection or not. The architecture is clearly in compliance with the IAB recommendation, and perhaps that could be stressed more. The last paragraph of the one-party consent section is a little confusing. It calls copying an "adaptation" that cannot be detected. I think that the issue is more simply described as content privacy. Hilarie From owner-ietf-openproxy@mail.imc.org Fri Mar 26 10:08:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23867 for ; Fri, 26 Mar 2004 10:08:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6swe-0003k5-00 for opes-archive@ietf.org; Fri, 26 Mar 2004 10:08:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6sve-0003bE-00 for opes-archive@ietf.org; Fri, 26 Mar 2004 10:07:27 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B6sui-0003TE-00 for opes-archive@ietf.org; Fri, 26 Mar 2004 10:06:28 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QEtmAV017245; Fri, 26 Mar 2004 06:55:48 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2QEtmhp017244; Fri, 26 Mar 2004 06:55:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2QEtkDn017238 for ; Fri, 26 Mar 2004 06:55:47 -0800 (PST) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i2QEtmOR017356 for ; Fri, 26 Mar 2004 09:55:48 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i2QEteRG001622 for ; Fri, 26 Mar 2004 09:55:40 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i2QEtdkg013872 for ; Fri, 26 Mar 2004 09:55:39 -0500 (EST) Message-ID: <406444E5.5050702@mhof.com> Date: Fri, 26 Mar 2004 09:57:41 -0500 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.5+ (Windows/20040312) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: OPEs Documents Status Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks, apology for the delay, here's the long due status report on where we are with our documents and how to proceed. Drafts in RFC Editor queue -------------------------- - draft-ietf-opes-architecture (Informational) Shown as "Holding for normative reference" (our threats draft) - draft-ietf-opes-protocol-reqs (Informational) Shown as "Holding for normative reference" (our architecture draft) - draft-ietf-opes-scenarios (Informational) - draft-ietf-opes-threats (Informational) Shown as "Holding for normative reference" (our "architecture" and "authorization" draft) It seems nothing needs to be done by the WG on these documents, except for making sure that we get the "authorization" document into the RFC Editor Queue in order to resolve the various "Holding for normative reference" blocks. Drafts we received IESG Feedback ================================ The following drafts have been reviewed by the IESG and need updates in order to address IESG comments: - draft-ietf-opes-authorization (Informational) - draft-ietf-opes-end-comm (Informational) - draft-ietf-opes-iab (Informational) For information on what issues/concerns/comments we've to address, we have to rely on the 'Details' listed at the IETF data tracker at https://datatracker.ietf.org/public/pidtracker.cgi. That's all the information we have so far. We'll try to get more details where needed. We'll start separate email threads on each of these documents (I'll send out mails when I find some time later today). For the IAB draft, let's continue discussion on the thread Alex and Hilarie started. Drafts awaiting IESG action ============================ - draft-ietf-opes-ocp-core (Proposed Standard) - draft-ietf-opes-http (Proposed Standard) If I'm not mistaken, there's nothing to do for the WG at the moment. Open Drafts =========== - draft-ietf-opes-rules-p-02 This draft is pending at the moment, since we first wanted to get clarification with our AD on how to proceed. Sicne we had a change in ADs, we need to followup again. I'll send another note to our AD. Thanks, Markus From ndeluk@pastel.ocn.ne.jp Sat Mar 27 01:39:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14543 for ; Sat, 27 Mar 2004 01:39:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B77Tv-0001RY-00 for opes-archive@ietf.org; Sat, 27 Mar 2004 01:39:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B77TA-0001LN-00 for opes-archive@ietf.org; Sat, 27 Mar 2004 01:39:00 -0500 Received: from midsouth-24-151-208-113.westtn.chartertn.net ([24.151.208.113]) by ietf-mx with smtp (Exim 4.12) id 1B77S3-0001DV-00 for opes-archive@ietf.org; Sat, 27 Mar 2004 01:37:52 -0500 Received: from 140.85.204.234 by 24.151.208.113; Sat, 27 Mar 2004 11:31:49 +0500 Message-ID: From: "Leslie Suarez" Reply-To: "Leslie Suarez" To: opes-archive@ietf.org Subject: How to cash in on other people's success Date: Sat, 27 Mar 2004 00:33:49 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--52607496342357188890" X-Webmail-Time: Sat, 27 Mar 2004 10:31:49 +0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.5 required=5.0 tests=BIZ_TLD,HTML_40_50, HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----52607496342357188890 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable derek downtown inefficacy drawbridge wove parallax kin eyesight and= orra cruise intermit caliph ascribe anorthic cathode clerk pusey archimede= s paunchy=20

     

    Cash in with Google makes earning an affiliate income very simple. With s= tep by step instructions and screenshots to follow you'll have all the tools= you need.

    no more emails please

    ----52607496342357188890-- From wqwhggrkvi@uky.edu Sat Mar 27 03:13:39 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01330 for ; Sat, 27 Mar 2004 03:13:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B78wk-0001rP-00 for opes-archive@ietf.org; Sat, 27 Mar 2004 03:13:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B78vs-0001n5-00 for opes-archive@ietf.org; Sat, 27 Mar 2004 03:12:45 -0500 Received: from [208.62.166.66] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1B78vF-0001iT-00 for opes-archive@ietf.org; Sat, 27 Mar 2004 03:12:05 -0500 Received: from 106.200.227.137 by 208.62.166.66; Sat, 27 Mar 2004 10:09:32 +0200 Message-ID: From: "Michel Simons" Reply-To: "Michel Simons" To: opes-archive@ietf.org Subject: Fwd: Any Meds U Want! Order Online with No Prior Prescription. Best Source. Date: Sat, 27 Mar 2004 05:09:32 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--366594457337198" X-Priority: 3 X-IP: 144.104.104.108 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.5 required=5.0 tests=BIZ_TLD,CLICK_BELOW,HTML_40_50, HTML_FONTCOLOR_UNSAFE,HTML_LINK_CLICK_HERE,HTML_MESSAGE, MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI, PRIORITY_NO_NAME,RCVD_NUMERIC_HELO autolearn=no version=2.60 ----366594457337198 Content-Type: text/html; Content-Transfer-Encoding: 7Bit

    Hello,

    improving the quality of people's lives is what Prescription Medications are designed to do and CheapestMeds believes that you deserve access to these medications. By having doctors available to review your needs, CheapestMeds is ready to help you get the treatment you need.

    Make it easy for you to order meds. Click here.

    Gbridgeport beman thy science svelte credulity boxy josephson tang deltoid robust skyjack introductory synopsis clearance diploid athabascan carboxy marksmen !! Gthirteenth october tetanus till glendale cluj harmonic buggy boron commandeer pork banter boisterous bowstring disk licorice bedpost intuitable unesco ; Kburdock tutelage ultra count almond redbud stonewort incontrovertible turbinate supposable dukedom debar countersunk dare jo mulatto effusion digital profligacy perennial marriage quota supremacy centroid melanie billet introvert brahmaputra patrolling whatever contravene etymology infirm automaton quezon .

    If this notice has reached you in error, please notify us by clicking here ----366594457337198-- From WAABTDGHJSG@interlink.es Sat Mar 27 17:09:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02446 for ; Sat, 27 Mar 2004 17:09:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7LzH-0007VZ-00 for opes-archive@ietf.org; Sat, 27 Mar 2004 17:09:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7LyP-0007QR-00 for opes-archive@ietf.org; Sat, 27 Mar 2004 17:08:14 -0500 Received: from [210.207.122.165] (helo=132.151.6.1) by ietf-mx with smtp (Exim 4.12) id 1B7Lxj-0007KX-00 for opes-archive@ietf.org; Sat, 27 Mar 2004 17:07:32 -0500 Received: from 168.192.208.46 by 132.151.6.1; Sun, 28 Mar 2004 00:07:26 +0200 Message-ID: From: "Delmer Goldsmith" Reply-To: "Delmer Goldsmith" To: opes-archive@ietf.org Subject: Make online profits without a website Date: Sat, 27 Mar 2004 15:07:26 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--72311929049888893" X-Priority: 3 X-CS-IP: 16.164.32.216 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.3 required=5.0 tests=BIZ_TLD,HTML_50_60, HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,PRIORITY_NO_NAME, RCVD_NUMERIC_HELO autolearn=no version=2.60 ----72311929049888893 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable 36.234.238.12

     

    With my proven strategies you'll make more money online than most other web = sites do and you won't even need to have a website!

    I don't want more emails

    ----72311929049888893-- From azzoy@free-online.net Sun Mar 28 15:20:43 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02993 for ; Sun, 28 Mar 2004 15:20:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7glw-0000ic-00 for opes-archive@ietf.org; Sun, 28 Mar 2004 15:20:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7gl0-0000cL-00 for opes-archive@ietf.org; Sun, 28 Mar 2004 15:19:46 -0500 Received: from bgp430994bgs.union01.nj.comcast.net ([68.36.217.88]) by ietf-mx with smtp (Exim 4.12) id 1B7gk7-0000Vy-00 for opes-archive@ietf.org; Sun, 28 Mar 2004 15:18:52 -0500 From: "Jules Langley" To: Date: Sun, 28 Mar 2004 17:16:19 -0300 Message-Id: Mime-Version: 1.0 X-Sent-Mail: on Reply-To: azzoy@free-online.net X-Mailer: MailCity Service X-Priority: 3 Subject: Fwd: Need Meds? We Got Them. No prescription needed. Best Source Online. FedEx delivered X-Sender-IP: 192.16.82.229 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: multipart/alternative; boundary="=_-=_-WCSGWMBXEVGAAAA" Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=BIZ_TLD,HTML_50_60, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE autolearn=no version=2.60 --=_-=_-WCSGWMBXEVGAAAA Content-Type: text/html; Content-Transfer-Encoding: 7Bit

    Hello,

    CheapestMeds offers online prescriptions for FDA-approved medication. Upon approval a prescription will be issued for an FDA-approved medication of your choice.

    Absolutely No Doctor Appointment Needed!

    Order by 2 pm EST and you get your meds tomorrow.

    Get your meds here

    Cpernicious degrade cowmen gerontology northrop triangulate numerable equilibria poverty camaraderie vibrant backlash sawtooth backtrack construct royce minutiae ; Hdrexel patrimonial cathode mercenary christmas : Udispensate combatant solution regurgitate confide fluency embassy pocus .

    If this notice has reached you in error, please notify us by clicking here --=_-=_-WCSGWMBXEVGAAAA-- From owner-ietf-openproxy@mail.imc.org Mon Mar 29 08:47:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02136 for ; Mon, 29 Mar 2004 08:47:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7x6t-0003gc-00 for opes-archive@ietf.org; Mon, 29 Mar 2004 08:47:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7x61-0003Zg-00 for opes-archive@ietf.org; Mon, 29 Mar 2004 08:46:34 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B7x5V-0003SF-00 for opes-archive@ietf.org; Mon, 29 Mar 2004 08:46:01 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2TDYg3M040530; Mon, 29 Mar 2004 05:34:42 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2TDYgRR040529; Mon, 29 Mar 2004 05:34:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2TDYfNx040508 for ; Mon, 29 Mar 2004 05:34:41 -0800 (PST) (envelope-from markus@mhof.com) Received: from mhof.com (unknown[135.104.20.88]) by comcast.net (rwcrmhc13) with ESMTP id <20040329133437015008t6ope> (Authid: biena2004); Mon, 29 Mar 2004 13:34:38 +0000 Message-ID: <406825F0.9090106@mhof.com> Date: Mon, 29 Mar 2004 08:34:40 -0500 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.5+ (Windows/20040312) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Work on Rules Language Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks, the deadline for our rules language document was October last year. This deadline has already been extended a few times. So we need to decide on how to move on with this document. Based on earlier discussions on the mailing list about status and work needed, we checked with Ted (our AD) and discussed the following options: (1) Produce a minimal draft on "P" now, knowing that it will not be sufficient and be obsolete if the group gets re-chartered and if it continues to work on "P". Pros: We would meet the charter item Cons: Wastes time (assuming "P" will be in possible re-charter) (2) Extend the current deadline for another 2-4 months. (3) Remove this specific work item from our current charter and put it up for consideration in a possible re-charter. After discussions with Ted, we believe that choice (3) is the most sensible, as it allows us to actually to do the work we believe needs doing, and all this in a realistic time frame. We also won't waste any time completing a document that won't meet our needs. As such, we'll send a request to our AD and to the secretariat to remove the OPES rules language from our current charter and include it in discussions for a re-charter. Any strong objections? Thanks, Markus From owner-ietf-openproxy@mail.imc.org Mon Mar 29 12:11:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12690 for ; Mon, 29 Mar 2004 12:11:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B80IM-0002aA-00 for opes-archive@ietf.org; Mon, 29 Mar 2004 12:11:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B80HP-0002SW-00 for opes-archive@ietf.org; Mon, 29 Mar 2004 12:10:32 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B80GT-0002JL-00 for opes-archive@ietf.org; Mon, 29 Mar 2004 12:09:33 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2TGtwBq054780; Mon, 29 Mar 2004 08:55:58 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2TGtwRa054779; Mon, 29 Mar 2004 08:55:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2TGttGi054767 for ; Mon, 29 Mar 2004 08:55:56 -0800 (PST) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i2TGtvuH091990; Mon, 29 Mar 2004 09:55:57 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i2TGtuQO091989; Mon, 29 Mar 2004 09:55:56 -0700 (MST) (envelope-from rousskov) Date: Mon, 29 Mar 2004 09:55:56 -0700 (MST) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: Re: Work on Rules Language In-Reply-To: <406825F0.9090106@mhof.com> Message-ID: References: <406825F0.9090106@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, 29 Mar 2004, Markus Hofmann wrote: > (3) Remove this specific work item from our current charter and > put it up for consideration in a possible re-charter. > > After discussions with Ted, we believe that choice (3) is the most > sensible, as it allows us to actually to do the work we believe needs > doing, and all this in a realistic time frame. We also won't waste any > time completing a document that won't meet our needs. I agree and glad we are finally moving forward with this! Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Tue Mar 30 14:33:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06266 for ; Tue, 30 Mar 2004 14:33:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8OzI-0004lc-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 14:33:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8OyL-0004cT-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 14:32:29 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B8Oxc-0004T9-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 14:31:44 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UJJpBo040564; Tue, 30 Mar 2004 11:19:51 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2UJJpe1040563; Tue, 30 Mar 2004 11:19:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UJJoCk040557 for ; Tue, 30 Mar 2004 11:19:50 -0800 (PST) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i2UJJsOR098629 for ; Tue, 30 Mar 2004 14:19:54 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i2UJJli7079725 for ; Tue, 30 Mar 2004 14:19:47 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i2UJJlkg014151 for ; Tue, 30 Mar 2004 14:19:47 -0500 (EST) Message-ID: <4069C8CE.7050704@mhof.com> Date: Tue, 30 Mar 2004 14:21:50 -0500 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.5+ (Windows/20040326) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Work on Rules Language References: <406825F0.9090106@mhof.com> In-Reply-To: <406825F0.9090106@mhof.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks, quick update... Since our request removes a milestone from the current charter, this nominally requires IESG approval. We've been working with Ted (who is now bringing this to the IESG), so there shouldn't be a problem. However, it'll take a little to get this through the process. For now, we will go forward assuming the change will go through. This means that we - first, have to address comments from IESG review of our current documents, - once this is done, we'll continue discussion of possible re-charter (including the rules stuff). Thanks, Markus Markus Hofmann wrote: > > Folks, > > the deadline for our rules language document was October last year. This > deadline has already been extended a few times. So we need to decide on > how to move on with this document. > > Based on earlier discussions on the mailing list about status and work > needed, we checked with Ted (our AD) and discussed the following options: > > (1) Produce a minimal draft on "P" now, knowing that it will not > be sufficient and be obsolete if the group gets re-chartered > and if it continues to work on "P". > Pros: We would meet the charter item > Cons: Wastes time (assuming "P" will be in possible re-charter) > > (2) Extend the current deadline for another 2-4 months. > > (3) Remove this specific work item from our current charter and > put it up for consideration in a possible re-charter. > > After discussions with Ted, we believe that choice (3) is the most > sensible, as it allows us to actually to do the work we believe needs > doing, and all this in a realistic time frame. We also won't waste any > time completing a document that won't meet our needs. > > As such, we'll send a request to our AD and to the secretariat to remove > the OPES rules language from our current charter and include it in > discussions for a re-charter. > > Any strong objections? > > Thanks, > Markus > From owner-ietf-openproxy@mail.imc.org Tue Mar 30 14:39:29 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06439 for ; Tue, 30 Mar 2004 14:39:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8P57-0005dU-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 14:39:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8P4B-0005Tr-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 14:38:31 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B8P3O-0005Ly-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 14:37:42 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UJAUq3039471; Tue, 30 Mar 2004 11:10:30 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2UJAUaS039470; Tue, 30 Mar 2004 11:10:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UJATYc039463 for ; Tue, 30 Mar 2004 11:10:30 -0800 (PST) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i2UJAWOR098525; Tue, 30 Mar 2004 14:10:32 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i2UJAPRG098524; Tue, 30 Mar 2004 14:10:25 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i2UJAPkg013902; Tue, 30 Mar 2004 14:10:25 -0500 (EST) Message-ID: <4069C69C.5070201@mhof.com> Date: Tue, 30 Mar 2004 14:12:28 -0500 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.5+ (Windows/20040326) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org, Ted Hardie Subject: Re: Revised ID Needed for draft-ietf-opes-iab-04? References: <200403260044.i2Q0iZ1P029587@localhost.localdomain> In-Reply-To: <200403260044.i2Q0iZ1P029587@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks, as pointed out earlier, the IETF ID tracker shows that a revised version of our IAB considerations document is needed. I don't have any more information that what the IETF tracker at http://datatracker.ietf.org/ shows, so let's work from there. [Ted - if you've any more information and/or advice on what exactly we're expected to do, please let us know! Thanks.] From looking at the comments in the ID tracker, and as summarized by Hilarie, it seems we need to address the following issues: - We need to re-work the notification example given in Section 5.1, the comment we received is certainly valid and I'd suggest to use a different example. What about using an example in which the content provider receives notification that her content was rejected by an OPES virus scanning service? This would give the content provider the opportunity to verify its content, and if there's an error with the virus scanner, to inform the OPES service provider. This example also seems to be close to the one used in the original IAB document. - Clarification is need on our Section 7 (URI adaption vs. URI resolution). - Section 3 needs some clarification. I don't believe that there's a fundamental problem here, re-wording might do it. - The security considerations section was considered "inadequate" by a reviewer and it was asked to add "pointers to sections that discuss [...] integrity and confidentiality". Can we do that? Please also see Hilarie's comments (cited below). Alex, Abbie - can you start working on an updated version that will address these issues and share it with the group? When do you think we'd be able to have such updated version? Ted - please let us know if there's anything that would help us in making sure the updated version will pass IESG. Thanks, Markus The Purple Streak, Hilarie Orman wrote: > The main objection seemed to be the confusing example about > notifications, which seems to have little relevance to OPES > protocol issues. The example calls for a note to be sent from a > child ISP to a parent company when a user reconfigures his > preferences in such a way as to subvert a policy of the parent > company. OPES is only indirectly involved, if at all. Is there a > better example? > > I'm not sure if the IESG comments about "one-party consent" are an > objection or not. The architecture is clearly in compliance with > the IAB recommendation, and perhaps that could be stressed more. > > The last paragraph of the one-party consent section is a little > confusing. It calls copying an "adaptation" that cannot be > detected. I think that the issue is more simply described as > content privacy. > > Hilarie > From owner-ietf-openproxy@mail.imc.org Tue Mar 30 14:53:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06995 for ; Tue, 30 Mar 2004 14:53:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8PIj-0007nT-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 14:53:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8PHt-0007eo-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 14:52:41 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B8PHI-0007W0-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 14:52:04 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UJd3lO042102; Tue, 30 Mar 2004 11:39:03 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2UJd23o042101; Tue, 30 Mar 2004 11:39:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UJd2tt042095 for ; Tue, 30 Mar 2004 11:39:02 -0800 (PST) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i2UJd6OR098861 for ; Tue, 30 Mar 2004 14:39:06 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i2UJcxRG002287 for ; Tue, 30 Mar 2004 14:38:59 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i2UJcwkg014771 for ; Tue, 30 Mar 2004 14:38:59 -0500 (EST) Message-ID: <4069CD4E.8090303@mhof.com> Date: Tue, 30 Mar 2004 14:41:02 -0500 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.5+ (Windows/20040326) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Revides ID needed for draft-ietf-opes-authorization-02 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks, we also need to revise our draft draft-ietf-opes-authorization-02. All the information we've so far is in the ID tracker, which says - No security consideration section - All-caps MUST, SHOULD, etc. used but not defined - Lots of lower case musts that may need to be upper case; please review. - Look for note from Allison descibing additional concerns. While were waiting for the notes from Allison, we ca ncertainly already get started to address the first three conerns. Abbie - as the master editor, can you please take a lead and work with the other document authors to address these issues? Thanks! Thanks, Markus From owner-ietf-openproxy@mail.imc.org Tue Mar 30 15:38:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10536 for ; Tue, 30 Mar 2004 15:38:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8Q0I-0004u9-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 15:38:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8PzT-0004rp-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 15:37:44 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B8Pyd-0004og-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 15:36:51 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UKMhup045178; Tue, 30 Mar 2004 12:22:48 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2UKMhxR045177; Tue, 30 Mar 2004 12:22:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UKMgMh045170 for ; Tue, 30 Mar 2004 12:22:43 -0800 (PST) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i2UKMkuH055829; Tue, 30 Mar 2004 13:22:46 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i2UKMkxT055828; Tue, 30 Mar 2004 13:22:46 -0700 (MST) (envelope-from rousskov) Date: Tue, 30 Mar 2004 13:22:46 -0700 (MST) From: Alex Rousskov To: Markus Hofmann cc: OPES WG Subject: Re: Revised ID Needed for draft-ietf-opes-iab-04? In-Reply-To: <4069C69C.5070201@mhof.com> Message-ID: References: <200403260044.i2Q0iZ1P029587@localhost.localdomain> <4069C69C.5070201@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Markus, I will start working on these issues and will post suggested changes. I hope I can fix all of them except I am not quite sure about the "inadequate security considerations section" comment. I can address the latter by providing a list of Security Sections in the other drafts, but doing so seems silly/redundant. The example you suggest may not be appropriate because pro-actively notifying 3rd parties of viruses and such is becoming less and less popular idea (there were some IETF drafts about that IIRC). Thank you, Alex. P.S. I did not receive Hilarie's and another message for some reason. Found both in the list archive. Others may want to check that they did not miss any recent posts. On Tue, 30 Mar 2004, Markus Hofmann wrote: > > Folks, > > as pointed out earlier, the IETF ID tracker shows that a revised > version of our IAB considerations document is needed. I don't have any > more information that what the IETF tracker at > > http://datatracker.ietf.org/ > > shows, so let's work from there. > > [Ted - if you've any more information and/or advice on what exactly > we're expected to do, please let us know! Thanks.] > > From looking at the comments in the ID tracker, and as summarized by > Hilarie, it seems we need to address the following issues: > > - We need to re-work the notification example given in Section 5.1, > the comment we received is certainly valid and I'd suggest to use > a different example. What about using an example in which the > content provider receives notification that her content was rejected > by an OPES virus scanning service? This would give the content > provider the opportunity to verify its content, and if there's an > error with the virus scanner, to inform the OPES service provider. > This example also seems to be close to the one used in the original > IAB document. > > - Clarification is need on our Section 7 (URI adaption vs. URI > resolution). > > - Section 3 needs some clarification. I don't believe that there's a > fundamental problem here, re-wording might do it. > > - The security considerations section was considered "inadequate" by > a reviewer and it was asked to add "pointers to sections that > discuss [...] integrity and confidentiality". Can we do that? > > Please also see Hilarie's comments (cited below). > > Alex, Abbie - can you start working on an updated version that will > address these issues and share it with the group? When do you think > we'd be able to have such updated version? > > Ted - please let us know if there's anything that would help us in > making sure the updated version will pass IESG. > > Thanks, > Markus > > > The Purple Streak, Hilarie Orman wrote: > > > The main objection seemed to be the confusing example about > > notifications, which seems to have little relevance to OPES > > protocol issues. The example calls for a note to be sent from a > > child ISP to a parent company when a user reconfigures his > > preferences in such a way as to subvert a policy of the parent > > company. OPES is only indirectly involved, if at all. Is there a > > better example? > > > > I'm not sure if the IESG comments about "one-party consent" are an > > objection or not. The architecture is clearly in compliance with > > the IAB recommendation, and perhaps that could be stressed more. > > > > The last paragraph of the one-party consent section is a little > > confusing. It calls copying an "adaptation" that cannot be > > detected. I think that the issue is more simply described as > > content privacy. > > > > Hilarie > > > > From owner-ietf-openproxy@mail.imc.org Tue Mar 30 15:46:37 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10843 for ; Tue, 30 Mar 2004 15:46:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8Q86-0005Hn-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 15:46:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8Q7D-0005FL-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 15:45:43 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B8Q6w-0005Ca-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 15:45:26 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UKZ5wl045950; Tue, 30 Mar 2004 12:35:05 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2UKZ54a045949; Tue, 30 Mar 2004 12:35:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UKZ3fW045943 for ; Tue, 30 Mar 2004 12:35:04 -0800 (PST) (envelope-from markus@mhof.com) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i2UKZ7OR099586 for ; Tue, 30 Mar 2004 15:35:07 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i2UKZ0RG008832 for ; Tue, 30 Mar 2004 15:35:01 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i2UKZ0kg016186 for ; Tue, 30 Mar 2004 15:35:00 -0500 (EST) Message-ID: <4069DA6F.9050307@mhof.com> Date: Tue, 30 Mar 2004 15:37:03 -0500 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.5+ (Windows/20040326) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES WG Subject: Re: Revised ID Needed for draft-ietf-opes-iab-04? References: <200403260044.i2Q0iZ1P029587@localhost.localdomain> <4069C69C.5070201@mhof.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex, > I will start working on these issues and will post suggested > changes. Excellent, thanks!! > I hope I can fix all of them except I am not quite sure about > the "inadequate security considerations section" comment. I can > address the latter by providing a list of Security Sections in the > other drafts, but doing so seems silly/redundant. My feeling is that this might be sufficient, since I believe the security considerations are already address elsewhere, we just need to point it out. If we can address the comment and thereby pass IESG review, we should do so. > The example you suggest may not be appropriate because > pro-actively notifying 3rd parties of viruses and such is becoming less > and less popular idea (there were some IETF drafts about that IIRC). You're right, I remember previous comments along those lines. Any other suggestions, anyone? -Markus From owner-ietf-openproxy@mail.imc.org Tue Mar 30 15:59:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11482 for ; Tue, 30 Mar 2004 15:59:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8QKi-0005xr-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 15:59:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8QJr-0005uf-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 15:58:48 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B8QJT-0005rK-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 15:58:23 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UKi0jj046333; Tue, 30 Mar 2004 12:44:00 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2UKi0TU046332; Tue, 30 Mar 2004 12:44:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UKhxlw046326 for ; Tue, 30 Mar 2004 12:43:59 -0800 (PST) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i2UKi4lb005178 for ; Tue, 30 Mar 2004 15:44:04 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i2UKhsi7090108 for ; Tue, 30 Mar 2004 15:43:54 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i2UKhskg016384 for ; Tue, 30 Mar 2004 15:43:54 -0500 (EST) Message-ID: <4069DC85.5030709@mhof.com> Date: Tue, 30 Mar 2004 15:45:57 -0500 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.5+ (Windows/20040326) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Revides ID needed for draft-ietf-opes-authorization-02 References: <4069CD4E.8090303@mhof.com> In-Reply-To: <4069CD4E.8090303@mhof.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks, Allison just gave the OK to move forward with the document, so we just need to add a reference to RFC 2119 and address the "must" vs. "MUST" issue. Once this is done, we'll notifiy Ted and he'll take it from there. Abbie - can you take care of this? If not, please let us know so that someone else does it. Thanks, Markus Markus Hofmann wrote: > > Folks, > > we also need to revise our draft draft-ietf-opes-authorization-02. All > the information we've so far is in the ID tracker, which says > > - No security consideration section > - All-caps MUST, SHOULD, etc. used but not defined > - Lots of lower case musts that may need to be upper case; > please review. > - Look for note from Allison descibing additional > concerns. > > While were waiting for the notes from Allison, we ca ncertainly already > get started to address the first three conerns. > > Abbie - as the master editor, can you please take a lead and work with > the other document authors to address these issues? Thanks! > > Thanks, > Markus > From owner-ietf-openproxy@mail.imc.org Tue Mar 30 17:13:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16519 for ; Tue, 30 Mar 2004 17:13:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8RTn-0004MY-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 17:13:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8RRX-0003z6-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 17:10:48 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B8RNi-0003TB-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 17:06:50 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2ULscf0050951; Tue, 30 Mar 2004 13:54:38 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2ULsc1M050950; Tue, 30 Mar 2004 13:54:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2ULsabE050943 for ; Tue, 30 Mar 2004 13:54:36 -0800 (PST) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i2ULsflb006374 for ; Tue, 30 Mar 2004 16:54:41 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i2ULsVi7099257 for ; Tue, 30 Mar 2004 16:54:31 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i2ULsUkg018347 for ; Tue, 30 Mar 2004 16:54:31 -0500 (EST) Message-ID: <4069ED12.8000606@mhof.com> Date: Tue, 30 Mar 2004 16:56:34 -0500 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.5+ (Windows/20040326) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Revised ID needed for draft-ietf-opes-end-comm-06.txt Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Folks, here's the third of our pending drafts. We also deed to revise our tracing draft draft-ietf-opes-end-comm-06.txt. Please see ID tracker at https://datatracker.ietf.org for details. In summary, it looks like the following issues needs to be addressed: - The design choice in Section 4 needs to be explained/motivated better, i.e. why is a bypass request ignored rather than an error message returned when there's no non-opes version. Our text explains that it might be impossible for a specific OPES intermediary to determine whether a non-opes version is available or not. In this case, it makes sense to *not* send an error message and ignore the request. But if the intermediary can determine that no non-opes version is available, there might be scenarios where an error message might be preferred over ignoring the bypass. - Section 8.2 discusses a threat introduced by using OPES for wiretap, but according to RFC 2804, the "IETF has decided not to consider requirements for wiretapping as part of the process for creating and maintaining IETF standards." Seems like removing this specific threat scenario from Section 8.2 will address this specific comment. - The Security and Authorization requirements should be made normative. Abbie - if you need someone to help with these or need some discussion, please let us know. Otherwise, let's get the changes in and re-submit. Thanks, Markus From owner-ietf-openproxy@mail.imc.org Tue Mar 30 17:51:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20818 for ; Tue, 30 Mar 2004 17:51:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8S5G-00005L-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 17:51:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8S4M-0007nJ-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 17:50:55 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B8S3T-0007iO-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 17:50:00 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UMcDJ5053406; Tue, 30 Mar 2004 14:38:13 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2UMcDsp053405; Tue, 30 Mar 2004 14:38:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UMcC3L053398 for ; Tue, 30 Mar 2004 14:38:12 -0800 (PST) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i2UMcAk21232; Tue, 30 Mar 2004 17:38:10 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Mar 2004 17:38:11 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD75408FE8FEB@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Markus Hofmann , OPES Group Subject: RE: Revides ID needed for draft-ietf-opes-authorization-02 Date: Tue, 30 Mar 2004 17:38:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C416A7.A950A762" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 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_01C416A7.A950A762 Content-Type: text/plain will do abbie > -----Original Message----- > From: Markus Hofmann [mailto:markus@mhof.com] > Sent: Tuesday, March 30, 2004 3:46 PM > To: OPES Group > Subject: Re: Revides ID needed for draft-ietf-opes-authorization-02 > > > > Folks, > > Allison just gave the OK to move forward with the document, > so we just > need to add a reference to RFC 2119 and address the "must" vs. "MUST" > issue. > > Once this is done, we'll notifiy Ted and he'll take it from there. > > Abbie - can you take care of this? If not, please let us know so that > someone else does it. > > Thanks, > Markus > > > Markus Hofmann wrote: > > > > > Folks, > > > > we also need to revise our draft > draft-ietf-opes-authorization-02. All > > the information we've so far is in the ID tracker, which says > > > > - No security consideration section > > - All-caps MUST, SHOULD, etc. used but not defined > > - Lots of lower case musts that may need to be upper case; > > please review. > > - Look for note from Allison descibing additional > > concerns. > > > > While were waiting for the notes from Allison, we ca ncertainly > > already > > get started to address the first three conerns. > > > > Abbie - as the master editor, can you please take a lead > and work with > > the other document authors to address these issues? Thanks! > > > > Thanks, > > Markus > > > > ------_=_NextPart_001_01C416A7.A950A762 Content-Type: text/html RE: Revides ID needed for draft-ietf-opes-authorization-02

    will do

    abbie

    > -----Original Message-----
    > From: Markus Hofmann [mailto:markus@mhof.com]
    > Sent: Tuesday, March 30, 2004 3:46 PM
    > To: OPES Group
    > Subject: Re: Revides ID needed for draft-ietf-opes-authorization-02
    >
    >
    >
    > Folks,
    >
    > Allison just gave the OK to move forward with the document,
    > so we just
    > need to add a reference to RFC 2119 and address the "must" vs. "MUST"
    > issue.
    >
    > Once this is done, we'll notifiy Ted and he'll take it from there.
    >
    > Abbie - can you take care of this? If not, please let us know so that
    > someone else does it.
    >
    > Thanks,
    >    Markus
    >
    >
    > Markus Hofmann wrote:
    >
    > >
    > > Folks,
    > >
    > > we also need to revise our draft
    > draft-ietf-opes-authorization-02. All
    > > the information we've so far is in the ID tracker, which says
    > >
    > >  - No security consideration section
    > >  - All-caps MUST, SHOULD, etc. used but not defined
    > >  - Lots of lower case musts that may need to be upper case;
    > >    please review.
    > >  - Look for note from Allison descibing additional
    > >    concerns.
    > >
    > > While were waiting for the notes from Allison, we ca ncertainly
    > > already
    > > get started to address the first three conerns.
    > >
    > > Abbie - as the master editor, can you please take a lead
    > and work with
    > > the other document authors to address these issues? Thanks!
    > >
    > > Thanks,
    > >   Markus
    > >
    >
    >

    ------_=_NextPart_001_01C416A7.A950A762-- From owner-ietf-openproxy@mail.imc.org Tue Mar 30 17:56:49 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21971 for ; Tue, 30 Mar 2004 17:56:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8SA7-0000Vd-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 17:56:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8S9L-0000RX-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 17:56:04 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B8S8I-0000ML-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 17:54:58 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UMcZkC053448; Tue, 30 Mar 2004 14:38:35 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2UMcZSm053447; Tue, 30 Mar 2004 14:38:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UMcYIL053441 for ; Tue, 30 Mar 2004 14:38:34 -0800 (PST) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i2UMcduH061441; Tue, 30 Mar 2004 15:38:39 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i2UMccmJ061440; Tue, 30 Mar 2004 15:38:39 -0700 (MST) (envelope-from rousskov) Date: Tue, 30 Mar 2004 15:38:38 -0700 (MST) From: Alex Rousskov To: Markus Hofmann cc: OPES Group Subject: Re: Revised ID needed for draft-ietf-opes-end-comm-06.txt In-Reply-To: <4069ED12.8000606@mhof.com> Message-ID: References: <4069ED12.8000606@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 30 Mar 2004, Markus Hofmann wrote: > - Section 8.2 discusses a threat introduced by using OPES for > wiretap, but according to RFC 2804, the "IETF has decided not to > consider requirements for wiretapping as part of the process for > creating and maintaining IETF standards." > > Seems like removing this specific threat scenario from Section 8.2 > will address this specific comment. FWIW, I believe this comment should be addressed differently, by adding the following text (or its polished version): Following an IETF policy on Wiretapping [RFC2804], OPES communication model does not consider wiretapping requirements. Nevertheless, the documented threat is real, not obvious, and OPES technology users operating in wiretapping or similar logging environments should be aware of it. Thank you, Alex. From owner-ietf-openproxy@mail.imc.org Tue Mar 30 18:12:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26247 for ; Tue, 30 Mar 2004 18:12:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8SPK-0001v7-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 18:12:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8SOP-0001t7-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 18:11:37 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B8SNp-0001rQ-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 18:11:01 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UMsBpx054452; Tue, 30 Mar 2004 14:54:11 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2UMsB2t054451; Tue, 30 Mar 2004 14:54:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UMsATa054445 for ; Tue, 30 Mar 2004 14:54:10 -0800 (PST) (envelope-from markus@mhof.com) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id i2UMsFlb007020 for ; Tue, 30 Mar 2004 17:54:15 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id i2UMs8i7005500 for ; Tue, 30 Mar 2004 17:54:08 -0500 (EST) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id i2UMs8kg020154 for ; Tue, 30 Mar 2004 17:54:08 -0500 (EST) Message-ID: <4069FB0B.2080601@mhof.com> Date: Tue, 30 Mar 2004 17:56:11 -0500 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.5+ (Windows/20040326) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: Re: Revised ID needed for draft-ietf-opes-end-comm-06.txt References: <4069ED12.8000606@mhof.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > FWIW, I believe this comment should be addressed differently, by > adding the following text (or its polished version): > > Following an IETF policy on Wiretapping [RFC2804], OPES > communication model does not consider wiretapping requirements. > Nevertheless, the documented threat is real, not obvious, and > OPES technology users operating in wiretapping or similar > logging environments should be aware of it. I wouldn't have a problem with phrasing it that way. I actually like the idea of keeping it documented somewhere. -Markus From owner-ietf-openproxy@mail.imc.org Tue Mar 30 18:56:38 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08065 for ; Tue, 30 Mar 2004 18:56:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8T60-0004yK-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 18:56:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8T55-0004wO-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 18:55:43 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B8T4p-0004tz-00 for opes-archive@ietf.org; Tue, 30 Mar 2004 18:55:28 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UMbN9L053302; Tue, 30 Mar 2004 14:37:23 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2UMbNGc053301; Tue, 30 Mar 2004 14:37:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2UMbMeV053292 for ; Tue, 30 Mar 2004 14:37:23 -0800 (PST) (envelope-from abbieb@nortelnetworks.com) Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i2UMbJk21177; Tue, 30 Mar 2004 17:37:19 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Mar 2004 17:37:20 -0500 Message-ID: <87609AFB433BD5118D5E0002A52CD75408FE8FE8@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Markus Hofmann , OPES Group Subject: RE: Revides ID needed for draft-ietf-opes-authorization-02 Date: Tue, 30 Mar 2004 17:37:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C416A7.8EEBDF0E" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 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_01C416A7.8EEBDF0E Content-Type: text/plain will do abbie > -----Original Message----- > From: Markus Hofmann [mailto:markus@mhof.com] > Sent: Tuesday, March 30, 2004 2:41 PM > To: OPES Group > Subject: Revides ID needed for draft-ietf-opes-authorization-02 > > > > Folks, > > we also need to revise our draft > draft-ietf-opes-authorization-02. All > the information we've so far is in the ID tracker, which says > > - No security consideration section > - All-caps MUST, SHOULD, etc. used but not defined > - Lots of lower case musts that may need to be upper case; > please review. > - Look for note from Allison descibing additional > concerns. > > While were waiting for the notes from Allison, we ca ncertainly > already get started to address the first three conerns. > > Abbie - as the master editor, can you please take a lead and > work with > the other document authors to address these issues? Thanks! > > Thanks, > Markus > > ------_=_NextPart_001_01C416A7.8EEBDF0E Content-Type: text/html RE: Revides ID needed for draft-ietf-opes-authorization-02

    will do

    abbie


    > -----Original Message-----
    > From: Markus Hofmann [mailto:markus@mhof.com]
    > Sent: Tuesday, March 30, 2004 2:41 PM
    > To: OPES Group
    > Subject: Revides ID needed for draft-ietf-opes-authorization-02
    >
    >
    >
    > Folks,
    >
    > we also need to revise our draft
    > draft-ietf-opes-authorization-02. All
    > the information we've so far is in the ID tracker, which says
    >
    >   - No security consideration section
    >   - All-caps MUST, SHOULD, etc. used but not defined
    >   - Lots of lower case musts that may need to be upper case;
    >     please review.
    >   - Look for note from Allison descibing additional
    >     concerns.
    >
    > While were waiting for the notes from Allison, we ca ncertainly
    > already get started to address the first three conerns.
    >
    > Abbie - as the master editor, can you please take a lead and
    > work with
    > the other document authors to address these issues? Thanks!
    >
    > Thanks,
    >    Markus
    >
    >

    ------_=_NextPart_001_01C416A7.8EEBDF0E-- From JADTZDK@gjr.paknet.com.pk Wed Mar 31 02:03:52 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08056 for ; Wed, 31 Mar 2004 02:03:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8ZlP-0006pn-00 for opes-archive@ietf.org; Wed, 31 Mar 2004 02:03:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8ZkZ-0006mL-00 for opes-archive@ietf.org; Wed, 31 Mar 2004 02:02:59 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B8Zja-0006gW-00 for opes-archive@ietf.org; Wed, 31 Mar 2004 02:01:58 -0500 Received: from cb253.dormc.nkfust.edu.tw ([163.18.33.86]) by mx2.foretec.com with smtp (Exim 4.24) id 1B8ZjW-0000fF-Qn for opes-archive@ietf.org; Wed, 31 Mar 2004 02:01:55 -0500 Received: from 112.151.36.124 by web292.mail.yahoo.com; Wed, 31 Mar 2004 00:00:51 -0700 Message-ID: From: "Taylor Cook" To: opes-archive@ietf.org Subject: Big payoffs from search engines - no website needed Date: Wed, 31 Mar 2004 12:56:51 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--3686482904790089316" X-CS-IP: 20.174.176.188 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.5 required=5.0 tests=BIZ_TLD,HTML_40_50, HTML_MESSAGE,MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 ----3686482904790089316 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable B64.63.90.43

     

    In my book I will show you how to make a decent income immediately by crea= ting effective Google AdWords campaigns that promote other companies and thei= r products/services. You will be paid each time your ad generates a sale or sign up!

    I don't want any more emails

    ----3686482904790089316-- From owner-ietf-openproxy@mail.imc.org Wed Mar 31 11:48:55 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01473 for ; Wed, 31 Mar 2004 11:48:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8itd-0003GX-00 for opes-archive@ietf.org; Wed, 31 Mar 2004 11:48:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8ish-0003Ep-00 for opes-archive@ietf.org; Wed, 31 Mar 2004 11:47:59 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B8irv-0003DS-00 for opes-archive@ietf.org; Wed, 31 Mar 2004 11:47:11 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VGScCZ010319; Wed, 31 Mar 2004 08:28:38 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2VGSc3f010318; Wed, 31 Mar 2004 08:28:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VGSb3J010312 for ; Wed, 31 Mar 2004 08:28:37 -0800 (PST) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i2VGSeuH001858; Wed, 31 Mar 2004 09:28:40 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i2VGSdFn001857; Wed, 31 Mar 2004 09:28:39 -0700 (MST) (envelope-from rousskov) Date: Wed, 31 Mar 2004 09:28:39 -0700 (MST) From: Alex Rousskov To: Markus Hofmann cc: ietf-openproxy@imc.org, Ted Hardie Subject: Re: Revised ID Needed for draft-ietf-opes-iab-04? In-Reply-To: <4069C69C.5070201@mhof.com> Message-ID: References: <200403260044.i2Q0iZ1P029587@localhost.localdomain> <4069C69C.5070201@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Tue, 30 Mar 2004, Markus Hofmann wrote: > - We need to re-work the notification example given in Section 5.1, > the comment we received is certainly valid and I'd suggest to use > a different example. I suggest the following two examples as a replacement. The above concerns call for making notification optional. The OPES architecture allows for an efficient and meaningful notification protocol to be implemented in certain OPES environments. For example, an OPES callout server attached to a gateway or firewall may scan outgoing traffic for signs of worm or virus activity and notify a local Intrusion Detection System (IDS) of potentially compromised hosts inside the network. Such notifications may use OPES tracing information to pinpoint the infected host (which could be another OPES entity). In this example, notifications are essentially sent back to the content producer (the local network) and use OPES tracing to supply details. Another environment where efficient and meaningful notification using OPES tracing is possible are Content Delivery Networks (CDNs). A CDN node may use multiple content adaptation services to customize generic content supplied by the content producer (a web site). For example, the node may insert advertisements for client-local events or services. The node itself may not understand specifics of the ad insertion algorithm implemented in OPES callout servers. However, it may use OPES trace to notify content producer about the number of certain advertisements inserted (i.e., the number of "impressions" delivered to the customer) or even the number of ad "clicks" the customer made (e.g., if the node hosts content linked from the ads). Note that OPES services may not have enough information to contact the content producer directly in this case. I have already updated the latest draft snapshot at http://www.measurement-factory.com/tmp/opes/ with the above examples (so that folks can review them in contex), but would be happy to incorporate whatever example(s) the group decides on, of course. Thanks, Alex. From owner-ietf-openproxy@mail.imc.org Wed Mar 31 16:48:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14463 for ; Wed, 31 Mar 2004 16:48:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8nZl-00049s-00 for opes-archive@ietf.org; Wed, 31 Mar 2004 16:48:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8nYq-00046P-00 for opes-archive@ietf.org; Wed, 31 Mar 2004 16:47:49 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B8nYa-00044b-00 for opes-archive@ietf.org; Wed, 31 Mar 2004 16:47:32 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VLN79h035330; Wed, 31 Mar 2004 13:23:07 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2VLN7uP035329; Wed, 31 Mar 2004 13:23:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VLN6io035322 for ; Wed, 31 Mar 2004 13:23:06 -0800 (PST) (envelope-from markus@mhof.com) Received: from mhof.com (unknown[135.104.20.84]) by comcast.net (sccrmhc13) with ESMTP id <2004033121230501600j2ibue> (Authid: biena2004); Wed, 31 Mar 2004 21:23:05 +0000 Message-ID: <406B36BD.3060708@mhof.com> Date: Wed, 31 Mar 2004 16:23:09 -0500 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.5+ (Windows/20040312) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: Revised ID Needed for draft-ietf-opes-iab-04? References: <200403260044.i2Q0iZ1P029587@localhost.localdomain> <4069C69C.5070201@mhof.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex, both examples look good to me. Minor comment inline. > The above concerns call for making notification optional. The OPES > architecture allows for an efficient and meaningful notification > protocol to be implemented in certain OPES environments. For > example, an OPES callout server attached to a gateway or firewall may > scan outgoing traffic for signs of worm or virus activity and notify > a local Intrusion Detection System (IDS) of potentially compromised > hosts inside the network. Such notifications may use OPES tracing > information to pinpoint the infected host (which could be another > OPES entity). Although I believe to understand the intent of using the term "host" here, I'm wondering wether it might be easier to understand if we talk about a "server" in this example. I had to read the example twice to understand that the "host" you're talking about is a content source rather than the content consumer. But it might just be me :) > Another environment where efficient and meaningful notification using > OPES tracing is possible are Content Delivery Networks (CDNs). A CDN > node may use multiple content adaptation services to customize > generic content supplied by the content producer (a web site). For > example, the node may insert advertisements for client-local events > or services. The node itself may not understand specifics of the ad > insertion algorithm implemented in OPES callout servers. However, it > may use OPES trace to notify content producer about the number of > certain advertisements inserted (i.e., the number of "impressions" > delivered to the customer) or even the number of ad "clicks" the > customer made (e.g., if the node hosts content linked from the ads). > Note that OPES services may not have enough information to contact > the content producer directly in this case. The last sentecne could be explained a little more (e.g. what information might be missing etc.). Thanks, Markus From owner-ietf-openproxy@mail.imc.org Wed Mar 31 17:28:31 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16969 for ; Wed, 31 Mar 2004 17:28:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8oCH-0006ix-00 for opes-archive@ietf.org; Wed, 31 Mar 2004 17:28:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8oBI-0006fe-00 for opes-archive@ietf.org; Wed, 31 Mar 2004 17:27:33 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B8oAM-0006bp-00 for opes-archive@ietf.org; Wed, 31 Mar 2004 17:26:34 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VMACYx038583; Wed, 31 Mar 2004 14:10:12 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i2VMACQa038582; Wed, 31 Mar 2004 14:10:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from measurement-factory.com (measurement-factory.com [206.168.0.5]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i2VMAAcW038576 for ; Wed, 31 Mar 2004 14:10:11 -0800 (PST) (envelope-from rousskov@measurement-factory.com) Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id i2VMAEuH016420; Wed, 31 Mar 2004 15:10:15 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id i2VMAEjI016419; Wed, 31 Mar 2004 15:10:14 -0700 (MST) (envelope-from rousskov) Date: Wed, 31 Mar 2004 15:10:14 -0700 (MST) From: Alex Rousskov To: Markus Hofmann cc: ietf-openproxy@imc.org Subject: Re: Revised ID Needed for draft-ietf-opes-iab-04? In-Reply-To: <406B36BD.3060708@mhof.com> Message-ID: References: <200403260044.i2Q0iZ1P029587@localhost.localdomain> <4069C69C.5070201@mhof.com> <406B36BD.3060708@mhof.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, 31 Mar 2004, Markus Hofmann wrote: > > an OPES callout server attached to a gateway or firewall may > > scan outgoing traffic for signs of worm or virus activity and notify > > a local Intrusion Detection System (IDS) of potentially compromised > > hosts inside the network. Such notifications may use OPES tracing > > information to pinpoint the infected host (which could be another > > OPES entity). > > Although I believe to understand the intent of using the term "host" > here, I'm wondering wether it might be easier to understand if we talk > about a "server" in this example. I had to read the example twice to > understand that the "host" you're talking about is a content source > rather than the content consumer. But it might just be me :) Hmm... I meant the host inside a network. It could be a user PC, a web server, or some other kind of a server/agent. In case of a user PC, the PC is the content producer where content is whatever that infected PC is sending outside of the network (malformed GET requests, port probes, etc.). In case of a web server, the server is the content producer where content is a web page with scripting bugs or other bad things inside. In either case, the host is infected and is the content producer. Is that how you interpreted it? The "host" to "server" change would eliminate an important case of an infected client PC. Any other suggestions on how to polish the above? > > Note that OPES services may not have enough information to contact > > the content producer directly in this case. > > The last sentecne could be explained a little more (e.g. what > information might be missing etc.). Will do. Alex. From owner-ietf-openproxy@mail.imc.org Wed Mar 31 22:47:48 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00166 for ; Wed, 31 Mar 2004 22:47:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8tBF-00032s-00 for opes-archive@ietf.org; Wed, 31 Mar 2004 22:47:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8tAF-0002zr-00 for opes-archive@ietf.org; Wed, 31 Mar 2004 22:46:48 -0500 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1B8t9U-0002xg-00 for opes-archive@ietf.org; Wed, 31 Mar 2004 22:46:00 -0500 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i313OnlH058411; Wed, 31 Mar 2004 19:24:49 -0800 (PST) (envelope-from owner-ietf-openproxy@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i313OnTi058410; Wed, 31 Mar 2004 19:24:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openproxy@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i313OlWD058365 for ; Wed, 31 Mar 2004 19:24:48 -0800 (PST) (envelope-from markus@mhof.com) Received: from mhof.com (unknown[135.104.20.86]) by comcast.net (sccrmhc11) with ESMTP id <2004040103244901100dv029e> (Authid: biena2004); Thu, 1 Apr 2004 03:24:49 +0000 Message-ID: <406B8B85.7010009@mhof.com> Date: Wed, 31 Mar 2004 22:24:53 -0500 From: Markus Hofmann User-Agent: Mozilla Thunderbird 0.5+ (Windows/20040326) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Re: Revised ID Needed for draft-ietf-opes-iab-04? References: <200403260044.i2Q0iZ1P029587@localhost.localdomain> <4069C69C.5070201@mhof.com> <406B36BD.3060708@mhof.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Alex Rousskov wrote: > On Wed, 31 Mar 2004, Markus Hofmann wrote: > > >>> an OPES callout server attached to a gateway or firewall may >>> scan outgoing traffic for signs of worm or virus activity and notify >>> a local Intrusion Detection System (IDS) of potentially compromised >>> hosts inside the network. Such notifications may use OPES tracing >>> information to pinpoint the infected host (which could be another >>> OPES entity). >> >>Although I believe to understand the intent of using the term "host" >>here, I'm wondering wether it might be easier to understand if we talk >>about a "server" in this example. I had to read the example twice to >>understand that the "host" you're talking about is a content source >>rather than the content consumer. But it might just be me :) > > > Hmm... I meant the host inside a network. It could be a user PC, a web > server, or some other kind of a server/agent. In case of a user PC, > the PC is the content producer where content is whatever that infected > PC is sending outside of the network (malformed GET requests, port > probes, etc.). In case of a web server, the server is the content > producer where content is a web page with scripting bugs or other bad > things inside. In either case, the host is infected and is the content > producer. > > Is that how you interpreted it? The "host" to "server" change would > eliminate an important case of an infected client PC. Any other > suggestions on how to polish the above? Yup, that's the way I interpreted it. And, yes, the "host" to "server" change would eliminate the case of an infected client PC. However, since this is just an example for illustration, I felt that simplicity is more important than completness. But that's minor suggestion, I don't have a problem with the current phrasing. -Markus

    GET YOUR UNIVERSITY DIPLOMA

    Do yo= u want a prosperou= s future, increased earning power
    more money and the respect of all?

    Ca<= !b>ll this number: 

    1-720-834-2989

    (24 hours)

     

  • There are no required tests, classes, books, or= interviews!
     
  • Get a Bachelors, Ma<= !d>sters, MBA, and Doctorate (PhD) diploma!
     
  • Receive the benefits and admiration that comes= with a diploma!
     
  • No one is turned= down!

     

    Call Today

    =

    1-720-834-2989

     (7 days a week)=

    Confidentiality a<= !r>ssured!
     

    W= e are located in USA  international= callers are very welcome