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

[Kent Watsen <[e-mail]>]

Hi Rob,

> - In terms of properties that cannot be changed once written, I would rather see this issue framed more in the direction of it just being extra documentation written in a machine-readable way.  Specifically, using the annotation to give an indication that servers MAY reject requests to create/delete, or change, the configuration, but not requiring that they do so.  I.e., at the data model level, I don't think that we should preclude servers being able to handle this is in a more client friendly way (e.g., by breaking a single client transaction up into multiple internal transactional changes where needed).

I agree that the document does not make it clear enough, but this is already the case.   As I said at the end of this document's presentation on Friday's NETMOD, session, this document has no runtime-impact on servers (other than them needing to return annotated YANG and/or metadata).  There is also no runtime-impact on clients, as they as free to ignore all the annotations and metadata.   All this document does is define a mechanism for servers to describe the behavior they already implement.   The text in the document is confusing because the normative statements make it sound like the server needs to implement behavior to reject certain updates *because annotations/metadata said so*, but actually it's the other way around, as the server was already implemented to reject the changes.

1st paragraph in the Introduction:

This document defines a way to formally document as a YANG extension or YANG metadata an existing model handling behavior that is already allowed in YANG and which has been used by multiple standard organizations and vendors. It is the aim to create one single standard solution for documenting modification restrictions on data declared as configuration, instead of the multiple existing vendor and organization specific solutions. See Appendix B <https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag#Existing_implementations> for existing implementations.¶ <https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag#section-1-1>




> - For any immutable related metadata annotations, I think that this additional metadata should only be returned to clients when explicit requested via a separate RPC parameter, and I think that the draft needs to add text for protocol capabilities used to indicate whether this new option is supported (e.g., along the lines of RFC 6243, with-defaults).

Somewhat agree (Principle of Least Astonishment), though it's neither illegal, would cause client problems, or cause excessive network utilization (unlike with-defaults).

K.