Re: [netmod] New Version Notification for draft-ma-netmod-immutable-flag-07.txt

[Kent Watsen <[e-mail]>]

Cherry picking a few items below.


> [Rob Wilton (rwilton)]
> I think that the document is unclear about how it interplays with the system datastore, e.g., I find very few references to the system datastore, so I think that it would be helpful for that to be clarified.
> [Qiufang] Sure. That’s true, most of the references to system datastore document only appear in the use case appendix, I agree that this should be more explicit, to point out that only the server can create immutable configuration, and thus immutable data appears in <system>(if exists). A client may create a same value of immutable node as in <system> (e.g., to fulfil leafref constraints), but is not allowed to modify or override (https://www.ietf.org/archive/id/draft-ietf-netmod-system-config-01.html#section-5.4) immutable node with different values. Will clarify in the next version.
> But I think we don’t necessarily want immutable flag to be coupled with system datastore, that is to say, even a server doesn’t implement a <system> datastore, it could still be possible to have non-modifiable system configuration somewhere (e.g., in <operational>), and thus an immutable flag could be helpful in this case. Make sense?

The WG extracted the immutable-flag idea out of, at that time, the “with-system” draft, for this reason.

However, I only recall one case used for justification (see below).  It would be good to identify others cases.

The one case I recall, is when a device implements the concept of sub-devices, whereby NETCONF-clients connect to the sub-device, and have the illusion of being connected to a real device, using the same YANG and everything, just with lesser access.  For instance, the parent/host device may be able to set, e.g., the MTU on an interface shared with a sub-device, but the MTU value is immutable to sub-device NC-clients.

This validity of this case is questionable.  Specifically, that it is a case independent of system configuration at all.  It seems reasonable to opine that the MTU is, in fact, system configuration from the POV of the NC-client.  



>> If this is the case, then I’m not sure that I understand the value of the “extension immutable”, can you give examples of where this would be useful please?
> 
> [Qiufang] The “extension immutable” is considered to be used if a particular data node is always considered to be immutable independent of any its instance(s).
> A YANG extension makes immutability even visible for the client at implementation time (not just runtime), Therefore, the client has the opportunity to avoid error response in its NMS design/development time due to attempts to override immutable configuration.
> We do have an open issue regarding should the "immutable" metadata annotation also be returned for nodes described as “extension immutable” so that there is a single source of truth.

Regarding the open-issue.  Food for thought.

Assuming a client supports servers implementing this YANG module, how often do we expect the client to request configuration (get-config) with the immutable annotation included?  Would it be all the time, or only when a server returns a write-access error?  

What’s the overhead and does it matter?  Recall, the flag is hierarchal, so if returned for immutable nodes also set in the YANG module, via the extension statement, there’s a compression that occurs that may result in the overhead not being so bad.



> Possibly, if the WG decides to adopt this work, it might be worth considering whether this would be better documented as part of the system datastore draft?
> [Qiufang] Since we have decided to limit the scope of immutable flag to system configuration and not support non-transactional APIs, it makes sense to me for it to be documented in the system datastore draft.
> But as I mentioned above, we would like the immutable flag to work even when the system datastore is not implemented.
> Even that said, I'm open to this, and okay to document it as part of system datastore draft if the WG thinks it's a good idea.

Currently the “system-config” draft has an Informative reference to this draft.  Should it be a Normative reference, and the “system-config” draft state definitively that system data is marked as such per the “immutable-flag” draft?

Or do you mean to fold the “immutable-flag” draft back into the “system-config” draft (merge two drafts into one).  I personally do not wish for this.  Even if another immutable-flag use is never found.


> Regards,
> Rob
>  
> Best Regards,
> Qiufang

Kent