Subject: Re: [Netconf] Clarification request for NETCONF edit-config default-operation replace

From: "Sterne, Jason (Nokia - CA)" <[email-masked]>
Date: Fri, 3 Jun 2016 00:48:15 +0000

Hi Mahesh,

In a system with the writable-running capability you can <edit-config> directly to the running datastore.  SR OS has that capability (and I think that is basically how Cisco IOS, non-XR, works in their CLI).

Regards,
Jason 

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Mahesh Jethanandani
Sent: Tuesday, May 31, 2016 11:10
To: Sterne, Jason (Nokia - CA)
Cc: [email-masked]
Subject: Re: [Netconf] Clarification request for NETCONF edit-config default-operation replace

> On May 31, 2016, at 6:36 AM, Sterne, Jason (Nokia - CA) <[email-masked]> wrote:
> 
> Thx Martin.  Your explanation that a default replace operation can only apply to elements that are in the request helps a lot.
> 
> So there really is no such thing as an edit-config 'replace' operation that operates "at the root". That can only be done with a special dedicated RPC (e.g. copy-config as you show in Case 5).
> 
> So my case 4 is equivalent to this:
> 
>>     <system operation='replace'>
>>       <password-control operation='replace'>             
>>         <min-length operation='replace'>10</min-length>  
>>       </password-control>  
>>     </system>
> 
> which will replace the entire contents of the /system subtree (but not anything else).
> 
> On a related note -> is the final result (i.e. datastore contents) of a replace operation always exactly the same as a remove + merge with the same data at the same location ?  I can't think of an example where that isn't true but I may be missing some corner case.  
> 
> For the candidate datastore it seems that 'replace' is simply a shorthand way to do remove+merge in a single edit-config.  For a running datastore (writeable-running) the impacts would be quite different though since the edit-config 'remove' would be applied immediately which would clear out all config for a short period before the 'merge' then gets processed.

You would normally edit the candidate configuration, and once validated commit it to running. You would normally not <edit-config> the running data store directly.

Mahesh Jethanandani
[email-masked]

> 
> Regards,
> Jason
> 
> -----Original Message-----
> From: Martin Bjorklund [mailto:[email-masked]]
> Sent: Tuesday, May 31, 2016 4:50
> To: Sterne, Jason (Nokia - CA)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Netconf] Clarification request for NETCONF edit-config 
> default-operation replace
> 
> "Sterne, Jason (Nokia - CA)" <[email-masked]> wrote:
>> Hi guys,
>> 
>> I think there is some conflicting information wrt default-operation 
>> replace here.
> 
> I agree it is not clear.
> 
>> The following snippet of RFC 6241 clearly states (IMO) that the 
>> entire config is affected/replaced.  The first sentence says it.
> 
> I don't think this statement clearly says that the entire datastore is replaced.  It uses the term "completely replace".  I don't know how that is different from "replace".  IMO, "replace" implies "completely"...
> 
>> Then the second sentence gives yet another indication that it 
>> replaces the entire config:
> 
> Not necessarily.
> 
>>>        replace:  The configuration data in the <config> parameter
>>>           completely replaces the configuration in the target
>>>           datastore.  This is useful for loading previously saved
>>>           configuration data.
>> 
>> 
>> I also found an older discussion on this on the mailing list that 
>> indicates that a default action of replace is intended to be used for 
>> the entire datastore.  From
>> https://mailarchive.ietf.org/arch/msg/netconf/s4KOJxIgbDzqAXS-uF_jFi-iQsU:
>> 
>> 
>>> 1)
>>>   $backup = get-config(source=running)
>>> 2)
>>>   copy-config(source=$backup, target=running)  OR
>>>   edit-config(source=$backup, target=running,
>>>   default-operation=replace)"
>> 
>> 
>> <edit-config> operations are inherited. The default-operation applies 
>> to all top level objects.  But I'm not certain whether it applies to 
>> all top level objects in the data model on the server or just all the 
>> top level objects that are included in the <edit-config> request.
> 
> The latter.  It is just a default value for the "operation" attribute; i.e., instead of using "default-operation", you could explicitly set the "operation" attribute - and you can only do that for the elements in the request (obvioulsy).
> 
>> From the descriptions above it seems it must apply to all top level 
>> objects in the server but that seems to conflict with:
>> 
>>> "only the configuration actually present in the <config> parameter 
>>> is  affected"
>> 
>> Here is a set of examples that may help clarify things. The first 3 
>> cases are an incremental lead-in to case 4 which is the least clear 
>> for me.
>> 
>> ## Initial server Config A (used in all the cases below):
>>  <system>
>>    <password-control>
>>      <min-length>12</min-length>
>>      <require-caps>true<require-caps>
>>    </password-control>
>>    <console>
>>      <width>132</width>
>>      <enabled>true</enabled>
>>    </console>
>>  </system>
>>  <qos>
>>    <ingress>
>>      <class-limit>8</class-limit>
>>      <sub-classes>true</sub-classes>
>>    </ingress>
>>  </qos>
>> 
>> ## Case 1:
>> - Initial Config A
>> - edit-config request (no default operation):
>>     <system>
>>       <password-control>
>>         <min-length operation='replace'>10</min-length>
>>       </password-control>
>>     </system>
>> - Resulting config on the server (only 'min-length' affected):
>>     <system>
>>       <password-control>
>>         <min-length>10</min-length>
>>         <require-caps>true<require-caps>
>>       </password-control>
>>       <console>
>>         <width>132</width>
>>         <enabled>true</enabled>
>>       </console>
>>     </system>
>>     <qos>
>>       <ingress>
>>         <class-limit>8</class-limit>
>>         <sub-classes>true</sub-classes>
>>       </ingress>
>>     </qos>
>> 
>> ## Case 2:
>> - Initial Config A
>> - edit-config request (no default operation):
>>     <system>
>>       <password-control operation='replace'>
>>         <min-length>10</min-length>   // inherited replace
>>       </password-control>
>>     </system>
>> - Resulting config on the server (all 'password-control' affected):
>>     <system>
>>       <password-control>
>>         <min-length>10</min-length>
>>       </password-control>
>>       <console>
>>         <width>132</width>
>>         <enabled>true</enabled>
>>       </console>
>>     </system>
>>     <qos>
>>       <ingress>
>>         <class-limit>8</class-limit>
>>         <sub-classes>true</sub-classes>
>>       </ingress>
>>     </qos>
>> 
>> ## Case 3:
>> - Initial Config A
>> - edit-config request (no default operation):
>>     <system operation='replace'>
>>       <password-control>             // inherited replace
>>         <min-length>10</min-length>  // inherited replace
>>       </password-control>
>>     </system>
>> - Resulting config on the server (all 'system' affected) :
>>     <system>
>>       <password-control>
>>         <min-length>10</min-length>
>>       </password-control>
>>     </system>
>>     <qos>
>>       <ingress>
>>         <class-limit>8</class-limit>
>>         <sub-classes>true</sub-classes>
>>       </ingress>
>>     </qos>
>> 
>> ## Case 4:
>> - Initial Config A
>> - edit-config request (!! with default-operation replace !!):
>>     <system>
>>       <password-control>             
>>         <min-length>10</min-length>  
>>       </password-control>  
>>     </system>
>> - Resulting config on the server (entire server datastore affected ?):
>>     <system>
>>       <password-control>
>>         <min-length>10</min-length>
>>       </password-control>
>>     </system>
>>    // no qos data ?
> 
> This is not correct; qos is unaffected.
> 
> ## Case 5:
> - Initial Config A
> - copy-config request
>    <system>
>       <password-control>             
>         <min-length>10</min-length>  
>      </password-control>  
>     </system>
> - Resulting config on the server (entire server datastore affected !):
>     <system>
>       <password-control>
>        <min-length>10</min-length>
>      </password-control>
>     </system>
>    // no qos data !
> 
> 
> 
> /martin
> 
> 
> 
>> 
>> Regards,
>> Jason
>> 
>> -----Original Message-----
>> From: EXT Xiang Li [mailto:[email-masked]]
>> Sent: Tuesday, May 03, 2016 11:21
>> To: Sterne, Jason (Nokia - CA); 'Martin Bjorklund'; 
>> [email-masked]
>> Cc: [email-masked]
>> Subject: RE: [Netconf] Clarification request for NETCONF edit-config 
>> default-operation replace
>> 
>> Hi
>> 
>>> -----Original Message-----
>>> ... 
>>> In my first question I meant "using an <edit-config>":
>>> 
>>> Is there no way to delete (or replace) the entire contents of the
>> datastore
>>> using an <edit-config> (and without using <copy-config> without 
>>> having to explicitly list every single top level node ?
>> 
>> I don't think edit-config is designed to do that.
>> 
>> To delete a datastore, use <delete-config>, although <running> can't 
>> be deleted.
>> To replace the *entire config*, use <copy-config>. 
>> 
>>> From the description of the default-operation 'replace' it seems it 
>>> is
>> possible
>>> via the default operation:
>>>         replace:  The configuration data in the <config> parameter
>>>            completely replaces the configuration in the target
>>>            datastore.  This is useful for loading previously saved
>>>            configuration data.
>> 
>> 
>> No. The definition of "replace" as an operation says clearly:
>> 
>>            Unlike a  <copy-config> operation, which replaces the entire target
>>            configuration, only the configuration actually present in
>>            the <config> parameter is affected.
>> 
>> In other words, the <replace> only replaces the data nodes that exist 
>> in the target and for nodes that are in <config> in the 
>> <edit-config>but not in the target, they are created. Other nodes 
>> that exist in the device but are not present in the <config> of the 
>> <edit-config> are NOT affected in any way (this is the key difference 
>> with <copy-config>, where they are removed because it operates on the
>> *entire* datastore.)
>> 
>>> But can replace of the entire contents be done without replace as 
>>> the
>> default
>>> operation ?
>> 
>> Not with the default "replace" operation, nor with the normal 
>> "replace"
>> operation.
>> The default "replace" operation has no additional semantics compared 
>> to The "operation" parameter
>> 
>>> Or delete of the entire contents ?  The RFC doesn't seem to clear on 
>>> whether we can use an operation on the <config> node:
>>> <config operation="delete"/>
>>> <config operation="replace"/>
>> 
>> 
>> The description of <edit-config> says: the target configuration is 
>> not necessarily replaced, as with the <copy-config> message.  
>> Instead, the target configuration is changed in accordance with the 
>> source's data and requested operations.
>> 
>> In other words, the <config> parameter in <edit-config> will not be 
>> valid if you do not specify it (assuming no url capability) or make 
>> it empty, as in your example.
>> 
>> config:  A hierarchy of configuration data as defined by one of
>>         the device's data models.  The contents MUST be placed in an
>>         appropriate namespace, to allow the device to detect the
>>         appropriate data model, and the contents MUST follow the
>>         constraints of that data model, as defined by its capability
>>         definition.
>> 
>> 
>>> (c) and (d) have a delete operation on a leaf (in (c) is it
>>> inherited) but
>> are
>>> providing a value for the leaf at the same time. What is the meaning 
>>> of
>> the
>>> value ? That seems like an error to me.  We should warn the client 
>>> that they've done something unexpected (the client may have been 
>>> intending to do something different than deleting that leaf).
>>> I can see how that works when the leaf is a key leaf in a list.  But 
>>> it
>> seems like
>>> an error for just a plain leaf.
>> 
>> 
>> No. I think the value is actually used by <edit-config>. For example,
>> RFC6241
>> has this example:
>> 
>> Delete the configuration for an interface named "Ethernet0/0" from
>>   the running configuration:
>> 
>>     <rpc message-id="101"
>>          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>>       <edit-config>
>>         <target>
>>           <running/>
>>         </target>
>>         <default-operation>none</default-operation>
>>         <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0">
>>           <top xmlns="http://example.com/schema/1.2/config">
>>             <interface xc:operation="delete">
>>               <name>Ethernet0/0</name>
>>             </interface>
>>           </top>
>>         </config>
>>       </edit-config>
>>     </rpc>
>> 
>> 
>> Without specifying value so that the device can find an exact matched 
>> interface, this won't work.
>> 
>> In other words, my understanding is that if a value is given, and the 
>> device
>> 
>> can't find a match then then the delete will fail with a 
>> <data-missing> error.
>> 
>>> I'm also not convinced about (f) and (g).  Wrt your analogy of a 
>>> directory
>> with
>>> files: you can delete a container in NETCONF and that automatically
>> deletes
>>> any children, grandchildren and so on (the entire subtree).  It 
>>> seems
>> strange
>>> that there is no way to delete (or replace) the entire contents of a 
>>> list
>> or leaf-
>>> list.
>> 
>> I don't necessarily disagree with you on this one.
>> 
>> I was simply suggesting that the protocol perhaps should have a 
>> simple way to allow me to remove list entries. In particular I think 
>> it would be useful it allows:
>> 1) to delete a specific list entry by providing a list entry's 
>> Instance ID ( all key nodes and corresponding values).
>> 2) to delete all entries of a list by just providing all key nodes in 
>> the <config>.
>> 
>> Best,
>> --Xiang
>> 
>> 
>> 
>>> Or perhaps I'm misinterpreting the description of the replace and 
>>> delete operations in RFC6241 (the sentences "only the configuration 
>>> actually present in the <config> parameter is affected" and "if and 
>>> only if the configuration data currently exists" are giving me some 
>>> pause here).
>> There
>>> aren't many examples illustrating delete & replace in the RFC.
>>> 
>>> Regards,
>>> Jason
>>> 
>>> -----Original Message-----
>>> From: EXT Xiang Li [mailto:[email-masked]]
>>> Sent: Friday, April 29, 2016 20:05
>>> To: Sterne, Jason (Nokia - CA); 'Martin Bjorklund'; 
>>> [email-masked]
>>> Cc: [email-masked]
>>> Subject: RE: [Netconf] Clarification request for NETCONF edit-config
>> default-
>>> operation replace
>>> 
>>> 
>>> 
>>> -----Original Message-----
>>> From: Netconf [mailto:[email-masked]] On Behalf Of Sterne, 
>>> Jason (Nokia - CA)
>>> Sent: Friday, April 29, 2016 2:12 PM
>>> To: Martin Bjorklund <[email-masked]>; [email-masked]
>>> Cc: [email-masked]
>>> Subject: Re: [Netconf] Clarification request for NETCONF edit-config
>> default-
>>> operation replace
>>> 
>>> Is there no way to delete the entire contents of the datastore 
>>> without
>> having
>>> to explicitly list every single top level node ?
>>> 
>>> e.g.
>>> with no default operation (i.e. merge):
>>> <config operation="delete"/>
>>> 
>>> Or
>>> With default operation = delete:
>>> <config/>
>>> 
>>> Similarly -> Is there no way to replace the entire contents of the
>> datastore ?
>>> 
>>> [XL] I think< copy-config> or <delete-config> can do this.
>>> 
>>> About the cases below shouldn't (c) and (d) return an error ?  They
>> contain
>>> data for an object that is being deleted.  (e) seems like the 
>>> correct way
>> to do
>>> it.
>>> 
>>> [XL] I think Martin's explanation is correct. My understanding is 
>>> that if
>> the
>>> value does not match, then the <delete> would return an error since 
>>> the no matching data node found (yes I view this as a content-match).
>>> Or I might
>> be
>>> totally wrong here, i.e., the value does not matter in any way as 
>>> Martin
>> said?
>>> 
>>> (f) and (g) surprise me.  If I can <get-config> an entire leaf-list 
>>> or
>> list by just
>>> specifying the tag for the leaf-list/list name, why doesn't delete 
>>> get rid
>> of the
>>> entire leaf-list/list ?
>>> (if you specify a specific list entry/member in a delete it is 
>>> basically
>> just a
>>> content match node but otherwise you've selected the entire list no 
>>> ?).
>>> 
>>> [XL] I also thought that I can delete a list entry by specifying all 
>>> key
>> nodes
>>> and their values (i.e., list entry's instance ID). If no values of 
>>> key
>> nodes are
>>> given, then the entire list entries matched and all of them should 
>>> be
>> deleted.
>>> Although Martin's explanation also makes sense here, that is, you 
>>> can't
>> just
>>> delete a key node yet if it is still used by non-key nodes.
>>> Just like deleting a directory when the directory still contains 
>>> files.
>> But, in any
>>> case,  I would still like that I can delete a list entry by giving 
>>> the
>> list entry's IID
>>> since we can unmistakably identify  a list entry by given a list 
>>> entry's
>> IID (i.e. ,
>>> all key nodes and their corresponding values).  I think such a 
>>> delete operation would be useful,  just like "rm -rf directory".
>>> 
>>> --Xiang
>>> -----Original Message-----
>>> From: Netconf [mailto:[email-masked]] On Behalf Of Martin 
>>> Bjorklund
>>> Sent: Friday, April 15, 2016 10:49
>>> To: [email-masked]
>>> Cc: [email-masked]
>>> Subject: Re: [Netconf] Clarification request for NETCONF edit-config
>> default-
>>> operation replace
>>> 
>>> William Ivory <[email-masked]> wrote:
>>>> OK - I think it might help if I gave some specific examples, with 
>>>> my understanding of what would get deleted and you can tell me if 
>>>> I'm correct or not.  Apologies for length, but I'd like to avoid 
>>>> any confusion by not spelling out my queries, and I'm struggling to 
>>>> get a clear picture of how this all works with all the different 
>>>> permutations!
>>>> 
>>>> Let's take a configuration like this:
>>>> 
>>>> <topCont>
>>>>    <aLeaf>leafValue</aLeaf>
>>>>    <aLeafListEntry>leaflistValueOne</aLeafListEntry>
>>>>    <aLeafListEntry>leaflistValueTwo</aLeafListEntry>
>>>>    <aListEntry>
>>>>        <listKey>firstEntryKey</listKey>
>>>>        <listLeaf>firstEntryLeaf</listLeaf>
>>>>    </aListEntry>
>>>>    <aListEntry>
>>>>        <listKey>secondEntryKey</listKey>
>>>>        <listLeaf>secondEntryLeaf</listLeaf>
>>>>    </aListEntry>
>>>> </topCont>
>>>> 
>>>> ---
>>>> 
>>>> (a) topCont, default operation delete
>>>> 
>>>> With the default operation set to delete:
>>>> 
>>>> <config>
>>>>    <topCont>
>>>> </config>
>>>> 
>>>> => topCont, and everything under it, would be deleted
>>> 
>>> Yes.
>>> 
>>>> (b) topCont, operation delete
>>>> 
>>>> With the default operation set to none:
>>>> 
>>>> <config>
>>>>    <topCont xc:operation=delete>
>>>> </config>
>>>> 
>>>> => topCont, and everything under it, would be deleted
>>> 
>>> Yes.
>>> 
>>>> ---
>>>> 
>>>> (c) aLeaf delete, operation specified for topCont
>>>> 
>>>> With the default operation set to none:
>>>> 
>>>> <config>
>>>>    <topCont xc:operation=delete>
>>>>        <aLeaf>leafValue</aLeaf>
>>>> </config>
>>>> 
>>>> => Will delete aLeaf node.  If this leaves topCont empty, then 
>>>> topCont would be removed.  If topCont still contains other 
>>>> elements, topCont would remain?
>>> 
>>> No.  This deletes the topCont and everything below it.
>>> 
>>>> ---
>>>> 
>>>> (d) aLeaf delete, operation specified for aLeaf
>>>> 
>>>> With the default operation set to none:
>>>> 
>>>> <config>
>>>>    <topCont>
>>>>        <aLeaf xc:operation=delete>leafValue</aLeaf>
>>>> </config>
>>>> 
>>>> => Will delete aLeaf node.  If this leaves topCont empty, then 
>>>> topCont would be removed unless it is a presence node.
>>> 
>>> Yes  (s/would/may/)
>>> 
>>>> ---
>>>> 
>>>> (e) aLeaf delete, operation specified for aLeaf, but no value given
>>>> 
>>>> With the default operation set to none:
>>>> 
>>>> <config>
>>>>    <topCont>
>>>>        <aLeaf xc:operation=delete/> </config>
>>>> 
>>>> => Would this delete aLeaf, and, as per (d), conditionally 
>>>> <topCont>, or must the value of the leaf be specified?
>>> 
>>> Yes, this would delete aLeaf.  The value doesn't matter.
>>> 
>>>> ---
>>>> 
>>>> (f) aLeafListEntry
>>>> 
>>>> Is there a way to delete all leaflist entries without specifying 
>>>> them individually, eg:
>>>> 
>>>> <aLeafListEntry xc:operation=delete>
>>> 
>>> No
>>> 
>>> 
>>>> 
>>>> ... or, assuming there are other sibling nodes such that we can't 
>>>> just delete topCont, must I specify each individual leaflist 
>>>> element I wish to remove?
>>>> 
>>>> ---
>>>> 
>>>> (g) aListEntry
>>>> 
>>>> As per leaflist entries, is there a way to delete all entries 
>>>> generically
>>> 
>>> No.
>>> 
>>>> , or must each be specified?
>>> 
>>> Yes.
>>> 
>>>> Separately, if I delete a non-key node inside a list entry, I 
>>>> assume that just deletes that node.  If I delete the list's key 
>>>> node, then presumably that removes the complete entry, eg:
>>>> 
>>>> <config>
>>>>    <topCont>
>>>>        <aListEntry xc:operation=delete>
>>>>            <listKey>firstEntryKey</listKey>
>>>>        </aListEntry>
>>>> </config>
>>> 
>>> Yes
>>> 
>>>> Would the following achieve the same, ie removal of this list entry:
>>>> 
>>>> <config>
>>>>    <topCont>
>>>>        <aListEntry >
>>>>            <listKey xc:operation=delete >firstEntryKey</listKey>
>>>>        </aListEntry>
>>>> </config>
>>> 
>>> Hmm.  I would say that this results in an error - deleting just the 
>>> key of
>> a list is
>>> not possible.
>>> 
>>> 
>>> 
>>> /martin
>>> 
>>> 
>>> 
>>>> 
>>>> ---
>>>> 
>>>> Thanks  for bearing with me,
>>>> 
>>>> William
>>>> 
>>>> -----Original Message-----
>>>> From: Martin Bjorklund [mailto:[email-masked]]
>>>> Sent: 15 April 2016 13:44
>>>> To: William Ivory <[email-masked]>
>>>> Cc: [email-masked]
>>>> Subject: Re: [Netconf] Clarification request for NETCONF 
>>>> edit-config default-operation replace
>>>> 
>>>> William Ivory <[email-masked]> wrote:
>>>>> Hi Martin,
>>>>> 
>>>>> Thanks - I think that the section on 'replace' under 
>>>>> 'default-operation' could do with being clarified next time the 
>>>>> RFC is updated then.
>>>>> 
>>>>> I'd appreciate some further clarification on what exactly ' only 
>>>>> the configuration actually present in the <config> parameter is 
>>>>> affected'
>>>>> means in practice.
>>>>> 
>>>>> First, the general pattern of examples which use 
>>>>> 'operation=<operation>' is that this command is put in the 'parent'
>>>>> element's tag, ie the tag which specifies 'delete' is *not* deleted.
>>>> 
>>>> No.  For example:
>>>> 
>>>>    <interface xc:operation="delete">
>>>>      <name>192.0.2.4</name>
>>>>    </interface>
>>>> 
>>>> will delete the "interface" node with the name "192.0.2.4"
>>>> 
>>>> It does NOT keep the "interface" node and just delete the "name" node.
>>>> 
>>>>> How then would you delete a top-level container?
>>>> 
>>>> <my-top-level-container nc:operation="delete"/>
>>>> 
>>>> 
>>>> 
>>>> /martin
>>>> 
>>>> 
>>>>> The examples have a
>>>>> '<top>' element but in cases where there are multiple top-level 
>>>>> nodes, some of which are optional in the configuration (ie not 
>>>>> presence containers), is it possible to delete these nodes?
>>>>> 
>>>>> Secondly, if I'm correct that the 'delete' operation would only 
>>>>> affect nodes below the one with the delete operation, is it 
>>>>> possible to construct an edit-config PDU that would delete all 
>>>>> child nodes without having to explicitly specify each one?  Or is 
>>>>> the only way to achieve this either to explicitly specify all 
>>>>> config to be removed, or to do a copy-config explicitly specifying 
>>>>> all config that is not to be deleted.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> William
>>>>> 
>>>>> -----Original Message-----
>>>>> From: Martin Bjorklund [mailto:[email-masked]]
>>>>> Sent: 14 April 2016 09:34
>>>>> To: William Ivory <[email-masked]>
>>>>> Cc: [email-masked]
>>>>> Subject: Re: [Netconf] Clarification request for NETCONF 
>>>>> edit-config default-operation replace
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> William Ivory <[email-masked]> wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> I'd appreciate clarification of how the NETCONF edit-config 
>>>>>> command should work with default-operation set to 'replace'.
>>>>>> For the most part, the edit-config section is clear that config 
>>>>>> will only be replaced if explicitly overwritten (ie if you 
>>>>>> provide replacement config for given nodes).  However, the 
>>>>>> section on default-operation is less clear:
>>>>>> 
>>>>>>         The <default-operation> parameter is optional, but if
>>> provided,
>>>>>>         it has one of the following values:
>>>>>> 
>>>>>>         merge:  The configuration data in the <config> parameter is
>>>>>>            merged with the configuration at the corresponding 
>>>>>> level
>>> in
>>>>>>            the target datastore.  This is the default behavior.
>>>>>> 
>>>>>>         replace:  The configuration data in the <config> parameter
>>>>>>            completely replaces the configuration in the target
>>>>>>            datastore.  This is useful for loading previously saved
>>>>>>            configuration data.
>>>>>> 
>>>>>> Specifically, while 'merge' states that merge happesn with 
>>>>>> 'configuration as the corresponding level', 'replace' states that 
>>>>>> is 'completely replaces' the configuration, suggesting that it 
>>>>>> will remove ALL existing configuration regardless of what is 
>>>>>> explicitly provided as the replacement.  Is that correct, or is 
>>>>>> 'replace' meant to have equivalent semantics to 'merge' ie it 
>>>>>> will only replace configuration when an explicit replacement is 
>>>>>> provided.  In other words, if the latter case is correct, all it 
>>>>>> does is remove the requirement to specify the operation in each
>>> element of new config.
>>>>> 
>>>>> Yes the latter is correct.  Note that the definition of "replace" 
>>>>> as an operation says:
>>>>> 
>>>>>            Unlike a
>>>>>            <copy-config> operation, which replaces the entire target
>>>>>            configuration, only the configuration actually present in
>>>>>            the <config> parameter is affected.
>>>>> 
>>>>> 
>>>>> /martin
>>> 
>>> _______________________________________________
>>> Netconf mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/netconf
>>> 
>>> _______________________________________________
>>> Netconf mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/netconf
> 
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: "Sterne, Jason (Nokia - CA)" <[email-masked]>
Date: Fri, 3 Jun 2016 00:49:58 +0000

Thx.  In case I accidently gave the wrong impression -> I wasn’t advocating to change <edit-config>.  Just trying to clarify the intended/expected behavior.

I wasn’t even considering NACM during this whole discussion.  I would assume NACM would affect the behavior of <edit-config> replace or delete (i.e. nodes that the client can’t access are not deleted, can easily result in invalid candidate configs) , but that permission should be controlled for the <copy-config> at the RPC level (i.e. all or nothing authorization for a client/user to use the copy-config RPC).

Jason

From: Andy Bierman [mailto:[email-masked]]
Sent: Tuesday, May 31, 2016 20:50
To: Sterne, Jason (Nokia - CA)
Cc: Martin Bjorklund; [email-masked]
Subject: Re: [Netconf] Clarification request for NETCONF edit-config default-operation replace

Hi,

I don't think <edit-config> needs to be changed to provide the
same replace semantics as <copy-config>.  copy-config is
for complete configurations.

There is an unwritten assumption that the copy-config contents are
not pruned at all by access control. A missing node will be interpreted as a delete attempt.
This is not at all desirable if the client is not authorized and is not even aware
of these "hidden" nodes.

Andy

On Tue, May 31, 2016 at 6:36 AM, Sterne, Jason (Nokia - CA) <[email-masked]<mailto:[email-masked]>> wrote:
Thx Martin.  Your explanation that a default replace operation can only apply to elements that are in the request helps a lot.

Regards,
Jason

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, May 31, 2016 4:50
To: Sterne, Jason (Nokia - CA)
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netconf] Clarification request for NETCONF edit-config default-operation replace

I agree it is not clear.

> The following snippet of RFC 6241 clearly states (IMO) that the entire
> config is affected/replaced.  The first sentence says it.

> Then the second sentence gives yet another indication that it replaces
> the entire config:

Not necessarily.

## Case 5:
- Initial Config A
- copy-config request
    <system>
       <password-control>

/martin

> From: EXT Xiang Li [mailto:[email-masked]<mailto:[email-masked]>]
> To: Sterne, Jason (Nokia - CA); 'Martin Bjorklund'; [email-masked]<mailto:[email-masked]>
> Cc: [email-masked]<mailto:[email-masked]>
> <edit-config>but not in the target, they are created. Other nodes that
> exist in the device but are not present in the <config> of the
> The description of <edit-config> says: the target configuration is not
> necessarily replaced, as with the <copy-config> message.  Instead, the
> target configuration is changed in accordance with the source's data
> and requested operations.
>
> valid if you do not specify it (assuming no url capability) or make it
> empty, as in your example.
>
> I was simply suggesting that the protocol perhaps should have a simple
> way to allow me to remove list entries. In particular I think it would
> be useful it allows:
> > From: EXT Xiang Li [mailto:[email-masked]<mailto:[email-masked]>]
> > [email-masked]<mailto:[email-masked]>
> > Cc: [email-masked]<mailto:[email-masked]>
> > From: Netconf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Sterne,
> > Jason (Nokia - CA)
> > To: Martin Bjorklund <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> > Cc: [email-masked]<mailto:[email-masked]>
> > [XL] I also thought that I can delete a list entry by specifying
> > all key
> nodes
> > From: Netconf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Martin
> > Bjorklund
> > To: [email-masked]<mailto:[email-masked]>
> > Cc: [email-masked]<mailto:[email-masked]>
> > William Ivory <[email-masked]<mailto:[email-masked]>> wrote:
> > > any confusion by not spelling out my queries, and I'm struggling
> > > to get a clear picture of how this all works with all the
> > > different permutations!
> > >
> > > From: Martin Bjorklund [mailto:[email-masked]<mailto:[email-masked]>]
> > > To: William Ivory <[email-masked]<mailto:[email-masked]>>
> > > Cc: [email-masked]<mailto:[email-masked]>
> > > William Ivory <[email-masked]<mailto:[email-masked]>> wrote:
> > > > Hi Martin,
> > > >
> > > > child nodes without having to explicitly specify each one?  Or
> > > > is the only way to achieve this either to explicitly specify all
> > > > config to be removed, or to do a copy-config explicitly
> > > > specifying all config that is not to be deleted.
> > > >
> > > > Thanks,
> > > >
> > > > William
> > > >
> > > > From: Martin Bjorklund [mailto:[email-masked]<mailto:[email-masked]>]
> > > > To: William Ivory <[email-masked]<mailto:[email-masked]>>
> > > > Cc: [email-masked]<mailto:[email-masked]>
> > > > William Ivory <[email-masked]<mailto:[email-masked]>> wrote:
> > > > > Hi,
> > > > >
> > > > > For the most part, the edit-config section is clear that
> > > > > config will only be replaced if explicitly overwritten (ie if
> > > > > you provide replacement config for given nodes).  However, the
> > > > > 'configuration as the corresponding level', 'replace' states
> > > > > that is 'completely replaces' the configuration, suggesting
> > > > > that it will remove ALL existing configuration regardless of
> > > > > what is explicitly provided as the replacement.  Is that
> > > > > correct, or is 'replace' meant to have equivalent semantics to
> > > > > 'merge' ie it will only replace configuration when an explicit
> > > > > replacement is provided.  In other words, if the latter case
> > > > > is correct, all it does is remove the requirement to specify
> > > > > the operation in each
> > element of new config.
> > > >
> > [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Thu, 2 Jun 2016 18:00:04 -0700

Hi,

NACM is not defined to be all-or-nothing for GET.

The round-trip described in RFC 3535 only works if the GET is complete

  config = get-config source=running

[edit config offline]

   copy-config source=config target=candidate

Any nodes missing from the get-config because the user is unauthorized
will look like delete attempts in the copy-config.  The nodes can be
anywhere,
not just top-level.

Andy

On Thu, Jun 2, 2016 at 5:49 PM, Sterne, Jason (Nokia - CA) <
[email-masked]> wrote:

> Thx.  In case I accidently gave the wrong impression -> I wasn’t
> advocating to change <edit-config>.  Just trying to clarify the
> intended/expected behavior.
>
>
>
> I wasn’t even considering NACM during this whole discussion.  I would
> assume NACM would affect the behavior of <edit-config> replace or delete
> (i.e. nodes that the client can’t access are not deleted, can easily result
> in invalid candidate configs) , but that permission should be controlled
> for the <copy-config> at the RPC level (i.e. all or nothing authorization
> for a client/user to use the copy-config RPC).
>
>
>
> Jason
>
>
>
> *From:* Andy Bierman [mailto:[email-masked]]
> *Sent:* Tuesday, May 31, 2016 20:50
> *To:* Sterne, Jason (Nokia - CA)
> *Cc:* Martin Bjorklund; [email-masked]
> *Subject:* Re: [Netconf] Clarification request for NETCONF edit-config
> On Tue, May 31, 2016 at 6:36 AM, Sterne, Jason (Nokia - CA) <
> [email-masked]> wrote:
>
> Thx Martin.  Your explanation that a default replace operation can only
> apply to elements that are in the request helps a lot.
>
> So there really is no such thing as an edit-config 'replace' operation
> that operates "at the root". That can only be done with a special dedicated
> RPC (e.g. copy-config as you show in Case 5).
>
> On a related note -> is the final result (i.e. datastore contents) of a
> replace operation always exactly the same as a remove + merge with the same
> data at the same location ?  I can't think of an example where that isn't
> true but I may be missing some corner case.
>
> For the candidate datastore it seems that 'replace' is simply a shorthand
> way to do remove+merge in a single edit-config.  For a running datastore
> (writeable-running) the impacts would be quite different though since the
> edit-config 'remove' would be applied immediately which would clear out all
> config for a short period before the 'merge' then gets processed.
>
> Regards,
> Jason
>
> I don't think this statement clearly says that the entire datastore is
> replaced.  It uses the term "completely replace".  I don't know how that is
> different from "replace".  IMO, "replace" implies "completely"...
>
> The latter.  It is just a default value for the "operation" attribute;
> i.e., instead of using "default-operation", you could explicitly set the
> "operation" attribute - and you can only do that for the elements in the
> request (obvioulsy).
>
> > To: Sterne, Jason (Nokia - CA); 'Martin Bjorklund'; [email-masked]
> > Cc: [email-masked]