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

[Andy Bierman <abierman@cisco.com>]

At 02:19 PM 4/1/2004, Juergen Schoenwaelder wrote:
>On Thu, Apr 01, 2004 at 01:28:29PM -0800, Andy Bierman wrote:
> 
>> 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 all approaches require changes to <get-config> retrieved data 
>to compose a meaningful <edit-config> arguments. If I recall correctly,
>then the operator's requirement was to be able to restore a complete 
>previously retrieved configuration on the device without having to
>change it (basically the reason for the separation of state/statistics
>from configuration data). My reading of the current NETCONF ID makes
>me believe that this is the purpose of the <copy-config> operation.

No.  It's not an accident that the default operation for
<edit-config> is 'merge'.  A complete config retrieved with 
<get-config> can be saved (e.g., as the startup config) and 
applied the same box (or replacement box) without modification. 


>> >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.
>
>So then Cisco should like to idea of subsetting xpath for smaller
>boxes. I fail to see how creating something completely new to 
>solve the already solved problem of selecting parts of an XML 
>document will save any money.

I don't think the NETCONF WG is the right forum for redefining
XML standards.  The value of off-the-shelf tools is lost if
the agents don't conform to the same XML standards as the
applications.


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