Re: Poll for consensus on edit operations

[Andy Bierman <abierman@cisco.com>]

At 06:51 AM 4/11/2004, Simon Leinen wrote:
>Andy Bierman writes:
>> I now agree with Juergen that it is highly undesirable
>> to require protocol-specific attributes in data-model
>> elements to implement any NETCONF protocol operation.
>
>I still prefer the approach of having the operations and their
>starting points encoded within the configuration objects (whether as
>attributes or as elements, I don't care).

I do too now.  If Xpath alone would solve the problem,
I would probably lean that way, but without a standard
attribute in the data model, the Xpath expressions will
all be proprietary, and developers will have to maintain
device-specific mappings and build massive libraries to
support the 100s of different Xpath expressions they need.

That would be worse than what we have now with SNMP.
So as long as we need protocol-specific meta-data in the
data models, the attribute approach is our best choice.


>> It is better to keep the data models as protocol independent
>> as possible, to avoid dependencies on specialty tools
>> that will limit the deployment of NETCONF.  It is better
>> to use more complex mechanisms (like XPath) that are likely 
>> be supported by general-purpose XML standards-based tools.
>
>Although this sounds nice from a client-side development point of
>view, it means additional complexity on the agent side.
>
>As an operator, I want as little stuff as possible between me and the
>configuration beyond what's necessary (most of which is already in
>today's CLI configuration engines).
>
>What I certainly don't want is a situation as with SNMP today (with
>many/most device vendors), where the instrumentation has to be done by
>SNMP specialists, rather than by the people who implement the base
>functionality of the device.

This is an excellent point.  It is very difficult for vendors
to make a business case for lots of specialists to support
yet another NM protocol.  Hopefully, vendors will be able to
integrate their netconf agent implementation with their native
CLI operational environment, and the same person will be able
to instrument for CLI and NETCONF with the same code base.


>Thus adding an XPath subset to NETCONF would be a step in the wrong
>direction.

Xpath subset -- yes.
But I wouldn't rule out full Xpath as an optional
filter and wildcard expression language for either
edit-config or get operations.  Something for the
data modeling WG effort to look at, perhaps.

>-- 
>Simon. 

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