Re: Notification Message Processing Model

[Andy Bierman <ietf@andybierman.com>]

Phil Shafer wrote:
> "Hector Trevino \(htrevino\)" writes:
>   
> > Now, given the above, someone may decide to use a single session for
> > both rpcs and notifications. This is a lose-lose situation as you point
> > out below.
> >     
>
> If it's a lose-lose, why allow it?
>
>   
> > One thing that could be done if need be is to allow
> > configuration of priorities (prioritize rpcs over notifications or
> > viceversa but that's about it) & things run to completion. 
> >     
>
> This seems like adding more complexity to handle the additional
> complexity of a complex solution.
>
> A long-lived RPC running on a distinct channel is trivial and is
> allowed within the existing netconf spec for no additional
> protocol-level work.  Just make a capability that defines your RPCs
> and you are golden.
>   

Here is a variant of your proposal that gets rid of the partial
XML document problem.

New Capability:

  :notification-mode

Architecture changes:

  An active NETCONF session has two modes:

  rpc-mode: The session is being used for RPC operations.
  The manager can send <rpc> or <stop-notifications/>.
  The agent can send <rpc-reply>.

  notification-mode: The session is being used for notifications.
  The manager can send <start-notifications> or <stop-notifications/>.
  The agent can send <notification> and <rpc-reply>.

  Initial mode: rpc

Protocol changes:

 New RPC method (i.e., from manager to agent):

  <start-notifications>

    Parameters:

       (parameter details TBA -- to-be-argued)

     If the agent is in 'rpc' mode, and the parameters are
     acceptable, then a positive response is returned and the
     agent will enter notification mode. 

     If the agent is already in notification mode, and the agent
     will allow the new parameter set values (if different than
     the current values), then the agent will return a positive
     response and start using the new parameter values.  If the
     new parameter values are the same as the current values,
     then a positive response is returned.

     Otherwise a negative response is returned.

     While in notification mode, all <rpc> requests will be returned
     with negative response <rpc-reply> messages.  In this mode the
     manager should expect to receive <notification> messages that
     meet the selection criteria specified in the 'xxx' parameters,
     generated as various events occur within the agent.

   Positive Response:

     <ok/>

   Negative response:

    If the agent cannot honor the requested the request for any
    reason a <rpc-error> response will be generated.


 <stop-notifications>

     If the agent is in rpc mode it will simply return a positive
     response and stay in rpc mode.

     If the agent is in notification mode it will finish sending
     any <notification> message in progress to maintain a well-formed
     XML message stream, and then terminate notification mode, and
     switch to rpc mode.

     Regardless of the current mode, the agent will return a positive
     response.

  Parameters:

     none

  Positive Response:

     <ok/>

  Negative Response:

     none


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