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." > 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: > The leaf-list is immutable (through inheritance), in which case you cannot > add/remove/change any entries in the leaf list. > 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,# > 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". > 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 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]
