On Thu, Aug 27, 2015 at 10:39 AM, Rob Shakir <r...@rob.sh> wrote: > 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. > > Sorry -- are you suggesting that maybe /device adds no value beyond /? If so, I agree.
> 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? > RTFM > 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? > The modules you are using have data locations defined. In order to define YANG data (with YANG 1.0 or 1.1) a top-level data node or augment-stmt will be present specifying the /path/from/root How do you know where data is that has not been defined yet? You don't and YANG has no ability to reference undefined data anyway. “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. > Why isn't RTFM good enough? Is there some expectation that just /the/path/from/root is enough to make somebody an expert in managing some feature or an expert in writing new YANG modules? Additional tools outside the scope of IETF standardization work are needed to make development easier. Nothing whatsoever is stopping the routing area from defining some structure for new modules. Pick whatever you like. The only pushback is wrt/ obsoleting existing RFC modules and moving the data nodes in them to a different location. Some of us do not agree that a problem has been demonstrated that warrants starting over for these RFCs. 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. > > Andy
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
