Subject: RE: netconf notification transport issues

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 26 Jan 2006 13:45:27 -0500

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:[email-masked]] 
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Phil Shafer <[email-masked]>
Date: Thu, 26 Jan 2006 14:47:02 -0500

"Sharon Chisholm" writes:
>about.

This could still be done over a separate connection.

The only case for receiving notifications over the normal rpc
connection I see is when the notifications pertain to the outstanding
RPC.

For example, if I do a <commit-configuration> and the system starts
spewing notifications about the commit, it would be good to see
them.  But it would be good to see them _during_ the commit operations,
not after, so having them delayed until completion of the rpc defeats
the only use case I can imagine, leaving me to wonder what the win
is.  Why not just put them over another connection?  System resources?
Juergen's number question that.  Simplicity?  Seems to be adding
complexity rather than removing it.

FWIW, we've done this as a separate channel within beep, where the
intermixing isn't an issue, and the developers feel that this was
needless complexity.  Using a distinct connection is such a win in
simplicity that it's hard to beat.

Re: parsing issues:  Yes, this shifts you from a document world to
a SAX world, but this does not seem like a huge deal.

Thanks,
 Phil