Hi Jason, Quifang,
> I think there are use-cases for "immutable" even outside of system config so > we may not want to restrict it to system config. > [Qiufang Ma] Agree that we can just define such an “immutable” flag without > restricting it to decorating system configuration. In that way, maybe we can > discuss whether we should define this annotation in an independent > I-D.[>>JTS: ] Yes perhaps. Although I'm not sure this is an urgent item for > the WG. Interested to hear what others think as well. Agreed to not restricting context. For instance, in a past-life, I used an “immutable” flag for config resources exported from a host-system to logical-systems (think: host exports eth3 to logical system; logical-system can see “eth3” in its config (perhaps now its <system> config), but the config node is immutable from the logical-system’s PoV. I do think an independent I-D is needed for an “immutable” annotation. It may (or not) be the case that this <system> work has a normative dependency on that I-D. > Regarding this “immutable” flag there may be a question to answer: what if > legacy clients receive some annotations they do not understand? Should they > just ignore it silently? [>>JTS: ] Yes - that is what clients would have to > do. Not ideal but maybe not critical. Servers have various reasons they may > reject a configuration, even if that configuration looks valid against the > YANG model. Handling legacy clients will be the biggest issue with introducing an “immutable” flag. > I'm not sure it would be as simple as erroring when a write is attempted to > that value. Say some more, Jason, since this is the *only* “relief valve” we have with this solution… > Are you talking about an error at edit time, or at commit/validation time ? > [Qiufang Ma] My assumption is an error at edit time, static checks are > sufficient for the server to detect the problem. But I think it’s also okay > to report an error at commit/validation time. [>>JTS: ] I think in order to > allow the behavior I mention at the end, we'd need to make this a commit time > behavior. IMO the candidate should be allowed to contain a new/changed value > for an immutable leaf. The when the commit occurs, the system can attempt to > achieve what the candidate is asking for. If it can't achieve it, then it can > reject. Agreed. > What if the value configured is the same as the current value ? > [Qiufang Ma] I have the same question. Some implementations do allow the > client to configure a same value(e.g., for the purpose of offline validation > of <running>). But I feel that it may depend on the discussion of another > thread “should the origin=’system’ be required for system configurations > copied/pasted into <running>’” which I posted to the WG. If the > origin=“intended” , it actually means overwrite. > [>>JTS: ] The "immutable" tag would be in the YANG model, which means it is > against that schema node whether there is an equivalent data node in <system> > or <candidate> or both. I think it becomes a warning to the client that the > value can't be *changed* in a datastore. It can only be *created* initially > (if it didn't already exist). For a leaf that is at the top level or only > has non-presence containers as ancestors, it means that leaf can only be set > once in any particular datastore (or maybe changing it requires a reboot ?). > For leafs that are descendants of presence containers or lists, then the > nearest p-container or list entry ancestor would have to be effectively > deleted and re-created under the hood to get to the config that the user > declared they want. I think the “immutable” would be a metadata annotation (not a YANG "extension") > It is probably best if this is a validation/commit time check. > > If the immutable leaf is inside a list entry, then it should probably be > acceptable for the server to allow a change to the leaf by destroying and > re-creating the list entry under the hood. i.e. allow a change to the > immutable item (which is in line with configurations being "declarative" - > just get me there if possible). > [Qiufang Ma] Are you suggesting a server should allow a client to > delete/create the “immutable” data item in <running>? Wouldn't that be a > little strange if a client can delete a particular data item but has no right > to change its value? Theoretically, the deletable is modifiable. > [>>JTS: ] I don't think delete is allowed unless a parent is deleted (i.e. > the nearest presence container or list entry). But we do need to allow > parents of immutable leafs to be deleted IMO. Hmmm, that last bit (deleting an immutable node’s ancestor) doesn’t sit well with me…do you have a use-case in mind? K.
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
