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@xxxxxxx 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf