(unofficial issue 2) Subscription versus never-ending command

["Sharon Chisholm" <schishol@nortel.com>]

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