[Netconf] Difference between test-then-set and set within <edit-config>operation
Qin Wu <bill.wu@huawei.com> Thu, 20 December 2018 01:32 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 4DD8212D4EF for <netconf@ietfa.amsl.com>; Wed, 19 Dec 2018 17:32:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level:
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] 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 mjGaEXbhElhc for <netconf@ietfa.amsl.com>; Wed, 19 Dec 2018 17:32:06 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0ABB127133 for <netconf@ietf.org>; Wed, 19 Dec 2018 17:32:05 -0800 (PST)
Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id CE42AF420306A for <netconf@ietf.org>; Thu, 20 Dec 2018 01:32:01 +0000 (GMT)
Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 20 Dec 2018 01:32:02 +0000
Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Thu, 20 Dec 2018 01:32:02 +0000
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1591.10 via Frontend Transport; Thu, 20 Dec 2018 01:32:02 +0000
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.172]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0415.000; Thu, 20 Dec 2018 09:31:50 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: Difference between test-then-set and set within <edit-config>operation
Thread-Index: AdSYA8d/6gfS7uj/SK6nQEU6b7fF0w==
Date: Thu, 20 Dec 2018 01:31:50 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA9B1B5673@nkgeml513-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.33.244]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9B1B5673nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/HnjW044UKMRitv1AOU3Jti0Nxdg>
Subject: [Netconf] Difference between test-then-set and set within <edit-config>operation
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing 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: Thu, 20 Dec 2018 01:32:09 -0000
Hi, All:
RFC6241 said:
"
test-option: The <test-option> element MAY be specified only if
the device advertises the :validate:1.1 capability
(Section 8.6<https://tools.ietf.org/html/rfc6241#section-8.6>).
The <test-option> element has one of the following values:
test-then-set: Perform a validation test before attempting to
set. If validation errors occur, do not perform the
<edit-config> operation. This is the default test-option.
set: Perform a set without a validation test first.
test-only: Perform only the validation test, without
attempting to set.
"
It is not clear to me the real difference between test-then-set and set witin <edit-config> operation? Why test-then-set is set as default option?
Do we use explicitly validate operation defined section 8.6.4 of RFC6241 to perform validation test in the test-then-set?
RFC 7950 section 8.3.3 said:
"
If the datastore is
"running" or "startup", these constraints MUST be enforced at the end
of the <edit-config> or <copy-config> operation. If the datastore is
"candidate", the constraint enforcement is delayed until a <commit>
or <validate> operation takes place.
"
It gives me impression that for <running>, the configuration MUST be validated before it can be set.
Therefore there seems no difference between test-then-set and set option.
But for <candiate> datastore, selecting between test-then-set and set option seems to have value.
So when we will choose to use 'test-then-set', when we will choose to use 'set'?
Do we need to clarify this in RFC6241 for this?
-Qin