Re: netconf notification transport issues

[Phil Shafer <phil@juniper.net>]

"Sharon Chisholm" writes:
>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.

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

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