-----Original Message-----
From: jfcm [mailto:info(_at_)utel(_dot_)net]
Sent: Wednesday, April 09, 2003 10:25 AM
To: Alex Rousskov; ietf-openproxy(_at_)imc(_dot_)org
Subject: Re: Tracing Draft version-0004082003
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