Hi, Kent and Rob, Sorry for being late on this response, please see my reply inline…
From: Rob Wilton (rwilton) [mailto:[email protected]] Sent: Wednesday, April 30, 2025 11:40 PM To: Kent Watsen <[email protected]> Cc: maqiufang (A) <[email protected]>; [email protected] Subject: Re: [netmod] 2nd WGLC on immutable-flag Hi Kent, Quick replies inline … From: Kent Watsen <[email protected]<mailto:[email protected]>> Date: Wednesday, 30 April 2025 at 16:06 To: Rob Wilton (rwilton) <[email protected]<mailto:[email protected]>> Cc: maqiufang (A) <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: Re: [netmod] 2nd WGLC on immutable-flag Hi Rob, A couple quick responses. On Apr 30, 2025, at 8:40 AM, Rob Wilton (rwilton) <[email protected]<mailto:[email protected]>> wrote: Hi Qiufang, authors, I was reviewing the latest draft and thinking about the immutability of lists/leaf-lists again. Foe me at least, I think that the default (and most obvious) behaviour is that if the parent container of a list (or leaf-list) is marked as immutable then the list element itself is immutable (cannot add, remove, or reorder entries), and all entries within that list are immutable as well. I.e., the whole subtree is immutable. I think that this is the same way that Kent is thinking about it. Yes, unless the descendants toggle the immutable flag to "false", in which case their non-key fields could change. Agree? Yes, I think so. I am not against if we go towards this way, but I think this might add some extra complexities and I want to ensure we are in agreement. Something that is unclear to me is that, e.g., if a parent node is immutable, and some child list entries are immutable, and other entries are mutable, is a new entry allowed to be added? No? because the inherited immutability affects the reordering and addition of new entries? And I think the answer keeps unchanged even all list entries are mutable but the parent node is immutable? Does the same apply to leaf-list? A leaf-list is a set of values, and to me it feels like each of the value itself serves like the key to the list, so it does not make a lot of sense if leaf-list entries are marked as mutable but the addition of new entries is not allowed… In an example similar to the one you gave below, if you want to have a container with a couple of immutable fields, and a list that has some immutable elements (but more could be added), then could the solution be to mark the container as being mutable, but for the fields within the container and each list entry be marked as immutable? > Throughout this section, the word "change" refers to creating, or > deleting a node, along with, where applicable, changing its value. I would like to better understand the aspect of how deletes are handled in two cases: 1. Section 5 effectively states that you cannot delete a node with an immutable annotation. Do you mean that a client cannot delete the node from running (i.e., the server would reject the config change if you tried), or that a client can delete the node from running (which I think should be the allowed), but the immutable value would be merged back in from system and hence the net effect is that the data node would still exist in <intended>. The latter one is what I have in mind. <system> define the configuration that is non-deletable, as it’s always merged into <intended> and present in <operational> if successfully applied. 2. If a parent node is mutable, and a child node is immutable, then I presume that you effectively cannot delete the parent node. I.e., depending on the answer to my question above then either the server should reject the change because it is implicitly deleting an immutable child node, or it should accept the change, but the node would be merged back into intended, so the net effect is that the node still exists. The parent node can be deleted from <running>. But as it is system-defined, the parent node with the immutable node still exists in <intended>. I think that clarifying these two points in the draft would be helpful. I'm beginning to think that an example or two in the draft for list/leaf-list would improve understandability. Yes, also agree. I think that there is some subtle complexity and corner cases here and we need to make sure that we are all on the same page on what the exact expected behaviour is so that the implementations end up being interoperable. Sure, some examples in my mind: · <system> contains a parent container which is mutable, with some child list entries being immutable. o A client is allowed to add new entries into <running> o A client can copy/delete the parent container with the immutable list entries in <running>, but the client is not allowed to update the immutable entry (e.g., change the non-key leaf value). · <system> contains a parent container which is immutable, with some child list entries being immutable, and others being mutable. o A client is/isn’t (depending on the answer of my question above) allowed to add new entries · Another example for leaf-list if it should be handled differently. Best Regards, Qiufang
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
