Hi Qiufang, > I think that it is undesirable to support the "with-immutable" request > parameter on non-configuration datastores. The reason why is that I believe > the "with-origin" flag is more useful. If the "origin" is "system", then > immutability is "true". > Is this true: If the “origin” is “system”, then immutability is “true”? > What if a system-defined node present in <operational> is actually > modifiable, i.e., allowing a client to write a different value in <running> > that overrides the one defined in <system>?
If the "node present in <operational> is actually modifiable", then I surmise that it is NOT "immutable". I believe that what you are describing is a normal (not immutable) "config true" node that happens to have an initial value set by the system, which could be seen in <operational> using NMDA, perhaps having origin equal to "default", "learned", or "system". Hmmm, I may need to backtrack on the `If the "origin" is "system", then immutability is "true"` statement. Or rather, we may want to revisit the contents of <system>. I understand wanting <system> defining fixed interfaces (e.g., loopback), but maybe <system> *should not* define dynamically-generated configuration that is already visible in <operational>. AFAICT, there isn't a need for <system> to contain *all* origin=system data, just the subset that is "config true" and, even then, maybe less. Thoughts? I guess I don't understand this example in the "system-config" draft: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config#section-6.2. > The reason why I am thinking it might be useful for non-configuration > datastores to return immutable flag is that, I think a client may want to > know if it has the ability to change a value before it actually changes it > (writes into configuration datastore). If that immutable flag doesn’t return > until it is copied into configuration datastores(e.g., <running>), that would > be awkward. Understood. It is indeed the goal for clients to use the "immutable" information to avoid knowably-invalid configurations. > PS: there's an open-question as to if "with-immutable" also returns the > "immutable" flag for nodes described as immutable in the YANG schema. I > think that the flags should be returned for all nodes regardless by default > so that there is single source of truth. That said, I'm open to the idea of > the "with-immutable" parameter taking an argument specifying how much to > return. > Yes, agree that this should be an open question. The current document doesn’t > ask the server to return immutable flag for immutable nodes specified at > schema-level, but that would cause the client to query both schema and > instance data to obtain its real immutability. Thanks for tracking it. > The "client creates a node instance but cannot modify that afterwards" > (unless the parent is deleted?) case seems to be exactly the > non-transactional example we are trying to avoid, agreed? This definition > (#1) essentially guarantees transactionality, since there is nothing clients > can do to alter what the system considers immutable. A node is immutable if > and only if system-defined. > I guess I don’t agree your last sentence. I don’t think all system-defined > nodes are immutable, they do have a distinction between modifiable system > configuration and non-modifiable system configuration. I didn't write that all system-defined nodes are immutable. I wrote that all immutable-nodes are system-defined. There's a difference. I'm very much trying to assert that "immutable" data is life-cycled (created/changed/deleted) only by the server; a client can never create/change/delete immutable data. At best a client can make immutable-data visible in <running>, but they would only do that in order to, e.g, configure a mutable descendant (e.g., an interface's "description" or MTU) or, e.g., to reference it in a "must" or "when" expression. That said, I do agree with your statement "I don’t think all system-defined nodes are immutable". But, as I wrote at top above, the nodes should not be flagged as "immutable" (nor show up in <system>). For such "config true" nodes that are given an initial (perhaps "default") value, it seems that the existing practice of reading the operational value from <operational> prevails. > A temporal nature is at play here. > > 1) when the client sets the config when the card is installed, the system can > fail the request if it affects any "immutable" nodes (non-matching values). > [PS: it is assumed that, for this case, the metadata annotation (not the YANG > extension), would be used.] > > 2) However, if the card is not installed, the client could put non-matching > values for the "immutable" parts, and the server would have no way to > validate it, and hence the server would, presumably, allow the update to > <running>. When the card is later installed, the interface would appear in > <operational>, and <system> if supported. At that time the non-matching > value would be discovered. Presumably the system would 1) ignore the > non-matching config from <running>, 2) send an alert that <running> is > invalid, and 3) force the next commit to <running> to correct the > non-matching values. > > Is this what you are focusing on? > I agree with your statement here. Since a server may allow the client to > update an interface type value because it has no way to validate that, and > also because it is just when the interface is installed that it will flag > interface type as immutable, this still doesn’t seem to go against with your > definition “only system can create/update/delete immutable configuration”. > Jürgen raised another possibility which I also agree, but I believe that > server behavior of internally regarding this value as immutable is consistent > with most existing vendor implementations now. > While from the client’s perspective, it can always delete immutable > configuration from read-write configuration datastore, that is just to make > immutable nodes invisible according to your interpretation and will not > really delete the configuration from the device. Yes, this seems right. > I disagree that only terminal nodes should be immutable. For starters, > consider an immutable presence container. > > Also, with JUNOS's immutable list of "applications" that are referenced by > security policies, there are hundreds of them. Surely the entire list should > be marked as immutable in the schema. > Sure, we can keep going with leaf, leaf-list, container, list, anyxml and > anydata statement in support of immutable flag. Thanks for tracking this. > I stand corrected. Please see above regarding RFC 7952 JSON encoding for > leaf-list. This being the case, I would rewrite this definition as: > > When a "leaf-list" node (element) is immutable: > > - the value, for each element in the leaf-list, cannot change. > > - it is not possible to designate the leaf-list as a > whole as immutable, because the leaf-list itself > doesn't exist as a node in the data-tree (and hence > cannot be flagged as "immutable" in the response > to a "with-immutable" request. > > - If it is desired to communicate that list-entries > cannot be added/removed by clients, this is already > the case as the leaf-list's `key` node(s) is immutable > (i.e., clients cannot make up their own key values). > Does this mean that if all the leaf-list instances are flagged as “immutable” > in the response to a “with-immutable” request, it already conveys that new > leaf-list entries cannot be added? No, unfortunately, the "with-immutable” response alone cannot convey if the the entire list is immutable, only the schema-level extension can do that it seems. This because the list as whole is not a node in the data tree. > I understand the desire. My concern is that the `list` and `leaf-list` YANG > nodes themselves do not exist in the data tree. For example, in XML no > parent-node exists and, in JSON, no metadata can be conveyed at that level. > Thus I'm hoping that all semantics can be conveyed in the "with-immutable" > response, without the client having to also consult the YANG. Maybe it's > not worth it (i.e., XC/Y demands YANG-awareness) and your understanding > prevails. Either way is okay. > Okay, I understand it now. That way, your consideration makes sense to me. > If it is desired to communicated that list-entries cannot be added/removed by > clients, do we need the key instance(s) of all list entries to be marked with > immutable=true (that might be a huge data volume)? Or only a particular one, > such as the key node(s) in the first entry? I think that this question is related to, or at least answered by, my previous response. > - if it is desired to communicate that a list-entries cannot > by reordered, the list must be "ordered-by system". > Corollary: an "ordered-by user" list is never immutable. > By the way, if a specific list instance is specified as immutable at > instance-level, can a user create a descendant node instance inside that list > instance? > > Yes, if the schema for the descendent node toggles "immutable" to "false" > using the YANG-base extension - makes sense? > But what if the descendant node doesn’t use the YANG extension to toggle > “immutable” to “false”? It inherits the immutability of its parent node which > is immutable=true if not otherwise specified. > According to our definition above, immutable configuration can only be > system-defined, thus a server will reject a descendant node instance to be > created by the client? Right? I'm confused. Why wouldn't the mutable descendant be "immutable false" in the schema? I'm assuming that you're focusing on the case of a mutable-descendent of an immutable-node. Yes? > Best Regards, > Qiufang K.
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
