Hi, Rob, Kent,
(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).
My concern is related to the statement in RFC 8342: <intended> MUST always be a
valid configuration data tree.
If a client references an interface eth0 in <running> which is afterwards
physically removed and thus disappears from <system>, we end up with dangling
reference in <intended>. Similarly, If the upgrade/downgrade happens before
keeping the configuration consistent, the invalidity of configuration between
t1 (the upgrade/downgrade) and t2 (the first operation to make configuration
consistent) seems also a violation of that statement.
I kind of agree that we should say less rather than more, especially when this
is beyond the scope of the document. The examples here are used only to
enlighten some possible solutions, we can remove these, but I am really unsure
we should relax MUST to SHOULD here.
Regards,
Rob
Best Regards,
Qiufang
_______________________________________________
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
