Hi, Rob, Kent, Some comments below with [Qiufang]… For 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. [Qiufang] Is the above statement added by Kent on the premise that the list as a whole is immutable? If the list is immutable (through inheritance), I don’t think inserting additional entries should be allowed. If the list is mutable, but only some entries are immutable, it seems that we are proposing something like the immutability on the individual entries also affects the ordering of them. Is this the intention? Note the current document states: “The immutable annotation attached to the individual list instance provides immutability with respect to the instance itself.” Is this still true? 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. [Qiufang] I am working on the update of this parts, and I find it is still not 100% clear. I agree that the key point of immutability is that the client cannot override the node with a different value, and it can always be created (with a same value) and deleted in <running>, but these edits won’t prevent the node from being present in <intended>. As my understanding of this comment, a system-defined leaf-list entry with its value will always appear in <intended>, agreed? In the case 1 above, the leaf-list as a whole is immutable, the client cannot add/remove/change any entries. But I want to go one step further, is the statement still true even when some leaf-list entries are mutable? Because you cannot add new entries, and the mutable entries in <system> will always be in <intended>. Or can we say something like the following: “If a leaf-list as a whole is immutable through inheritance, it is meaningless for some of its entries to be annotated as mutable, as new entries are not allowed to be added given the immutability of the leaf-list and there is no way for the client to delete any system-defined leaf-list entries.” Again in case 2, should we allow the immutability of instances also has bearing on the ordering? Did I miss something? Best Regards, Qiufang
_______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
