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

From: "Sterne, Jason (Nokia - CA)" <[email-masked]>
Date: Tue, 3 May 2016 13:48:29 +0000

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 ?

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

But can replace of the entire contents be done without replace as the default operation ?  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"/>

(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.

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.

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

---

From: "Xiang Li" <[email-masked]>
Date: Tue, 3 May 2016 10:20:52 -0500

Hi

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

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:

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
> 
> Subject: RE: [Netconf] Clarification request for NETCONF edit-config
default-
> operation replace
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.
> 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
default-
> operation replace
> Hmm.  I would say that this results in an error - deleting just the key of
a list is
> not possible.

---

From: "Xiang Li" <[email-masked]>
Date: Tue, 3 May 2016 10:38:00 -0500

> From: Netconf [mailto:[email-masked]] On Behalf Of Xiang Li
> Sent: Tuesday, May 03, 2016 10:21 AM
> To: 'Sterne, Jason (Nokia - CA)' <[email-masked]>; 'Martin
> Bjorklund' <[email-masked]>; [email-masked]
> Cc: [email-masked]
default-
> > using an <edit-config> (and without using <copy-config> without having
target
> 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.)
> 
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:
> 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.

*if* the device accepts such a <config> in the edit-config request, then it
probably
should do the following:

Upon receiving a  <config operation="delete"/>
returns a data-missing error since no match is found to delete.

Upon receiving a <config operation="replace"/>
returns <ok> but effectively no-op.

-Xiang

> > 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).
error.
> 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).
<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).
> > 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
> > > 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!
> > >
> > > => Will delete aLeaf node.  If this leaves topCont empty, then
> > > topCont would be removed.  If topCont still contains other elements,
> > > topCont would remain?
> >
> > > => Will delete aLeaf node.  If this leaves topCont empty, then
> > > topCont would be removed unless it is a presence node.
> >
> > Yes  (s/would/may/)
> >
> > > ---
> > >
> > >         <aLeaf xc:operation=delete/> </config>
> > >
> > > => Would this delete aLeaf, and, as per (d), conditionally
> > > <topCont>, or must the value of the leaf be specified?
> > >
> >
> > > Is there a way to delete all leaflist entries without specifying
> > > them individually, eg:
> > >
> > > ... 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
> > >
> > > > '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'
> > > > 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
> > > >
> > > > > 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:
> > > > >
> > > > > '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
> > > > > 'replace' meant to have equivalent semantics to 'merge' ie it
> > > > > will only replace configuration when an explicit replacement is
> > > > Yes the latter is correct.  Note that the definition of "replace"
> > > > as an operation says:
> > > >
> > > >             Unlike a

---

From: "Sterne, Jason (Nokia - CA)" <[email-masked]>
Date: Mon, 30 May 2016 22:44:34 +0000

Hi guys,

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

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

datastore

To delete a  datastore, use <delete-config>, although <running> can't be deleted.
To replace the *entire config*, use <copy-config>. 

possible

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

default

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

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

are
the
seems like

     <rpc message-id="101"

Without specifying value so that the device can find an exact matched interface, this won't work.

can't find a match then then the delete will fail with a <data-missing> error.

with
deletes
strange
or leaf-

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

> only if the configuration data currently exists" are giving me some pause here).
There
default-
default-
having
contain
to do
the
be
said?
list by just
of the
just a
nodes
nodes are
deleted.
just
But, in any
list entry's IID
IID (i.e. ,
default-
a list is
> > > the configuration actually present in the <config> parameter is affected'
> > > means in practice.
> > >

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 31 May 2016 10:50:03 +0200 (CEST)

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

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

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

> 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.)
> 
> target configuration is changed in accordance with the source's data
> and requested operations.
> 
> 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).
> > pause here).

---

From: "Sterne, Jason (Nokia - CA)" <[email-masked]>
Date: Tue, 31 May 2016 13:36:59 +0000

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

>          <min-length operation='replace'>10</min-length>  

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

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.

> >    copy-config(source=$backup, target=running)  OR

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

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

/martin

> > using an <edit-config> (and without using <copy-config> without 
> > having to explicitly list every single top level node ?
> > 
> 
> > all key nodes and their corresponding values).  I think such a 
> > delete operation would be useful,  just like "rm -rf directory".
> > 
> > --Xiang
> > > 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!
> > >
> > > topCont would be removed.  If topCont still contains other 
> > > elements, topCont would remain?
> > 
> > > just delete topCont, must I specify each individual leaflist 
> > > element I wish to remove?
> > >
> > > ---
> > >
> > > (g) aListEntry
> > >
> > > 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>
> > > > 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
> > > >
> > > > > 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 
> > > > > 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.
> > > >

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 31 May 2016 08:10:07 -0700

> On May 31, 2016, at 6:36 AM, Sterne, Jason (Nokia - CA) <[email-masked]> wrote:
> 

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]

---

From: Andy Bierman <[email-masked]>
Date: Tue, 31 May 2016 17:49:33 -0700

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]> 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
>
> replaced.  It uses the term "completely replace".  I don't know how that is
> different from "replace".  IMO, "replace" implies "completely"...
>
> 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).
>