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

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 7 Aug 2018 22:19:27 -0700

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.

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 08 Aug 2018 09:36:46 +0200 (CEST)

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 09 Aug 2018 11:20:22 +0200

Hi,

as the author of this document, I support the adoption.

Rob agreed to become a co-author.

Thanks, Lada

On Tue, 2018-08-07 at 22:19 -0700, Mahesh Jethanandani 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
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 09 Aug 2018 11:44:07 +0200

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:
> > 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.
> > 
> > 
>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 13 Aug 2018 09:40:12 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> 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.

Yes this needs to be addressed.  (The solution might be that both
cannot be used at the same time)

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

Agreed.

> client-side web applications.

Maybe I wasn't clear - my comment was supposed to support the
introduciotn of this new staging capability; I meant that even in the
case that the client prepares a single message with all changes, this
new staging capability can be useful.

/martin