On Wed, 2019-08-07 at 09:07 +0000, Rob Wilton (rwilton) wrote: > 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.
I agree. In any case, protocol behaviour like this should not be a part of YANG specification. This is one of the things that need to be removed in 7950bis. Lada > > 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 -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
