At 00:20 14/08/03, Alex Rousskov wrote:
On Wed, 13 Aug 2003, jfcm wrote:
> At 19:57 13/08/03, Alex Rousskov wrote:
> >On Tue, 12 Aug 2003, Markus Hofmann 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.
>
> 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.
Not sure I follow. Are you objecting to potentially unlimited size of
the set?
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.
> 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.
Suits me. You may add "A set of OPES entities, parts of a single or of
multiple OPES operators domains, organized ..."
jfc