Re: [Netconf] #14: notification termination mechanism considered dangerous

[Andy Bierman <ietf@andybierman.com>]

Netconf wrote:
> #14: notification termination mechanism considered dangerous
> ----------------------------------------------+-----------------------------
>   Reporter:  ietf@andybierman.com             |       Owner:                 
>       Type:  defect                           |      Status:  new            
>   Priority:  major                            |   Milestone:                 
>  Component:  draft-ietf-netconf-notification  |     Version:                 
> Resolution:                                   |    Keywords:  notification-08
> ----------------------------------------------+-----------------------------
> Comment (by schishol@nortel.com):
>
>  This has been design intent ever since interactive notification sessions
>  were removed after the Montreal meeting. Why is this suddenly an issue?
>
>  Do we expect to resolve this "issue" in this release or via an additional
>  capability later that fully supports interactive notification sessions?

I do not want to enter thread replies into the tracker.
There is too much overhead in the messages.

This is an issue because it cam up during a WGLC review.
I am raising an objection to the design of the termination
mechanism as defined.  It is especially bad form for a
WG that is supposed to know network management to design
a protocol mechanism that generates alarms (drop TCP conn)
or makes it easy to break the network (kill wrong session),
on purpose -- with intent -- by design, even.

IMO, a better design would be that agents MUST support
RPC inter-leaving, at least for the <close-session> operation.

This greatly impacts the complexity of script-driven NETCONF
client implementations, which connect to an agent,
execute a bunch of NETCONF commands, and then
use <close_session> to finish up cleanly.  This Notification
design choice breaks all applications that assume they can
establish a session, do work, then close the session.
This is a rather common design assumption, and it keeps
applications simple.

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