[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: vendor capabilities - is this actually a good idea?
- To: "EOS WG (email@example.com)" <firstname.lastname@example.org>
- Subject: Re: vendor capabilities - is this actually a good idea?
- From: "David L. Partain" <email@example.com>
- Date: Thu, 05 Apr 2001 15:00:45 -0400
- Delivery-date: Thu, 05 Apr 2001 12:00:54 -0700
- Envelope-to: firstname.lastname@example.org
I know I'm gonna get whacked for this, but...
> Glenn's presentation this morning mentioned the idea of letting
> the vendors define their own extensions to SNMP and that
> we include a method in the capabilities MIB to handle
> this situation.
> Do we really want to do this?
I am, until otherwise convinced, strongly opposed to this idea.
In my opinion, EOS is about doing evolutionary standards-based
change to the management framework, changes that are going to
affect the guts of the protocol engine itself. I don't think
this is the purview of the vendor community and don't think
that EOS should be used as a way of opening the floodgates to
a morass of of non-interoperable SNMP engines from company X,
Y, Z, ad infinitum.
There are currently 9174 companies with a branch under
enterprises, indicating some potential interest in SNMP.
Do we really want to open the doors for 9174 companies to
make their own proprietary changes to the protocol engine?
I don't think so.
> This sounds like something that
> will make multi-vendor management a lot more complicated.
I completely agree. EOS's WG changes alone are going to make
life a bit more difficult (but better :-)).
> The enhancements that EOS is proposing will be defined in RFCs.
> Where will vendor extensions be properly defined? Is there enough
> benefit in supporting vendor extensions to off-set the management
Assuming success in our effort to define the appropriate
mechanisms for further standards-based extensions, I think the
onus should be on the vendor community to move the standards
forward to include the changes that they want/need.
I think vendor differentiation in managed objects is great
and necessary, but I don't think that changes in the protocol
engine should be a way for vendors to differentiate themselves.
With kind regards,