Subject: RE: kill-session: editorial mistake

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 22 Dec 2005 10:58:39 -0800

Hi,

I agree with Lei Zhang - the spec is _very_ deficient
in stating this subtle behavior.

Thanks to Andy for clarifying the (somewhat) surprising
intended behavior - but expecting implementors to get
that much implied context out of these paragraphs in
the spec is inherently unsafe for interoperability.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Lei Zhang
> Sent: Thursday, December 22, 2005 12:01 PM
> To: Andy Bierman
> Cc: [email-masked]
> Subject: Re: kill-session: editorial mistake
> 
> 
> Andy Bierman wrote:
> 
> > Sec. 7.9 is referring to changes that have been commited 
> from <candidate>
> > to <running>.  If the <kill-session> occurs after the first 
> <commit> 
> > but before
> > the second <commit>, then the agent treats the 
> <kill-session> the same
> > as a dropped session, and reverts the <running> config.
> 
> ok that sounds reasonable. The text sure can use some rewrite 
> to clarify 
> things up.
> 
> Thanks,
> Lei
> 
> 
> 
> 
> --
> 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: Thu, 22 Dec 2005 11:28:39 -0800

>the spec is inherently unsafe for interoperability.

Agreed that this detail is fairly well buried.

At first, I thought this was a bug, but then I remembered we
talked about this in the past (forget when).  Phil explained
to me that this is a feature, not a bug.

I always learned that you try to keep the Astonishment Factor as low
as possible.  This is certainly not a side effect of <unlock> that one
would reasonably expect to find.  But if you use locks correctly,
nothing will be in the <candidate> to discard.

>- Ira

Andy