RE: Time to Revise the TC list

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

You compile your collection of MIB modules, specify you
want an output list of defined items. The items defined
in the MIB modules are listed. Items with the identical
descriptor are marked with term "**dup".

Regards,
/david t. perkins

On Fri, 5 May 2006, David Harrington wrote:
> Hi,
> 
> I know smicng has the ability to identify dups when they are both
> imported into the same document. But if the TC was specified in a
> different document than it had been specified previously, would smicng
> be able to spot that? This would presumably require an external file
> that tracked where TCs were located, and could spot when the TC had
> been moved or duplicated.
> 
> dbh
> 
> > -----Original Message-----
> > From: David T. Perkins [mailto:dperkins@dsperkins.com] 
> > Sent: Friday, May 05, 2006 11:23 AM
> > To: David Harrington
> > Cc: 'C. M. Heard'; 'Mreview (E-mail)'; ietfmibs@ops.ietf.org
> > Subject: RE: Time to Revise the TC list
> > 
> > 
> > HI,
> > 
> > SMICng has had the ability to specify "dups" for a very
> > long time.
> > 
> > Regards,
> > /david t. perkins
> > 
> > On Fri, 5 May 2006, David Harrington wrote:
> > > Hi,
> > > 
> > > I suspect we would not normally see the impact of such conflict
> here
> > > in the IETF. It would show up in the real world when customers use
> > > applications that import these names into a large database of MIB
> > > modules, and end up with a conflict. Hopefully all applications
> have
> > > been updated to use scoped naming.
> > > 
> > > In the IETF, we should be careful to not allow a WG to modify a
> > > definition copied from another MIB module, so we don't have two
> > > different standard TCs with the same name.
> > > 
> > > Do libsmi or smicng have the ability to detect
> non-global-uniqueness
> > > in standards modules? Just wondering if this has been automated.
> > > 
> > > dbh
> > > 
> > > > -----Original Message-----
> > > > From: owner-mreview@ops.ietf.org 
> > > > [mailto:owner-mreview@ops.ietf.org] On Behalf Of C. M. Heard
> > > > Sent: Friday, May 05, 2006 10:15 AM
> > > > To: Mreview (E-mail); ietfmibs@ops.ietf.org
> > > > Subject: RE: Time to Revise the TC list
> > > > 
> > > > 
> > > > On Fri, 5 May 2006, Wijnen, Bert (Bert) wrote:
> > > > > > If the TCs live by themselves in a separate MIB 
> > module -- which
> > > is
> > > > > > often, but not always the case -- then I agree with this. 
> > > >  However,
> > > > > > TCs that reside in a MIB module with other 
> > definitions cannot be
> > > > > > moved into another MIB module, since that would break MIB
> > > modules
> > > > > > that import those TCs.  So it's not possible to split such
> TCs
> > > out
> > > > > > into a separate document.
> > > > > > 
> > > > > 
> > > > > Maybe I should have said "copied" instead of "moved". 
> > > > > I know it would cause a name clash, but I do not see 
> > any technical
> > > > > problems with that. Over time, when the old MIB gets 
> > > > revised, the old
> > > > > definitions can be obsoleted.
> > > > 
> > > > Yes, we do have a rule in RFC 2579 that "all names used for the
> > > > textual conventions defined in all ``standard'' 
> > information modules
> > > > shall be unique" but there are cases where this is 
> > violated with no
> > > > apparent ill consequence -- for instance, OwnerString is 
> > defined in
> > > > both IF-MIB (where it is deprecated) and RMON-MIB (where 
> > it is not).
> > > > 
> > > > //cmh
> > > > 
> > > > 
> > > 
> > > 
> > > 
> > 
> 
>