Re: [netmod] a question about 'when'

[Andy Bierman <[e-mail]>]

On Wed, Aug 7, 2019 at 2:07 AM Rob Wilton (rwilton) <[e-mail]>
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 <[e-mail]> On Behalf Of Ladislav Lhotka
> Sent: 07 August 2019 08:39
> To: Andy Bierman <[e-mail]>; Fengchong (frank) <
> [e-mail]>; [e-mail]; Zhangxiaoping (C) <
> [e-mail]>; liuzhiying <[e-mail]>
> Subject: Re: [netmod] a question about 'when'
>
> Andy Bierman <[e-mail]> writes:
>
> > On Mon, Aug 5, 2019 at 2:49 AM Ladislav Lhotka <[e-mail]> wrote:
> >
> >> "Fengchong (frank)" <[e-mail]> 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
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/netmod
> >>
> >> --
> >> Ladislav Lhotka
> >> Head, CZ.NIC Labs
> >> PGP Key ID: 0xB8F92B08A9F76C67
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/netmod
> >>
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>