Hello, A few of us in the routing area architecture yang DT discussed this draft yesterday and had a couple of comments, (note that the open config contributors who are members of the design team did not participate in this discussion):
- that with tooling, it is possible for the models available using your extension have important similarities to the model conventions proposed by open config. We think it would be worth mentioning that tooling extensions could be used to auto generate both yang and tree formats that would be effectively available using the extension. - we think there is significant value in having a tools based approach which uses existing models, and which keeps config nodes in unmodified locations. Chris Hopps came up with the idea of a minor change to your extension where instead of adding 4 new config leaf values cfg-* replacing the original leaf, the three new leaf values would be added underneath a sibling node, perhaps called <leaf>-cfg. The benefit of this is that user code would be the same with respect to intended config with or without your extension. This also addresses the list index problem. - also from Chris: it would be useful to have a way of retrieving intended config along with any applied config that differs from the intended config, e.g. with-config-state=intended+diff-cfg. Thoughts? Lou (with Chris) _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
