Re: Notification Message Processing Model

[Phil Shafer <phil@juniper.net>]

Kunihiko Toumura writes:
>In notification, a server (=router/switch) sends message to client (=manager),
>and there is no need to reply for the notification message.
>This far differs from RPC model (client->server, request-reply).

It's a matter of perspective, I guess.  I see it as an RPC asking
for a realtime feed of specific syslog data.  The reply contains
the data, and continues feeding data until the request is aborted.
The client is requesting data, the server is serving it up, in a
classic client/server model.

In the subscription-model, the application asks the device to send
notifications as a background task, interleaved with the normal
<rpc-reply>s that are the netconf mainstay.  I dislike this "oh by
the way, if you're bored, please send some notifications" metaphor.
It takes a fairly simple request for data and turns into something
more complex.  It puts multiplexing/interleaving into an RPC mechanism
where it is not well suited, imho.

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