tom.petch wrote:
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.
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
----- Original Message -----
From: "Netconf" <trac@tools.ietf.org>
Cc: <netconf@ops.ietf.org>
Sent: Wednesday, August 01, 2007 4:47 PM
Subject: [Netconf] #14: notification termination mechanism considered
dangerous
#14: notification termination mechanism considered dangerous
---------------------------------------------+------------------------------
Reporter: ietf@andybierman.com | 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 rzǧuƠz'z ( 笶l_뢸0m
( rz)ڲ) b欶zˁ^
w&rzm Ȟ+ b?\w
--
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/>
--
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/>