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

Reply via email to