Re: [netmod] J. Sterne comments on draft-ietf-netmod-system-config-00

["Jason Sterne (Nokia)" <[e-mail]>]

Thanks Qiufang. Please see inline. I got down to J6 and will continue with feedback in a subsequent reply.
Jason

From: maqiufang (A) <[e-mail]>
Sent: Monday, April 17, 2023 11:53 PM
To: Jason Sterne (Nokia) <[e-mail]>
Cc: [e-mail]
Subject: RE: [netmod] J. Sterne comments on draft-ietf-netmod-system-config-00


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.


Hi, Jason

Apologies for replying so late, there are a lot to chew on;-) And many thanks for the detailed comments, all good points.
I try to respond here and also welcome others to join the discussion if there are any other different points of view.
Please see my reply inline.

From: netmod [mailto:[e-mail]] On Behalf Of Jason Sterne (Nokia)
Sent: Thursday, March 23, 2023 7:54 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [netmod] J. Sterne comments on draft-ietf-netmod-system-config-00

Hello authors and WG,

Here are a few comments and questions on draft-ietf-netmod-system-config-00. I've labelled them for easier reference/separation.

The first few are general items. The rest are from specific sections of the doc.

##################
(J1)
General
Likewise Generally, I think the following regarding resolve-system parameter are very good questions, I gave my answers here but I think all these could also be open for more discussion.
We may need to have a more detailed discussion (virtual interim call?) about the concept of resolve-system (i.e. the automatic copying). It may get complicated to make it fully usable for an operator.
-        If resolve-system is used to have some objects copied into the <running>, is a client/user allowed to delete it?
Yes, a client/user can always delete configuration copied from <system> into <running>, I think this is independent of whether it is copied by the client/user explicitly or copied by the system automatically. If some objects is copied from <system> into <running>, then it should be treated as client/user defined configuration. But note that if deleting that copied configuration would cause the configuration invalid, the <edit-config> operation might not be performed successfully; or it might be copied into <running> again if a "resolve-system" parameter is carried in the operation.[>>JTS:] I agree.
-        What happens to the system object running when all references to it are deleted by the client/user? Does the system remove it?
No, if a data object is copied from <system> into <running>, that data object will not be automatically removed or updated. There is no difference between a data object is copied into <running> automatically or manually. Generally we don't want system making changes to configuration in <running> which the client doesn't know that. So I don't expect the system could remove that automatically.[>>JTS:] I agree. (we may want to clarify this point explicitly in the draft).
-        What happens if some system config that was auto-copied disappears from the system DS (e.g. conditionally active, i.e. turning off the qos function)? It may be odd that it stays around in running.
Per my last comment, I think it should stays around in <running>, and merged into <intended>. But if that configuration is actually not in use by the device, it may not be present in <operational>. For example, the interface configuration in <running> which is not physically present doesn't appear in <operational> but only in <intended>. There might be some other implementation which may also annotate these configuration as inactive/down.[>>JTS:] OK. The key question here was whether it stays in running (when it is no longer in system). But your answer is in line with the fact that this is a one-time copy into running and nothing ever automatically removes it from running.
-        What is copied? Only the referenced leafs (e.g. the list key), or also the other siblings (other descendants of the list entry that aren't directly referenced)?
Only the referenced leafs and the required configuration (e.g., mandatory true) sufficient to make the configuration valid are necessarily needed to copy into <running>. Sec 5.2 (Explicit Declaration of System Configuration) states that "The client does not necessarily need to declare all the contents of the list entry (i.e., the descendant nodes), only the parts that are required to make the <running> appear valid." But I find sec 5.3 (Servers Auto-configuring Referenced System Configuration) failed to mention that. This should be clearly stated in the next version.[>>JTS:] OK.
-        What if a must statement refers to a leaf in the system DS, and the presence of that leaf is required in running to make the running valid. Is that copied as well? (We've mostly been talking about objects, aka list entries, and their keys being the target of a leafref)
I had the similar question as raised in the IETF 116 NETMOD session, not only for when statement, but also cases like must statement, mandatory true data node, exactly satisfy the min-element constraints, I personally think that absence of any of these cases would make resolve-system parameter a partial solution.[>>JTS:] Yes - I think that's probably the best way to do this.
-        Section 3.2 mentions that config auto-copied into running isn't updated when that same config in system changes (during s/w upgrade). I think maybe servers that convert configuration during upgrade (a common approach) would want to convert/upgrade system config as well as any copied system config that exists in running.
That requirement can be understood. But I don't have a solution yet. Maybe define an RPC operation to interlink configuration both in <system> and <running> and use that to convert/upgrade system configuration defined in <running>? Thoughts?[>>JTS:] I think that a system that normally does config conversion during an upgrade would convert both the contents of system and the contents of running.
-        When a client deletes an override (e.g. of a mandatory leaf), does "resolve-system" populate the copy of the leaf again from system?
My understanding is that, if that node must be present to make configuration valid and "mandatory true" data nodes are also in the loop of "resolve-system" parameter (not just leafref), that will populate the copy of the leaf again from <system>, to make configuration valid. Make sense?[>>JTS:] I'm not as certain for this one. When a client is adding configuration and some reference is needed I can see it is fairly intuitive to add the missing data from 'system' to make the running valid. It *may* also make sense to do what you propose here (as long as the edit-config that contains the 'delete' operation also has 'resolve-system' specified). I guess it means that a client that wants to take advantage of resolve-system would typically include that in every single edit-data operation (whether they are adding, deleting, modifying, etc).
[>>JTS:] Overall the resolve-system function may mean an expensive (time consuming) operation on the server side. Conceptually it may mean doing a validation on the running, and then when an error is hit, searching the 'system' datastore for something that could resolve that invalid aspect. Then running validation again and hitting the next error. It may require multiple passes (since some errors are dependent on the previous error being present or 'fixed').

##################
(J2)
General

The terms 'active' and 'applied' (NMDA term) are used in a number of places in the document. We should probably clarify how those concepts differ, and define 'active' precisely (and if they don't differ, then just use one term). They feel like they don't always mean the same thing as NMDA 'applied' in this doc.

Some example uses in the doc:
-        When the device is powered on, immediately-active system configuration will be generated in <system> and applied immediately but inactive-until-referenced system configuration only becomes active if it is referenced by client-defined configuration
-        Configuration defined in <system> is merged into <intended>, and present in <operational> if it is actively in use by the device
Sure, but my understanding is that both "active configuration" and "applied configuration" refer to configuration that is in use by the device, and it's not intended to differ from the definition in NMDA.
See if sec.2 in -01 version (https://www.ietf.org/archive/id/draft-ietf-netmod-system-config-01.html#section-2)  has made that clear:

"Active system configuration refers to configuration that is in use by
   a device.  As per definition of the operational state datastore in
   [RFC8342], if system configuration is inactive, it should not appear
   in <operational>.  However, system configuration is present in
   <system> once it is generated, regardless of whether it is active or
   not."
[>>JTS:] It still feels to me like the "active" terminology in this draft isn't really exactly 1:1 synonymous with RFC8342 "applied". We may need to keep the terms a bit separate and not define active in terms of applied. We may need a concept of config that is immediately in 'system' (at power up) even though it isn't considered 'applied'.

##################
(J3)
General

It feels like the key concepts of the draft are:
-        A get-config of <running> returns a config that is considered valid by the client or offline tools (i.e. the referenced config needs to be in <running>)
-        System config shows up in intended and operational
-        System config can be overridden

But I'm not sure if the availability of the <system> DS is a key critical piece. Should we consider making that part optional? (perhaps a SHOULD)

Note that Section 5 has the following sentence so others may have been thinking along these lines at some point as well:

A device MAY implement the mechanism defined in this document without implementing the "system" datastore.

(although this contradicts other statements in the current draft, e.g the statement in section 4 about it being mandatory).
The current document states that NMDA servers compliant with this document *MUST* implement a <system> configuration datastore; but on the other hand I think there are some non-NMDA servers which can also implement a "resolve-system" parameter without implementing the <system> datastore. It is a MUST for NMDA server, but still possible for non-NMDA server to only implement a resolve-system parameter.
An NMDA server claiming to support this document should at least allow the client to see what system configuration is available; I am worried we will devalue this work without this minimal ability, we lose the standard way to copy system config into <running>, configure descendant nodes of system configuration, and the conceptual model of datastores also becomes meaningless. Make sense?

##################
(J4)
General

Today in the industry there are several server implementations that consider their <running> DS valid even though referenced system config isn't present in the <running> DS.  In this draft, section 4 makes it clear that the referenced system config MUST appear in <running>. So a server that claims support of (conformance to?) this system-config specification would consider <running> as invalid without referenced system config present.

But what about servers that don't claim to support this system-config spec. Are they OK to continue treating their <running> as valid event though referenced system config isn't present in <running>? Maybe that's out of scope but I wasn't sure whether this is worth a discussion within the WG.
If servers don't claim to support this system-config spec, I assume it's still okay to treat <running> as valid even referenced system config is not in <running>, just as they previous did. But note that these servers may communicate with new clients aware of this spec or relying on the offline validity of <running>, but I guess still no big issue. The client can simply copy referenced system config into <running> explicitly after discovering that the server don't support a resolve-system parameter.
Note that there is still an ongoing discussion about whether all the referenced system configuration should appear in <running>.

##################
(J5)
General

Should we drop/keep the <> brackets around DS names like <system>, <running>, etc? Those imply it is a leaf or other element but in NMDA it is a *value* (an identity) so you would never see it in XML brackets like that.

Note that the NMDA RFC does use brackets around the DS names.  They are a useful separator. Alternatively we could use single or double quotes but I'm not sure we do that much in other NETMOD docs for DS names.

In pre-NMDA, the DSes *do* have angle brackets around their use in get-config, copy-config, etc. (which is probably why we see it used a lot still).
That's a good catch. I would prefer we follow NMDA practice. It seems that NMDA RFC assumes  DS configuration datastore is equivalent to <DS>, e.g., the intended configuration datastore (<intended>).
I guess I need to make a thorough check of that. Thank you for pointing this out.
##################
(J6)
Abstract

I'd suggest we use this sentence to introduce the key subject of this work first, then talk about some of the mechanisms second. Proposal: add this sentence before the rest of the Abstract:

This  document describes how a management client and server handle YANG-based configuration data that is created, modified or deleted by the server itself. The system created configuration elements can be referenced (e.g. leafref) by user controlled configuration.
Sure, added. While I am unsure if we should define "user controlled configuration" here, there is no such expression used in previous RFCs. Or instead of stating "user controlled configuration", would it be better to simply say it as "configuration"?
[>>JTS:] replacing "user controlled configuration" with just "configuration" may not be clear enough (to differentiate it from the "system created configuration" at the start of the sentence. Perhaps "configuration that was explicitly created by a client"?
Here are also a few suggested edits in the next part of the abstract. Replace this:

This document updates NMDA 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 into the target configuration datastore (e.g., <running>), a "resolve-system" parameter has been defined to allow the server acting as a "system client" to copy referenced system-defined nodes automatically.

with this:

The NMDA [RFC8342] 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 has been defined to allow the server acting as a "system client" to copy referenced system-defined nodes automatically.
Okay, looks good to me.

##################
(J7)
Abstract

The last part of the abstract uses the term "overlay". Is isn't clear what that term means. I think we probably need a sentence or two instead of just that word to describe the concept.

Note this "overlay" term is also used in the Introduction.
Agree that the word "overlay" seems somewhat abstract here. How about this:
OLD:

"The solution enables
   clients manipulating the target configuration datastore (e.g.,
   <running>) to overlay and reference nodes defined in <system>,
   override values of configurations defined in <system>, and configure
   descendant nodes of system-defined nodes."

NEW:
The solution enables clients manipulating the target configuration
datastore (e.g., <running>) to overlay (e.g., copy system configuration using the same key values as in <system>) and
reference nodes defined in <system>, override values of configurations defined in <system>, and configure
descendant nodes of system-defined nodes."


##################
(J8)
1. Introduction

Add "The" in front of "NMDA" in both places in the Intro (that's how rfc8526 for example refers to it).
Sure, updated.
##################
(J9)
1. Introduction

Here are some proposed edits for the 3rd paragraph. Replace this:

In some cases, the client references a system configuration which isn't present in the target datastore (e.g., <running>). Having to copy the entire contents of the system configuration into the target datastore should be avoided or reduced when possible while ensuring that all referential integrity constraints are satisfied.

with this:

Some servers allow the client-defined configuration to reference a system configuration object which isn't present in the target datastore (e.g., <running>). The absence of the system configuration object in the datastore can render the datastore invalid from the perspective of a client or offline tools (e.g. missing leafref targets). This document describes several approaches to bring the datastore to a valid state and ensuring that all referential integrity constraints are satisfied.
Same comments as above regarding "client-defined configuration"; would it be better to replace client-defined configuration with configuration? And s/system configuration object/system configuration node/? RFC7950 doesn't use the term "object".
##################
(J10)
1. Introduction

Here are some proposed edits for the 4rd paragraph. Replace this:

In some other cases, configuration of descendant nodes of system-defined configuration needs to be supported. For example, the system configuration contains

with this:

Some servers allow the descendant nodes of system-defined configuration to be configured or modified.  For example, the system configuration may contain
Okay.
##################
(J11)
1. Introduction

Here is a proposed edit for the second last paragraph (to match an edit proposed for the Abstract above). Replace this:

To avoid clients' explicit copy/paste of referenced system-defined configuration into the target configuration datastore (e.g., <running>), a "resolve-system"

with this:

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"
This aligns with what you've proposed in the abstract sec, I've fixed.
##################
(J12)
1.1 Terminology

Here is a proposed edit for the definition of "System configuration". Instead of this:

Configuration that is provided by the system itself. System configuration is present in <system> once it's created (regardless of being applied by the device), and appears in <intended> which is subject to validation. Applied system configuration also appears in <operational> with origin="system"

I'd propose this:

Configuration that is provided by the system itself.  System configuration is present in the system datastore (regardless of being applied by the device or referenced by other configuration nodes), and appears in the intended datastore. System configuration that is considered applied (according to the NMDA RFC8342) appears in <operational> with origin="system", regardless of whether that system configuration is referenced by user created configuration or not.
Looks good.
Note that I dropped the concept of "once it is created". The term "created" gives the impression that the user takes some action. We can explain later in the doc the details of how config may appear and disappear from the system DS.
Okay.
I also dropped the part about validity. Let's keep the details of validity to the main body of the document. It feels odd to call this out here (and it highlights the validity of intended) without mentioning the validity of running (which is a key issue in this doc).
Sure, that makes sense to me.
I'd propose we also remove "the complete" from the definition of "System configuration datastore".
Good catch. I found that NMDA RFC only for the definition of <operational> and <intended> uses the "the complete" words. And also because that deletable system configuration might also be present in <factory-default>. It's not necessarily the complete system configuration that is held in the <system>.
##################
(J13)
1.1 Terminology

We do clarify later (section 3.1) that "System configuration" is different than RFC 8088 factory config. But it might be worth mentioning that right up front in the definition. Perhaps add this sentence to the end of the "System configuration" definition?

System configuration is a different and separate concept from RFC 8808 factory default configuration (which is all considered "conventional" origin, and is populated into the running only at startup time).
I have no objection to mention the difference between system configuration and factory configuration defined in 8808 in the definition. But I don't really understand what do you mean by "all considered 'conventional' origin", currently there is no origin valued conventional as defined in NMDA (https://datatracker.ietf.org/doc/html/rfc8342#section-5.3.4), and I am unsure if we can just say "factory default configuration is populated into running only at startup time" if the server has implemented a <startup> datastore.

How about we use the definition directly from the 8808 RFC:
System configuration is a different and separate concept from RFC 8808 factory default configuration (which represents a preset initial configuration that can be used to initialize the configuration of a server).
##################
(J14)
3.1. Read-only to Clients

I'd propose we break this sentence up to be clear that it is in intended even if not actively in use:
Configuration defined in <system> is merged into <intended>, and present in <operational> if it is actively in use by the device.

New sentences:
Configuration defined in <system> is merged into <intended>. It is also present in <operational> if it is actively in use by the device.
Sure, fixed. But note that this sentence has been moved into sec.5.1 Conceptual Model of Datastores in -01 given that I think it should fall within the scope of the conceptual model.
##################
(J15)
3.1. Read-only to Clients

Some proposal additional text about the RFC 8088 sentence. Replace this:

Any deletable system-provided configuration must be defined in <factory-default> [RFC8808], which is used to initialize <running> when the device is first-time powered on or reset to its factory default condition.

with this:

Any deletable system-provided configuration that is placed into <running> by the system at bootup, without being part of the contents of a <startup> datastore, must be defined in <factory-default> [RFC8808], which is used to initialize <running> when the device is first-time powered on or reset to its factory default condition.
Looks good. I've replaced that locally.
##################
(J16)
4.3.  Servers Auto-configuring Referenced System Configuration

I'd propose to add the following sentence just before "RFC 7317 enables a client...":

An example of this type of opt-in behavior can be found in RFC7317
Sure, added, but with a slight difference from your proposal:
"An example of this type of opt-in behavior can also be found in RFC7317, which enables a client ..."
Would this be better?

##################
(J17)
4.4.  Modifying (overriding) System Configuration

We should probably expand on this sentence:

But the leaf could not be deleted.

How about this instead?

The leaf (override value) can be deleted from <running>, but it can't be deleted from <system>
This sentence has already been deleted in -01. See if the following proposed sentences in Sec.5.1 of version -01 make it clearer:
" Configuration defined in <system> is present in <operational> if it
   is actively in use by the device, even if a client may delete the
   configuration copied from <system> into <running>.  For example,
   system initializes a value for a particular leaf which is overridden
   by the client with a different value in <running>.  The client may
   delete that node in <running>, in which case system-initialized value
   defined in <system> can be still in use and appear in <operational>."


If deleting the leaf from <running>, while using "resolve-system", causes the system to copy the leaf again from <system> into <running>, we should perhaps mention that here.
Right, but the precondition is that the leaf has been referenced. How about writing like this:
Note that even a referenced data node can be deleted from <running>, the system will still copy that referenced node into <running> again to make configuration valid, when a "resolve-system" parameter is carried.

##################
(J18)
4.5.1.  Server Configuring of <running> Automatically

About 10 lines up from the very end of the section, part of the response shows this:
          <application or:origin="or:system ">
            <name>ftp</name>
            <protocol>tcp</protocol>
            <destination-port>21</destination-port>
          </application>

But once the config has been copied into running, and can be read from running using <get-config>, isn't the origin really 'intended' now?
Yes, good catch. But note that only the key node "name" is present in <running>. I think It's supposed to be this:
          <application>
            <name>ftp</name>
            <protocol or:origin="or:system">tcp</protocol>
            <destination-port or:origin="or:system">21</destination-port>
          </application>
Agreed?
I'd propose to add a few words to the very last sentence like this:

Since the configuration of application "smtp" is not referenced by the client, and this server treats smtp as 'inactive-until-referenced', it does not appear in <operational> but only in <system>.
Sure, the added words make that easier to understand. I've added these in my local version. Thank you Jason.

Jason (he/him)

Best Regards,
Qiufang