On Mon, Aug 3, 2015 at 7:48 AM, t.petch <[email protected]> wrote: > ----- Original Message ----- > From: "Andy Bierman" <[email protected]> > To: "Acee Lindem (acee)" <[email protected]> > Cc: "NETMOD Working Group" <[email protected]> > Sent: Saturday, August 01, 2015 7:05 PM > Subject: Re: [netmod] Y34 > On Sat, Aug 1, 2015 at 9:51 AM, Acee Lindem (acee) <[email protected]> > wrote: > > > Hi Juergen, > > > > On 8/1/15, 2:51 AM, [email protected]> 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. > 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 > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
