Re: Tracing Draft version-0004082003

[Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>]

On Wed, 9 Apr 2003, jfcm wrote:

> > >                       OPES tracing facility
> >
> >How about just "OPES Tracing"? Does "Facility" mean something specific?
> >Will there be other (non "facility") OPES tracing drafts?
>
> You talk about notification as specific and sometime separate from a blocked
> tacing.

What is block tracing? What do you mean by "notification as specific
... blocked tracing"?

> Also IAB expects a paper on tracing.

What makes you think that? RFC 3238 does not contain the word "trace"
or "tracing", just "notification". Did I miss it?

> >What about faulty callout servers? Do we have a term that describes
> >OPES system (processor + callout servers + whatever else is out there
> >that is OPES-related)?
>
> In this Abbie's context, with "OPES Processor" being actually used
> as a word for the whole system manager, I fully accept the wording.
> OPES Processor can be a process in a box or the supervisor of a
> large buch of callout/non-call out servers.

OPES processor is defined in the architecture draft. The definition is
not context dependent. Figure 1 in that draft clearly shows callout
servers outside of the processor box. We can change the definition
and/or the figure (and I would support a discussion about it), but
until we do, we have to use the old concept whether we like it or not.

> >The above classification seems like a result of protocol
> >over-engineering to me. Would it be possible to avoid introducing any
> >classifications/terms until the draft starts actually _using_ them for
> >a specific purpose?  This will save us a lot of time -- there is no
> >reason (and it is very difficult) to discuss something that is not
> >used (yet).
>
> Leaf to trunc (Basica vs C) approach. I do support that initial lexical
> referencing. Skip the reading if you dislike it and refere to it further
> on. Reading has not to be linear. Keep the info of where is the
> definition, so you dont have to master it first shot. Makes life easier,
> reading simpler and debates quicker. Our main problem here is word
> definition, and where they fit in a commonly accepted model.

You misinterpreted my comment. I am objecting not to forward-looking
definitions (they are perfectly fine), but definition that are not
_used_ anywhere. It does not make sense, IMO, to include
debate-causing definitions (there is no consensus about the above
definitions) when those definitions are not used! We can include them
once we actually start using them.

> Is it necessary to so exnesively motivate a decision.

If a decision may contradict IAB expectations, then yes.

> It would be helpfull in foot notes. Should notes be permited?

As an Appendix, yes. I am fine with moving the above rant into an
Appendix.

> >Why not MUST be always-on? We are talking about interoperability here (a
> >broken intermediary that does not use Via-OPES headers is an interoperability
> >problem because it cannot be bypassed).
>
> If HTTP Via is SHOULD it can only be SHOULD.

Why? HTTP does (did) not have IAB considerations to address. We have a
much higher bar to jump over.

> >Also, we need to add MUST/SHOULD/MAY to each traceable entity, I guess.
>
> MAY. to be consitent with your wording.

Which wording?

> >I am not sure about the above. It contradicts our statement that we are
> >addressing IAB concerns. If there is no trace, we are not.  I think it is
> >reasonable to say that there MUST be at least one trace entry per "system".
> >(A trust domain may include several such systems/entities, see the trust
> >domain definition).
>
> I think we are with option to turn it out. Privacy must be permitted.

If a provider has an option to turn _all_ tracing off, then we are not
supporting notification in any shape or form. Privacy can be permitted
by making trace entries contain no private information.

Alex.