[fixing the typo in the Subject line]
Hi Rob, Great review! Some comments below. Kent // contributor > (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. Good catch. > 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, ... Agree - the sentence about factory defaults datastore should be removed. > (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. 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? > (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>. 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? > Minor level comments: > <snip/> Kent
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
