Subject: [YANG] [sub]module name uniqueness

From: Andy Bierman <[email-masked]>
Date: Fri, 04 Apr 2008 15:13:06 -0700

Hi,

Sec 4.2.1 is silent on the requirement for module and sub-module
names to be unique, across some naming scope.  This is needed
for interoperability.

There are 3 options for processing import or include statements:

  1) modules and sub-module names are globally unique, and there can
     only 1 file that corresponds to a given import or include statement.

  2) there is some proprietary mechanism to determine which file
     is requested when more than 1 corresponds to the import or include
     statement value.

  3) there is some standard mechanism to determine which file
     is requested when more than 1 corresponds to the import or include
     statement value.

IMO, modules and submodules need to share the
same naming scope, and be globally unique.
All SMIv2 module names should also be considered part
of this naming scope, so that SMIv2 modules translated to YANG do
not conflict with new modules written in YANG.

Andy

_______________________________________________
YANG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/yang

---

From: Phil Shafer <[email-masked]>
Date: Fri, 04 Apr 2008 23:52:22 -0400

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

>     is requested when more than 1 corresponds to the import or include

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

>     is requested when more than 1 corresponds to the import or include

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.

>same naming scope, and be globally unique.

Are we wiling to live with module names like "org.ietf.foo.bar.yang"?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 04 Apr 2008 22:19:37 -0700

> may keep all your modules in a database.  It's all implementation

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.

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

Andy

---

From: Phil Shafer <[email-masked]>
Date: Sat, 05 Apr 2008 16:39:27 -0400

Andy Bierman writes:
>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.

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  ;^)

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Sat, 05 Apr 2008 14:40:26 -0700

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

> ends up calling the standard "foo-mib", because, well, no one else

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.

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 6 Apr 2008 12:34:01 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 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:
> > 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.
> > 
> > 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.
> 
> 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.
> > 
> 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

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 06 Apr 2008 15:14:44 +0200 (CEST)

> names to be unique, across some naming scope.  This is needed

Section 7.1 (module) and 7.2 (submodule) have this text:

   Standard module names will be assigned by IANA.  The names of all
   standard modules MUST be unique (but different revisions of the same
   module should have the same name).

   Private module names will be assigned by the organization owning the
   module without a central registry.  It is recommended to choose names
   for their modules that will have a low probability of colliding with
   standard or other enterprise modules, e.g. by using the enterprise or
   organization name as a prefix.

The idea has always been to make module names work like in SMIv2.

/martin

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 7 Apr 2008 23:22:13 -0600

Hi -

> From: "Martin Bjorklund" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Sunday, April 06, 2008 7:14 AM
...
> The idea has always been to make module names work like in SMIv2.
...

This means it will be a non-issue for most agent environments, and a
royal pain for management systems when module names clash.  (And
without well-thought-out guidelines for module naming, they *will* clash.)
(I have no sympathy at all for applications that had trouble with clashing
SMI object descriptors, since those are clearly required to be scoped
by the module name.)

Randy