IETF Logo Mail Archive

Re: [tcpm] draft-eggert-tcpm-historicize-00

Lars Eggert <lars.eggert@nokia.com> Tue, 29 June 2010 17:15 UTC

Return-Path: <lars.eggert@nokia.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 139CC3A6C11 for <tcpm@core3.amsl.com>; Tue, 29 Jun 2010 10:15:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.353
X-Spam-Level:
X-Spam-Status: No, score=-6.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+-NOcyxyiG2 for <tcpm@core3.amsl.com>; Tue, 29 Jun 2010 10:15:26 -0700 (PDT)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 0D2103A6C04 for <tcpm@ietf.org>; Tue, 29 Jun 2010 10:15:23 -0700 (PDT)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o5THFSd9025416; Tue, 29 Jun 2010 20:15:28 +0300
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Jun 2010 20:15:27 +0300
Received: from mgw-sa01.ext.nokia.com ([147.243.1.47]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Jun 2010 20:15:27 +0300
Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa01.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o5THFQC6018999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Jun 2010 20:15:26 +0300
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.96.1 at fit.nokia.com
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary="Apple-Mail-25-1024291338"; protocol="application/pkcs7-signature"; micalg="sha1"
From: Lars Eggert <lars.eggert@nokia.com>
In-Reply-To: <5FDC413D5FA246468C200652D63E627A0935F804@LDCMVEXC1-PRD.hq.netapp.com>
Date: Tue, 29 Jun 2010 18:15:18 +0100
Message-Id: <94AE5A53-9C1C-474B-9D8A-ACF2D0FC2842@nokia.com>
References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com><2262C708-DF9A-4DD9-9378-D84C5AF330AC@nokia.com><C304DB494AC0C04C87C6A6E2FF5603DB48105A5A82@NDJSSCC01.ndc.nasa.gov> <0C53DCFB700D144284A584F54711EC580A0CE306@xmb-sjc-21c.amer.cisco.com> <5FDC413D5FA246468C200652D63E627A0935F804@LDCMVEXC1-PRD.hq.netapp.com>
To: "Scheffenegger, Richard" <rs@netapp.com>
X-Mailer: Apple Mail (2.1081)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.fit.nokia.com); Tue, 29 Jun 2010 20:15:20 +0300 (EEST)
X-OriginalArrivalTime: 29 Jun 2010 17:15:27.0315 (UTC) FILETIME=[AB233230:01CB17AE]
X-Nokia-AV: Clean
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, "Anantha Ramaiah (ananth)" <ananth@cisco.com>, "Biswas, Anumita" <Anumita.Biswas@netapp.com>
Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Jun 2010 17:15:44 -0000

Hi,

On 2010-6-25, at 16:07, Scheffenegger, Richard wrote:
> Of course, if RFC1146 could be extended to include algorithms which
> actually "violate" some of the specs of it, but maintain using the same
> TCP options with a new algorithm codepoint, that would be fine with me.
> 
> But this would probably ask for a new RFC obsoliting RFC1146 anyway (in
> effect making it again historic :) ).

yes, that was my thinking too. I don't think we can fix RFC1146 in a way that is backwards compatible, so we might as well make it historic and then decide if we need a new piece of work in this space.

Lars

v2.23.0 | Report a Bug | By Email