Andy, Apologies, I don’t understand how your mail answers the questions that I posed.
On August 27, 2015 at 12:25:20, Andy Bierman (a...@yumaworks.com) wrote: A whole lots of words here, but I am still confused why /device is better than / for solving your "data model awareness" problem. Please re-read my email - here’s the single statement where I said that this was NOT the discussion that I think is important: It strikes me that there is a need to take a step back from the debate of whether /device is a good idea or not. I’m not sure how this could be clearer. YANG is no different than any other part of the source code. Reusable YANG is just as likely or unlikely as reusable C, depending on how aware people are of the existing code base. Which OAM? Read the modules and decide. No magic there. How would /device vs / (as the first node) help you figure this out? Nobody is objecting at all to creating structure for the new modules. If /device has siblings, then let's see them in the uber-tree. The objection is to adding in a useless layer, and moving existing data nodes, which breaks existing implementations of all those data nodes. Please suggest an alternate approach to the one that is laid out in draft-openconfig-netmod-model-structure that you believe will help with the two problems that I raised. I’ll rephrase them here with less explanation, albeit that comes with less clarity. 1) As a consumer of YANG models, how do I identify the set of models that provide a set of functionality? How do YANG model writers ensure that their models are as easy to deal with as possible by having consistent modelling approaches for config? 2) As a creator of YANG models, how do I know the targets for references such that I capture references to the elements that I want, given there is no currently defined structure? “Just read through the modules” is not acceptable answer when considering making things easy to use for YANG model consumers. I want to have things that are logical to humans such that they can easily adopt YANG-based netmgmt. If they need to adopt the ecosystem by having to use hodgepodge approaches, then this feels like we are fundamentally missing an opportunity to simplify things. I want to make sure that we DO have re-usable YANG - like we have re-usable code elsewhere. In my experience this is done elsewhere by defining conventions that ensure that this is the case. Regards, r.
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod