Re: [netmod] a question about 'when'

"Rob Wilton (rwilton)" <rwilton@cisco.com> Wed, 07 August 2019 09:07 UTC

Return-Path: <rwilton@cisco.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 409D112030A for <netmod@ietfa.amsl.com>; Wed, 7 Aug 2019 02:07:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 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_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=lino65ei; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=BI5nAB/q
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 yuaWZGG8AeRn for <netmod@ietfa.amsl.com>; Wed, 7 Aug 2019 02:07:54 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82270120303 for <netmod@ietf.org>; Wed, 7 Aug 2019 02:07:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5412; q=dns/txt; s=iport; t=1565168874; x=1566378474; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=UIHIK85VOtX/X6DXh1+LvBBWvfdS6f9sIAdDAvoqrvs=; b=lino65eiP87AtDkt7dbTQ+U40lsN+4LesoUVczsML5IRetFqlw9+oBA8 LsZ0Hn53cAO1ktHrWJnoEX4S2GeZ9mXzM4F1ZL2xOrT0PorfVCboybyUH IGj0gMR8Hi7ihoO3/utxWFwICzXsGSClSJSFPvLyimJNs45kZZy3Lol/6 Q=;
IronPort-PHdr: =?us-ascii?q?9a23=3AjAYyQxyClK1slfnXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhSN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZufFkz/MPnsRyc7B89FElRi+iLzPA=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A2AQCjlEpd/4oNJK1mHAEBAQQBAQc?= =?us-ascii?q?EAQGBVQUBAQsBgUQkLANtVSAECyoKh1sDizJMgg+XXYEugSQDVAkBAQEMAQE?= =?us-ascii?q?YCwoCAQGDekUCgj8jNgcOAQQBAQQBAQIBBm2FJwyFSgEBAQECAQEBECgGAQE?= =?us-ascii?q?sDAQHBAIBCBEEAQEBGAYQJwsdCAEBBAESCBqDAYFqAw4PAQIMnxkCgTiIYII?= =?us-ascii?q?jgnoBAQWBBwGEDhiCFAMGgTQBi2MXgUA/gVeCTD6CYQEBgSohGE2CboImeI4?= =?us-ascii?q?CnDYJAoIclD2CL5YCjU2BNJZAAgQCBAUCDgEBBYFXATCBWHAVO4JsgkKDcYU?= =?us-ascii?q?UhQgBNnKBKYspAiICB4EEAYEgAQE?=
X-IronPort-AV: E=Sophos;i="5.64,357,1559520000"; d="scan'208";a="611180844"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Aug 2019 09:07:27 +0000
Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x7797Rps018674 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Aug 2019 09:07:27 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 7 Aug 2019 04:07:27 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 7 Aug 2019 05:07:26 -0400
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 7 Aug 2019 05:07:25 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HitXxeJlcq6YyoIuiBPi9E1N9O3/b3vYm09I2muh7pBQfw+cWocImW2Qj+NCr2HTmqhXMPHq3sGaxZ9Pj5yVixHOou4yk1u//iXqLjDhCmCtQhKZH6LICVESSrzePOyNRyn8clo0TSdRhymroEqMLbAjQhpGjoPIKXJosgsW90t94rttuTfKc7h2AcxOzJag18H+nqgyjYW9EyI7r7lmM3TPCmuXKeOWkiaz1UEmBktA7rlIt5QZQ9Jkk298KaE6ktk9A3EO6fpivzih9c3EAxOYpPn0Yv0IjJtxHn4xMbSt9Os0xm/DPlvwsSBn6kIMHoDN+JXTLRllSdmSQ//ocw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bN4pgmIM/vvD+1k6c1E1SfTOK6SioNJ483btCOuY3DE=; b=GPTYz1fFOeI0e6u1G23JvaWZu4hsPBlsviQXMS3aylndqGnQXmn5QqQP46fMfNjH9ra7QzwoEXQbohlCytHI3WIo+kxLw4tOEXJIEi2BuQokqc+7IYkW21Lv/0oBnekPvn0zG/68VELGL1N3iEsQqG3GXZ+xoAeQSL++30cny60Ep2FzPHvtty9ppPs8zoqQ6cQ+NMU+n+OB/xD2v60B7rBQagFMxx4bn8pTCF3ADpEAH2efQ0yaYpkDF4IuIeVexZTPzNz7KD+VwzKVex3bzE+4O67C7b8YaZC9tqOj20DmtKdEuVm8W3kbkUx38R5PTnGydAgVMYO80nF6ZaDj8A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bN4pgmIM/vvD+1k6c1E1SfTOK6SioNJ483btCOuY3DE=; b=BI5nAB/qaqvdcAsR9ue10BqIxwsDofNv+L++fJTsgVDIh4c3rc+6ks1UPdlRFxzJgOrsCHDZMKvForp0hOXWIcwGJj6KuNnKtrb0pgEYguWgDjWzWGyPWjjyQnGHv9cpOgfJZxcruhafC3vDW77JdRjoO3Ihu5sO0VNla2btm7s=
Received: from BYAPR11MB2631.namprd11.prod.outlook.com (52.135.227.28) by BYAPR11MB3222.namprd11.prod.outlook.com (20.177.127.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.17; Wed, 7 Aug 2019 09:07:24 +0000
Received: from BYAPR11MB2631.namprd11.prod.outlook.com ([fe80::91da:1669:aaf0:d428]) by BYAPR11MB2631.namprd11.prod.outlook.com ([fe80::91da:1669:aaf0:d428%4]) with mapi id 15.20.2136.018; Wed, 7 Aug 2019 09:07:24 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Ladislav Lhotka <lhotka@nic.cz>, 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>
Thread-Topic: [netmod] a question about 'when'
Thread-Index: AdVLPM5Xmpgaa94hSz6Z+hOvCeCLfwANi6kAAD2D/oAAIoPxAAABScmg
Date: Wed, 7 Aug 2019 09:07:24 +0000
Message-ID: <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>
In-Reply-To: <8736ide87b.fsf@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com;
x-originating-ip: [173.38.220.41]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f2046554-33ef-488d-4a01-08d71b16a9dc
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB3222;
x-ms-traffictypediagnostic: BYAPR11MB3222:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <BYAPR11MB3222D093D17099B45535620BB5D40@BYAPR11MB3222.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 01221E3973
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(346002)(396003)(376002)(39860400002)(13464003)(52314003)(53754006)(199004)(189003)(55016002)(33656002)(66946007)(76116006)(305945005)(5660300002)(7736002)(478600001)(66556008)(71190400001)(2906002)(71200400001)(66476007)(86362001)(2501003)(3846002)(66446008)(256004)(6306002)(74316002)(81156014)(53936002)(68736007)(8936002)(64756008)(14444005)(6116002)(66066001)(966005)(186003)(76176011)(8676002)(6436002)(52536014)(110136005)(11346002)(6506007)(476003)(53546011)(102836004)(99286004)(26005)(316002)(446003)(14454004)(7696005)(6246003)(81166006)(25786009)(229853002)(9686003)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3222; H:BYAPR11MB2631.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: hpLurJbUPHw8vozEltkqiJ9zsF2QnJz8sm0Wb5i+njKgP1E+rvT1J+a+fPrxydNRNBrTzHbsy4mFiRku0xErXylcB6tAa/Zl/EPR3a+OuT1xgI34KLF2AiJvjrKaoi3tToQnVSqcxwKliUNiNpfk2qApcTk2uYe/aEYmcf56if4FVL9PGKlKSEpzuJwW2nhV49yHs1U+kMj1Id6aSS7EjMCPqe1hfHZH4VQR7XN4ccWJkvKlGMxh0Vr6w9oTaxscx4q2ADwcytw/VJLuuwUoRuNqTSTnPSjX1MBAUdZF9dcKzaAJhjIyzXF3g++2UirP2lZSN/ccpjpknTKcYO6O3aGXFGkj0qwqAoy2Ffh+m+S7zfVkIGVWkE/6LonRA+Sle3AhoQzbqCXYMYJvagwq4+rC24OY0byyrPCPlJf61X8=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: f2046554-33ef-488d-4a01-08d71b16a9dc
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2019 09:07:24.7942 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: rwilton@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3222
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.26, xch-rcd-016.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ilWPq6nx29vK97nljLkNy97sSLM>
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 09:07:58 -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 <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