Subject: (unofficial issue 2) Subscription versus never-ending command

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 27 Mar 2006 11:27:25 -0500

hi

I said in the wg meeting that I would start capturing some of the pros
and cons of the subscription method versus the never-ending command
design alternative that some have suggested. This will hopefully allow
us to evaluate them less subjectively. This list is from the meeting,
the mailing list and some off-line discussions we had in Dallas.

1. Subscription

Similar to what is done in Oasis Notifications and SIP, the user
specifies which notifications are of interest and receives a reply
indicating whether or not the subscription command was successful. Then
subscriptions are sent asynchronously across the connection. The user
can modify the subscription, cancel it or start additional
subscriptions. They are also free to execute other synchronous commands
if it makes operational sense to do so on the same connection.

Pros:

- Allows you to modify the subscription without losing any notifications
- Allows you to have more then one subscription at a given time
(including short-lived ones)
- All the information to be easily processed as soon as it arrives since
each notification is a complete document
- Future proofing - easily supports event replay subscriptions
- Conserves connections
- Easily supports operator/manager use cases
- Supporting multiple subscriptions mirrors some popular CLIs

Cons: 

- Notifications could be blocked by poorly chosen asynchronous commands
- Implementations need to perform more tasks on a single connection,
instead of separating them out into separate ones.

2. Never-ending command. A user sends a command which specifies which
notifications are of interest and waits for a reply. Reply will come in
the form of notifications at some point in the future. User is unable to
directly modify the subscription, cancel the command or execute other
commands.

Pros: 

- Simple for the server to implement (see below)
- On a single connection, the server only has to either send
notifications or listen for commands
- There is also less functionality to provide
- Only blocked by other notifications (not by other commands)

Cons:

- Eats up more connections
- harder for the client to use (See below)
- Can't be modified ( modifying subscription without losing
notifications requires creating a new connection, creating a new
notification command, start receiving notifications, remove duplicates
then kill the old command)
- Can't be processed by document oriented XML parsers
- Unclear how you would cancel the subscription
- Unclear how to tell if the command was not successful

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada

--
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, 27 Mar 2006 09:22:43 -0800

> hi

I like the publish/subscribe model, but that is not
what is in the draft.  IMO the classifications and content
of each notification should be defined independently
of this document.

This document should just define how a standard NETCONF agent
publishes a set of IANA-registered event-type URIs to indicate it can
meet all the requirements specified for generating those event types.

This document must also specify how a manager subscribes/unsubscribes
to receive an arbitrary subset of those event types.

(IMO that is all the filtering that is needed, but if
the WG really needs to make this more complicated, then fine.)

The only real difference in your list is:
  - the ability to change the event type subscription from
    the same session.
  - the ability to use the same session for operations and
    notifications.

The trade-off is massive complexity -- how massive the complexity
and how valuable these features are in return is quite debatable.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 27 Mar 2006 13:41:13 -0800

Hi -

I prefer a subscription-based approach.

However, I dislike the specific subscription approach proposed.
I would prefer a more general approach that separated the
subscription supervision from the data transfer.  All of the 
"cons" of the subscription-based proposal in Sharon's summary
are consequences of requiring the notification flow to happen on
the same connection as was used to create the subscription.

An approach in which a subscription object is treated like any other
chuck of configuration data would not suffer from those problems.
This is one of the few things that CMIP and SNMP do in similar ways.
I think binding a subscription to a specific connection, rather than to
the subscriber's identity, would be an architectural mistake.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 27 Mar 2006 14:07:36 -0800

> the subscriber's identity, would be an architectural mistake.

You read my mind.
I am thinking, why isn't there a table to configure
notification preferences and targets on the agent
instead of this mixed channel or even endless RPC stuff?

Why isn't this just more config data like in SNMP?

All these specialized RPCs are overkill.
Disregard for security and access control will
never get past me or the IESG.

If the preference table entry (indexed by profileName for Sharon ;-)
is a static schema-based configuration instead of session-set parameters,
it is much easier to simply reuse existing architecture than invent
a new one which includes special access control for notifications.

I agree with you that connection-based instead of user-based is a mistake.
In the current draft the agent doesn't decide,
the manager decides with the RPC parameters.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 28 Mar 2006 11:49:39 +0200

Do we allow one user to use multiple subscriptions ? I would say yes.

If we connect the notification subscription strictly to a user identity we force the user 
to specify security data multiple times to be able to use multiple subscriptions. Is this 
our aim or am I missing something ? (In our management system different functional parts 
are interested in different notifications, but I see no need for a security point of view 
to require multiple user identities for them.)

Balazs

Andy Bierman wrote:
>> subscription supervision from the data transfer.  All of the "cons" of 
>> the subscription-based proposal in Sharon's summary

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 29 Mar 2006 11:31:48 -0800

Hi -

> From: "Balazs Lengyel" <[email-masked]>
> To: "Netconf (E-mail)" <[email-masked]>
> Sent: Tuesday, March 28, 2006 1:49 AM
> Subject: Re: (unofficial issue 2) Subscription versus never-ending command
>

Of course.
 
> to specify security data multiple times to be able to use multiple subscriptions. Is this 

User identity is obviously not the only interesting attribute of a subscription.
Think how SNMP notification subscriptions work.  The user identity is necessary
for access control (both of the subscription itself as well as in constraining what
is permitted to be sent).  One also needs information describing *where* the
information should be sent on behalf of that user, among other things.

> to require multiple user identities for them.)
...

No disagreement.  Indeed, this is yet another argument against binding the
subscription to a connection.  Consider the scenario where there are multiple
"interested" systems or applications, and the devices to be managed are
intermittently reachable.  Is it better for the managed device to establish a
connection if/when needed, or have the applications futilely attempting to make
connections to all the devices that happen to be unreachable at the moment?
Think netconf for cellphones and PDAs.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Wed, 29 Mar 2006 15:40:49 -0800

>> Do we allow one user to use multiple subscriptions ? I would say yes.

Do you mean multiple subscriptions per session?
If so I don't agree.  (Note that this is not the
same as a single subscription + modify-subscription feature.)

It might make sense to support multiple subscriptions
per session if netconf had multi-user sessions, but it doesn't.
Why (in the name of Good Engineering) would you ever want
the agent to spend lots of time classifying events, and
sending multiple copies of the same notification on the
same single-user session?

This isn't an snmp notification or syslog demuxer,
so why try to turn it into one?

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 29 Mar 2006 15:50:06 -0800

Hi -

The context of the quoted message was the discussion of why binding
subscriptions to sessions doesn't make sense to some of us.  In that
context, I have trouble making sense of Andy's questions.  Indeed, they
seem to be hinting at further reasons why binding subscriptions to
sessions may be undesirable.

Randy