Re: [netmod] Y34 - root node

[Andy Bierman <[e-mail]>]

On Wed, Aug 26, 2015 at 9:41 AM, t.petch <[e-mail]> 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).
>
> 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.
>
>

YANG uses XPath absolute-path expressions to identify data instances.
Each node in the tree has a QName (namespace + local-name).
There is zero ambiguity in an absolute path expression, so it
works whether there are 3 modules or 30,000 modules.
But if the path expression cannot change over time.

We do not need to place every new node at the top.
In fact, we don't, as the ietf-ip module proves.
We do need to pick a home for data and never change it -- ever.
Starting over with a data node means picking a new location for its home.

IMO the "logical view" injected into the model is the worst part.
This does not apply to very many implementations, and these
virtual devices are usually dealt with in the protocol, not the data model.
That way, different logical views can be derived, instead of imposing
a single logical model (with a uint8 index to cover all possible logical
instances).







> Tom Petch
>

Andy


>
> > 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: [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
>