1) Define a data model for all the parameters that control/monitor
the notification subscription, so that it can also be used by the
agent without any manager subscription. I.e., a table indexed by
a name string containing one 'row' per parameter set. A separate
table for reusable filters is also needed.
A notification target table is also needed which is completely
independent of the session-subscription API. Parameters such
as the notification receiver address, user name, and user credentials
need to be included to configure a traditional notification
generation application.
2) Use standard operations such as <edit-config> to manipulate
all notification parameters, even for changing profiles in use.
<create-subscription> and all other special RPCs go away.
3) A new special RPC <start-notifications> is used
for a manager to start receiving notifications.
There is no subscription ID because there is only one
stream of notifications on this session, which can be changed
by editing the configuration.
The <stop-notifications> RPC is used to tell the agent to
cease notification generation for the session.
4) There is no real need for <suspend> and <resume> because
the parameters passed in <start-notifications> are trivial.
5) mixed-mode vs. endless-RPC is very problematic.
I could live with mixed-mode, but I don't want
the WG coming back next year asking for a lot
of complicated hacks to deal with the horrible
operational characteristics of mixed-mode.
The answer will be "don't mix operations and notifications
if you are not prepared to deal with the delays or the lost
notifications."
We should not compromise for the sake of a compromise.
What I am interested in is to have an easy mechanism to request that
notifications are directed to a given session (by default 'this'
session if we allow mixed content) and to have that request bound to
the lifetime of the session. In other words, I am thinking of a
subscription which establishes operational state rather than a change
of the configuration of the device and hence <edit-config> might not
be the primitive of choice.
You are looking for ways to configure persistent notificiation
receivers and I agree that this is essentially a configuration change
and so <edit-config> seems to be the appropriate primitive to use.
I think the first decision to take is whether the WG wants to support
both, one, or none of the use cases.