Hi all,
I’ve reviewed this document. Overall, I think that this document is pretty
close, and it has significantly improved (and been simplified) during the WG
process. There are still a couple of issues that I would like to see addressed
- in particular, that the default of the "system" origin should always mean
"system configuration" (which can be overridden by running, but not the other
way around).
(2) p 3, sec 1.1. Terminology
system configuration: Configuration that is provided by the system
itself. System configuration is present in the system
configuration datastore (regardless of whether it is applied or
referenced). It is a different and separate concept from factory
default configuration defined in [RFC8808] (which represents a
preset initial configuration that is used to initialize the
configuration of a server). System configuration may also be
referred to as "system-defined configuration" or "system-provided
configuration" throughout this document.
Note that RFC 8342 already defines "system configuration". Hence you probably
should be explicit that this document expands on the definition of "system
configuration" from RFC 8342.
I don't think that you need the third sentence at all, and I would delete it,
i.e., I would delete the "It is different ..." sentence. Otherwise, there are
other datastores that system also is not, and should not be confused with,
e.g., running, intended, operational, ...
(3) p 4, sec 1.3. Updates to RFC 8342
This document also updates the definition of "intended" origin
metadata annotation identity defined in Section 5.3.4 of [RFC8342].
The "intended" identity of origin value defined in [RFC8342]
represents the origin of configuration provided by <intended>, this
document updates its definition as the origin source of configuration
explicitly provided by clients, and allows a subset of configuration
in <intended> that flows from <system> yet is not configured or
overridden explicitly in <running> to use "system" as its origin
value.
I think that there should be a statement that all data nodes in operational
that are annotated with an origin "system" MUST appear in the system datastore.
I.e., I explicitly do not want the "system" origin to identify two different
types of data nodes, with only a subset of them appearing in the <system>
datastore.
(4) p 4, sec 2.1. Immediately-Present
Immediately-present refers to system configuration which is generated
in <system> when the device is powered on, irrespective of physical
resource present or not, a special functionality enabled or not. An
example of immediately-present system configuration is an always-
existing loopback interface.
I think that "always-present" is a better and simpler name than
"immediately-present".
(5) p 8, sec 5.2. No Impact to <operational>
This work has no impact to <operational>. Notably, it does not
define any new origin identity as it is able to use the existing
"system" identity defined in Section 5.3.4 of [RFC8342]. This
document does not assert that all configuration nodes in
<operational> with origin "system" originate from <system>,
especially in cases where it is ambiguous which origin should be
used.
As per my previous comment in (3), I strongly disagree with this part of the
paragraph. I think that the there should only be one meaning of system
configuration and the system origin. If we want a new origin to indicate
whether the system has overridden user provided configuration that we will need
a new origin identity to be defined, perhaps as part of an RFC 8342-bis (or a
vendor could define their own identity). Otherwise, I think that the whole
part of configuration in running overriding the configuration in system falls
apart.
I.e., RFC 8342 states:
o system: represents configuration provided by the system itself.
Examples of system configuration include applied configuration for
an always-existing loopback interface, or interface configuration
that is auto-created due to the hardware currently present in the
device.
Why would this configuration not appear in <system>?
(6) p 9, sec 6.1. May Change via Software Upgrades or Resource Changes
* Servers reject the operation to change system configuration (e.g.,
software upgrade fails) and needs the client to update the
configuration in <running> as a prerequisite. Servers are
RECOMMENDED to include some hints in error responses to help
clients understand how <running> should be updated.
I think that the "MUST" is probably too strong, and perhaps would be better as
"SHOULD". I think that there are certain actions, e.g., software upgrade where
systems may struggle to guarantee that <intended> always stays valid, and one
valid option for handling this is to allow it to become invalid, and then
require the first edit-config/edit-data operation to get <running>/<intended>
back to being a valid datastore again.
I'm not entirely sure whether we should be providing examples here. If you do
provide any examples then I think that you should definitely strip any RFC 2119
language, but I would probably strip the text about alerting clients or
returning errors responses. Since, handling this is out of scope, the less
that is said the better, IMO.
Minor level comments:
(7) p 2, sec 1. Introduction
Some servers allow the descendant nodes of system-defined
configuration to be configured or modified. For example, the system
configuration may contain an almost empty physical interface, while
the client needs to be able to add, modify, or remove a number of
descendant nodes. Some descendant nodes may not be modifiable (e.g.,
the interface "type" set by the system).
I suggest perhaps expanding the example:
For example, the system configuration may contain an almost empty physical
interface list entry, whose existence in the system configuration is tied to
the presence of particular hardware, while the client needs to be able to add,
modify, or remove a number of descendant nodes.
(8) p 5, sec 2.2. Conditionally-Present
Conditionally-present refers to system configuration which is
generated in <system> based on specific conditions being met in a
system. For example, if a physical resource is present (e.g., an
interface card is inserted), the system automatically detects it and
loads associated configuration; when the physical resource is not
present (an interface card is removed), the system configuration will
be automatically cleared. Another example is when a special
functionality is enabled, e.g., when a license or feature is enabled,
specific configuration may be created by the system.
"the system configuration will be automatically cleared” => “the interface will
automatically be removed from <system>, but <running> is left unchanged."
Should we clarify section 5.3.4 of RFC 8342 here, to indicate that the origin
for such system created resources should always be reported as system,
regardless of whether the interface is also configured in <running>, e.g., to
configure properties under the interface?
(9) p 9, sec 6.3. Modifying (Overriding) System Configuration
In some cases, a server may allow some parts of system configuration
(e.g., a leaf's value) to be modified. Modification of system
configuration is achieved by the client writing configuration data in
<running> that overrides the values of matched configuration nodes at
the corresponding level in <system>. Configurations defined in
<running> take precedence over system configuration nodes in <system>
if the server allows the nodes to be modified. The immutability of
system configuration is defined in [I-D.ietf-netmod-immutable-flag].
Since the immutability flag still seems to be having quite active discussion,
I'm not sure whether it is really a good idea for it to be referenced here. If
you do want to keep, I would make this more informational rather than normative.
(10) p 10, sec 7.1. The "factory-default" Datastore
Any deletable system-provided configuration that is populated as part
of <running> by the system at boot up, 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.
I think that the paragraph should be predicated on whether RFC 8808 is
implemented by the server.
(11) p 26, sec Appendix B. Key Use Cases
And the contents of <system> keep unchanged since the interface is
not physically present:
“And the contents of <system> keep unchanged since ...” => “And the contents of
<system> remain unchanged, only containing the "lo" loopback interface, since
...”
(12) p 28, sec Appendix B. Key Use Cases
<interfaces xmlns="urn:example:interfacemgmt"
xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"
or:origin="or:intended">
<interface or:origin="or:system">
<name>lo0</name>
<type>loopback</type>
<enabled or:origin="or:default">true</enabled>
<ip-address>127.0.0.1</ip-address>
<ip-address>::1</ip-address>
<description>system-defined interface</description>
</interface>
<interface>
<name>et-0/0/0</name>
<type or:origin="or:system">ethernet</type>
<enabled or:origin="or:default">true</enabled>
<ip-address>192.168.10.10</ip-address>
<description>pre-provisioned interface</description>
</interface>
</interfaces>
Should "interface" and "name" not be origin system, with only the ip-address
and description being marked as origin intended? This applies to the B.4
example as well.
Nit level comments:
(13) p 5, sec 2.2. Conditionally-Present
Conditionally-present refers to system configuration which is
generated in <system> based on specific conditions being met in a
system. For example, if a physical resource is present (e.g., an
interface card is inserted), the system automatically detects it and
loads associated configuration; when the physical resource is not
present (an interface card is removed), the system configuration will
be automatically cleared. Another example is when a special
functionality is enabled, e.g., when a license or feature is enabled,
specific configuration may be created by the system.
loads associated => loads the associated
Regards,
Rob
From: Kent Watsen <kent+i...@watsen.net>
Date: Tuesday, 10 December 2024 at 18:38
To: netmod@ietf.org <netmod@ietf.org>
Subject: [netmod] 2nd WGLC on system-config-10
NETMOD WG,
We did a 2nd WGLC in August on the -08 version of this document. There were
major concerns raised then, which Qiufang addressed in -09 with an update that
removed the need to copy nodes into <running>. Andy and Juergen raised some
additional concerns on -09, which I think are addressed in this -10.
This email begins a two-week WGLC on:
System-defined Configuration
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-10
Please take time to review this draft and post comments by Dec 24. Whilst
favorable comments are welcomed, given that this document already has a lot of
support, the primary focus now is to determine if there are any objections or
concerns. If no objections or concerns are raised, this document will
automatically progress to the next step.
>From the IPR poll in March, there is no known IPR for this document:
https://mailarchive.ietf.org/arch/msg/netmod/IpzWIAbgifXoKaNfLhEDmYbyXkY/
Kent // co-chair
_______________________________________________
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
