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

From: "Netconf" <[email-masked]>
Date: Wed, 01 Aug 2007 14:47:37 -0000

#14: notification termination mechanism considered dangerous
---------------------------------------------+------------------------------
 Reporter:  [email-masked]             |       Owner:     
     Type:  defect                           |      Status:  new
 Priority:  major                            |   Milestone:     
Component:  draft-ietf-netconf-notification  |     Version:     
 Keywords:  notification-08                  |  
---------------------------------------------+------------------------------
 There needs to be a safe mechanism to terminate
 a session that is in notification delivery mode.
 The manager must be able to invoke <close-session>
 in this mode, rather than terminating the
 session by other means.

 Currently a manager must start another session,
 determine the correct session number the kill,
 (don't get that wrong!) and invoke the <kill-session>
 operation, then close the new session.

 The current '<kill-session> method', as the standard mechanism
 to terminate notifications, is dangerous.  Imagine a unix
 program that could only be turned off with a 'kill -9 pid'
 command.  That is a really dangerous sysadmin practice.
 The <kill-session> should be used sparingly, just like
 the unix 'kill' command.

 The other standard way to terminate notifications is for
 the manager to close the transport connection (unexpectedly
 in the agent's POV).  This is even worse than <kill-session>
 because the agent might (incorrectly) generate event
 notifications about a network problem (lost session).

-- 
Ticket URL: <http://www3.tools.ietf.org/wg/netconf/trac/ticket/14>
Netconf <http://tools.ietf.org/wg/netconf/trac/>
Issue tracker for the NETCONF Working Group������r��zǧu���Ơz�'z�(��ު笶�l��_��0��m��(�ۧ���r��z)ڲ)���b�欶�z���^���w&�r�zm���Ȟ��+��b��?��\�w�

---

From: "tom.petch" <[email-masked]>
Date: Wed, 1 Aug 2007 16:47:18 +0200

A different approach would be to make the subscription soft so that it must be
refreshed every hour or so and in the absence of a re-subscription, it is
closed.

Tom Petch

----- Original Message -----
From: "Netconf" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 01, 2007 4:47 PM
Subject: [Netconf] #14: notification termination mechanism considered dangerous

> Issue tracker for the NETCONF Working Group rzǧuƠz'z ( 笶l_뢸0m؅(  rz)ڲ) b欶zˁ^
w&rzm Ȟ+ b?۝\w

--
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: Wed, 01 Aug 2007 11:19:16 -0700

> refreshed every hour or so and in the absence of a re-subscription, it is

The NETCONF protocol has no 'refresh' mechanism.
The notifications draft has to make it to the
finish line without requiring a single edit to RFC 4741.
(so far, so good.)

One really valid option, raised by Phil, is to just
close the session normally (as if the <create-subscription>
was followed by a <close-session>) after replay w/stopTime is
complete. Problem solved. The agent never 'sees' any new <rpc>
because the <close-session> is implicitly ahead of it in the queue.

I like this approach the best myself, rather than coming
to some technically lame solution, to reach WG consensus,
on what to do with any <rpc> that might have been sent
by the manager during replay delivery mode.

> Tom Petch

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 02 Aug 2007 09:56:02 +0200

Hello,
How does this handle the case when you want to close the notification session before stopTime 
or in the absence of stopTime ? As I understand the agent might not read anything until stopTime.
Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: "Netconf" <[email-masked]>
Date: Mon, 13 Aug 2007 14:47:48 -0000

#14: notification termination mechanism considered dangerous
----------------------------------------------+-----------------------------
  Reporter:  [email-masked]             |       Owner:                 
      Type:  defect                           |      Status:  new            
  Priority:  major                            |   Milestone:                 
 Component:  draft-ietf-netconf-notification  |     Version:                 
Resolution:                                   |    Keywords:  notification-08
----------------------------------------------+-----------------------------
Comment (by [email-masked]):

 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?

-- 
Ticket URL: <http://www3.tools.ietf.org/wg/netconf/trac/ticket/14#comment:1>
Netconf <http://tools.ietf.org/wg/netconf/trac/>
Issue tracker for the NETCONF Working Grouph�{.n�+���zwZ��,j��w�r�߭�z�h�Ȟ��+����^ݺ{.n�+�����"�	^�)�j�azg�����mn�rj�!�������l��_��?�+-��޵�'

---

From: Andy Bierman <[email-masked]>
Date: Mon, 13 Aug 2007 08:31:24 -0700

> #14: notification termination mechanism considered dangerous

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

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 14 Aug 2007 07:32:21 -0400

<Andy>

One really valid option, raised by Phil, is to just close the session
normally (as if the <create-subscription> was followed by a
<close-session>) after replay w/stopTime is complete. Problem solved.
The agent never 'sees' any new <rpc> because the <close-session> is
implicitly ahead of it in the queue.

<Andy>

That's an unexpected side-effect and not terribly pretty. I think the
current behaviour of just not reading the requests until stopTime makes
the most sense.

Sharon

---

From: Andy Bierman <[email-masked]>
Date: Tue, 14 Aug 2007 06:33:35 -0700

> current behaviour of just not reading the requests until stopTime makes

The real issue is the interpretation of the filter which is
specified by startTime and stopTime.

I think there is WG consensus that this filter only applies
to logged entries, not notifications in the future that have
not happened yet.  Are you challenging this WG consensus?

Whether the notifications are stored with sequence IDs or
timestanps makes no difference.  If there are notifications numbered
4, 5, and 6 in the replay log, and I ask "Give me all the
stored notifications from 1 to 10", this still just returned
4, 5, and 6, sends replayComplete, and is done.

It doesn't mean "Send 4, 5, 6, and wait (maybe forever)
until notifications 7 - 10 are generated."

So stopTime in the future is not an error -- it is just the upper
bound on the set of stored notifications.

Andy