[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: vendor capabilities - is this actually a good idea?
- To: firstname.lastname@example.org
- Subject: Re: vendor capabilities - is this actually a good idea?
- From: Jon Saperia <email@example.com>
- Date: Thu, 19 Apr 2001 09:59:42 -0400
- Delivery-date: Thu, 19 Apr 2001 07:00:46 -0700
- Envelope-to: firstname.lastname@example.org
Forgive the lateness of this posting. Attached is a thread that was
sent to this list by David Partain a while ago.
The issue is should vendors be allowed/enabled to make extensions to the
protocol? It is one thing for a standards body to extend base
technology, the eos work, and quite another to facilitate vendor
>From an operational perspective, this would significantly reduce vendor
interoperability. From an equipment vendor perspective, they would drift
toward more and more to vendor specific approaches - we have strong
evidence for this in the large number of objects that exist in private
MIB Modules that do essentially the same thing as objects in standards
track modules. People building management software would have even more
of a dilemma than they presently do in terms of where to invest. They
would have to spend more time dealing with vendor protocol differences
and less time writing code that actually helped people manage services
I agree with the points David Partain made. The proposed extensibility
is really counter productive economically, technically and
------------------------- Forwared mail:
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,
------- End of Forwarded Message