RE: Time to Revise the TC list

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

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