Re: [tcpm] I-D Action:draft-eggert-tcpm-historicize-01.txt

Lars Eggert <lars.eggert@nokia.com> Thu, 17 February 2011 17:42 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 A21373A6CB8; Thu, 17 Feb 2011 09:42:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.694
X-Spam-Level:
X-Spam-Status: No, score=-102.694 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 fqbSuZLoOgsH; Thu, 17 Feb 2011 09:42:39 -0800 (PST)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id 98D8D3A6C6A; Thu, 17 Feb 2011 09:42:39 -0800 (PST)
Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1HHh7J7017188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Feb 2011 19:43:08 +0200
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.96.5 at fit.nokia.com
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/signed; boundary="Apple-Mail-82--317678865"; protocol="application/pkcs7-signature"; micalg="sha1"
From: Lars Eggert <lars.eggert@nokia.com>
In-Reply-To: <CEBCE3CF81D2D441B14B84256C3C46810BD9E5C2@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
Date: Thu, 17 Feb 2011 19:43:04 +0200
Message-Id: <AAAF4BBA-EC7F-4B64-A246-B63318C4C68A@nokia.com>
References: <20110216121501.9756.17896.idtracker@localhost> <CEBCE3CF81D2D441B14B84256C3C46810BD9E173@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> <11AE786E-F8C6-408E-9F1A-863BBFD0BC10@nokia.com> <CEBCE3CF81D2D441B14B84256C3C46810BD9E5C2@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com>
To: Christian Huitema <huitema@microsoft.com>
X-Mailer: Apple Mail (2.1082)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Thu, 17 Feb 2011 19:43:05 +0200 (EET)
X-Nokia-AV: Clean
Cc: "ops-dir@ietf.org" <ops-dir@ietf.org>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>, "Scott O. Bradner" <sob@harvard.edu>
Subject: Re: [tcpm] I-D Action:draft-eggert-tcpm-historicize-01.txt
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: Thu, 17 Feb 2011 17:42:40 -0000

ACK.

I'll leave it to David as the responsible AD to make a call here. As I said, I have no issue removing 1263 from this doc if this is the consensus.

Lars

On 2011-2-17, at 19:35, Christian Huitema wrote:

> I would suggest to leave 1623 alone for now. There may be a  rationale to downgrade it later -- or maybe not. In any case, that rationale is not that it defines unused TCP extensions, and thus it does not belong to the same batch.
> 
> -----Original Message-----
> From: Lars Eggert [mailto:lars.eggert@nokia.com] 
> Sent: Thursday, February 17, 2011 12:57 AM
> To: Christian Huitema
> Cc: tcpm@ietf.org Extensions; ops-dir@ietf.org; Scott O. Bradner
> Subject: Re: [tcpm] I-D Action:draft-eggert-tcpm-historicize-01.txt
> 
> Hi,
> 
> On 2011-2-17, at 9:00, Christian Huitema wrote:
>> I note that the list of RFC includes RFC 1263, "TCP Extensions Considered Harmful." The purpose of the draft is to make some extensions historic. Since RFC 1263 does not define any particular extension, I don't see the point of including it. RFC 1263 is an informational RFC. It provides advice on protocol design, and that advice appears to be just as informational now as it was then. I don't see why we should reclassify it.
> 
> it provides advice on *TCP* protocol design going forward, but the community went the other way. I don't feel strongly about moving it to Historic or not, but someone suggested it (see below).
> 
> Scott Bradner brought this up during his ops-dir review as well:
> 
>> On 2011-2-11, at 4:24, Scott O. Bradner wrote:
>>> I'm not sure why RFC 1263  "TCP Extensions Considered Harmful" should
>>> be included in the list since it seems to me that message of the RFC
>>> is still valid.  But if it is to be included it seems like the
>>> "it is not used" general description does not apply to this RFC and some
>>> specific text should be added to say why it should be made historic
>> 
>> good point. Someone (I can't remember who, might have been Craig Partridge) suggested to include RFC1263 in this list because it argues for an architectural approach which the subsequent TCP evolution with its myriad of options did not follow. (RFC4614 also contains text along those lines.)
>> 
>> I'm adding this text to my working copy:
>> 
>> <xref target="RFC1263"/> ("TCP Extensions Considered Harmful") is somewhat of a special case. Unlike the other RFCs made Historic by this memo, it does not specify a TCP option that failed to see deployment, but argued for a way to evolve TCP forward that the community did not choose to follow.
> 
> Lars