Re: [NGO] external module properties

Martin Bjorklund writes:
>If we want something verbose, we already have the namespace uri, which
>also is supposed to be globally unique.  It could be used to identify
>the module.

With the issue that it's even uglier that the already-ugly-enough
java scheme, and it gives an even less simple module->filename
mapping.

We could say that the module name is just a user-friendly term
that means nothing to the language, and then import by URIs,
but this doesn't answer includes.  And I think we'd have to
give some helpful words about the URI->filename mapping, such
as "you could give a file that contains this mapping".

>I have limited experience of using SNMP MIBs in larger NMS systems;
>but is the current module name scheme of SMI a problem?  If it is, we
>should do something better.  If it isn't, we shouldn't try to solve
>it.

In truth, it's rare and mostly seems to occur between multiple early
versions of the same technology.  The most common conflicts I could
find (in a quick search) was "vlan-mib", "switch-mib", and, um, er,
one other that I've forgotten.  Rats.

I'm happy (more than happy) to declare this a non-problem, but we
declared it a non-problem a couple months ago and here it is again.

Can we get a non-problem pre-first-meeting concensus and move on?

My take is either it's not a problem, or it needs a once-and-for-all
fix.  I'm not a fan of the java naming scheme (or java at all), but
the difference between "module ietf-vlan" and "module org.ietf.vlan"
is zero.  Hack, we could do non-reverse names: "module vlan.ietf.org".

Either way, it's not a big deal.  Let's pick an answer and get it
off the table.

Thanks,
 Phil
_______________________________________________
NGO mailing list
NGO@ietf.org
https://www.ietf.org/mailman/listinfo/ngo