Subject: Re: [end points comm] OPES System

From: jfcm <[email-masked]>
Date: Mon, 11 Aug 2003 23:02:54 +0200

What about this? I presuppose we define in here system and domain.

An OPES system is a system organized to permit its users to obtain a single 
or a coordinated set of open puggable edge services. Such a system can be 
statically and/or dynamically organized by its user, the community of its 
users, a host provider or any other third party. An OPES domain is the part 
of an OPES system belonging to a given operator. An OPES domain is not a 
sub-OPES system as it may need external ressources to provide services. 
OPES domains have no incidence  on the structure of an OPES system, but 
they may influence its organization for different reasons such as security, 
payment, quality of service, delivery parameters, etc. particularly in the 
case of  dynamicly prioritized organization and revamping choices.

jfc

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 12 Aug 2003 09:59:29 -0400

jfcm wrote:

> An OPES system is a system organized to permit its users to obtain a 
> single or a coordinated set of open puggable edge services. Such a 
> system can be statically and/or dynamically organized by its user, the 
> community of its users, a host provider or any other third party. An 
> OPES domain is the part of an OPES system belonging to a given operator. 
> An OPES domain is not a sub-OPES system as it may need external 
> ressources to provide services. OPES domains have no incidence  on the 
> structure of an OPES system, but they may influence its organization for 
> different reasons such as security, payment, quality of service, 
> delivery parameters, etc. particularly in the case of  dynamicly 
> prioritized organization and revamping choices.

I basically agree, but I don't see the need to formally define the 
term "OPES system". If we've the notion of an OPES domain as indicated 
above - in which draft and where would we need the term "OPES system"?

Let's simply say that "An OPES domain describes all OPES entities 
operated by a single provider". I would assume that's all we need in 
the context we talked about.

Also, please keep in mind Hilarie's view on the need to identify every 
single OPES processor and post your thoughts to the list. If consensus 
would be that each single OPES processor needs to be identified, we 
might not even need the notion of an "OPES domain".

-Markus

---

From: jfcm <[email-masked]>
Date: Tue, 12 Aug 2003 17:05:15 +0200

Very very strong objection to this.
- military forces in Iraq are a military system made to free Iraq by GW Bush
- UK milirary forces in Iraq are a Bristh domain of forces contributing to 
that system
- Polish miliratry forces could join the system in Irak at a latter stage.

In no way the US, the UK and the Polish domain can quailfy as the self 
sustainable military system that GW Bush deemed necessary to protect the 
world from Iraqi mass destruction weapons.

I just picked that controversial image because it will be clearer to 
everyone. And that every one will easily understand that there are many 
differences/gateays between US, UK , Polish military domains in terms of 
equipment, security, chains of commands, standards, languages, operation 
protocols, etc.

Defining OPES is like definining the Iraqi strategy. Defining the OPES 
system as definiing the way for the user (GWB) will organize the necessary 
resources. Talking of OPES domains is like defining the possible 
independent contributions to the OPES system.

jfc

On 15:59 12/08/03, Markus Hofmann said:
>>single or a coordinated set of open puggable edge services. Such a system 
>>can be statically and/or dynamically organized by its user, the community 
>>of its users, a host provider or any other third party. An OPES domain is 
>>the part of an OPES system belonging to a given operator. An OPES domain 
>>is not a sub-OPES system as it may need external ressources to provide 
>>services. OPES domains have no incidence  on the structure of an OPES 
>>system, but they may influence its organization for different reasons 
>>such as security, payment, quality of service, delivery parameters, etc. 
>>particularly in the case of  dynamicly prioritized organization and 
>>revamping choices.
>
>I basically agree, but I don't see the need to formally define the term 
>"OPES system". If we've the notion of an OPES domain as indicated above - 
>in which draft and where would we need the term "OPES system"?
>
>Let's simply say that "An OPES domain describes all OPES entities operated 
>by a single provider". I would assume that's all we need in the context we 
>talked about.
>
>would be that each single OPES processor needs to be identified, we might 
>not even need the notion of an "OPES domain".

---

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

On Tue, 12 Aug 2003, Markus Hofmann wrote:

> I don't see the need to formally define the term "OPES system". If
> we've the notion of an OPES domain as indicated above - in which
> draft and where would we need the term "OPES system"?

Tracing/bypass draft. We need to define either "OPES system" or "OPES
domain" as the primary traceable/addressable entity. OPES system is
not currently defined. OPES domain is semi-defined in
draft-ietf-opes-architecture-04.

> the context we talked about.

I have to disagree. If Disney distributes its content with the help of
Akamai, Akamai entities belong to the same OPES domain/system as
Disney entities but are not operated by Disney. In fact, from an end
user or trust point of view, Disney and Akamai are (should be)
indistinguishable in this case -- they form a single OPES
system/domain.

> Also, please keep in mind Hilarie's view on the need to identify
> every single OPES processor and post your thoughts to the list. If
> consensus would be that each single OPES processor needs to be
> identified, we might not even need the notion of an "OPES domain".

I think it is totally unrealistic to expect/require every single OPES
processor to be identified in a trace. Moreover, I see no practical
value of such trace for the other side (the side reading the trace).
Internal structure of an OPES system is that system internal matter.
Knowing internals does not help the other side.

Tracing and bypass requirements must be defined for OPES
systems/domains.

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.

Or we can use the "coloring" trick from
draft-ietf-opes-architecture-04. Just make sure that the end
(provider/consumer) is included in the OPES domain/system and that the
definition is based on a given message.

The above definition puts both Disney and Akamai into one OPES system,
for a given application message they may process. Moreover, if Disney
uses both Akamai and Mirror Image (or whatever) for content
distribution, the distinction would be made on a per-message
(per-content) basis, which is the right thing to do because Akamai and
Mirror Image do not necessarily belong to the same OPES domain/system.

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 13 Aug 2003 15:54:33 -0400

Alex Rousskov wrote:

> domain" as the primary traceable/addressable entity.

That's exactly what I said - we need either one, but not both.

> indistinguishable in this case -- they form a single OPES

If Disney's (original) Web servers are operated by Akamai, they're 
part of the same OPES domain as Akamai entities. If they're not 
operated by Akamai, they do not belong to the same OPES domain.

I don't see yet why Disney and Akamai should be indistinguishable in 
the latter case. If something goes wrong on an OPES entity operated by 
Akamai, I've to turn to Akamai, if something goes wrong on a Disney 
server, I need to turn to Disney.

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

I'm wondering whether - for tracing purposes - an OPES system/domain 
should be defined by trust boundaries or by operational boundaries.

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 13 Aug 2003 14:33:48 -0600 (MDT)

On Wed, 13 Aug 2003, Markus Hofmann wrote:

> > I have to disagree. If Disney distributes its content with the
> > help of Akamai, Akamai entities belong to the same OPES
> > domain/system as Disney entities but are not operated by Disney.
> > In fact, from an end user or trust point of view, Disney and
> > Akamai are (should be) indistinguishable in this case -- they form
> > a single OPES system/domain.
>

The content you receive is produced _both_ by OPES entities operated
by Disney and OPES entities operated by Akamai. Each company operates
its own entities, and the two groups of entities form a single OPES
domain/system.

> the latter case. If something goes wrong on an OPES entity operated
> by Akamai, I've to turn to Akamai, if something goes wrong on a
> Disney server, I need to turn to Disney.

The point is that you both (a) do not know where exactly something
went wrong and (b) would very much prefer to have a single point of
contact. Imagine a rather typical situation when there are several
companies producing the final piece of content; as an end-user, you do
not want to be responsible for figuring out which company made a
mistake. Furthermore, imagine that the problem is in the _interaction_
between two OPES entities (i.e., each OPES entity is not at fault, but
OPES system is malfunctioning).

To summarize: One "end" does not want its internal organization to be
known to the outside world. The other "end" wants to have a single
point of contact/failure to troubleshoot. Tracing individual OPES
entities violates both preferences. Tracing OPES systems satisfies
both preferences.

> turn if there're any problems?

To whoever is identified in the OPES trace. It would be up to the OPES
system to decide what ID/contact info to put in the trace. Note that
we are talking about authorized adaptation of content not just
proxying/carrying of opaque data. In OPES world, A and B would have
some kind of agreement between them. The trace would reflect that
agreement in providing a single "responsible party". That party could
be A, B, or even C (some support outsourcing agency). That party would
be responsible for taking complaints, troubleshooting problems, and
defining privacy policy.

> should be defined by trust boundaries or by operational boundaries.

Operational boundaries would be impossible to define clearly. Even if
we define them, there will be too many distinct operational entities
to manage. In OPES-compliant world, there should be no more than two
mandatory traceable entities: data producer system/domain and data
consumer system/domain.

AFAIK, the "end-to-end" principle dictates the same bipolar design and
prohibits mandatory exposure of internal organization within each
system: We do not want to create intermediaries (from
trust/authority/tracing point of view) -- we want two ends talking to
each other.

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 13 Aug 2003 14:45:21 -0600 (MDT)

> 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: jfcm <[email-masked]>
Date: Wed, 13 Aug 2003 23:30:06 +0200

Dear Markus,
please stop confusing system and domains!
Whatever the definition there are many needs to support. American is poor 
enough in terms not to reduce their number :-)

Intuitively domain relates to what belong to someone or which is stable 
enough with boarders
System relates to someting whch is assembled for a purpose and which may 
expand. And uses differnt domains. Ex. The moon belongs to the Earth Domain 
and the Earth participate to the Sun system.

Or will you support the SNS for system name system? :-)
jfc

---

From: jfcm <[email-masked]>
Date: Wed, 13 Aug 2003 23:11:16 +0200

>         processing of a given message.

OK for that definition with two provisions:

1. the recursiveness makes it potentially an illimited ectoplasm what I 
accept in principle if you read Open in that sense.

Nevertheless I prefer my own approach of saying that a system is organized 
by someone because of the differences in the system, usage and awareness 
depending on who organize it. This permits me to qualify as a boarderless 
system as most probably a structural bug?

2. I maintain the important interest of the notion of domain as belonging 
to an operator. Because of the practical influence in terms of rates, 
contracts, security, qos, etc. Sub-domains should be alluded to to show 
that what count is the parameter decided by an authority.

jfc

>---
>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: Wed, 13 Aug 2003 16:20:46 -0600 (MDT)

On Wed, 13 Aug 2003, jfcm wrote:

> 1. the recursiveness makes it potentially an illimited ectoplasm
> what I accept in principle if you read Open in that sense.

Not sure I follow. Are you objecting to potentially unlimited size of
the set?

> Nevertheless I prefer my own approach of saying that a system is
> organized by someone because of the differences in the system, usage
> and awareness depending on who organize it. This permits me to
> qualify as a boarderless system as most probably a structural bug?

IIRC, you proposed to define OPES system as "a system organized to
permit its users to obtain a set of open puggable edge services."
While that make sense, it allows for more than two OPES systems to
exist for a given application message being adopted. Thus, it
complicates tracing/bypass requirements and raises end-to-end/IAB
concerns.

My definition is essentially the same except a particular formation
mechanism is embedded to prevent more than two (one "provider" and one
"consumer") systems to co-exist. The two definitions can probably be
merged:

	OPES system: A set of OPES entities organized by (or on behalf
	of) either a data provider or data consumer for
	adaptation of a given message.

Alex.

---

From: jfcm <[email-masked]>
Date: Thu, 14 Aug 2003 12:45:52 +0200

>Not sure I follow. Are you objecting to potentially unlimited size of

No. But I ask if this is what we want.

Your airfreight system is the best standard image. Passengers or luggages 
representing datagrams (however I do not understand your point about system 
tracability in another mail, I will address here, so we can see if we agree).

Let come back to your real world image and wording.
1. there is an air transport system you chose/you are proposed to travel 
(your definition below)
2. this system calls on different companies.

If a luggage is lost your last operator does not want to know where it has 
been lost, but who is reponsbile to find it back: the different involved 
companies domains of responsibility. The system MUST trace these domains 
however tiny they are (single machine). It COULD trace the different 
airports/processors but that may become confusing (they may use different 
wording, solutions) and useless (a company has no power within another 
company domain).

The question I rose was: if you accept "recursive" in the definition you 
imply that whatever the transit, as long as the luggage arrives, it is OK. 
I say this may rise a lot of questions because the luggage may this way 
legitimately transit throught places I do not want and we lose the 
possibility to say  there are transit bugs? or to restrict my luggage's 
travel and prefer them late than having transited in the USA, at risk of 
having been lost by the TSA. To keep with the discussed image.

>         of) either a data provider or data consumer for adaptation of a 
> given message.

Suits me. You may add "A set of OPES entities, parts of a single or of 
multiple OPES operators domains, organized ..."

jfc

---

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

> please stop confusing system and domains!

Not sure wheher I'm the one who's confusing things...

I refered to "OPES domain" as a collection of OPES entities operated 
by a single carrier, while an "OPES system" is rather described by 
trust boundaries. Depending on how we define tracing, we probably need 
only one of the terms.

-Markus

---

From: jfcm <[email-masked]>
Date: Tue, 19 Aug 2003 00:15:07 +0200

At 22:32 18/08/03, Markus Hofmann wrote:
>I refered to "OPES domain" as a collection of OPES entities operated by a 
>single carrier, while an "OPES system" is rather described by trust 
>boundaries. Depending on how we define tracing, we probably need only one 
>of the terms.

No, sir.

The OPES system is the system providing me/I organize to provide me a 
service. I need to reference it. But I can have several OPES system 
providing me the same service.

Each of theses OPES system can be actually built in using system bu 
different operators with different responsibilities.

Example: My ISP provides me translating services of the web pages I access. 
He calls on several services depending on the language: this is his 
WEBTranslationSystem

He also provide the same translation service for mail he names 
Translate-mailSystem. These are two different systems and I need to 
identify them.

Now WEBTS uses different translation servers, so does Te-mS. One is BBC and 
one is CNN. I does not like CNN, so I want to bar the CNN domain. As he 
does not want to lose me my ISP accepts to trim the load and to permit me 
to use BBC on both System but with a markup on Te-mS as it is a special 
service. Now I may decide to degrade to CNN on option for low importance 
mails. I obviously want to automate all that and be able to make 
statitstics etc.

Now, CNN can come with a special deal: if I accept some delays they will 
permit me to use some of their processors @ lower cost, etc....

The system is my/someone decided construct. Like an Airline System.
The domain is the processor owner accepted area of responsiblity? Like an 
Airport.

Now to know if this is runway 31 or runway 33, (identifiying each 
processor) this may or not be of used and disclosed by the domain owner, 
potentially to who they want (crypted).

Two totally different things.
jfc