On Thu, 3 Apr 2003, Oskar Batuner wrote:
1. An OPES processor SHOULD add its identification
to the trace.
The OPES processor is the only entity that is always present, so if
there is a MUST - it is here.
I used a SHOULD because rule 3 is a MUST. The idea is that OPES
processor must/should/may include several pieces of tracing
information. The processor ID is a SHOULD because that information is
not required by IAB and is not very useful for agents outside of the
"system".
Rule 3 is a MUST because IAB requires that privacy policy is known.
In other words, knowing individual OPES processors benefits only the
"system" admins and is not really important to others. It is a SHOULD.
Knowing privacy policy and "system" in charge is important to the
other "end" and is a MUST, the only MUST.
On another hand if OPES processor belongs to the content producer
trust domain (and in fact is an integral part of the origin) - why
should it be exposed?
I'd say MUST unless it belongs to the content producer trust domain
and is covered by the appropriate privacy policies and other
regulations (TBD).
I agree with the intent -- outside agents only care about the whole
"system" identification and policies, not its individual components.
On the other hand, "system" admins may need more detailed trace. My
solution to the problem was rule 4 which is designed to give "system"
admins full control over how the system looks to the "outside" world.
In other words, what is added by individual OPES processors can be
aggregated (i.e., partially removed) by the "system" as a whole.
2. An OPES processor SHOULD add to the trace
identification of every callout service that received
the application message.
Unless those callout processors belong to the same trust domain
and covered by the same policies.
See above. I wanted to avoid repeating "unless, ..." for every rule.
That is why I added rule 4: What is added can be removed by the same
or other agents within the same "system".
3. An OPES processor MUST add to the trace identification
of the "system/entity" it belongs to.
"system/entity" is not well defined, it is absent in the
architecture. I'd put more stress on OPES processor as a traceable
entity. We may introduce "system" (TBD), but it is a MAY.
Yes, the "system/entity" needs to be defined. If we manage to define
it, I think it will keep the rules much simpler. Here is my reasoning:
The architecture draft talks about OPES processors and trust domains.
OPES processor is too low-level entity in this context because you
have to add "... unless the processor belongs to the same ..."
exceptions to every rule.
The "trust domain" is too high-level entity in this context because a
single trust domain may include several systems with different privacy
policies and we MUST identify every applicable policy in the trace. As
you have pointed out previously, there are more than two players here;
there can be only two trust domains. Trust domains are based on
delegation of authority. We need something based on the authority
itself and its privacy policy.
Actually, the architecture draft does use "entity" (i.e., "system")
term without defining it! See section 3.1, "Trust Domains":
The delegation of authority starts at either a data consumer or data
provider and moves to more distant entities in a "stepwise" fashion.
Stepwise means A delegates to B and B delegates to C and so forth.
The entities thus "colored" by the delegation are said to form a
trust domain
The entity in the above wording is probably my "system".
How about defining an "OPES system" in this context as a "logical
group of OPES entities operating under the same authority and using
the same privacy policy"?
Will such a definition work for our purposes? Any better ideas?
"System"
ID MUST make it possible to access "system" privacy
policy.
The second sentence belongs to paragraph 1.
Or, better, a separate rule.
4. An OPES processor MAY group the above information
(items 1-3) for sequential trace entries having
the same "system/entity" ID. In other words, trace
entries produced within the same "system/entity"
MAY be merged/aggregated into a single less detailed
trace entry.
Agreed.
5. An OPES processor MAY delegate trace management to
a callout service within the same "system/entity".
I'm not sure what do you mean by delegate here. If this means
that tracing information is inserted by callout processors
according to the OPES processor instructions and under its
supervision - OK, but in this case the exact point of trace
info insertion is not essential.
Yes, that is what I meant. Yes, it is not essential in this context. I
was just trying to address concerns that sometimes it is better for a
callout service (and not the OPES processor) to add tracing
information.
If you mean delegation of authority - this does not look right.
No, I do not.
I'd set two types of requirements. First one is requirement to
identify the OPES flow participant. It will be covered by rules
1-3 (or whatever they will be transformed to). Second set of
requirements should state what kind of tracing information
MUST/SHOULD/MAY be inserted.
Sounds good to me.
- Identify traceable entities (definitions, not requirements)
- Document trace entries (definitions, not requirements)
- Document who MUST/SHOULD/MAY insert what (requirements)
Most of already proposed rules fall into the last category. I think we
almost agree regarding what is traceable (OPES processor, applied
services, and system authority and/or policy). We need to define
"system" (or rewrite the rules without it) and agree what the trace
entries should look like.
Alex.