----- Original Message ----- From: "Juergen Schoenwaelder" <[email protected]> To: "t. petch" <[email protected]> Cc: <[email protected]>; "Martin Bjorklund" <[email protected]>; <[email protected]> Sent: Sunday, August 23, 2015 6:04 PM
> On Wed, Aug 19, 2015 at 05:24:41PM +0100, t. petch wrote: > > > The current model is a flat architecture of hundreds (or thousands) of > > modules each with their own top level nodes, namespace, namespace name, > > prefix etc. (This is quite different to SMI with its hierarchy but that > > probably is only significant to those who have spent 20 years with SMI). > > This is most likely a wrong perception. There are basically only two > locations where SNMP modules are registered in the IETF: under mib-2 > and under transmission (yes there are a few exceptions but overall in > number they do not matter). There are close to 240 MIB modules below > mib-2 and about 50 MIB modules below transmission. Juergen I know what you mean, that the MIB module tree is somewhat fasciated, but there is still one root, from which an obvious, absolute OID can be used to identify uniquely any MIB module (or in some contexts a relative one, relative to transmission or mib 2). If SMI did have constraints, then there would not be an issue of how to express them, nor would there be any question of mounting a module elsewhere for whatever reason (which then creates problems for the references in the constraints). A flat sea of YANG modules is different; I haven't counted lately how many top level nodes I have seen but it is a lot and when I see people wanting to organise YANG modules into a tree, I wonder if they are trying to recreate an SMI-like tree and my reaction is that this is not SMI! The flat sea of YANG modules brings a different set of issues and I am unsure what they are; I understand what is involved with the references in constraints, I can see that there will be a lot of namespaces and prefixes and can speculate about what that will bring but what it means to have so many top level nodes, I do not know. I believe that in a year or three we will be wishing we had paid more attention to this. Tom Petch > RFC 4181: > > - The value assigned to the MODULE-IDENTITY descriptor MUST be unique > and (for IETF standards-track MIB modules) SHOULD reside under the > mgmt subtree [RFC2578]. Most often it will be an IANA-assigned > value directly under mib-2 [RFC2578], although for media-specific > MIB modules that extend the IF-MIB [RFC2863] it is customary to use > an IANA-assigned value under transmission [RFC2578]. In the past, > some IETF working groups have made their own assignments from > subtrees delegated to them by IANA, but that practice has proven > problematic and is NOT RECOMMENDED. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
