Hi,
I believe the rule was applied to the Entity MIB and the RMONMIB work,
IIRC.
dbh
-----Original Message-----
From: Henning Schulzrinne [mailto:hgs(_at_)cs(_dot_)columbia(_dot_)edu]
Sent: Thursday, July 13, 2006 9:02 AM
To: Joel M. Halpern
Cc: ietf(_at_)ietf(_dot_)org
Subject: Re: Comments on draft-carpenter-newtrk-questions-00.txt
Has this been exercised in the past, say, 5 years?
At least for widely-implemented protocols, such as SIP, there is no
reasonable way to say "there is only one implementation that
does X",
as there is no plausible way to catalog all such implementations.
Most of the implementors don't show up at IETF meetings and
implementations are written by dozens of small start-ups,
open source
systems and other non-traditional sources.
This provision actually discourages any DS effort: the danger
is that
you can't find an implementation that does use a certain
feature, you
deprecate it and then find that there was some SDO or implementor
somewhere that actually did find this extremely useful. That just
makes everyone look silly.
On Jul 13, 2006, at 7:29 AM, Joel M. Halpern wrote:
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf