Andy Bierman <[email protected]> writes: > On Mon, Nov 9, 2015 at 2:48 AM, Ladislav Lhotka <[email protected]> wrote: > >> Andy Bierman <[email protected]> writes: >> >> > On Thu, Nov 5, 2015 at 1:20 AM, Martin Bjorklund <[email protected]> wrote: >> > >> >> Juergen Schoenwaelder <[email protected]> wrote: >> >> >> >> ... >> >> >> > - Old function: make auto-delete for choice and when non-NETCONF >> specific >> >> > >> >> > Revision -08 of YANG 1.1 defines auto-deletion as a property of the >> >> > NETCONF edit-config operation and the issue is whether this >> >> > auto-deletion behaviour is a NETCONF specific edit-config property >> >> > or a general YANG datastore validation property that equally applies >> >> > to RESTCONF, COMI, ... >> >> > >> >> > It is unclear where we are with this. More input would be welcome. >> >> >> >> I think it would be very confusing if e.g. RESTCONF behaved >> >> differently than NETCONF. However, I can see how it might make sense >> >> for a server on a constrained device to not do auto-delete - but OTOH >> >> such a server probably don't do "must" and "when" checking at all. >> >> And it might have specialized data models that don't use such >> >> constructs. >> >> >> >> >> >> >> > I don't like any of the NETCONF-specific text in YANG 1.1. >> > YANG datastore constraints refer to a conceptual "valid datastore". >> > There is no reason to talk about specific protocol behavior, >> > except that we are too lazy to put protocol text where it belongs. >> >> Agreed. >> >> > >> > It should at least be clear that datastore validation does not at all >> depend >> > on how the datastore contents were changed. The current text does >> > not even fully support <copy-config>, so it does not even support >> NETCONF, >> > let alone RESTCONF. >> > >> > IMO auto-deletion should not be changed. >> > It works fine and the only issue that has ever come up is >> > auto-deleting data from an edit-config payload. >> >> IMO a scarier prospect is the ripple effect where an edit-config causes >> some remote part(s) of the data tree to disappear. >> >> I looked into the existing uses of "when" and none of them seems to be >> really designed for the auto-deletion option. That is, auto-deletion is >> either impossible (e.g. if "when" involves just a list key) or otherwise >> it would clearly be an operator error (e.g. if interface type is changed >> by mistake). >> >> > > > I do not agree. > The when-stmt and choice-stmt change the schema tree.
It's not about the schema tree but rather about what the server does if a data tree doesn't conform to the schema. What happens if the client sends some instances that are not in the schema at all? Will the server simply ignore these? And what happens if the client sends two competing cases of a choice in the same edit-config? Will the server toss a bitcoin and auto-delete one of the cases? > The false schema nodes are like false if-feature nodes. > This is what makes "must" different than "when". There are other significant differences, the server can behave either way, and the client can achieve the same things either way. > If an error is returned instead of deletion, then there is no difference > between must and when statements. YANG has worked this way from > the very beginning, so I do not understand what the problem is now. Well, I did express my reservations against auto-deletion several times in the past, e.g. https://mailarchive.ietf.org/arch/msg/netmod/SR9UUgFzuBcGlTHuvbKAmhVDk9w However, it seems I am not alone now. Lada > This "general confusion" argument is really weak. > > > Lada >> > > Andy > > >> >> >> > >> > >> > >> > >> > >> > /martin >> >> >> >> >> > >> > Andy >> > >> > >> >> _______________________________________________ >> >> netmod mailing list >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> > _______________________________________________ >> > netmod mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/netmod >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
