Re: [netmod] Clarifications re RFC 8342 NMDA

Schönwälder, Jürgen <J.Schoenwaelder@jacobs-university.de> Fri, 03 January 2020 15:43 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 DF1C3120018 for <netmod@ietfa.amsl.com>; Fri, 3 Jan 2020 07:43:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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] 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 K3FLf7RzDpSN for <netmod@ietfa.amsl.com>; Fri, 3 Jan 2020 07:43:34 -0800 (PST)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10047.outbound.protection.outlook.com [40.107.1.47]) (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 E2A2A12000F for <netmod@ietf.org>; Fri, 3 Jan 2020 07:43:33 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nWY6aVXhKMT5EYLPgEEdU8C3pCMc/SQtLlXHPWmNg/BwHo/KQnLJVWTkBvBcWbkX0H3F3nwqZMLdLHbhRospl0FIO+tliAUjeCOIZspa/mwQIm+0nKVHunQXUf0XJtZ2NuxwAlPKRRPAmJR8WZ9WSMFDyI0Opwq+k4nNXyBNw7OYlJEHxL1zI+CNKyI09ygzMG/Ma8cAvLS14FY5LXjIl3e7CW/iiJUu1xosoHL6LMpaMmnQf7I9ZKpT/+UO9Ohq3OgmbU/g1N6SlpWLYQY1eSXD3tnPqGaFvHS7VG0n2VnKo2ZuQaAHhHd1IjknULMJKQ7XRy+W6GzsjbkhxVXDIA==
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=l5YIXvsgGIycYUYq/36SWpRF5JlGq//QgRDd2vgnHKA=; b=Cpu41wPWd4kaPjmh3kyC8TDcRYkp2eYuX6uJSAnHexZzdJmOXKeobvHI4B8DP4oOXrGF/wVftWhZ2yeQtRjFwCiZIwtI8Hs+Jo1dj/WzK0TFle73pHungwHE6FNcU4bO6cyNy7Op6Gqxzy+3CGnVuEoESxX205IyCcpg75LRYeIcoql9Tvc15u8P5MaG5CFi1KAC05t5OUEMNKmjEUbKx0dNPnhXfgLbhRe47rzp6oBiSzNj5/PpNArr7QYTSr0R9HeuTEtNPeAdUGf56p5ANfk1N18pEqyjp7vD750Y+aF1Iqj1ZS9UGCL/qh2AzT1wMSImb45/ScZyWOwK4KSoPw==
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=l5YIXvsgGIycYUYq/36SWpRF5JlGq//QgRDd2vgnHKA=; b=dHLinzaTv+H5lmdC2qrXwYLXervl+dYJV/QLATdheO1e2LD02GJoh3o2mcpRlLZZ5haZ9/SiWIi0ZrBmOwCamdwLCgHG6rNam78YiyYQx8VvKIVKBDtjv5lF9qnEZHtwy2i2gnDMwFFxhXdahXDGiIUsSSgowij6TIZprOaGPMI=
Received: from DB6P190MB0312.EURP190.PROD.OUTLOOK.COM (10.165.140.31) by DB6P190MB0104.EURP190.PROD.OUTLOOK.COM (10.172.228.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2581.12; Fri, 3 Jan 2020 15:43:31 +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.2602.012; Fri, 3 Jan 2020 15:43:31 +0000
Received: from localhost (212.201.44.247) by AM4PR08CA0049.eurprd08.prod.outlook.com (2603:10a6:205:2::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.11 via Frontend Transport; Fri, 3 Jan 2020 15:43:30 +0000
From: "Schönwälder, Jürgen" <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: AQHVwkyMTmmXOjXGPEOqIu+iW35ptA==
Date: Fri, 03 Jan 2020 15:43:31 +0000
Message-ID: <20200103154330.4iswclcwvfg4bqm5@anna.jacobs.jacobs-university.de>
References: <em2975b9f7-f2aa-4f8a-9052-e0f141dc029e@vanguard> <20200102183705.gyymbaylpmx7lkxk@anna.jacobs.jacobs-university.de> <eme5cd3fe4-f085-44ef-8fd9-233423d9c0a5@vanguard>
In-Reply-To: <eme5cd3fe4-f085-44ef-8fd9-233423d9c0a5@vanguard>
Reply-To: "Schönwälder, Jürgen" <J.Schoenwaelder@jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: AM4PR08CA0049.eurprd08.prod.outlook.com (2603:10a6:205:2::20) 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: 070faaac-df25-42d9-09c5-08d79063af17
x-ms-traffictypediagnostic: DB6P190MB0104:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <DB6P190MB01042956877E9B9909308858DE230@DB6P190MB0104.EURP190.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 0271483E06
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(346002)(136003)(396003)(39850400004)(199004)(189003)(16526019)(26005)(3450700001)(6916009)(2906002)(6496006)(8936002)(52116002)(186003)(81166006)(81156014)(8676002)(6486002)(478600001)(71200400001)(66556008)(956004)(66476007)(66946007)(64756008)(66446008)(5660300002)(316002)(1076003)(4326008)(786003)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6P190MB0104; H:DB6P190MB0312.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: VZ1zag9XWvstuBwp0+qt8AvsazOz+Uj0OjxK8Nz6eLVnw/F2L2qYH6HLXUg8BcnISHlXWBijUsKjM/1hWe9UYq7de/w/f5nR6txu3Dm4fDSCw6K606R5etqRVd1C1Atjqc1RVWMqLdTGbqoPAxMtLAivhFn0kQbWmYQE+PXrWqOCEbo471rVQjRf/a+/6PsAzdMmbD611/DnqavYCX2fZPyGDawGj2U5AY8bv5SfMa+tJ+t6rqgt/+gpQ8yFkXU/gV/AJHEnXRQR8NgbtXISu72vClpri3oo3zdf7R2+mfe8COX/uVS1fBMg/11FP56w8ZAJeOF1aBKaRDqiA9ncLWC0oMrtf2UAzzf1ZKO2+o1UN7JL51PkhzP63SezF6FlRBCPoHv/kHc2SHgGXnQzn4dPfDM6nErJt4++YLvU7f6Kgil/YtRQhpfOofPNHzNFWiF/xLFjBPtagwTAYG8PdmF0dGLk5zd6L5rfA0rm7Sc=
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <91B19F764FA800468120019BB218AEF2@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: 070faaac-df25-42d9-09c5-08d79063af17
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2020 15:43:31.3177 (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: ioYvkOjkcx0EWCl5RQpEGK7cwVWVL/f8BWQQ4d2x1paklo21AQgIT4rC1l1IjdDwsrvGNeCpDjM8vz/V+Unfpu/kVKzhbKDOBblwN8Rhvmk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0104
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/mpnrxFuHii_1zI24d1Uwr2GQuWw>
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: Fri, 03 Jan 2020 15:43:37 -0000

On Fri, Jan 03, 2020 at 11:39:31AM +0000, Jonathan wrote:
> > 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 6241 describes <get> as retrieving "running configuration and device
> state information" and <get-config> as retrieving "all or part of a
> specified configuration datastore". RFC 8526 introduces <get-data> which it
> describes as "similar to NETCONF's <get-config> operation". As far as I can
> tell, neither RFC 8342 not RFC 8526 actually identify which operation to use
> to retrieve operational state data. Am I right in assuming it would be
> <get-config>? In that case, it is similar to <get> when performed on
> <operational> as it will also return state data.

There is quite some discussion of 'operational state datastore' in
subsections of section 3.1.1 'The <get-data> Operation' in RFC 8526.
There is also an example in section 3.1.1.4.

The <get-config> operation returns config data, hence it won't return
config false data, i.e., its not a good choice for <operational>. The
reason why we have NMDA is that <get> semantics have been found to be
problematic. Hence, NMDA systems should use RFC 8526 operations
(<get-data> and <edit-data>) when talking to each other.

> And what should be the result of performing <get> on an NMDA-supporting
> server? Should it still return config true nodes from <running> plus config
> false nodes from <operational>? Or should the operation be rejected?

A proper NMDA client should never send a <get>. Supporting <get> only
makes sense for legacy clients and they might expect RFC 6241
behaviour as far as that is implementable (the reason we have NMDA is
that <get> semantics assume that <running> is identical to <applied>
config, which is just not always true).

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