Subject: Tracing Draft version-05042003

From: "Abbie Barbir" <[email-masked]>
Date: Sun, 4 May 2003 07:00:46 -0400

hi,

attached is the updated version of the tracing draft.
please provide feedback ASAP.

Note: This is work in progress. I am on the road with limited e-mail access
untill May 8th.

Regards

Abbie

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 9 May 2003 15:07:03 -0600 (MDT)

> 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>