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

["maqiufang (A)" <[e-mail]>]

Hi, Kent


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.
Exactly. When we were discussing the “with-system” draft (about 2 years ago), we were trying to identify all categories of system configuration, like resource-dependent vs. resource-independent, applied-immediately vs. applied-after-referenced, deletable system config vs. non-deletable system config, modifiable system config vs. non-modifiable system config…
However, I only recall one case used for justification (see below).  It would be good to identify others cases.
Yes, your case provided blow is one of them, others I can recall are like, the well-known "interface problem" : The system configures an interface when it’s physically present with its name, ip-address, type, enabled, etc., the user is allowed to add, modify, and delete all descendant nodes but except the "name" and "type" leaf; the hidden and immutable junos-default group which contains system predefined system configuration for comment use; the immutable system capability related configuration (e.g., case in https://www.ietf.org/archive/id/draft-ma-netmod-immutable-flag-07.html#appendix-A.1).
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?
I assume it won’t be too often, since the immutability must only change by software upgrade or license change?
Each time when above factors occur, a client may include a "with-immutable" parameter in its request to query the contents of <system> or <operational>, then understand what system configuration cannot be overridden.
Or simply do nothing, but query the immutability of certain system nodes until an RPC error returned.
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.
By “compression”, you mean omission?
Indeed, the metadata annotation of immutability doesn’t have to be explicitly declared for every node, since most can be omitted by default inheriting the immutability of its parent node. If not specified, the default immutable annotation value of a top-level node instance is immutable=”false”.



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?
I think it is a good question.
I have Just re-read some statements regarding normative and informative references (https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/):
“Normative references specify documents that must be read to understand or implement the technology in the new RFC, or whose technology must be present for the technology in the new RFC to work.”
I am thinking whether we’d really like to mandate this, since immutable flag is intended to provide descriptive information for the client, and even nothing can prevent the client from ignoring it and still tries to override an immutable node.
And also, immutable-flag draft doesn’t apply to the server which doesn’t have any immutable system nodes.

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.
Not sure if this is what Rob had in his mind. But I think I agree with you, I kind of hope we can draw clear boundaries between these two drafts.

Regards,
Rob

Best Regards,
Qiufang

Kent

Best Regards,
Qiufang