Re: [netconf] system configuration sync mechanism

Hi Qiufang,

I just read your draft and have a few comments:

1) I wish there were more examples, especially for "resource-independent” configuration.  I understand well enough "resource-dependent" (dynamic) configuration, but am unclear about what all "resource-independent” entails.  By example, JUNOS has a concept called “JUNOS defaults”, which is effectively read-only and hidden-by-default configuration that, most times, must be referenced in order to take effect.   For instance, check the examples halfway down this page: https://nextheader.net/2016/06/10/junos-defaults-group.  Is this similar to what you have in mind?

2) Please treat NETCONF and RESTCONF equally.  Currently the draft speaks only to how it impacts NETCONF, but it should equally show how RESTCONF in impacted.

3) The “basic mode” term sounds too close to the “with-defaults” basic modes...can we please pick another name (e.g., system-datastore-operating-mode)?  

Regarding your question below I don’t feel ready to comment on it yet.  I do understand the JUNOS model and, if it is compatible, would recommend considering, as it is implemented and seems to be working well enough.  That said, it might be the case that every vendor has defined their own way and each needs to be documented in turn...

K.  // contributor

> On Jun 22, 2021, at 11:43 PM, maqiufang (A) <maqiufang1@huawei.com> wrote:
> 
> Dear all, 
> One of the open issues of draft https://datatracker.ietf.org/doc/html/draft-ma-netconf-with-system-02 <https://datatracker.ietf.org/doc/html/draft-ma-netconf-with-system-02> is about how to synchronize the system configuration into <running>.
> I think we could have 2 options.
> Option 1: Any update in <system> will be synced up into <running> automatically
>   PRO:
>        o  effective for the client: there is no need for the client to retrieve the referenced system configuration from <operational> and then copy it into <running> manually.
>   CON: 
>             o   implementation complexity 
>     
> Option 2: To define a RPC operation to propagate <running> with <system>
>   PRO:
>        o  client-driven: it totally depends on the client when and how to populate <running>.
>   CON:
>        o  The client needs to :
> o   spend energy to detect the <system> update and operate the RPC every time the client references the system configuration or the system configuration is in the when/must statement.
> o   subscribe the <system> update and copy it into <running> whenever an update is detected.
>  
> I incline to the view that this issue involves some kind of trade-off, which is hard to distinguish the preference.
> Maybe both options can be reserved and differentiated by different modes, so that the server implementer may choose from.
> Any thoughts?
>  
>  
> Best Regards,
> Qiufang Ma
> _______________________________________________
> netconf mailing list
> netconf@ietf.org <mailto:netconf@ietf.org>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>