Re: [YANG] [sub]module name uniqueness

["Romascanu, Dan (Dan)" <dromasca at avaya.com>]

> -----Original Message-----
> From: yang-bounces at ietf.org [mailto:yang-bounces at ietf.org] On 
> Behalf Of Andy Bierman
> Sent: Saturday, April 05, 2008 8:20 AM
> To: Phil Shafer
> Cc: yang
> Subject: Re: [YANG] [sub]module name uniqueness
> 
> Phil Shafer wrote:
> > Andy Bierman writes:
> >>  1) modules and sub-module names are globally unique, and there can
> >>     only 1 file that corresponds to a given import or 
> include statement.
> > 
> > This would lead to scoped names ala java class names, 
> giving us module 
> > names like "org.ietf.smi.interface-mib.yang".  This is partially 
> > elegant, but mostly verbose.
> > 
> >>  2) there is some proprietary mechanism to determine which file
> >>     is requested when more than 1 corresponds to the 
> import or include
> >>     statement value.
> > 
> > This could be done with simple rules like:
> > 
> > - Imported modules must be found in a directory given via the
> >   -I option.
> > - Multiple -I options may be listed.
> > - They are searched in the order they appear on the command
> >   line.
> > - Included submodules must be found in the same directory
> >   as their module.
> > 
> > This makes "import" behave similarly to '#include <foo.h>'
> > and "include" behave similarly to '#include "foo.h"'.
> > (Yes, not exactly, but similar.)
> > 
> >>  3) there is some standard mechanism to determine which file
> >>     is requested when more than 1 corresponds to the 
> import or include
> >>     statement value.
> > 
> > The standard doesn't need to talk about files, since your 
> YANG IDE may 
> > keep all your modules in a database.  It's all implementation 
> > specific.
> 
> I don't see how a WG could ever publish
> an RFC with FOO-MODULE in it if another RFC already has a 
> YANG module using that name.
> 
> 
> > 
> >> IMO, modules and submodules need to share the same naming 
> scope, and 
> >> be globally unique.
> > 
> > Are we wiling to live with module names like 
> "org.ietf.foo.bar.yang"?
> > 
> 
> Why would we name modules like that?
> 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 don't think the problem will be any worse 
> with at least 63 unique characters, as YANG mandates.
> 

We can control only the naming in the standard space and recommend rules
for proprietary extensions. RFC2578 sets the rules for SMIv2 objects
naming and these are mandatory for standard MIB modules, but just a
"strong" recommendations for enterprise-specific modules. I am pretty
sure there are more than one SMIv2 module out three named ETHERNET-MIB
and more than one object named ethernetPortAdminStatus. This did not
cause any interoperability problem as long as the MIB modules and
objects were rooted under different OIDs, but some tools I encountered
ran into trouble when loading simultaneously MIB modules with clashing
modules or names. 

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