Re: [netmod] Y34 - root node

[Andy Bierman <[e-mail]>]

On Wed, Aug 26, 2015 at 11:42 PM, Juergen Schoenwaelder <
[e-mail]> wrote:

> On Wed, Aug 26, 2015 at 05:41:29PM +0100, t. petch wrote:
> > ----- Original Message -----
> > From: "Juergen Schoenwaelder" <[e-mail]>
> > To: "t. petch" <[e-mail]>
> > Cc: <[e-mail]>; "Martin Bjorklund" <[e-mail]>;
> > <[e-mail]>
> > 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>