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

[Ariel Otilibili Anieli <[e-mail]>]

Hi Attila,

Below my comments.

Regards,
Ariel

Quoting 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.
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.
> 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>
'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.
>>
>>> 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
>>
>>
>



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