Re: [YANG] [sub]module name uniqueness

[Andy Bierman <ietf at andybierman.com>]

Phil Shafer wrote:
> Andy Bierman writes:
>> There are 1000s of SMI modules and generating a
>> unique name with at most 64 unique characters has
>> not been a real problem in 2 decades.
> 
> I'm no SNMP dude, so I'll take your word for it, but I've seen a
> number of vendor mibs with names like "foo-mib", which seems to be
> begging for a collision with something else's foo mib.
> 

It doesn't happen that often, since the odds of both proprietary
MIB modules showing up on the same agent are very low.


> My guess would have been that this is fairly common.  Vendor A
> invents "foo" technology, names the mib with the obvious "foo-mib".
> Other vendors follow, naming their mibs with "foo-mib" so they look
> like they invented "foo".  The IETF standardizes the foo mib and
> ends up calling the standard "foo-mib", because, well, no one else
> matters  ;^)
> 

Most vendors use some sort of prefix to prevent naming collisions.
Certainly, the IETF does not allow any of its module names to collide.
If 2 RFCs have the same SMIv2 module, then they are different versions
of the same module.

This could be a detail that is part of the conformance for
IETF modules.  For example, modules with no description
clauses, no organization, no contact, etc. may be valid YANG,
but they should not be valid IETF YANG modules.

If vendors think it's a good idea to allow
FOO-MIB to mean totally different modules within the same system,
then they should do that.

The downside to the 'no-CLR' approach is that the IETF can only
manage its own module names, and any collisions with vendor names
are irrelevant (to the IETF).  Vendors should pick names the IETF
would never choose, and therefore avoid any collisions. (Eg. ACME-ROUTING-MIB).

My original coding issue is actually related to submodules
with the same name.  Is module FOO-MIB allowed to include a totally
different BAR-TYPES.yang than the one included by GOO-MIB?
The belongs-to clause could actually be used to sort it out,
but IMO this is a bad idea.  Implementations are not likely
to keep hunting 'BAR-TYPES.yang' files until it finds the
right 'belongs-to' value.  First match wins is much more likely.


> Thanks,
>  Phil
> 
>

Andy


_______________________________________________
YANG mailing list
YANG at ietf.org
https://www.ietf.org/mailman/listinfo/yang