On Wed, Aug 7, 2019 at 2:07 AM Rob Wilton (rwilton) <[email protected]> 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. > > I don't see the big distinction between types of clients. YANG has 2 mechanisms (must and leafref) that will cause an error instead of a silent deletion. The when-stmt is used to indicate that the subtree is not relevant to the model if the result is false. You can easily use must-stmt instead to cause the error behavior instead of deletion behavior. This should be part of the model design, not left up to server developers. 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. > There has been nothing preventing anyone from augmenting the operations to turn off auto-deletion. Is this widely implemented? Implemented at all? > > Thanks, > Rob > > Andy > > -----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
