Hi,
I will sort through and then make a decision on how to address the issues here.
So, please wait untill the next update.
Abbie
> -----Original Message-----
> From: jfcm [mailto:info@xxxxxxxx]
> Sent: Wednesday, April 09, 2003 10:25 AM
> To: Alex Rousskov; ietf-openproxy@xxxxxxx
> 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
>
>
>