Hi all, Please see inline. (Note: I haven't read Rob's review yet) Jason From: Jan Lindblad (jlindbla) <jlindbla=40cisco....@dmarc.ietf.org> Sent: Tuesday, May 7, 2024 8:57 AM To: maqiufang (A) <maqiufa...@huawei.com>; Qin Wu <bill...@huawei.com>; fengchong...@gmail.com Cc: Kent Watsen <k...@watsen.net>; 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. 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. 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: and then also remove the middle bullet "Servers don't migrate..." #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>" #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... #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. #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). 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. 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). #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? #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. #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. Thank you for your efforts authoring this document! Best Regards, /jan 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
