Re: [MIB-DOCTORS] [OPSAWG][OPS-DIR] http://www.ietf.org/internet-drafts/draft-ietf-ippm-storetraceroutes -10.txtandRFC4560

On Wed, Aug 13, 2008 at 11:05:35AM +0200, Romascanu, Dan (Dan) wrote:
>  
> 
> > -----Original Message-----
> > From: opsawg-bounces@ietf.org 
> > [mailto:opsawg-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder
> > Sent: Wednesday, August 13, 2008 11:25 AM
> > To: tom.petch
> > Cc: 'MIB Doctors (E-mail)'; ops-dir@ietf.org; Rob Austein; 
> > opsawg@ietf.org
> > Subject: Re: [OPSAWG][OPS-DIR] 
> > http://www.ietf.org/internet-drafts/draft-ietf-ippm-storetrace
> > routes -10.txtandRFC4560
> > 
> > On Wed, Aug 13, 2008 at 09:11:15AM +0200, tom.petch wrote:
> >  
> > > And which delightfully points out a fundamental difference between
> > > SMIv2 and XML, that the former has a namespace, the latter has 
> > > infinite namespaces, so we can have as many InetAddress as 
> > we want in 
> > > XML, and doubtless will.
> > 
> > In SMIv2, you can have as many InetAddress definitions as you 
> > want as long as they are all defined in separate modules. 
> > Every SMIv2 module has in fact its own namespace.
> > 
> > /js
> > 
> 
> Are you sure? RFC2579 makes an assumption of uniqueness for TCs in
> standard space by saying that all names used for the textual conventions
> defined in all "standard" information modules shall be unique. This
> tells me that we cannot have more than one TC named InetAddress in
> SMIv2, while in XML we can have as many InetAddress as we want in
> different namespaces. 

Problems can only arise if I have a definition of InetAddress in the
modules A-MIB and B-MIB and I have to import both in modules in module
C-MIB. In this case, I have to disambiguate things. RFC 2578 says:

   [...] As such, if different objects with the same descriptor
   are IMPORTed, then this ambiguity is resolved by prefixing the
   descriptor with the name of the information module and a dot ("."),
   i.e.,

        "module.descriptor"

   (All descriptors must be unique within any information module.)

You are correct in the sense that this text talks about 'objects', so
this might not apply to TCs. Anyway, since we do not really have a
mechanism to enforce uniqueness (there is no IANA registration for
prefixes or TC names), I guess sooner or later collisions will occur
and then the A-MIB.InetAddress notation will be the only reasonable
way out, practically speaking.

The problem with some of the SMIv2 language is that it is often
unclear whether a CLR has a technical foundation or reflects an
attempt to enforce good usage guidelines (TC names should be unique to
reduce ambiguity when cutting and pasting just names).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www.ietf.org/mailman/listinfo/mib-doctors