Re: [netmod] WGLC - Comparison of NMDA datastores - draft-ietf-netmod-nmda-diff-03

Alexander Clemm <alex@futurewei.com> Wed, 26 February 2020 02:48 UTC

Return-Path: <alex@futurewei.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 9EDBD3A0A91; Tue, 25 Feb 2020 18:48:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com
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 ZojgFgliQRis; Tue, 25 Feb 2020 18:48:09 -0800 (PST)
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2108.outbound.protection.outlook.com [40.107.243.108]) (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 4B8523A0A93; Tue, 25 Feb 2020 18:48:09 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MuB3UVk344bboVhAh0wWrQfIh/ZE8+LrtJ2tPr7ZDfGu/BluKs6Rt73J3nfxLtpg4fFi5dpl2yN6KgY3kXGdO2HO7FhEaakrTfD/h4tMd4kyPTbb4p2FBWGN0/6YMV+UsmzNdqIi/7fqxq+/r5bIb9Rlnk2lwNX0D0qmmnpw3ctIFW/o6Tp6It8P8D/2/gH3YPVSjViF7Qr+dJr80GXd7/FPV12uDj+77t1EEF6WCcXS9BmO84lUurzTKWWvBGd1Fuw/xCQP4JbuihiCBy3orSW47MVtlwCZbKuM8JwRqzSardH5oLKC7+c1wrbol0Zv8V/vpNL5B+j1YXTVh05VIw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7TzEqmQKK9d2DAq3AOFsrLH42RtgyP08bEynGC0ErnM=; b=dymbXfU/S945br78dXRx6/SIHBS7jYQiB6aP/RrOvyOiCrb3kGceoKj295z68jsM6x66DTxxK2ZIlYrqIjNqw19FG+1W1jMMrhxI2Elu5n+f3g8Daa9wJxgK/Nu1mMUQMUr8cSeOIddYT275LsLe9Oy6oWH0LUC8zzuIcXdr8xnEKn31uBKTljn0Ei9Gf9fZm7l1evHwV1KIws8blFvUWDo/esEsDhBGXDSsryLcGiaeCjSH8PRXNrjJaHj22e7JBKLNyF/Jztbpbetyrw+7alj/rO5bn11AUEthZOs51GCtKLZsok0Do0utfRDoVDiIb7rxKwuDW3Q9FqZJJgh/kQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7TzEqmQKK9d2DAq3AOFsrLH42RtgyP08bEynGC0ErnM=; b=kDaDujI3infmtDYQ6/p2XtVkrLjlCi/5zEVv86bjO0OuvEDPxDqQoqIJ1nugLyFQNDB8Kanm3yzGQmgTwJNl8sg4Lq2/IJ9rcNUUPfy3BM9f/nxcYmeUg0RNnBtWKTMnjx01inF4UxEwQ4oQo/7TUCjdY89jlE7ESlkBfGPJqQs=
Received: from BY5PR13MB3300.namprd13.prod.outlook.com (2603:10b6:a03:1ae::21) by BY5PR13MB3013.namprd13.prod.outlook.com (2603:10b6:a03:185::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.6; Wed, 26 Feb 2020 02:48:05 +0000
Received: from BY5PR13MB3300.namprd13.prod.outlook.com ([fe80::c13e:12f9:5ebb:3385]) by BY5PR13MB3300.namprd13.prod.outlook.com ([fe80::c13e:12f9:5ebb:3385%3]) with mapi id 15.20.2772.012; Wed, 26 Feb 2020 02:48:05 +0000
From: Alexander Clemm <alex@futurewei.com>
To: Martin Bjorklund <mbj@tail-f.com>, "joelja@bogus.com" <joelja@bogus.com>
CC: "netmod-chairs@ietf.org" <netmod-chairs@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] WGLC - Comparison of NMDA datastores - draft-ietf-netmod-nmda-diff-03
Thread-Index: AQHV5cpbkGrB2wq/g0eF4L9huLkRAqgkUmQAgAhyvHA=
Date: Wed, 26 Feb 2020 02:48:05 +0000
Message-ID: <BY5PR13MB33007DC2DBA6B9FC5E585837DBEA0@BY5PR13MB3300.namprd13.prod.outlook.com>
References: <687b863b-4d54-db67-e3af-b08588c85360@bogus.com> <20200220.175834.640820639957432794.mbj@tail-f.com>
In-Reply-To: <20200220.175834.640820639957432794.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=alex@futurewei.com;
x-originating-ip: [12.111.81.95]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d9aa8a33-261a-4ee7-f94d-08d7ba664deb
x-ms-traffictypediagnostic: BY5PR13MB3013:
x-microsoft-antispam-prvs: <BY5PR13MB30134CA38B3A3C2E6D3B2EB5DBEA0@BY5PR13MB3013.namprd13.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0325F6C77B
x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10019020)(4636009)(376002)(396003)(39850400004)(366004)(346002)(136003)(189003)(199004)(81156014)(64756008)(9686003)(186003)(71200400001)(66446008)(81166006)(66556008)(66476007)(76116006)(966005)(86362001)(55016002)(4326008)(66946007)(26005)(6506007)(53546011)(2906002)(8676002)(54906003)(5660300002)(45080400002)(8936002)(7696005)(33656002)(110136005)(478600001)(52536014)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY5PR13MB3013; H:BY5PR13MB3300.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: kH53Sb+2MFtZSjfoDFKrywyylO4fBpGS76uRy+DwMTazL3sCyq4MjPDYc2aV9gj/D+LratQOvvb1ouooZXXJthQlVtoD3RKz23FdQcANY8sna79Yb8mA3vPaeamDSrCW9lJXYq8xFRqHVAA8MHOHCmSAMiiwZVYCersq0a3NDLBg+arbJZuaYGMQIBE4+dqMfmXTDbFw+IaJZxaM7yM5lTd/0vdMRABxKCaJbZOMXEGUB1Wz2kqDg5q/Vf/7hpWXSkt9JJOyL7yzUWGISnv1gxmnK0ggne/SW2EqRX5l66qvkxTNW60iysxS0Im/JSTMc6oVfkmjfQJCrh0err9tqpPfLcqKaSmdqUiPp5DtBhzTHjmAz2TFTAwABABoIRQXNh/SGOonuR/CgfEBiK8JcVz2jC4yQl/Zdgbp1mKRH2LvrkmWgSZGVu1UGOFnk9Go87iEqvOjR07KjsCGFKuFH3yaeXQhlvmD+JvyeF/CYWfkyetceR4l7UhLapZVrBcSs5wpL6IS9pqbE7kZpQJvbe5C+IywNQzDKFPr4jLLalA9sqHvrSfL8jGzvhUA6oQUS0rCQQ5VDGyh3WapWKvVWbTn0mQb1/QTYHtml27jMo5twD+iuAzT3QRMmWXjeZVq
x-ms-exchange-antispam-messagedata: muUbm0X7HvJiGgC5oiPVklWBnE4Z9vBrjd54r9hjCt3nYJT/jkf6qsA3KwWDTcVTgY13WxauT/23Ss/YecC3kacktM0PJ+VAs25eQXQyQ2Omd769SpPDREU/lZsLdlDJtqcg8t9bbl8TFwcMvrmZVw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: Futurewei.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d9aa8a33-261a-4ee7-f94d-08d7ba664deb
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2020 02:48:05.1396 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ttkP6+GJRN/NesODWY14/jPEN6rYWjEkv++8+FpUjdgmo6QbS0BFIVcofcUBBlg8aeu0uSO+yVDS+c6ggbLeDQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3013
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/f1zLE7iF91p0lIYDg11TpKXcG3Y>
Subject: Re: [netmod] WGLC - Comparison of NMDA datastores - draft-ietf-netmod-nmda-diff-03
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, 26 Feb 2020 02:48:12 -0000

Hi Martin,

thank you for your comments!  Please see replies inline, <ALEX>

--- Alex

> -----Original Message-----
> From: netmod <netmod-bounces@ietf.org> On Behalf Of Martin Bjorklund
> Sent: Thursday, February 20, 2020 8:59 AM
> To: joelja@bogus.com
> Cc: netmod-chairs@ietf.org; netmod@ietf.org
> Subject: Re: [netmod] WGLC - Comparison of NMDA datastores - draft-ietf-
> netmod-nmda-diff-03
> 
> Hi,
> 
> Joel Jaeggli <joelja@bogus.com> wrote:
> > Greetings,
> >
> > This was supposed to get processed shortly after IETF 106, however I lost
> track of it. We are therefore running a 2 week WGLC on draft-ietf-netmod-
> nmda-diff-03.
> >
> >
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatr
> acker.ietf.org%2Fdoc%2Fdraft-ietf-netmod-nmda-
> diff%2F&amp;data=02%7C01%7Calex%40futurewei.com%7C2a7d8572a82d4d
> c6fb8208d7b6263e8c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6
> 37178147700288369&amp;sdata=z8dXlaWjYttnG2vFn8YWLzld3i2TpQoMkHXks
> I9xm%2Bc%3D&amp;reserved=0
> >
> > the 02 - 03 diff is available here:
> >
> >
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-netmod-nmda-diff-
> 02%26url2%3Ddraft-ietf-netmod-nmda-diff-
> 03&amp;data=02%7C01%7Calex%40futurewei.com%7C2a7d8572a82d4dc6fb8
> 208d7b6263e8c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63717
> 8147700298323&amp;sdata=1uye5dZqb7dhIJ5DZaGb4yChrLD6BUCg8R%2BwK
> Pvnlm4%3D&amp;reserved=0
> >
> > Please send email to the list indicating your support or concerns.
> 
> 
> I have reviewed draft-ietf-netmod-nmda-diff-03 and have some comments.
> 
> o  Section 4
> 
>       (The filter dow not contain expressions that
>       would match values data nodes, as this is not required by most use
>       cases and would complicate the scheme, from implementation to
>       dealing with race conditions.)
> 
>   I don't think it is a good idea to reject filters that match
>   values.  For example, suppose I want to compare the config for a
>   specific interface.  I could do /interfaces/interfac[name='eth0'],
>   or a subtree filter.  Why should this not be possible?
> 
>   Besides, the mechanism of rejecting such filters is not defined.
>   The only text we have is this sentence within parentheses.
> 

<ALEX> In my response to Juergen, I suggested to simply remove the text in the parantheses as it is apparently confusing.  
Our intent was to keep it simple and simply use the filter to "scope" the operation.  If we want to include matching values, things get a bit more complex with no clear benefit (when you would even want to specify such filter), but admittedly we were thinking of e.g. rapidly changing operational data.  For example, what if the value matches in the source but not the target, or vice versa - do we need to specify which one we mean (source, target, or any)?  There are also the mentioned "race conditions" if snap shots are taken at different times - although I guess those would be implementation limitations.  

That said, we can of course add it in if you do feel we should have that option (and we don't get objections).  You are correct that we should specify an error for rejecting the filter.  
</ALEX>

> 
> o  leaf all in the YANG module
> 
>    s/Specifically, if one/For example, if one/
> 

<ALEX> Changed </ALEX>
> 
> o  leaf xpath-filter
> 
>   The description needs to specify the XPath context, see RFC 6991.
> 

<ALEX> Not sure what we need to be done here; the leaf uses the type definition from RFC 6991 (i.t. type yang:xpath1.0); is there anything else - please advise
</ALEX> 

> 
> o  container differences
> 
>   It is not clear what the YANG patch records reflect.  Is it the
>   patches that are required to go from "source" to "target"?  Or the
>   other way around?
> 

<ALEX> It is from source to target.  This is stated e.g. here: "The YANG-Patch data model is augmented to indicate the value of source datastore nodes in addition to the patch itself that would need to be applied to the source to produce the target."
I updated the description in the container "differences" as follows:
"            "The list of differences, encoded per RFC8072, 
             indicating the patches that need to be applied to 
             the source in order to arrive at the target, 
             with an augmentation to include source values where 
             applicable.";"
</ALEX>

> 
> o  anydata source-value
> 
>   This description needs work.  The current text isn't correct
>   ('value' is not present when the operation is 'move').
> 
>   The description should explain what this is supposed to contain.
> 

<ALEX> When the operation is 'move', we want to be able to indicate the order prior to the move.  What would you call it?  
</ALEX>

> 
> o  Section 6
> 
>   The example is confusing.  It seems the diff is the patches required
>   to go from target to source.  And the source-value contains the
>   origin present in the target, is that correct?  And the value
>   contains an origin that isn't present in neither the source nor the
>   target.
> 

<ALEX> We will review the example to ensure it's correct; will get back to you on that tomorrow.  The diff contains the patches to go from source to target, ie the patches that, when applied to source, give you the target.  

Thanks again for your review!
</ALEX>

> 
> 
> /martin
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Fnetmod&amp;data=02%7C01%7Calex%40fu
> turewei.com%7C2a7d8572a82d4dc6fb8208d7b6263e8c%7C0fee8ff2a3b24018
> 9c753a1d5591fedc%7C1%7C0%7C637178147700298323&amp;sdata=W1xgXQS
> lSzklkBAE1m324pwfJHnS%2B88OschqnJDdEBw%3D&amp;reserved=0