----- Original Message ----- From: "Andy Bierman" <[email protected]> To: "t.petch" <[email protected]> Cc: "NETMOD Working Group" <[email protected]> Sent: Monday, August 03, 2015 4:10 PM
On Mon, Aug 3, 2015 at 7:48 AM, t.petch <[email protected]> wrote: > ----- Original Message ----- > From: "Andy Bierman" [email protected] > Sent: Saturday, August 01, 2015 7:05 PM > 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. <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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
