Re: [tcpm] IANA TCP options registry ... policy amendments?

Lars Eggert <lars.eggert@nokia.com> Thu, 01 April 2010 13:49 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 0028D3A6808 for <tcpm@core3.amsl.com>; Thu, 1 Apr 2010 06:49:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.277
X-Spam-Level:
X-Spam-Status: No, score=-5.277 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 t3BROyuz49+J for <tcpm@core3.amsl.com>; Thu, 1 Apr 2010 06:49:28 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 9C6D33A6912 for <tcpm@ietf.org>; Thu, 1 Apr 2010 06:49:19 -0700 (PDT)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o31Dn1uZ031811; Thu, 1 Apr 2010 08:49:51 -0500
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 16:49:39 +0300
Received: from mgw-sa02.ext.nokia.com ([147.243.1.48]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 16:49:38 +0300
Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.ext.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o31Dnb71017907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Apr 2010 16:49:37 +0300
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.95.3 at fit.nokia.com
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: multipart/signed; boundary="Apple-Mail-89--235210553"; protocol="application/pkcs7-signature"; micalg="sha1"
From: Lars Eggert <lars.eggert@nokia.com>
In-Reply-To: <201004011207.OAA28159@TR-Sys.de>
Date: Thu, 01 Apr 2010 16:49:25 +0300
Message-Id: <21169863-7EB5-4A36-AEAD-59A8AA543BAF@nokia.com>
References: <201004011207.OAA28159@TR-Sys.de>
To: ah@tr-sys.de
X-Mailer: Apple Mail (2.1078)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.fit.nokia.com [0.0.0.0]); Thu, 01 Apr 2010 16:49:26 +0300 (EEST)
X-OriginalArrivalTime: 01 Apr 2010 13:49:38.0820 (UTC) FILETIME=[2C18A440:01CAD1A2]
X-Nokia-AV: Clean
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] IANA TCP options registry ... policy amendments?
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, 01 Apr 2010 13:49:29 -0000

Hi,

On 2010-4-1, at 15:07, ah@tr-sys.de wrote:
> Thus the following questions arise:
> 
> (1)  Should we take this opportunity to add more experimental
>     code points for TCP Option Kinds ?

no. If we allocate them for shared use, people will just use them and ship code using them, like they did in the past. Nothing is gained.

> (2)  Should we allow time-limited code point assignments for
>     experiments that only make sense if conducted with many
>     participants?
>     (IANA has reported that they are ready to support such
>     timed transitions in registries.)

Whether the registry contents time out or not is irrelevant. What would need to happen is that people need to stop running the code that uses the allocation when the experiment terminates, which is impossible to guarantee in practice, and so collisions aren't prevented by this. It just creates more IANA overhead.

> (3)  Combined idea: reserve an additional range of, say, 16 code points
>     for use in IESG-approved experiments (thus no change to RFC 2780!)

We don't need to assign a range for this - the IESG can *already* assign TCP option numbers for Experimental uses. The tcpct draft was written exactly to ask for such an assignment.

>     with a 2-year timeout that can be increased once by the same amount
>     of time *iff* the experiment has lead to follow-up work in an IETF
>     working group targetting Standards Track.  These code points would
>     be recycled in a circular manner.

See above for why the timeout doesn't work.

Lars