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(_at_)att(_dot_)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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf