Hi Rob, A couple quick responses.
> On Apr 30, 2025, at 8:40 AM, Rob Wilton (rwilton) <rwil...@cisco.com> 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? > 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. > > Kind regards, > Rob Kent // contributor
_______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
