[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D draft-weijing-netconf-interface-01.txt
At 02:21 PM 9/2/2003, Allen, Keith wrote:
>All,
>
>Below is a reference to an Internet Draft we have authored to illustrate a
>somewhat different approach to the NETCONF XML protocol than the one taken
>in the working group's current working text.
>
>http://www.ietf.org/internet-drafts/draft-weijing-netconf-interface-01.txt
>
>We have some concerns about the protocol specified in the current WG text so
>we created the I-D as a contribution to the upcoming working group interim
>meeting to show how these concerns could be addressed. (We felt discussing
>an example would be easier than arguing abstract concepts.) Our specific
>concerns with the current WG text are:
>
>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.
All devices have a running config.
Based on the device capabilities, it may also support a
candidate config and/or a distinct startup config.
> This need not be
>the case, and the protocol does not benefit from having this built in.
>Consider two examples below (the first is from the WG text):
>
> <get-config>
> <source>
> <running/>
> </source>
> <config xmlns="http://example.com/schema/1.2/config";>
> <users/>
> </config>
> <format>xml</format>
> </get-config>
>
>
> <get-config>
> <config xmlns="http://example.com/schema/1.2/config";>
> <running>
> <users/>
> </running>
> </config>
> <format>xml</format>
> </get-config>
>
>They both say the same thing: get the user data from the running
>configuration.
Not exactly. In the first example, the get-config operation
is restricted to the running configuration. In the second
example, there is nothing preventing the user from including:
<running>
<users/>
</running>
<startup>
<users/>
</startup>
This distinction is much more important for edit-config
than get-config. Also, in both cases the concepts of
running, startup, and candidate must be known to the
application and the device.
>A separate "source" element containing the target is
>unnecessary, and building the acceptable target values into the protocol is
>restricting and could come back to haunt us. The specification of a
>"running," "startup," or other target should be part of a device's
>information model schema.
I disagree. The concepts of candidate, running, and startup
are well-established and stable within the industry. In the
unlikely event that another type of configuration database
is needed in the future, the netconf protocol can be updated.
This is a trade-off between interoperability and flexibility.
I prefer a precise protocol that promotes interoperability.
>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." This is
>probably the biggest difference between the WG text and our draft. Our
>suggestion is to associate operations with elements in the information model
>in what we consider to be a more object-oriented approach. In our draft,
>the information model elements that could be considered "objects" have an
>attribute listing the possible actions that can be invoked on that element.
>(This has been discussed on the e-mail group as "action as attribute." The
>WG text uses this to a degree, but we take it a significant step further.)
>Our draft lists a set of "standard" operations (that includes actions like
>"copy," "validate" and "lock") but this list can be restricted or extended
>in a particular device's information model specification. The protocol
>needs to be flexible and extensible to allow for the management of both
>simple and complex devices.
I disagree. The operations defined in netconf such as copy,
validate, and lock are well-understood operations on an abstract
database. They are not specific to the content of the database at all.
This is another trade-off between interoperability and flexibility.
Allowing vendors to define their own set of protocol operations,
potentially a different set for every data object, would be a
disaster for interoperability and code reuse. Your proposal
does not remove complexity -- it just moves it into the
proprietary data models.
>3. The handling of "state" and "config" information in the WG text is
>inadequate. The information model specified for a device must identify what
>is state information and what is configurable without the need for separate
>container elements. Our draft defines a way to do this by tagging each
>element definition in an XML information model with a "category" indicating
>whether the element is state information or configuration data. The same
>category tag can be included in the get request message to act as a crude
>filter, retrieving just state information, just configuration information,
>or both.
The WG agreed in Vienna that some form of a 'get-all' mechanism
is needed so 2 requests are not needed to retrieve config and state
information.
>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. Thus, the device's information
>model schema can indicate that the text between the two tags will be
>untagged.
I agree with this point. A <text> tag would also allow for
mixed content (XML conforming to a detailed XSD and embedded
CLI).
>5. Removing some of the complexity from the protocol results in just a
>few simple operations the protocol must support. In our draft, we have just
>four command messages and four responses to those messages: get, perform,
>abort and notify. With just four operations, we don't feel it is really
>necessary to define a separate RPC layer as the WG text does.
Perform is too generic. Abort is broken because there is no
support for multiple streams (channels or multiple connections.)
Notify is also broken without support for multiple streams.
I don't think removing the <rpc> and <rpc-reply> elements
actually make implementations easier.
>Pulling up the schema from the two drafts in an editor shows that the
>protocol can be trimmed down quite a bit. There are just 8 elements defined
>in our draft, versus over 30 in the WG text. Of course, some of the
>complexity is being shifted to the information model, but we still feel that
>the "simpler is better" doctrine applies.
I think your draft glosses over a lot of important details
and punts even more details to proprietary data models.
This is not simpler, especially if you want to write an
application that will work with devices from lots of vendors.
>Our hope is that you will take a look at the draft and consider the approach
>we have taken. We think there is a lot to be said for a protocol that is
>simpler, and takes a more object-oriented approach towards operations. We
>hope to get an opportunity to discuss these ideas with you at the interim
>meeting next week, and to hopefully address our concerns with the current
>working text.
I agree that everyone should read this draft, and all the other
drafts that have been proposed to the WG. I hope we can resolve
the issues you raised on the mailing list or at the interim
meeting next week.
>Keith Allen
>SBC Labs
>9505 Arboretum Blvd.
>Austin, TX 78759
>(512) 372-5741
>keith_allen@labs.sbc.com
>
>Weijing Chen
>SBC Labs
>9505 Arboretum Boulevard
>Austin, Texas 78759
>(512) 372 5710
>wchen@labs.sbc.com
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/>