Re: [netmod] some comments on netmod-base-notification-nmda (validation after commit response, etc)

Qin Wu <bill.wu@huawei.com> Wed, 07 November 2018 15:38 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 DD5FD130DC3 for <netmod@ietfa.amsl.com>; Wed, 7 Nov 2018 07:38:05 -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 2Ls26Yxb1qXX for <netmod@ietfa.amsl.com>; Wed, 7 Nov 2018 07:38:04 -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 A87B0127B92 for <netmod@ietf.org>; Wed, 7 Nov 2018 07:38:03 -0800 (PST)
Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 6E40FFDC73C4E for <netmod@ietf.org>; Wed, 7 Nov 2018 15:38:00 +0000 (GMT)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 7 Nov 2018 15:38:01 +0000
Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.136]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0415.000; Wed, 7 Nov 2018 23:37:58 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: some comments on netmod-base-notification-nmda (validation after commit response, etc)
Thread-Index: AdR2rcGTDhLJgsLtSyCKImzYQfQbTQ==
Date: Wed, 7 Nov 2018 15:37:57 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA9B10099A@nkgeml513-mbs.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.126.171.31]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9B10099Ankgeml513mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/7t0bhiK6AoiqxF1bgzlFkdodOHk>
Subject: Re: [netmod] some comments on netmod-base-notification-nmda (validation after commit response, etc)
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: Wed, 07 Nov 2018 15:38:06 -0000

发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Sterne, Jason (Nokia - CA/Ottawa)
发送时间: 2018年11月6日 10:56
收件人: netmod@ietf.org
主题: [netmod] some comments on netmod-base-notification-nmda (validation after commit response, etc)

Hello,

The draft mentions that "It is possible that some configuration could not be applied to <operational> due to either validation issues, or missing resource etc."

But wouldn't validation errors cause an error response to the commit RPC? I'm not clear why there would be validation later in the commit/apply process that wasn't part of the decision to reply OK/NOK to the commit.


[Qin]:The configuration is written into running via commit operation, but commit operation doesn’t equal to validate operation. Validate operation is defined in RFC6241 to validate, e.g., candidate datastore or the <config> element containing the complete configuration in the edit config. But RFC6241 doesn’t discuss how validate operation can be applied to intended or other NMDA datastore since NMDA is introduced after RFC6241 gets published.



As described in RFC8342 and figure 2 of RFC8342

“Whenever data is written

   to <running>, the server MUST also immediately update and validate

   <intended>.

“

So validate <intended> takes place after commit operation. It involves in configuration transformations to <running> before intended validation operation.

The draft also implies that the process of moving config from running -> intended -> operational is decoupled from the application of a candidate -> running.
- Do systems reply OK/NOK to a commit before config is moved from running->intended->operational ?
[Qin]: reply OK/NOK indicates whether configuration is written into running but doesn’t tell us whether validation performed on intended is success or failure, validate operation defined in RFC6241 on candidate datastore may be different from Validation operation on intended since it clearly happens at different stage, sure validate operation can be applied to intended, but no standards explicitly specify whether validate operation can be applied to intended.
This is something we can update in this document.

- If so, then maybe it isn't correct to have a username in the notifications. A specific user/session did the commit, but then if the commit process ends after candidate->running (i.e. the reply happens at that point), then isn't it really the system moving the config from running->intended->operational?
[Qin]: See above.
Jason