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.