Re: [netconf] system configuration sync mechanism

Kent Watsen <> Mon, 28 June 2021 23:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2574C3A1BCA for <>; Mon, 28 Jun 2021 16:43:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CJy9i9GoSuuj for <>; Mon, 28 Jun 2021 16:43:35 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BADDD3A1BC7 for <>; Mon, 28 Jun 2021 16:43:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug;; t=1624923813; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=zw+zVHXTctvr3Bidz7clxVdJeY5BUK72YgeHmhjApKg=; b=hkd1/lc+t9B8THjkyb1NxwEwSnmWDQW66Z5qIl1JerhhJPcR7g8ynWQqSPha2Hfc VzEJWDZjwzxwaoUM6nfB4fHwuCb2gKPeuHhNp4+kgasNg3l9CFCdiipHPbHVjX2ozEu BxKK7Nu4JMQ1igXKpr9WgcWqzL5/pfFLrQzweCQ4=
From: Kent Watsen <>
Message-ID: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D40330D6-1357-4B6B-8CB0-52629179A997"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Mon, 28 Jun 2021 23:43:33 +0000
In-Reply-To: <>
Cc: "" <>
To: "maqiufang (A)" <>
References: <>
X-Mailer: Apple Mail (2.3654.
X-SES-Outgoing: 2021.06.28-
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: Mon, 28 Jun 2021 23:43:41 -0000

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?

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) <> 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
>   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
> <>
> <>