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

[Robert Wilton <[e-mail]>]

Hi Attila,

On 25/05/2018 13:01, Attila Vangel wrote:
> Hi Ariel,
>
> Thanks for the quick turnaround! See my comment below.
>
> On Fri, May 25, 2018 at 12:21 PM, Ariel Otilibili Anieli 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     Hi Attila,
>
>     Comments below.
>
>     Regards,
>     Ariel
>
>     Quoting Attila Vangel <[e-mail]
>     <mailto:[e-mail]>>:
>
>         Hi,
>
>         N00b question on netconf. Could somebody please clarify?
>
>         1. Does <discard-changes> (
>         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
>         effect as <copy-config>-ing 'running' to 'candidate'?
>
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.

>     No.
>
>
>         "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?
>
>     <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.
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


>
> Attila
>
>
>         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'.)
>
>     I suppose they wanted to edit 'candidate' from 'running', that's
>     why they <copy-config> before edition.
>
>
>         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
>         <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.
>
>               <...>
>
>     Another thing on <lock>
>
>         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
>
>
>
>
>     -------------------------------------------------------------------------------
>     This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>
>
>
>
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf