Hi, I believe the rule was applied to the Entity MIB and the RMONMIB work, IIRC. dbh > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@xxxxxxxxxxxxxxx] > Sent: Thursday, July 13, 2006 9:02 AM > To: Joel M. Halpern > Cc: ietf@xxxxxxxx > 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@xxxxxxxx > >> https://www1.ietf.org/mailman/listinfo/ietf > > > > > > _______________________________________________ > > Ietf mailing list > > Ietf@xxxxxxxx > > https://www1.ietf.org/mailman/listinfo/ietf > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf