Re: vendor capabilities - is this actually a good idea?

["David L. Partain" <partain@cs.utk.edu>]

Greetings all,

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 
> headache?

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,

David Partain

--
David Partain
partain@cs.utk.edu