Subject: Re: [Netconf] RESTCONF and confirmed-commit

From: Martin Bjorklund <[email-masked]>
Date: Fri, 08 Jan 2016 12:12:38 +0100 (CET)

Hi,

Andy Bierman <[email-masked]> wrote:
> Hi,
> 
> Sec. 1.3 in RESTCONF-09 does not mention confirmed-commit at all.
> I just finished implementing confirmed-commit for RESTCONF
> and some details should be mentioned in this section.
> 
> 1) persist-id
> 
> A normal NETCONF commit will fail if a confirmed-commit is running
> with a 'persist-id' lock, and the session does not provide the correct
> value.
> Since standard RESTCONF has no way of passing a 'persist-id'
> parameter to the edit or commit, any RESTCONF edit must fail
> if this parameter is expected by the server.
> 
> If no 'persist-id' is expected, then the RESTCONF edit will
> be processed by the server, and it will act as the confirming commit.

This seems pretty scary at first sight, but consistent with NETCONF.
If the NETCONF client want's to avoid that someone else performs the
confirming commit, it should grab a lock.

> 2) shared candidate
> 
> This section does not mention that any edits in the candidate at
> the time of the RESTCONF edit will also be part of the commit.

Ok.

> I propose that new text be added to sec. 1.3 similar to the text above.

Ok.

An alternative to both these could be to reject any RESTCONF request
with 409 if (1) there is an ongoing confirmed commit, or (2) the
candidate contains uncommitted changes.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 8 Jan 2016 18:44:37 -0800

> confirming commit, it should grab a lock.

Actually, it was quite straight-forward to implement the confirmed,
confirm-timeout, persist, and persist-id query parameters.

We implemented full access to all RPCs (XML anyway) even though
some ietf-netconf operations don't really work because a RESTCONF "session"
is 1 request.  But "commit" and "cancel-commit" work fine.
The RESTCONF client MUST provide a "persist" parameter,
or else the server will cancel the confirmed-commit when
the initiating session terminates (after this 1 request).

IMO the entire NETCONF locking and shared candidate design needs to
be tossed in the dumpster and replaced with a concurrent transaction model,
but that is another topic, out of scope for now.

> candidate contains uncommitted changes.

I thought of that but IMO being consistent with NETCONF would be better.
We may update NETCONF someday, and then we can decide how to fix
this (perhaps with private candidates).

> /martin

Andy