Hi Lou (& Chris),
Thanks for the comments.
On 04/02/2016 22:31, Lou Berger wrote:
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.
Yes.
I've not considered it in detail, but using tooling extensions it may be
possible to get even closer to the OpenConfig structure/conventions if
required. E.g. something roughly along the lines of every "config true"
leaf gets put into a config container and state container, state leaves
just go in a state container, interfaces & interfaces-state could be
merged similarly, etc. Of course this would be more complex that the
approach proposed in the draft.
- 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.
Yes, there is still a possible naming clash if a model already had a
config leaf called "<leaf>-cfg".
Possibly this could be mitigated by putting the additional meta data
leaves in a separate namespace, or perhaps the pragmatic approach would
be to say don't allow leaves to be called "<leaf>-cfg"!
The reasoning for the approach documented in the draft is that I
perceive that it is cleaner for client that want the intended vs applied
split, but agree that the approach that Chris suggests could make
backwards compatibility easier for clients.
- 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.
Yes, I think that such filters should be fairly easy to define and
implement. I.e. if there is a scheme in place for returning the
intended and applied values it should be quite straight forward on the
server side to filter which elements are returned for a particular request.
Thanks,
Rob
Thoughts?
Lou (with Chris)
.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
