Glenn Waters wrote:
While it's true that this was a form of locking, the purpose was to allow different management systems manage different domains of configuration. So for instance, you could have a QoS manager handle QoS and a VPN manager manage VPNs. It didn't work with implementations that cross leveraged different parts of their configurations. That was just about everyone, including Cisco. You would in essence have to change one of the fundamental concepts that has been in networking for a long time- the access list.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.
Locking of granular objects would be a good thing. But since we don't even have a standard meta-model I think we could end up adding the wrong semantics if we are not careful. The XMLCONF draft is extensible in this way by way of capabilities, so that we can add the appropriate locking when we're ready.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.