[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: stopping notifications
Martin Bjorklund wrote:
Andy Bierman <ietf@andybierman.com> wrote:
Hi,
If an agent was to keep track of dropped sessions, and perhaps even
generate a notification, or take other action, then the design of
the notification feature will be a concern.
The only way to stop getting notifications is to drop the session.
Or just open a new channel (netconf session) and send a <kill-session>
for the notification session.
true, although a little more work for the manager
Unlike normal RPC mode (i.e., <close-session>), the agent has no
indication that this is intentional and not a network problem.
Would it be a feature or a hack to allow the agent to accept a <close-session>
request during 'notification delivery mode'? If a feature, should this
be the mandatory mechanism to get out of notification mode and exit?
(The tail -f command this is modeled after has the manager send 'control-c'
in this case -- <close-session> is our closest matching operation.)
This means that the agent has to poll for and parse incoming requests
while sending notifications. If the request is something else, should
an error be generated or should the session be terminated? If the
agent has logic for this, it could very well handle any request, IMO.
The agent has to send something if a manager sends an RPC request
during notification mode, even if it is a quick 'operation-failed' reply.
Just letting the manager hang until it times out seems wrong.
IMO, there is already code to close down the session in case
it is dropped, and this is not nearly as hard to support as
allowing any RPC method.
However, the <kill-session> workaround could be good enough,
and it won't require any changes.
/martin
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/>