> Larry Menten wrote:
>
> With a transaction representation that allows the target of the operation
> to be named explicitly, offers an delete and add operation with an error
> return if the target does not exist, and the ability to group
> sub-transactions
> into an atomic operation, locking becomes optional for many management
> tasks.
I want to make sure I understand your point. Are you saying that we need to provide locking however it is up to the management station to choose if it wants to use the locking?
I believe that locking is absolutely required to be part of the protocol.
Most of the discussion I have seen is around locking and transactions. I would like to offer another perspective. There are applications that want to lock some piece of the configuration and hold the lock for long periods of time. This is exactly the semantics that COPS-PR uses when doing QoS configuration; the COPS-PR client has exclusive control over the QoS PIBs that it is managing. The locking semantics that COPS-PR defines are very useful since the client needs to keep synchronized with the configuration on the device. Without the long held exclusive lock it would be very expensive (and possibly error prone) for the client to keep synchronized.
While on the subject of locking, let me offer one more opinion. I believe that the protocol needs to offer locking to any node in to the tree, including a leaf. I think that the data models should describe the actual level of locking that is desired -- which may not be as far down into the tree as what the protocol allows. I also think that the protocol should offer a method to discover what can be locked.
> Larry
>
> --
> Larry Menten Lucent Technologies/Bell Laboratories
> Phone: 908 582-4467 600 Mountain Avenue, Murray Hill, NJ 07974 USA
Regards, /gww