[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: consecutive locks on the same session



Thanks Andy.  Yep, I don't believe we should terminate the 
session either but just wanted to be sure.

--jng 

> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com] 
> Sent: Saturday, June 04, 2005 7:29 AM
> To: John Ng (jng)
> Cc: Steven Berl (sberl); James Balestriere (jbalestr); 
> netconf@ops.ietf.org
> Subject: Re: consecutive locks on the same session
> 
> John Ng (jng) wrote:
> 
> >If we decide it is an error, should the session terminate?  
> >Or continue and just reply with the error?
> >  
> >
> 
> We already decided a long time ago it is an error.
> The section cited below explains what to do if a lock is in use.
> 
> Why would we want to terminate the session?
> That's a bit severe I think.  It's just an <rpc> failing.
> 
> However, in reading prot-06 again, the text has a bug.
> It's hard to spot because of the hyphenated word at the end 
> of the line (ID-nit!)
> 
> -----------------------------------
> 
> section 7.5, heading 'Negative Response',  para 2,  sentence 1:
> 
> OLD:
>   
>    If the lock is already held, the <error-tag> will be in-use and ...
> 
> NEW:
> 
>   If the lock is already held, the <error-tag> will be 
> 'lock-denied' and ...
> 
> ----------------------------------
> 
> Note that 'lock-denied' error code exists because the 
> 'session-id' of the lock holder needs to be returned.
> The errors 'in-use' and 'resource-denied' are intended for 
> generic cases or internal constructs not exposed to users.
> 
> >--jng
> >
> >  
> >
> 
> Andy
> 
> 
> >>-----Original Message-----
> >>From: owner-netconf@ops.ietf.org
> >>[mailto:owner-netconf@ops.ietf.org] On Behalf Of Steven Berl (sberl)
> >>Sent: Wednesday, June 01, 2005 12:00 PM
> >>To: James Balestriere (jbalestr); netconf@ops.ietf.org
> >>Subject: RE: consecutive locks on the same session
> >>
> >>Didn't see any other replies to this, so I will try.
> >>
> >>I don't think the current draft specifies this behavior. I propose 
> >>that an attempt to lock an already locked configuration should 
> >>generate an error just as if the lock were held by another session. 
> >>The error message contains the session-id of the session 
> holding the 
> >>lock. The manager software can compare this session-id with its 
> >>current session-id (which it received in the hello) and 
> know that the 
> >>lock is held by itself.
> >>
> >>Other opinions?
> >>
> >>-steve
> >>
> >>    
> >>
> >>>-----Original Message-----
> >>>From: owner-netconf@ops.ietf.org
> >>>[mailto:owner-netconf@ops.ietf.org] On Behalf Of James Balestriere
> >>>(jbalestr)
> >>>Sent: Wednesday, May 18, 2005 3:32 PM
> >>>To: netconf@ops.ietf.org
> >>>Subject: consecutive locks on the same session
> >>>
> >>> 
> >>> if a session does a lock and it gets the lock we send ok.
> >>> if it does a lock again whilst it still has the lock, does
> >>>      
> >>>
> >>it  get an
> >>    
> >>
> >>>error or ok ?
> >>> 
> >>> I am suspecting we send ok but it is not very clear from the spec.
> >>> 
> >>> James.
> >>> 
> >>>
> >>>
> >>>
> >>>--
> >>>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/>
> >>>
> >>>      
> >>>
> >>--
> >>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/>
> >>
> >>    
> >>
> >
> >--
> >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/>
> >
> >
> >  
> >
> 

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