At 15:03 09/04/03, Alex Rousskov wrote:
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"?
I mean that if he permits to block the tracing facility (what you object) he
documents case were there is no tracing and notification. So notification
should be in the title.
> 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?
lapsus calami. I meant IAB expects a paper on notification. Adding
tracingis OK but notification must also be quoted in the title.
> >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.
I do dislike it. I say it. And I just say that Abbie's paper is acceptable
even for a person outside of this WG knowing the reason of this
language.
> >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.
OK. You said you would not discuss that tevel in your mail. So
I assumed the above. However I not fully dig into the definitions but
I felt they brought some light on what he wanted to say and be of
use in the futher debale. Will not fight for them if the text is clear
without them.
> Is it necessary to so exnesively motivate a decision.
If a decision may contradict IAB expectations, then yes.
Is there not a way to document a position without entering
them into the text? This makes the text to be part of a debate
rather than a reference. This may give the feeling the examples
are very important to the text, while they are only current
examples.
> 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.
great.
> >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.
IAB is not the reference for me. The reference is the consistency of what
is considered. OPES are over HTTP. There should not be obliged more than
the supporting HTTP protocol. Seems layer violation to me.
> >Also, we need to add MUST/SHOULD/MAY to each traceable entity, I guess.
>
> MAY. to be consitent with your wording.
Which wording?
Just above you used the word "can ".
> >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.
If you accept to waste bandwidth and nanoseconds, yes.
jfc