On Sun, 4 May 2003, Abbie Barbir wrote:
attached is the updated version of the tracing draft.
please provide feedback ASAP.
Abbie,
I would suggest a [very] different organization for this
document. The current version seems to focus on IAB considerations
instead of on defining OPES tracing interface. It seems like we are
writing this for IAB and not for OPES users and implementors. I would
suggest to focus on the primary objective instead:
1. Introduction
2. What is traceable?
3. Requirements for OPES processors
4. Requirements for callout servers
5. Requirements for OPES systems
6. Privacy considerations
7. Security considerations
8. IAB considerations
8.1 Addressing IAB Consideration 3.1
8.2 Addressing IAB Consideration 3.2
...
...
Another big issue is that we are missing a very important piece here
-- the definition and clear understanding of an OPES "system", the
only mandatory traceable OPES entity. We need to define that, and
define its relationship with Trust Domains and OPES processors. Then
everything will snap into place :-).
Specific comments are below using the following notation.
[ square brackets surround comments on the above text ]
{ curly braces surround suggested replacement of the above text }
Thank you,
Alex.
-----------------------------
This memo provides a discussion of tracing requirements for OPES as
part of addressing the IAB considerations on this issue.
{
This memo documents tracing requirements for Open Pluggable Edge Services
(OPES).
}
In [2] the IAB has required OPES solutions to address end user and
content provider notification concerns. IAB, considerations regarding
notification suggests that the overall OPES framework needs to assist
content providers in detecting and responding to client-centric
actions by OPES intermediaries that are deemed inappropriate by the
content provider, and that the overall OPES framework should assist
end users in detecting the behavior of OPES intermediaries,
potentially allowing them to identify imperfect or compromised
intermediaries.
This document specifies tracing mechanisms that
address those concerns. The work focus on developing tracing
requirements that can be used to fulfill the notification and
Non-Blocking suggestions from the IAB. The appropriate design of
tracing mechanisms can properly address the notification requirements
without introducing added complexity to the OPES architecture.
[ Move the above two paragraphs out of the Introduction. IAB
considerations are not important to most readers; they are internal
IETF matter; we are here not to address IAB considerations but
to document OPES requirements; addressing IAB considerations is
a required side-effect of our work, not the primary objective.
Document what we are after here, without referring to IAB
concerns.]
[
Similar changes should be done throughout the document.
At the end, add an Appendix or Section titled "IAB Considerations"
and summarize how we addresses relevant considerations.
]
Tracing is defined as the inclusion of necessary
information within a message in an OPES flow that could be used to
identify the set of transformations or adpatations that have been
performed on its content before its delivery to an end point (the
data consumer application).
{
OPES trace:
application message information about
OPES entities that adapted that message
OPES tracing:
the process of including, manipulating, and interpreting
an OPES trace
}
Tracing SHOULD be performed on per message basis.
[delete -- yours and mine definitions of tracing leave no other
possibility]
The format is dependent on the application level
protocol that is used by the OPES system. The architecture requires
that tracing be supported in-band. Furthermore, tracing can be used
as a tool by the end user data application to infer the actions that
has been performed by the OPES system.
{ Trace format is dependent on the application protocol being adapted
by OPES. Data consumer can use OPES trace to infer the actions that
have been performed by OPES system(s).}
On the otherhand, notification propagates in opposite direction of
tracing and cannot be attached to application messages that it
notifies about. Notification can be done out-band and may require the
development of a new protocol. The direction of data flow for tracing
and notification are deoicted in Figure 1.
[ move the above paragraph and the whole "notification" discussion
to "8. IAB considerations" ]
3.1 What is traceable?
Tracing should provide information to end points in an OPES flow that
enable it to identify the various entities that are involved. The
main focus of this work is the data consumer application end point.
[I am not sure what the above text is trying to accomplish. Can you be
more direct? Delete it?]
The following entities SHOULD be identified in a trace by a data
consumer application end point:
o The data consumer application end point MUST be able to identify
the OPES processors that have acted on an application message.
o The data consumer application end point SHOULD be able to identify
OPES services (including callout services) that were performed on
request/responses that are part of an application message.
o TBD.
o TBD.
[The interaction of "SHOULD be identified" and "MUST be able to
identify" in the above is not clear to me. The purpose of "data
consumer application end point" limitation is also not clear. Consider
the following instead:]
{ For a given trace, an OPES entity involved in handling the
corresponding application message is "traceable" or "traced" if
information about it appears in that trace. OPES entities have
different levels of traceability requirements. Specifically,
o An OPES system MUST be traceable
o An OPES processor SHOULD be traceable
o An OPES service MAY be traceable
}
[ We still need to define "OPES system" ]
3.1.1 Requirements for Information Related to Traceable Entities
o The privacy policy at the time it dealt with the message.
o Identification of the party responsible for setting and enforcing
that policy.
o Information pointing to a technical contact
o Information that identifies, to the technical contact, the OPES
processors involved in processing the message
[ I would split the above into sections specific to each traceable
entity because I expect the required information to vary a lot,
depending on the entity.
]
3.2 Tracing and Trust Domains
A trust domain may include several OPES systems and entities. Within
a trust domain, there MUST be at least support for one trace entry
per system. Entities outside of that system may or may not see any
traces, depending on domain policies or configuration. For example,
if an OPES system is on the content provider "side", end-users are
not guaranteed any traces. If an OPES system is working inside
end-user domain, the origin server is not guaranteed any traces
related to user requests.
[ Does not the above contradict yours and mine MUSTs about OPES system
traceability, as well as IAB considerations? Let's define an OPES
system and then see how to fix the above text. ]
3.3 Tracing and OPES System Granularity
There are two distinct uses of traces. First, is to SHOULD enable the
"end (content producer or consumer) to detect OPES processor presence
within end's trust domain. Such "end" should be able to see a trace
entry, but does not need to be able to interpret it beyond
identification of the trust domain(s).
Second, the domain administrator SHOULD be able to take a trace entry
(possibly supplied by an "end? as an opaque string) and interpret it.
The administrator must be able to identify OPES processor(s) involved
and may be able to identify applied adaptation services along with
other message-specific information. That information SHOULD help to
explain what OPES agent(s) were involved and what they did. It may be
impractical to provide all the required information in all cases.
This document view a trace record as a hint, as opposed to an
exhaustive audit.
Since the administrators of various trust domains can have various
ways of looking into tracing, they MAY require the choice of freedom
in what to put in trace records and how to format them. Trace records
should be easy to extend beyond basic OPES requirements. Trace
management algorithms should treat trace records as opaque data to
the extent possible.
It is not expected that entities in one trust domain to be able to
get all OPES-related feedback from entities in other trust domains.
For example, if an end-user suspects that a served is corrupted by a
callout service, there is no guarantee that the use will be able to
identify that service, contact its owner, or debug it _unless_ the
service is within my trust domain. This is no different from the
current situation where it is impossible, in general, to know the
contact person for an application on an origin server that generates
corrupted HTML; and even if the person is known, one should not
expect that person to respond to end-user queries.
[ Ideally, I would like to see a more consistent/systematic approach
here.
Can we say that every Nth OPES "level" MUST see [N-1] level details?
So, end point MUST see OPES systems involved, OPES system operator
MUST see OPES processors and OPES processors MUST see OPES services?
I am not proposing the exact text; just illustrating the approach.
It should be easy for the reader to see the rationale/system behind
all these MUSTs and SHOULDs. ]
o Session related information: Session level data MUST be preserved
for the duration of the session. OPES processor is responsible for
inserting notifications if session-level information changes.
[What is a session?]
o End-point related data: What profile is activated? Where to get
profile details? Where to set preferences?
[Why is this related to OPES? Should not we limit ourselves to
intermediaries and exclude end-points?]
o TBD
[I suggest removing this section until it is needed]
3.6 Requirements for OCP Support for Tracing
If it is the task of an OPES processor to add trace records to
application messages, then the OCP protocol is not affected by
tracing requirements. In order for an OCP protocol to be tracing
neutral, the OPES server SHOULD be able to meet the following
requirements:
[Add OPES _callout_ server?]
o Callout services adapt payload regardless of the application
protocol in use and leave header adjustment to OPES processor.
[I may be missing something important, but I would delete this
requirement as both irrelevant to tracing and wrong from OCP point of
view]
o OPES processor SHOULD able to trace its own invocation and
service(s) execution because OPES processor understand the
application protocol.
[I do not understand this. How is this related to OCP?]
o Callout servers MAY be able to add their own OPES trace records
to application level messages.
[Agreed]
3.7 How to Support Tracing
[Again, I would split this section onto entity-specific sections ]
In order to support tracing, the following aspects must be addressed:
o There MUST be a System Identifier that identify a domain that is
employing an OPES system.
[Big problem here. We need to define an OPES system. Trust domain
may include many OPES systems. In fact, there are always no more than
two trust domains on the OPES path (but there may be tens of systems!
]
o An OPES processor MUST be able to be uniquely identified (MUST
have an Identifier) within a system.
o An OPES processor MUST add its identification to the trace.
[ I think these are SHOULDs. System MUST be identified, processor
SHOULD. ]
o An OPES processor SHOULD add to the trace identification of every
callout service that received the application message.
{An OPES processor SHOULD ensure that every callout service used is
traced}
[An OPES processor may not be the one that adds this information since
a callout server may add it]
o An OPES processor MUST add to the trace identification of the
"system/entity" it belongs to. "System" ID MUST make it possible
to access "system" privacy policy.
[Similar problem, I think. Not every processor may add this
information. System MUST add it (somehow, possibly using one of its
processors).]
o An OPES processor MAY group the above information 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.
[Again, this is a requirement for the system, not the processor; a
system may use a designated processor to fulfill the requirement ]
</eof>