Hi Kent, Some of my concern stems from the fact that during the NMDA architecture discussions there was a strong desire to make the configuration data stored in <running> to be owned by the client. I.e., the server has the right to accept or reject a particular configuration but ultimately it is the client that should control what is in <running>. Related to this, is the goal of ensuring the validation of the configuration is based on the state that the configuration represents, not the particular config edit that is being made to transition the configuration into that state. I.e., it should be possible for a client to change the configuration from any valid state A to any valid state B, without requiring extra client orchestration steps to keep the server happy (e.g., you can transition from A to B, but must go via C, D and E on the way). Or to put it another way, if such steps are required, then it is much simpler (for an automation client) to do those transitional steps on the server than it is to expose and force them on to the client.
As you point out, existing implementations don’t always follow these rules above, but I regard these as warts in the implementations relative to following the ideal architecture above. As such, I have little issue with a YANG extension or metadata annotation to programmatically indicate to clients where these aberrations occur for this use case. But this isn’t what the 3GPP liaison is asking for. They are requesting to bake the edit-config constraints directly into the management APIs defined in YANG because this is how their underlying management model is defined and they don’t want to change their underlying paradigm. No longer is YANG just defining the configuration data model, but protocol edit-config semantics are being merged and baked into the data model defining the management API. These newly defined management APIs will not just work with existing generic YANG clients and orchestrators because I presume that the clients will require custom code to be able to successfully interface with the server implementing these models. Perhaps these annotations provide sufficient information for YANG clients to generically work around these restrictions? But even in the case that they do then I still question whether that is really helpful. I.e., what is ultimately achieved other than the addition of some extra complexity in the automation, and what is the true goal here. If the aim is to signal to the client that there are some properties that cannot be changed without tearing down the containing service in a traffic impacting way, then rather than marking the properties as being immutable, it might be sufficient to annotate them as service impacting if changed. This might still provide the necessary visibility and awareness to the client, whilst avoiding additional orchestration complexity for clients. After all, there are many properties in the network configuration models standardized in the IETF (and OpenConfig) that are similarly service impacting if changed, that don’t seemingly require any protection. It also feels that we are on the path of fracturing the definition of the NETCONF/YANG management protocols, which is somewhat like how OpenConfig decided to interpret the pattern statement regex language differently (which they have now backtracked on) or their recent statement that servers are not generally expected/required to validate leaf ref constraints in the running configuration. Each of these little cuts, whilst innocent and good intentioned on their own, risk gradually devaluing the common standards by creating many incompatible subvariants of the language and protocols. Hence, this is why I think Jan’s approach of looking at the individual problems that are being solved and having a discussion as to what is the best way of solving these individual problems may result in a better overall solution. Specifically, is there a compromise that can meet 3GPP’s and ITU’s goals without eroding the underlying NETCONF/YANG architecture? Regards, Rob // Still no hats. From: netmod <netmod-boun...@ietf.org> On Behalf Of Kent Watsen Sent: 03 April 2023 22:23 To: Rob Wilton (rwilton) <rwilton=40cisco....@dmarc.ietf.org> Cc: Jan Lindblad (jlindbla) <jlindbla=40cisco....@dmarc.ietf.org>; netmod@ietf.org Subject: Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06 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.
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
