Subject: Publishing Tracing Draft as WG Document

From: Markus Hofmann <[email-masked]>
Date: Fri, 30 May 2003 09:21:28 -0400

Hi,

I suggest that the current write-up on "OPES Tracing" (see Abbie's
email to the list dated 5/4) also gets adopted and published as WG
Internet Draft, from which the WG will continue to work on.

Unless someone objects by Friday 6/6, I'd ask Abbie to submit the
"Opes Tracing" document for publication as WG ID.

Note that this is still work in progress, and that the WG will
continue to work on and modify the document.

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 30 May 2003 09:02:49 -0600 (MDT)

Markus,

	While I would like to see significant changes to the Tracing
draft organization and content (I have posted my specific comments
earlier), I have no problems with declaring the draft a working group
document. My understanding is that a "working group document"
declaration means nothing but the intention of the working group to
work on the document together.

	However, I think at least one issue needs to be resolved
before we submit the draft for publication. The current draft focuses
on tracing and the title reflects that. The other related
functionality that we will need to document is bypass. Bypass
documentation will probably be quite short. I suspect there may be
other small things that are not OCP-related but do not fit into
architecture or tracing drafts. This issue has been discussed before
(see April thread titled "set of OPES documents"), and I would like to
reiterate Oskar's suggestion that instead of a dedicated "OPES
Tracing" draft we have a more general draft that covers tracing,
bypass, and perhaps some other similar mechanisms.

	The following names have been suggested:

	"OPES tracing, notification and directives"
	draft-ietf-opes-dirs-trace (Oskar Batuner)

        "Processor-to-end communications in OPES"
        draft-ietf-opes-end

        "OPES processor and end points communications"
        draft-ietf-opes-end

I am not particularly happy with either one; hopefully we can find a
better name. I think there is an agreement that the document will be
about communication among OPES intermediaries (processors) and
application end points (clients and servers), including communication
among OPES intermediaries alone, but excluding callout protocol
specifics. Is the following too general?

        "OPES communications"
        draft-ietf-opes-comm

Or we could use something specific at a risk of being too specific:

	"OPES tracing and bypass"
	draft-ietf-opes-trace

It seems to be a good idea to decide on the name before publishing so
that we do not have to restart versioning if we change the name later.
The current text can remain the same, except for the title, of course.
Or we can add a short paragraph explaining the future direction of the
draft and inclusion of bypass feature.

Thank you,

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Fri, 30 May 2003 11:36:14 -0400

> work on the document together.

Absolutely correct!

> draft and inclusion of bypass feature.

Valid point, the title should be chosen so that we don't have to 
change it later on.

The IAB considerations talk about "notification" and mention "bypass". 
On the list, we had consensus that "tracing" is practially more 
feasible than a strict notification mechanisms, so the document will 
have to address those three issues - would "OPES tracing, 
notification, and bypass" be an approriate title?

Someone else any opinion on the title?

Thanks,
   Markus

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 30 May 2003 10:15:42 -0600 (MDT)

On Fri, 30 May 2003, Markus Hofmann wrote:

> The IAB considerations talk about "notification" and mention
> "bypass".  On the list, we had consensus that "tracing" is
> practially more feasible than a strict notification mechanisms, so
> the document will have to address those three issues - would "OPES
> tracing, notification, and bypass" be an approriate title?

IMO, the draft in question will not address notification at all. The
"IAB Treatment" draft addresses notification. Since we provide no
protocol-level support for notifications, there is no reason to talk
about them in the technical draft. Moreover, if somebody wants to
support notifications directly, they will write a separate "OPES
Notification" draft.  The "IAB Treatment" draft will discuss why we
concentrate on tracing and how notification is assisted by tracing.

Thus, I would be against using the word "notification" in the draft
title.

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Fri, 30 May 2003 13:30:09 -0400

> concentrate on tracing and how notification is assisted by tracing.

That's correct. Point is that we *will* have to address the 
notification issue somewhere; doing this in the "IAB 
considerations/Treatment/whatever" draft is fine, if we keep in mind 
that this is likely to require technical argumentation as well.

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 30 May 2003 12:57:15 -0600 (MDT)

> that this is likely to require technical argumentation as well.

I agree. The Treatment draft already has some wording explaining the
tracing versus notification trade-off, mostly based on Abbie's
original text.

Alex.