Subject: RE: Draft Agenda for IETF 56

From: "Reinaldo Penno" <[email-masked]>
Date: Wed, 12 Mar 2003 07:18:56 -0800

Hello Abbie,

I guess there are two approaches here:

1) Making extensions for every single application protocol that might use
OPES.
  ...Although some people that in realitly we will have maybe 4 (HTTP, RTP,
SMTP, FTP).

2) Developing an out of band protocol to signal such preferences. That's why
I said in the past looking at NSIS could be interesting if we feel the list
in 1) is already big/complicated enough or might grow.

There is also the practical uses of either approaches. Certainly,
negotiating with the OPES processor what will/not receive treatment every
single HTTP session could add a lot of overhead. Although HTTP could be used
to negotiate, I guess we should have provisions to say "bypass OPES for all
HTTP sessions, until I say otherwise", or vice-versa.

Regards,

Reinaldo

-----Original Message-----
From: Barbir, Abbie [CAR:1A00:EXCH] 
Sent: Wednesday, March 12, 2003 9:06 AM
To: Markus Hofmann; OPES Group
Subject: RE: Draft Agenda for IETF 56

Markus, 
it all do with HTTP extension etc. 
I will detail later, 
abbie 

> -----Original Message----- 
> From: Markus Hofmann [mailto:[email-masked]] 
> Sent: Wednesday, March 12, 2003 8:28 AM 
> To: OPES Group 
> Subject: Re: Draft Agenda for IETF 56 
> 
> 
> 
> Abbie Barbir wrote: 
> 
> > At this point, the issues of notification/tracing have not been 
> > brought up (yet?). 
> 
> Absolutley correct and an important point!! Is there anything me must 
> consider in the callout protocl design for tracing and 
> notification? I 
> would assume so... Any thoughts? 
> 
> While probably separate from the callout protocol design, we 
> also need 
> to discuss possible impact on the application message protocol, for 
> example for an "OPES bypass" mechanism. This refers to the 
> requirement 
> that a user must be able to signal an OPES processor that (s)he wants 
> to bypass any OPES service (one of the IAB requirements)  - 
> as briefly 
> discussed some time earlier, using (user-defined?) HTTP headers might 
> be an option.... So we also need to consider possible 
> impact/extensions on the application message protocol. Anyone some 
> thoughts on this one? 
> 
> -Markus 
> 
> 
>

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 12 Mar 2003 11:32:51 -0500

>   ...Although some people that in realitly we will have maybe 4 (HTTP, RTP,

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).

> HTTP sessions, until I say otherwise", or vice-versa.

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. [Note: Just to avoid 
confustion - this is *not* about the callout protocol, this is about 
the application protocl path).

Maybe Abbie and Reinaldo you want to take a first shot, since you seem 
to look at this from slightly different perspectives. Of course, 
anyone else should feel free to take a first step as well...

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 12 Mar 2003 10:11:43 -0700 (MST)

I would like to suggest that we need general framework(s) for tracing
and user preferences processing before we go into designing specific
protocols, especially if we want to add extensions to [many] existing
protocols. We must document what needs to be passed around and what
the reaction on that information should be. Given such a framework,
implementation in any specific protocol (new or old) would be a
mundane task:

	- what is addressable?
	- what is traceable?
	- can tracing info be aggregated/modified?
	- do we need information authentication?
	- can end-point affect the extent of tracing?
	- what is the default behavior?
	- etc.

All of the above has little dependency on the application protocols
and, IMO, should be decided/documented first. The existings drafts do
not cover these decisions well enough.

Specific remarks are below.

On Wed, 12 Mar 2003, Reinaldo Penno wrote:

> 1) Making extensions for every single application protocol that
> might use OPES. ...Although some people that in realitly we will
> have maybe 4 (HTTP, RTP, SMTP, FTP).

That seems like the right way to proceed given that many protocols use
similar extension mechanism (e.g. MIME or XML). One does not need to
start from scratch for every new application protocol, just for every
new extension scheme.

> 2) Developing an out of band protocol to signal such preferences.
> That's why I said in the past looking at NSIS could be interesting
> if we feel the list in 1) is already big/complicated enough or might
> grow.

Synchronization issues with out-of-band and application protocol may
prohibit you from supporting (2) efficiently. Also, it is usually
easier in practice to add support for an extension than for a new
protocol.

> negotiating with the OPES processor what will/not receive treatment
> every single HTTP session could add a lot of overhead. Although HTTP
> could be used to negotiate, I guess we should have provisions to say
> "bypass OPES for all HTTP sessions, until I say otherwise", or
> vice-versa.

This is debatable and probably protocol-specific. For example, it is
usually _more_ overhead to supply state in HTTP because HTTP is
stateless and can be proxied. Parsing a couple of simple extension
headers with every transaction is much simpler and robust approach
with HTTP, without noticeable performance penalties.

Are there any application protocols that natively support "state
management" on the intermediaries, across isolated transactions?

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 12 Mar 2003 10:32:42 -0700 (MST)

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

> 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.

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 12 Mar 2003 13:12:02 -0500

> 	  have higher priority than arguments for other application

Concur! We start designing an application-agnostic approach, and only 
if there's a conflict or if it would become far too complex, we would 
limit the approach to a specific application protocol(s) and would put 
highest priority on HTTP. But for now, I'd say we're good for moving 
forward with a protocol-agnostic design approach.

> support, especially if we decide to use out-of-bound (#2) approach.

If you talk about tracing, I completely agree thatthere's interaction 
(and I tend to say both OPES precesor and callout server need to be 
involved).

But for a general OPES bypass, I don't see that interaction between 
the application protocol and the OPES callout protocol would be 
required. If the user signals "no OPES, please", the callout protocol 
is not involved at all.

> sign that callout servers must not participate?

Hm... I tend to believe the callout servers must participate in 
tracing, since the user doesn't really know on which specific server a 
requested service will be executed (i.e. we assume late service 
binding for now). If the user now suspects that something goes wrong, 
(s)he better want to know what specific servers have been involved. 
Hm, however, this information is probably readily available on the 
OPES processor and the OPES processor might insert the approriate 
tracing info... Would that be enough?

-Markus

---

From: "Oskar Batuner" <[email-masked]>
Date: Wed, 12 Mar 2003 13:50:34 -0500

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  

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Alex Rousskov
> Sent: Wednesday, March 12, 2003 12:33 PM
> To: OPES Group

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 12 Mar 2003 12:06:23 -0700 (MST)

On Wed, 12 Mar 2003, Markus Hofmann wrote:

> required. If the user signals "no OPES, please", the callout
> protocol is not involved at all.

Please see my opes:filtering/cisco-defaults example with processing
delegation and related changes of the service ID. I am not sure if
that is legal OPES, but it does seem to require callout server
involvement.

> tracing, since the user doesn't really know on which specific server
> a requested service will be executed (i.e. we assume late service
> binding for now). If the user now suspects that something goes
> wrong, (s)he better want to know what specific servers have been
> involved.  Hm, however, this information is probably readily
> available on the OPES processor and the OPES processor might insert
> the approriate tracing info... Would that be enough?

I think the answer depends on how "late" your binding is:  can a
callout server delegate processing to another callout server? If yes,
the original OPES dispatcher/processor does not have enough
information and the callout server should pass that along to the next
OPES "hop".

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 12 Mar 2003 12:18:10 -0700 (MST)

> This may be not feasible - how do you know where to look without

Good catch! It looks like we have an answer as far as tracing is
concerned unless we want to add per-service tracing.

However, we do not have an answer for communicating user preferences
(e.g., bypass). You cannot make the same argument there because if a
user [agent] wants to communicate OPES preferences, it has to support
something new, possibly a new out-of-band protocol.

> 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.

On the other hand, callout servers already communicate with ends, by
modifying application messages (which is their primary purpose)!

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 12 Mar 2003 15:11:42 -0500

> that is legal OPES, but it does seem to require callout server

I was refering to a general "no OPES, please" signal, triggering the 
OPES processor to not do *any* callouts or service invokations at all, 
but letting the application message pass through as it would do in a 
non-OPES environment. In this particular case, I don't see any 
interaction with the OPES callout protocol. Your example is different, 
and I agree with your statement that this would probably require some 
interaction.

> information and the callout server should pass that along to the next

Agreed.

-Markus

---

From: "Oskar Batuner" <[email-masked]>
Date: Wed, 12 Mar 2003 15:37:20 -0500

> Sent: Wednesday, March 12, 2003 2:18 PM
> To: OPES Group

And they send these messages ONLY through the OPES processor. My point 
is that as OPES processor is the principal point of contact between 
OPES flow ends and the OPES application it should be the only 
point exposed to the end user/server. In your previous example 
about preferences end user does not know the OPES application 
composition (what functions are performed at what point), and 
preferences relate to the OPES application as a whole. 

Distribution of OPES application functions between components may 
even change dynamically as adaptation to the load conditions. Let's say 
until your OPES box is underloaded application functions are performed 
there, if load is too high - callout processor is invoked, if load is 
too high for callout processor a new one is added - either by the OPES 
processor or by callout processor. Certain things may break - I've 
already notified OPES server and one callout processor that I don't 
want adult contents, but now load balancer switched me to the new 
callout processor that does not know my preferences!

If you have a single user contact point this may scale pretty well, 
otherwise the user has to be involved in the process in which he/she 
is not interested at all - function distribution between OPES components.
 
As soon as the user is aware of OPES existence and knows the contact 
point (this information MUST be provided in-band) further communications 
may be ether in-band or out-of-band, depending on the particular protocol 
and application.

Oskar

---

From: jfcm <[email-masked]>
Date: Wed, 12 Mar 2003 22:01:55 +0100

Dear Folks,
when I suggest we build a bicycle first, in keeping in mind that we want to 
build a car further on and to reuse parts, I probably mean the same thing 
as Alex except that I wish to start on something real and responding to the 
IAB request for a bicycle. I just did that by my own and I was immediately 
confronted with the need to understand what I was doing, not yet in term of 
protocol, but in term of architecture.

1. to have a clear model and that model to be open
2. to have a clear wording of each component from that model
3. to understand what the protocol(s) relate(s) and how the servers will work

Otherwise we will have a perfect protocol we will try to patch to a model 
and applications.

Don't you think that there are already too many protocols around? To me the 
main interest of the callout protocol is that it is probably to address a 
large number of different needs, so it should be a good candidate to 
replace and simplify some other protocols (plural) rather than to add/copy 
one and to add in complexity by superseding many others.

jfc

At 19:50 12/03/03, Oskar Batuner wrote:

>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03

---

From: jfcm <[email-masked]>
Date: Wed, 12 Mar 2003 23:05:00 +0100

>preferences relate to the OPES application as a whole.

SOS! I am lost (low IQ, old brain).  I am not sure I fully grasp
some of the word, and most of all their different shades.
- OPES processor.
- OPES application.
- OPES flow ends.
- OPES box
- a callout processor.
- one or several servers proposing OPES (services)
- OPES components
Sorry for the questions. I don't need examples to understand
but I need logic and exact words which leads to simplicity,
even to robust rusticity.

At this time I understand
- there is a data flow between a user and a content provider.
- the user and the provider may switch roles,
- they usually want to talk HTTP
- between the user and the provider there is a converter
   made of
   - a filter (dispatcher)
   - transformers (OPES servers).
- there is a protocol from the dispatcher towards the servers,
   however it is not clear to me if the protocol is between
   dispatchers acting as front end for servers or between
   dispatchers and servers.

At some stage I understood that a property of OPES
was that the user did not know they exist and that he
could not relate with them. Now it appears that the HTTP
flow should be transport (how?) an indication of the
OPES presence, that the OPES could be opposed at
the user decision? That the dispatcher could relate with
the user, but not the OPES (service).

Am I reading this correctly in simple layman words?

If this is the case we are not anymore in the OPES field
as it is not an "edge service" but a "both ends" service.
IMHO the very nature of the OPES is to add a service to
one end. The other end may be interoperated as part
of the service, but should not decide of the service itself.

If the other end co-decides, it becomes a cooperator
of the OPES, and many other ends in a relation many
to many may also be cooperating: we enter another
model I call ONES.

>callout processor that does not know my preferences!

All these things are only operation management not architecture?

>point (this information MUST be provided in-band)

How?

>further communications

True. But is that still OPES?
jfc

PS. Please relax: I am out for 3 days :-)

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 12 Mar 2003 15:18:18 -0700 (MST)

On Wed, 12 Mar 2003, Oskar Batuner wrote:

> point exposed to the end user/server.

Two problems:

    - It looks like Markus (and others?) want callout servers and
      even services be traceable and, hence, exposed to the ends to a
      certain degree. We will need to get some consensus here.  What
      is exposed to ends? If something is exposed, does it communicate
      with ends? If it does, what "band" is used?

    - If callout servers communicate with ends via application
      protocol (by modifying application messages), then
      "communication through OPES processor" does not mean that the
      OPES processor actually understands what is going on. The OPES
      processor, in this case, may be a dumb relay. I think that
      contradicts your intention to have "required level of
      isolation". Dumb relay is a poor "isolator".

      If we do want to make OPES processor the only point of contact
      and truly remove callout servers from the end-visible picture,
      we need to do the following, at least:

        ~ adjust processor->callout server interface from current
          "do whatever you want with this message, I will just
           forward the result; and please obey OPES rules
	   (e.g., add tracing)"
          to
          "do whatever you want, tell me what
           you did, I may apply more processor-specific modifications
           based on what you did (e.g., add tracing), and I will
           build and forward the final result"

        ~ prohibit delegation of callout services from
          callout servers; support such delegation from OPES processor
          only (the callout server would have to tell OPES processor
          to delegate)

      Is that something you are after? Do you want to limit
      callout server role to message adaptation only and have
      _all_ OPES-related features to be enforced by the OPES
      processor?

> even change dynamically as adaptation to the load conditions.

Yes, of course.

> is not interested at all - function distribution between OPES

The user does not have to be involved in the process if her
preferences remain constant. It is the role of the OPES system to
correctly react to dynamic changes within the OPES system. Are you
implying that the user may have different preferences depending
on the actual OPES system in use?

Thanks,

Alex.

---

From: "Oskar Batuner" <[email-masked]>
Date: Wed, 12 Mar 2003 18:00:30 -0500

Please read this: 

http://www.ietf.org/internet-drafts/draft-ietf-opes-architecture-04.txt

Most of the terms are illustrated in Figure 3: Interaction of OPES Entities, 
(page 8).

Oskar

> [mailto:[email-masked]]On Behalf Of jfcm
> Sent: Wednesday, March 12, 2003 5:05 PM
> To: OPES Group

---

From: "Oskar Batuner" <[email-masked]>
Date: Wed, 12 Mar 2003 23:42:06 -0500

See inside.

> Sent: Wednesday, March 12, 2003 5:18 PM
> To: OPES Group

As far as I understand we have two-layered architecture: one layer is 
present in the OPES flow, another supports all out-of-band functionality 
prescribed by the OPES spec but specifically excluded from the OPES 
flow (like rules distribution). 

For the OPES flow (in-band is just another name for that) the only point 
exposed is OPES server IP (that MUST be exposed by the IAB requirements). 
The only way to communicate at that level is the application protocol 
(original or extended). In the second layer any point may be exposed, 
e.g. privacy policy server. It may even be unreachable to the OPES 
server by callout protocol: OPES entities are not required to use 
the callout protocol as the only method of communication. 

And if something is exposed - it is exposed exactly to enable the ends to 
communicate with it. Method of communication is determined by the role of 
the exposed component and the method of exposure.

Does this make sense?  

>       isolation". Dumb relay is a poor "isolator".

Let me disagree. To some degree a medical office receptionist arranging 
an urgent visit to any available doctor may be a good example: he/she 
acts as a dumb relay (does not attempt to  evaluate patient's medical 
problem details) but still pretty well isolates patient from dealing 
with multiple doctors' schedules and doctors from interruptions from 
all the patients trying to arrange a visit.

Even a dumb relay MUST understand what is going on: it MUST know that 
specific callout server supports all OPES requirements and just passing 
messages through will not result in violation of these requirements. 
 
Depending on the OPES application architecture OPES processor may 
or may not perform certain checks and insert certain information. 
But as a policy enforcement point it is responsible for implementing 
the policy - in cooperation with callout servers. 
 
>            build and forward the final result"

I'm not sure we have well defined notion of what the current interface is. 
Here you are looking at another dimension of the problem: should the 
distribution of functions between OPES processor and callout server 
be completely deterministic (predefined for a particular application) 
or we provide greater flexibility by allowing some level of 
negotiation, as in your second option. 

I think it can be both ways. If function distribution is deterministic 
no additional support is need at the callout protocol level. Each 
component knows what functions it has to perform and what functions 
will be performed by another component. For example some tracing 
information can be added by any of them, component just 
should know in advance that it is his function, while some 
tracing information may be available only at the point where 
the transformation is actually performed.

To implement your second option callout protocol should provide 
some support for negotiations. These additional functions may be 
grouped together and specified as a different level of protocol 
implementation. 

>           only (the callout server would have to tell OPES processor

I don't see the reason for such limitation. OPES processor is not 
interested in callout server architecture - is this one box, farm, 
grid, or hierarchy connected by callout protocol. As long as all 
OPES requirements are met any internal delegation is irrelevant. 
I think when we abandoned special requirements for cascading 
we in fact accepted this "black box" approach.   

>       _all_ OPES-related features to be enforced by the OPES

Again, my approach is that specific distribution of functions may be 
left to the specific application implementation. The only important 
thing is to guarantee that all OPES requirements are met. Is this 
guarantee achieved by deterministic function distribution, what 
specific distribution is used in each particular case or a
reliable negotiation protocol is used to establish such 
distribution dynamically - is irrelevant.

> on the actual OPES system in use?

I imply exactly the opposite - user should have a guarantee that as 
soon as his/her preferences are made known to OPES they will remain 
in force even if system makes dynamic configuration changes. And the 
best way to guarantee this is to provide the user with the single 
communication point. In fact there may multiple communication points, 
but for each function there should be exactly one. If a callout 
processor is exposed as such point no dynamic reconfiguration is 
possible unless this processor is able to distribute information 
communicated by the user to all new system participants. Add to this 
redundancy and (transparent) fallback requirements and you'll see the 
picture behind my reasoning.

Oskar

---

From: Markus Hofmann <[email-masked]>
Date: Thu, 13 Mar 2003 00:15:50 -0500

Alex Rousskov wrote:

>       certain degree. 

Amongst others, this came from IAB considerations 3.1 and 3.2 in 
RFC3238, which require that the ends can detect OPES actions. In 
particular, a user/end must be able to respond to OPES actions that 
"are deemed inappropriate" by herself - as such, all OPES actions need 
to be exposed to the end/user.

>       We will need to get some consensus here.  What
>       is exposed to ends? 

I would assume that all services that have been executed on a message 
are identified and exposed - or that a reference is given at which the 
end-user can query which services have been executed.

 >       If something is exposed, does it communicate

Could be a combination of in-band and out-of band. For example, 
in-band annotations could be used to expose a reference to the end 
user (e.g. a URL), at which the end-user can retrieve additional 
information about the services (and servers?) that have been executed 
on the message using a separate (out-of-band) mechanism.

Might remind of email: Email uses in-band annotations (i.e. the 
Received: headers) to let the user know which mail servers have been 
involved in handling an email. The user can then use out-of-band 
mechanisms to contact the postmaster of any mail server for further 
info...

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 12 Mar 2003 22:31:24 -0700 (MST)

Oskar,

	It looks like we are in agreement here. Perhaps the original
wording that caused this thread was not precise enough, or I
misinterpreted some implications. I agree with your key points, in
their current rendering.

	When we work on OPES documents detailing tracing and bypass,
we need to be especially clear what is exposed to the ends. We know
that OPES processor IP must be exposed and addressable. We also may
want to be able to trace what services have been applied. The latter
would make service IDs exposed, but not directly addressable for the
ends. We need to carefully document these destinctions.

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 12 Mar 2003 22:47:22 -0700 (MST)

On Wed, 12 Mar 2003, Reinaldo wrote:

> 1 - Is there anybody here that thinks the end points should talk to
> the callout server directly? Or know of its existence (apart from
> tracing/events)....I didn't hear anybody expressing this opinion. It
> seems the the consensus is that the end points only talk to the OPES
> processor.

I think the main problem is with things like bypass, not tracing, but
please read on.

>     I still hold that the opes processor do whatever it needs to
> honor a service request. If it use a callout server, does the
> processing itself, use the callout server for Bob, but not for Jane,
> does not matter, as long as you get the proper tracing messages if
> you want to/something goes wrong. It's just a black box from the end
> point perspective.

I sense a terminology conflict here. If something is a black box, it
can be only bypassed as a whole, and there can be only one trace entry
(black box #7) per black box. OPES users may need more granularity, up
to the services level. Markus suggested that services should be
traceable and provides good arguments in support of that requirement.
I noted that once services are traceable (hence known) some users may
want to bypass one service but not another (e.g., filter viruses but
not porn). Overall this makes the black box analogy inappropriate.

What we seem to be dealing with is a "semi-transparent" OPES box. The
ends are able to see/address the OPES processor and are also able to
see (but not address directly) OPES services.

Do you agree that users may have service-specific (not just OPES
box-specific) preferences? Or do we provide tracing without any
OPES-specific way to use the information?

Thanks,

Alex.

---

From: jfcm <[email-masked]>
Date: Thu, 13 Mar 2003 14:19:44 +0100

>Most of the terms are illustrated in Figure 3: Interaction of OPES Entities,

Dear Oskar,
my point is here:

- "most": I would like we could say "all"
- "illustrated" I would like we could say "defined"
- "draft" I would like to say we have a consensus

As long as there is no consensus
- on the building blocks
- on what they are supposed to do
we wind up with interesting but unclear debate. We
had a look now at the whole thing. Time IMO has
come to work, step by step.

jfc

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 13 Mar 2003 09:29:21 -0700 (MST)

On Thu, 13 Mar 2003, Reinaldo wrote:

> it's a black box in regards of the services it provides, not the
> tracing/events. Everytime you access a web page you do not get a
> list of all the routers in your path.

Actually, I do from HTTP point of view! I get a list of all proxies in
the Via: header.

> But you can use a traceroute or maybe get an ICMP type/code back to
> let you know of some error.

That does not count for many reasons. For example, the traceroute
output may have nothing to do with how my HTTP transaction was routed.
This is not only out-of-band, but is also out-of-sync.

But this is just a minor terminology disagreement. This thread has
clarified that we do expect individual services to be traceable and
that we may want ends to be able to bypass them. The latter is not
required for a fully functional OPES system though.

Alex.