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

From: "Abbie Barbir" <[email-masked]>
Date: Thu, 28 Aug 2003 16:42:14 -0400

Alex,

Agree, This is why I did the cut/Paste.

We need input from everyone here, please

Abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]] 
> Sent: Thursday, August 28, 2003 4:38 PM
> To: Barbir, Abbie [CAR:1A11:EXCH]
> Cc: [email-masked]
> Subject: Re: [opes-end-comm]: What is traceable in an OPES Flow?
> 
> 
> Abbie,
> 
> I would remove the entire old text you quoted and replace it 
> with implementation requirements:
> 
>     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 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.
> 
> 
> On Thu, 28 Aug 2003, Abbie Barbir wrote:
> 
> > 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: "Abbie Barbir" <[email-masked]>
Date: Fri, 29 Aug 2003 14:51:39 -0400

Hi,

Agreed on all

Abbie

> Sent: Friday, August 29, 2003 12:36 PM
> To: OPES WG
> 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.
> 
>

---

From: "Abbie Barbir" <[email-masked]>
Date: Fri, 29 Aug 2003 14:53:58 -0400

> Sent: Friday, August 29, 2003 1:26 PM
> To: Markus Hofmann
> Cc: OPES WG
> > 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.
> 
--------Abbie

Agreed