Subject: [newtrk] augmented newtrk agenda

From: [email-masked] (Scott Bradner)
Date: Thu, 29 Jul 2004 10:07:59 -0400 (EDT)

Harald reminded me of somthing I should have remembered - "add IDs"

Newtrk reading lits
Discussion of current proposals:  Black/Carpenter               35 m
	primary ID
	draft-ietf-newtrk-proposals-00.txt

	proposal IDs
	draft-bradner-ietf-stds-trk-01.txt
	draft-dawkins-pstmt-twostage-02.txt
	draft-dawkins-newtrk-wgs-00.txt

Adding a layer of indirection to standards naming: Klensin      40 m
	IDs
	draft-loughney-what-standards-01.txt
	draft-klensin-newtrk-std-repurposing-00.txt

additional agenda topic:
	document garbage collection: Lear/Alvestrand/Klensin
	IDs
	draft-alvestrand-newtrk-historical-00.txt
	draft-klensin-newtrk-antiques-00.txt

.
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: Thu, 29 Jul 2004 09:35:19 -0600 (MDT)

A few folks said that a single-stage track (with revisions,
interoperability register, etc.) may make the most sense. However,
there seems to be no draft documenting a single-stage track design. Is
anybody working or thinking of working on a single stage draft?

Thanks,

Alex.
.

---

From: Keith Moore <[email-masked]>
Date: Thu, 29 Jul 2004 14:10:34 -0400

> anybody working or thinking of working on a single stage draft?

I am, but it has more than one stage.

Yes, this sounds like a contradiction.  But it seems clear to me that
while one "standard" stage might be appropriate, there are cases where
we need other "stages" of published documents as necessary predecessors
to that standard stage. 

It also seems clear to me that we need more than one track, all 
terminating in the "standard" stage, because we can't reasonably expect
to derive all of our standards in the same way.  Simple standards that
don't have significant effects on other interests can be safely approved
with procedures like we have in place now (working group or individual
submission).  Complex standards, or standards that have significant
affect on other standards or on the infrastructure, need to be developed
through a rigorous engineering process, subject to periodic external
review, etc.  And we'll continue to have some standards that originate
elsewhere and are brought into IETF after significant deployment.
It's generally too late to "engineer" those standards.  So we need 
different tools for qualifying standards depending on their history
and complexity - and some of those tools will probably still need to 
involve the kind of "publish, implement, ship, deploy, evaluate" 
long feedback loops that 2026 seems to advocate.  

IMHO, the goal should not be to discard the current mechanisms, but to
provide faster means to get to "standard" status for the cases when it
seems warranted - e.g. for very simple standards or for standards that
were subjected to engineering rigor during development, and for which
implementation and testing occurred in parallel with development.

-Keith
.