Re: Notification Message Processing Model

[Phil Shafer <phil@juniper.net>]

Andy Bierman writes:
>   An active NETCONF session has two modes:

This introduces modality into the netconf session, which
is increasing the complexity.

Instead, we could just have a simple RPC that is long-lived:

C:  <rpc ...>
C:    <get-syslog-notifications>
C:      <level>warning</level>
C:    </get-syslog-notifications>
C:  </rpc>

The server responds with an <rpc-reply> containing an
unending series of notifications which match the criteria from
the <get-syslog-notifications> RPC:

S:  <rpc-reply ...>
S:    <notification> ... data for one notification ... </notification>
S:    <notification> ... data for another notification ... </notification>
S:    <notification> ... data for yet another notification ... </notification>
S:    <notification> ... data for one more notification ... </notification>

The notifications would continue until the channel is closed.  Or
until we resurrect the <abort/> mechanism ;^)

This is simple, direct, and uses the existing netconf framework.
If interleaving is a lose-lose, this is a win-win.

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