[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Sharon Chisholm wrote:

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



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








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