Re: [netmod] Y34 - root node

[t.petch <[e-mail]>]

----- Original Message -----
From: "Andy Bierman" <[e-mail]>
To: "Acee Lindem (acee)" <[e-mail]>
Cc: "NETMOD Working Group" <[e-mail]>
Sent: Saturday, August 01, 2015 7:05 PM
Subject: Re: [netmod] Y34
On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) <[e-mail]>
wrote:

> Hi Juergen,
>
> On 8/1/15, 2:51 AM,  [e-mail]> wrote:
>
> >On Fri, Jul 31, 2015 at 12:46:49PM -0400, Lou Berger wrote:
> >> Andy,
> >>
> >> On 07/27/2015 12:58 PM, Andy Bierman wrote:
> >> > Hi,
> >> >
> >> > I don't think a standard for relocating subtrees would be worth
it.
> >> > I am not in favor of moving /interfaces or /system to a new
location.
> >> > That's not how YANG works. It only allows "obsolete and start
over".
> >> >
> >> > I would suggest pursuing solutions that don't cause
> >> > as much disruption and expense as possible.
> >> >
> >> I think it would be really good to explore other, less "disruptive"
> >> options.
> >
> >I think the first step is to find out whether there is a problem
worth
> >to be fixed. Why are the RFCs in question broken? (Yes, I have read
> >the openconfig IDs,
>
> Section 1.1 in
> https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt
> lists the goals of a generic model structure that will accommodate
most
> modern network devices. I guess you don’t agree that these are
desirable?

The only objection I have to this draft is the insertion of a top-level
root
called "device".  (Might as well be called "self").
There are no sibling nodes planned or intended for
this node, so it serves as an extra document root.

<tp>
One aspect of YANG I have never grasped is what a root means, if
anything.

I understand that it is needed for NETCONF (filters) and for YANG
(augments, constraints) and so must be somewhere and must be relatively
stable, but has it any other significance in the data model?

As you may recall, I was involved with SMI first, where the root is
somewhere up in the sky and life only becomes interesting some six
levels down the hierarchy and that may colour my thinking.

Tom Petch


The well-specified XPath and YANG root (/) can be
accessed by all protocol operations, exactly the same
as a node called 'device'.  The actual node name will
depend on the RPC function (e.g. 'data' or 'config').

This is more than redundant however.  It introduces a "super-module"
into YANG that every other module is expected to augment.
YANG is intended to be more loosely coupled than that.
This introduces an extra node and namespace declaration
in all protocol messages, increasing message sizes.

It also assumes all existing YANG models will get rewritten to
account for "/device" in all path and XPath expressions.
This is highly disruptive to existing deployments.
Also, multiple data models to edit the same thing causes lots
of extra complexity in the server (supporting both old
location and new location).

IMO a resource directory approach is much more realistic.
The /device tree can contain all the organized NP containers.
Instead of all the actual data nodes, this tree just has pointers
to the real location of the resource. (like 301 Moved Permanently)

Thanks,
> Acee
>
>
>
Andy