Hi, Kent, Rob, Jan Apologies for reacting to this thread late.
I think that regarding the isInvariant concept in the liaison, 3GPP is asking to model the object which cannot be modified once created. While it's just a natural workaround for the clients to first delete it and then recreate with the really desired value, but not requiring that clients must do that. As Jan pointed out, all the use cases written in the current document now are targeting configuration cannot be updated or deleted. I also feel it better to define identities to only support our current use cases now, and leave the door open to allow other implementation to extend more if needed. Again, as mentioned, the objective is to document existing server behaviors, if the server already internally considers some configuration immutable for valid reasons. It doesn't apply to servers which don't have any immutable configuration, much less to encourage servers to add more such restrictions. The document should be updated if it failed to make that clear. Best Regards, Qiufang From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen Sent: Thursday, April 6, 2023 12:12 AM To: Rob Wilton (rwilton) <rwil...@cisco.com<mailto:rwil...@cisco.com>> Cc: Jan Lindblad (jlindbla) <jlindbla=40cisco....@dmarc.ietf.org<mailto:jlindbla=40cisco....@dmarc.ietf.org>>; netmod@ietf.org<mailto:netmod@ietf.org> Subject: Re: [netmod] Comments on draft-ma-netmod-immutable-flag-06 Hi Rob, My prior response to you focused on what the draft specifies (not the liaison), since you wrote: "Fundamentally, I generally interpret this draft as saying: NETCONF/YANG doesn't really match the existing management model/API in 3GPP and hence we want to make non-backwards compatible changes to NETCONF/YANG to match the 3GPP semantics." Which isn't the draft's proposition. Maybe you meant s/draft/liaison/? I just re-read the liaison and I fail to see how the immutable-flag draft's goal of describing existing server behavior isn't aligned with the liaison. At the end of the day, it doesn't really matter what extensions exist in the YANG, or annotations in the data, the client can send any request it wants to the server and, ultimately, the server must enforce whatever it wants to enforce. It effectively comes down to a quality-assurance effort to determine if the YANG accurately describes the server's existing behavior. To the extent that XC/Y tools might someday grok the YANG-extensions and/or data-annotations (to do some of the heavy-lifting) is out of scope, IMO. I'm unsure if the set of the extensions and annotations in the current draft are robust enough to sufficiently support every use-case. The WG could create taxonomies and the like to prove this out. But a possibly better solution is for the immutable-flag draft to define behaviors using identities (instead of bits/boolean), so that 1) we don't have to define a perfect set of flags upfront and 2) applications (3GPP) can define additional flags if desired. Whilst I agree that it is best for servers to be completely transactional, avoiding the need to delete a parent container in order to recreate a previously-immutable child, 3GPP has already decided to do this. I see no issue in providing them an ability to capture this semantic using identities they defined themselves. Kent On Apr 5, 2023, at 6:49 AM, Rob Wilton (rwilton) <rwil...@cisco.com<mailto:rwil...@cisco.com>> wrote: 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<mailto:netmod-boun...@ietf.org>> On Behalf Of Kent Watsen Sent: 03 April 2023 22:23 To: Rob Wilton (rwilton) <rwilton=40cisco....@dmarc.ietf.org<mailto:rwilton=40cisco....@dmarc.ietf.org>> Cc: Jan Lindblad (jlindbla) <jlindbla=40cisco....@dmarc.ietf.org<mailto:jlindbla=40cisco....@dmarc.ietf.org>>; netmod@ietf.org<mailto: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
