On Thu, Aug 27, 2015 at 11:56 AM, Nadeau Thomas <tnad...@lucidvision.com> wrote:
> > On Aug 27, 2015:2:29 PM, at 2:29 PM, Andy Bierman <a...@yumaworks.com> > wrote: > > > > On Thu, Aug 27, 2015 at 11:14 AM, Nadeau Thomas <tnad...@lucidvision.com> > wrote: > >> >> 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> 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 >> >> >> 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. >> >> > Are you suggesting that the openconfig drafts offer some solution > to "how do I use this YANG module" that does not involve reading the YANG > module? > If so, I didn't see it. Please point it out to us. > > > I am not taking sides. I hope I don’t need to point out these guys have > presented an alternative > solution. The WG must consider this seriously as it is a serious proposal > that is being seriously > considered in other parts of the IETF such as the routing area. I will > point out again that we are > looking at this closely and thoroughly. If its determined to be desired > via consensus, > then we will go forward with it; if not, then no. Its my action and job > to determine this and I’ve > outlined the process for this. > > We are going to interim meetings. We are discussing the issues on the WG mailing list. I was under the impression this is our process. I hope we get past the hand-waving phase and you can enumerate the exact changes and how they are going to be accomplished. For example, do all 7 of the existing RFCs need to recharter and start over? Is a WG going to be formed to create the uber-tree? There have been several objections to moving /interfaces to /device/interfaces. Are you declaring that the IETF agrees that this change is needed, despite all the objections and statements such as "an uber-tree makes things worse"? My only objection is to moving data that has already been published in an > RFC. > I am not the only person on this list that has questioned to value of > moving this small number of data models to new roots in the data tree. > > Everything done in an IETF meeting needs to be confirmed on > the mailing list. You know that. > > So what specifics are you ready to declare have WG consensus? > > > Again, my assumption was that there was sufficient consensus and > understanding around > the requirements (not the solutions) after the interim meetings. I > explicitly asked that > question at the meeting and went around the WebEx call to confirm. Those > conclusions were > documented in the meeting minutes posted on the list. > Just because there are objections to a top-level container named /device doesn't mean anything wrt/ the entire list of problems. Stop trying to push these solutions through all-or-none. Even if the IETF agrees to work on a problem, all solutions are subject to review and alteration by the WG. A design team solution is just a starting point (but you know that). >From my reading of the email (from Juergen, Tom, and others) there are real concerns that we have not agreed on the problems to be solved. > > —Tom > > Andy > > > > > > > —Tom (Speaking as Co-chair) >> >> >> > Andy > > >> 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
