> On 10 Aug 2015, at 22:15, Andy Bierman <[email protected]> wrote: > > > > On Mon, Aug 10, 2015 at 12:34 PM, Acee Lindem (acee) <[email protected]> wrote: > I think there is agreement that there is a problem. The YANG Routing Design > Team is addressing this with > https://www.ietf.org/id/draft-rtgyangdt-rtgwg-device-model-00.txt (which has > evolved from > https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt). In > essence, a place for everything and everything in its place. However, there > are those who feel that can’t mandate a single model structure for network > devices and we need mechanisms to manage multiple models but allow for > different device structure (e.g., > https://www.ietf.org/id/draft-bierman-netmod-yang-package-00.txt). I hope we > can agree on an approach in the coming interim meetings. > > > Do you expect "everything in its place" to apply to all other SDOs and > all vendor modules? Or do you expect just the IETF routing modules > to follow this subtree hierarchy? If the former, does this mean the > YANG Routing Design Team is the "YANG data placement authority" > or all YANG modules that ever get written? How long should > it take for all other SDOs and vendors to redo all their existing > modules to re-root them in their assigned place in the data tree? > > IMO is is not a good idea to rely on rigid data node placement, > and a single data placement authority. It is better and use meta-data > built from the YANG modules (or YANG packages) instead. > > The reason Linux uses packages to install/update functionality > is because managing 8000 packages is hard enough. > Managing 247,000 individual files would be insane. > The actual location of files is quite configurable and different > across distros. We could learn something from the last decade > of Linux package management, and try to apply it to YANG. >
That’s an interesting idea, could a YANG package also specify, e.g. that the root node for the package is X/Y/Z? This could solve some use cases for relocatability, and it would also be relatively easy to modify all absolute XPath expressions inside the package. Lada > > > > > > Thanks, > Acee > > > Andy > > > > > From: netmod <[email protected]> on behalf of "Einar Nilsen-Nygaard > (einarnn)" <[email protected]> > Date: Monday, August 10, 2015 at 5:29 AM > To: Jonathan Hansford <[email protected]> > Cc: NETMOD Working Group <[email protected]> > Subject: Re: [netmod] Y34 - root node > > As someone sharing responsibilities for guiding a number of development teams > both defining new models and implementing to some already defined models in > this area, I can only agree with this addition to what I said earlier. > > Cheers, > > Einar > >> On Aug 10, 2015, at 9:46 AM, Jonathan Hansford <[email protected]> >> wrote: >> >> And it is not just end users who need help to better understand YANG models >> and how to use them. For those still on the edge, looking to finally take >> the plunge and use NETCONF/YANG to configure their devices, help is also >> required to determine how best to structure their YANG models, make use of >> the existing ones, etc. For those who have "grown up" with the developments >> in NETCONF and YANG, much of this is probably second nature. But coming to >> it cold (in the sense of compiling/writing a first set of YANG models for a >> device; I've been following the netconf/netmod WGs for 3+ years), it still >> feels very much like a dark art! It is not just the individual modules, it >> is how to put them together to best manage a device (let alone a system). >> >> Jonathan >> >> >> >> ----- Original Message ----- >> From: >> "Einar Nilsen-Nygaard (einarnn)" <[email protected]> >> >> To: >> "Andy Bierman" <[email protected]> >> Cc: >> "NETMOD Working Group" <[email protected]> >> Sent: >> Sat, 8 Aug 2015 11:10:15 +0000 >> Subject: >> Re: [netmod] Y34 - root node >> >> >> Andy, >> >> I agree that there is a need for organization of models, but I don’t have a >> firm position on >> draft-openconfig-netmod-model-structure/draft-rtgyangdt-rtgwg-device-model >> or draft-bierman-netmod-yang-package. But we absolutely need *something* to >> help end-users of the models comprehend the overall structure of models, >> their relationship and how to use them. >> >> Cheers, >> >> Einar >> >> On Aug 4, 2015, at 5:16 PM, Andy Bierman <[email protected]> wrote: >> >> >> >> On Tue, Aug 4, 2015 at 2:34 AM, t.petch <[email protected]> wrote: >> ----- Original Message ----- >> From: "Andy Bierman" <[email protected]> >> To: "t.petch" <[email protected]> >> Sent: Monday, August 03, 2015 5:17 PM >> >> > ----- Original Message ----- >> > From: "Andy Bierman" <andy@yumaworkscom> >> > To: "t.petch" <[email protected]> >> > Sent: Monday, August 03, 2015 4:10 PM >> > >> > > ----- 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]> >> > > >> >>> On 8/1/15, 2:51 AM, [email protected]> wrote: >> >>> >> >>> 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. >> >> <tp> >> >> Andy >> >> I am agreeing with you that adding 'device' brings no technical benefit, >> rather that the motivation is the opposite of technical (which I >> referred to as political). I am also agreeing with the current declared >> consensus on Y34. >> >> And yes, YANG is going to give us a large number of modules, some >> tightly coupled (augments) some loosely so (how many do you need to >> configure OSPF?) and work in this area will be of benefit now and >> probably essential in a few years time. That said, I am unsure what >> such work would be like; I am looking (in despair) at 50 routing area >> YANG models and wondering how a user will ever get a coherent picture of >> how to do what they want to do. >> >> >> >> The "YANG Land Grab" gives a false sense of progress. >> Reaching WG consensus on every single leaf is hard work. >> >> I don't think a collection of 100s of YANG modules is ever >> going to to be easy to understand. Operators will not examine >> a NETCONF <hello> message, look at 150 module URIs, >> and say "I know exactly what this device supports". >> I guess it is up to client tools to do that >> >> I wrote a draft that defines YANG Packages, which can provide >> a higher level of organization for YANG modules. >> >> http://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/ >> >> You and I are apparently in the minority, since the official status >> is that there is no problem with the current approach, and no need >> to organize individual YANG modules into any larger abstractions. >> >> >> >> Tom Petch >> >> >> >> Andy >> >> 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) >> > > >> > > > Acee >> > > > >> > > Andy >> >> >> ** Solution Y34-02 >> >> Keep 'anyxml'. Introduce 'anydata' as above but without the >> 'format' substatement. >> >> 'anyxml' would still be used to represent unrestricted XML, as is >> done in NETCONF. >> >> 'anydata' would be an unknown chunk of data that can be modelled >> with YANG. Can be encoded as xml or json. >> >> For example: >> >> #+BEGIN_EXAMPLE >> anydata data; >> #+END_EXAMPLE >> >> ** Solution Y34-05 >> >> Same as Y34-02 plus two guidelines adopted from Y34-04: >> >> - Keep 'anyxml' unchanged as it is defined in YANG 1.0. This >> ensures backward compatibility. >> - Introduce a new 'anydata' statement that represents an unknown >> chunk of data that can be modeled with YANG >> - Document that implementations MAY have restrictions for anyxml and >> that anyxml is not necessarily interoperable; data model writers >> should use anydata whenever possible. >> - The guidelines document should say that YANG Doctors will review >> each use of anyxml in IETF modules when YANG 1.1 is adopted to >> avoid its use whenever possible. >> >> >> > >> >> >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod >> > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
