[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Notification Message Processing Model



It was in my response to your original e-mail. Pasted below

"From an operational standpoint it makes much more sense to have
dedicated connections or channels for commands/control & notifications.
When using SSH it is an operational/resource constraint decision whether
or not a full dedicated SSH session is used for commands & notifications
or a single session with multiple channels is utilized.
A notifications session/channel needs to allow the transfer of commands
(i.e. rpcs and notifications mixed) because for example (just one, there
are others) a management application dedicated to
monitoring/troubleshooting may need to retrieve additional information
in response to a received fault-notification. I think that in this
situations it is ok to simply interleave messages. "

Hector

 

> -----Original Message-----
> From: Andy Bierman [mailto:ietf@andybierman.com] 
> Sent: Thursday, March 23, 2006 12:58 PM
> To: Hector Trevino (htrevino)
> Cc: Phil Shafer; Netconf (E-mail)
> Subject: Re: Notification Message Processing Model
> 
>  >...
> >> 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.
> >
> >   
> 
> I don't see an example. Please explain in more detail.
> 
> >>  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/>