Subject: RE: [newtrk] question 3 for newtrk

From: [email-masked]
Date: Sat, 10 Jul 2004 20:40:40 -0400

With "newtrk-proposals draft co-author" hat off ...

IMHO, looking at question 3 suggests an answer to question 2:

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

I think there should be two stages because (question 3):

> independent of the number of named stages which of these requirements
> should we continue to have?
> 
> a/ "resolved known design choices" 
> 
> b/  "no known technical omissions with respect to the requirements placed
>    upon it"

These are important for the first stage.  Fully-featured implementations
with complete demonstrations of interoperability should not be required.
 
> c/ "at least two independent and interoperable implementations from
>    different code bases"
> 
> d/ If patented or otherwise controlled technology
>    is required for implementation, the separate implementations must
>    also have resulted from separate exercise of the licensing process."
> 
> e/ implementation requirement "applies to all of the options and features
>    of the specification" (including removal of options or features not
>    meeting requirement)

These are important for the second stage.

As a community gains experience with a protocol, the emphasis in
"rough consensus and running code" shifts toward the latter.  In
order to get the first solid version of a protocol completed and
out of a working group, features can wind up in the spec primarily
to obtain "rough consensus", and there may be (in 20/20 hindsight)
no serious interest in implementing some of them.

I think there's significant value to a second standards stage that
has an explicit goal of excising the junk that nobody implements,
coupled with process changes to cause and encourage greater use of
that second stage.  This would also give the IESG a firm foundation
to impose this class of implementation requirements as appropriate
on recycling of a specification at the first stage.

As things currently work, Proposed Standard and Draft Standard
could be those two stages, except that the process of moving
things to Draft Standard (and thereby excising the "junk") is
broken and/or not of sufficiently motivating interest in various
ways.  I see little to no value in a further third stage.

I also think we need some mechanism to indicate stability of a
version of a protocol that may still undergo changes beyond that
of some Internet-Draft, but this mechanism needs to include a
way of explicitly and publicly terminating the "blessed" state
of that stable-but-not-quite-done version with visible prejudice ...

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html