Re: [NGO] external module properties

This is also how enterpise MIB modules work; only cisco is allowed to
assign OID under the cisco tree.

The only registry IANA needs to define for enterprise MIBs is the one
that assigns subtrees based on enterpiseID, i.e. IANA delegates the
assignment authority for the subtree of private to the owner of the
enterpriseID.

dbh 

> -----Original Message-----
> From: Phil Shafer [mailto:phil@juniper.net] 
> Sent: Tuesday, April 29, 2008 12:11 PM
> To: Andy Bierman
> Cc: David Harrington; 'NETCONF Goes On'
> Subject: Re: [NGO] external module properties 
> 
> Andy Bierman writes:
> >The standard uses 'stock fuzzy text' to warn vendors
> >to pick module names that will not clash.  This is how the IETF
> >punts the problem, because the real solution involves a registry,
> >and we apparently already have enough of those.  Vendors would
> >not want to register their module names with IANA anyway.
> 
> 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.
> 
> Thanks,
>  Phil
> 

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