Hi, Kent I support ensuring XC/Y remains transactional, such that a client can always move from valid config-A to valid config-B in a single update. I also support requiring a "with-immutable" flag in client-requests in order for the "immutable" annotations to be returned (like "with-defaults"). Using an explicit parameter (e.g., with-immutable) avoids the case the client receives an "immutable" annotation yet doesn’t really understand that(clients don’t understand this annotation doesn’t even explicitly ask the server to return this). I agree that could be useful and should be added in the next version. I think this "with-immutable" flag should be supported even when a client retrieves a read-only target datastore (e.g., <system> or <operational>), though immutability only refers to restrictions on read-write datastores.
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>? 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. 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. Any issues with the following statements? 1) Only the server can create/change/delete `immutable` data, which is seen in the <operational> and <system> datastores by default. Clients are merely making immutable nodes visible/invisible in <running/start/candidate>. If the client does not make a system-defined node visible in <running>, the node still exists in <operational> and <system>. Among the common cases we see now are immutable data that is generated by system, and cannot be changed by the client. So the statement seems true for me. I am unsure if there would be a case like a client creates a node instance but cannot modify that afterwards. That way it will not be present in <system> and the client may also be allowed to delete that. We used to have a BGP AS number case for that in previous version (https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag-05#appendix-A.5) but that is not a good practice and it was removed. 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. FWIW, it may be possible for NACM to be non-transaction. For instance, a client-removing their own access to NACM, which would be irreversible by that client. But this is a corner-case, and one a server should guard against occurring. Noted. 2) The "immutable" YANG extension statement (not the metadata annotation) designates, at the schema-level, config=true nodes that, when present in <running/startup/candidate>, are system-defined and hence immutable. Note that NMDA does allow clients to create an interface entry with an interface-type value which is not yet physically present. Only when the interface physically appears, the type cannot be modified with another value not matching the real value the device is actually in use. 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. 3) The "immutable" metadata annotation (not the YANG extension) designates, at the instance-level, config=true nodes that, when present in <running/startup/candidate>, are system-defined and hence immutable. The metadata annotation is only needed to support config=true YANG lists that can contain a mix of client- and system- defined entries. There is no such a case like a client creates several instances some of which are immutable while others are mutable. Generally I agree that “The metadata annotation is only needed to support config=true YANG lists that can contain a mix of client- and system- defined entries.” Which I believe is the most common. Notice that leaf-list is not mentioned, cannot a particular leaf-list instance be immutable? Leaf-list is not mentioned because I wrongly thought that RFC7952 couldn't set metadata on a per leaf-list entry basis in the JSON encoding. But I see that it can and so, you're right, `leaf-list` should be treated the same as `leaf` in this statement. Okay, thank you. It seems to me all three above statements target that all immutable configuration are system-defined. But I assume some configuration may also be created by the client, e.g., interface type and BGP peer cases documented in the document. Thoughts? Exactly the intention. By having "immutable if and only if system-defined", regardless if the <system> datastore is implemented or not, transactionality is ensured. See my comments above, I think generally we can say that immutable configuration can only be system-defined to ensure transactionality, but it is not true all system configuration is immutable. IDK what "interface-type" case you refer to, but I assume the "BGP peer" case is UC5. The interface-type case refers to the one you commented above. For UC5, my understanding (assuming recursively toggle-able "immutable" flag described before), is that both `container bgp` and `list neighbor` would be "immutable false", while `leaf peer-type` would be "immutable true". Does that make sense? Yes. PS: I assume the YANG extension would be used since the immutability of `leaf peer-type` seems to be independent of any instance. Also makes sense? Yes. 4) The definition for the "immutable" flag means is identical whether it is specified via the YANG extension or the metadata annotation. Corollary: the "immutable" flag can only be used on data-nodes (e.g., not on "choice", "case", or "grouping"). Agree that it is a data node property, unless we define specifically what it means to use immutable flag on statements like choice/case/grouping, but I see it as out of scope for now. Good. A couple more musings: 1) I wonder if "immutable" should be a boolean that is "false" by default, but can be explicitly set to "false" if it is a descendent of a "immutable=true" node. That is, to let immutability be recursive but toggle-able. If I understand you correctly, Kent, you’re proposing something similar to https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag-06#section-3.2 except that im:immutable is changed to a Boolean type and of value “false” if not specified. That makes sense to me, if we agree that immutable should be a substatement to a "config true" leaf, leaf-list, container, list, anydata or anyxml statement rather than only terminal node like leaf or leaf-list. 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. 2) I wonder if *what* the "immutable" flag means should be defined per data-type. For instance: When a "leaf" node is immutable: - its value cannot change. Yes, it’s quite easy. When a "leaf-list" node is immutable: - its value cannot change. - If specified at the schema-level, "ordered-by user" is invalid, because reordering changes the value. My understanding is that, • if a leaf-list node is specified “immutable” at the schema-level, any leaf-list entries can neither be created or deleted. That means totally read-only to clients/users and I also agree that “ordered-by user” is invalid in this case. • if a specific leaf-list entry is specified “immutable” at the instance-level, only that specific entry cannot be deleted. Metadata annotation is only applied to existing instance, so the client can add/insert new entries; other entries without immutable flag can also be deleted. Is this consistent with what you have in mind? 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? - if it is desired to communicate that leaf-list entries cannot by reordered, the leaf-list must be "ordered-by system". Corollary: an "ordered-by user" leaf-list is never immutable. When a "container" or "list" node is immutable: - all of its recursive descendants are "immutable=true" unless toggled back to "immutable=false" by a descendent node. Yes, unless otherwise specified, immutability is inherited downwards towards the terminal leaves. Thanks for the confirmation. - for lists, it is not possible to designate the list as a whole as immutable, because the list itself doesn't exist as a node in the data-tree. - If it is desired to communicate that list-entries cannot be added/removed by clients, it is sufficient for the list's `key` node(s) to be immutable=true. I would rather see immutability of list the same way as leaf-list. That is, we do allow the list data node to be immutable at schema-level and it conveys that any list entry cannot be created and deleted, and likewise, “ordered-by user” is invalid in this case. I understand that list node may exist in multiple instances in the data tree but any issue you see with that? 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? - 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? When a "anydata" or "anyxml" node is immutable - the node, and all of its recursive descendants, if any, is/are "immutable=true", unless toggled back to "immutable=false" by a descendent node. Agree, I see it similar to a “container” node is immutable. Yes. One thing to note, though, is that since there is no schema for the decedents of an anydata/anyxml node, it is never possible for the "immutable" YANG extension to be used to declare up-front which parts of the anydata/anyxml may be immutable. Of course, the metadata annotation could say, and maybe that is good enough. Noted. Best Regards, Qiufang
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
