Rob, please definitively state if your issue has been addressed. Kent // chair
> On Jan 6, 2025, at 9:59 PM, maqiufang (A) > <[email protected]> wrote: > > Hi, Rob, all, > > Happy new year! > > I’ve posted an updated draft. Please review the new version directly and let > me know if you have any additional comments. Thanks a lot. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/ > > There is also an HTMLized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-11 > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-system-config-11 > > > Best Regards, > Qiufang > From: maqiufang (A) [mailto:[email protected]] > Sent: Monday, December 23, 2024 5:45 PM > To: Rob Wilton (rwilton) <[email protected] <mailto:[email protected]>>; > [email protected] <mailto:[email protected]> > Subject: [netmod] Re: 2nd WGLC on system-config-10 > > Hi, Rob, > > Thanks for the valuable comments, all good points. I’ve produced a new > revision to incorporate your inputs, and the diff is available at: > https://author-tools.ietf.org/diff?url_1=https://raw.githubusercontent.com/QiufangMa/system-config/refs/heads/main/draft-ietf-netmod-system-config-11.txt > > Please also see inline… > From: Rob Wilton (rwilton) [mailto:[email protected]] > Sent: Tuesday, December 17, 2024 1:49 AM > To: Kent Watsen <[email protected] <mailto:[email protected]>>; > [email protected] <mailto:[email protected]> > Subject: [netmod] Re: 2nd WGLC on system-config-10 > > 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). > Suppose there is no other objections from the WG, I’ve made the update that > follows the way you suggested. > > (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, ... > Sure. Please review the proposed new definition: > system configuration: > RFC 8342 > <https://htmlpreview.github.io/?https://raw.githubusercontent.com/QiufangMa/system-config/refs/heads/main/draft-ietf-netmod-system-config-11.html#RFC8342> > defines it as "Configuration that is supplied by the device itself." The > current definition expands on the definition from [RFC8342 > <https://htmlpreview.github.io/?https://raw.githubusercontent.com/QiufangMa/system-config/refs/heads/main/draft-ietf-netmod-system-config-11.html#RFC8342>] > that system configuration is present in the system configuration datastore > (regardless of whether it is applied or referenced). It may also be referred > to as "system-defined configuration" or "system-provided configuration" > throughout this document. > > > (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. > The following statement has been added as the last sentence: > Note all configuration nodes in <operational> with origin "system" MUST > originate from <system>. > > (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". > Agree! Fixed with “always-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>? > Make sense, the last sentence has been 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. > Please see my last email, and feel free to propose new text if necessary. > > > 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. > Fixed. > > (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." > Fixed. > 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? > I am less sure about this. There was a long discussion regarding should the > origin=”system” be required for system config copied into <running> (e.g., a > system-provided MTU is copied into <running> with the same value), and the > majority inclined to use origin=”intended”. For me, if some system config is > copied into <running> and <running> takes precedence over <system>, thus > using origin=“intended” seems better, this has nothing to do with what values > are provided in <running> (i.e., copy vs. override). > > (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. > How about the following update: > Configurations defined in <running> take precedence over system configuration > nodes in <system> if the server allows the nodes to be modified (some > implementations may have immutable system configuration as per > [I-D.ietf-netmod-immutable-flag > <https://htmlpreview.github.io/?https://raw.githubusercontent.com/QiufangMa/system-config/refs/heads/main/draft-ietf-netmod-system-config-11.html#I-D.ietf-netmod-immutable-flag>]). > > > (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. > Would the following update be better? > The "factory-default" datastore defined in [RFC8808 > <https://htmlpreview.github.io/?https://raw.githubusercontent.com/QiufangMa/system-config/refs/heads/main/draft-ietf-netmod-system-config-11.html#RFC8808>] > is used to initialize <running> when the device is first-time powered on or > reset to its factory default condition. If a <factory-default> is supported > on a server, 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 <startup>, must be defined in <factory-default>. Otherwise, > deletable system configuration could be provided as the initial contents of > <startup> as an alternative. > > > (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 ...” > Fixed. > > (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. > I believe this comment is related to your comment #8. I think this is a case > where is somewhat ambiguous to decide which origin value to use. Should we > make this clear in the draft? > > 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 > Fixed, Thanks. > > Regards, > Rob > > Best Regards, > Qiufang > > From: Kent Watsen <[email protected] <mailto:[email protected]>> > Date: Tuesday, 10 December 2024 at 18:38 > To: [email protected] <mailto:[email protected]> <[email protected] > <mailto:[email protected]>> > 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 -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]>
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
