What I was expressing is that if you wish to, for example, delete an interface without
deleting one that might be created, then after you have done your "get" operation
you must lock the configuration to prevent, for example, another interface being created
by another user that will be SILENTLY deleted when you submit your delete operation.
This is true if you are updating the entire configuration, or if your
interfaces are sequentially named on the fly. Those circumstances do
exist, and some care must be taken to avoid such race conditions.
Locking is a viable approach to tackling the problem. The granularity
of locking is something I addressed in my previous message.The absence of an agreement upon how to express locking makes my point even more strongly.
We should not adopt an approach that relies upon locking to achieve robustness. The draft
requires locking if it is not to introduce race conditions not exhibited by other approaches.
Therefore, following your lead, the draft is seriously broken. There are much better solutions.
Solutions that do not introduce these race conditions.
For some value of "serious". I would agree that there is a need for
locking on big hardware. On small hardware the need is perhaps less.
That's a marketing decision (indeed some hardware might not even support
locking at all). Ultimately the protocol attempts to allow the
expression of what the underlying hardware and software can reasonably
support without having to warp any given operating model.