[netconf] comments on draft-lindblad-netconf-transaction-id
Qin Wu <bill.wu@huawei.com> Tue, 22 March 2022 08:11 UTC
Return-Path: <bill.wu@huawei.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D553A0C27 for <netconf@ietfa.amsl.com>; Tue, 22 Mar 2022 01:11:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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] 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 Oo6uLamkvdq1 for <netconf@ietfa.amsl.com>; Tue, 22 Mar 2022 01:11:23 -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 0C2163A0C25 for <netconf@ietf.org>; Tue, 22 Mar 2022 01:11:23 -0700 (PDT)
Received: from fraeml739-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KN40l2th6z67Mmd for <netconf@ietf.org>; Tue, 22 Mar 2022 16:10:15 +0800 (CST)
Received: from canpemm500008.china.huawei.com (7.192.105.151) by fraeml739-chm.china.huawei.com (10.206.15.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 22 Mar 2022 09:11:19 +0100
Received: from canpemm500005.china.huawei.com (7.192.104.229) by canpemm500008.china.huawei.com (7.192.105.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Tue, 22 Mar 2022 16:11:17 +0800
Received: from canpemm500005.china.huawei.com ([7.192.104.229]) by canpemm500005.china.huawei.com ([7.192.104.229]) with mapi id 15.01.2308.021; Tue, 22 Mar 2022 16:11:17 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Netconf <netconf@ietf.org>
CC: "jlindbla@cisco.com" <jlindbla@cisco.com>
Thread-Topic: comments on draft-lindblad-netconf-transaction-id
Thread-Index: Adg9w6H4p3l5b8ryQeqjUEbpnZXx5A==
Date: Tue, 22 Mar 2022 08:11:17 +0000
Message-ID: <6bba069173714170b57495748dc37a65@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.100.16]
Content-Type: multipart/alternative; boundary="_000_6bba069173714170b57495748dc37a65huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/F4DIK1hDeMcdGaYEcPIXJ4picro>
Subject: [netconf] comments on draft-lindblad-netconf-transaction-id
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Mar 2022 08:11:28 -0000
Hi, Jan: Nice presentation in yesterday netconf session, thank for well documented problem statements. I have read through the latest version of draft-lindblad-netconf-transaction-id, believe the idea is very close to Optimistic concurrency control or Optimistic lock. Three things I want to make sure 1. Do we intend to replace NETCONF lock and partial lock with transaction id proposed in this draft? 2. Every time there has been a configuration change on the server, how the server synchronize transaction id to all the clients who get access to the same server? Return updated transaction id only when the client polls the server? 3. When multiple clients in parallel poll the same server on the same resource e.g., frequent sent edit-configs to perform operation on the same data resource, can transaction id handle this scenarios? Thanks in advance! -Qin
- [netconf] comments on draft-lindblad-netconf-tran… Qin Wu
- Re: [netconf] comments on draft-lindblad-netconf-… Jan Lindblad (jlindbla)