Subject: [netconf] comments on draft-lindblad-netconf-transaction-id

From: Qin Wu <[email-masked]>
Date: Tue, 22 Mar 2022 08:11:17 +0000

Hi, Jan:
Nice presentation in yesterday netconf session, thank for well documented problem statements. I have read through the latest version of draft-lindblad-netconf-transaction-id, believe the idea is very close to Optimistic concurrency control or Optimistic lock.
Three things I want to make sure

1.       Do we intend to replace NETCONF lock and partial lock with transaction id proposed in this draft?

2.       Every time there has been a configuration change on the server, how the server synchronize transaction id to all the clients who get access to the same server? Return updated transaction id only when the client polls the server?

3.       When multiple clients in parallel poll the same server on the same resource e.g., frequent sent edit-configs to perform operation on the same data resource, can transaction id handle this scenarios?
Thanks in advance!

-Qin

---

From: "Jan Lindblad (jlindbla)" <[email-masked]>
Date: Wed, 23 Mar 2022 22:20:42 +0000

Qin, WG,

Thank you!
Yes, this is a NETCONF adaptation of an optimistic locking design.

I think traditional locks and partial locks have their uses as well, and I'm not sure we could remove them any time soon even if we wanted to, due to backwards compatibility constraints.

Clients that want to stay constantly updated can already use YANG Push. YANG Push alone is not enough to solve the issues discussed in this draft, but in the next revision we intend to describe how YANG Push can get more efficient when used with the etag concept.

This depends on what you mean by 'handle'. The mechanism here will detect changes by another client, and possibly abort an edit-config. Changes would also be detected at get-config or through YANG Push, but with some delay.

Best Regards,
/jan