RE: Comments on draft-carpenter-newtrk-questions-00.txt

["David Harrington" <[e-mail]>]

Hi,

I believe the rule was applied to the Entity MIB and the RMONMIB work,
IIRC.

dbh 

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[e-mail]] 
> Sent: Thursday, July 13, 2006 9:02 AM
> To: Joel M. Halpern
> Cc: [e-mail]
> 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
> >> [e-mail]
> >> https://www1.ietf.org/mailman/listinfo/ietf
> >
> >
> > _______________________________________________
> > Ietf mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/ietf
> 
> 
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ietf
> 


_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf