RE: Netconf! Part Deux

["Andrea Westerinen" <andreaw@cisco.com>]

Phil, I would like to comment on your ABO vs OOV argument.  I agree that for
simple add/modify/delete operations (diff and patch kind of things) that
verbs and OO operations are heavyweight. But will this be the entire extent
of NetConf, or just be the first level/basic requirements?  If the answer is
"no" (that NetConf will expand in capabilities in later releases, and other
operations or even abstractions of operations will be needed), then a
concept of verbs is necessary. Maybe you have some basic +/- capabilities
built into NetConf, and still allow for OOV.  For configuration tasks where
you have input parameters, output parameters, return codes on the method
(like "Not Supported" :-), then OOVs make a world of difference.

Andrea

-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Phil Shafer
Sent: Thursday, April 08, 2004 2:13 PM
To: netconf@ops.ietf.org
Subject: Netconf! Part Deux

<snip>

(II) Attribute-based Operations

Most of the recent discussion has been about shifting from attribute-based
operations (ABO) to more "object oriented verbs" (OOV).

I don't see the win, since the target audience isn't after full-blown
object-oriented technology.  The requirement is more like that of 'diff' and
'patch', so that a configuration database can be easily modified. ABO
attributes are comparable to the '+', '-', and '!' tags at the front of the
diff lines.  Data is marked with the operation that should be performed,
giving a simple mechanism for expressing the desired change.

Consider the case where you want to change the address of an interface.
Since multiple addresses are supported, you really need to delete the old
one and add the new one.  With ABO, this is simple:

  <configuration>
    <interfaces>
      <interface>
        <name>so-0/0/0</name>
        <unit>
          <name>0</name>
          <family>
            <inet>
              <address delete="delete">
                <name>10.1.1.1/24</name>
              </address>
              <address> <!-- adding a new one -->
                <name>10.2.2.2/24</name>
              </address>
            </inet>
          </family>
        </unit>
      </interface>
    </interfaces>
  </configuration>

The equivalent in OOV is more verbose:

<delete>
  <configuration>
    <interfaces>
      <interface>
        <name>so-0/0/0</name>
        <unit>
          <name>0</name>
          <family>
            <inet>
              <address>
                <name>10.1.1.1/24</name>
              </address>
            </inet>
          </family>
        </unit>
      </interface>
    </interfaces>
  </configuration>
</delete>
<create>
  <configuration>
    <interfaces>
      <interface>
        <name>so-0/0/0</name>
        <unit>
          <name>0</name>
          <family>
            <inet>
              <address>
                <name>10.2.2.2/24</name>
              </address>
            </inet>
          </family>
        </unit>
      </interface>
    </interfaces>
  </configuration>
</create>

Not only is the OOV version more repetitive (making it harder to generate
and maintain), but the desired goal (changing the interface
address) is harder to discern from the XML.  Imagine writing an xsl template
that has to generate both hierarchies rather than allowing the normal xsl
descent to emit your enclosing elements.

Somewhere in the discussion, the comment was made that we're "not likely to
add more verbs anytime soon".  I strongly disagree, since we'll need verbs
to adjust the order (insert), activate and deactivate sub-trees, renaming,
copying, etc.  I'd expect that all the operations one can do under the CLI
will find their way into the API.

<snip>


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