Re: consecutive locks on the same session

[Andy Bierman <ietf@andybierman.com>]

Steven Berl (sberl) wrote:

> Well I guess it wasn't obvious enough to someone who wasn't part of the
> WG discussions. Otherwise the question would never have been asked. :-)
>  

You're right.   We often leave out rationale for decisions and details 
in RFCs.
However, one needs to read specifications carefully.  In this situation, 
no mention
of this corner-case means it isn't one.  I would only expect a sentence 
dedicated
to a special-case if it was handled differently than the normal case.

Andy

> I'd suggest that if there is another opportunity to update the doc, then
> there be a sentence added explicitly calling out this situation. But I
> don't think it is important enough to derail the current draft if the
> doc is otherwise acceptable. 
>
> -steve
>
>  
>
> > -----Original Message-----
> > From: Andy Bierman [mailto:ietf@andybierman.com] 
> > Sent: Wednesday, June 01, 2005 2:57 PM
> > To: Steven Berl (sberl)
> > Cc: James Balestriere (jbalestr); netconf@ops.ietf.org
> > Subject: Re: consecutive locks on the same session
> >
> > Steven Berl (sberl) wrote:
> >
> >    
> >
> > > 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?
> > >
> > >
> > >      
> > not opinion -- fact -- this is how the protocol works and the 
> > document is clear (IMO) that if the lock is already in use, 
> > an error is returned.  
> > It doesn't
> > matter which session already holds the lock.
> >
> >
> >    
> >
> > > -steve
> > >
> > >
> > >      
> > Andy
> >
> >    
> >
> > >      
> > >
> > > > -----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/>