Subject: create-subscription vs. subscribe

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 13 Nov 2006 15:31:10 +0100

Hi,

I like to propose to rename <create-subscription> to simply
<subscribe> in draft-ietf-netconf-notification-04.txt as it is shorter
nice verb that matches well with other protocol verbs (lock, unlock,
commit, validate, ...). I know, this is cosmetics and not really
important, but I thought I mention my preference anyways. ;-)

/js

-- 
Juergen Schoenwaelder		 International University Bremen
				 (Jacobs University Bremen as of Spring 2007)
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 13 Nov 2006 07:22:23 -0800

> important, but I thought I mention my preference anyways. ;-)

I like <subscribe> better, but neither name actually describes
what this particular verb does.

We have a "streams" model, not really a "subscribe" model.
(This is by WG choice.)  In Phil's draft the verb is called <get-syslog-events>.
IMO, the name <start-notifications> best describes this RPC method.

> /js

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 13 Nov 2006 17:55:39 +0100

> IMO, the name <start-notifications> best describes this RPC method.

You subscribe to a stream - sounds quite natural to me.

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 13 Nov 2006 08:57:54 -0800

> You subscribe to a stream - sounds quite natural to me.

ok - it isn't that important.

Actually, <get-notifications> is probably better because
it covers subscribe and replay modes.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 13 Nov 2006 13:24:50 -0800

Phil Shafer wrote:
> Andy Bierman writes:
> But it's not <get>ting them, since they aren't returned immediately.
> It's <start>ing them, or <subscribe>ing to them.  <start> is odd
> too, since there's no <end>, so I'd lean toward <subscribe>, even
> though it's not really a pub/sub model anymore.
> 
> And I guess that's the thing that still bugs me, that it's like a
> pub/sub model without the pub/sub.
> 

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.
(Next year will we have to add the 'publish' half of the model
because that's what is expected when this terminology is used?)

I ran into the same thing wrt/ the term 'transaction'
as used within NETCONF vs. what it means in database terminology.

The verb <subscribe> is fine with me.  Maybe someday a <publish> verb
will be added (but not today ;-).

> I keep thinking that we had two drafts at the interim meeting, one
> simple with few features, and one complex with many features.  But
> it feels like we walked away with a mixture that has most of the
> complexity of the complex one combined with most of the features
> of the simple one.  I know that last afternoon of the interim was
> a whirlwind, but I'm worried we somehow lost the better parts of
> both drafts.

(This is why I wanted you to co-author the RFC. !!!)
Specifically, what needs to be changed?

I noticed that (although undocumented) the <get-syslog-streams> RPC
had a lot more detail in it, such as the <recording/> attribute.
The current stream element doesn't have much in it at all.
How about a list of attributes we should have?

Some changes were made at the WG meeting, and draft minutes
will be done this week.  The 'stopTime' parameter was put back,
and the 'filter' AND 'namedProfile' has been changed to
a choice (OR instead of AND).

> Thanks,
>  Phil

Andy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 13 Nov 2006 15:26:56 -0500

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Mon, 13 Nov 2006 16:41:35 -0500

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

>a choice (OR instead of AND).

Excellent.  Both sound reasonable.  I'll wait to read the
notes before commenting further.

Thanks,
 Phil

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 13 Nov 2006 21:10:43 +0100

> it covers subscribe and replay modes.

To me, subscribing to a stream is a fair summary of the action taken.
Why should the verb indicate that streams have different properties?
How does <get-notifications> indicate that you might get notifications
replayed?

Back in the days when Usenet news were popular, you subscribed to a
newsgroup and depending on the storage capacity of your news server,
you would either get access only to new postings only or also to the
still known old postings. I think we are doing exactly the same here
and since I am old fashioned I like to use the same verb for this
"subscribe" action.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 13 Nov 2006 23:34:36 +0100

> the method names.  It can't help but be confusing.

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

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.

/js

---

From: Phil Shafer <[email-masked]>
Date: Tue, 14 Nov 2006 08:26:07 -0500

Andy Bierman writes:
>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.

Yup, exactly.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 13 Nov 2006 18:39:40 -0800

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

>                              |  <create-subscription>    |

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

Andy