Re: Second Example in section 7.2 of netconf-proto

[Andy Bierman <ietf@andybierman.com>]

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

> > We have copy-config for course-grained clobbering
> > of config data.  Edit-config is for fine-grained operations,
>
> But copy-config replaces the *entire* configuration, which also means
> that you have to have write-access to *all* config data in order to
> use copy-config at all.
>
> > so yes, you would have to explicitly delete subtrees by
> > including the root of the subtree in the request.
>
> 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.

The issue here is unspecified subtrees under the
node that contains an operation="replace" attribute.
Not sure if the spec is unclear on this topic.
IMO, you should not touch anything not explicitly
mentioned in the replace-subtree.  That is how I
interpret the text.  I can see how there could be
exceptions.

For example, let's say you had a data model that
was essentially a discriminated union.  In this case,
the agent knows the data model semantics, and
knows that if you change the discriminator that
a different sibling in the union will be selected.

(Sorry for the psuedo-C; IMO it's easier to read than XSD.
Real data model is more complicated; this is just a subset
of my RFC 4001 data model):


    struct InetAddr {
      InetAddressType addr-type;
      choice {
        InetAddressIPv4  ipv4-addr;
        InetAddressIPv6  ipv6-addr;
        InetAddressDns   dns-addr;
      }
    }

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

  struct Interface {
     IfNameType name;
     InetAddr   addr;
     ...
  }

 <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 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 don't know which is right or wrong, or if they
are both right (or wrong ;-).



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