Subject: [netmod] FW: New Version Notification for draft-ma-netmod-with-system-01.txt

From: "maqiufang (A)" <[email-masked]>
Date: Mon, 14 Feb 2022 07:12:18 +0000

Hi, all
V-01 is available now: https://www.ietf.org/archive/id/draft-ma-netmod-with-system-01.txt. 
According the discussion around system configuration on the list, especially the thread "MUST offline-validation of <running> alone be required" (thank you all for being involved in the discussion and sharing your valuable ideas) , the authors tried to seek convergence and updated the draft based on some folks' comments.
The most significant changes compared to the previous version are to remove the "with-system" query parameter and define a new parameter named "resolve-system" to allow the server to copy referenced system configuration automatically in order to make <running> valid.
Clients unware of this parameter can explicitly declare the referenced system configuration on their own to satisfy the referential integrity of <running>.

For more details, please review the draft, comments and suggestions are welcome!

Best Regards,
Qiufang

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, February 11, 2022 6:43 PM
To: Fengchong (frank) <[email-masked]>; Fengchong (frank) <[email-masked]>; Jan Lindblad <[email-masked]>; Qin Wu <[email-masked]>; Qin Wu <[email-masked]>; maqiufang (A) <[email-masked]>
Subject: New Version Notification for draft-ma-netmod-with-system-01.txt

A new version of I-D, draft-ma-netmod-with-system-01.txt
has been successfully submitted by Qiufang Ma and posted to the IETF repository.

Name:		draft-ma-netmod-with-system
Revision:	01
Title:		System-defined Configuration
Document date:	2022-02-11
Group:		Individual Submission
Pages:		40
URL:            https://www.ietf.org/archive/id/draft-ma-netmod-with-system-01.txt
Status:         https://datatracker.ietf.org/doc/draft-ma-netmod-with-system/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ma-netmod-with-system
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ma-netmod-with-system-01

Abstract:
   This document updates NMDA [RFC8342] to define a read-only
   conventional configuration datastore called "system" to hold system-
   defined configurations.  To avoid clients' explicit copy/paste of
   referenced system-defined configuration, a "resolve-system" parameter
   has been defined to allow the server acting as a "system client" to
   populate referenced system-defined nodes automatically.  The solution
   enables clients to reference nodes defined in <system>, overwrite
   values of configurations defined in <system>, and configure
   descendant nodes of system-defined nodes.

The IETF Secretariat

---

From: Kent Watsen <[email-masked]>
Date: Fri, 18 Feb 2022 18:56:44 +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