Re: Vendor Private Extension

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>om>, Tony Li writes:
> 
> [Catching up on old mail...]
> 
>    I thought this mentality died at least a decade ago when users began
>    in large number avoiding the purchase of products that didn't
>    interoperate with other vendor's products.
> 
> Note that interoperability and private extensibility are not
> necessarily contradictory concepts.  
> 
>    I'd like to point out that there is no provision in any routing
>    protocol to date for "vendor proprietary extensions".  The only thing
>    resembling a vendor proprietary extensions is an enterprise MIB.
>    There are no vendor proprietary IP options, TCP options, etc.
> 
> Well, they're not labelled as such, but that's very much what they
> effectively are.  They are simply options.  There are implementations
> which use unregistered option numbers all over the place.  Usually
> such features are a value-add to the protocol.  Of course, if you'd
> like to stop folks from innovating....
> 
>    I think a field for vendor proprietary extensions should not even
>    appear in NHRP at all.  The protocol should be extensible, but
>    extensions added with new standard attributes.  If some vendor wants
>    to be "better" they can try to build a faster or more stable product
>    and be among the first to implement extensions brought forward in the
>    standards process.
> 
> Sorry, but you are simply ignoring reality here.  If you provide for
> extensibility and don't provide a vendor proprietary mechanism, then
> vendor proprietary extensions will simply go underground _again_.
> Eliminating competition in a free market economy is simply impossible.
> And it has proven to be damn difficult even in a totalitarian regime.
> 
> Tony
> 
> Ob. Disclaimer: No, I am not representing my employer.  And yes, many
> vendors follow the above model.  


Tony,

I was reacting strongly to mail that was suggesting provisions for
extensibility should be modified to better support "vendor proprietary
extensions".

The extensibility in BGP attriobutes and TCP and IP options, etc, are
intended for extensions to be defined by the IETF and is not, and was
never intended for, vendor proprietary extensions.  I was arguing that
the same should remain true of NHRP.

Maybe I didn't clear state that.

Curtis