Inline.
> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
> Behalf Of Andy Bierman
> Sent: Friday, May 27, 2005 09:23
> To: dbharrington@comcast.net
> Cc: Chisholm, Sharon [CAR:5K50:EXCH]; 'netconf'
> Subject: Re: no NETCONF WG meeting planned for Paris
>
> 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.
While I would prefer that NETCONF supports partial locking I can live without this feature for now. However this feature is number 2 on my feature list with the number 1 feature listed below.
> 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.
Polling is not a good substitute for notifications. Polling does not scale both with a large box and across large networks. Notifications are simply required and required within NETCONF. Using SNMP or Syslog for notifications does not provide the integrated solution required to build consolidated and robust applications.
> 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
Regards, /gww