[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Notification Message Processing Model



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

Andy Bierman wrote:
> 
> I am trying to understand how the protocol will have
> to be modified to support notifications and RPCs on
> the same channel-less connection.

Rather than go into specific details, I would rather say that:

- - Putting notifications and RPCs on the same channel adds complexity to
the server.

- - It also adds complexity to the client (but really only to clients that
want it).

- - It would be nice to live without the complexity if we can.

I *think* this is pretty much what Andy Bierman has been saying.

As I see it, a client can usually multiplex two channels into one very
easily. Can someone explain a case where this is not true? (One case
presented in the working group where this may not be true is for clients
that are managing tens of thousands of devices. However, I think both
SSH and BEEP allow multiple channels on a single TCP connection, so we
should probably consider the "massive management" case a non-problem.)

Also, can someone give a specific example where putting notification and
RPCs on the same channel would be simpler than creating a new channel?

Apologies if this has already been given and I missed it!

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

iD8DBQFEIsRgMsfZxBO4kbQRAsrvAKC7DswY53262nWpXak/qsFnkl9HjACfYkm2
PpxTL6l87W8w/M+IW3MS7Lc=
=Xp+M
-----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/>