On Wed, Aug 26, 2015 at 11:42 PM, Juergen Schoenwaelder < [email protected]> wrote:
> 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. > > The only thing the same between SMIv2 and YANG here is age-old question of how should we care about "dumb" tools that are not very schema-aware. With YANG, the data related to "foo" can actually be located under /some/path/to/foo. I agree with you that for a programmatic interface, the location is not at all important, but to a human typing URLs into a browser, it will be important. I don't see the 6 modules that have already been published so far in RFCs as the problem. I suggest focusing on the 194 modules that have not been published. Should the IETF spend a year or two debating the ONE TRUE PERFECT uber-tree? 6 months? How long will it take for all interested vendors to agree where every little thing goes, before starting on any of it. > /js > > Andy > -- > 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 >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
