[netmod] Re: 3rd WGLC on system-config-10 (was "2nd")

["Rob Wilton (rwilton)" <[e-mail]>]

HI Kent,

Thanks for the reply.  Please see inline ….

From: Kent Watsen <[e-mail]>
Date: Wednesday, 18 December 2024 at 16:20
To: Rob Wilton (rwilton) <[e-mail]>
Cc: [e-mail] <[e-mail]>
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