Re: Vendor Private Extension

Curtis Villamizar <curtis@ans.net> Mon, 17 July 1995 16:06 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa05732; 17 Jul 95 12:06 EDT
Received: from [204.249.96.18] by IETF.CNRI.Reston.VA.US id aa05728; 17 Jul 95 12:06 EDT
Received: from maelstrom.acton.timeplex.com (maelstrom.nexen.com [204.249.97.5]) by nexen.nexen.com (8.6.12/8.6.12) with ESMTP id LAA04000; Mon, 17 Jul 1995 11:47:59 -0400
Received: (from root@localhost) by maelstrom.acton.timeplex.com (8.6.12/8.6.12) id LAA01899 for rolc-out; Mon, 17 Jul 1995 11:41:40 -0400
Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.acton.timeplex.com (8.6.12/8.6.12) with ESMTP id LAA01890 for <rolc@nexen.com>; Mon, 17 Jul 1995 11:41:36 -0400
Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by nexen.nexen.com (8.6.12/8.6.12) with ESMTP id LAA03817 for <rolc@nexen.com>; Mon, 17 Jul 1995 11:41:34 -0400
Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.6.12/8.6.9) with ESMTP id LAA00550; Mon, 17 Jul 1995 11:34:19 -0400
Message-Id: <199507171534.LAA00550@brookfield.ans.net>
To: Telford001@aol.com
cc: tlb@eecs.harvard.edu, rolc@nexen.com
Reply-To: curtis@ans.net
Subject: Re: Vendor Private Extension
In-reply-to: Your message of "Sat, 15 Jul 1995 07:41:25 EDT." <950715074124_115396157@aol.com>
Date: Mon, 17 Jul 1995 11:34:17 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Curtis Villamizar <curtis@ans.net>
X-Orig-Sender: owner-rolc@nexen.com
Precedence: bulk
X-Info: Submissions to rolc@nexen.com
X-Info: [Un]Subscribe requests to rolc-request@nexen.com
X-Info: Archives for rolc via ftp://ietf.cnri.reston.va.us/ietf-mail-archive/rolc/

> Vendors create differences between their products and the
> competition in order to give customers a reason to choose
> their product over the competition's product.  The vendor
> private extension must express such differences.  It
> cannot possible be standard across all the vendor products.
> 
> Joachim Carlo Santos Martillo Ajami


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.

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.

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.

Curtis