Subject: [opes-end-comm]: What is traceable in an OPES Flow?

From: "Abbie Barbir" <[email-masked]>
Date: Thu, 28 Aug 2003 15:54:10 -0400

Hi,

I am working my way through the tracing draft.
The next issue is section 2.1 "What is traceable in an OPES Flow?"

The section is below

  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

   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

I need feedback from the WG on this issue. Please send your remark ASAP

Abbie

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 28 Aug 2003 14:38:00 -0600 (MDT)

Abbie,

I would remove the entire old text you quoted and replace it with
implementation requirements:

    o  An OPES system MUST add its entry to the trace.

    o  An OPES processor SHOULD add its entry to the trace.

    o  An OPES service MAY add its entry to the trace.

    An OPES entity MAY manage trace entries of entities it
    controls(?). For example, an OPES processor may add
    and/or remove callout service entries.

The above needs further polishing of course. The main point is that we
should have specific implementation requirements in this draft, and
reduce abstract talk about what end points would like to see in the
trace. In other words, describe how to build the trace, spend less
time (and no RFC 2919 keywords!) on why we want the trace to look like
that. Make all rationale explanations clearly non-normative.

HTH,

Alex.

---

From: jfcm <[email-masked]>
Date: Fri, 29 Aug 2003 14:45:13 +0200

Cute and approved with some questions.

>     o  An OPES system MUST add its entry to the trace.

OK.

>    o  An OPES processor SHOULD add its entry to the trace.

OK.

>    o  An OPES service MAY add its entry to the trace.

OK. Would prefere SHOULD but real workd will tell.

>     controls(?).

?    "it will be able to authoritatively document
       the tracing queries"

>    For example, an OPES processor may add

"remove" or "screen"?

>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.512 / Virus Database: 309 - Release Date: 19/08/03

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 29 Aug 2003 09:20:35 -0600 (MDT)

> >     and/or remove callout service entries.

The intent behind the above two sentences is to allow "higher level"
entities to manage traces for or on bahalf of "lower level" entities.
For example, if an OPES processor uses 100 tiny callout services, the
processor may be configured to remove all callout service entries from
the trace and just insert its own entry (to keep the trace reasonably
small). Another example is when an OPES processor knows that a callout
service does not trace itself and adds a callout service trace entry
for that service. Similarly, an OPES system may designate an OPES
processor to remove all tracing entries and ad a single system entry.

I am not sure what you mean by "documenting tracing queries". Do we
talk about "tracing queries" at all anywhere? What are they?

> "remove" or "screen"?

To me, "screen" means "looking at something with the intent to
remove". "remove" sounds more direct in this context. Perhaps I
misunderstood your question.

Thanks,

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Fri, 29 Aug 2003 11:54:31 -0400

Alex Rousskov wrote:

> small). 

It seems to me, however, that in this case, the OPES processor must 
still be able to identify those 100 tiny callout services when a user 
inquiry arrives later on. It's not sufficient just to know "yes, I did 
something to the message and a several services were executed". It's 
necessary to know exactly which services were executed. How else would 
someone be able to solve possible problems?

This should be spelled out in the document.

It might be a local matter on how this is achieved - one might decide 
to maintain the necessary state (well, I probably wouldn't opt for 
that option), or maybe the executed services get somehow 
encoded/encrypted in the trace entry itself...

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 29 Aug 2003 10:35:49 -0600 (MDT)

On Fri, 29 Aug 2003, Markus Hofmann wrote:

> Alex Rousskov wrote:
>
> > The intent behind the above two sentences is to allow "higher
> > level" entities to manage traces for or on bahalf of "lower level"
> > entities. For example, if an OPES processor uses 100 tiny callout
> > services, the processor may be configured to remove all callout
> > service entries from the trace and just insert its own entry (to
> > keep the trace reasonably small).
>
> still be able to identify those 100 tiny callout services when a
> user inquiry arrives later on. It's not sufficient just to know
> "yes, I did something to the message and a several services were
> executed". It's necessary to know exactly which services were
> executed. How else would someone be able to solve possible problems?

The above is indeed desirable but on a MAY level:

	- The OPES processor may have a fixed configuration
	  so it can always answer your question without
	  any extra information in the trace.

	- The OPES processor may insert a [coded] summary
	  of the 100 services applied so that it can
	  answer your question with more (but perhaps
	  incomplete) information about 100 services.

	- The user will most likely not understand and
	  not care what those 100 tiny services are. We
	  cannot demand that every service is documented
	  sufficiently enough that every reasonable
	  human being understands what it does.

	* It is the job of the OPES processor to solve
	  problems. Let's not tell it how. It is the right
	  of the other side to complain about problems.
	  Let's give it sufficient tools to do so. What is
	  sufficient? Whatever the trace builder considers
	  sufficient (because it is the builder that is
	  responsible for decoding the trace details and
	  solving the problem)! A System MUST be traced
	  so that the other side always knows who to
	  complain, regardless of what the trace builder
	  considered "sufficient".

The first three arguments are just examples of why anything above MAY
level would not make much sense when we are talking about something as
poorly scoped as an OPES service.

The last argument is the most important one, IMO. It is the
cornerstone of what I would consider a good tracing approach in an
OPES context. The trace is a trouble ticket ready for submission to a
known address. The trace in itself is not necessarily a detailed or
clear description of what has happened.

We are not dealing with two "equal" sides communicating with one
another. Our sides have very different view of the problem domain.
Let's make it easy for a side to complain. Let's leave troubleshooting
specifics to the troubleshooter since there are so many different ones
that we cannot even enumerate them.

> This should be spelled out in the document.

Yes, of course, but that's Abbie's job :-).

> It might be a local matter on how this is achieved - one might
> decide to maintain the necessary state (well, I probably wouldn't
> opt for that option), or maybe the executed services get somehow

Exactly.

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Fri, 29 Aug 2003 12:51:46 -0400

I'd suggest that the document includes and explains these thoughts and 
reasons - just along the lines of your comments below. It will help to 
decide whether we've consesus or not.

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 29 Aug 2003 11:25:56 -0600 (MDT)

On Fri, 29 Aug 2003, Markus Hofmann wrote:

> I'd suggest that the document includes and explains these thoughts
> and reasons - just along the lines of your comments below. It will
> help to decide whether we've consesus or not.

Yes, as a separate non-normative "Rationale" section or subsection.
While I do want to document our rationale, I am afraid that if it is
intermingled with normative text than people will find a mistake or a
loophole in our reasoning and will use that as a reason to violate a
related MUST. This common problem is especially dangerous when we talk
about controversial and poorly defined concepts as OPES.

Alex.