Hi Juergen, I don't really follow your point.
The solution is fully backward compatible - in that only clients that make use of the protocol extension would see the new encoding. Existing clients would continue to see the encoding as directly defined in the YANG schema, and a server would be able to support old and new clients concurrently.
Rob On 05/02/2016 09:50, Juergen Schoenwaelder wrote:
This I-D seems to break core design assumptions of YANG data encoding works and hence it seems to break all existing implementations. If you define leaf mtu { type uint32; } then this is encoded as <mtu>9000</mtu> and there is not room for mixed content. I am stictly against any solution that is not backwards compatible. /js On Thu, Feb 04, 2016 at 05:31:54PM -0500, 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. - 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
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
