Hi Rob, > 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.
True. > 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. Looks good. > 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. Perhaps it's too subtle, but there is a difference between the node existing versus its value. I'm stating that the node must exist, but (to your point) its value may differ. > Kind regards, > Rob Likewise, Kent // contributor
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
