Re: create-subscription vs. subscribe

[Andy Bierman <ietf@andybierman.com>]

Juergen Schoenwaelder wrote:
> On Mon, Nov 13, 2006 at 04:41:35PM -0500, Phil Shafer wrote:
> > Andy Bierman writes:
> > > I agree, but many others think the 'subscribe' model is the
> > > most familiar.  I am concerned that we might be setting up
> > > expectations of feature complexity with this terminology.
> > Exactly.  When I look at:
> >
> >    http://en.wikipedia.org/wiki/Observer_pattern
> >    http://en.wikipedia.org/wiki/Publish/subscribe
> >
> > I don't see a lot of parallels.  More strongly, I don't see the fit
> > between pub/sub and the unicast world of netconf.  We don't have a
> > message bus or a broker.  We don't have multiple subscriptions.  We
> > don't have anything one would recognize as a pub/sub system except
> > the method names.  It can't help but be confusing.

I agree.  We are presumably using filters as a way for the NMS
to subscribe to different event classes, except we removed event
classes, and the filters are static.

Our 'publish' operation is actually a <get> of <the <streams> element.


> I am confused. What is the "unicast world of netconf"?

I am guessing Phil means NETCONF is peer to peer on a
single transport connection.  We do not have a "buss" or
"multicast" communication architecture that one usually finds
with a pub/sub model.


> I guess your main concern is that you do not like this
>
>                              C                           S
>                              |                           |
>                              |  <create-subscription>    |
>                              |-------------------------->|
>                              |<--------------------------|
>                              |     <rpc-reply>           |
>                              |                           |
>                              |     <notification>        |
>                              |<--------------------------|
>                              |                           |
>                              |     <notification>        |
>                              |<--------------------------|
>                              |                           |
>                              |     <notification>        |
>                              |<--------------------------|
>                              |                           |
>
> and instead would like to see this
>
>                              C                           S
>                              |                           |
>                              |  <create-subscription>    |
>                              |-------------------------->|
>                              |                           |
>                              |     <notification>        |
>                              |<--------------------------|
>                              |                           |
>                              |     <notification>        |
>                              |<--------------------------|
>                              |                           |
>                              |     <notification>        |
>                              |<--------------------------|
>                              |                           |
>                              |<--------------------------|
>                              |     <rpc-reply>           |
>                              |                           |
>
> right? But that is a much more fundamental discussion. For what the
> current ID describes, I do believe "subscribe" is the better name.

I think this is the long-lived RPC model, which we are not using.
We are using the model in your first diagram.


> /js

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