Subject: [netmod] a question about 'when'

From: "Fengchong (frank)" <[email-masked]>
Date: Mon, 5 Aug 2019 03:32:07 +0000

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>

Or

  <password-type>simple</password-type>
  <password-text>123456</password-type>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 05 Aug 2019 11:48:52 +0200

>   <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.

Lada

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka 
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Andy Bierman <[email-masked]>
Date: Tue, 6 Aug 2019 08:10:15 -0700

On Mon, Aug 5, 2019 at 2:49 AM Ladislav Lhotka <[email-masked]> wrote:

> 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.
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 also inconsistent with the
standard
behavior for choice-stmt (new case deletes the old case automatically).

Lada
Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 07 Aug 2019 09:38:32 +0200

> 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

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 7 Aug 2019 09:07:24 +0000

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-masked]> On Behalf Of Ladislav Lhotka
Sent: 07 August 2019 08:39
To: Andy Bierman <[email-masked]>; Fengchong (frank) <[email-masked]>; [email-masked]; Zhangxiaoping (C) <[email-masked]>; liuzhiying <[email-masked]>
Subject: Re: [netmod] a question about 'when'

Andy Bierman <[email-masked]> writes:

>> > And then, I reconfig the password-type to simple, what data should 
>> > be
>> returned?
>> >
>> > Is
>> 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.
>>
>>

> doing and expects the standard to be followed.  Consider the burden on 
> the client deleting all the "false-when" nodes manually. This is

> also inconsistent with the standard behavior for choice-stmt (new case 
> deletes the old case automatically).

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 7 Aug 2019 11:47:25 +0200

> 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 (equival…

In hindsight, I tend to agree with your conclusion.

But since the default is recursive deletion, implementors can choose
to add an option controling the behavior (and perhaps we could even
standardize such an option). But it is in my view not OK to simply
implement a different behavior since clients may rightfully expect
recursive deletion as this is what the specs says.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 07 Aug 2019 12:15:05 +0200

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

> To: Andy Bierman <[email-masked]>; Fengchong (frank) <
> [email-masked]>; [email-masked]; Zhangxiaoping (C) <
> [email-masked]>; liuzhiying <[email-masked]>
> 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.
> 
> 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.
> 
> 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
> > > >

---

From: Andy Bierman <[email-masked]>
Date: Wed, 7 Aug 2019 08:29:41 -0700

On Wed, Aug 7, 2019 at 2:07 AM Rob Wilton (rwilton) <[email-masked]>
wrote:

> all the configuration that references that VRF can magically disappear.
> Assuming the server supports config rollback then even if I make a
> 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.

> 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?

Andy

> 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.
>
> 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.
>
> 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
> >> >

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 7 Aug 2019 15:53:10 +0000

Hi Andy,

From: Andy Bierman <[email-masked]>
Sent: 07 August 2019 16:30
To: Rob Wilton (rwilton) <[email-masked]>
Cc: Ladislav Lhotka <[email-masked]>; Fengchong (frank) <[email-masked]>; [email-masked]; Zhangxiaoping (C) <[email-masked]>; liuzhiying <[email-masked]>
Subject: Re: [netmod] a question about 'when'

On Wed, Aug 7, 2019 at 2:07 AM Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>> 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.

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.

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.

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.

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.

Thanks,
Rob

Thanks,
Rob

Andy

-----Original Message-----
From: netmod <[email-masked]<mailto:[email-masked]>> On Behalf Of Ladislav Lhotka
Sent: 07 August 2019 08:39
To: Andy Bierman <[email-masked]<mailto:[email-masked]>>; Fengchong (frank) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Zhangxiaoping (C) <[email-masked]<mailto:[email-masked]>>; liuzhiying <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] a question about 'when'

Andy Bierman <[email-masked]<mailto:[email-masked]>> writes:

> On Mon, Aug 5, 2019 at 2:49 AM Ladislav Lhotka <[email-masked]<mailto:[email-masked]>> wrote:
>
>> "Fengchong (frank)" <[email-masked]<mailto:[email-masked]>> writes:
>>
>> > Hi all,
>> >

Lada

>> > [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 09 Aug 2019 14:07:54 +0200

> 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.

> 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