Re: Clarification on future stopTime

[Martin Bjorklund <mbj@tail-f.com>]

Phil Shafer <phil@juniper.net> wrote:
> Martin Bjorklund writes:
> >An alternative is to allow the second create-subscription, and let the
> >manager deal with notifications from multiple streams.  I.e. keep the
> >current text as it is.  If the manager excplitly asks for multiple
> >streams, it can probably handle it.  (And I never understood the
> >problems with multiple streams anyway...)
> 
> The problem is that it takes a simple service (give me events) that
> can be _easily_ handled over a single channel with useful and
> endearing properties (real-time, low overhead, simple model, easily
> implemented) and turns it on its head to cover a rare and uninteresting
> corner case.
> 
> If you want two sets of events, open two channels.  If you want to
> perform RPCs while getting events, open another channel.  The
> interleaving and multi-use channel aspects of the current draft are
> the annoying details where the devils live.
> 
> But I'm definitely in the KISS camp, if my face paint and shoes
> didn't clue you in already.  Keep the simple cases simple; keep
> the complex cases from interfering with the simple cases; keep
> the corner cases few and obvious.

Of course.  Simple is always good.  But simple for who?  For the agent
implementation?  Simplicity of the spec?  For the manager?  One
implementor stated that the non-interleaving mode was much more
difficult for him to implement, and he would never support it.
Several others (myself included) stated that it is not more difficult
to implement interleaving than non-interleaving.  I think the
specification would be simpler with as few special corner cases as
possible.  As for the non-interleaving mode, it was pointed out that
it would be simpler for the manager to send a <close-session> (and
thus the agent would have to handle it) than opening a new channel and
send <kill-session>.



/martin


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