netconf notifications review

["David B Harrington" <dbharrington@comcast.net>]

Hi Andy,

> I would appreciate it if you could read the
> latest notification draft and either fully review it
> or send comments in context of your requirements.
> 

I will try to do a review for you, but a detailed review probably
won't be very soon.
I am editing two ISMS documents and chairing the syslog WG, and
preparing other documents and presentations before Montreal, 
preparing a MIB template in xml2rfc format and doing reviews as
part of the security directorate. I also need to work with my team to
implement netconf protocol so we can contribute more effectively. 
Netconf notifications definitely fall after those in my priority list.

I would appreciate it if you (and others in the netconf community)
would review the ISMS documents. 
ISMS is dealing with issues netconf also needs to address, such as
session-based management and (VACM-independent) access control and
architectural issues; I would like to see some consistency in the
approaches to make deployment of both protocols in the same system
easier (not necessarily integration or reuse, but consistency in some
of the design decisions).

I think you'll get more from reviewing those than I expect to get from
reviewing the netconf notifications draft; I am unconvinced
notifications are needed for configuration. It doesn't much matter if
Sharon's XSD is correct or not if netconf doesn't need notifications
to perform its primary mission well.
-

I am concerned that the netconf WG is adding nice-to-have, not
must-have, features to the original scope, and Sharon keeps talking
about some unnamed applications that can run over the same channel,
and so on. I saw COPS-PR try to expand beyond its original
configuration scope, and it died as it tried to retrofit its design to
the new requirements (like message security and access control) as
well as dying for political reasons and a perpetual lock. 

Netconf is focusing on nice-to-have features like notifications and
not 
addressing real issues it will have to address, like data modeling and

access control, that are likely to impact the protocol design.

This makes me fear for the future of netconf. That is why I am pushing
for a discussion of what is the purpose of netconf, so we can bring it
out in the open and get consensus on the direction, and the
requirements. It is also why I am pushing for a management framework -
so we can discuss how snmp and syslog and netconf fit together in an
overall management protocol toolkit, much as ping, telnet, netstat,
cli, and snmpv1 have fit together as a management toolkit in the past.

This is the same type of discussion that is needed in a company that
produces multiple products or product lines with overlapping
functionality. We need to understand how the pieces can be used
together to form a system rather than competing with each other by
duplicating functionality.

If netconf tries to do everything, it will likely stop doing one thing
well and end up doing all things poorly. 

The netconf community needs to decide what netconf should be designed
to do. And so far, I do not see consensus on that point.

dbh




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