Hi Kent,
From: Kent Watsen <[email protected]> Date: Wednesday, 7 May 2025 at 15:35 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, Qiufang, Please find some quick responses below. Kent // contributor On May 7, 2025, at 6:27 AM, Rob Wilton (rwilton) <[email protected]> wrote: 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). +1 FWIW, this is identical behavior for containers, except the extra part about list keys. One statement could added: "If the list is ordered-by user, one cannot reorder the immutable entries, but inserting addition entries between them is probably okay." Fine with me. 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. Agree, but: - s#you can add/remove other entries#you can add/remove/change other entries# - s#I would also assume that#I would also assume that, if the leaf-list is ordered-by user,# Agreed. For the first one, I see that changing a leaf-list entry is effectively the same as adding/removing it. 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. I'm confused what "latter" points to - is it #2 below? In any case, I completely agree that <system> defined nodes can never be deleted from <intended>. That said, when we say that "nodes can be deleted", what we really mean is "nodes *added* via <running> may be deleted". Yes, I think that this is really the key point. Immutability isn’t about whether the data node can be created or deleted (since it will always exist in the resultant combined configuration). Hence it only indicates whether a client is allowed to overwrite its value with a different value in the running configuration datastore. There is a comment in the existing document that states: Throughout this section, the word "change" refers to creating, or deleting a node, along with, where applicable, changing its value. I think that paragraph could perhaps be expanded to something like: A node that is annotated as immutable in the system datastore cannot be changed via configuring a different value in the running datastore, nor is there any way to delete the node from the combined configuration (as described in [draft-ietf-netmod-system-config]). The node MAY be explicitly configured by a client in <running> with the same value and that configuration in <running> may subsequently be removed again, but neither of these edits will change the <intended> configuration of the device. 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. An even stronger statement can be made: any (mutable or not) node in <system> MUST be present in <intended>, since there is no way for clients to delete <system> defined nodes. I don’t think that is quite right, since a data node marked in system marked as mutable could be configured with a different value in running. Kind regards, Rob 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]
