Subject: netconf notifications review

From: "David B Harrington" <[email-masked]>
Date: Thu, 18 May 2006 09:11:20 -0400

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 May 2006 07:11:34 -0700

> Netconf notifications definitely fall after those in my priority list.

Netconf implementation is actually first on my priority list.
I will volunteer to review 1 or both ISMS documents if you review
the notifications document.

(First RAQMON, now this -- I don't want to learn about security! ;-)

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

I can't speak for others, but I am trying to address these problems
(and more) with running code, not I-Ds.  Documentation of this research
when it is done is a possibility, but not a priority.

> duplicating functionality.

In a company, one of your first steps might be to have some people explore
the solution space and even prototype the most promising solution approach.
After that, you can discuss the problem with some understanding
of the probability and cost of solving it.

I don't think the vendors and operators have enough experience
with netconf to really understand all the integration requirements.

> well and end up doing all things poorly. 

It hasn't actually started to do 1 thing well yet.

> to do. And so far, I do not see consensus on that point.

I don't either, be we will keep looking for consensus anyway.

> dbh

Andy