Subject: [newtrk] question two for newtrk

From: [email-masked] (Scott Bradner)
Date: Wed, 30 Jun 2004 09:00:07 -0400 (EDT)

as I mentioned in the last exchange with Spencer, I did not see
a consensus for a "1-stage" IETF standards process (e.g., having
a single stage called something like "IETF Standard") from this
lask of consensus on a 1-stage I read that there is a consensus for
a multiple stage process (specifically, multiple stages where there
is IESG review & approval for publication resulting in RFCs with
different designations)

the current IETF process has (in theory and sometimes in practice) 3 stages
	Proposed Standard
	Draft Standard
	(Internet) Standard

question two for newtrk is "how many IESG-approved stages?"

(note that this question does not include the possibilty of a 
low-threshold-for-approval Working Group Snapshot that might need
an IESG OK for publication but would not need a formal IESG review - teh
IESG might just have to check to see that some series of steps had been
followed - that question is next)

my assumption is that there would be some increased requirement for
the "higher" stages as there currently is but lets leave the question of
the specific requirement for later

option A
	2 IESG reviewed stages
	e.g.	Proposed Standard
		IETF Standard
	
option B
	3 IESG reviewed stages
	e.g. what we have now

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

---

From: Melinda Shore <[email-masked]>
Date: Wed, 30 Jun 2004 09:30:55 -0400

> 	e.g. what we have now

But you left out a proposal for a 5-stage process!

Regardless, I have a strong preference for a two-stage process (option 
A).

Melinda

.

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 30 Jun 2004 09:11:16 -0600 (MDT)

On Wed, 30 Jun 2004, Scott Bradner wrote:

> the "higher" stages as there currently is but lets leave the
> question of the specific requirement for later

All I can say in this fuzzy context is that we should have the minimum
number of meaningful/useful stages, where "meaningful/useful" is
defined primarily from IETF customers (standards users) point of view.

I currently can detect no more than two meaningful/useful stages (each
accompanied by unlimited number of in-stage revisions). I can easily
justify one stage. With some effort, I may be able to find enough
corner cases to justify two stages.

Alex.
.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Jun 2004 16:51:46 +0200

I would like to see the list of pros and cons for various
numbers of stages before we reach a consensus.

Umm, I'm co-author of the draft that is supposed to contain
that list, so I'd better get on it.

    Brian

Melinda Shore wrote:
> Regardless, I have a strong preference for a two-stage process (option A).
> 
> Melinda
> 
> .
.

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 30 Jun 2004 13:36:44 -0600 (MDT)

Scott Bradner kindly advised me to post my objections, in the light of
new (to me) meaning of Question One. So here they are, for the record,
FWIW.

On Wed, 30 Jun 2004, Scott Bradner wrote:

> I did not see a consensus for a "1-stage" IETF standards process
> (e.g., having a single stage called something like "IETF Standard")

I believe there was consensus that a one-publication IETF standards
process is not acceptible. Most folks agreed that some bug fixing is
inevitable/required for a quality standard.

I do not think Question One was accurate enough to talk about
consensus (or lack thereof) for a one-stage process. The idea of
multiple revisions within one stage did not come up on the list until
after the question was asked and answered by some, and multiple
revisions change the meaning/meaningfulness of the question, IMHO.
They definately change my answer to the question which I posted before
multiple unnamed revisions within one stage were in scope.

In fact, I have found no e-mail in the mailing list archives of this
thread that can be clearly interpreted as

	"one stage will not work, even if there are multiple revisions
	and associated statements of stability and/or snapshots within
	that one stage".

and there are several e-mails saying that "one stage with revisions,
statements, and/or snapshots" is a good idea!

> from this lask of consensus on a 1-stage I read that there is a
> consensus for a multiple stage process

I do not understand how lack of consensus for one stage indicates
consensus for multiple stages rather than, say, lack of consensus for
any number of stages or diverse opinions regarding what the question
actually meant.

To move on, I suggest that you either ignore this posting or rephrase
the second question to allow "1 stage" as the answer (in addition to
the current "2" and "3 stage" answers).

Thanks,

Alex.
.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 30 Jun 2004 20:03:24 -0500

Seeing that we've had, functionally, one IESG-approved stage for
almost all specifications we've published, I'd like to hear why people
think we need two.

I'd also like to hear why people think we'll start using more than one
stage for most specifications, for the first time in history. Our
history is actually a decent predictor of our future in a lot of
cases...

> question two for newtrk is "how many IESG-approved stages?"

Ignoring the part where I'm a co-author on a draft that says "two",
I'm thinking "one" would be a pretty good answer, and it's probably
what we'll end up with for most specs in practice anyway.

Someone (Scott Brim?) said they liked rewarding specifications that
were good enough to be stable ("these are the specs that have been
stable for several years, and these are the specs that change every
9-18 months"). I understand this motivation; I'm just not sure we need
to change the level label to accomplish it.

Dave Crocker's suggestion was that Full Standard is ONLY a mindshare
consensus ("people think the spec is OK and are deploying it"). I'm
not sure that would qualify as "IESG approval" in this thread.

Spencer

.