Re: netconf notifications review

[Andy Bierman <ietf@andybierman.com>]

David B Harrington wrote:
> 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.

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! ;-)


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


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.


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


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.



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


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


> The netconf community needs to decide what netconf should be designed
> 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

>

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