Randy Presuhn wrote:
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.
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.
Randy
Andy
--
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/>