IETF Logo Mail Archive

Re: [netmod] Thoughts on draft-clemm-netmod-nmda-diff

Qin Wu <bill.wu@huawei.com> Fri, 20 July 2018 15:26 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 7AE661311D8 for <netmod@ietfa.amsl.com>; Fri, 20 Jul 2018 08:26:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 4JIebsJXqag7 for <netmod@ietfa.amsl.com>; Fri, 20 Jul 2018 08:26:35 -0700 (PDT)
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 44C7D1310AC for <netmod@ietf.org>; Fri, 20 Jul 2018 08:26:33 -0700 (PDT)
Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id A6FE0A0286620 for <netmod@ietf.org>; Fri, 20 Jul 2018 16:26:29 +0100 (IST)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.399.0; Fri, 20 Jul 2018 16:26:30 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.110]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0382.000; Fri, 20 Jul 2018 23:26:25 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Joe Clarke <jclarke=40cisco.com@dmarc.ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] Thoughts on draft-clemm-netmod-nmda-diff
Thread-Index: AdQgO9aPf9MFKlVCS3ix012Wcdg4yQ==
Date: Fri, 20 Jul 2018 15:26:24 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA9AF59763@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.124.182.175]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/RDPUAdHBN58WpDP5c53RCU6Vloo>
Subject: Re: [netmod] Thoughts on draft-clemm-netmod-nmda-diff
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
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: Fri, 20 Jul 2018 15:26:43 -0000

Add two additional thoughts,
(1) I hope NMDA datastore can be used to compare one datastore at two different timepoints, so I am not sure source and target defined in the model are enough to support this case.
(2) NMDA Base events defined in (https://tools.ietf.org/html/draft-wu-netconf-base-notification-nmda-01 can leverage NMDA diff to perform NMDA data validation, right now it is up to the server to detect validation event, but now we might rely on NMDA diff to decide which object is missing, what failed objects are. NMDA diff becomes a good tool.
On the other hand, user might want to know when applied configuration start, when applied configuration complete, based on this to see when to perform NMDA diff. To address this, we might consider two or three new notifications
In the draft-wu-netconf-base-notification-nmda-01 to help to decide when to use NDMA diff

-Qin
-----邮件原件-----)
发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Joe Clarke
发送时间: 2018年7月20日 21:52
收件人: netmod@ietf.org
主题: [netmod] Thoughts on draft-clemm-netmod-nmda-diff

I just had a chance to finish reading this.  The in-person meeting group seems to strongly support this work, and I agree.

Coming from a serviceability standpoint, I find this might serve as a precursor to a VCS-like "blame log".  Would it be reasonable to include identifiers as to who (or what) made the change and when?  Sorry if this was raised at the mic today.  I came to the room a bit late.

Joe

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

v2.23.0 | Report a Bug | By Email