Re: I-D draft-weijing-netconf-interface-01.txt

[Phil Shafer <phil@juniper.net>]

"Allen, Keith" writes:
>We felt discussing
>an example would be easier than arguing abstract concepts

Thanks for pulling your comments out in this email. It's much
easier to understand the differences, problems, and motivations
in this format.

>1. Assumptions about a device's information model are being built into
>the protocol.  One way this is manifested is with the protocol's use of
>"targets."  The specification of "startup," "running," and "candidate"
>targets presumes that the device supports these concepts.

"running" is the only target built into the base protocol; the
others are added by capabilities. If a device does not support,
say, the "startup" capability, it simply doesn't announce the
relevant capability.

The motivation for making explicit targets comes from the desire to
make a protocol that allows the device to explicitly define and
announce its native capabilities.  This allows clients to discover
these capabilities and treat the device appropriately.

For instance a device with a distinct startup configuration needs to
have the running configuration copied to the startup configuration for
the changes to be permanent. The application has to know this in order
to operate correctly, and the application can learn this via the
capabilities announcement.

We also feel that this expressiveness (here and elsewhere in the
protocol) given an exactness and explicitness that helps both the
application developer and the device programmer, since I will know
when someone wants to perform a commit operation, not by guess work
but by explicit command. The application writers will know that they
need to send a commit operation because my software announces the
"#candidate" capability.  Future products have a mechanism for
expressing their abilities without making implicit assumptions on what
they think the application is trying to do.

>The specification of a
>"running," "startup," or other target should be part of a device's
>information model schema.

Having the set of available sources and targets be part of the
protocol allows the manipulation of configuration to be separate from
the information model. If you give me a chunk of configuration, I can
put it on the router and activate it without understanding the
configuration contents, based on what I learn about the device via the
capabilities announcement.

>2.	Another way that assumptions about the device's information model
>are being built into the protocol is with many of the operations being
>specified in the protocol, like "copy," "validate" and "lock."... Our
>suggestion is to associate operations with elements in the information model
>in what we consider to be a more object-oriented approach.

The draft has locking available at any level of the configuration
hierarchy. This is both expensive and increases the cost of locking,
rollback, archival, and other tasks. A simple single short-lived lock
for the full configuration should suffice.

>The information model specified for a device must identify what
>is state information and what is configurable without the need for separate
>container elements.

Device implementations naturally segregate configuration data into a
separate mode or database. "Configuration mode" allows manipulation of
configuration data and "operational mode" displays operational
information about the device. We kept this distinction in netconf for
two reasons. First it matches the way users (and applications) think
about the device. If you are loading the configuration for a VPN, you
don't need or what operational data. Second, it matches the way
devices are implemented and reduces the cost of implementing netconf.

>4.	This is not a major point, but the "format" element in the WG text
>is unnecessary.  A more straightforward approach for devices that don't
>support a true XML interface would be to enclose the CLI text supported by
>the device with a single pair of XML tags.

The format element allows the application to retrieve the
configuration in the device's native text-based format. This allows
for archival, text-based diffing, human viewing and other applications
for which xml is not suitable.  For example, we download configuration
files in text format for cvs archival, so 'cvs diff -u -Dyesterday'
shows human-readable text.

>In our draft, we have just
>four command messages and four responses to those messages: get, perform,
>abort and notify.

You've effectively hidden the real protocol operations (lock,
validate, copy, etc) inside a small number of requests, making the
intent opaque (and increasing the cost of implementation).

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