Re: Clarification on future stopTime

[Phil Shafer <phil@juniper.net>]

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.

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