RE: Notification Message Processing Model

["Hector Trevino \(htrevino\)" <htrevino@cisco.com>]

> -----Original Message-----
> From: Phil Shafer [mailto:phil@juniper.net] 
> Sent: Thursday, March 23, 2006 11:52 AM
> To: Hector Trevino (htrevino)
> Cc: Andy Bierman; Netconf (E-mail)
> Subject: Re: Notification Message Processing Model 
> 
> "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?

HT: I think dedicated sessions/channles should be used. But we can't
disallow the use of mixed rpcs and notifications because there're
situations in which you may need to issue rpcs on a notification
session/channel (as per my example). I say it is a lose-lose situation
because if someone decides to use a single session for both then chances
are the operational needs will not be satisfied w/o adding much
complexity. 

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

HT: Yes, agree w/you. Simply was saying that if we need to do something
then it needs to be relatively simple. But my preference to avoid any
additional work & complexity. 
> 
> 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/>