Re: Issue 13.12) <lock>

[William Caban <william@hpcf.upr.edu>]

On Tue, 2003-12-02 at 20:37, Andy Bierman wrote:
> 13.12.1) Multiple concurrent locks
> 
>   - Should multiple occurrences of the <target> parameter be 
>     allowed to acquire multiple locks at once?
For this I will say that instead of allowing multiple locks at once lets
try:
	* no locks for reading
	* only one lock allowed at the same time for modification
	 of a <target> and any other session requesting a
	 simultaneous lock just receive an error notification.
	* other session only "reading" receive a notification
	 if any modification was done during that time such that
	 they will be able to update their views.

> 13.12.2) <target> Clarification
> 
>   - Target parameter says it is optional; should say default <running>
I vote for this just to make it clear for the user/programmer.

> 13.12.3) Error handling
> 
>   - Negative response says session-id of lock owner will be returned; 
>     how will actually be done (specific element)
> 
>   - What error response is given if a <lock> fails because a 
>     non-NETCONF entity holds the lock?
What about just a notification stating that the lock is hold by the
system and create a special session id like session-id="-1" or reserve
session-id="0" for this type of case.

-- 
William Caban <william@hpcf.upr.edu>


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>