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
- Vendor Private Extension James Luciani
- Re: Vendor Private Extension Bruce Cole
- Re: Vendor Private Extension James Luciani
- Re: Vendor Private Extension Bruce Cole
- Re: Vendor Private Extension James Luciani
- Re: Vendor Private Extension Bruce Cole
- Re: Vendor Private Extension James Luciani
- Re: Vendor Private Extension Andrew Smith
- Re: Vendor Private Extension Trevor Blackwell
- Re: Vendor Private Extension Telford001
- Re: Vendor Private Extension Curtis Villamizar
- Re: Vendor Private Extension Tony Li
- Re: Vendor Private Extension Curtis Villamizar
- Re: Vendor Private Extension Tony Li
- Re: Vendor Private Extension Trevor Blackwell