RE: Time to Revise the TC list

["David Harrington" <ietfdbh@comcast.net>]

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
> > > 
> > > 
> > 
> > 
> > 
>