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

[Andy Bierman <[e-mail]>]

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) <
[e-mail]> 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.
>
> Regards,
> Jason
>
> -----Original Message-----
> From: Martin Bjorklund [mailto:[e-mail]]
> Sent: Tuesday, May 31, 2016 4:50
> To: Sterne, Jason (Nokia - CA)
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [Netconf] Clarification request for NETCONF edit-config
> default-operation replace
>
> "Sterne, Jason (Nokia - CA)" <[e-mail]> 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:[e-mail]]
> > Sent: Tuesday, May 03, 2016 11:21
> > To: Sterne, Jason (Nokia - CA); 'Martin Bjorklund'; [e-mail]
> > Cc: [e-mail]
> > 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:[e-mail]]
> > > Sent: Friday, April 29, 2016 20:05
> > > To: Sterne, Jason (Nokia - CA); 'Martin Bjorklund';
> > > [e-mail]
> > > Cc: [e-mail]
> > > Subject: RE: [Netconf] Clarification request for NETCONF edit-config
> > default-
> > > operation replace
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Netconf [mailto:[e-mail]] On Behalf Of Sterne,
> > > Jason (Nokia - CA)
> > > Sent: Friday, April 29, 2016 2:12 PM
> > > To: Martin Bjorklund <[e-mail]>; [e-mail]
> > > Cc: [e-mail]
> > > 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:[e-mail]] On Behalf Of Martin
> > > Bjorklund
> > > Sent: Friday, April 15, 2016 10:49
> > > To: [e-mail]
> > > Cc: [e-mail]
> > > Subject: Re: [Netconf] Clarification request for NETCONF edit-config
> > default-
> > > operation replace
> > >
> > > William Ivory <[e-mail]> 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:[e-mail]]
> > > > Sent: 15 April 2016 13:44
> > > > To: William Ivory <[e-mail]>
> > > > Cc: [e-mail]
> > > > Subject: Re: [Netconf] Clarification request for NETCONF
> > > > edit-config default-operation replace
> > > >
> > > > William Ivory <[e-mail]> 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:[e-mail]]
> > > > > Sent: 14 April 2016 09:34
> > > > > To: William Ivory <[e-mail]>
> > > > > Cc: [e-mail]
> > > > > Subject: Re: [Netconf] Clarification request for NETCONF
> > > > > edit-config default-operation replace
> > > > >
> > > > > Hi,
> > > > >
> > > > > William Ivory <[e-mail]> 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netconf
> > >
> > > _______________________________________________
> > > Netconf mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netconf
> >
> >
>
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>