Re: [netmod] a question about 'when'
Andy Bierman <andy@yumaworks.com> Wed, 07 August 2019 15:29 UTC
Return-Path: <andy@yumaworks.com>
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 ACBC2120368 for <netmod@ietfa.amsl.com>; Wed, 7 Aug 2019 08:29:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 rX2ua4XCAmeR for <netmod@ietfa.amsl.com>; Wed, 7 Aug 2019 08:29:55 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38DA61200C5 for <netmod@ietf.org>; Wed, 7 Aug 2019 08:29:55 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id b29so57114443lfq.1 for <netmod@ietf.org>; Wed, 07 Aug 2019 08:29:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0Bk8/dRnIrhdWhn1l3Ok6pZNO+ZKXJzzlXxL2mFzxyg=; b=RA20yHhjwYWSpQHnUkWDFDJAP41YEJZW9vl438khOzSGwoPCPgXtJ1AOHuvQvMQHOM dsksU48UvMu6FZirkxPIAJI5i4sSuHJz2n94Li0HBscQdVB9zCB67B3BTTsCrx7moDz+ gDUtCRylFnoU+H56LDKdp0nXR+FYx5+n0cv7N2AaeRwFQSpuQXW8RPuT3fYT9kBk/WIz zHVbh9ALujxqQLWjq7XI4lQTZJvyOiKBnLcftxb6czVPXiQsHjpIeA8OcAGqb69zb4eE ahfDLVHzUPTft/BC3sud7zDujknyKU1eqKmPcpx1KZkW6gez52Bczm6kQNRFNJ8ePXVf Fwug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0Bk8/dRnIrhdWhn1l3Ok6pZNO+ZKXJzzlXxL2mFzxyg=; b=igi9w63Tzr9wVkJv8LU3CAdRnmdaT+k0Zhw42hFUYe/PP6Sh7v1RKtLxkHLT/92XWH nIEjW7qYIdVX/zp/EbZ+7wDpeBxJjmdXkwswfiV/0Q2V0GAITkeZRrZMmhsK2B+Vj/9W FXL8lUZrNE8Lr+gPMIw8AUg49hndoDVOgAOioiHhvpbYWqLPppbs0nslPJ0kJFoXH075 tcYVBn5XdPs072JhBDspjVQVq8KIXrZH63WjwSre1+IvNoizLfsbe4fY6YxA5+9+CJmz tWjS1AehfK7/v17Cue6kDL82HD3CQGjvpncb5PATeXwndAn3Vm7mkAeSOCyTw8p7yl4A zkPQ==
X-Gm-Message-State: APjAAAU9hexNHGce2sUtmUonUONmXUs7WOuxCexO0PzzQrDjY0XyjHxP 9ynSV8Ym298rKZHgOZ0BWVcTNbiWJ4aP4zp9CBizDA==
X-Google-Smtp-Source: APXvYqzcVJwiIbvziRy6ycK3JZjj8hL84A+4MxAyFD6LR6Iiunio8uIKEd/ubZetRkJpOnoXAhmhA4F9AwsFUx6JGoM=
X-Received: by 2002:ac2:44ac:: with SMTP id c12mr6385957lfm.33.1565191793158; Wed, 07 Aug 2019 08:29:53 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <BYAPR11MB2631BBE3A5726FBDB016D24DB5D40@BYAPR11MB2631.namprd11.prod.outlook.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 07 Aug 2019 08:29:41 -0700
Message-ID: <CABCOCHT_9EhEkdPKiGxAZYEvsDGauDNQw=TMUkm+qZFCRPXr7Q@mail.gmail.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
Cc: Ladislav Lhotka <lhotka@nic.cz>, "Fengchong (frank)" <frank.fengchong@huawei.com>, "netmod@ietf.org" <netmod@ietf.org>, "Zhangxiaoping (C)" <zhang.xiaoping@huawei.com>, liuzhiying <liuzhiying@huawei.com>
Content-Type: multipart/alternative; boundary="000000000000d64151058f889c73"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/3TvQFql1hDnweocoMF1r-y6kH4o>
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 15:29:59 -0000
On Wed, Aug 7, 2019 at 2:07 AM Rob Wilton (rwilton) <rwilton@cisco.com> 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 <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 >
- [netmod] a question about 'when' Fengchong (frank)
- Re: [netmod] a question about 'when' Ladislav Lhotka
- Re: [netmod] a question about 'when' Andy Bierman
- Re: [netmod] a question about 'when' Ladislav Lhotka
- Re: [netmod] a question about 'when' Rob Wilton (rwilton)
- Re: [netmod] a question about 'when' Juergen Schoenwaelder
- Re: [netmod] a question about 'when' Ladislav Lhotka
- Re: [netmod] a question about 'when' Andy Bierman
- Re: [netmod] a question about 'when' Rob Wilton (rwilton)
- Re: [netmod] a question about 'when' Ladislav Lhotka