Re: Second Example in section 7.2 of netconf-proto

[Martin Bjorklund <mbj@tail-f.com>]

Andy Bierman <ietf@andybierman.com> wrote:
> Martin Bjorklund wrote:
> > Andy Bierman <ietf@andybierman.com> wrote:
> >>> 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.
> > 
> > So if the datamodel does not allow duplicates, then 'replace' and
> > 'merge' behave the same?
> 
> Yes

So the only reason for having a separate 'replace' operation is
because it behaves different from merge when the data model allows
duplicates? 

Could you give an example of a data model with duplicates, and how
replace and merge would behave in your interpretation?


> > This seems quite complicated...  Maybe an operation
> > "really-REALLY-replace" would be useful :)
> 
> I don't think so.  Clearly the operation attribute
> has no affect whatsoever on sibling nodes, so you
> can't clobber the entire config just because you
> replace something in one subtree.

Suppose you have a subtree 'system' with parameters 'dnsservers',
'ntpservers', 'syslogservers', ...  i.e. parameters which could be
common for many boxes in a network.  Now the manager wants to set all
these to the same value on all his boxes.  With my interpretation,
this can be done with the same edit-config to all boxes.  With your
interpretation, the manager has to query each box, and build a special
edit-config for each one.  Isn't that more complicated than necessary?

To elaborate unless my description isn't clear:

Suppose I want the end result to be:

  <dnsservers>
    <server>
      <host>10.0.0.1</host>
    </server>
  </dnsservers>

(simpler example to save space)

With my interpretation, I would send

  <dnsservers operation="replace">
    <server>
      <host>10.0.0.1</host>
    </server>
  </dnsservers>

to all boxes.

But suppose box A already has:

  <dnsservers>
    <server>
      <host>10.0.0.2</host>
    </server>
  </dnsservers>

with your interpretation (replace == merge) you would have to do:

  <dnsservers operation="replace">
    <server>
      <host>10.0.0.1</host>
    </server>
    <server operation="delete">
      <host>10.0.0.2</host>
    </server>
  </dnsservers>

... if I understand what you're saying correctly.


> What if you want to change the IP address on an interface:

>   <interfaces>
>      <interface operation="replace">
>        <name>eth0</name>
>        <addr>
>          <addr-type>ipv4</addr-type>
>          <ipv4-addr>192.168.0.1</ipv4-addr>
>        </addr>
>        <adminStatus>up</adminStatus>
>      </interface>
>    </interfaces>
> 
> +
> 
>    <interfaces>
>      <interface operation="replace">
>        <name>eth0</name>
>        <addr>       # operation=replace should really go here
>          <addr-type>dns</addr-type>
>          <dns-addr>myhost.example.com</dns-addr>
>        </addr>
>      </interface>
>    </interfaces>
> 
> =
> 
>    <interfaces>
>      <interface operation="replace">
>        <name>eth0</name>
>        <addr>
>          <addr-type>dns</addr-type>
>          <dns-addr>myhost.example.com</dns-addr>
>        </addr>
>        <adminStatus>up</adminStatus>
>      </interface>
>    </interfaces>
> 
> 
> AdminStatus is not an optional element.
> It must have some value.  Since <addr> contains
> a choice, the agent knows to remove <ipv4-addr>
> and replace it with <dns-addr>.  (So choices are special.)

I wouldn't use replace in this case, I'd use merge.

> I think your interpretation of operation=replace
> is cleaner and more strict -- you would return an error here
> and not make any changes, because the <adminStatus>
> element is not allowed to be missing.  This forces
> the manager to put the operation attribute exactly
> where it belongs, including everything in the subtree,
> or get an error.
> 
> My interpretation is more forgiving of sloppy managers,
> but would require the operation="delete" if the manager
> really did want to delete a subtree.

I think 'merge' is for the sloppy manager.

> I don't know which is right or wrong, or if they
> are both right (or wrong ;-).

Isn't it important for interopability that this issue is clear?


/martin

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