Subject: [Netconf] is <commit> non-destructive on <candidate> as well as <running>?

From: Andy Bierman <[email-masked]>
Date: Fri, 24 Jul 2009 18:29:14 -0700

Hi,

If the <commit> operation fails, then the <running> config
is supposed to be left as-it-was, but what about the <candidate>?

One example: pruning empty NP containers.
Or the <candidate> might change by implementation choice,
if it is unspecified in the standard.

So is it specified, and I just missed it (again)?

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 24 Jul 2009 22:51:48 -0400

>is supposed to be left as-it-was, but what about the <candidate>?

Candidate is untouched.

>One example: pruning empty NP containers.

These can be pruned at any time.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Sat, 25 Jul 2009 07:18:20 -0700

>> is supposed to be left as-it-was, but what about the <candidate>?

where does it say this in the draft?
I don't think it does.

> These can be pruned at any time.

not in the <candidate>.

what if the operator for some dumb reason
decides to create an NP container, and then
fill it with leafs one at a time:

 <edit-config>
    ...
    <default-operation>none</default-operation>
    <config>
       <np-container>
          <new-leaf nc:operation="create">7</new-leaf>
       </np-container>
    </config>
  </edit-config>

This needs to work, even if it is not the best way to use <edit-config>.
That's why I wait until the <commit> to delete empty NP containers.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Sat, 25 Jul 2009 12:26:32 -0400

>where does it say this in the draft?

No, but it doesn't say that commit changes startup.  Or that
discard-changes can format your disk.  It just says what the
operation does.

>not in the <candidate>.

Sure you can:

  A NETCONF server that replies to a <get> or <get-config> request MAY
  choose not to send a container element if the container node does not
  have the "presence" statement and no child nodes exist.  Thus, a
  client that receives an <rpc-reply> for a <get> or <get-config>
  request, must be prepared to handle the case that a container node
  without a presence statement is not present in the XML.

>That's why I wait until the <commit> to delete empty NP containers.

This is an implementation detail.

Thanks,
 Phil