[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Netconf! Part Deux
HI,
When you start talking about additional operations and these
are "actions", then I believe that the analysis is different
than configuration data, status, and statistics.
At 02:58 PM 4/9/2004 -0700, Andrea Westerinen wrote:
>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>
>
>
>--
regards,
/david t. perkins
--
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/>