Subject: RE: [end points comm] OPES System

From: "Abbie Barbir" <[email-masked]>
Date: Wed, 13 Aug 2003 17:18:50 -0400

Alex,

Fully agree with you.

Airline example is the example that we should use. I think we should define
the OPES system in that fashion where there is only one accountable system .

Abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]] 
> Sent: Wednesday, August 13, 2003 4:45 PM
> To: OPES Group
> Subject: Re: [end points comm] OPES System
> 
> 
> 
> 
> On Wed, 13 Aug 2003, Markus Hofmann wrote:
> 
> > Alex Rousskov wrote:
> >
> > > Here is where I would start:
> > >
> > > 	OPES system: OPES system is a set of OPES entities
> > > 	defined for a given application message. The formation of an
> > > 	OPES system is recursive: OPES system starts with either data
> > > 	provider or data consumer (for the given message); OPES system
> > > 	then includes any OPES entity trusted by (accepting authority
> > > 	from) an entity already in the OPES system. The trust and
> > > 	authority delegation is viewed in the context of the given
> > > 	application message. As implied by the above definition, some
> > > 	OPES entities in the system may not participate in the
> > > 	processing of a given message.
> >
> > Hm... Assume a carrier A trusting carrier B. According to above 
> > definition, they both form an OPES system/domain. As such, they're 
> > identified by a single OPES trace entry. To whom would an end user 
> > turn if there're any problems?
> 
> To the [single] entity identified in the trace.
> 
> Now suppose there are two or more trace entries. To whom 
> would an end user turn if there're any problems?
> 
> 
> A real-world illustration of the same problem is baggage 
> handling by airlines. When your checked-in baggage does not 
> arrive with you at the final destination, you are supposed to 
> complain to a single carrier only (the last airline, in this 
> case). It is the responsibility of that carrier to follow the 
> global airline system/domain rules to find your baggage and 
> deliver it to you. Naturally, you would not normally know 
> exactly where your baggage have been, who lost it, and how it 
> was found.
> 
> OPES system implementations can adopt the same last-entity 
> model if they find it useful, but they do not have to. They 
> may choose to outsource OPES troubleshooting instead (for example).
> 
> Alex.
> 
>

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Wed, 13 Aug 2003 16:40:35 -0600

I think this discussion has become far too embroiled in business
practices and far too remote from protocols.  And I'd like to note that
today it is all too common to have airline baggage problems and be told
that your problems are due to TSA and there is NO way to either trace or
complain about lost items.

An OPES processor MUST support tracing.  You can set policy on who has
authorization to turn on tracing or to see the results, you can set
policy on granularity.  But until this group has defined the tracing
mechanism and told OPES implementors that the facility MUST be
present, the rest of it is irrelevant.

Hilarie

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 13 Aug 2003 17:28:57 -0600 (MDT)

On Wed, 13 Aug 2003, The Purple Streak, Hilarie Orman wrote:

> An OPES processor MUST support tracing.  You can set policy on who
> has authorization to turn on tracing or to see the results, you can
> set policy on granularity.

If a given OPES processor implementation is always used deep inside an
OPES system, the above MUST would be an overkill. Moreover, violating
that MUST may not affect interoperability if sufficient tracing is
provided by other entities in the system. I agree that a
general-purpose processor must support tracing (because it may be used
in isolation), but it is wrong to require that from any OPES
processor. Only OPES systems MUST be traceable.

> But until this group has defined the tracing mechanism and told OPES
> implementors that the facility MUST be present, the rest of it is
> irrelevant.

The purpose of this thread is to identify what MUST be traceable. Some
(including myself) insist that only OPES system MUST be traceable
while smaller OPES entities SHOULD or MAY be traceable. Such approach
implies, of course, that a stand-alone, isolated OPES processor MUST
be traceable (because it represents an OPES system).

If you accept that point of view, we can move on to specific tracing
mechanisms (what should be included in the trace and how that
information should be encoded). Your comments regarding optional
tracing and tracing granularity make me thing that our positions are
not that different.

Alex.

P.S.

> And I'd like to note that today it is all too common to have airline
> baggage problems and be told that your problems are due to TSA and
> there is NO way to either trace or complain about lost items.

The above is a self-contradictory statement. If somebody is telling
you that your baggage problems are "due to TSA", then you found
somebody to complain about lost items to! Whether your complaint is
going to be effective is not relevant in the context of this thread.
The mechanism we discuss is not going to eliminate problems; It is
going to identify the responsible party (or partIES, in your version).

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Wed, 13 Aug 2003 18:08:48 -0600

My point about TSA is that there is no way to determine if items were
lost by TSA or the airline.  All you can do is to talk to the airline
and be told "we didn't lose it, it must be TSA".  That's not a
"trace", and TSA will say the airline is at fault.  We don't want a
protocol system with this kind of information loss.

Hilarie

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 14 Aug 2003 08:51:39 -0600 (MDT)

On Wed, 13 Aug 2003, The Purple Streak, Hilarie Orman wrote:

> lost by TSA or the airline.

My point is that you should not care who lost the items. The only
thing you should care about is who you should complain to (and,
eventually, who will compensate you for your losses). If my bags are
lost, I got to the last airline on my itinerary. I do not care who
lost the bags. If the last airline cannot recover them on the spot, I
can file a formal claim with them and take them to small claims court
if needed.  Then it will be the airline responsibility to recover
their cost from TSA/government/whatever. This is how the system is
supposed to work according to, IIRC, Warshaw Convention (and usually
does).

> All you can do is to talk to the airline and be told "we didn't lose
> it, it must be TSA".  That's not a "trace", and TSA will say the
> airline is at fault.  We don't want a protocol system with this kind
> of information loss.

It is not information loss. It is information/responsibility
encapsulation.

You do not need to know more than "who is responsible". The
responsible party does not want you to know more than that they are
responsible (but the trace may embed more opaque-to-you information to
help them troubleshoot, of course; just like your bags have barcodes
that you cannot understand but that are useful to the airline).

Alex.

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Thu, 14 Aug 2003 10:59:29 -0600

Airlines have no responsibility or ability to recover passenger items from
government inspectors.  Don't repeat this mistake in designing protocols.

OPES processors MUST support tracing.

Hilarie

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 14 Aug 2003 11:27:47 -0600 (MDT)

On Thu, 14 Aug 2003, The Purple Streak, Hilarie Orman wrote:

> Airlines have no responsibility or ability to recover passenger
> items from government inspectors.  Don't repeat this mistake in
> designing protocols.

I do not think we are repeating any mistakes yet. Government
inspectors are, apparently, outside of the airline equivalent of the
OPES system and, hence, are not in the scope of this discussion.
According to your comments, they are similar to a "transparent" proxy
adapting traffic without either end authorization; we do not consider
such entities because we cannot regulate them. We only consider
entities that want to be called OPES entities and want to obey OPES
rules.

> OPES processors MUST support tracing.

We are not discussing what OPES processors must support. We are
discussing what OPES entities MUST be represented in any OPES trace.
IMO, only OPES systems MUST be represented.

Alex.

---

From: jfcm <[email-masked]>
Date: Thu, 14 Aug 2003 18:28:39 +0200

Alex,
Hilarie point was correct and I think your response is final.

At 16:51 14/08/03, Alex Rousskov wrote:
>eventually, who will compensate you for your losses).

True as a passenger. But the Airline needs to know it (and probably to be 
able to document it a lot?). So the trace MUST tell it.

>It is not information loss. It is information/responsibility encapsulation.

This is the exact need we have: opaque information.

I was told that when French Customs and Gendarmerie were asked to use 
TCP/IP to deversify from OSI they encapsulated the OSI packets into TCP/IP 
datagram and added crypted tracing data. This means that Hackers packets 
come with information about the hacker. May be someone knows better about 
their architecture? I think the idea interesting.

jfc

---

From: jfcm <[email-masked]>
Date: Fri, 15 Aug 2003 00:56:10 +0200

>entities that want to be called OPES entities and want to obey OPES

This is a nice description of a hacker. Trace must help tro know who has 
been hacked.

>IMO, only OPES systems MUST be represented.

Please! Why are saying that again?
As per (y)our previous definition there is only one system in use (even if 
user may call on different system. "only OPES domains MUST be presented".
jfc

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 14 Aug 2003 17:43:32 -0600 (MDT)

On Fri, 15 Aug 2003, jfcm wrote:

> >discussing what OPES entities MUST be represented in any OPES
> >trace. IMO, only OPES systems MUST be represented.
>

The purpose of the trace is not to count OPES systems (there can be no
more than one on the other end), but to identify the OPES system (if
any).

As for OPES domains, it is not yet clear for me what they are in your
definition. Nevertheless, I believe that the other end MUST receive at
least one trace entry. If domains (whatever they are) within an OPES
system decide to disclose their identity, that's up to them.

Alex.

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Thu, 14 Aug 2003 17:30:48 -0600

This is truly a barrel of red herring.  Separate mechanism from policy.

The discussion is the policy that an organization can set regarding
trace information.  The proposal is that processor ids can be
considered privileged information and deleted from the trace.  Fine,
then the organization must have a way to respond to queries about its
tracing policies and to respond "processor ID's are not available".
That doesn't mean that the policy is recommended, it doesn't have to
appear in any RFC.  An organization can have any policy its wants for
trace information, but it MUST support tracing mechanisms and it MUST
reveal its policy.

Hilarie

---

From: jfcm <[email-masked]>
Date: Fri, 15 Aug 2003 02:26:38 +0200

>more than one on the other end), but to identify the OPES system (if

OK. If you name that a Trace (I would name that a signature) good to me.

>system decide to disclose their identity, that's up to them.

I name an OPES domain the area of reponsibility of an operator.
That information MUST be traced (even if totally or partially opaque).

1. to be informed of/if (which) different "boarders" have been crossed.

2. to be informed of the possible loops or creeps.
     If I expect 2 domain booarders to be crossed and I am reported
    10, I  know that an unexpected recursion happened.

3. To prevent some operators domain to be accessed is a need.
     The report of the domain being crossed is therefore a need.

4. The reporting can be opque to permut concerned domains
     to get the store the private info they need in case of trouble
     shouting.

jfc

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 18 Aug 2003 11:41:16 -0600 (MDT)

> I name an OPES domain the area of reponsibility of an operator.

What's an operator or operator responsibility? When Disney-owned
content is created on and made available via Akamai servers, is Disney
an operator? Is Akamai? Is Disney+Akamai?

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Mon, 18 Aug 2003 16:24:33 -0400

Hi,

rather than responding to individual emails, let me try to summarize 
the thread (while catching-up with queued emails...).

Goal: Tracing must allow the endpoints to detect that some OPES 
services were involved, and which party to contact in order to resolve 
possible problems. This has resulted in different views:

(a) One view is that this requires each individual OPES processor to 
support tracing. Policies can be used to authorize who can turn on 
tracing and who can see the results.

(b) Another view is that this requires only one trace per "OPES 
system", with an "OPES system" being the collection of entities that 
are trusted by the respective endpoint. This assumes that certain 
business arrangements/rules are in place, which will ensure that 
problems can be traced across carrier domains.

(c) One view might be that this requires only tracing per "OPES 
domain", with an "OPES domain" being the collection of entities 
operated by a single carrier.

Both, (b) and (c), assume that the carriers somehow have enough 
(internal) information to answer possible inquiries, e.g. they 
themselves must figure out which exact OPES processors have been 
involved when a specific user inquiry comes in.

For each of the views, it would be helpful to detail and to illustrate 
the entire tracing process showing an example scenario, including how 
a user would inquire about suspected problems and how this inquiry 
would be resolved. [It might also be helpful to learn from existing 
solutions to similar problems in other protocol areas, e.g. email etc.]

Since (b) seems to be the most "relaxed" view, let's start with this 
approach, and then see whether/how it solves real-life problems, 
whether the assumptions are valid, how it addresses the IAB 
considerations, and how differences to IAB consideration will be 
explained.

-Markus

---

From: jfcm <[email-masked]>
Date: Mon, 18 Aug 2003 23:23:57 +0200

>an operator? Is Akamai? Is Disney+Akamai?

This is where you are confusing the issues by pleasure.
The responsible operator is the one saying he is responsible.
Stick to your airline image and do not make too many layer violation.

NO processor should be without domain operator.  And no processor can be 
with two separate domain owner. Otherwise I will/people will _NEVER_ 
trust.use an OPES.

This means that every processor MUST be something and that something is to 
be decided by its operator. And as a SYSTEM user I must be able to 
say/decide if I trust or not an operator for who he is or for the 
information he discloses or for the cost of his services.

You just do not pick any cab (system) because they are cabs. And every cab 
has a number makingtem part of a domain/company. They can fake them, they 
can hide them. It is up to you to decide if you trust or not a hiden number 
cab, for example because you like the name of the cab company or because 
you want to commit suicide.

jfc

>Alex.
>
>
>
>
>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.507 / Virus Database: 304 - Release Date: 04/08/03

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 18 Aug 2003 15:41:08 -0600 (MDT)

On Mon, 18 Aug 2003, jfcm wrote:

> This means that every processor MUST be something and that something
> is to be decided by its operator. And as a SYSTEM user I must be
> able to say/decide if I trust or not an operator for who he is or
> for the information he discloses or for the cost of his services.

That's fine, but you need a better definition of a domain and/or
operator. The original "OPES domain is the area of reponsibility of an
operator" does not imply the above explanation.

Also, since you leave domain boundaries for the operator to decide,
you need to explain how conflicts (two operators think they are
responsible for the same domain and instruct their processors to
update the trace accordingly) and misses (no operator claims
responsibility for a domain/processor).

Alex.

---

From: jfcm <[email-masked]>
Date: Tue, 19 Aug 2003 01:08:29 +0200

>responsibility for a domain/processor).

I must go. But I think better anyway to proceed with a general
response and see what you objet as I do not understand your
question. So I suppose there is confusion to clarify.

Let stick to the Airline image. And let take the following analogy
(different of the one I took with Markus, but as good and clearer here).

A   jet        = processor
An airline   = domain - area of responsibility of the ariline operator.
An alliance (or a tour or a travel I organize, etc.) = a system

Are all your questions answered or not?
If not where are you difficulties coming from?
The analogy or  from not addressed conflicts?

jfc

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 19 Aug 2003 08:43:40 -0600 (MDT)

On Tue, 19 Aug 2003, jfcm wrote:

> >operator. The original "OPES domain is the area of reponsibility of
> >an operator" does not imply the above explanation.
> >

I can use the airline analogy to illustrate what is missing in your
definitions, though it may not be a perfect example:

Lack of responsibility:

	Your tour group arrives at the destination
	with their bags lost. They call you (the
	"system" contact point) to complain. You tell
	them that the bags are not your responsibility
	and they should check with the last jet airline.
	They go to the last airline, Northwest Airlines.
	Northwest tells them that the last leg on their
	itinerary was operated by KLM and they have to
	complain to KLM. KLM says that based on their
	agreement with Northwest, Northwest is responsible
	for the lost baggage.

	Thus, your group has contacted three suspects and all refused
	to take responsibility. Since your definitions rely
	on somebody to accept/define responsibility, it is not clear
	who is at fault here.

Double responsibility:

	Upon arrival, your tour group discovers that they
	were awarded twice the miles they should have been
	because both KLM and Northwest airlines took the
	responsibility to award miles for the trip. Each
	individual airline claims it had the right to do
	that since they can define the area of responsibility any way
	they want.

HTH,

Alex.

---

From: jfcm <[email-masked]>
Date: Tue, 19 Aug 2003 21:44:34 +0200

>definitions, though it may not be a perfect example:

Usually a good one. Let take it as long as it does not fail us.

>Lack of responsibility:

here you confuse system and domain operator.

1. as a user you go and see the system. Since you chose the image of a tour 
operator, the ystem for the user is the group operator. Period.

2. as a tour operator. i.e. a system. Your problem is to find back the 
luggage. And believe me, from experience as an operator _every relevant 
infromation_ to do that is necessary.

>         and they should check with the last jet airline.

Then they sue you and win.

>         They go to the last airline, Northwest Airlines.

Nroth West will not speak to them. They do not even know them as 
passengers. They only know you as a tour, etc....

>         on somebody to accept/define responsibility, it is not clear

I nover said that. I said that it is to people to accept to be a domain 
operator for a CPU/jet.
That is to have the responibility of a domain. I selfom saw a jet takingof 
without pilot.

>         responsibility to award miles for the trip.

Who will complain :-)

>         Each

You probably missed one point again in confusing reponsibility and domain 
of responsibility (strange that such an obvious notion to any operational 
person can be a problem to you.). No CPU - jet - can have two owners or no 
owner. Fact of the life. You may tell your neighbor that his wife is yours, 
but usually law prevents this not to be a bug.
jfc

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 20 Aug 2003 09:48:56 -0600 (MDT)

On Tue, 19 Aug 2003, jfcm wrote:

> You probably missed one point again in confusing reponsibility and
> domain of responsibility (strange that such an obvious notion to any
> operational person can be a problem to you.). No CPU - jet - can
> have two owners or no owner. Fact of the life. You may tell your
> neighbor that his wife is yours, but usually law prevents this not
> to be a bug. jfc

Things that are clear to most people in the real world become very
fuzzy in the virtual reality that we are building and documenting
here. Not to mention that I disagree with your assumption that
ownership and domain of responsibility are always clear in real world.

The "take them to court and win the case" answer is not satisfactory
to me. I want the specs to be clear how the responsibility is
assigned, traced, and managed.

Alex.

---

From: jfcm <[email-masked]>
Date: Wed, 20 Aug 2003 21:38:42 +0200

At 17:48 20/08/03, Alex Rousskov wrote:
>Things that are clear to most people in the real world become very fuzzy 
>in the virtual reality that we are building and documenting here. Not to 
>mention that I disagree with your assumption that

Sorry, these are comments. Not real logical facts.

We have a hierarchical identification:
- top is system
- below is domain
- below is server
- below is service
- below or aside is the traveler

You may certainly imagine identification plan/protocol violations. But 
please come document them.
In the model we chose (airtransport) as seen from the users (not from a 
single user _and_ from a tour operator):

- the system (alliance, tour, travel) is identfied by the Warsaw 
conventions and the issuer of the ticket
- the domain (airline) is idenfied by its international code
- the server (plane) is international identified by its indicative and IFF 
or eventually destroyed (what you expect from an hacker)
- the stewart, the offered bottle, the milleage plan, the luggages, the 
passengers, are idenified and traced in many ways, sometimes there are 
confusions but that works usually well because protocols are pretty clear.

OK I accept that when we started I asked if OPES were ONES or not and I 
gave air reservation and  SITA attached systems as a ONES example. Or Swift 
related systems.

So I am ready to accept that OPES do not qualify to support that type of 
need, if you say so. But I do not see why.
jfc

>assigned, traced, and managed.

This was not a response to a technical problem. Only a comment on the way 
the question was meaningless because you confused two layers.

You cannot demand a protocol to respond a question it is not to be asked.

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 20 Aug 2003 14:00:51 -0600 (MDT)

> conventions and the issuer of the ticket

Exactly. What we need is an equivalent of Warsaw Convention. That is
what is missing in your definition. "Accepting/taking the
responsibility" is not sufficient. There has to be some rules about it
(to avoid duplication or lack of responsibility).

Alex.

---

From: jfcm <[email-masked]>
Date: Wed, 20 Aug 2003 23:02:07 +0200

>(to avoid duplication or lack of responsibility).

Alex please consider what I/we said.

The system is by essence what the user, the provider or a third party as 
decided as a global service. This is what in the Airline analogy we call 
the travel (user), the alliance (Air France with Delta, with NorthWest, etc 
against BA alliance etc.)

The domain is the airline. It is made by a company accepting/taking 
responsbility to buy airplanes, to hire pilots, etc. No one else will setup 
any rule on the free decision of the investors, entrepreneurs, etc. Like it 
or not. And no other rule than the decision of the customers will say if 
they want or not to fly American Airways. I do not understand your problem.

There cannot be lack of responsibilty - unless you the OCP designer wants 
it, but the TSA will not permit it. This means that you want to accept 
unknown planes, without pilots.

As indicated there is a clear indentifcation hierarchy system, domain, 
server/service which permits everyone to determine classes of users and 
permitted access groups of domains (my first mails on this list) so one can 
deal with prefered, accepted, obliged services, security, laws, commercial 
policies, real life operations. etc.

I really am at pain understanding your problem. And at understanding hos 
you cannot understand operators and users needs.

Or please give examples. Or am I dumb stupid ?

jfc