Re: Comments on draft-carpenter-newtrk-questions-00.txt

A variety of people at the plenary last night said "declare victory".
But I know that different people took that statement to mean different
things. To me, declare victory means "recognizing the reality of the
single level standard as it appears to be and moving on". This doesn't
mean to stop working on newtrk, but to refocus newtrk on recognizing
that fact. Put an end to the arguments about whether we should go to
1-level, 2-level or 3-level, and move on from there.

When a new spec is published on the standards track, it's meant to be
the new standard, and the industry should be using it, and that's what
industry is (more or less) doing. (The less comes into play once in a
while when a non-clueful company puts out an RFP/RFQ for an old standard
because "that's the standard".)

On the flip side is the question of when a standard is no longer a
standard. For this I think it should be based on whether there is a
group willing to work on: doing interop testing & maintaining an errata
list for the spec and/or working on a new version of it.

If no one is willing to do the testing necessary to find and generate an
errata list, the spec should automatically become Historic. (Pick a time
span, say 2 years.) So the burden then is laid on updating the errata
list in order for the spec to remain a standard. (There would be an
opportunity for an empty errata to be created only if there is interop
experience to back it up and only after a given time has elapsed.) If
people are interested in the standard, they should be willing to do the
minor amount of work to keep it from becoming Historic.

	Tony Hansen
	tony@att.com

Eliot Lear wrote:
> Fred Baker wrote:
>> I would like to believe that a well documented interoperability test
>> constitutes DS qualification; the current DS qualification sets the
>> bar somewhat higher than that, and I note that few documents actually
>> achieve that, even though we can daily see implementations
>> interoperating in the field at PS.
> 
> Some data to Fred's point:
> 
> By RFC, not by STD (obviously):
> 
> Status	1999	2000	2001	2002	2003	2004	2005
> -------------------------------------------------------------
> PS	102	119	71	105	103	131	169
> DRAFT	6	6	2	4	7	7	3
> STD	3(*)	2	0	8*	3	0	1
> 
> 
> (*) 3 in 1999 were SMIv2 6 in 2002 were SNMP.
> 
> These are rough based on 10 minutes of scripting I did back in March.  I believe there are two reasons for the huge gap between PS and DRAFT:
> 
>  - it's difficult to get there (interop requirements, picking out
>    uncommonly used features, etc)
>  - nobody wants or needs to do the work (what GM in her right
>    mind would want her experts working on something that neither
>    generates new features nor fixes product bugs)
> 
> If Iljitsch's proposal is that the IESG "makes a call" based perhaps on somebody's request with some modest effort to demonstrate that a spec is ready for the next step, I think that actually would be a fine two-step approach.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf