> On Aug 27, 2015:1:59 PM, at 1:59 PM, Andy Bierman <a...@yumaworks.com> wrote: > > > > On Thu, Aug 27, 2015 at 10:39 AM, Rob Shakir <r...@rob.sh > <mailto: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 > <mailto: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
Andy, While it might be frustrating, coming to an understanding of what the problem is or might be, and then looking at why the existing mechanisms/models or additional ones solve these requirements (or do not) is what is at hand. I think everyone agreed at the interim meeting that the requirements were clear and sound. This is detailed in the meeting minutes. If anyone disputes this, I am happy to do an official WG call for consensus on these specifics, but given the unanimous agreement at the meeting, I did not feel that it was necessary to do this. Based on that, the next question is: are these problems solved with what is here today, or do we need another approach/es. Rob is clearly not an idiot and is asking for detailed reasons why you and others believe what he/OpenConfig have proposed is insufficient. Please be as considerate and constructive as he has been in asking his questions when you address them. —Tom (Speaking as Co-chair) > 2) As a creator of YANG mode > > ls, 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
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod