Subject: Re: [netmod] The "resolve-system" parameter in the new "with-system" I-D

From: "Jan Lindblad (jlindbla)" <[email-masked]>
Date: Tue, 1 Mar 2022 13:23:32 +0000

Kent, WG,

> [As a contributor]
> 
> This message regards the value of the "resolve-system” parameter defined in the latest “with-system” draft.
> 
> The "resolve-system” parameter is defined in its own optional-to-implement module.  The question is if the WG believes the parameter is valuable or if the module should be removed from the draft before adoption call?

I believe the resolve-system parameter has value in certain use cases. In particular I think the flag matches common expectations from the RESTCONF community, where a complete understanding of the server's configuration is rarely desired, and where injecting multiple, disjunct pieces of configuration is perceived as complicated by some.

To model the resolve-system flag as an optional capability is the best trade off in my opinion. For some device types it doesn't make sense to implement this flag, while for other device types, this might become the typical client behavior.

Best Regards,
/jan

> The "resolve-system” parameter is a convenience function, enabling clients to NOT have “manually” copy/paste referenced system-defined nodes into <running>.  Instead, by including this parameter in <edit-config>, <commit>, or equivalents, the client requests the server to itself copy/paste the missing system nodes into <running>. 
> 
> It is true that this work began with a goal of never having to copy/paste system-defined nodes into <running>.   The concern wasn’t about *how* the referenced system-defined nodes came to be in <running>, but *if* they needed to be in <running> at all.   But now that the current draft says referenced system-nodes MUST be in <running>, the only remaining question regards *how* they came to be in <running>.  
> 
> Yes, there is convenience in using the “resolve-system” parameter, but there is also some implementation complexity.   Ultimately, the question is, is the convenience worth the complexity?   Thoughts?
> 
> Thanks,
> Kent
>