Re: minor <lock> ambiguity

[Martin Bjorklund <mbj@tail-f.com>]

Andy Bierman <ietf@andybierman.com> wrote:
> Hi,
> 
> prot-12:sec. 7.5, para 2 says a lock request must fail
> if "an existing session" hold the lock.
> 
> para 6, bullet 2 says a lock must not be granted
> if "another NETCONF session" holds the locks.
> 
> Issue:  Does the agent need to check for the corner-case
> where the manager is calling lock multiple times,
> or is the agent strict and treat this as an error?
> 
> I remember we discussed this issue in the past, but I
> don't remember making a decision:
> 
> Is it an error if a session call <lock> on a config
> that it already locked?  This is probably a programming
> error on the NMS, so IMO a lock-denied error should always be
> returned if any attempt is made to lock an already locked config.
> 
> Therefore, para. 2 is correct and para. 6 is incorrect.
> 
> Can we agree on this interpretation so managers can expect
> a consistent API?

I think this is very reasonable.  (The description of lock-denied also
says "another entity".)

BTW, this is the way our agent behaves; i.e. it sends a lock-denied
error if the same session tries to grab a lock twice.


/martin

--
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/>