On Thu, Aug 27, 2015 at 6:56 AM, Rob Shakir <r...@rob.sh> wrote: > NETMOD, > > One of the chairs encouraged me to post this to the list. I didn’t really > find how it fits in to the existing threads, but I wanted to make an > observation. > > 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. > > As a *user* of something that results from compiling/generating bindings > from a YANG model, I have two requirements: > > - I need to be able to compose the right modules to be able to get the > functionality that that the thing I’m trying to configure uses. > - Let’s say I want to configure some OAM continuity checking > functions - for both MPLS and IP. > - Right now, I have the choice of ‘ietf-lspping’ which defines > /lsp-pings, then ‘mplstp-oam’ which defines /mplstp-oam. Presumably then > we’ll have ‘ietf-ip-oam’ and then ‘ietf-ipv6-oam’. > - As a developer - how do I figure out which models I need to build > my OAM function. Do I have to trawl some directory to find all of the > different fragments of OAM? > - Do I then need to accept the complexity of dealing with the fact > that the structures of LSP pings is completely different to the IP OAM > structures? [Given that there is no co-ordination of models, then this > *will* happen.] > - As someone that is building YANG models, how do I know where I > should leaf-ref too. > - Let’s say I want to tie an OAM probe to some protocol liveliness > - where do I point my leafref to? At the moment, without *some* > structure, than any path that is specified is pointing to some > placeholder > location, until we agree where the structure might sit. > > On the first issue here, it strikes me that this is what ietf-routing is > doing. It is placing a set of models under some root node which happens to > be /routing. If we don’t need /device, then why do we need /routing? > > The other point here, is that it is entirely unclear how ietf-routing > actually fits in to the structure. I can configure L3 protocols here, > great. But what happens when the ‘instance’ that I create has L2 protocols > too (e.g., is a VPLS with a routed L3 interface in it), or is a mix of the > two? ietf-routing doesn’t help me here - but there’s no overall structure > that tells me what should fit in. If we have *some structure* then we can > start to define what models should do what such that they are actually > usable to people who want to build things via YANG models. > > I would also observe that of the vendor implementations of YANG models I > have looked at already, almost all define some form of structure of the > data within them. In addition, the OSS tools that I’ve looked at that help > interact with devices via NETCONF/YANG do the same thing. > > When I originally drew the tree that was iterated on to form > openconfig-model-structure, the reason to draw it was not to create some > ‘/device’ node. It was to answer the two questions above. Reviewing Section > 1 of draft-openconfig-netmod-model-structure, these problems are again > drawn out. > > The issue of the IETF here is that we are solutions-driven. It is > difficult to bring this ‘challenge’ to the IETF without bringing a > solution. I first raised these points with one of the routing ADs almost a > year ago. I had found that in our attempts to define any form of models for > higher-layer functions in the systems we were debating at the time, we > needed an architecture for the models at that layer. The same thing is > needed at the device layer - the draft I presented in Dallas is an attempt > to suggest a possible solution for the challenges I outlined above. > > So. Please can we take a step back and figure out if the IETF is > interested in building models that are usable to the consumers of them? > > To me, this means debating solutions for the two questions above, and then > figuring out how to support that structure. > > If we don’t solve this issue in the IETF, then efforts elsewhere that are > more usable to developers will probably have to remain separate. > >
A whole lots of words here, but I am still confused why /device is better than / for solving your "data model awareness" problem. 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. > Just my £0.0002, > 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
