Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06

[Kent Watsen <[e-mail]>]

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.