[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: no NETCONF WG meeting planned for Paris
David B Harrington wrote:
Hi Andy
There are some pretty powerful features within a
decent transaction model to act on that bucket of XML content.
I know some of us on the design team we're really just
trying to eliminate screen-scraping the CLI with 1.0.
Even if NETCONF is just used as a programmatic interface
to the CLI at first, this is better than screen-scraping.
And I strongly support that vision. Screen-scraping needs to go.
But we also need to move past the constraint that any operator must be
able to lock the whole configuration to modify it, and a large number
of other issues that you have collected during the development of
netconf 1.0. Just changing from screen-scraping to XML isn't enough to
meet operators' needs, even if it is a big step in the right
direction.
I disagree.
The 2 main deferred features -- partial locking and notifications --
are both simply speed optimizations, which impact a relatively small
number of use cases. We don't have any serialization in SNMP or
CLI at all! Concurrent writes can clobber config now, but this
doesn't seem to be a big problem. I'm not convinced the lack
of locked concurrent writes in NETCONF is a problem yet.
Notifications essentially provide a speed improvement over polling
techniques. Currently, many CLI applications use SNMP notifications
and SYSLOG for this purpose. The convenience of receiving async
messages within a NETCONF session is probably balanced out by
the increased localized cost of the NETCONF implementation, and
most likely does not represent a significant percentage of either
the implementation or deployment complexity.
IMO, the lack of these deferred features has no significant impact
on the usefulness of NETCONF 1.0.
As for NETMOD -- I don't see much hope of a WG agreeing on the
one true NETCONF data modeling language. I agree that would
be the ideal from a standards-POV, but not realistic or even
close to operationally optimal. E.g., A scheme tuned for SNMP
integration isn't going to work well for CLI-oriented configuration.
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/>