Re: [netmod] a question about 'when'

Ladislav Lhotka <lhotka@nic.cz> Wed, 07 August 2019 10:15 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 D0185120640 for <netmod@ietfa.amsl.com>; Wed, 7 Aug 2019 03:15:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.997
X-Spam-Level:
X-Spam-Status: No, score=-6.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 EIN7R7T7EzLr for <netmod@ietfa.amsl.com>; Wed, 7 Aug 2019 03:15:08 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E8E120636 for <netmod@ietf.org>; Wed, 7 Aug 2019 03:15:08 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 4B0FC140BA7; Wed, 7 Aug 2019 12:15:06 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1565172906; bh=jnBvO+fHBVGQLOVTbEoXBbE0HZMTa5qWvLGWYGGrJXM=; h=From:To:Date; b=PlqypwUnBnZAHMeKkp9rvxImJAdoQRkbLpGZrSnm4xRmYWaorDag6B+YH3jRQM+x5 fZj5M7At1hKwQ11LftMMrjk4XjpiJxOCxPIqKRgsh8xQSiCsYZus3icPC0/3e+uGqB KcQh82+gXpqDkevTZy4PCglRGpafmBWqm/ZNFSrg=
Message-ID: <721adaafbbd2c7d837f39f6a8ba6e2d89cd5fb71.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>, 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 12:15:05 +0200
In-Reply-To: <BYAPR11MB2631BBE3A5726FBDB016D24DB5D40@BYAPR11MB2631.namprd11.prod.outlook.com>
References: <5756FB984666AD4BB8E1D63E2E3AA3D001EE95B1@DGGEMM533-MBS.china.huawei.com> <87o914gcxn.fsf@nic.cz> <CABCOCHQLqB60o1JJQ24TV_ogZFKS3poJ8PxBZeM4+po==qZqcQ@mail.gmail.com> <8736ide87b.fsf@nic.cz> <BYAPR11MB2631BBE3A5726FBDB016D24DB5D40@BYAPR11MB2631.namprd11.prod.outlook.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.32.4
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.100.3 at mail.nic.cz
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/6s5Poef0d0tIwrKrdCQN0j1It28>
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 10:15:11 -0000

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

> 
> Thanks,
> Rob
> 
> 
> -----Original Message-----
> From: netmod <netmod-bounces@ietf.org> On Behalf Of Ladislav Lhotka
> Sent: 07 August 2019 08:39
> To: Andy Bierman <andy@yumaworks.com>; Fengchong (frank) <
> frank.fengchong@huawei.com>; netmod@ietf.org; Zhangxiaoping (C) <
> zhang.xiaoping@huawei.com>; liuzhiying <liuzhiying@huawei.com>
> Subject: Re: [netmod] a question about 'when'
> 
> 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
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67