Hi Kent, Quick replies inline …
From: Kent Watsen <[email protected]> Date: Wednesday, 30 April 2025 at 16:06 To: Rob Wilton (rwilton) <[email protected]> Cc: maqiufang (A) <[email protected]>, [email protected] <[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]> 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. 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>. 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. 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. Kind regards, Rob Kind regards, Rob Kent // contributor
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
