Subject: [Netconf] Enhancement proposal for NetConf's <lock>

From: "Kent Watsen" <[email-masked]>
Date: Wed, 30 Jul 2008 13:41:23 -0700

Section 7.5 (i.e. "<lock>") of the NetConf spec reads:

      A lock MUST not be granted if either of the following conditions
      is true:
 
       * A lock is already held by any NETCONF session or another
         entity.

       * The target configuration is <candidate>, it has already been
         modified, and these changes have not been committed or rolled
         back.

The 2nd bullet-point can lead to an app wedging itself when its own
editing session drops unexpectedly, prior to it executing <commit>, and
thus leaving contents in the candidate datastore.

This is a problem because the app can't be sure that the contents in the
candidate datastore are from its previous session or some other user,
which results in it going into an exception-handler (potentially
involving end-user approval)

It would be much cleaner if NetConf could provide an auto-rollback
guarantee to <lock> handling dropped sessions.  For instance, something
like: 

   <rpc>
     <lock rollback="automatic">
       ...
     </lock>
   </rpc>

At least then an app can beFrom [email-masked]  Wed Jul 30 13:42:24 2008
Content-class: urn:content-classes:message
Date: Wed, 30 Jul 2008 13:41:23 -0700
From: "Kent Watsen" <[email-masked]>
To: <[email-masked]>
Subject: [Netconf] Enhancement proposal for NetConf's <lock>
Sender: [email-masked]

Section 7.5 (i.e. "<lock>") of the NetConf spec reads:

      A lock MUST not be granted if either of the following conditions
      is true:
 
       * A lock is already held by any NETCONF session or another
         entity.

       * The target configuration is <candidate>, it has already been
         modified, and these changes have not been committed or rolled
         back.

The 2nd bullet-point can lead to an app wedging itself when its own
editing session drops unexpectedly, prior to it executing <commit>, and
thus leaving contents in the candidate datastore.

This is a problem because the app can't be sure that the contents in the
candidate datastore are from its previous session or some other user,
which results in it going into an exception-handler (potentially
involving end-user approval)

It would be much cleaner if NetConf could provide an auto-rollback
guarantee to <lock> handling dropped sessions.  For instance, something
like: 

   <rpc>
     <lock rollback="automatic">
       ...
     </lock>
   </rpc>

At least then an app can be sure  sure that the contents in the candidate
datastore are not leftover from its own editing session and hence
warranting the end-user approval to <discard-changes>

What do you think?

Thanks,
Kent

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

that the contents in the candidate
datastore are not leftover from its own editing session and hence
warranting the end-user approval to <discard-changes>

What do you think?

Thanks,
Kent

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Wed, 30 Jul 2008 14:17:28 -0700

Kent Watsen wrote:
> At least then an app can be sure that the contents in the candidate

This is a <candidate> specific feature, that has little
to do with <lock>.  Rollback as a feature was rejected
by the WG for various reasons.  I would rather have a
coherent NETCONF verb set, which includes rollback,
but this XML attribute for <lock> is not it.

But until then, a band-aid could help...

IMO, a separate operation <discard-changes-on-exit/>,
could be invoked if this behavior was desired.  The
manager could invoke this before any <edit-config>,
and if its session got terminated for any reason,
a <discard-changes> will be invoked at termination time.

> Kent

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 30 Jul 2008 14:17:28 -0700

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 30 Jul 2008 22:28:31 +0100 (IST)

Hi,

"Kent Watsen" <[email-masked]> wrote:
> guarantee to <lock> handling dropped sessions.

Section 8.3.5.2 says:

   When a client fails with outstanding changes to the candidate
   configuration, recovery can be difficult.  To facilitate easy
   recovery, any outstanding changes are discarded when the lock is
   released, whether explicitly with the <unlock> operation or
   implicitly from session failure.

Doesn't this cover what you're asking for?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 30 Jul 2008 22:28:31 +0100 (IST)

Hi,

Section 8.3.5.2 says:

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 30 Jul 2008 14:36:23 -0700

> a <discard-changes> will be invoked at termination time.

Actually, this doesn't work for the same reason your proposal
doesn't work.  What matters is the session *before* the
one that gets the <lock> denied.  You cannot be sure if the dirty
<candidate> buffer was left behind intentionally or
by mistake.

Martin pointed out that if the previous session did take
out a lock, then the agent would have already cleaned
up, the <candidate> would be clean, and a new <lock> will succeed.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 30 Jul 2008 14:36:23 -0700

Andy

---

From: "Kent Watsen" <[email-masked]>
Date: Wed, 30 Jul 2008 15:40:21 -0700

> -----Original Message-----
> From: Martin Bjorklund [mailto:[email-masked]]
> Sent: Wednesday, July 30, 2008 5:29 PM
> To: Kent Watsen
> Cc: [email-masked]
> Subject: Re: [Netconf] Enhancement proposal for NetConf's <lock>
> 
> Hi,
> 

Wow, I do not know how I missed that - exactly where Andy said it should
be...  sorry for the wasted bandwidth!

Thanks,
Kent

---

From: "Kent Watsen" <[email-masked]>
Date: Wed, 30 Jul 2008 15:40:21 -0700

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Wed, 30 Jul 2008 15:52:25 -0700

> be...  sorry for the wasted bandwidth!

Actually, that was Martin.
Don't worry about it -- he is always finding stuff
the rest of us miss...

Andy

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailmanFrom [email-masked]  Wed Jul 30 15:52:23 2008
Date: Wed, 30 Jul 2008 15:52:25 -0700
From: Andy Bierman <[email-masked]>
To: Kent Watsen <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Enhancement proposal for NetConf's <lock>
Sender: [email-masked]

> be...  sorry for the wasted bandwidth!

Actually, that was Martin.
Don't worry about it -- he is always finding stuff
the rest of us miss...

Andy

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listi/listinfo/netconf

nfo/netconf

---

From: "Kent Watsen" <[email-masked]>
Date: Wed, 30 Jul 2008 15:58:05 -0700

> Don't worry about it -- he is always finding stuff

No, I mean you said in your first response "This is a <candidate>
specific feature" and that's exactly where Martin found it in the spec
:)

Cheers,
Kent

---

From: "Kent Watsen" <[email-masked]>
Date: Wed, 30 Jul 2008 15:58:05 -0700

Cheers,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Wed, 30 Jul 2008 16:17:04 -0700

> specific feature" and that's exactly where Martin found it in the spec

The NETCONF WG may want to reconsider the 'capability document template'
approach in RFC 4741.  It may not be intuitive for the reader to
gather bits of data for each verb, partitioned by capability.

<rfc4741-bis-tangent>
BTW, I do not really want a new protocol spec published yet.
This is a super-low priority.  I prefer instead to continue
using the capability extension approach (e.g., Notifications,
partial-lock, with-defaults).

After some experience with that 'content' thing, we can roll up
all the various capabilities in the 'base2' capability, defined
in 4741-bis.
</rfc4741-bis-tangent>

Andy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 30 Jul 2008 16:17:04 -0700

<rfc4741-bis-tangent>

Andy