Re: Separation of configuration and control - good or bad?

[Phil Shafer <phil@juniper.net>]

Larry Menten writes:
>The idea presented is that the
>configuration operations be modeled as direct modifications to a
>tree of configuration information.

Configuration content is certainly underspecified in the draft, mostly
because this was seen as future work. I'd be happy to see the
attribute-based configuration operations from Junoscript added to the
draft, which I think will answer most of your points. Here's an
example from a previous email:

<configuration xmlns="http://xml.juniper.net/junos/5.4I0/junos";>
  <protocols>
    <ospf>
      <exports>
        <export insert="before" name="bar">foo</export>
      </exports>
      <areas>
        <area active="inactive">
          <name>0.0.0.1</name>
        </area>
        <area>
          <name>0.0.0.0</name>
          <interfaces>
            <interface replace="replace">
              <name>135.104.52.3</name>
              <hello-interval>10</hello-interval>
            </interface>
            <interface delete="delete">
              <name>135.104.52.2</name>
            </interface>
          </interfaces>
        </area>
      </areas>
    </ospf>
  </protocols>
</configuration>

Replace, delete, insert, copy, and rename operations are supported
inside a <load-configuration> (the Junoscript equivalent of
<set-config>) operation. The goal was to allow the functionality of
'patch' inside a single operation.

The statement in
>the proposed guidelines that recommends that elements for which
>more than one sibling instance can appear should be collected in
>an element representing the array suggests to me that they might
>be using an object serialization/restoration design pattern to
>construct the candidate configuration data structures from the
>configuration file.

Not at all. It's just that in Junoscript we've got cases with and
without the enclosing element and our experience is that having
such container elements makes life easier (for some unspecified value
of 'easier').

Thanks,
 Phil

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