Subject: RE: minor <lock> ambiguity

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 21 Apr 2006 10:25:28 +0200

I agree with this logic and support the statements
by Andy and Martin

Bert

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Andy Bierman
> Sent: Thursday, April 20, 2006 20:26
> To: Martin Bjorklund
> Cc: [email-masked]
> Subject: Re: minor <lock> ambiguity
> 
> 
> Martin Bjorklund wrote:
> > Andy Bierman <[email-masked]> 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.
> > 
> 
> Mine too.
> 
> Also, an operation-failed error will be returned
> if attempt to unlock a config that is not locked is made.
> This is explicitly stated in sec. 7.6.
> It would be inconsistent to treat this as an error,
> but not the similar case for <lock>.
> 
> > 
> > /martin
> 
> Andy
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Apr 2006 17:12:03 -0700

> I agree with this logic and support the statements

So here is the RFC Editor note:

draft-ietf-netconf-prot-12.txt, page 46, para 6:

OLD:

     A lock MUST not be granted if any of the following conditions are
     true:

       *  a lock is already held by another NETCONF session or another
                                    ^^^^^^^
          entity

NEW:

     A lock MUST not be granted if any of the following conditions are
     true:

       *  a lock is already held by any NETCONF session or another
          entity

Andy