On Wed, Aug 26, 2015 at 05:41:29PM +0100, t. petch wrote: > ----- 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).
While SMIv2 does not have something like MUST and WHEN expressions, it still does have references between model elements. Prime example: ifTabel got augmented by ifXTable registered in a very different location. It is a major mis-conception that the OID tree is relevant; what is relevant are relationships between conceptual tables. > 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! There is no point in organizing them into a tree. There simply is no universal forever stable tree. When SMIv2 started, people thought such a tree would evolve and it was later recognized that this is an illusion and we ended up registering almost everything under mib-2 or transmission. > The flat sea of YANG modules brings a different set of issues and I > am unsure what they are; This is main problem I have. What the heck is the problem we are trying to fix? > 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. Having 200+ MIB modules registered below mib-2 has not been a problem as far as I know. /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
