RE: Time to Revise the TC list

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

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