IETF Logo Mail Archive

Re: [netconf] (Reaffirming) Poll on transaction ID

"maqiufang (A)" <maqiufang1@huawei.com> Wed, 16 August 2023 10:59 UTC

Return-Path: <maqiufang1@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 9B04FC151097; Wed, 16 Aug 2023 03:59:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.904
X-Spam-Level:
X-Spam-Status: No, score=-6.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nox55u3CmhPR; Wed, 16 Aug 2023 03:59:55 -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 D2C33C151062; Wed, 16 Aug 2023 03:59:54 -0700 (PDT)
Received: from lhrpeml500003.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4RQlRX5bC1z6J7Pn; Wed, 16 Aug 2023 18:55:52 +0800 (CST)
Received: from kwepemm000018.china.huawei.com (7.193.23.4) by lhrpeml500003.china.huawei.com (7.191.162.67) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Wed, 16 Aug 2023 11:59:51 +0100
Received: from kwepemm600017.china.huawei.com (7.193.23.234) by kwepemm000018.china.huawei.com (7.193.23.4) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Wed, 16 Aug 2023 18:59:49 +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.2507.031; Wed, 16 Aug 2023 18:59:49 +0800
From: "maqiufang (A)" <maqiufang1@huawei.com>
To: Jan Lindblad <janl@tail-f.com>
CC: Mahesh Jethanandani <mjethanandani@gmail.com>, "netconf@ietf.org" <netconf@ietf.org>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>
Thread-Topic: [netconf] (Reaffirming) Poll on transaction ID
Thread-Index: AQHZzxSPzb49Ku7K6kqhS+JjFnYhn6/qeQYAgAIpeBA=
Date: Wed, 16 Aug 2023 10:59:49 +0000
Message-ID: <fc2aad3ae41345fea6ac5884e063d483@huawei.com>
References: <FAAC0435-8964-43AA-A2ED-6364DF3E8469@gmail.com> <E0CCC23E-0A45-46D4-B9BF-78514EAF1204@tail-f.com>
In-Reply-To: <E0CCC23E-0A45-46D4-B9BF-78514EAF1204@tail-f.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.118.147]
Content-Type: multipart/alternative; boundary="_000_fc2aad3ae41345fea6ac5884e063d483huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/_hqLu1TWK6mi_BfseRB583mM5V4>
Subject: Re: [netconf] (Reaffirming) Poll on transaction ID
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 16 Aug 2023 10:59:59 -0000

Hi, Jan, all

Thanks for providing the context, I recall I voted “No/variance” option during the meeting. I think it is okay for NETCONF protocol to support richer transaction ID mechanism than RESTCONF. And I also think that the server today already needs to maintain some history to implement configuration rollback/recover, if this historic information is useful to help further save the response data from the server in transaction ID work, then why not accept it.

It seems that the proposal is to allow the server to return the latest requested configuration which has been changed since the client last knew (please correct me if I have misunderstood the intention). I am also wondering whether it would be better for the server’s response to produce a direct configuration compare result which shows the difference in the format like YANG-patch? Sometimes it might be desirable for the client to get a diff result that could be applied directly with the “edit-config” operation. Otherwise, some efforts might be spent to transform that server response. Just some thoughts.

Best Regards,
Qiufang
From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Jan Lindblad
Sent: Tuesday, August 15, 2023 4:01 PM
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: netconf <netconf@ietf.org>; netconf-chairs <netconf-chairs@ietf.org>
Subject: Re: [netconf] (Reaffirming) Poll on transaction ID

Mahesh, WG,

Please allow me to give a little more context, since I think it is hard to understand the poll question out of the blue.

The transaction-id mechanism discussed here builds on and extends the RFC 8040/RESTCONF ideas about Etags and Timestamps for config true data. The goal is to reduce redundant communications between server and client significantly, and reduce the need for datastore locks. While implementing the draft mechanism, we came up with a possibility to further enhance the mechanism specified in the latest transaction-id draft, https://datatracker.ietf.org/doc/draft-ietf-netconf-transaction-id/01/ for even greater savings in communication and computation.

I raised the poll question to the WG to understand whether the author(s) should take the time to specify this enhancement in detail, for the WG to consider. If the WG thinks the enhancement is going in the wrong direction, that would be good to know, so that effort is not wasted.

The poll has two options:
"NO/variance": Authors, please specify in detail how the transaction-id mechanism in NETCONF could (optional to implement) work more efficiently. Leave RESTCONF as is.
"YES/stay true": Authors, please do not add further differences between the transaction-id mechanism in NETCONF and RESTCONF.

In principle it would be possible to bring the same enhanced mechanism to RESTCONF as well, but that would require a slight change of wording in RFC 8040. If the WG is interested, that would be a discussion for later.

Best Regards,
/jan




On 15 Aug 2023, at 03:04, Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>> wrote:

Hi WG,

One of the polls taken in IETF 117 during the WG session was on the question of whether we wanted to allow variance in how transaction ID is implemented in RESTCONF. In other words, should the transaction ID stay true to RFC 8040. If it is still not clear what the poll was asking, please refer to the following deck, and in particular the slides on “Comparing Variants”

https://datatracker.ietf.org/meeting/117/materials/slides-117-netconf-transaction-id-and-trace-00.pdf

We wanted to re-affirm that poll on the mailing list here. Here it goes.

Question - Should transaction ID draft (draft-ieft-netconf-transaction-id-0) stay true to RFC 8040, or allow for variance in what is returned when requested for a versioned node?

Yes says it should stay true to RFC 8040.
No says it should allow for variance.

Please vote. Thanks.

Mahesh Jethanandani
mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>





_______________________________________________
netconf mailing list
netconf@ietf.org<mailto:netconf@ietf.org>
https://www.ietf.org/mailman/listinfo/netconf

v2.23.0 | Report a Bug | By Email