[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Second Example in section 7.2 of netconf-proto

Martin Bjorklund wrote:

Andy Bierman <ietf@andybierman.com> wrote:

Martin Bjorklund wrote:

Andy Bierman <ietf@andybierman.com> wrote:

Martin Bjorklund wrote:

IMO:

If the agent data model has sub-trees that are
not included in the 'replace' subtrees, then they
are not touched.  Only the agent data model subtrees
explicitly included in the replace-subtrees are touched.

At least that's what I meant when I wrote the original text.

An example:

  <bowler xmlns="urn:foo">
    <name>Fred</name>
    <status>married</status>
    <cars>
      <car>
        <id>ABC-123</id>
        <make>volvo</make>
      </car>
    </cars>
  </bowler>
  <interfaces>
    <interface>
       <name>eth0</name>
       <ip>10.0.0.1</ip>
    </interface>
  </interfaces>
+ <bowler operation="replace"> 
   <name>Fred</name>
   <status>divorced</status>
 </bowler>



To come up the the result that follows,
you need to do:

   <bowler operation="replace">
    <name>Fred</name>
    <status>divorced</status>
    <cars operation="delete"/>
   </bowler>


Otherwise the 'cars' element is untouched.


If this is the case, how is 'replace' different from 'merge'??



Depends on the data model.
What if the data model allowed duplicate entries?
What if some subtrees allow duplicates or have
some additive properties (defined in the object semantics)?
Then merge and replace act very differently.
They don't in your example though.





The 'interfaces' data model (and all the other
sibling subtrees not included in the replace-subtrees)
are not affected whatsoever by an operation="replace".


That means that	in order to actually completely *replace* an entire
subtree (i.e. not the entire config), a manager would have to first
do a get-config to figure out all instances of all objects, then do an
edit-config where all of these instances are marked as delete, and at
the same time add the new instances?


We have copy-config for course-grained clobbering
of config data.  Edit-config is for fine-grained operations,
so yes, you would have to explicitly delete subtrees by
including the root of the subtree in the request.





This is the whole point of using an operation attribute
placed in the root of the subtree to be affected.


I agree that the operation attribute is very useful.


/martin




Andy


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>