IETF Logo Mail Archive

RE: IPCOMP and Tunnel Mode

Paul Koning <pkoning@xedia.com> Fri, 21 August 1998 15:00 UTC

Return-Path: pkoning@xedia.com
Received: from bubbuh.cisco.com (bubbuh.cisco.com [198.92.30.35]) by ftp-eng.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA20066 for <ippcp-archive-file@ftp-eng.cisco.com>; Fri, 21 Aug 1998 08:00:21 -0700 (PDT)
Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88]) by bubbuh.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id HAA14642 for <ippcp@external.cisco.com>; Fri, 21 Aug 1998 07:59:42 -0700 (PDT)
Received: from proxy1.cisco.com (proxy1.cisco.com [192.31.7.88]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id IAA26842 for <ippcp@external.cisco.com>; Fri, 21 Aug 1998 08:01:14 -0700 (PDT)
Received: (from smap@localhost) by proxy1.cisco.com (8.8.7/8.8.5) id HAA19702 for <ippcp@external.cisco.com>; Fri, 21 Aug 1998 07:59:38 -0700 (PDT)
Received: from relay3.uu.net(192.48.96.8) by proxy1.cisco.com via smap (V2.0) id xma019694; Fri, 21 Aug 98 14:59:32 GMT
X-SMAP-Received-From: outside
Received: from xedia.com by relay3.UU.NET with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQfdkd27575; Fri, 21 Aug 1998 10:58:38 -0400 (EDT)
Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA28282; Fri, 21 Aug 98 10:58:11 EDT
Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA18166; Fri, 21 Aug 1998 10:58:39 -0400
Date: Fri, 21 Aug 1998 10:58:39 -0400
Message-Id: <199808211458.KAA18166@tonga.xedia.com>
From: Paul Koning <pkoning@xedia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: tjenkins@TimeStep.com
Cc: shacham@cisco.com, ipsec@tis.com, ippcp@external.cisco.com
Subject: RE: IPCOMP and Tunnel Mode
References: <319A1C5F94C8D11192DE00805FBBADDF32A41B@exchange.timestep.com>
X-Mailer: VM 6.34 under 20.3 "Vatican City" XEmacs Lucid
Content-Transfer-Encoding: 7bit

Tim,

I might conceivably agree that your proposal is better than what's in
the spec if it had come in a year ago.  But given the state of the
spec, and the fact that numerous people have already implemented
what's specified with no trouble, I see no sense at all in pursuing
what, at best, might be a very minor optimization for some
implementations and a minor pessimization for others.

	paul

v2.23.0 | Report a Bug | By Email