Subject: Re: [netmod] "immutable" flag

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 8 Dec 2021 22:42:25 +0000

Hi Qiufang,

I think there are use-cases for "immutable" even outside of system config so we may not want to restrict it to system config.

I'm not sure it would be as simple as erroring when a write is attempted to that value.

Are you talking about an error at edit time, or at commit/validation time ? What if the value configured is the same as the current value ? 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).

Jason

From: netmod <[email-masked]> On Behalf Of maqiufang (A)
Sent: Monday, November 22, 2021 7:12 AM
To: [email-masked]
Subject: [netmod] "immutable" flag

Hi, all

There are some system configuration which may not be modifiable for clients(e.g., interface "name" and "type"). Should we define an "immutable" flag to indicate to the clients which system configuration is read-only or which is not?

The server will return an error if the clients attempt to configure a value for a system defined data node with an "immutable" flag.

My assumption is that this annotation should be carried only when the clients retrieve <running> with "with-system" parameter to get  a merged view.

Suggestions, comments and concerns about this issue?

Best Regards,
Qiufang Ma

---

From: "maqiufang (A)" <[email-masked]>
Date: Thu, 9 Dec 2021 12:57:17 +0000

Hi, Jason,

Thanks for your comments, please see my reply inline.

From: Sterne, Jason (Nokia - CA/Ottawa) [mailto:[email-masked]]
Sent: Thursday, December 9, 2021 6:42 AM
To: maqiufang (A) <[email-masked]>; [email-masked]
Subject: RE: [netmod] "immutable" flag

Hi Qiufang,

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.
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?

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.
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.

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.

Best Regards,
Qiufang Ma

Jason

From: netmod <[email-masked]<mailto:[email-masked]>> On Behalf Of maqiufang (A)
Sent: Monday, November 22, 2021 7:12 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [netmod] "immutable" flag

Hi, all

Best Regards,
Qiufang Ma

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 9 Dec 2021 15:46:08 +0000

Hi Qiufang Ma,
Please see inline.
Jason

From: maqiufang (A) <[email-masked]>
Sent: Thursday, December 9, 2021 7:57 AM
To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>
Cc: [email-masked]
Subject: RE: [netmod] "immutable" flag

Hi, Jason,

From: Sterne, Jason (Nokia - CA/Ottawa) [mailto:[email-masked]]
Sent: Thursday, December 9, 2021 6:42 AM
To: maqiufang (A) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [netmod] "immutable" flag

Hi Qiufang,

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.
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.

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.

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.

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.

Best Regards,
Qiufang Ma

Jason

Hi, all

Best Regards,
Qiufang Ma

---

From: Kent Watsen <[email-masked]>
Date: Tue, 14 Dec 2021 01:20:50 +0000

Hi Jason, Quifang,

> [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…

> [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.

> [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.

I think the “immutable” would be a metadata annotation (not a YANG "extension")

> [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.

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.