On Sun, 6 Apr 2003, The Purple Streak, Hilarie Orman wrote:
Stepping back for a moment, it seems to me that you need to identify
four essential things relevant to a "traceable entity" (Oskar called
these "reference points", I believe):
1. The privacy policy at the time it dealt with the message.
Maybe, though #2 is probably sufficient. If we include #1, we would
have to define what a "privacy policy" is, which is not going to be
fun. Moreover, we would have to define what an _acceptable_ (OPES
compliant?!) privacy policy is. See my earlier e-mail about that.
For starters, are "we have no privacy policy" and "our privacy policy
is only available through a court order or for $1,000" acceptable
privacy policies?
As long as the "responsible party" is identified, OPES responsibility
ends. If a user does not like (or cannot find!) that "party" policies,
the user can bypass.
2. Identification of the party responsible for setting and
enforcing that policy.
Yes.
3. Information pointing to a technical contact
Should be optional. Info in #2 is the only "point of contact" that
outsiders should be able to see.
4. Information that identifies, to the technical contact, the
OPES processors involved in processing the message
Item 4 can be opaque, i.e., only has meaning to the technical contact.
Yes, but also optional, of course.
I don't know if we want to standardize the representation of any of
this, other than the tracing header names.
The only reason to standardize representation is to expect some
automated processing of this information. I would not spend too much
time on this. I would suggest something very basic like:
<URI|""> [comment]
for every identifier (required URI or empty string, followed by an
optional free-flow comment, encoded appropriately depending on the
application protocol). This should be good enough for log analyses and
similar automated tools but flexible enough to accommodate virtually all
human needs.
There has not been any discussion of what triggers tracing. I
suppose it must originate from an endpoint (consumer or provider).
Is it "per request" or "per connection" or "per something-else"
(application-specific)? Or required all the time?
I would start by requiring it at all times because:
- you cannot, in general, re-trace an old message;
network paths and intermediary decisions are
not constants; if you do not get a trace
with the message, you cannot be sure the bug
you saw was caused by the same intermediaries
you are now tracing one second later
- some messages are impossible, dangerous, and/or
costly to repeat
The only objection to always-on tracing is the performance and
bandwidth overhead. Our design limits the amount of information to the
necessary minimum, so we should be safe given we are adapting
application protocols and not transport-level things that have to
count every bit.
There's also the question of "who's asking?" Items 1-3 might be
considered sensitive information, relevant to competitors, or even
security and privacy relevant. So a consumer might intend a trace
request to mean "tell me what is applied by my network service
provider and entities he contracts with, and anything else you can
find out from the provider, but don't tell the content provider
anything." And a caching OPES processor might send requests to
content providers with a tracing request that meant "one or more of
my consumers has requested tracing" and would cache the response
with tracing headers.
I do not think traces reveal anything sensitive other than identities
of "systems" that touched our message. Moreover, the latter can be
obscured if really needed! I would start with a simple always-on
scheme and make it more complex only if there are very specific
reasons for that added complexity.
Thanks,
Alex.