Alex Rousskov wrote:
Tracing/bypass draft. We need to define either "OPES system" or "OPES
domain" as the primary traceable/addressable entity.
That's exactly what I said - we need either one, but not both.
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.
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.
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?
I'm wondering whether - for tracing purposes - an OPES system/domain
should be defined by trust boundaries or by operational boundaries.
-Markus