Re: [netmod] What's the problem with NMDA? was Re: 答复: 答复: Please clarify implementation about ‘when’

Schönwälder, Jürgen <J.Schoenwaelder@jacobs-university.de> Thu, 26 September 2019 18:35 UTC

Return-Path: <J.Schoenwaelder@jacobs-university.de>
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 B6C63120116 for <netmod@ietfa.amsl.com>; Thu, 26 Sep 2019 11:35:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=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=jacobsuniversity.onmicrosoft.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 HiBMBUbWUcWo for <netmod@ietfa.amsl.com>; Thu, 26 Sep 2019 11:35:18 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60076.outbound.protection.outlook.com [40.107.6.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A629C120103 for <netmod@ietf.org>; Thu, 26 Sep 2019 11:35:17 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kcziD2+t8xUJHm3VQeoy79Iy55ajItN2XMn/asbzROON/Q3inl4UX1Q2Y23ChAOfj4dy3lxDYe6088O+i/Hnayk05ZV6LQUuRTCepj/Fc7W3ynadTJXauKkx/vsBSH0ym95ZYPtde1YYQY469079SkmSyzvz9MLHCN2RYk9duWhonAPMPfsxkBlbDlHuruMNLpF2xzqslyZHkB4ndhJKige8FegnXF+tu2iFooYUaY1CI/iXxVbApLkG6qNvhSv9yyZDrU0RfjwFTEH5jvrSdDE5sGrm44i58pYXIC9+sVGvh2EsHjF055qwr9zrJPBVjmOSQ7UfehKZfRoU5lgMeA==
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=0FT8ZAcx1zTcrhfJ5GT0WJLa17lq5cfplw79VAG5XBs=; b=OVgdBLa6BPWiRFArbfJTtMhJ2ElnlKPFgO8c9vetbBDMsSycwesBkhWwszCGabEg74M1/BGhYfSf1YJVQKEYRQ4DHmuETvXm43YXy5bFb2502I1A2Uf3z3/JYCoq9R0IIpk4SWjVw8J5jRfqd6YTAZTqa1YWtzN5yNrHXhDQkYHoD3QG0VJwf+I4kYdkQqgRqEFpms/MyHkui5zihuqL8y/QCgXb1iY+U/9SZ3zXmWvOVBucQoimkoqIPjkKrAshJmFOjyFIWydcDUHe7mS2eJQcBhxRVWOyd4oYlR2Ddj5AFDn9lhUzilKMmgjzbJr4BnNBkG/bYjIr1q6roxX8CA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0FT8ZAcx1zTcrhfJ5GT0WJLa17lq5cfplw79VAG5XBs=; b=G8+TGKVokt043Q+iAVZh6gWzVygBngKR+AQI/winHUJv+Xg7yQC3gdFcnn6DFvSmlbyouAvnCJcubImt77tIxHApwQCb6IGamwSgih7IZ8gEp3csMVvl/LhC0H5hk2q3UuRNIW3AKjsjBKweQneu2tLgLpF8IQZTMaVVU6gkL8k=
Received: from VI1P190MB0686.EURP190.PROD.OUTLOOK.COM (10.186.159.71) by VI1P190MB0062.EURP190.PROD.OUTLOOK.COM (10.172.13.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.18; Thu, 26 Sep 2019 18:35:15 +0000
Received: from VI1P190MB0686.EURP190.PROD.OUTLOOK.COM ([fe80::e061:7f73:a47f:2ad4]) by VI1P190MB0686.EURP190.PROD.OUTLOOK.COM ([fe80::e061:7f73:a47f:2ad4%2]) with mapi id 15.20.2284.028; Thu, 26 Sep 2019 18:35:14 +0000
From: =?utf-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= <J.Schoenwaelder@jacobs-university.de>
To: Andy Bierman <andy@yumaworks.com>
CC: tom petch <ietfc@btconnect.com>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: =?utf-8?B?W25ldG1vZF0gV2hhdCdzIHRoZSBwcm9ibGVtIHdpdGggTk1EQT8gd2FzIFJl?= =?utf-8?B?OiAg562U5aSNOiDnrZTlpI06IFBsZWFzZSBjbGFyaWZ5IGltcGxlbWVudGF0?= =?utf-8?B?aW9uIGFib3V0IOKAmHdoZW7igJk=?=
Thread-Index: AQHVdJkjYln0UqVlr0W6G+qKgxe5Jw==
Date: Thu, 26 Sep 2019 18:35:14 +0000
Message-ID: <20190926183514.6jxnybluwdubrzvy@anna.jacobs.jacobs-university.de>
References: <87h84z4kmw.fsf@nic.cz> <20190926.085644.1268671875357328723.mbj@tail-f.com> <9bc06f9f3f1c87c79ccce4e1c4d40755c804875a.camel@nic.cz> <20190926.094526.272771637371098799.mbj@tail-f.com> <MN2PR11MB4366078636D6030398489551B5860@MN2PR11MB4366.namprd11.prod.outlook.com> <CABCOCHQzmDjH+7wqFmrSsnaD0T_Q1LPsDi0yuY9Ow2gSvef4SA@mail.gmail.com> <01c701d57485$400d8d40$4001a8c0@gateway.2wire.net> <CABCOCHRse2RJkoQ1r6pf+F4qP8MUn+4ypBY3M5zH+0QWoqBpuQ@mail.gmail.com>
In-Reply-To: <CABCOCHRse2RJkoQ1r6pf+F4qP8MUn+4ypBY3M5zH+0QWoqBpuQ@mail.gmail.com>
Reply-To: =?utf-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= <J.Schoenwaelder@jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: AM4P190CA0011.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:56::21) To VI1P190MB0686.EURP190.PROD.OUTLOOK.COM (2603:10a6:800:12e::7)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2001:638:709:5::7]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 80683667-2f94-4329-0310-08d742b045bd
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600167)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:VI1P190MB0062;
x-ms-traffictypediagnostic: VI1P190MB0062:
x-ms-exchange-purlcount: 1
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <VI1P190MB00626EB1891BD84B8AD1F67CDE860@VI1P190MB0062.EURP190.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 0172F0EF77
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39850400004)(396003)(366004)(346002)(376002)(189003)(199004)(6436002)(64756008)(66556008)(66446008)(66946007)(54906003)(102836004)(99286004)(66476007)(386003)(5660300002)(6506007)(8936002)(305945005)(81156014)(81166006)(7736002)(76176011)(186003)(25786009)(85182001)(3450700001)(316002)(52116002)(786003)(486006)(43066004)(1076003)(85202003)(256004)(2906002)(6486002)(6916009)(46003)(224303003)(476003)(478600001)(11346002)(14454004)(446003)(6306002)(6512007)(86362001)(6116002)(71190400001)(71200400001)(6246003)(229853002)(4326008)(777600001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1P190MB0062; H:VI1P190MB0686.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: jacobs-university.de does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: FRJrTrtb5FRq5ikvY1hVGLQ6X6nXKqrV9GQBW9rBbXsEUdijf1B+WlF5UMQkyOL4yOORp5IXv9dEHNy/eunrIZKdRsGbXZh1nrTGDX9EmoCxs9+zoyqP6ivilv7OBR8xhCxI9n7YH+1VBd7ljEfcMEAPTLlcU+B6oWGZYrXZF6aaR+nngVFt6YkLbUas1YZntGOH/r7rnjeAi4hSmRrKpwAVx6DUEnOgaJoQdpe8w8OuZhxHz+O+9ceNpRM3qdgjBs+/oQruikgwcqzWz+wW6XDze0PzZS4/G99BPOHFqAhABRVPG0ZVKl3Zhqe2fprYPanYoU5npKbtsRwe9x6nHBZCbeEUppfetnpdfP+bmQUvLtg20Yw9ogiXsVSoNBCCWID1oiB3ihGm5U2R+XgyHpqtZxOflxZ7OyXmW97n8mwfswxow9qDAcE1pwq6GwE75Z9utl6OwgbWl3xZgMNy+g==
Content-Type: text/plain; charset="utf-8"
Content-ID: <35DB3D7274361F4C9BF0E307E864769B@EURP190.PROD.OUTLOOK.COM>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: jacobs-university.de
X-MS-Exchange-CrossTenant-Network-Message-Id: 80683667-2f94-4329-0310-08d742b045bd
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2019 18:35:14.8917 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: WIk58RRunqYc/TVa6DA7c3i+YTahur16ubIPAN4ZcPA1kyUvDrS9l+mo3G4J4/bVm5bWhdFkZ3+ANDpoCVjMAzU+rWmQ+kyuerpTgo5atLU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P190MB0062
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/uwmdLHrNkpLLU3QG9glTh2hzYE0>
Subject: Re: [netmod] =?utf-8?q?What=27s_the_problem_with_NMDA=3F_was_Re=3A__?= =?utf-8?b?562U5aSNOiDnrZTlpI06IFBsZWFzZSBjbGFyaWZ5IGltcGxlbWVudGF0aW9u?= =?utf-8?b?IGFib3V0IOKAmHdoZW7igJk=?=
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: Thu, 26 Sep 2019 18:35:21 -0000

On Thu, Sep 26, 2019 at 10:44:01AM -0700, Andy Bierman wrote:

> The IETF has completely punted the problem of converting data for a
> configuration datastore to the schema tree for <operational>.

I am not sure. The <operational> model consists of the applied
configuration plus any config false extras. NMDA simplifies things
since there is now a single tree structure instead of two if you have
to handle models where applied configuration can be different than
intended config. If I configure /foo/bar in <running>, I can check
/foo/bar in <operational> whether it exists and matches what I
configured.

> Deviations may be different.  A leaf may be string in 1 tree and
> decimal64 in the other. There is an incorrect assumption that
> software developers will deal with these corner-cases (correctly and
> consistently).

Not really true for applied config. And with non NMDA, there is no
guarantee either that /foo/bar and /foo-state/bar use the same type
and semantics.
 
> The other big problem is an untested NMDA transition strategy that is not
> well understood by vendors.
> Should non-NMDA (/foo-state) be visible to <get-data> or just <get>?

Perhaps there is more explanation necessary. The idea here is that an
NMDA client should not bother to search for /foo-state, it should send
a <get> for /foo/state in operational.

Yes, NMDA requires updates to clients. Whether these are visible or in
which form they are visible to application logic likely depends on the
client design. But yes, NMDA is not for free for clients. But once you
have updated, we believe NMDA actually makes things simpler and more
consistent.

> Using the YANG library to separate the modules relies on the assumption that
> the client is capable of managing each datastore independently (instead of
> 1 schema tree per server).

Yes, YANG library can express pretty complex server model
organizations.  This does not mean that all server have to use server
model organizations.  I assume that also many clients will not be
interested to understand the entire server model, they likely want to
check the existance of only those pieces that they care about.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>