interleaving

["David B Harrington" <dbharrington@comcast.net>]

Hi,

(Andy, do you plan to put interleaving into trac?)

For what it's worth, ISMS supports interleaving over its SSH
connections; the tunnel is a tunnel, and traffic is traffic. 

If an operator prefers to NOT interleave the ISMS traffic, for example
to ensure notifications aren't held up by large response messages,
they can configure their notifications to go over a different SSH
session by specifying a different port in the TARGET-MIB. 

ISMS doesn't have subscriptions and replay and other niceties as an
extension of the protocol; in SNMP such things would be handled
through data model manipulations rather than protocol extensions.

David Harrington
dbharrington@comcast.net
ietfdbh@comcast.net


> -----Original Message-----
> From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Wednesday, August 01, 2007 10:58 AM
> To: Balazs Lengyel
> Cc: David B Harrington; trac@tools.ietf.org; netconf@ops.ietf.org
> Subject: Re: [Netconf] #9: notification replay in the future
> 
> Balazs Lengyel wrote:
> > Hello,
> > I vote for MUST NOT. Why complicate things. Will it bring 
> us anything?
> > 
> 
> Things are complicated either way.
> First, what are the choices?
> 
>    1) require interleaving MUST be supported by the agent
>    2) allow interleaving to be supported by the agent,
>       but just warn that the manager SHOULD NOT interleave
>       and the agent MAY NOT accept interleaved requests.
>    3) allow interleaving to be supported by the agent,
>       based on the '#interleave' capability,
>       and also warn that the manager SHOULD NOT interleave
>       and the agent MAY NOT accept interleaved requests.
>    4) require interleaving MUST NOT be supported by the agent
>       - what happens when the manager sends an <rpc> anyway?
>         a) close session
>         b) ignore request
>         c) send operation-failed response
> 
> What are the benefits?
> 
> There obvious benefit from allowing interleaving,
> if you believe sessions are expensive -- it saves an extra session
> on both the manager and the agent.
> 
> The real benefit is that <close-session> is a the cleanest way
> to terminate sessions, and it should be used in all modes.
> The <kill-session> and drop connection methods are both bad ideas.
> 
> It would also be a HUGE CLR to forbid interleaving completely.
> In the future, some new feature will come up that will make it
> clear the agent should never be in a mode it MUST stop listening
> to all input from the client.  It will be clear then (if not now)
> that this is a really bad idea.
> 
> So what are the benefits of forbidding interleaving completely,
> and what happens if the manager sends an <rpc> anyway?
> 
> 
> > I submitted the same comment as Dave in trac, but it seems 
> that there is 
> > no email about updates to trac issues.
> > 
> > Balazs
> > 
> 
> 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/>
> 



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