Re: [netmod] Y34 - root node

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

----- Original Message -----
From: "Andy Bierman" <[e-mail]>
To: "t.petch" <[e-mail]>
Cc: "NETMOD Working Group" <[e-mail]>
Sent: Monday, August 03, 2015 4:10 PM

On Mon, Aug 3, 2015 at 7:48 AM, t.petch <[e-mail]> wrote:

> ----- Original Message -----
> From: "Andy Bierman" [e-mail]
> Sent: Saturday, August 01, 2015 7:05 PM
> 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.
>

YANG does a poor job of defining the root for YANG data nodes.
It is sometimes called a datastore (in the abstract).
Technically, YANG borrows the definition from XPath.
YANG just defines top-level data nodes and the parent of
these nodes is the document root.

There is no protocol or encoding neutral definition,
only an XML-specific definition.

<tp>

Thanks for that.

It seems to me that much of the extensive discussion on Y34 (all of
which I have read) is as much political as technical, that is SMI is
hierarchical, top down, perhaps befitting its origins in ISO, whereas
YANG is bottom up. IETF-like.  YANG could have had a single tree, but
doesn't.  So when I read

https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt

I see a plea for a more hierarchical organisation, and when I read

draft-bjorklund-netmod-openconfig-reply-00

I see a response that says we are not like that.

If so, I doubt that there ever will be a technical solution.

And I am mindful that when I configure routing in a (Cisco) router, I
have to do some of it under the interface definitions and some of it
under the definition of the routing protocol.  Which is life, never
wholy interface-centric and never wholy routing protocol-centric!

Tom Petch
>

Andy

> 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