Please see inline below. I think there are a couple of important fundamental issues raised below:
Only auto-copy things missing to make <running> valid vs auto-copy the entire contents of a referenced list entry from system->running. When to auto-copy: at edit time or at validation time. Jason From: maqiufang (A) <maqiufa...@huawei.com> Sent: Saturday, May 11, 2024 3:34 AM To: Jan Lindblad (jlindbla) <jlind...@cisco.com>; Jason Sterne (Nokia) <jason.ste...@nokia.com> Cc: Qin Wu <bill...@huawei.com>; chong feng <fengchongl...@gmail.com>; Kent Watsen <k...@watsen.net>; netmod@ietf.org Subject: RE: [netmod] Re: WGLC on system-config-05 [resending due to mailarchive issues] From: maqiufang (A) Sent: Saturday, May 11, 2024 3:38 PM To: Jan Lindblad (jlindbla) <jlind...@cisco.com<mailto:jlind...@cisco.com>>; Jason Sterne <jason.ste...@nokia.com<mailto:jason.ste...@nokia.com>> Cc: Qin Wu <bill...@huawei.com<mailto:bill...@huawei.com>>; chong feng <fengchongl...@gmail.com<mailto:fengchongl...@gmail.com>>; 'Kent Watsen' <k...@watsen.net<mailto:k...@watsen.net>>; NETMOD Group <netmod@ietf.org<mailto:netmod@ietf.org>> Subject: RE: [netmod] Re: WGLC on system-config-05 Hi, Jason and Jan, Thank you both for your valuable comments, all goods points, much appreciated. Please also find my reply below inline... From: Jason Sterne (Nokia) [mailto:jason.ste...@nokia.com] Sent: Saturday, May 11, 2024 12:09 AM To: Jan Lindblad (jlindbla) <jlindbla=40cisco....@dmarc.ietf.org<mailto:jlindbla=40cisco....@dmarc.ietf.org>>; maqiufang (A) <maqiufa...@huawei.com<mailto:maqiufa...@huawei.com>>; Qin Wu <bill...@huawei.com<mailto:bill...@huawei.com>>; fengchong...@gmail.com<mailto:fengchong...@gmail.com> Cc: Kent Watsen <k...@watsen.net<mailto:k...@watsen.net>>; netmod@ietf.org<mailto:netmod@ietf.org> Subject: RE: [netmod] Re: WGLC on system-config-05 Hi all, Please see inline. (Note: I haven't read Rob's review yet) [Qiufang] I am working on it now;-) Jason From: Jan Lindblad (jlindbla) <jlindbla=40cisco....@dmarc.ietf.org<mailto:jlindbla=40cisco....@dmarc.ietf.org>> Sent: Tuesday, May 7, 2024 8:57 AM To: maqiufang (A) <maqiufa...@huawei.com<mailto:maqiufa...@huawei.com>>; Qin Wu <bill...@huawei.com<mailto:bill...@huawei.com>>; fengchong...@gmail.com<mailto:fengchong...@gmail.com> Cc: Kent Watsen <k...@watsen.net<mailto:k...@watsen.net>>; netmod@ietf.org<mailto:netmod@ietf.org> Subject: [netmod] Re: WGLC on system-config-05 CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Authors, WG, I have taken a good read of the -05 version of the system-config document now (thanks for the reminder to review, btw!). I think this is a well written and important document. It is touching some of the foundational aspects of the entire NETCONF/YANG cluster of documents, which I see as much needed maintenance. Just as when priceless paintings are being restored, however, extreme care is needed. As we have seen with previous revisions of this document, there will be strong opinons about specific wording in some cases, even when we are very close in our views. [Qiufang] Thanks. I also agree that this document might need careful review from the WG, a lot of good discussion around this work happened, but the authors sometimes feel it not easy to document the outcome accurately or reflects the real WG intention, we appreciate your review and comments. Here are some points I noted while reading, in order of appearance, and of greatly varying significance. Only point #1, in my opinion, is a major problem. #1 Running MAY become invalid Section 4.2, which discusses software upgrades etc., has some wording that is new in -05: If system configuration changes (e.g., due to device upgrade), <running> MAY become invalid. The server behaviors of migrating updated system data into <running> is beyond the scope of this document. That said, the following gives a list of examples of server implementations that might be possible: I think this is unacceptable and a direct violation of RFC 7950 section 8.1. Prior to this document, I am not aware of any RFC that allows running to become invalid under any circumstances. I think the always valid running is a very important part of the contract between servers and clients. [Qiufang] The authors added this in -05 trying to document some outcome at the interim, but you are making a good point, Jan. I agree to remove this first sentence and say nothing about the validity of <running> in this draft, what is stated in 7950 is still the case that way. The client's ability to validate a configuration may not be very important in itself, but client's ability to *reason* about the server's configuration is, and by allowing invalid configurations (contradiction in terms?), this gets very hard. [>>JTS:] I can see Jan's concern here. Perhaps we should could replace the "If system configuration changes..." paragraph with the following: The behavior of the server when system configuration changes (e.g. due to device upgrade) is outside the scope of this document. That said, , the following gives a list of examples of server implementations that might be possible: [Qiufang] Thank you Jason for the proposed text, regarding the first sentence (starting with "The behavior of the server..."), I am thinking whether we need to document it more specific to software upgrade scenario given the statement in sec5.3 that If the "resolve-system" parameter is not given by the client, the server should not modify <running> in any way otherwise not specified by the client. OLD: The behavior of the server when system configuration changes (e.g. due to device upgrade) is outside the scope of this document. NEW: The behavior of the server when software is upgraded is not specific to system configuration and outside the scope of this document. Better? [>>JTS:] I don't think we should restrict the statement to only being about the software upgrade scenario. This section 4.2 is about changes to <system> no matter how they happen (upgrade, but also other reasons mentioned in the draft). The server behavior when those changes occur can vary whether system changed because of upgrade or those other reasons. I also think 5.3 is a somewhat different issue. That 5.3 statement you quote is more general (and not specifically related to changes to <system> that could trigger changes to <running>, e.g. during an upgrade). and then also remove the middle bullet "Servers don't migrate..." [Qiufang] Sure, and also the other two bullets slightly rephrased as follows to say nothing about the validity of <running>: * Servers migrate system configuration update into <running> with the clients' awareness * Servers rejects the upgrade operation and needs the client to update the configuration in <running> as a prerequisite [>>JTS:] I think it was OK to mention validity in the other two bullets. But now that I look at this again I'm not positive what is meant by "with the clients' awareness". It may be better to remove that part and just say "Servers migrate the system configuration update in <running> to keep <running> valid." (notice I changed 'into' to 'in' since it may be just migration of that data in the running rather than an actual copy back into running). #2 <running> merged into <system> The fourth paragraph of section 5.1 starts: To ensure the validity of <intended>, configuration in <running> is merged into <system> to become <intended>, in which process, configuration appearing in <running> takes precedence over the same node in <system>; additional nodes to a list entry or new list/leaf- list entries appearing in <running> extends the list entry or the whole list/leaf-list defined in <system> if the server allows the list/leaf-list to be updated. I find the wording "<running> merged into <system> to become <intended>" a bit odd. To me, this grammatical construct suggests that the contents of running would end up in system, which I don't believe was the authors' intent. Could "with" be a more natural choice of word? I.e. "<running> merged with <system> to become <intended>" [Qiufang] The original intent was to highlight the content of <intended> is generated by <running> being merged towards <system> (instead of <system> being merged towards <running>), i.e., what's in <running> takes the first priority. If a modifiable leaf node appears in both datastores, the result is set to the value of the leaf instance found in <running>. But you're right that this would probably cause some confusion. I agree to use "with" here because the second half part already clarifies that <running> takes precedence over <system>. Will fix it in the new revision, thanks a lot. #3 Defaults vs system config The last paragraph of section 5.2 ends: The client can explicitly declare (i.e., configure in the datastore like <running>) the list entries (with at least the keys) that are referenced elsewhere in <running>. The client does not necessarily need to declare all the contents of the list entry (i.e. the descendant nodes), only the parts that are required to make the datastore appear valid. While this makes sense in many ways, I wonder how defaults are to be interpreted in this situation. Let's say the system configuration contains a loopback interface "lo0" with leaf "enabled" set to "false". Someone wants to refer to this interface, so they create an "lo0" interface in running. According to the interface YANG module, the default value for leaf "enabled" is "true". When a client reads running, they may get the impression that the interface is enabled when it is not. Is this a problem? What if there is another overlay-related YANG module that refers to the interface list for underlay interfaces. The overlay YANG only allows referring to enabled interfaces as underlay. Would referring to the seemingly enabled interface be allowed? Perhaps the example in 5.5.3 or thereabout could be fleshed out to cover YANG module defaults as well? [>>JTS:] I suppose we have two options here: 1) Say that the system values override defaults in the running, or 2) Say that any leaf with a non-default value in system also needs to be copied into running? Of course then this no longer becomes purely about *validity* anymore... [Qiufang] I think Jan is raising a good point, the WG should not miss the interplay between defaults and system config. I am not sure I like option 1) . If it is the client's intention to enable interface "lo0" and explicitly write a default value (true) into <running>, it should override the value in <system>. [>>JTS:] You mention "explicitly write". I'm not positive what you meant here, but I was talking about the case where the operator creates lo0 in running but does *not* explicitly configure the 'enable' leaf in running. So in option #1: * reading the 'enable' leaf from running will return nothing * the client may assume that the value being used by the router for 'enable' is 'true' (default in the YANG) * actual value being used by the router is 'false' But this issue isn't really specific to just defaults. It is an issue for *any* instance data in <system> that isn't auto-copied into <running>. For example, imagine a leaf that doesn't have any default value at all, but that leaf is configured to a specific value in <system>. Any data missing from running will result in the client having the wrong view/information. If we want to also solve that problem in this draft, then every single leaf that has an explicit value in <system> would have to be copied as part of the resolve-system auto copy (not just the leafs that are required for validity). That's option #2. Interesting question for the WG. That may be simpler than trying to determine exactly which subset of those leafs are actually needed for validity of running (i.e. "just copy everything"). Option 2) may seem to work for me. If the server sets the value for a node that is different from the schema default value, it must be copied into <running> if its parent node is copied explicitly or automatically by "resolve-system" parameter, and any updates of this value (unless it's updated to its schema default value) needs to be reflected into <running> automatically. And I think this is independent of the topic about the validity of <running> alone. Thoughts? [>>JTS:] I'm not sure what you mean about "and any updates". Are you referring back to section 4.2? #4 Resolve-system only for filling in blanks The second paragraph in 5.3 states that The "resolve-system" parameter is optional and has no value. If it is present, and the server supports this capability, the server MUST copy referenced system nodes into the target datastore (e.g., <running>) without the client doing the copy/paste explicitly, to resolve any references not resolved by the client. One possible interpretation here is that the server must copy the referenced items from running when resolve-system is in use. I don't think that is the authors' intent. I believe the intent is that the configuration should only be copied if it is *missing* in running, i.e. never overwrite anything in running. If this is correct, I think the wording should be improved to reflect this. [>>JTS:] Agree we should say this copy only occurs for schema elements that aren't already explicitly configured in running. [Qiufang]Yes, also agree that only the missing part needs to be copied. Would the following proposed update work for both of you: OLD: If it is present, and the server supports this capability, the server MUST copy referenced system nodes into the target datastore (e.g., <running>) without the client doing the copy/paste explicitly... NEW: If it is present, and the server supports this capability, the server MUST copy referenced system configuration into the target datastore (e.g., <running>) where it is missing from without the client doing the copy/paste explicitly... [>>JTS:] That new sentence isn't quite right IMO, and this may need further rework depending on Jan's "#3 Defaults vs system config" (since we may need to copy more than just the referenced configuration - it may need to include all explicitly configured descendant nodes as well). Perhaps this instead: If it is present, and the server supports this capability, the server MUST copy referenced system nodes and all explictly configured descendant nodes in <system> that are missing from <running> into <running> without the client doing the copy/paste explicitly. The copy operation MUST NOT overwrite any explicit configuration in <running>. #5 Non-grammatical sentence The third paragraph of section 5.3 reads The server's copy referenced nodes from <system> to the target datastore MUST be enforced at the end of the <edit-config>/<edit- data> or <copy-config> operations during the validation processing, regardless of which target datastore it is. I am not able to parse or guess the intended meaning here. There is something non-grammatical about this sentence. Please rephrase. [>>JTS:] I believe this is trying to address when the auto copy happens. In theory it could happen as part of the application of the edit-config but the paragraph implies it just needs to happen before a validation. I was generally thinking this would happen as part of the edit, but I can also see that in theory an implementation could deal with all the auto-copying during a validation operation instead (it may be easier to identify all the things that need to be copied to make it valid at that point). [Qiufang] Thanks Jason for helping clarify the intent. I assume this is the easier way for the server to copy the missing parts during the leafref/when/must/mandatory true/min-element constraints enforcement process. But if we say this only has to happen before validation, then a client won't necessarily be able to see the auto-copied data if they do a get-data right after an edit-data. [Qiufang] Yes, another reason I think the timing of auto-copy enforcement should be specified instead of leaving it as implementation specific is, things might become different if auto-copy happens at different process. I.e., if it happens during validation, it implies that if <candidate> doesn't need to be validated, then auto-copy won't happen even though the "resolve-system" parameter is present. But in the end I'm not positive we want to force implementations to do this auto-copy as part of the edit. A candidate datastore doesn't have to be valid (until a validate or commit). [Qiufang] Another thought in mind: Should the validate and commit RPC operation also support this parameter? [>>JTS:] Interesting question. If we aren't going to auto-copy until validate-time, then perhaps the resolve-system should indeed be a parameter of <validate> or <config>. The downside is that I think it may be more intuitive to users if the auto-copy happens as part of an edit. On the other hand, maybe a subsequent edit was going to add some configuration that was going to resolve the missing leafref. If we don't auto-copy at edit time, then the client won't be able to see a complete view of what is about to be committed when they do a get-data before the commit. But if we do auto-copy at edit time, that may be a pretty expensive operation for the server (I'm worried it may effectively have to do some something almost as expensive as a validation to find the missing pieces). #6 Atypical leaf naming in example The module example-acl in section 5.5.1 is using underscores _ in names (e.g. acl_rule, source_address) where YANG style typically is to use hyphen. Consider updating? [Qiufang] Sure, will fix in the new revision. Thanks. #7 NETCONF protocol as example The example in section 5.5.1 says If a client configures an ACL rule referencing system provided applications which are not present in <running>, take NETCONF protocol for example, but when you look at the example, I can't find anything NETCONF related there. I think that is good, since using NETCONF as an example here has the potential to confuse the reader, but then that sentence probably needs updating. [Qiufang] The example taking NC protocol for example refers to the following "edit-config" RPC operation that uses the "resolve-system" parameter, and if it is for RC, the usage of this parameter could be a different way. I guess you mean the examples in other parts are protocol independent, see if the following update works for you: OLD: take NETCONF protocol for example, the client may issue an <edit-config> operation with the parameter "resolve-system" as follows: NEW: For example, the client may issue an <edit-config> operation with the parameter "resolve-system" to the NETCONF server: #8 No before and after in a transaction The first paragraph in section 5.5.2 introduces an example like this: For instance, in the above example, the client MAY also explicitly configure the following system defined applications "ftp" and "tftp" only with the list key "name" before referencing: In this sentence, I find the use of "before" a bit unfortunate. I am afraid some readers may interpret this as meaning that the "ftp" and "tftp" list items have to be configured in a separate transaction prior to the one where they are being referenced, while in reality they can be added in the same transaction as the reference. [Qiufang] I agree with you, they are split into two XML snippets in order to highlight what extra configuration are needed for the client to explicitly write into <running>. We've removed the "before referencing" to avoid such misreading. The following statement starting with "Then the client configures the following..." might also be confusing, updated as follows: OLD: Then the client configures the following ACL rule referencing applications "ftp" and "tftp" as follows... NEW: And the configuration of ACL rules referencing application "ftp" and "tftp" are... Thank you for your efforts authoring this document! Best Regards, /jan Best Regards, Qiufang From: Lou Berger <lber...@labn.net<mailto:lber...@labn.net>> Date: Monday, 29 April 2024 at 23:55 To: Balazs Lengyel <balazs.leng...@ericsson.com<mailto:balazs.leng...@ericsson.com>>, Rob Wilton (rwilton) <rwil...@cisco.com<mailto:rwil...@cisco.com>>, Jan Lindblad (jlindbla) <jlind...@cisco.com<mailto:jlind...@cisco.com>>, Mohamed Boucadair <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> Cc: Kent Watsen <k...@watsen.net<mailto:k...@watsen.net>> Subject: Fwd: [netmod] WGLC on system-config-05 Hi - Time for a little peer pressure. We, the chairs, would like to ask for your help in reviewing the system-config that is currently in last call. We are not asking for any specific position or opinion, simple that you review the document and then provide a statement of if you do/do not support publication. Of course, technical details support objections are most helpful -- and that all comments should be sent to the list. Thank you so much for your on going, meaningful and important contributions to our WG! Kent and Lou -------- Forwarded Message -------- Subject: Re: [netmod] WGLC on system-config-05 Date: Mon, 29 Apr 2024 17:48:57 -0400 From: Lou Berger <lber...@labn.net><mailto:lber...@labn.net> To: netmod@ietf.org<mailto:netmod@ietf.org> <netmod@ietf.org><mailto:netmod@ietf.org> CC: Kent Watsen <kent+i...@watsen.net><mailto:kent+i...@watsen.net> WG, We'd like to extend this LC for another couple of weeks in the hope that we get more feedback from the WG on this document. Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome! This is useful and important. Thank you, Lou and Kent On 3/29/2024 10:08 AM, Kent Watsen wrote: This email begins a two-week WGLC on: System-defined Configuration https://datatracker.ietf.org/doc/draft-ietf-netmod-system-config/ Please take time to review this draft and post comments by April 12. Favorable comments are especially welcomed. There is no known IPR for this document: https://mailarchive.ietf.org/arch/msg/netmod/IpzWIAbgifXoKaNfLhEDmYbyXkY/ Kent // co-chair _______________________________________________ netmod mailing list netmod@ietf.org<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
