On Thu, Aug 27, 2015 at 11:19 AM, Rob Shakir <r...@rob.sh> wrote: > Hi Andy, > > I’m struggling with this debate. > > On August 27, 2015 at 13:59:55, Andy Bierman (a...@yumaworks.com) wrote: > > > Sorry -- are you suggesting that maybe /device adds no value beyond /? > If so, I agree. > > No, I am suggesting that should understand what the alternatives to > solving issues are, before moving on to debating the merits of a particular > solution that has nothing to compare and contrast against. >
There is a proposal for the data root -- use / as we are doing now. > One container does not add value, the structure (which happens to start > with /device in ONE proposal, to which there are no alternates) is what > matters. Unfortunately you seem to be stuck on this container. Please > ignore it and focus on the problems I defined. > > RTFM > > Great. So, I need to go and write a bunch of different implementations of > how to set up a ping, and trawl through a huge number of roots to find > things that are related. If this is the approach we take with IETF modules, > then they will be worse to use than the existing configuration approaches > that we have. At least the vendor specific ones have some form of logic as > to how they are usable to consumers. > Did you really think that just because we created a nice DML that somehow you would not need to know about the topic of your YANG module? I actually have heard this complaint from some people. Great. How does YANG help? I still have to be an expert in MPLS to write a YANG module that manages MPLS. Yep. That's right. Nothing in YANG helps you know more than you do now about specific networking technologies. I don't see what the "huge number of roots" has to do with this issue. > 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. > > Consider VRRP ‘tracking’. I want to be able to add some form of new thing > that VRRP might track. If we’ve defined a structure that says that there is > some list of ‘tracking-objects’ that I can leafref to, then my new OAM > mechanism can augment there. If there is no such structure, then we cannot > do that, and rather the VRRF model only leafrefs to the currently known > paths (my ‘track’ leaf has explicit leafref to a subset of ‘ping’ and known > continuity checks when I wrote the module). Adding the new OAM mechanism > then means a new version of the VRRP module - which seems suboptimal. The > first approach is cleaner, but needs someone to define the structure such > that we get it right. > No matter what set of NP containers you create, there might be stuff that could reasonably be put in different places. So what? This is part of the design choice when picking the one true home for everything. The structure is ad-hoc and arbitrary. Its only value is in the common agreement of where things should go. So make up some structure and fill it in. What's the problem? 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. > > Defining structure with arbitrary subsets of the tree doesn’t help! As an > operator I want to be able to configure a device, because this is what my > network is built from. Not IETF areas. > > Do you suggest that the existing models are placed as a constraint on any > new work in YANG? If so, I’d be grateful if you can point out to me what > the precedent is to show that they are useful in the real world? > I have not seen any evidence that moving /interfaces, /interfaces-state, /nacm, /netconf-state, /netconf, /ipfix, /system and /snmp will solve any real problems. There are implementations of these modules already. Are you suggesting that work the new routing modules cannot proceed because these 8 top-level nodes are somehow preventing this work? Are you suggesting it would solve your OAM or VRRP design problems if the path was /device/interfaces instead of just /interfaces? Kind regards, > r. > > Andy
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
