Re: Proposal to do away with netconf attributes in data model payloads

[Andy Bierman <abierman@cisco.com>]

At 01:03 PM 4/1/2004, Juergen Schoenwaelder wrote:
>On Wed, Mar 31, 2004 at 03:54:49PM -0800, Andy Bierman wrote:
> 
>> Look at this encoding:
>>   
>> <modify>
>>   <target xmlns="http://example.com/xsd/foo.1";>
>>    /chassis/slots/slot[@instance-id='3']/ports/port[@instance-id='7']/duplex-mode
>>   </target>
>>   <value>auto</value>
>> </modify>
>> <create>
>>  <target xmlns="http://example.com/xsd/foo.1";>
>>   /chassis/slots/slot[@instance-id='3']/ports/port[@instance-id='7']/filters/ip-filters/ip-filter[@instance-id='1']
>>   </target>
>>   <value>
>>     <action>permit</action>
>>     <direction>both</direction>
>>     <address>
>>       <addr-type>ipv4</addr-type>
>>       <addr>192.168.1.1</addr>
>>     </address>
>>   </value>
>> </create>
>
>This is more or less what I have in mind and what I prefer to do. Note
>that this approach does not dictate how naming is actually done (as
>long as you can express it in xpath).

This requires Xpath in every box, which is going to be
a deal-breaker for some vendors.

I'd like to hear from operators who are thinking of using
NETCONF in scripting applications.  Which is easier
for you to implement?
  a - the Xpath expression plus a data model element tree, 
  b - the Xpath expression plus just the <value> data to change (like
     the example above)
  c - the operation attribute inside the data model element tree?

One problem with the approach 'b' above is that it doesn't meet the
operator requirement that the output from a <get-config>
operation should be usable as input back into an <edit-config>
command.  The config representation has to be identical
for edit and get.

> 
>> I think this was suggested already on the mailing list.
>> IMO, if Xpath is supported, it's a much more efficient encoding
>> than what we have now.  But I don't want to make Xpath mandatory.
>
>I believe that the main market for initial netconf deployment are 
>operator networks and they run boxes that should be capable to do 
>xpath processing. Once netconf is successful in this market and 
>operators/administrators like it, smaller boxes will start to 
>support it because there is a customer demand. If netconf does 
>not take off in this market, then we have failed anyway and the
>whole issue becomes a mood point.

I can't speak for other vendors, but Cisco is looking for
a standard that can be deployed on all of our platforms
in a cost-effective manner.  Optional implementation of
Xpath on large boxes (for extended filter and wildcard
features) is fine, but if it appears from the start
that the protocol is only appropriate for large routers,
there won't be very much incentive to implement it
for vendors who have other networking products besides large
routers.


>/js

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