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

Ladislav Lhotka <lhotka@nic.cz> Thu, 09 August 2018 09:44 UTC

Return-Path: <lhotka@nic.cz>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CBE130F12 for <netconf@ietfa.amsl.com>; Thu, 9 Aug 2018 02:44:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOh1sHc9o0Mo for <netconf@ietfa.amsl.com>; Thu, 9 Aug 2018 02:44:09 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52D6B130F0A for <netconf@ietf.org>; Thu, 9 Aug 2018 02:44:09 -0700 (PDT)
Received: from birdie (unknown [IPv6:2a02:2788:1038:6bd::7]) by mail.nic.cz (Postfix) with ESMTPSA id C62FA6244A for <netconf@ietf.org>; Thu, 9 Aug 2018 11:44:07 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1533807847; bh=tHOG8R/Hip9/QgS9MqO0LE7ICJwqjyW278Sz+8/SSHc=; h=From:To:Date; b=WzdK6FCzyAScmuHllTDP4/ImT7bxg2yNC/l5JOzEKHjFBSnumx2vVTL4vsni4ms0x Uoa5g0xmdAvaupJsAWO5fEK1LXEtOHiGd4tzBiJkYPElSZYGKMO0K32EUA+3md5USd jUo+H0yJgE3seJxHdChUH2IbC2ZYdU2Wx7zkTf3k=
Message-ID: <6e80b426e3e85b52d4ce2b52362504144d4d2725.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: netconf@ietf.org
Date: Thu, 09 Aug 2018 11:44:07 +0200
In-Reply-To: <20180808.093646.6873295121240790.mbj@tail-f.com>
References: <F9C9F795-FA36-48A9-9020-4D3812457628@gmail.com> <20180808.093646.6873295121240790.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.5
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/eV72x9L4b5torjrhWWhHTo5cXsc>
Subject: Re: [Netconf] WG adoption poll for draft-lhotka-netconf-restconf-transactions-00
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Aug 2018 09:44:13 -0000

Hi Martin,

Rob had similar comments in Montreal, so these issues will certainly be
discussed. I am somewhat concerned that exposing the client to various
combinations of other datastores will considerably increase the complexity. For
example, it is not clear to me how <staging> would interact with <candidate>, if
an implementation supports the latter.

It is true that the transaction can be mostly prepared on the client side - this
is basically the mode of operation of git. However:

1. When the final changes are sent to the server, a conflict may arise, caused
by another client concurrently editing the target datastore (as with "git
push"). This needs to be addressed in any case.

2. This approach is not suitable for simple clients such as shell scripts or
client-side web applications.

Lada
 
On Wed, 2018-08-08 at 09:36 +0200, Martin Bjorklund wrote:
> Hi,
> 
> 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.
> 
> 
> 
> /martin
> 
> 
> 
> 
> Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
> > In the NETCONF 102 WG meeting, Robert presented the following document on
> > behalf of Lada, and asked for WG adoption.
> > 
> > https://tools.ietf.org/html/draft-lhotka-netconf-restconf-transactions-00 <
> > https://tools.ietf.org/html/draft-lhotka-netconf-restconf-transactions-00>
> > 
> > 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.
> > 
> > 
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67