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. 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. 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. 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? Kind regards, r.
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
