Re: Notification Message Processing Model

[Andy Bierman <ietf@andybierman.com>]

Phil Shafer wrote:
> 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.
>
>   

The objection to this approach in the WG meeting was that off-the-shelf 
validation tools
will not be able to work because they will be waiting for the </rpc-reply>
before finishing the validation.  Hence the validation phase never ends.

I love your approach.
It would be simple for me to implement.
I'm not using off-the-shelf validation tools though.


> Thanks,
>  Phil
>
>   

Andy



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