[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-ietf-netconf-notification-01.txt
On Wed, May 03, 2006 at 02:31:31PM -0700, Andy Bierman wrote:
> I think a combined approach would be acceptable:
>
> 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.
--
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany
--
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/>