IETF Logo Mail Archive

[netmod] The new "with-system" I-D

Kent Watsen <kent+ietf@watsen.net> Fri, 18 February 2022 18:56 UTC

Return-Path: <0100017f0e319379-027be0bf-2687-492d-80a1-de26673ef17c-000000@amazonses.watsen.net>
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 79DD53A12D8; Fri, 18 Feb 2022 10:56:50 -0800 (PST)
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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 4zILj1MmDTOL; Fri, 18 Feb 2022 10:56:49 -0800 (PST)
Received: from a48-110.smtp-out.amazonses.com (a48-110.smtp-out.amazonses.com [54.240.48.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBA1D3A1046; Fri, 18 Feb 2022 10:56:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1645210604; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=olWSCG+BmfACryFHUBRYXSItqj0Ycx/LFkJ3STGnZRg=; b=AyjhMfI5376eG0lsKIyrIp4K0r1vxZH19Rg+ZFzJZzSQY463+PA2ySnHBIcTxtIO DxnMymBV6gGkM7kwDBtpAaniyLmvPOwtM9fvN9lxfeKoCb8AMlJFt4J9t7rP+m8q6wW Jk8YRFf6fxeZ7ZlNezY3g+NdDP0STH+LAtnrPurI=
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
From: Kent Watsen <kent+ietf@watsen.net>
In-Reply-To: <b662256ac1f4414182247511bdd9eb70@huawei.com>
Date: Fri, 18 Feb 2022 18:56:44 +0000
Cc: draft-ma-netmod-with-system@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-ID: <0100017f0e319379-027be0bf-2687-492d-80a1-de26673ef17c-000000@email.amazonses.com>
References: <164457619900.31742.6493631046859192633@ietfa.amsl.com> <b662256ac1f4414182247511bdd9eb70@huawei.com>
To: "netmod@ietf.org" <netmod@ietf.org>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2022.02.18-54.240.48.110
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/RbrVrq6Cxghd8KBFY3cmwo_dFb8>
Subject: [netmod] The new "with-system" I-D
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, 18 Feb 2022 18:56:51 -0000

[As a contributor]

This message merely provides some insight behind the latest update to the "with-system" draft.  [PS: “with-system” is now a misnomer, it is a holdover from when the solution mimicked the “with-defaults” RFC.]

The latest “with-system” draft is nearly the polar-opposite of the -00 version.  Whereas the -00 version was very much trying to negate the need for *referenced* system-defined nodes to be copied into <running>, the latest version says that all referenced system-defined nodes MUST be copied into <running>.

For <system>-aware clients, both the existence and the definition of system-defined nodes are known by querying the <system> datastore (using the NC/RC NMDA-extensions defined in RFC 8526 and RFC 8527).

For <system>-unaware clients (e.g., "legacy" clients), there are two kinds: 1) those that never configure system-defined resources and 2) those that intend to configure system-defined resources.

For 1st kind of legacy client, no special access needs to be provided.  The solution only needs to ensure that system-defined resources exist in <running> so these clients don’t have offline-validation errors.  This is exactly what the current version of this draft ensures, as opposed to the -00 version.

For the 2nd kind of legacy client, the draft says: "How clients unaware of the <system> datastore can find appropriate configurations is beyond the scope of this document.”, but one imagines servers exposing proprietary equivalents to querying the <system> datastore.   But since this draft states that servers MUST support NMDA, any proprietary mechanism would be redundant to the NMDA-equivalent.  Further, the effort to modify a client to use the proprietary mechanism seems nearly equivalent to the effort to modify a client to use the NMDA mechanism.  Combined, it begs the question if servers would ever expose a proprietary mechanism or, instead, assume “legacy” clients would actually become <system>-aware.

That’s enough of a primer for now, cheers!

Kent

v2.23.0 | Report a Bug | By Email