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:[email protected]] On Behalf Of 
[email protected]
Sent: Tuesday, July 4, 2023 7:05 PM
To: [email protected]
Cc: [email protected]
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

[email protected]<mailto:[email protected]>

https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to