Re: [NGO] external module properties

Martin Bjorklund wrote:
> Phil Shafer <phil@juniper.net> wrote:
>> The other option is the one java took: use reversed domain name
>> hierarchies to ensure that there are no conflicts.  No one but sun
>> can make a com.sun.java.swing module, given you instant
>> self-organizing uniqueness.  If you own the domain, you own the
>> namespace under that domain.  Pro: simple; con: verbose.
> 
> 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.
> 
> 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.
> 

We should do what we can within the XML sandbox.
I agree with your comment about using the namespace URI instead
of a long string for the module name.  There are enough static
mappings to deal with already.  However, these URIs will
not be very easy to memorize, unlike module names.

I prefer to use derived fields from the YANG module (ala revision
date for version ID) instead of adding potentially redundant fields,
in case you were thinking of a 'short' module name an a 'long' module name. ;-)

> 
> /martin
> 
> 
> 

Andy

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