Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

"maqiufang (A)" <maqiufang1@huawei.com> Thu, 24 March 2022 14:22 UTC

Return-Path: <maqiufang1@huawei.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 081CE3A0D39 for <netmod@ietfa.amsl.com>; Thu, 24 Mar 2022 07:22:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.806
X-Spam-Level:
X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Ssv6eOrrCeZZ for <netmod@ietfa.amsl.com>; Thu, 24 Mar 2022 07:22:48 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1D53A0D16 for <netmod@ietf.org>; Thu, 24 Mar 2022 07:22:48 -0700 (PDT)
Received: from fraeml742-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KPS6z51bRz67xFj for <netmod@ietf.org>; Thu, 24 Mar 2022 22:20:27 +0800 (CST)
Received: from kwepemm600019.china.huawei.com (7.193.23.64) by fraeml742-chm.china.huawei.com (10.206.15.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 24 Mar 2022 15:22:44 +0100
Received: from kwepemm600017.china.huawei.com (7.193.23.234) by kwepemm600019.china.huawei.com (7.193.23.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 24 Mar 2022 22:22:42 +0800
Received: from kwepemm600017.china.huawei.com ([7.193.23.234]) by kwepemm600017.china.huawei.com ([7.193.23.234]) with mapi id 15.01.2308.021; Thu, 24 Mar 2022 22:22:42 +0800
From: "maqiufang (A)" <maqiufang1@huawei.com>
To: Andy Bierman <andy@yumaworks.com>
CC: Balázs Lengyel <balazs.lengyel=40ericsson.com@dmarc.ietf.org>, Kent Watsen <kent+ietf@watsen.net>, NETMOD Group <netmod@ietf.org>
Thread-Topic: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00
Thread-Index: AQHYPvIPKTDCKOttWkWRZvthAfjfqazM8mAAgAAElICAAAllAIAAEt+AgAF3m3A=
Date: Thu, 24 Mar 2022 14:22:42 +0000
Message-ID: <4fb3a9ab84744c42bc54084903f94ba5@huawei.com>
References: <CABCOCHRqZgCfH0j5XnEt0aK0fwVCaxe_aSHCAZn3jb0QLrDuKw@mail.gmail.com> <VI1PR0701MB2351A430BA5F2EEFE96CE094F0189@VI1PR0701MB2351.eurprd07.prod.outlook.com> <CABCOCHSY6CN7Xf05RtTF0jm1S6gLd1umr5BtG3pkkeCBu47Jyw@mail.gmail.com> <VI1PR0701MB23518B3F1FB9EE3EE32C9FDAF0189@VI1PR0701MB2351.eurprd07.prod.outlook.com> <CABCOCHT5D3=cZR=f86FiCQ48=1Enqwi+-eyR3Y-xSE37_cyvzA@mail.gmail.com>
In-Reply-To: <CABCOCHT5D3=cZR=f86FiCQ48=1Enqwi+-eyR3Y-xSE37_cyvzA@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.48.10.166]
Content-Type: multipart/alternative; boundary="_000_4fb3a9ab84744c42bc54084903f94ba5huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/U6hLOZ6c42vYnmeCX5wE6uJzq1I>
Subject: Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00
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: Thu, 24 Mar 2022 14:22:54 -0000

Hi, Andy, Balazs,

I can see your points in some of the use cases.
But as Kent mentioned, the motivation of this work is that we have some system-defined instance which are read-only to clients.
And there may be some cases where a list/leaf-list data node may exist in multiple instances with different control rules.

To be specific, An instance-level annotation could be useful in following use cases:

a)       The system generates some QoS templates when QoS functionality is enabled, and some of the generated templates are read-only, while others are free to be updated by the clients.

b)       The system predefines some list/leaf-list instances which are read-only for clients(the clients cannot update or delete them, like predefined NACM rules), but the clients is free to add/update/delete their own defined instances.

While YANG-extension can be useful for a schema-level immutability.
I am thinking that, maybe we need both to complete the solution?

Best Regards,
Qiufang

From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Thursday, March 24, 2022 7:14 AM
To: Balázs Lengyel <balazs.lengyel@ericsson.com>
Cc: NetMod WG <netmod@ietf.org>
Subject: Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00



On Wed, Mar 23, 2022 at 3:06 PM Balázs Lengyel <balazs.lengyel@ericsson.com<mailto:balazs.lengyel@ericsson.com>> wrote:


From: Andy Bierman <andy@yumaworks.com<mailto:andy@yumaworks.com>>
Sent: Wednesday, 23 March, 2022 22:32
To: Balázs Lengyel <balazs.lengyel@ericsson.com<mailto:balazs.lengyel@ericsson.com>>
Cc: NetMod WG <netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: Re: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00



On Wed, Mar 23, 2022 at 2:16 PM Balázs Lengyel <balazs.lengyel@ericsson.com<mailto:balazs.lengyel@ericsson.com>> wrote:
Hello Andy,
I also propose an extension. (see my mail Review of draft-ma-netmod-immutable-flag-00)
In Ericsson we saw no need for exceptions, but do see the need for applying it to descendant nodes. Typically we need to protect a full subtree.

Why do you need the exceptions? Could you provide some use-case examples ?

I think create/delete-only and modify-only access modes are used the most, after no-access.
BALAZS: How is a modify-only data-node different from a mandatory data-node? It must be there but can be changed. It get’s an initial value somehow.

Mandatory=true requires the system to provide a value.
Modify-only allows the system to decide when an instance is created.


BALAZS: Any examples when would a create/delete only data node be used?

Sometimes developers do not want to write complex instrumentation that supports
modification of resources.  Instead a user has to delete the old entry and create a new
one with (potentially) different parameters.



Applying to descendant nodes may be better, or may require more work to
undo the extension used in an ancestor node. This impacts the extension usage within a grouping.

BALAZS2: I did not include it in my mail, but we actually have one more rule:
“Top level statements in augment or groupings do NOT inherit
       the static-data value from containing nodes, they default to
       static-data false.”


This seems complicated to users and developers to track how the final schema tree was derived.

The 'static-data' extension seems fine to me.
We have to support 'user-write' anyways, so it is better if it is not too close to this extension.
Things that seem the same, but are NOT the same cause the most support tickets.


Regards Balazs

Andy

Andy




From: netmod <netmod-bounces@ietf.org<mailto:netmod-bounces@ietf.org>> On Behalf Of Andy Bierman
Sent: Wednesday, 23 March, 2022 21:10
To: NetMod WG <netmod@ietf.org<mailto:netmod@ietf.org>>
Subject: [netmod] Alternative approach to draft-ma-netmod-immutable-flag-00

Hi,

IMO the problem should be viewed as a refinement to the
access control policy of the device.  A standard mechanism
such as a YANG extension would be better than a growing
mix of proprietary solutions.

We have such a YANG extension called "user-write" that is widely deployed.
A simple boolean is not fine enough granularity, so a bits type is
needed instead to allow control of create, update, and delete access operations.


https://www.yumaworks.com/pub/latest/yangauto/yumapro-yangauto-guide.html#ncx-user-write<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-876c03f0bc610d95&q=1&e=c875257e-41f5-45d6-a9e9-871e5ebb4243&u=https%3A%2F%2Fwww.yumaworks.com%2Fpub%2Flatest%2Fyangauto%2Fyumapro-yangauto-guide.html%23ncx-user-write>


Andy