Hi Qiufang, Kent, Please see inline (indentation seems slightly broken, so I’ve also coloured in red) …
From: maqiufang (A) <[email protected]> Date: Wednesday, 7 May 2025 at 08:01 To: Rob Wilton (rwilton) <[email protected]>, Kent Watsen <[email protected]> Cc: [email protected] <[email protected]> Subject: [netmod] Re: 2nd WGLC on immutable-flag 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? RW: I also think the answer is no. If the list itself is immutable (because that is what it has inherited), then you cannot add, remove or reorder any list entries. By default the list entries are also immutable (through inheritance), but any number of them could be marked as mutable. As Kent indicated, for the list entries that are marked mutable you would be allowed to add/remove/edit any data nodes except for the list keys themselves (since changing them would be mutating the list). 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… RW: I think that there are two cases: 1. The leaf-list is immutable (through inheritance), in which case you cannot add/remove/change any entries in the leaf list. 2. The leaf-list is mutable (again through inheritance), but individual entries are marked as immutable. In this case I think that you can add/remove other entries but not add/remove/change the immutable entries. I would also assume that you cannot reorder the immutable entries, but inserting addition entries between them is probably okay. 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. RW: Agreed, the latter behaviour is preferable. 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>. RW: Okay, yes, I agree that is the right behaviour. Does the document have (or need) any text to make this explicit? I.e., any data nodes in <system> marked as immutable MUST always be present in the <intended> configuration. I.e., even if they are below ancestor nodes that are marked as being mutable, there is no way that the immutable nodes can ever be removed by the client, unless the server itself takes some action to remove them from <system> or stop marking them as being immutable. 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. A client is allowed to add new entries into <running> 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. 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. RW: Yes, I think that adding those examples would be good. Kind regards, Rob Best Regards, Qiufang
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
