Re: Time to Revise the TC list

[Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>]

On Sun, May 07, 2006 at 01:21:10AM -0700, Michael Kirkham wrote:
> On Fri, 5 May 2006, Andy Bierman wrote:
> 
> >I agree with Juergen.
> >There are known problems with some tools which
> >encounter multiple versions of a TC from different
> >modules, even if the module being compiled doesn't
> >actually import these TCs.
> >
> >Moving a TC for better coupling and cohesion is even risky,
> >but at least that's an engineering reason.  Cloning a TC
> >for standards track rule compliance is a bad idea.
> 
> I'm going to offer a dissenting view that hamstringing the standards 
> process for the sake of ancient tools that are themselves not 
> standards-complaint isn't such a great idea either.

I might have not been clear. My reasoning was not about the protection
of broken MIB parsers and applications because name clashes are
something they really have to deal with. Instead, my reasoning was
that

a) moving definitions is not allowed by the SMI (you can only create new
   definitions and deprecate old ones) and

b) cloning definitions for standards process compliance has a cost
   because it becomes unclear which is authoritative and the whole
   process to update all modules is going to take ages.

OwnerString is actually a nice example for b) since it was copied from
RMON, slightly improved when it was copied, later deprecated because
having two OwnerStrings is not much of a value and just recently I has
to ask people about the little semantic differences since I did not
know the history of the evolution of these definitions.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany