Re: [Netconf] WG adoption poll for draft-lhotka-netconf-restconf-transactions-00

Martin Bjorklund <> Wed, 08 August 2018 07:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 356AA130DE6 for <>; Wed, 8 Aug 2018 00:36:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EmINaMmbkLvq for <>; Wed, 8 Aug 2018 00:36:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2D606130E78 for <>; Wed, 8 Aug 2018 00:36:48 -0700 (PDT)
Received: from localhost ( []) by (Postfix) with ESMTPSA id 76D921AE018A; Wed, 8 Aug 2018 09:36:46 +0200 (CEST)
Date: Wed, 08 Aug 2018 09:36:46 +0200 (CEST)
Message-Id: <>
From: Martin Bjorklund <>
In-Reply-To: <>
References: <>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Netconf] WG adoption poll for draft-lhotka-netconf-restconf-transactions-00
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Network Configuration WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Aug 2018 07:37:01 -0000


I like the idea of having a "private candidate" or "staging"
datastore.  However, I don't think the solution in this draft is
adequate.  Specifically, I don't think we can change the semantics of
the existing {+restconf}/data resource.

I think a better solution would be to introduce "staging" as a proper
NMDA datastore, with associated rpcs (similar to the ones in this
draft (*)).  This has the advantage that "staging" becomes available
not only for RESTCONF, but also for NETCONF.

(*) I think that maybe some other operations on "staging" might be
useful as well, such as validate and confirmed-commit.

When this draft was presented in Montreal, someone made a comment that
clients often construct a single message with all changes and send it
in one go.  This is my experience as well, but even in such
environments this capability can be useful for orchestration of
network-wide transactions.

FWIW, we have a "transaction" capability for NETCONF that has turned
out to be very useful (it's been used at least since 2007).  It is
consists of rpcs to start a transaction towards any datastore, and
then it exposes std two-phase commit operations via NETCONF rpcs.
This is stateful (tied to the session), so it doesn't work that well
for RESTCONF.  I would love to see a standard solution that could
replace this, and also work for RESTCONF.


Mahesh Jethanandani <> wrote:
> In the NETCONF 102 WG meeting, Robert presented the following document on behalf of Lada, and asked for WG adoption.
> <>
> This starts an adoption poll for the above draft. Please indicate your support or objection to the adoption poll. If objecting, please state your reasons by responding on this thread.
> Thanks.
> Mahesh & Kent.