Subject: RE: requirement: agent initiated session support

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 3 Apr 2006 10:01:41 -0400

<Andy>
>> 2) get rid of all the parameters in the start-notifications
>>    or modify-subscription except the profileName (index)
>>
>> This way agents and managers can both share the profiles
>> and the manager won't reenter the same data in the most complex 
>> manner possible every time.  I can configure the agent to connect to 
>> notification receiver X using profile Y.  The manager can just 
>> subscribe using profile Y.
>>
>> (An agent may not allow a profile in use to be modified.)
</Andy>

As a manager who actually supported Notification subscription in SNMP, I
hated the pre-configured approach for two reasons:

1) It was way too complicated. It was spread out over 100 tables with
far too many options. Even the case you used 99 times out of 100 was a
lot of work. You would get it to work for some devices, then find one
where it didn't work and realize that you forgot to create a row in yet
another table. I like the idea of command-line options since it acts as
a deterrent from over-engineering the subscription model

2) It was persistent. I had to always check if I was already set up to
get notifications from the box. This was more annoying then it sounds.

Plus, in a connection-oriented model, would we have the idea of
subscriptions that were there, but not active for when the underlying
session died?

Sharon

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "David T. Perkins" <[email-masked]>
Date: Mon, 3 Apr 2006 08:47:57 -0700 (PDT)

HI,

In addition to the points below, one must have "admin authorization"
to subscribe to receive notifications. Thus, I really believe
that there are two types of notification receivers -
1) those that run all the time and are primarily for storing
   a record of events for later analysis
2) those that are transient and are run when an application
   is changing the config or initiating and action

I believe that there is a need for both, and it seems like
the conflict has been over trying to choose either #1 or #2
instead of understanding the uses cases for each and making
it easy for each to be used where they are appropriate.

Enjoy,
/david t. perkins

---

From: Eliot Lear <[email-masked]>
Date: Tue, 04 Apr 2006 09:25:23 +0200

>    is changing the config or initiating and action

How about:

  3) Those that run all the time and keep track of inventory changes?

Eliot