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

[Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>]

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.


> Alex Rousskov wrote:
>
> > 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).
> >>
> >>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?
> >
> >
> > 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
> >>encoded/encrypted in the trace entry itself...
> >
> >
> > Exactly.
> >
> > Alex.
> >
>
>