ietf-openproxy
[Top] [All Lists]

RE: Draft Agenda for IETF 56

2003-03-12 11:50:04

As per architecture:

"The OPES architecture requires that tracing be feasible
   on the OPES flow per OPES processor using in-band annotation. "

This requirements is essential, it provides participants with the 
ability to detect OPES in the course of normal interaction. It is 
necessary to satisfy IAB. Without in-band tracing one should undertake 
special query to find out if there was something done to the data. 
This may be not feasible - how do you know where to look without 
tracing info? 

Out-of-band component may be used to get more detailed info, but as 
in-band tracing is a must it has to be protocol-specific. For the 
tracing purposes callout server role is not that important, the 
essential thing is if there are changes made. OPES architecture 
provides for OPES service implementation on the OPES computer, 
and placement the application functionality on one computer or 
another are details that should be isolated from the other 
OPES-flow participants. If my application (end-user or content 
provider application) somehow interacts with OPES it should not 
depend on such details. 

For that matter I'd suggest that callout processor should 
not be able to communicate with OPES participant directly, 
only through OPES server. This 
will provide the required level of isolation. OPES processor 
may use callout protocol to communicate certain requests to callout 
processor and send responses back to the user/server. If user 
requests are coming in-band OPES communication with callout 
processor provides better reliability and simplifies synchronization, 
but this may depend on actual tracing specification.
 
Oskar  


-----Original Message-----
From: owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Alex 
Rousskov
Sent: Wednesday, March 12, 2003 12:33 PM
To: OPES Group
Subject: Re: Draft Agenda for IETF 56



On Wed, 12 Mar 2003, Markus Hofmann wrote:

Just a reminder - although we've a SHOULD requirement that states
that our solutions should be protocol agnostic (and I think we all
agree on that), our charter is focused on HTTP (and RTP, although we
agreed the main focus being on HTTP).

What it means to me is that:
      - we MUST support HTTP as an application protocol
      - we SHOULD support more than just HTTP
      - in case of a specific design conflict, HTTP-arguments MAY
        have higher priority than arguments for other application
        protocols

The above is different from
      - we MUST support HTTP as an application protocol
      - we MUST NOT consider other application protocols
        until HTTP is supported
      - we SHOULD check other application protocols
        after HTTP is supported

I'd suggest we go down a similar path as we currently do with the
callout protocol, namely discussing required functionality and
general design issues, first (rather than starting to discuss how
and in which specific form to do it). I.e. what exactly do we need
to signal (one example is the "OPES bypass"), what are the
interaction schemes, what needs to be signaled, etc. Then we can
discuss what's the best way to do this (e.g. "in-band" vs.
"out-of-band") etc.

I, obviously, agree.

[Note: Just to avoid confustion - this is *not* about the callout
protocol, this is about the application protocl path).

There is some interaction between the two though. For example, we need
to decide whether the callout server or OPES dispatcher/processor is
responsible for tracing (could be both too!). If callout server is
responsible, then the callout protocol may have to provide appropriate
support, especially if we decide to use out-of-bound (#2) approach.

Hmm... The latter actually demonstrates another weakness of the
out-of-bound approach: it makes it difficult for callout servers to
participate in tracing and similar activities because the "end" is not
talking to them but to the proxy. On the other hand, maybe this is a
sign that callout servers must not participate?

Alex.



<Prev in Thread] Current Thread [Next in Thread>