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.
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.
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.
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.
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.
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 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.
I'm wondering whether - for tracing purposes - an OPES system/domain
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.