[netmod] Ambiguity on list entry deletion using edit-config

Qin Wu <bill.wu@huawei.com> Sat, 10 November 2018 16:18 UTC

Return-Path: <bill.wu@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 1E0761277C8 for <netmod@ietfa.amsl.com>; Sat, 10 Nov 2018 08:18:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 2upGkXf8f6uc for <netmod@ietfa.amsl.com>; Sat, 10 Nov 2018 08:18:32 -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 ED720124408 for <netmod@ietf.org>; Sat, 10 Nov 2018 08:18:31 -0800 (PST)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 25E894D6C85A4 for <netmod@ietf.org>; Sat, 10 Nov 2018 16:18:25 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 10 Nov 2018 16:18:26 +0000
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.171]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0415.000; Sun, 11 Nov 2018 00:18:15 +0800
From: Qin Wu <bill.wu@huawei.com>
To: NETMOD WG <netmod@ietf.org>
Thread-Topic: Ambiguity on list entry deletion using edit-config
Thread-Index: AdR5EOMNHMIJ2wK/S0id97IrYa2vTQ==
Date: Sat, 10 Nov 2018 16:18:14 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA9B10535C@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.45.111.30]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9B10535Cnkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/GuJHcwd646Qt6kRvuiqZCIbOAUc>
Subject: [netmod] Ambiguity on list entry deletion using edit-config
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: Sat, 10 Nov 2018 16:18:34 -0000

Hi,
I have confusion on list entry deletion operation defined in RFC7950.
RFC7950 said:
"
List entries can be deleted through <edit-config> by using the "operation" attribute in the list's XML
element. When a NETCONF server processes an <edit-config> request, if the operation is "delete", the entry
is deleted from the list if it exists.  If the list entry does not exist, a "data-missing"
error is returned.
"
I am wondering how do we define the list entry exist in the above Quoted text?
A list entry may include one or multiple key leafs and/or one of multiple non-key leafs.
Do we just check if requested list entry with specified key leafs exist in the list of target datastore
or do we need to check if the requested list entry with all specified leafs including key leafs and non-key leafs
exist in the list of target datastore?

In other words, do we need to validate non-key leafs within the list? What about requested list entry with specified
key leaf matching corresponding key leaf in the list of target datastore while specified non-key leaf not matching?

Do we judge this as the list entry not exist and report "data-missing" error?
or we should report new error "non-key-data-mismatching"?

If we follows RFC7950 rule and judge this case as the list entry doesn't exist, I feel this rule is too strict and RFC7950
doesn't clarify whether validation on leaf of list is required.

If my understanding is correct, if the key leaf matches, the corresponding leaf list will be delete even though
non-key leafs mismatches? But this seems not complaint with RFC7950?

Comments or clarification?

-Qin