Re: [netmod] a question about 'when'

Ladislav Lhotka <lhotka@nic.cz> Wed, 07 August 2019 07:38 UTC

Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E011A120285 for <netmod@ietfa.amsl.com>; Wed, 7 Aug 2019 00:38:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utlQCIcCuo3A for <netmod@ietfa.amsl.com>; Wed, 7 Aug 2019 00:38:54 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCE412024C for <netmod@ietf.org>; Wed, 7 Aug 2019 00:38:54 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id BDBDD182048C; Wed, 7 Aug 2019 09:41:09 +0200 (CEST)
Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id BC37C1820043; Wed, 7 Aug 2019 09:40:50 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Andy Bierman <andy@yumaworks.com>, "Fengchong (frank)" <frank.fengchong@huawei.com>, "netmod@ietf.org" <netmod@ietf.org>, "Zhangxiaoping (C)" <zhang.xiaoping@huawei.com>, liuzhiying <liuzhiying@huawei.com>
In-Reply-To: <CABCOCHQLqB60o1JJQ24TV_ogZFKS3poJ8PxBZeM4+po==qZqcQ@mail.gmail.com>
References: <5756FB984666AD4BB8E1D63E2E3AA3D001EE95B1@DGGEMM533-MBS.china.huawei.com> <87o914gcxn.fsf@nic.cz> <CABCOCHQLqB60o1JJQ24TV_ogZFKS3poJ8PxBZeM4+po==qZqcQ@mail.gmail.com>
Mail-Followup-To: Andy Bierman <andy@yumaworks.com>, "Fengchong \(frank\)" <frank.fengchong@huawei.com>, "netmod\@ietf.org" <netmod@ietf.org>, "Zhangxiaoping \(C\)" <zhang.xiaoping@huawei.com>, liuzhiying <liuzhiying@huawei.com>
Date: Wed, 07 Aug 2019 09:38:32 +0200
Message-ID: <8736ide87b.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/skJbhc0jgyheqsHHh57OD8-KpdU>
Subject: Re: [netmod] a question about 'when'
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Aug 2019 07:38:57 -0000

Andy Bierman <andy@yumaworks.com> writes:

> On Mon, Aug 5, 2019 at 2:49 AM Ladislav Lhotka <lhotka@nic.cz> wrote:
>
>> "Fengchong (frank)" <frank.fengchong@huawei.com> 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
>> > netmod@ietf.org
>> > https://www.ietf.org/mailman/listinfo/netmod
>>
>> --
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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