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