"Rob Wilton (rwilton)" <[email protected]> writes: > Hi Andy, > > From: Andy Bierman <[email protected]> > Sent: 07 August 2019 16:30 > To: Rob Wilton (rwilton) <[email protected]> > Cc: Ladislav Lhotka <[email protected]>; Fengchong (frank) > <[email protected]>; [email protected]; Zhangxiaoping (C) > <[email protected]>; liuzhiying <[email protected]> > Subject: Re: [netmod] a question about 'when' > > > > On Wed, Aug 7, 2019 at 2:07 AM Rob Wilton (rwilton) > <[email protected]<mailto:[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. > [RW] > The definition of a “when” statement is fine (i.e. the subtree becomes > invalid if the ‘when’ check fails). My only issue is with the automatic > deletion behaviour that I think is unhelpful at times.
On the other hand, the "when" statement is so dangerous and tricky exactly because it is so powerful. If it was restricted and its effects localized, then the auto-delete behaviour could also be more generally acceptable. > > 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. > [RW] But as a client I would not want the server to silently remove > configuration because a when condition became false. Instead, I > would rather do it explicitly and have the server return an error so > that I can fix the behaviour of the client. If the client is aware > of the schema then it can also prune config associated with failed > when conditions if it wants. Yes, the same YANG module can be used with different setups and policies that may require different approaches. > > Ultimately, my aim as a client is to get a complete configuration in the > client down to the server, and to be sure that the two are consistent. The > ‘when automatic deletion’ behaviour doesn’t help with that, it makes it > riskier. As mentioned previously, this can be mitigated by always sending > the entire configuration down as a config replace, at which point I would > presume that the ‘when’ statements are evaluated equivalently to ‘must’ > statements anyway – although I’m not sure whether RFC 7950 is clear on this. > > 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? [RW] I think that it is as Lada stated, some > servers just don’t check must or when statements at all, or don’t > perform the automatic deletion. I’m not advocating that is a good > or the right thing to do. They just don’t comply to that part of > the RFC. Right, there is no reason why YANG couldn't be used with management protocols that don't support server-side auto-deletion. In fact, it is already used in situations when there is no management protocol at all. Lada > > Thanks, > Rob > > > > Thanks, > Rob > > Andy > > > -----Original Message----- > From: netmod <[email protected]<mailto:[email protected]>> On > Behalf Of Ladislav Lhotka > Sent: 07 August 2019 08:39 > To: Andy Bierman <[email protected]<mailto:[email protected]>>; Fengchong > (frank) <[email protected]<mailto:[email protected]>>; > [email protected]<mailto:[email protected]>; Zhangxiaoping (C) > <[email protected]<mailto:[email protected]>>; liuzhiying > <[email protected]<mailto:[email protected]>> > Subject: Re: [netmod] a question about 'when' > > Andy Bierman <[email protected]<mailto:[email protected]>> writes: > >> On Mon, Aug 5, 2019 at 2:49 AM Ladislav Lhotka >> <[email protected]<mailto:[email protected]>> wrote: >> >>> "Fengchong (frank)" >>> <[email protected]<mailto:[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]<mailto:[email protected]> >>> > https://www.ietf.org/mailman/listinfo/netmod >>> >>> -- >>> Ladislav Lhotka >>> Head, CZ.NIC Labs >>> PGP Key ID: 0xB8F92B08A9F76C67 >>> >>> _______________________________________________ >>> netmod mailing list >>> [email protected]<mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> _______________________________________________ >> netmod mailing list >> [email protected]<mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > [email protected]<mailto:[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
