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

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

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

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?
  *   What happens to the system object running when all references to it are deleted by the client/user? Does the system remove it?
  *   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.
  *   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)?
  *   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)
  *   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.
  *   When a client deletes an override (e.g. of a mandatory leaf), does "resolve-system" populate the copy of the leaf again from system?

##################
(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

##################
(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).

##################
(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.

##################
(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).

##################
(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.

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.


##################
(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.

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

Add "The" in front of "NMDA" in both places in the Intro (that's how rfc8526 for example refers to it).

##################
(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.

##################
(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

##################
(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"

##################
(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.

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.

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).

I'd propose we also remove "the complete" from the definition of "System configuration datastore".

##################
(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).

##################
(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.

##################
(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.

##################
(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

##################
(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>

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.

##################
(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?

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>.

Jason (he/him)