Subject: [Netconf] Does <discard-changes> do the same thing as <copy-config>-ing 'running' to 'candidate'?

From: Attila Vangel <[email-masked]>
Date: Fri, 25 May 2018 11:19:21 +0200

Hi,

N00b question on netconf. Could somebody please clarify?

1. Does <discard-changes> (
https://tools.ietf.org/html/rfc6241#section-8.3.4.2) have totally the same
effect as <copy-config>-ing 'running' to 'candidate'?

"This operation discards any uncommitted changes by resetting the
   candidate configuration with the content of the running
   configuration."

If so, was it introduced as a shorter alternative of copying?
If not, what is the difference between them?

2. I got confused because I watched a tutorial on youtube which used both
commands, first <discard-changes> before locking any config datastores, and
<copy-config>-ing 'running' to 'candidate' after locking these datastores.
(The assumption in this example is that the device supports 'candidate'.)

3. For the first time I was puzzled why to do <discard-changes> before
doing any locking, but then I read in the RFC that lock would fail if
'candidate' was "dirty" (https://tools.ietf.org/html/rfc6241#section-7.5):

A lock MUST NOT be granted if any 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.

      <...>

But still I am not sure about 1. If these commands do the same thing, using
<copy-config> in this tutorial was just for showcasing doing it yet another
way in 2.?

(I was not sure whether to share the link for the tutorial, maybe it
would look like as advertising the company/author who did the
tutorial.)

Best regards,
Attila

---

From: Ariel Otilibili Anieli <[email-masked]>
Date: Fri, 25 May 2018 12:21:48 +0200

Hi Attila,

Comments below.

Regards,
Ariel

> effect as <copy-config>-ing 'running' to 'candidate'?
No.
> If not, what is the difference between them?
<copy-config> copies the content of a datastore to another, whatever  
it is; <discard-changes> discards the changes made on the 'candidate'  
datastore.
> (The assumption in this example is that the device supports 'candidate'.)
I suppose they wanted to edit 'candidate' from 'running', that's why  
they <copy-config> before edition.
>          modified, and these changes have not been committed or rolled
Another thing on <lock>
> would look like as advertising the company/author who did the

-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr

---

From: Attila Vangel <[email-masked]>
Date: Fri, 25 May 2018 14:01:31 +0200

Hi Ariel,

Thanks for the quick turnaround! See my comment below.

On Fri, May 25, 2018 at 12:21 PM, Ariel Otilibili Anieli <
[email-masked]> wrote:

> <copy-config> copies the content of a datastore to another, whatever it
> is; <discard-changes> discards the changes made on the 'candidate'
> datastore.
>

In this case the description for <discard-changes> is incorrect in RFC,
because it states: "resetting the
   candidate configuration with the content of the running
   configuration" (see above). So looks like this is a bug in the RFC.
Anyway, I get the point now.

Attila

> I suppose they wanted to edit 'candidate' from 'running', that's why they
> <copy-config> before edition.
>
>>

---

From: Ariel Otilibili Anieli <[email-masked]>
Date: Fri, 25 May 2018 15:27:00 +0200

Hi Attila,

Below my comments.

Regards,
Ariel

>    configuration" (see above). So looks like this is a bug in the RFC.
It depends on what 'candidate' contained before edition. Let's say  
'candidate' contains B; 'running' has A. When editing, I changed B in  
B'. At that moment, if I have sent no <commit>, and I  
<discard-changes>, then 'running' stays A, 'candidate'  becomes A  
(though it contained B'). This is how I understand Section 8.3.4.2 of  
RFC 6241.
>>>          modified, and these changes have not been committed or rolled
'candidate' behaves the same way with <lock> and <unlock> (See,  
https://tools.ietf.org/html/rfc6241#section-8.3.5.2): Supposing  
'candidate' contains B, that I have changed in B', at the release with  
<unlock>, 'candidate' reverts to B, if no <commit> I have made.

---

From: Robert Wilton <[email-masked]>
Date: Fri, 25 May 2018 14:49:47 +0100

Hi Attila,

On 25/05/2018 13:01, Attila Vangel wrote:
> On Fri, May 25, 2018 at 12:21 PM, Ariel Otilibili Anieli 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Attila,
>
>     Comments below.
>
>     Regards,
>     Ariel
>
>     Quoting Attila Vangel <[email-masked]
>     <mailto:[email-masked]>>:
>
>         Hi,
>
>         https://tools.ietf.org/html/rfc6241#section-8.3.4.2
>         <https://tools.ietf.org/html/rfc6241#section-8.3.4.2>) have
>         totally the same
In terms of the contents of the candidate datastore then I would say yes 
the operations are the same.

However, if the server is tracking config commits, then it could store 
different associated meta data for the two operations.

>     <copy-config> copies the content of a datastore to another,
>     whatever it is; <discard-changes> discards the changes made on the
>     'candidate' datastore.
>
>
> In this case the description for <discard-changes> is incorrect in 
> RFC, because it states: "resetting the
I don't think that RFC is wrong.

Is is just that <candidate> normally starts with a copy of <running>.
Then the client modifies the contents of <candidate>, and finally it 
gets committed to <running>, at which point both datastores then have 
the same contents again.

So the <discard-changes> is effectively removing any pending changes in 
candidate, which is equivalent to reverting the contents back to 
<running>, and would also be equivalent to doing <copy> from <running> 
to <candidate>, if that is supported by the server.

So I think <discard-changes> is really just syntactic sugar.

Thanks,
Rob

>     I suppose they wanted to edit 'candidate' from 'running', that's
>     why they <copy-config> before edition.
>
>
>         'candidate' was "dirty"
>         (https://tools.ietf.org/html/rfc6241#section-7.5
>         <https://tools.ietf.org/html/rfc6241#section-7.5>):
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Attila Vangel <[email-masked]>
Date: Mon, 28 May 2018 08:32:00 +0200

Hi Ariel, Robert,

Thank you very much for the clarifications!

Regards,
Attila

On Fri, May 25, 2018 at 3:49 PM, Robert Wilton <[email-masked]> wrote:

> Then the client modifies the contents of <candidate>, and finally it gets
> committed to <running>, at which point both datastores then have the same
> contents again.
>
> candidate, which is equivalent to reverting the contents back to <running>,
> and would also be equivalent to doing <copy> from <running> to <candidate>,
> if that is supported by the server.
>
> Netconf mailing [email-masked]://www.ietf.org/mailman/listinfo/netconf
>
>
>