RE: netconf notification transport issues

["Sharon Chisholm" <schishol@nortel.com>]

hi

The generalized use case is when you want to send commands to get or
edit information related to the thing you are receiving notifications
about.  So, if you wanted to retrieve information about active alarms,
component state, statistics or configuration before or during receiving
notifications. It also makes for easier notification triggered polling.
If I receive information that a component has been modified, but did not
receive all the information I wanted for whatever reason, then you
simply do a query to retrieve this information and then carry on
receiving events. The main trick for this is if the response to a
command is too large, then the benefits of having the single connection
get outweighed by the delay in processing events. Then you need to open
a second connection for that function.

Oh, and another advantage of this approach is it allows you to modify
the subscription without tearing it down and restarting it. This
eliminates the chances of missing events.

Sharon

-----Original Message-----
From: Phil Shafer [mailto:phil@juniper.net] 
Sent: Thursday, January 26, 2006 1:19 PM
To: Chisholm, Sharon [CAR:ZZ00:EXCH]
Cc: Netconf (E-mail)
Subject: Re: netconf notification transport issues 


"Sharon Chisholm" writes:
>There are cases when you want to have your synchronous commands on the 
>same connection as your asynchronous one.  This obviously does not 
>imply you always want to do this.

Can you give details or use cases?

Thanks,
 Phil


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