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)
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
