there is one useful aspect of our DS contortions. When we do the
work, we actually figure out which features turn out not to be used,
and get them out of the spec.
OSPF had ToS routing in its PS specification. It turned out that
there was only one implementation.
So when the protocol was ready to advance, that feature was removed.
Knowing that the feature was not being used proved very helpful to us later.
Yours,
Joel
At 02:45 AM 7/13/2006, 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.
Eliot
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf