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 thesubscription supervision from the data transfer. All of the "cons" of the subscription-based proposal in Sharon's summaryare 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/>