Re: stopping notifications

[Martin Bjorklund <mbj@tail-f.com>]

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.

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


/martin

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