Re: [netmod] Y34 - root node

[Andy Bierman <[e-mail]>]

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

> ----- 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!
>
>

Are you saying the job would be easier if the
path was /device/interfaces/interface instead
of just /interfaces/interface?  Are you saying
that /protocols/routing could not also be defined?
Clearly edit-config and copy-config allow both
subtrees to be accessed in the same operation,
so I don't understand your concern.

I have been trying to get the root node to be better defined
in the protocols that use YANG (i.e., ncx:root, Y34-04).
IMO this is a better approach than defining a YANG module
with a special container that all other modules are expected
to augment.  YANG is designed such that each vendor or SDO
is not dependent on other vendors or SDOs in order to
define data nodes.



> Tom Petch
> >
>
>

Andy


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