I can see that 'when automatic deletion' processing can be useful if the configuration is being manipulated by a human. E.g. if I delete a VRF then all the configuration that references that VRF can magically disappear. Assuming the server supports config rollback then even if I make a catastrophic mistake, it isn't usually that hard to recover from.
But for a fully automated client, then I agree with Lada, in that I see the server side 'when automatic deletion' processing as unhelpful. The client logically needs to know/understand the full configuration anyway, so it should be able to generate the complete configuration change required to update the server with a new valid configuration state. In these scenarios, having the server perform 'when automatic deletion' processing seems to increase the risk that that client and server views of the configuration could end up out of sync. Some clients simplify the protocol operations by always doing a config replace on every config change to guarantee that the copy of the configuration on the server matches what is in the client. For clients that exist somewhere between no automation and full automation, then I can imagine that for some cases 'when automatic deletion' processing might be useful, and other cases where it is unhelpful. Personally, I would have preferred that the 'when automatic deletion' processing was controlled via an explicit protocol option, with the default behaviour to just validate when statements (equivalently to must statements) and not perform any automatically config deletion. Thanks, Rob -----Original Message----- From: netmod <[email protected]> On Behalf Of Ladislav Lhotka Sent: 07 August 2019 08:39 To: Andy Bierman <[email protected]>; Fengchong (frank) <[email protected]>; [email protected]; Zhangxiaoping (C) <[email protected]>; liuzhiying <[email protected]> Subject: Re: [netmod] a question about 'when' Andy Bierman <[email protected]> writes: > On Mon, Aug 5, 2019 at 2:49 AM Ladislav Lhotka <[email protected]> wrote: > >> "Fengchong (frank)" <[email protected]> writes: >> >> > Hi all, >> > >> > I encounter a question about 'when', when I implement yang model >> associated when condition. >> > >> > Yang model: >> > >> > leaf password-type { >> > type enumeration { >> > enum null; >> > enum simple; >> > enum cipher; >> > } >> > } >> > >> > leaf password-text { >> > type string; >> > when "../password-type != null"; >> > } >> > >> > I config these two leafs as below: >> > <password-type>simple</password-type> >> > <password-text>123456</password-text> >> > >> > And I changed password-type to null, I get the config like below: >> > <password-type>null</password-type> >> > >> > And then, I reconfig the password-type to simple, what data should >> > be >> returned? >> > >> > Is >> > <password-type>simple</password-type> >> >> According to RFC 7950, sec. 8.2, the server deleted "password-text" >> after you changed "password-type" to null but the original value >> isn't recovered after you change the type back. >> >> This server behaviour means that a typo or similar trivial error may >> have catastrophic consequences such as auto-deletion of entire >> configuration subtrees. That's why our RESTCONF implementation >> (jetconf) does something >> else: it won't permit you to change "password-type" to null as long >> as the "password-text" exists. >> >> > It seems odd to optimize the server for client mistakes. This is just the principle of least embarrassment. The problem is that it is not indicated in the data model that deleting or changing something may have far-reaching consequences. > It is far more likely (99 to 1?) that the client knows what it is > doing and expects the standard to be followed. Consider the burden on > the client deleting all the "false-when" nodes manually. This is If it is a significant burden, then it's also quite likely that the client may not be completely aware of what's going to be auto-deleted. > also inconsistent with the standard behavior for choice-stmt (new case > deletes the old case automatically). This is quite different in that the impact is localized: one can easily see that a given leaf is a case in a choice so that it cannot exist along with another case. Lada > > Lada >> >> > Andy > > >> > >> > Or >> > >> > <password-type>simple</password-type> >> > <password-text>123456</password-type> >> > _______________________________________________ >> > netmod mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/netmod >> >> -- >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> _______________________________________________ >> 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 Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
