Subject: [newtrk] some questions about WGSs

From: [email-masked] (Scott Bradner)
Date: Fri, 19 Mar 2004 10:54:32 -0500 (EST)

Following up on the discussion in Korea, do people on this list think that
defining a Working Group Snapshot (WGS) is a separable issue from defining
a new standards track?

i.e., do we have to wait until we have reached consensus on a new
standards track before we can create a document that describes a WGS?

This question assumes that there is consensus that the IETF should have
something like a WGS.  I'm defining a WGS at a high level at this point -
just saying that a Working group Snapshot is a way for a Working Group
(with or without some level of IESG involvement) to anoint a particular
pre-Proposed Standard RFC as something vendors who want to implement
pre-Proposed Standard technology could implement.   I'm specifically not
presupposing the answer to a number of questions including: what level of
IESG involvement should there be in approving a WGS, what external review
requirements might there be, is the WGS an archival document, is the WGS 
part of a new documentation series, etc - all of these issues, and more, 
would be discussed while discussing a WGS document.

specific questions:

1/ am I correct that there is some level of consensus in favor of a
pre-Proposed Standard WGS?

2/ if so, is a WGS something that can be defined on its own or must it be
defined at the same time (and in the same document) as a possible revised
standards track?

tnx

Scott
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 19 Mar 2004 09:19:27 -0700 (MST)

> standards track before we can create a document that describes a

I guess that depends on whether WGS is essentially a step/milestone on
the new standards track path. That is, it depends on your high-level
definition of WGS.

> I'm defining a WGS at a high level at this point - just saying that
> a Working group Snapshot is a way for a Working Group (with or
> without some level of IESG involvement) to anoint a particular
> pre-Proposed Standard technology could implement.

The above definition is not yet usable, IMO. What are the essential
differences between an Internet draft, WGS, and PS? An Internet Draft
is a pre-PS document that vendors who want to implement pre-PS
technology could implement. For WGS high-level definition to be
useful, it has to imply some essential difference between ID, WGS, and
PS.

Is that an "implementability" difference: a WG assurance/opinion that
the technology is documented with sufficient detail to be fully
implementable? Is that a "stability" difference: a WG
assurance/opinion that whatever pieces are documented they are not
going to change much in the anticipated PS version? Is that a
"direction" difference: a WG assurance/opinion that the draft will
become a PS rather than an informal informational RFC? A combination
of the above? Something else? Let's define it.

> pre-Proposed Standard WGS?

There is always some level of consensus, especially when the intent is
noble and definitions are fuzzy.

> 2/ if so, is a WGS something that can be defined on its own or must
> it be defined at the same time (and in the same document) as a
> possible revised standards track?

I hope the answer to this question should be clear once the high-level
definition of WGS defines something other than "ID that is not PS".

Alex.
.

---

From: "Charles E.Perkins" <[email-masked]>
Date: Fri, 19 Mar 2004 09:25:05 -0800

Hello Alex,

My view of the WGS is that it is a tool for the
working group, more stable than an Internet Draft 
(probably _much_ more stable).  While not a
itself a step towards standardization, it provides
an identifiable known quantity that implementation
teams can use with some confidence.

I prefer requiring interoperability for WGS, but
opinions vary on this point.  By the way, I would
also greatly prefer to change the requirement
for Proposed Standard to require interoperability,
and I never understood why it wasn't required.

> the new standards track path. That is, it depends on your high-level

By my above statement, I reckon that the WGS definition
is separable from the effort to define a new standards
track.  But, in practice I think there will be some effect.
If we have WGS, then Proposed Standard could remain the
timeconsuming goal it is today, while work proceeds
more productively within the working group in the meantime.

Also, if (according to my preference) implementations are
required. then logically implementations should be required
for Proposed Standard also.
 
>                                             What are the essential

In practice, there are more Internet Drafts than implementation
teams during the development time for the specification.
For example, two independent teams might easily trigger the
production of a half-dozen Internet Drafts.  A third team
might be at a loss to find out "which" protocol to implement.
With WGS, this problem would go away.  Furthermore, test
suites would be more likely available for WGS versions 
than for other random drafts.

Besides that, the working group is sometimes, today, paralyzed
by considerations stemming from the status of related documents
(normatively referenced).  For instance, if protocol X uses
a feature from protocol Y that is in a document not yet published,
then protocol X basically cannot go forward, no matter how
trivial the dependence.  In the meantime, bad things happen,
and other protocols enter the marketplace with _far worse_
overall effects than the astronomically unlikely bad effect
that _might_ result from yet another revision to unpublished
protocol Y.

This is basically stupid.  We can do better!  A natural
evolution of this stupid and bad effect, is that IETF
working groups should NEVER normatively reference the
work in any other working group.  Why don't we engineer 
our evolution to avoid these sorts of horrid adaptations?
My belief is that WGS is a step along the way towards
a better evolution.

> implementable?

Yes, in my opinion.

>                      Is that a "stability" difference: a WG
> going to change much in the anticipated PS version?

I don't think the WG can give that assurance, given current 
relationship with the IESG.  For instance, an IESG member
can essentially demand any change, even killing a document.
The working group does not have enough control to make 
the suggested guarantee. 

>                                                     Is that a
> become a PS rather than an informal informational RFC?

I would much prefer to say what a WGS is (e.g., as I have
tried to describe it above) instead of already restricting
its applicability.  I don't see why the suggested assurance
is helpful.  For instance, the IESG might demand publication
as Informational instead of Proposed, or else as Experimental.
Who knows?

Regards,
Charlie P.
.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 19 Mar 2004 09:40:41 -0800

Personally, I don't see much difference between a WGS and
an Experimental RFC.  Unless a WGS publication doesn't
involve the RFC Editor (and maybe doesn't involve the
IESG).  But in any case, a WGS is not (I hope) a Standards
Track document.

I think changes to levels of a Standard Tracks can and
should be considered separately from WGS proposals.  I suggest
newtrk consider changes to levels first, as I think WGS
proposals are going to be far more contentious.

Kurt

.

---

From: John C Klensin <[email-masked]>
Date: Fri, 19 Mar 2004 13:03:03 -0500

Scott,

I share Alex's concerns (it is just easier to say what little I 
have to say in response to your posting).

I think the WGS can be defined independent of the standards 
track, and that it is potentially useful.  But "vendors can go 
off and implement this" scares me -- while the current 2026 
language circles around it a bit, we basically don't make that 
recommendation for PS today, or at least surround it with a lot 
of warnings about our ability to change PSs for even fairly 
minor reasons.  Whether we, or the vendors, believe those 
disclaimers is part of the standards track discussion, IMO.

Instead, I'd see "WGS" a little differently.  Let me suggest a 
definition in the hope of bringing your suggestions and Alex's 
concerns a little closer together, or at least giving us 
something to discuss.

Problem (I'm tired of "we don't know what problem this solves, 
but maybe it is a good idea anyway" solutions, so want to 
encourage people to identify the problems they are trying to 
solve): the distinction between draft-ietf-wgname-foo... and 
draft-ParticipantName-bar... is a little too subtle for most of 
us and doesn't convey any information about document status. 
Listing something on a WG web page may or may not provide any 
useful information.

If others (including Scott) are trying to solve a different 
problem, I think if would be helpful if they would identify it.

Suggestion:  Let's borrow most of the procedure and definitions 
associated with what JTC1 calls a "Committee Draft" (CD) and 
adapt it (those who were in, or listened to, one of my tirades 
in Seoul should note this suggestion and its origins).   In 
JTC1, WGs fling all sorts of numbered documents around as well 
as meeting and email conversations.  The CD designation 
identifies something that is likely to eventually emerge as a 
product (standard or technical report) to be taken and studied 
seriously (for flaws, if nothing else) in its own right.  A CD 
is far enough along that the WG believes that

	(i) it is responsive to one of the WG's work items and
	
	(ii) Barring some nasty surprise, it is likely to
	eventually evolve into a first-level standard.  However,
	nasty surprises happen, and "evolve" can cover some
	changes radical enough to make the relationship between
	the draft and the standard (and, in JTC1's case, a level
	or two of intermediate balloting documents) nearly
	unrecognizable.   I.e., someone who deploys product on
	the basis of a CD is likely either an extreme optimist
	or a fool (to the extent that those categories are
	different).

So, for our purposes, maybe something like the following would 
work:

* A WGS is solid enough that there is some plausible level of WG 
consensus that it is likely to evolve into a standard or other 
formal WG output.  That consensus need not exclude other cases 
or outputs, nor must the WG conclude that further significant 
evolution is implausible.  Picking on a comment in Charlie's 
note, but trying to preserve flexibility, WG's should probably 
be encouraged to include in the WGS (or a statement about it) 
exactly what it does represent, e.g., whether there are 
implementations and whether interoperability tests/ 
demonstrations have been performed, but I think we would hurt 
ourselves by making that a requirement.

* The requirements for a WGS are

	-- rough (extremely rough) consensus within the WG that
	the designation is appropriate and a statement to that
	effect by the WG Chair.
	
	-- signoff (I would prefer by timeout and default) by
	the cognizant AD that the WG consensus is reasonable.

Explanation of the "signoff" requirement:  I expect that ADs 
will, at a minimum, know which WGs are in trouble, behaving 
badly, having consensus problems, etc.  I believe that is 
generally the case today, whether action is being taken or not. 
If a WG Chair sends a note to the AD that says "we are going to 
make draft-xxx-yyy... a WGS" and the WG is generally in good 
shape, I'd expect the AD to either send best wishes or to sleep 
through the announcement (and I don't think we should prefer one 
over the other).  If, by contrast, the WG is problematic in one 
way or another, I'd expect the AD to assure him or herself that 
the claim of consensus is plausible before issuing a "go ahead", 
or going back to sleep, or requesting somewhat more process. 
Again, this gets pretty close to what JTC1 does in practice: 
"registering" a CD requires a consensus request from the WG and 
approval by the parent Subcommittee.  But the subcommittee 
usually approves those request pro-forma unless there is some 
evidence of controversy within, or surrounding, the WG.

_However_ a WGS, conceived as analogous to a JTC1 registered CD, 
isn't an archival document, it is more or less a formalization 
of a type of I-D, although perhaps one that doesn't 
automatically expire but instead survives until replaced or 
explicitly abandoned by the WG, and maybe it also expires when 
the WG is discontinued.

   john

--On Friday, 19 March, 2004 10:54 -0500 Scott Bradner 
<[email-masked]> wrote:

> Following up on the discussion in Korea, do people on this
> list think that defining a Working Group Snapshot (WGS) is a
> separable issue from defining a new standards track?
>
> i.e., do we have to wait until we have reached consensus on a
> new standards track before we can create a document that
> describes a WGS?
>
> This question assumes that there is consensus that the IETF
> should have something like a WGS.  I'm defining a WGS at a
> high level at this point - just saying that a Working group
> Snapshot is a way for a Working Group (with or without some
> level of IESG involvement) to anoint a particular pre-Proposed
> Standard RFC as something vendors who want to implement
> pre-Proposed Standard technology could implement.   I'm
> specifically not presupposing the answer to a number of
> questions including: what level of IESG involvement should
> there be in approving a WGS, what external review requirements
> might there be, is the WGS an archival document, is the WGS
> part of a new documentation series, etc - all of these issues,
> and more,  would be discussed while discussing a WGS document.
>
> specific questions:
>
> 1/ am I correct that there is some level of consensus in favor
> of a pre-Proposed Standard WGS?
>
> 2/ if so, is a WGS something that can be defined on its own or
> must it be defined at the same time (and in the same document)
> as a possible revised standards track?
>
>
> tnx
>
> Scott
> .
> newtrk
> resources:_____________________________________________________
> web user interface:
> http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc
> archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

.

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 19 Mar 2004 11:07:48 -0700 (MST)

> for Proposed Standard also.

Implementations are required to declare WGS? Then we would need a
pre-WGS state where implementations are not required but possible!

>> a WG assurance/opinion that ...

> relationship with the IESG.  For instance, an IESG member can
> essentially demand any change, even killing a document. The working
> group does not have enough control to make the suggested guarantee.

That is why I used an assurance/opinion pair. A WG says "as far as we
are concerned, this is stable/implementable/standardizable/whatever".
It is understood that IESG and other factors beyond WG control can
change the status and content of the draft. This is true for all WG
assurances/opinions.

From your responses, it feels like you want WGS to mean

  "If it were in this WG power, this version of the document
  would be published as an RFC. However, IESG and other factors
  outside of this WG control may change this document before it
  becomes an RFC and might even kill it".

Is that an accurate summary of what you want WGS to be? Note that "an
RFC" above implies that it could be a PS or an Informational or
Experimental RFC.

Thanks,

Alex.

P.S.

> By the way, I would also greatly prefer to change the requirement
> for Proposed Standard to require interoperability, and I never
> understood why it wasn't required.

My understanding is that you cannot require interoperability at the
first stage of a standard because there are no stable implementations
at that stage; vendors just started working on implementing stuff.
Unfortunately, PS status has changed from its intended/documented
meaning. That's why we are here, I guess.

.

---

From: "Charles E.Perkins" <[email-masked]>
Date: Fri, 19 Mar 2004 10:40:17 -0800

Hello again Alex,

> pre-WGS state where implementations are not required but possible!

I thought that it was implementation experience that
best shaped understanding and knowledge of the problem
space, thus leading to better protocol specifications.
Then, the shared experience produces ever better
specifications as more teams produce implementations.

> change the status and content of the draft. This is true for all WG

I thought the WG would be claiming that the WGS version
is stable enough and reasonable well understood.  It is
not an assurance that it is standardizable, but instead
an assurance that, working from the WGS, the working group
expects to produce a standardized protocol.

> RFC" above implies that it could be a PS or an Informational or

No, I don't mean that.  I mean that the working group has
WGS as a tool to indicate a relatively stable specification
from which a multiplicity of implementation and design teams
can base further development experiences.
 
> meaning. That's why we are here, I guess.

In the working groups I have been in, there have been
a good number of implementations long before Proposed
Standard.  It is expected that, before publication as
Proposed, the implementations are not fully stable.
As things are today, if Internet Drafts expire and
are replaced by different protocol specifications, it
may be difficult for a new team to justify implementation
at all.  I think that should be changed.

Regards,
Charlie P.
.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Mar 2004 11:08:34 -0800

Scott,

It looks as if quite a few of us chose to offer helpful changes to your
question and thereby derailed your query.

Let me suggest going back to your carefully-limited query, with a small
deletion from your original text, in order to try to avoid all of the
fine-tuning that we engineering types are so compulsive in offering:

SB> This question assumes that there is consensus that the IETF should have
SB> something like a WGS.  I'm defining a WGS at a high level at this point -
SB> just saying that a Working group Snapshot is a way for a Working Group
SB> (with or without some level of IESG involvement) to anoint a particular
SB> pre-Proposed Standard RFC [...].

SB> specific questions:

SB> 1/ am I correct that there is some level of consensus in favor of a
SB> pre-Proposed Standard WGS?

SB> 2/ if so, is a WGS something that can be defined on its own or must it be
SB> defined at the same time (and in the same document) as a possible revised
SB> standards track?

The critical text that I removed was "as something vendors who want to
implement pre-Proposed Standard technology could implement". I also
removed as well as the remainder of that paragraph, which had further
discussion, rather than the core information to consider.

The purpose behind removing it is to eliminate discussion about the
various ways a working group might use the label, so that the working
group can use it in multiple ways -- formal reviews, testing of
algorithms, prototype implementation, and so on.

In order to maintain some focus, responses to your query should be
either

      Yes to both questions

or

      No to question [1 or 2 or both] because...

As for my own 'vote':

Yes to both questions.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

.

---

From: Eric Rosen <[email-masked]>
Date: Fri, 19 Mar 2004 14:13:19 -0500

> I'm tired of  "we don't know what  problem this solves, but maybe  it is a
> good idea anyway" solutions 

Indeed.  I am reminded of the  recent discussion about our inability to kill
bad  ideas early.  Perhaps  before newtrk  takes this  on they  should first
produce a requirements document and a framework document. 

The  original problem  that was  posed  with regard  to the  standardization
process  is that we  seem to  have too  many categories.   So of  course the
solution proposed is "add another category".  Sigh.  

> A WGS is solid enough that there is some plausible level of WG 
> evolution is implausible. 

There  is very  little point  to establishing  a category  whose  meaning is
subtle  and replete  with  conditions.  No  one  will pay  attention to  the
nuances; if we have multiple  categories of document, the categories must be
simple, easy  to understand, and easy  to explain.  And  we certainly should
not assume that  there is any causal relation between  the category in which
we put a document and the disposition of a vendor to implement it.

.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 19 Mar 2004 10:48:39 -0800

Scott,

I'll only have an opinion on the second point at this time....

> defined at the same time (and in the same document) as a possible revised

If a WGS is an RFC, it changes a number of things including the load factor 
on the RFC-Editor and the meaning (if any) of the RFC "label" enough that I 
think it should be defined together with the "new model for 
standardization".

If a WGS is some other kind of publication, I think that:
1) it will have a big impact only if it's successful
2) it can be run as an experiment until we know if it's successful

So if you're willing to add "not an RFC" to your definition of a WGS, I 
tend towards saying that "this can be defined and experimented with 
independently of the model for standardization".

                       Harald

.

---

From: Scott W Brim <[email-masked]>
Date: Fri, 19 Mar 2004 15:08:09 -0500

We don't want a WGS process to slow down progressing a draft to proposed
(or whatever) standard.  Standard status is still just as important.
For this reason and other related ones I think WGS should be a WG issue,
separate from standards track issues, it should be optional for use only
if it advances the WG's goals, and that it can be explored separately.  

> >of a pre-Proposed Standard WGS?

No objection.  It could be a good tool.  

> >as a possible revised standards track?

It should be an optional tool for use by the WG to communicate the state
of a specification to the rest of the world and to encourage test
implementations.  WGs may use it, but I don't think it should be a
required step in the standardization process -- they can use it if it
helps *them* but should not be required to.  I wonder if the IETF as a
whole needs to do any more than define what a WGS is, stick the
definition somewhere referrable (when a WG declares a WGS), and be done.

> problem, I think if would be helpful if they would identify it.

I think that's a very different problem.  You're (expertly) addressing
the space of what happens when an idea becomes a work item.  I believe a
WGS addresses the time when the WG thinks it might be finishing a work
item, and wants to see more field testing.  How can the WG encourage
people to take a look at its product before it becomes a standard?

swb
.

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 19 Mar 2004 13:14:12 -0700 (MST)

On Fri, 19 Mar 2004, Dave Crocker wrote:

> SB> I'm defining a WGS at a high level at this point -
  or
        The proposed definition is not suitable to answer the
questions in a way that can be consistently interpreted by others.

IMHO, the discussion that followed already illustrated why yes (or no)
answer would mean very different things to different people. The
essential differences of WGS status compared to WG ID or RFC should be
clear before the two questions can be answered in a meaningful way.

Alex.
.

---

From: [email-masked] (Scott Bradner)
Date: Fri, 19 Mar 2004 15:32:52 -0500 (EST)

> So if you're willing to add "not an RFC" to your definition of a WGS,

'not an RFC' is what I had in mind

Scott
.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 19 Mar 2004 12:11:57 -0800

--On 19. mars 2004 11:08 -0800 Dave Crocker <[email-masked]> wrote:

> SB> 2/ if so, is a WGS something that can be defined on its own or must
> it be SB> defined at the same time (and in the same document) as a
> possible revised SB> standards track?
>
>

how is this different from "here's a blank check, please sign"?
I actually see some value in a status that is "not just an I-D, not an 
RFC", and some value in leaving it highly flexible, so, surprisingly, I 
tend to agree that leaving the check almost blank is a good thing.

anyway, my own answer is, of course, "none of the above":

1/ Not enough information available to answer that question.

2/ Yes - if a WGS is not an RFC.
   No - if a WGS is an RFC.

.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Mar 2004 14:21:54 -0800

Harald,

HTA> how is this different from "here's a blank check, please sign"?

In every possible way.

1) The thing it is producing is an explicit, but internal, coordination
event. The "currency" it is using is its own, internal reference, rather
than anything that is "national" (ie, IETF-wide). So, the usual model of
a check -- drawing from a private subset of a public pool -- does not
apply at all.

2) The working group is "signing" its own checks.

3) The working group specifies the purpose (amount) for the particular
use of the label. So to the extent that the check image applies, the
check is not blank.

But let's try this a different way:

How is this different from the working group sponsoring I-D's? is there
something that dictates what I-Ds they may have? I don't think so.

HTA> I actually see some value in a status that is "not just an I-D, not
HTA> an...

Each of us can see "some value" in all sorts of things.

However Scott was looking for a common base, rather than tweaking by
each of us.

d/

.

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 19 Mar 2004 15:33:28 -0700 (MST)

> However Scott was looking for a common base, rather than tweaking by

You are also tweaking though. As far as I can see, given comments
received so far, "a WG decides what WGS means" tweak is not a common
base.

Alex.
.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Mar 2004 15:19:26 -0800

AR> You are also tweaking though. As far as I can see, given comments
AR> received so far, "a WG decides what WGS means" tweak is not a common
AR> base.

indeed, i suggested _removing_ a qualifier, so there would be less
detail to debate. forgive me for thinking that that was quite different
from what folks were doing, namely to _add_ detail.

silly me.  when folks want to debate rather than look for consensus,
then debate is what we will have.

d/

.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 19 Mar 2004 15:14:52 -0800

> HTA> how is this different from "here's a blank check, please sign"?

Sigh. I was referring to the statement "I have not defined what a WGS is, 
but I want you to say whether you support it or not" - I wasn't attempting 
to call a WGS a blank check.

What I am trying to say is:

I think there's a sensible definition of WGS hiding in the discussion that 
is quite loose and quite useful - that means I could support the thing in 
principle, but I could still see definitions of WGS that I would object to.

                  Harald
.

---

From: John Leslie <[email-masked]>
Date: Fri, 19 Mar 2004 18:31:01 -0500

John C Klensin <[email-masked]> wrote:
> associated with what JTC1 calls a "Committee Draft" (CD)...
> The CD designation identifies something that is likely to
> eventually emerge as a product (standard or technical report)
> to be taken and studied seriously (for flaws, if nothing else)
> in its own right. 

   This idea hasn't exactly caught on so far; but I think John is
on the right track. (Though, obviously, a direct copy of JTC1 is
a non-starter. ;^)

> formal WG output. 

   Clearly a stronger statement is needed, but I think there's
strong support for publishing a WGS, based mainly on WG consensus
(without action by the full IESG or RFC Editor) when the WG agrees
that it is stable enough for external review and, barring gotchas
during external review or implementation experience, "is likely
to evolve into a standard".

   I don't believe most of us are willing to give every WG carte
blanche to declare "IETF WGS" status; but those details can be
worked out without creating more IESG work for each WGS.

> WG's should probably be encouraged to include in the WGS (or a
> statement about it) exactly what it does represent...

   Yes, there should be guidelines: details to be worked out.

> * The requirements for a WGS are

   No, John, let's not go into those details yet.

> explicitly abandoned by the WG, and maybe it also expires when 

   These also are details to be explored. A WGS could make sense
under the same expiration rules as an I-D, but probably deserves
somewhat different expiration rules.

>> separable issue from defining a new standards track?

   I believe we do, though we may wish to revisit some of the details
after designing a new standards track.

>> new standards track before we can create a document that

   IMHO, No.

>> of a pre-Proposed Standard WGS?

   It looks that way to me.

>> as a possible revised standards track?

   I believe we're ready to work on it on its own.

--
John Leslie <[email-masked]>
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 19 Mar 2004 16:33:40 -0700 (MST)

On Fri, 19 Mar 2004, Dave Crocker wrote:

> detail to debate.

In addition to removing a qualifier, you suggested that the definition
of WGS would be up to the WG. That's _adding_ (and a lot!) to the
debate you want to avoid.

Note that I am not saying that one-for-all WGS definition is better
that a WG-specific one. I am saying that we must know what WGS is
before we can answer questions about it in a meaningful way.
Moreover, we do not have to debate that definition. We can answer same
question for multiple conflicting definition already offered (FWIW).

Alex.
.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Mar 2004 15:36:04 -0800

Harald,

HTA> I think there's a sensible definition of WGS hiding in the discussion that
HTA> is quite loose and quite useful - that means I could support the thing in 
HTA> principle, but I could still see definitions of WGS that I would object to.

Let me try to rephrase (but not change) the definition I read in Scott's original
proposal, with the goal of making the definition simple and positive; it
leaves out qualifiers and other references:

SB>  a Working group Snapshot is a way for a Working Group
SB> [...] to anoint a particular
    [Internet Draft].

This does not declare a purpose and it does not say anything about RFCs
or standards track.  It defines a labeling technique for working groups
to use on internet drafts.

d/

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 19 Mar 2004 19:34:27 -0600

Just to answer Scott's question for myself...

----- Original Message ----- 
From: "Scott Bradner" <[email-masked]>
To: <[email-masked]>
Sent: Friday, March 19, 2004 9:54 AM
Subject: [newtrk] some questions about WGSs

> pre-Proposed Standard WGS?

I would like to see WGS available.

> 2/ if so, is a WGS something that can be defined on its own or must
it be
> defined at the same time (and in the same document) as a possible
revised

I would like to see WGS defined independently from the standards
track, primarily because I think we could figure out WGS in a lot less
time than we could figure out the standards track.

Spencer

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 19 Mar 2004 20:00:38 -0600

From: "Alex Rousskov" <[email-masked]>

> useful, it has to imply some essential difference between ID, WGS,
and

Alex is pointing out correctly that we are not discussing a draft...

I talked about WGS in Seoul (slides at
http://www.ietf.org/proceedings/04mar/slides/newtrk-1/index.html),
because I am interested in pulling the WGS writeup from
http://www.ietf.org/internet-drafts/draft-dawkins-pstmt-twostage-01.txt
and issuing it as a standalone individual draft.

Two reasons -

- There are a number of reasons why a WG might use WGS (mentioned in
the slides), and not all are related to the standards track, and

- The proposed charter for NEWTRK showed our milestone for forwarding
the revised standards track as May 05, and I believe that's a
realistic date, so I'd like to try something in the intervening year
and see if it's useful. We could end up discarding WGS based on
experience instead of debating.

I am looking for co-authors, so, if you don't find the slides too hard
to swallow, and would like to contribute text, please let me know.

Spencer

.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Mar 2004 09:07:26 +0100

I've gone round this in my head and in previous rounds of discussion with
Scott, and haven't got out of my worry loop yet. I still worry that blessing
the WGS designation would result after two or three years in an Internet
that runs on WGS documents rather than one that runs on PS documents, and
all we would have achieved is taking the IESG out of the approval loop for
the first step.

On the other hand, I worry about messy situations such as the implementation
status of Mobile IPv6, where it is hard to find two implementations that
are based on the same I-D. If the WG had been able to declare a couple of
snapshots along the way, the world would be a better place today.

> pre-Proposed Standard WGS?

I don't think we're there yet.
> defined at the same time (and in the same document) as a possible revised

No. WGS in effect adds a step. We could pretend that it isn't a "real" 
standards track step, but that would be self-delusion.

There is experimental evidence that we already have too many steps, i.e.
we use DS very little and Standard almost never. 

So I would only introduce WGS if we simultaneously eliminated two other steps,
reducing the total number of steps from 3 to 2.

   Brian
.

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 24 Mar 2004 07:43:54 -0500

I concur with Brian...

I share Brian's concern about any definition of WGS that does not 
involve some level of cross-area review and approval.  I also agree 
with his statemet that there have been cases where a lighter-weight 
document publication mechanism would have made things better.

I also agree with Brian that a WGS as one step in the overall 
standards track, so it shouldn't be considered separately.

I don't see the value in developing a new archival document series 
when we already have one (the RFCs).  If the problem is that we have 
raised the bar too high for publication at PS, we should lower the 
bar (which may involve changing the name to avoid confusion regarding 
the status of current PS documents).  Removing the bar altogether 
would not, IMO, be wise.

Margaret

.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Mar 2004 07:03:19 -0800

BEC> I've gone round this in my head and in previous rounds of discussion with
BEC> Scott, and haven't got out of my worry loop yet. I still worry that blessing
BEC> the WGS designation would result after two or three years in an Internet
BEC> that runs on WGS documents rather than one that runs on PS documents

Over time, the IETF has institutionalized the concept of a "working
group" Internet Draft.  It now requires formal approval of the working
group to have an I-D listed as draft-ietf-<wg name>-*.

WGS is designed to be used in a related manner, for wg internal
coordination.

Working group draft has not suffered the kind of abuse you fear for WGS,
so why is there such concern about WGS?

On reflection, one way to make sure that it _does_ suffer that global
mis-use is to raise the bar for assigning the label.  Give it added
requirements, such as cross-area review, and folks will treat it as a
more formal and external event.

(And, by the way, requiring it to have cross-area review ensures that it
cannot be used as a reference point for _soliciting_ cross-area review.)

We really do need to stop being quite so parental and paranoid about
working groups and about the rest of the community. And we definitely
need to stop fearing that someone, somewhere, will "abuse" IETF work.

We need to focus on the clarity and direct utility of proposals, rather
than hypothetical concerns about hypothetical abuses.

BEC> , and all we would have achieved is taking the IESG out of the
BEC> approval loop for the first step.

This appears to be looking for an IETF-wide labeling change. WGS is not
it. It is defined to fill the need for various working group internal
coordination requirements.

BEC> So I would only introduce WGS if we simultaneously eliminated two other steps,
BEC> reducing the total number of steps from 3 to 2.

WGS is not a standards-track mechanism, any more than Experimental and
Informational are.  It serves very different purposes, although
sometimes it will no doubt show up in a standard-track sequence (as
does, for example, Experimental or "working group I-D".

MW> I don't see the value in developing a new archival document series 
MW> when we already have one (the RFCs).  If the problem is that we have 

WGS is not calling for a new archival document series.

d/

.

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 24 Mar 2004 10:59:39 -0500

Hi Spencer,

>and issuing it as a standalone individual draft.

Sorry, I couldn't attend the newtrk meeting in Seoul due to a 
conflict.  However, I have read your slides, I am quite interested in 
the idea of a WGS, and I believe that it could be useful.

When do you think that you will have a draft available?  I think that 
we could have a much more productive discussion if we were discussing 
a particular draft, even if the draft includes some open 
issues/questions.

Margaret

.

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 24 Mar 2004 10:46:54 -0500

Hi Dave,

Are you certain that your use of the term "WGS" matches Scott's use 
of the term?  There seem to be some major differences.

Two examples:

At 7:03 AM -0800 3/24/04, Dave Crocker wrote:
>WGS is designed to be used in a related manner [to WG drafts], for wg internal
>coordination.

At 10:54 AM -0500 3/19/04, Scott Bradner wrote:
>a Working group Snapshot is a way for a Working Group

At 10:54 AM -0500 3/19/04, Scott Bradner wrote:
>I'm specifically not
>part of a new documentation series, etc.

So, it appears (to me anyway) that Scott is asking questions about a 
much broader set of potential definitions for the term "WGS" than you 
(Dave) are considering in your response to Brian and me.

Scott's message issued two consensus calls: (1) Do we have consensus 
in favor of a pre-Proposed Standard WGS? and (2) Can it be defined on 
its own, independent of standards track changes?

For me, the answers to both of these questions depend heavily on the 
answers to some of the questions to which Scott is explicitly _not_ 
presupposing answers... such as: What problem is a WGS intended to 
solve? What is the intent of a WGS -- inter-WG coordination, 
anointing a draft for vendor implementation, something else? What 
level of IESG (or other cross-area) involvement will there be in 
approving a WGS, if any?  Is a WGS an archival document, or will it 
expire like current I-Ds?  Will it be an I-D, an RFC or something 
else altogether?  I would expect a concrete WGS proposal to answer 
all of these questions.

Without these answers, I don't know how we can form consensus that a 
WGS is needed, or that it could be defined separately from a new 
standards track...

Margaret

.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 24 Mar 2004 08:11:33 -0800

I generally concur with Brian here.

To me, this whole WGS idea is something which WG chairs could
today implement without any formalization.  They can simply
by e-mail or by external WG website or other means communicate
to the WG which I-Ds are ready for early implementation.  I
think there is real danger in attaching any formal status to
such communication as it will further weaken the "a work in
progress" nature of an Internet-Draft.

.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Mar 2004 08:42:47 -0800

Margaret,

MW> Are you certain that your use of the term "WGS" matches Scott's use
MW> of the term?  There seem to be some major differences.

sigh, alas, yes there does.

That's why there was an earlier thread trying to clarify that point and
remove the problematic clause from Scott's original query.

MW> At 10:54 AM -0500 3/19/04, Scott Bradner wrote:
>>I'm specifically not
>>presupposing the answer to a number of questions including

In other words, he is not calling for an archival document series.

MW> For me, the answers to both of these questions depend heavily on the
MW> answers to some of the questions to which Scott is explicitly _not_ 
MW> presupposing answers... such as: What problem is a WGS intended to 
MW> solve? What is the intent of a WGS -- inter-WG coordination, 
MW> anointing a draft for vendor implementation, something else?

"WGS" is defined in
http://www.ietf.org/internet-drafts/draft-dawkins-pstmt-twostage-01.txt:

     2.1. Working Group Snapshot (WGS)
     
     The Working Group Snapshot (WGS) label can be affixed to an
     Internet-Draft, for working group synchronization.

MW> What 
MW> level of IESG (or other cross-area) involvement will there be in 
MW> approving a WGS, if any?

     A working group can issue a WGS at any time, and does so by
     notifying the IESG of their intention to issue a WGS as the
     *next* revision of an Internet-Draft.
     
     The IESG has up to 1 month to supply additional text that is
     added to an "IESG Comments" section of the document. It may
     not delay or veto issuance of a WGS. Therefore, IESG
     involvement is not for "approval" but rather to permit
     formal, outside comments to be affixed to the draft.

MW> Is a WGS an archival document, or will it 
MW> expire like current I-Ds?  Will it be an I-D, an RFC or something 
MW> else altogether?

     The document is subject to all normal I-D rules.

MW> I would expect a concrete WGS proposal to answer 
MW> all of these questions.

me too.  good thing the proposal that defines "wgs" does that.

d/

.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Mar 2004 18:00:34 +0100

Dave Crocker wrote (among other things):

> WGS is not a standards-track mechanism

This subtlety will be invisible from the outside. I assert that effectively
it will become a step in the standards process, when the industry's use
of the IETF's work product is considered. That doesn't mean it's a bad thing, 
of course.

   Brian
.

---

From: John C Klensin <[email-masked]>
Date: Wed, 24 Mar 2004 12:29:11 -0500

Dave,

For whatever my opinion is worth, the style and direction of 
this discussion makes me nervous.

It feels like there are at least three definitions of "WGS" 
floating around in people's minds.   Those are

	(i) The somewhat out-of-context excerpt from
	draft-dawkins-pstmt-twostage-01.txt a document that, in
	context, is about a standards-track change with WGS
	being part of that change.  I think Brian's observation
	that it will be construed as a standards-track step is
	correct.  That triggers concerns about cross-area review
	and, for me, makes it something I don't think can really
	be considered without poking at the standards track.
	
	(ii) My reading/suggestion, drawn from a variation on
	the ISO/IEC JTC1 "Committee Draft" concept.   I _think_
	it is a little lighter weight, and perhaps a bit
	earlier, than the WGS of (i).  Certainly it doesn't
	involve sitting around for a month while the IESG
	figures out whether to attach notes: the only
	requirement is WG consensus, asserted by the WG Chair
	and signed off on by the responsible AD.
	
	(iii) Several other ideas, or variations on the above
	that I don't understand well enough to characterize.

With regard to Scott's questions, I think it is possible to 
believe that the second can be done without work/ agreement on 
the standards track, while the first one cannot.  The reverse, 
or other combinations, may also be true.  And I think it is 
possible to be sympathetic to one or more (perhaps _any_ one or 
more) of these definitions/ models while having deep 
reservations about the others.

With the "problematic clauses" removed from Scott's query, it 
feels to me as if we are being asked to agree to a name or broad 
concept, with unspecified semantics.  That doesn't seem wise to 
me, even as a question.

Because of those ambiguities about what I'm expected to "vote" 
on, if I've forced to "vote", I'd have to say "no, I'm not 
convinced that it can be done independently of working on the 
standards track" and "no, I'm not convinced that there is 
consensus on a near-enough approximation to one proposal".

That doesn't seem to be a good way to make progress, so perhaps 
a little more of the discussion of details and of exactly what 
we are talking about (to which you seem to be objecting) is in 
order.

     john

--On Wednesday, 24 March, 2004 08:42 -0800 Dave Crocker 
<[email-masked]> wrote:

> Margaret,
>
>
> MW> Are you certain that your use of the term "WGS" matches
> Scott's use MW> of the term?  There seem to be some major
> differences.
>
> That's why there was an earlier thread trying to clarify that
> point and remove the problematic clause from Scott's original
> query.
>...

.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Mar 2004 09:34:41 -0800

Brian,

>> WGS is not a standards-track mechanism

BEC> This subtlety will be invisible from the outside. I assert that effectively
BEC> it will become a step in the standards process, when the industry's use
BEC> of the IETF's work product is considered. That doesn't mean it's a bad thing, 
BEC> of course.

That's just plain wrong.

I-Ds are not standards-track.  As many problems as there are or might
be, surrounding I-Ds, they are not realistically confused with standards
track.  Do some people get it wrong?  Sure.  Is it a realistic problem?
No!

Therefore an assertion that a working group internal labeling even for
an I-D will somehow be confused by the unwashed masses involves more
biased fantasizing than is appropriate for a process design discussion.

Once again:  We need to be clear and careful with how we define and run
things.  We do _not_ need to be parental in our fears that someone,
somewhere, will misunderstand what we have done.

d/

.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Mar 2004 10:03:16 -0800

John,

JCK> 	(i) The somewhat out-of-context excerpt from
JCK> 	draft-dawkins-pstmt-twostage-01.txt a document that, in
JCK> 	context, is about a standards-track change with WGS
JCK> 	being part of that change.

The WGS portion of that document is entirely separable and is in the
process of being moved to a separate document. Yes, having it in the
broader document has turned out to be confusing, though the rationale
for combining the details made sense at the time. Anyhow, that concern
is easily fixed.

JCK>  I think Brian's observation
JCK> 	that it will be construed as a standards-track step is
JCK> 	correct.

Unless the IETF has now moved to voting on abstract fears and somehow
then claiming that that is a sound basis for designing a standards
process, there needs to be a sound basis offered for such assessments.

JCK> 	.  Certainly it doesn't
JCK> 	involve sitting around for a month while the IESG
JCK> 	figures out whether to attach notes: the only
JCK> 	requirement is WG consensus, asserted by the WG Chair
JCK> 	and signed off on by the responsible AD.

Personally, I'm just as happy to have no IESG involvement. The reason
that coordination step was added to the proposal was as a consideration,
to _allay_ fears of wayward working group actions.

Silly me. I forgot that in the IETF, any proposal for action is always
subject to an equal and opposite fear of action.

JCK> With the "problematic clauses" removed from Scott's query, it
JCK> feels to me as if we are being asked to agree to a name or broad 
JCK> concept, with unspecified semantics.

The semantics are defined in the proposal:

Is this a general-purpose mechanism?  Sure?  Is that a problem?  No more
than draft-ietf-<wgname> is a problem.  No more than deciding to issue a
revised I-D is a problem.

Both of these are formal, public working group actions. Yet they cause
none of the horrible problems that people are fearing for WGS.

KDZ> To me, this whole WGS idea is something which WG chairs could
KDZ> today implement without any formalization.

The fundamental truth and implication of this observation is being
missed. It serves to underscore why the label is not nearly as momentous
a problem as it is being cast.

d/

.

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 24 Mar 2004 13:14:02 -0500

Hi John,

Your most recent message reminded me of this post, which I had meant to respond
to earlier.

First, let me say that, in general, I like this definition of a WGS 
better than the one in draft-dawkins-pstmt-twostage-01.txt.

>associated with what JTC1
>calls a "Committee Draft" (CD) and adapt it (those who were in, or 
>listened to, one of my
>tirades in Seoul should note this suggestion and its origins).   In 
>JTC1, WGs fling all sorts
>of numbered documents around as well as meeting and email 
>conversations.  The CD
>designation identifies something that is likely to eventually emerge 
>as a product (standard
>  or technical report) to be taken and studied seriously (for flaws, 
>if nothing else) in its own
>right.  A CD is far enough along that the WG believes that
>

I think that this qualification is important and seems to be missing 
from other proposals.

[...]

>Explanation of the "signoff" requirement:  I expect that ADs will, 
>at a minimum, know which
>WGs are in trouble, behaving badly, having consensus problems, etc. 
>I believe that is
>generally the case today, whether action is being taken or not. If a 
>WG Chair sends a note
>  to the AD that says "we are going to make draft-xxx-yyy... a WGS" 
>and the WG is generally
>in good shape, I'd expect the AD to either send best wishes or to 
>sleep through the
>announcement (and I don't think we should prefer one over the 
>other).  If, by contrast, the
>WG is problematic in one way or another, I'd expect the AD to assure 
>him or herself that
>the claim of consensus is plausible before issuing a "go ahead", or 
>going back to sleep,
>or requesting somewhat more process.

This seems reasonable to me.

I don't like the pstmt-twostage I-D's one month waiting period for an 
IESG note...  It has
three problems:  (1) the one month waiting period, (2) it involves 
the whole IESG and
(3) even if the IESG thinks there are serious problems with a draft, 
the WG can publish
it as a WGS and recommend implementation...  thus potentially 
exacerbating an already
bad situation by encouraging people to implement something that we 
know won't be
approved as a standard.

This mechanism would have another beneficial side-effect in my 
opinion -- it would
encourage the responsible AD to review the document when it is 
proposed as a WGS,
thus lessening the likelihood that the document will be the subject 
of "late surprises" in
the AD evaluation stage.

Or course, an ADs decision to approve or refuse publication of a WGS should be
subject to appeal, just like any other AD decision.

Margaret

.

---

From: "Charles E.Perkins" <[email-masked]>
Date: Wed, 24 Mar 2004 10:25:38 -0800

Hello Brian,

Brian E Carpenter wrote:

> of the IETF's work product is considered.

That's setting up the strawman.

>           That doesn't mean it's a bad thing,
> of course.

It's bad because it makes a strawman that can then
be knocked over.

I can envision the following chain of implication:
WGS is standards-track
	==> need for thorough external review
        ==> need for external approval
        ==> danger of being viewed as de-facto standard
        ==> severe impairment to WG progress

I have pointed out several reasons why there is a real
need for WGS, and my examples do NOT need WGS as
standards-track.

Thus, I assert we should not position WGS as standards-track.

Regards,
Charlie P.
.

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 24 Mar 2004 13:42:49 -0500

Hi Dave,

>none of the horrible problems that people are fearing for WGS.

In order for a WGS to be a useful construct, it has to be _different_ 
from a WG I-D and it has to be different from a Proposed Standard. 
My understanding is that we are talking about something that would 
like between the two...

This raises some basic questions:

What is the purpose of a WGS?  And, why isn't this purpose met by WG I-Ds?

This let's us understand what problem we are trying to solve and may 
give us some indication of what properties a WGS should have.

Examples of problems that aren't solved the WG I-Ds might be: 
Reviewers aren't certain what WG documents are worthy of in-depth 
review, WGs produce too many drafts in a short period causing 
confusing amongst vendors, vendors don't have enough confidence in 
the stability of WG I-Ds to implement them.

Examples of desirable properties might be:  longer-lived, more likely 
to become a standard as written, well reviewed, having passed certain 
types of review/approval, etc.

Depending on what problems we are trying to solve, WGS might or might 
not be the right tool.

For example, I have often thought it might be useful if every version 
that is published as a "WG I-D" were explicitly approved as a WG 
document.  For instance:

In today's process,  I publish draft-wasserman-foo-good-idea-00.txt 
and sumbit it to the foo WG for consideration. Based on discussion, I 
publish -01 and -02 versions, and the -02 version is accepted as a WG 
work item (draft-ietf-foo-good-idea-00.txt).

Later, if I have some new ideas and I update this document.  As it 
works today, I publish those new ideas as a WG document -- 
draft-ietf-foo-good-idea-01.txt.  I can do this without WG chair 
approval, and I can include things that have not been discussed by 
the WG or decided by WG consensus.  Using this process, we can (and 
do) end-up with WG drafts, some of the contents of which have never 
achieved WG consensus.

What if I had to submit my new ideas as draft-wasserman-foo-*, 
instead?  Only moving them to draft-ietf-foo-* when they have 
received WG consensus?  I know that this would run into trouble with 
our current numbering scheme, but the fact that all documents have to 
be numbered from -00 based on draft name is merely an internal 
secretariat convention, not a natural law.  So, I think we could 
change it...

Or, maybe we could keep our current I-D naming/numbering conventions 
and use a new convention (WGS) for the WG to tag I-Ds that it 
believes have WG consensus?  Using the above example, the WG could 
produce a series of IDs called draft-ietf-foo-wgs-good-idea-xx.txt 
which would be WGS documents.  In between, incremental updates could 
be published as draft-ietf-foo-good-idea-xx.txt, with only those 
documents that receive explicit WG approval being published as 
draft-ietf-wgs-foo-*.

If that's what we want to use WGS for, then I would support the idea. 
However, I would not support representing that version of WGS as a 
document that is any more stable or likely to be standardized in its 
current form than any other WG draft.  The only promise would be that 
the WGS versions do represent WG consensus, while the 
draft-ietf-wgname documents might not.

Margaret

.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Mar 2004 11:16:02 -0800

Margaret,

MW> In order for a WGS to be a useful construct, it has to be _different_
MW> from a WG I-D and it has to be different from a Proposed Standard. 
MW> My understanding is that we are talking about something that would 
MW> like between the two...

No we are talking about a _label_ that is affixed to an Internet-Draft.

Note that Internet Drafts do not all "belong" to a working group.  In
fact, the ability to have an I-D contain "draft-ietf-<wgname>-*" has
become a formal step, requiring working group "adoption" of the effort
to develop that I-D.

WGS is another, similar, labeling technique.  Rather than have the label
reflected in the name of the document, it is a separate label.

MW> What is the purpose of a WGS?  And, why isn't this purpose met by WG I-Ds?

internal working group coordination, as the proposal says.

real-world examples include reviewing a common version or doing test
implementations of a common version.

MW> This let's us understand what problem we are trying to solve and may 
MW> give us some indication of what properties a WGS should have.

Indeed.  That's why it has been stated many times.

MW> Examples of problems that aren't solved the WG I-Ds might be: 
MW> Reviewers aren't certain what WG documents are worthy of in-depth 
MW> review, WGs produce too many drafts in a short period causing 
MW> confusing amongst vendors, vendors don't have enough confidence in 
MW> the stability of WG I-Ds to implement them.

ok.

MW> Examples of desirable properties might be:  longer-lived,

no.

MW> more likely to become a standard as written,

in some cases, perhaps.

MW> well reviewed, having passed certain types of review/approval, etc.

in some cases, perhaps.

MW> Later, if I have some new ideas and I update this document.  As it
MW> works today, I publish those new ideas as a WG document -- 
MW> draft-ietf-foo-good-idea-01.txt.  I can do this without WG chair 
MW> approval, and I can include things that have not been discussed by 
MW> the WG or decided by WG consensus.

You can get the IETF Secretariat to issue the revision without formal WG
coordination/approval, yes.

However, you cannot make changes without WG approval. Once a document is
a wg document, it is subject to wg rough consensus. This has always been
true.

If we have a problem with authors running rogue, adding the bureaucratic
step of always requiring wg chair approval for issuing the next I-D
revision does not begin to solve the problem. It just adds hassle for
every version of every I-D.

MW> Using this process, we can (and 
MW> do) end-up with WG drafts, some of the contents of which have never 
MW> achieved WG consensus.

Yeah, it's a terrible thing to have a system that ever permits people to
act inappropriately.

However it is a worse system to try to anticipate every mis-behavior and
invent masses of bureaucracy to prevent them, whether they happen
regularly or not, and whether their effects are serious or not.

MW> What if I had to submit my new ideas as draft-wasserman-foo-*,

What if we tried to solve real and pressing problems?

There is already rather serious stuff on our plate.

MW> Or, maybe we could keep our current I-D naming/numbering conventions 
MW> and use a new convention (WGS) for the WG to tag I-Ds that it 
MW> believes have WG consensus?  Using the above example, the WG could 
MW> produce a series of IDs called draft-ietf-foo-wgs-good-idea-xx.txt 
MW> which would be WGS documents.

Part of the goal, here, was to streamline things, rather than make them
ever-more cumbersome.

MW> However, I would not support representing that version of WGS as a
MW> document that is any more stable or likely to be standardized in its 
MW> current form than any other WG draft.

Excellent!

None of the text promises or implies either of those things.

d/

.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 24 Mar 2004 14:19:25 -0800

>become a formal step, requiring working group "adoption" of the effort

I note WG I-Ds need not be named "draft-ietf-<wgname>-...", a chair
can have any I-D be considered a WG draft (by sending e-mail to the
secretariat) and, in doing so, have it appear on the WG web page as such.

And, in reverse, not all drafts named "draft-ietf-<wgname>-..." are
WG drafts.  The WG could have abandoned the draft (advising the secretariat
that its no longer a WG I-D and, hence, no longer to be listed on the
WG web page) or the WG could have been concluded and individuals are
just continuing to use the old file name in their individual pursuit
of RFC publication.

The way to know for sure that a I-D is a working group draft
is to visit the WG web page, the data tracker, and possible other
IETF-produced web pages that distinguish I-Ds by true ownership.
That is, you cannot rely on the label as a status indicator.

>reflected in the name of the document, it is a separate label.

Okay.  But the question is what semantics, especially those governing
the progression of the draft through the standards process, are attached
to that label.

>internal working group coordination, as the proposal says.

Okay, so in terms of the formal standardization process, none.

>coordination/approval, yes.

Yes, but the chair can ask the secretariat that the I-D is no longer
a WG I-D.  Another option is for the chair to ask the secretariat to
expire the I-D early.

>regularly or not, and whether their effects are serious or not.

Yes... or to formalize communications when informal communications can
and should be sufficient.

This, to me, is kind of like the communication problem we had recently
with the I-D tracker.  Seemed ADs began to assume that simply updating
a label in the tracker was communication of an event and hence stopped
sending e-mail notices as they did previously.  Now we have automatic
notification here.

So, I wonder, if chairs start to rely on this label mechanism instead
of using existing communication mechanisms, we'll we see the need
to add automatic notification to the label management system?  And
if so, how will we achieve automatic notification?

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 24 Mar 2004 20:59:30 -0600

Sorry, I thought I'd sent this to the list - but sent it only to
Brian. Resending...

................

Brian,

Nice summary. A couple of comments inline.

From: "Brian E Carpenter" <[email-masked]>

The next two paragraphs should probably appear in the Security
Considerations section of any WGS draft...

> > 2/ if so, is a WGS something that can be defined on its own or
must it be
> standards track step, but that would be self-delusion.

Umm, maybe. I listed a bunch of reasons for WGS just before Seoul. I
got mostly-positive feedback (in principle) based on face-to-face
conversations in Seoul, but we haven't had any discussion on the
mailing list. There were reasons that smelled like standards track
steps, and reasons that didn't ("this TCP proposal is stable enough to
ask the research community for simulations", for example).

What I was proposing in Seoul was that WGS was not a standards-track
step, but could be used by a WGS for any purpose, or not used at all.
That was my intent in saying that each WGS had to state its purpose,
so if the WGS said, "we're doing a WGS to send the protocol for
architectural review", this might provide some direction that burning
the protocol into ROM was premature.

My presentation is available at
http://www.ietf.org/proceedings/04mar/slides/newtrk-1/index.html. The
specific slide is
http://www.ietf.org/proceedings/04mar/slides/newtrk-1/sld3.htm. And
yeah, I know this isn't an Internet Draft yet - I was waiting for
feedback to Scott's question before writing it up. (Thank you for
providing feedback)

(... and John Loughney's presentation is available at
http://www.ietf.org/proceedings/04mar/slides/newtrk-2/index.html)

> reducing the total number of steps from 3 to 2.

I agree with the sentiment, only noting that we are unlikely to
"simultaneously" change the standards track in 2004, so
"simultaneously" would prevent us from gaining real-world experience
with WGS before it's codified - the proposed charter puts our target
date for forwarding our proposal to the IESG in May 2005.

.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Mar 2004 10:33:17 +0100

Charlie,

My assertion is not that we will position WGS as standards track. It's
that anywhere further than a kilometer from the IETF meeting hotel,
other people (such as product development managers) will treat a WGS as a 
stable spec they can have people implement. Which is how they treat a PS RFC
today.

And I didn't say that would be a bad thing. But to me it only makes sense
if we simultaneously abolish one or two levels in the standards track,
to make the whole system simpler instead of more complicated.

So I can't separate Scott Bradner's two questions.

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 25 Mar 2004 05:56:12 -0600

Hi, Margaret,

We put together a WGS draft with some changes from the text that
appears in draft-dawkins-pstmt-twostage-01.txt. It should be announced
shortly.

Thanks for asking,

Spencer

From: "Margaret Wasserman" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>;
<[email-masked]>
Sent: Wednesday, March 24, 2004 9:59 AM
Subject: Re: [newtrk] some questions about WGSs

> Hi Spencer,
[]

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 25 Mar 2004 07:34:58 -0600

Hi, Margaret,

Thanks for the questions - let's wait for the draft to be announced
and talk then, OK?

Thanks,

Spencer, who now understands the difference between idea and draft a
little more clearly...

----- Original Message ----- 
From: "Margaret Wasserman" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>;
<[email-masked]>
Sent: Thursday, March 25, 2004 7:07 AM
Subject: Re: [newtrk] some questions about WGSs

> How are you picturing that this would work?
>
> Let's say that the foo WG has an I-D called
> draft-ietf-foo-good-idea-07.txt that it wants to make a WGS.  Let's
> further assume that it has been through whatever WGS approval
process
> we define and that it is ready for publication as a WGS...
>
> Would there be a new version of the draft
> (draft-ietf-foo-good-idea-08.txt) published that includes text
inside
> the document that states that this is a WGS and includes an
> explanation of the purpose of the WGS?  Or would you expect the tag
> to be external to the document -- perhaps something on the WG's web
> page?
>
> And, how would a WGS expire?  Automatically after six months?  When
> the WG produces draft-ietf-foo-good-idea-n+1.txt (whether or not
that
> version is a WGS)?  When the next WGS is published?  Only when the
> chair or AD requests expiration?
>
> The reason that I had sort of assumed that we would use a different
> naming convention (draft-ietf-foo-wgs-good-idea-nn.txt) is that this
> would provide a set of WGS documents that are separate from WG I-Ds.
> Unless we made other changes, they would still expire in six months
> or when a new WGS is published, but they wouldn't automatically
> expire when a new WG draft is published.  For example, if
> draft-ietf-foo-good-idea-07.txt was re-published (perhaps including
> an explanation of the purpose of the WGS) as
> draft-ietf-foo-wgs-good-idea-00.txt, the WG could publish several
> more iterations of draft-ietf-foo-good-idea-nn.txt before choosing
to
> update/expire the WGS by publishing one of those new drafts as
> draft-ietf-foo-wgs-good-idea-01.txt...
>
> I know that I made this suggestion earlier and Dave Crocker
indicated
> that I wasn't discussing a serious issue.  But, I do think that
_how_
> we label WGS documents and how/if they are expired/obsoleted by
other
> documents should be  clearly understood for any WGS proposal.  I
also
> consider it an important practical consideration to build a WGS
> system that minimizes impact on our secretariat, IESG and RFC editor
> procedures and tools.
>
> I support the concept of experimenting with WGS before making other
> changes to the standards track, which isn't exactly the same thing
as
> saying that we can define WGS independently of the standards track
> changes...
>
> Margaret
>

.

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 25 Mar 2004 08:07:06 -0500

Hi Spencer,

Let's say that the foo WG has an I-D called 
draft-ietf-foo-good-idea-07.txt that it wants to make a WGS.  Let's 
further assume that it has been through whatever WGS approval process 
we define and that it is ready for publication as a WGS...

(draft-ietf-foo-good-idea-08.txt) published that includes text inside 

And, how would a WGS expire?  Automatically after six months?  When 
the WG produces draft-ietf-foo-good-idea-n+1.txt (whether or not that 
version is a WGS)?  When the next WGS is published?  Only when the 
chair or AD requests expiration?

more iterations of draft-ietf-foo-good-idea-nn.txt before choosing to 

I know that I made this suggestion earlier and Dave Crocker indicated 
that I wasn't discussing a serious issue.  But, I do think that _how_ 
we label WGS documents and how/if they are expired/obsoleted by other 
documents should be  clearly understood for any WGS proposal.  I also 
consider it an important practical consideration to build a WGS 
system that minimizes impact on our secretariat, IESG and RFC editor 
procedures and tools.

I support the concept of experimenting with WGS before making other 
changes to the standards track, which isn't exactly the same thing as 
saying that we can define WGS independently of the standards track 
changes...

Margaret

.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Mar 2004 15:55:31 +0100

Well, I'd like to comment on the WGS proposal in the context of the
current draft.

As I said in my answer to Scott Bradner, I don't want to see WGS
introduced without simultaneously reducing the number of formal
standards track stages. The argument is that we need to make things
simpler, not more complicated.

And I would suggest that the two conditions for declaring a WGS should
not be

>           a)   Achieves ôrough consensusö based on a Working
>                Group Last Call
>           
>           b)   May receive IESG comment

but rather
          
          a)   MUST have received cross-area review outside the WG
               judged to be adequate by the WG Chair(s)

          b)   MUST have received rough consensus based on a Working
               Group Last Call

So, take the IESG out of the loop but oblige the Chairs to get the thing
widely reviewed.

The other comment is that since a) and b) would be WG Chair judgement
calls, both a) and b) should be appealable to the AD etc.

I would still prefer to roll PS and IS into a single stage called
IETF Specification, with parallel publication of interoperability
claims. But I could just about live with WGS plus PS plus IS.

The draft needs to define how existing PS, DS and Standard documents
are grandfathered into the new scheme.

  Brian

.

---

From: Scott W Brim <[email-masked]>
Date: Thu, 25 Mar 2004 10:20:07 -0500

On Thu, Mar 25, 2004 10:33:17AM +0100, Brian E Carpenter allegedly
wrote:
> other people (such as product development managers) will treat a WGS
> as a stable spec they can have people implement. Which is how they
> treat a PS RFC today.

Undoubtedly, even in those meanings of WGS where that is not intended.
WGS is a good idea iff it doesn't slow down moving things to some level
of standard.

> And I didn't say that would be a bad thing. But to me it only makes
> sense if we simultaneously abolish one or two levels in the standards
> track, to make the whole system simpler instead of more complicated.

We should do that anyway.

The two issues are decoupled.  WGS is a useful concept within a working
group that might want to declare a level of consensus to the outside
world.  Reducing the number of standards stages has virtue for
completely separate reasons.

swb
.

---

From: Eric Rosen <[email-masked]>
Date: Thu, 25 Mar 2004 10:28:37 -0500

Dave> As many problems as there are  or might be, surrounding I-Ds, they are
Dave> not realistically confused with standards track. 

Oh?   Any time a  WG takes  any action  which can  possibly be  construed as
endorsing a particular i-d,  the corporate marketing machines start churning
out the message that the i-d is  a standard, and that only a few formalities
remain.  As a result, there is often a lot of argument about whether a draft
should become a WG draft. 

Adding another category of endorsement  would just add another thing for the
WG to  argue about, as  it considers who  benefits and who doesn't  from the
marketing propaganda that is sure to result. 

Perhaps this  perspective reflects my experience  that it is  even harder to
navigate the corporate  clash of interests in  the WG than it is  to get the
IESG  to approve  something.   There's nothing  "abstract" or  "speculative"
about this worry.

We should be simplifying the WG process, not complicating it. 

.

---

From: Keith Moore <[email-masked]>
Date: Fri, 26 Mar 2004 10:43:14 -0500

> So, take the IESG out of the loop but oblige the Chairs to get the 

I can't imagine that this could be sufficient.  WG chairs have far too 
much incentive to skimp on cross-area review, and I've seen too many WG 
chairs deliberately exclude outside input.  Having the WG be its own 
judge of what is adequate is completely unacceptable.

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sat, 27 Mar 2004 15:00:04 -0600

Just to follow up on a statement that is true, but sometimes truth
doesn't matter..

Spencer

From: "Kurt D. Zeilenga" <[email-masked]>
Sent: Wednesday, March 24, 2004 4:19 PM
Subject: Re: [newtrk] clarifying WGS

> secretariat) and, in doing so, have it appear on the WG web page as
such.

Steve Coya used to make this point in WG chairs training, and it is
true, and I wish that WGs adopted individual drafts without changing
the name, but ...

I've gotten pretty serious pushback, including pushback from IESG
members, saying "there are WAY too many drafts announced for me to
even read abstracts - if I see a draft-ietf-WG announcement for a WG
I'm following, I'll keep reading".

So WG drafts that aren't named draft-ietf-WG are rare enough to
startle most people, and that makes using this capability even less
attractive.

Too bad, because sites like http://bgp.potaroo.net/ietf/indexb.html
have terrific version-by-version difs "all the way back" - to when the
name changed, but it's a work of archeology to figure out the path
that a document that started out as an individual draft, got adopted
by MPLS, and then moved to CCAMP (for example) took on its way to RFC.
But that's just the way things work these days.

Changing the name also more explicitly marks the transition from
individual draft under author change control to working group draft
under working group change control, which is a big deal in both the
current WG chair training and editor training (although changing or
not-changing names isn't mentioned explicitly in either, now that I
look at the slides on http://edu.ietf.org more carefully).

Spencer

.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 28 Mar 2004 11:03:58 +0200

Keith,

> judge of what is adequate is completely unacceptable.

I've been backward and forward on that. But either we delegate more trust
to WG Chairs, or we don't. If we don't, how do we get rid of the IESG
bottleneck?

    Brian

.

---

From: Keith Moore <[email-masked]>
Date: Tue, 30 Mar 2004 09:45:46 -0500

>>> So, take the IESG out of the loop but oblige the Chairs to get the
>>> thing widely reviewed.
>>

IMHO the IESG bottleneck is overrated.  But I'll get back to that in a 
separate message.

I think that when a WG is chartered, IESG (or maybe IAB?) needs to 
specify the points/intervals/milestones at which external review is 
required, and the groups from which the WG is expected to solicit 
reviews and respond to reviewers' comments.  Once these things are 
specified, IESG doesn't have to "be in the loop" and probably doesn't 
want to be.  However, these requirements could be changed just like any 
other charter change.

However, having existing WGs review documents from other WGs is 
problematic, because WGs are usually chartered to have a narrow focus 
and to exist for a limited time.  Asking WGs to review documents from 
other WGs distracts them from their narrow focus, and the fact that WGs 
exist for a limited time means that there will not always be a WG with 
competency in an area.

So I think we need "review groups" in addition to working groups.  
Review groups would be chartered according to the area of 
competency/expertise that we want them to have and what kinds of review 
we want them to provide.  They would not be allowed to develop 
standards, though they might occasionally publish some guidelines to 
articulate the rationale that they use in conducting reviews.  It might 
be that the IAB, rather than IESG, should organize and supervise review 
groups.

Keith

.