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

Ladislav Lhotka <lhotka@nic.cz> 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:
> 
> 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.

Agreed.

> 2. This approach is not suitable for simple clients such as shell scripts or
> 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

> 
> 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
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
> 