Re: Notification Message Processing Model

[Shane Kerr <Shane_Kerr@isc.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hector Trevino (htrevino) wrote:
>>From an operational standpoint it makes much more sense to have
> dedicated connections or channels for commands/control & notifications.
> When using SSH it is an operational/resource constraint decision whether
> or not a full dedicated SSH session is used for commands & notifications
> or a single session with multiple channels is utilized.
> A notifications session/channel needs to allow the transfer of commands
> (i.e. rpcs and notifications mixed) because for example (just one, there
> are others) a management application dedicated to
> monitoring/troubleshooting may need to retrieve additional information
> in response to a received fault-notification. I think that in this
> situations it is ok to simply interleave messages. 

Why not perform the query to retrieve additional information on a
separate channel?

As a client developer, it would be simplier. You avoid the case:

server -> client
  event A
client -> server
  RPC asking for more info about event A
server -> client
  event B (sent before RPC began)

The client has to either handle the event asynchronously, or save it in
some buffer somewhere (or perhaps ignore it).

- --
Shane
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEIvkdMsfZxBO4kbQRAg+fAJ9bKEopxrJIMU+YMsh/juEjC3BtrACffiWe
aeAdc9InfNEOwE+b/MDZiF0=
=Pq7j
-----END PGP SIGNATURE-----

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