Subject: RE: manager subscription model for notifications: usage survey

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Mon, 1 May 2006 20:23:33 +0300

> -----Original Message-----
> From: Andy Bierman [mailto:[email-masked]] 

> 
> IMO, this doesn't make engineering sense, because the cost of 
> development and deployment is so much higher for embedded 
> systems than workstations.  (That's probably why NE vendors 
> don't offer this feature today.)
> 
> 

Is it really much more complex to implement than the SNMP-TARGET-MIB and
SNMP-NOTIFICATION-MIB? 

Dan

--
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: Andy Bierman <[email-masked]>
Date: Mon, 01 May 2006 11:26:44 -0700

> Is it really much more complex to implement than the SNMP-TARGET-MIB and

Maybe about the same, but who is using the full capability
of these MIBs today?  Some complexity is due to the lack
of nested data structures in SMI, which is not a problem in XML.
I don't think the netconf configuration of a notification
generator application would need to be as complex.

My biggest concern is one of actual deployment.
If NE vendors are not inclined to offer this feature now,
then why is it all of a sudden going to become a great
idea when it shows up in a netconf RFC?

I'm not saying this is one of those "must-have features nobody
ever heard of" that Phil mentioned.  I'm saying if this was
really useful, then vendors would already be doing it in some
form, in some products.  Some WG members have told me "well,
the vendors don't know what they're doing.  We need do what's
right anyway."  IMO, this is the kind of thinking that got us into
a disconnect with the operator community in the first place.

> Dan

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 1 May 2006 21:12:32 +0200

> Is it really much more complex to implement than the SNMP-TARGET-MIB and

You are right that the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB
basically allow subscriptions (and they are pretty complicated to use
with all the features that went in). These MIBs, however, have two
problems that are important if you want to use them:

a) Notification targets can't be bound to a "session" nor are there any
   timers which cause targets to expire if the timer is not refreshed.
   Hence, garbage collection of dead dynamic subscriptions is a mess.
   This is an engineering problem which could be fixed easily by
   adding the missing capability to the standards.

b) Most default installations are simply read-only and it typically
   requires to use the CLI to add a subscription. Given the lack of
   standards in this space, you can't really write interoperable code
   that actually works in operational networks. This is mainly a
   deployment problem and could be solved by agreeing on common access
   control setups that actually allow more useful work to happen (but
   again will take a long time to become effective).

By introducing a subscription mechanism which uses additional protocol
verbs rather than a writable data model, you kind of automatically
make it much more likely that neither a) nor b) becomes a problem.

Subscription operations make management applications that like to
subscribe to notifications easier to write and I believe this is a
feature and not a bug.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: "David T. Perkins" <[email-masked]>
Date: Tue, 2 May 2006 09:59:10 -0700 (PDT)

HI,

Excellent description of the problems with the current SNMPv3
notification distribution system, and why a change would
increase interoperability and usability! 

> subscribe to notifications easier to write and I believe this is a
Regards,
/david t. perkins