[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal to do away with netconf attributes in data model payloads
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.
> >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.
/js
[I still believe the costs for handling simple xpath expressions
is roughly the same as comparing XML subtrees - the parsing might
actually be simpler with xpath.]
--
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany
--
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/>