Re: [netmod] Clarifications re RFC 8342 NMDA

Schönwälder, Jürgen <J.Schoenwaelder@jacobs-university.de> Thu, 02 January 2020 18:37 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 AAFD91200F7 for <netmod@ietfa.amsl.com>; Thu, 2 Jan 2020 10:37:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 0iT3ZogvWUTd for <netmod@ietfa.amsl.com>; Thu, 2 Jan 2020 10:37:10 -0800 (PST)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140051.outbound.protection.outlook.com [40.107.14.51]) (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 2B55512006F for <netmod@ietf.org>; Thu, 2 Jan 2020 10:37:10 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iLKmuzBdv1J/q0NANUva8s8NiU3Pjy21RwBCgDG2KOTWTyWWssDoQwn3NFc2kRueAqMaZz4fV9tJSSCCUqxKSxFtz5FPFUiqHSHvr2hvwp+bfNXV9Dhb4ua6Yiw+90jOmenq0WUtzlz6NrQZ2VBgG3mZ66IvAdb+eYzkiUeAzzj3AUlhDg6IuzUuvA9fmEmB18YokKUzU+3qTreBa7hqBTPjawV9E0AcZz1VwU1oDDcYCtpFkFb6SBbd/Fe7ljeEjNmAznCwzY7lBze6iK0FatzkUA3QEUqZGauPEXTuJvqLu5X6Miyy40LQczBKBn+w/kK/uFG93EdU5KoPVnLNBA==
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=Uy85KLN4YCF8T4zztIOL9b88RzLJPtyN1hm6xdOQ8ug=; b=D1sYpE+F4vr7zYUTd+eD2yqtwsWooVmUareBwX+kg/MDpP3rxTWIITG4UaU4r0dJY8ABURzIkPOwodDAD4Xs6B/9AmIbBSBzL4wK0TdOWBOC1yNPXAcTecs/ngoBstiAPqk2sin0J+IMiQE15VCNRfVYz1XB0PHul+rmwGV2r/1etBgLTha5TFadE/CQBsEhI6IzwzKwopUqdZEWUJUjeWqWmeaflXmrk4NJSgqNEL54+l7sHUHkSm1QQg2jO+iKh33fHA86pzluWLCVFE3Vyxh4JME8wBdfGPfiCubq2sq5pM49ArCWa2dH+rXwrg8FxOY5KZDwFcPFkSANsIHFog==
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=Uy85KLN4YCF8T4zztIOL9b88RzLJPtyN1hm6xdOQ8ug=; b=Ob2SctP1mTiqQt8RcAXyPz/lTUXvfIRHQmIaCnSNRE7GhOqBcMEtRqICS/841841x+qe7OpbGyYkcorZIlHKY8z0Xp0blPiLFhhcG/cLj9PvlU6Mg+HPdPjyhEc3WS52PbP+QM4Gay0826eoUN/UpEwq7ju4+BwcYZOd0vovelc=
Received: from DB6P190MB0312.EURP190.PROD.OUTLOOK.COM (10.165.140.31) by DB6P190MB0567.EURP190.PROD.OUTLOOK.COM (10.175.241.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.11; Thu, 2 Jan 2020 18:37:07 +0000
Received: from DB6P190MB0312.EURP190.PROD.OUTLOOK.COM ([fe80::bcdc:4d6:7dfc:a946]) by DB6P190MB0312.EURP190.PROD.OUTLOOK.COM ([fe80::bcdc:4d6:7dfc:a946%6]) with mapi id 15.20.2581.014; Thu, 2 Jan 2020 18:37:07 +0000
Received: from localhost (212.201.44.247) by FRYP281CA0008.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.12 via Frontend Transport; Thu, 2 Jan 2020 18:37:06 +0000
From: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= <J.Schoenwaelder@jacobs-university.de>
To: Jonathan <jonathan@hansfords.net>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] Clarifications re RFC 8342 NMDA
Thread-Index: AQHVwY/fy7SITk65WEysD0s2tUsgKqfXtCOA
Date: Thu, 2 Jan 2020 18:37:06 +0000
Message-ID: <20200102183705.gyymbaylpmx7lkxk@anna.jacobs.jacobs-university.de>
References: <em2975b9f7-f2aa-4f8a-9052-e0f141dc029e@vanguard>
In-Reply-To: <em2975b9f7-f2aa-4f8a-9052-e0f141dc029e@vanguard>
Reply-To: =?iso-8859-1?Q?Sch=F6nw=E4lder=2C_J=FCrgen?= <J.Schoenwaelder@jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: FRYP281CA0008.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10::18) To DB6P190MB0312.EURP190.PROD.OUTLOOK.COM (2603:10a6:6:34::31)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=J.Schoenwaelder@jacobs-university.de;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [212.201.44.247]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8850c76e-d8cc-4e43-8577-08d78fb2c4b3
x-ms-traffictypediagnostic: DB6P190MB0567:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <DB6P190MB05674FCCC83261B8526EE944DE200@DB6P190MB0567.EURP190.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0270ED2845
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(346002)(396003)(39840400004)(136003)(189003)(199004)(64756008)(66556008)(6486002)(6916009)(956004)(186003)(66446008)(16526019)(71200400001)(66946007)(66476007)(26005)(478600001)(1076003)(8676002)(86362001)(786003)(6496006)(5660300002)(8936002)(3450700001)(316002)(81166006)(4326008)(81156014)(52116002)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6P190MB0567; H:DB6P190MB0312.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: BCL:0;
x-microsoft-antispam-message-info: vPU+ZrVrO4UoijAekeCZd2ow7UzTf+wyp7qyBNLg1j284xbyDbgKBhMVo52iybSCDF4AgKzwXKXV+K56x3Wpu1USe0QogCoHuV2q0JQp4VPO9NmJyOGyFzoErzEIfeXv2FuJOTYXXphdaFSXrXJLejrXmTVQpbJyjB/hjEcAWWkiL+X5IImU+Hm7C7Ega9tK8rZ4ArvXvgDslqP7f8yJP1eKCrZ4RTFR8e1SZuSZsJZfw1Y+I/rk1vdFm43cQITQS69fIrMtELqBJc0nTkFGLMBaHHqEgx6+i9cIbXfW8ZNgM2V6yHvv8QA25d41Q6NzMHLQJYu1pQt+NXNvMH0mF4sWEXtNioCf5zPRlJQ6i7AggjzCFwo3I13X/oEjR84X0yKS1OzKupYYF1uzKg+pZIuyo9HT8tmsNOJYSMj/0Tc4UQdbLs0HELuG1A1XbGUeREYLJh6usVDLjIDeo/jiKMCd/an/j9EDh4dVAr60HCA=
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <FA3F9756E378FA479CB5E1D3A0F37577@EURP190.PROD.OUTLOOK.COM>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: jacobs-university.de
X-MS-Exchange-CrossTenant-Network-Message-Id: 8850c76e-d8cc-4e43-8577-08d78fb2c4b3
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2020 18:37:07.3408 (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: OyQaCnbkF+rOBulRrzIvNssgP/Tjq8bNFCRxw+Z0ushUOROc9SulIckyZexaGXUp/TlCQPRVxVyqoXMpp16rrMiA7oWA+kAd81A+89ABeg8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0567
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/E3LooXKY6UiKNRbdtjNf0FF-dzg>
Subject: Re: [netmod] Clarifications re RFC 8342 NMDA
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, 02 Jan 2020 18:37:14 -0000

On Thu, Jan 02, 2020 at 05:12:30PM +0000, Jonathan wrote:
> Hi,
> 
> I have been reading through RFC 8342 and have a number of questions I
> couldn't resolve after a couple of passes through. Can anyone advise?
> The RFC states "The startup configuration datastore may not be supported by
> all protocols or implementations", "the candidate configuration datastore
> may not be supported by all protocols or implementations" and "<running>
> MUST be supported if the device can be configured via conventional
> configuration datastores". I can find no explicit guidance on:The intended
> configuration datastore: The RFC does state, "Whenever data is written to
> <running>, the server MUST also immediately update and validate <intended>."
> Is <intended> mandatory for NMDA-supporting servers that support
> <running>?

It is not mandatory to expose <intended>. On simple implementations,
<intended> may be identical with <running>.

> The operational state datastore: The RFC does state it is "a
> read-only datastore that consists of all "config true" and "config false"
> nodes defined in the datastore's schema" and that "the datastore schema for
> <operational> MUST be a superset of the combined datastore schema used in
> all configuration datastores ...". Is <operational> mandatory for
> NMDA-supporting servers?

Since <operational> is the only way to expose config false nodes for
an NMDA server, it is kind of mandatory as soon as you have config
false nodes to expose.

> RFC 8525, section 1 states, "For backwards
> compatibility, an NMDA-supporting server SHOULD populate the deprecated
> "/modules-state" tree in a backwards-compatible manner."That suggests an
> NMDA-supporting server SHOULD be backwards-compatible with a
> non-NMDA-supporting client. Is that correct?

This might be a misuse of 'SHOULD' since backwards-compatibility is
important for a transition phase but not in pure NMDA environments.
The idea here was to encourage support for a transition phase where
NMDA and non-NMDA implementations may need to co-exist.

> Can an MMDA-supporting client be
> backwards-compatible with a non-NMDA-supporting server?

An NMDA client should talk NMDA with an NMDA server. Whether an NMDA
client also talks to non-NMDA servers is up to the implementor. I
personally would distinguish between the protocol interaction and the
data model of the management application. To me, it makes a lot of
sense to make the data model of the management application NMDA aware
even if the application is used with non-NMDA servers.

> I can't find any
> mention of YANG version 1 in RFC 8342. Is it safe to assume NMDA is
> compatible with YANG version 1 modules?

It should not matter whether the model is written in YANG 1 or 1.1.
However, core data models are moving towards YANG 1.1.

/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/>