Juergen Schoenwaelder <[email protected]> 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.
It is backwards compatible in the sense that the client has to explicitly ask for this new encoding from the server. However, the solution requires new code paths for encoding/decoding the data. Interactions with subfiltering is also a bit unclear. But I have another observation. Just like draft-kwatsen-netmod-opstate, this solution makes the assumption that the server internally has knowledge of "applied" vs. "intended" values for data modelled as config true. The two solutions differ in the way this data is requested and encoded. I would argue (no surprise here) that the encoding proposed in draft-kwatsen-netmod-opstate is much simpler. /martin > > /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 > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
