Separation of protocol and information model

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

Phil, Andy,

Thanks for your comments on our draft and recent e-mail.  Of the five
concerns we raised in the email about the current working group text, three
basically enumerated various ways we feel the current protocol is being
designed around assumptions about a device's information model (the
running/startup/backup targets, the various operations built into the
protocol such as lock, kill, and validate, and separate get-config and
get-state operations).

Andy's response reiterates the validity of the assumptions.  For example:

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

We didn't mean to imply that the assumptions were invalid, but instead that
it was a bad idea to design a management protocol that built in assumptions
about the device's information model, regardless of how good they were.  We
argued quite a bit at the formation of this group and agreed that it was
outside its charter to standardize an information model, but we seem to be
starting that activity by designing the beginnings of one into the protocol.

Phil's response seems to indicate that beginning to integrate some of the
device's information model into the protocol somehow makes it clearer:

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

We feel that the way a device should make its native capabilities known is
through its information model description.  The last sentence excerpted from
Phil's response is unfair.  No guess work is involved in invoking operations
as described in our I-D.  Using the information model to define a device's
capabilities is no less clear than specifying them in a management protocol.

I think, though, that Phil's comments are probably getting close to a tough
question at the heart of this issue.  How much do we assume that management
applications know about each device's information model?  Both Andy's and
Phil's comments seem to indicate an assumption that management applications
will be intimately familiar with the details of the protocol, but less so
with the details of a device's information model.  We assume that a
management application will also be intimately familiar with the details of
the information model of each device it manages.  We don't assume that a
management application will be able to manage a new device by simply feeding
it an XML schema for the device.  Unless the device supports a standard
schema, we assume it will take a good bit of coding.

Don't get us wrong; to alleviate some of that coding we totally support the
standardization of information models.  We just think it shouldn't be done
in the protocol.

So, it seems that two diverse views on the separation of protocol and
information model have been laid out for the group.  This is probably an
important point to make a decision upon since it has a significant impact on
the protocol.


Keith Allen
SBC Labs
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
keith_allen@labs.sbc.com
 


> -----Original Message-----
> From: Allen, Keith [mailto:Keith_Allen@labs.sbc.com]
> Sent: Tuesday, September 02, 2003 4:22 PM
> To: netconf@ops.ietf.org
> Subject: I-D draft-weijing-netconf-interface-01.txt
> 
> 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/>

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