Re: Vendor Private Extension

Trevor Blackwell <tlb@eecs.harvard.edu> Fri, 14 July 1995 22:18 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06997; 14 Jul 95 18:18 EDT
Received: from [204.249.96.18] by IETF.CNRI.Reston.VA.US id aa06993; 14 Jul 95 18:18 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 PAA01027; Fri, 14 Jul 1995 15:20:39 -0400
Received: (from root@localhost) by maelstrom.acton.timeplex.com (8.6.12/8.6.12) id PAA19780 for rolc-out; Fri, 14 Jul 1995 15:15:37 -0400
Received: from nexen.nexen.com ([204.249.96.18]) by maelstrom.acton.timeplex.com (8.6.12/8.6.12) with ESMTP id PAA19770 for <rolc@nexen.com>; Fri, 14 Jul 1995 15:15:33 -0400
Received: from chardonnay.eecs.harvard.edu (chardonnay.eecs.harvard.edu [140.247.60.66]) by nexen.nexen.com (8.6.12/8.6.12) with ESMTP id PAA00835 for <rolc@nexen.com>; Fri, 14 Jul 1995 15:15:31 -0400
Received: from localhost (localhost [127.0.0.1]) by chardonnay.eecs.harvard.edu (8.6.12/8.6.12) with SMTP id OAA07561 for rolc@nexen.com; Fri, 14 Jul 1995 14:42:33 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Trevor Blackwell <tlb@eecs.harvard.edu>
Message-Id: <199507141842.OAA07561@chardonnay.eecs.harvard.edu>
X-Authentication-Warning: chardonnay.eecs.harvard.edu: Host localhost didn't use HELO protocol
To: rolc@nexen.com
Subject: Re: Vendor Private Extension
In-reply-to: Your message of "Fri, 14 Jul 95 10:35:48 PDT." <9507141735.AA15716@milliways-le0>
Date: Fri, 14 Jul 95 14:42:33 -0400
X-Mts: smtp
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/

Recent discussion of vendor private extensions suggest that they have
evolved from being a mechanism for future contingencies, to an
important feature that people want to use right away.

If you have concrete ideas for uses of VPX at this point in time, then
maybe they should go directly into the spec. Or at least it might
prompt other groups to realize they require similar functionality.

Could relevant parties summarize their plans for this field to the
list?

--
Trevor Blackwell         tlb@eecs.harvard.edu          (617) 495-8912