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

["Allen, Keith" <Keith_Allen@labs.sbc.com>]

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

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.

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.

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.

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.

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.

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.


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


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