[netmod] FW: I-D Action: draft-ietf-netmod-system-config-02.txt

Hi, all

v-02 is available now, most of the update reflects comments raised by Jason (thank you Jason!), as well as some recent discussion happened on the list.

A diff compared from the previous version is available at:

https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-system-config-02.

With the ongoing discussion of the issue "should referenced system configuration always be copied into <running>", there are some other notable issues which have already been touched on or recognized by other folks, the authors feel we might need more discussion:

*             What if the system configuration is updated, and the stale copy is still present in <running>? What's the consequence?

The current document does not allow the configuration copied from <system> into <running> to be updated automatically if the configuration in <system> is updated. The intent is still not to surprise client with unexpected changes.

Notice that Kent was suggesting two options:"

1)      The system-draft says non-necessary fields MUST NOT be copied into <running>.  This may be difficult to enforce, but I believe it's viable.

2)      The system-draft says that it is the server's responsibility to migrate the data in running/startup/candidate during a software update"

            And also maybe option 3): the server updates the configuration in <running> to ensure consistence with what is in <system>.

*             Should the origin="system" be required for system configuration copied into <running>?

This affects the XML snippets example in sec.5.5.1 , the origin value of the key name of application "ftp" and "tftp" which is copied into <running> to fulfil leafref constraints.

There was a proposal to use origin="intended". But after think about it, basically when <running> is merged with <system> to become <intended>, configuration in <running> takes precedence over <system> if the node allows to be modified.

So origin="intended" seems no issue in this case.

But suppose the system defined node is immutable, a client writing a same value of that node in <running> will still cause it to appear in <operational> with origin="intended"? that doesn't seem true since it's not really about "override".

I personally feel it better to use origin="system" for consistence, but would also welcome different opinions.

Thoughts?

Best Regards,
Qiufang

-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
Sent: Tuesday, July 4, 2023 7:05 PM
To: i-d-announce@ietf.org
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-system-config-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This Internet-Draft is a work item of the Network Modeling

(NETMOD) WG of the IETF.

   Title           : System-defined Configuration

   Authors         : Qiufang Ma

                     Qin Wu

                     Feng Chong

   Filename        : draft-ietf-netmod-system-config-02.txt

   Pages           : 46

   Date            : 2023-07-04

Abstract:

   This document describes how a management client and server handle

   YANG-modeled configuration data that is defined by the server itself.

   The system-defined configuration can be referenced (e.g. leafref) by

   configuration explicitly created by a client.

   The Network Management Datastore Architecture (NMDA) defined in RFC

   8342 is updated with a read-only conventional configuration datastore

   called "system" to hold system-defined configuration.  As an

   alternative to clients explicitly copying referenced system-defined

   configuration into the target configuration datastore (e.g.,

   <running>) so that the datastore is valid, a "resolve-system"

   parameter is defined to allow the server acting as a "system client"

   to copy referenced system-defined nodes automatically.  This solution

   enables clients manipulating the target configuration datastore

   (e.g., <running>) to overlay (e.g., copy system configuration using

   the same key value as in <system>) and reference nodes defined in

   <system>, override values of configurations defined in <system>, and

   configure descendant nodes of system-defined nodes.

   This document updates RFC 8342, RFC 6241, RFC 8526 and RFC 8040.

The IETF datatracker status page for this Internet-Draft is:

https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/

There is also an htmlized version available at:

https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-02

A diff from the previous version is available at:

https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-system-config-02

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

_______________________________________________

netmod mailing list

netmod@ietf.org<mailto:netmod@ietf.org>

https://www.ietf.org/mailman/listinfo/netmod