Re: [netconf] system configuration sync mechanism

"maqiufang (A)" <> Tue, 29 June 2021 11:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A5133A3070 for <>; Tue, 29 Jun 2021 04:18:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1CQy4BXZjb6n for <>; Tue, 29 Jun 2021 04:18:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 27FFB3A306D for <>; Tue, 29 Jun 2021 04:18:21 -0700 (PDT)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4GDhSf27Srz6L4s2 for <>; Tue, 29 Jun 2021 19:04:34 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Tue, 29 Jun 2021 13:18:17 +0200
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Tue, 29 Jun 2021 19:18:15 +0800
Received: from ([]) by ([]) with mapi id 15.01.2176.012; Tue, 29 Jun 2021 19:18:15 +0800
From: "maqiufang (A)" <>
To: "" <>
CC: "" <>
Thread-Topic: [netconf] system configuration sync mechanism
Thread-Index: Addn4K+zt1m84GV6QrqhDxVqt12upwEU6oGAAB6TrRA=
Date: Tue, 29 Jun 2021 11:18:15 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_765757acb49741f7a64013b5525cdbb4huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [netconf] system configuration sync mechanism
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Jun 2021 11:18:26 -0000

Hi, Kent:
Thanks for kicking off some discussion around this draft. Please see my reply inline.

From: Kent Watsen []
Sent: Tuesday, June 29, 2021 7:44 AM
To: maqiufang (A) <>
Subject: 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:  Is this similar to what you have in mind?
[Qiufang Ma]  Yes. Physical-resource-independent system configuration is generated when the device is powered on and has nothing to do with the physical resource. Loopback interface may be the most common physical-resource-independent system configuration. To my knowledge, many vendors ((e.g., Huawei NE40E and Cisco IOS XR) will provide several predefined user groups and/or task groups which are used for authentication, authorization and accounting (AAA) services. Since these configurations are provided by the device/system, they could  be treated as system configuration. I think your  information about the predefined hidden configuration group which contains preconfigured values should also be treated the same.
More examples about system configurations would be worked on and added in  the next version of the draft.:)
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.
[Qiufang Ma] Thanks for bringing it to my attention, I would take RESTCONF into consideration and see how the proposal works on RESTCONF.

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)?
[Qiufang Ma] Yes, agree. Actually we don’t really want to cause any confusion or misunderstandings. This term controls whether the device will update <running> with system configuration change or not.
Your proposal looks good to me, other suggestions are also welcome here.

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...
[Qiufang Ma] The issue we try to resolve here is that in order for system configurations being referenced or to make sure a successful validation when the system configuration is in the when/must statement, the system configuration must be retrieved from <operational> firstly and then copied into <running> manually, which is cumbersome. In this case, we would like to define some kind of mechanism to synchronize system configuration into <running>. Currently two system configuration data handling modes are specified. One will update <running> with any system configuration change automatically, and the other will not, so that the implementer may choose the mode more suitable for them. Hopefully this clarifies what we try to do. Please feel free to comment or suggest.

Best Regards,
Qiufang Ma

K.  // contributor

On Jun 22, 2021, at 11:43 PM, maqiufang (A) <<>> wrote:

Dear all,
One of the open issues of draft 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

       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.
            o   implementation complexity

Option 2: To define a RPC operation to propagate <running> with <system>
       o  client-driven: it totally depends on the client when and how to populate <running>.
       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<>