HI Kent,
Thanks for the reply. Please see inline ….
From: Kent Watsen <kent+i...@watsen.net>
Date: Wednesday, 18 December 2024 at 16:20
To: Rob Wilton (rwilton) <rwil...@cisco.com>
Cc: netmod@ietf.org <netmod@ietf.org>
Subject: Re: [netmod] 3rd WGLC on system-config-10 (was "2nd")
[fixing the typo in the Subject line]
Hi Rob,
Great review! Some comments below.
Kent // contributor
<snipped>
(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.
Seems reasonable, from a “goals” perspective. I wonder how hard it might be to
implement. Was there a discussion before about it hard/impossible in some
cases?
In trying to understand the case, it seems that there would have to be a
“config true” leaf that is “mandatory false” and doesn’t have a “default”, such
that it’s understood that the system will set the value.
Basically agree, but with the extension that I regard configuration annotated
with origin system, or in the system datastore, as being like system-default
configuration. I.e., in some cases a user can explicitly override the system
value, and the user configured value must always be taken in preference over a
system-default.
I think on another thread, there was an example by Jason, where the device
needs to quantize some configured value to write in the hardware. So perhaps
a user configured the value “0.12” and the system has to treat that as “0.1”.
One choice here is to reject the configuration and force the client to use the
quantized value (e.g., “0.1”). The other choice is that the system accepts the
configuration, but what gets actually applied is the quantized value. I think
that this is valid behaviour, but obviously the operational in-use value
differs from configuration, and it is the operationally in-use value that
should be reported (as per RFFC 8342) and hence it should have a different
origin. I inferred from Jason, that they may be using origin system for this
case, but I think that we should use a different origin.
Basically, I want to cleanly differentiate between a system-default value that
can be overridden by configuration vs the system deciding to modify and
override the user provided value. I think that conflating these two into the
same identity is likely to be confusing. Note – one way to tweak this would be
use derived identities, but I suspect that just introduces more, unnecessary,
complexity.
Nwo imagine this leaf being inside a client-configured list. It seems that
<system> would need to maintain a copy of the client-configured list, but only
just enough to configure the aforementioned leaf for each list-item?
Yes, I think this is required.
Note – there is no requirement for the system datastore to actually exist on
the device like other datastores. It is only an abstraction that needs to
exist at the management API layer. Or to put it another way, if the device can
figure out that it has origin system then presumably it can also figure out
that it should be returned in a get request on 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".
“Always-present” seems better.
Technically, “unconditionally-present” might be best, since it is the exact
opposite of “conditionally-present”, which is the title of the other related
Section in the draft.
(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>?
Agreed. In line with the “goal” of your comment (3), the last sentence could
be removed.
(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.
Juergen that stated that it must not be possible for a change in <system> to
invalidate <intended>.
For me, I have a slightly looser requirement. I don’t think that the device
should be modifying and making the configuration invalid on its own.
E.g., for interface entries that are tied to hardware existence, then that
configuration can become unapplied if the hardware is missing.
If the configuration is changing (or being broken) due to some client
instructed management operation (e.g., upgrade or downgrade the software), then
I agree that it is better for the client to warn and encourage the
configuration to be fixed before the operation is performed, but I’m sure that
corner cases exist where this simply doesn’t happen, or the client may want to
force the upgrade/downgrade to happen because that is more important than
keeping the configuration consistent. In that scenario, I think that the
pragmatic solution is that the device forces the configuration to become valid
again on the next write config operation.
Another example would be a license that expires, such that a subset of the
configuration is no longer valid. Choices could be:
* Configuration is left as it is, but the configuration is no longer valid,
and the configuration becomes unapplied. Attempts to configure the feature
without a valid license would be rejected with an error during validation.
* Configuration is automatically removed from running by the device (but I
don’t like this option). I prefer if the client *always* controls the contents
of running.
* Always allow the configuration, even if there is no valid license
present) but just don’t apply it if there isn’t a valid license (this seems
like generally less helpful behaviour to me).
So, in summary, perhaps not as clean as a MUST, but maybe more
pragmatic/realistic?
And he’s right for automations to succeed. That said, if there a
human-in-the-loop, it seems possible that the system could offer your idea as
an option. Maybe a sentence could be added to say that?
I’m not sure – I’m sort of after less words/examples rather than more …
For me, I interpret this as:
1. SHOULD always stay consistent.
2. If, for any reason, it becomes inconsistent then SHOULD* be made
consistent on the first operation taken.
(*) I was going to write this as MUST, but I know of cases where customers are
unhappy of systems not letting them shutdown an interface because of an
another, entirely separate, part of the configuration is not valid. Hence, I
think that some systems at least, have a “force” mode to force the
configuration change to made (perhaps still with some level of constraints).
Regards,
Rob
Minor level comments:
<snip/>
Kent
_______________________________________________
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
