Re: Notification Message Processing Model

[Shane Kerr <Shane_Kerr@isc.org>]

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

Andy Bierman wrote:
> 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.

I wonder why not do something like:

C:  <rpc ...>
C:    <get-syslog-notifications>
C:      <level>warning</level>
C:    </get-syslog-notifications>
C:  </rpc>
S:  <rpc-reply ...>
S:     <okay/>
S:  </rpc-reply>
S:  <notification>
S:    ... data for notification ...
S:  </notification>
S:  <notification>
S:    ... data for notification ...
S:  </notification>
S:  <notification>
S:    ... data for notification ...
S:  </notification>
   .
   .
   .

Each notification is valid XML, self contained. Do we really need to
wrap the set for some reason?

- --
Shane

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

iD8DBQFEIzUJMsfZxBO4kbQRAib1AKDLhZdxN4OZAW5KfonZiUyFVEIKGQCfboSJ
byuRmLeOXNChjR64oFgmWq4=
=bN6H
-----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/>