Rob,
Thanks for the response, see below.
On February 5, 2016 6:36:47 AM Robert Wilton <[email protected]> wrote:
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.
While achieving closer alignment with the layout proposed in the open
config draft is certainly possible, that is not where we were headed. Our
point was that with a modification to pyang it would be trivial to show the
tree that would result with your proposal as well as, with a little more
tooling work, auto generate additional leaves / information. -- and that
would be generally helpful. I can see how this would be useful during model
discussion and development, as well as facilitate certain implementation
approaches. I was not proposing any meaningful change to the Yang that
would be provided by the server running your extension in this bullet.
- 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"!
I think keeping things as simple as possible is a good idea. Perhaps to
even further reduce the possibility of naming conflict use something like
-metadata rather than -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.
Keep in mind that this is a user in this case. His argument for minimizing
deltas/ maximizing similarity resonates with me. I can also see how this
change would make things a bit easier on the server side.
- 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.
Excellent.
Thanks for the response,
Lou
Thanks,
Rob
Thoughts?
Lou (with Chris)
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
