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

[Attila Vangel <[e-mail]>]

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]> wrote:

> Hi Attila,
>
> Comments below.
>
> Regards,
> Ariel
>
> Quoting Attila Vangel <[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) have totally the
>> same
>> effect as <copy-config>-ing 'running' to 'candidate'?
>>
> 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.

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
>> ):
>>
>> 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
>
>