Re: [tcpm] SYN/ACK Payloads, draft 01

Lars Eggert <lars.eggert@nokia.com> Tue, 12 August 2008 14:48 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5E973A6B50; Tue, 12 Aug 2008 07:48:21 -0700 (PDT)
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 91EDE3A6B50 for <tcpm@core3.amsl.com>; Tue, 12 Aug 2008 07:48:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.463
X-Spam-Level:
X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 nhmTLDh6YouO for <tcpm@core3.amsl.com>; Tue, 12 Aug 2008 07:48:16 -0700 (PDT)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 22A333A69DD for <tcpm@ietf.org>; Tue, 12 Aug 2008 07:48:15 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7CEluoO024063; Tue, 12 Aug 2008 17:48:03 +0300
Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 17:47:58 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 17:47:46 +0300
Received: from net-204.nrpn.net ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Aug 2008 17:47:45 +0300
Message-Id: <D26754AE-6FF0-4F5A-A05D-2DD996E22168@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
To: ext Sergio Freire <etfreire@ua.pt>
In-Reply-To: <000301c8fc81$8e02d470$aa087d50$@pt>
Mime-Version: 1.0 (Apple Message framework v926)
Date: Tue, 12 Aug 2008 17:47:39 +0300
References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <000001c8fbfe$0dba0960$292e1c20$@pt> <396556a20808111617n622aceabn62db0d55b25ae712@mail.gmail.com> <000301c8fc81$8e02d470$aa087d50$@pt>
X-Mailer: Apple Mail (2.926)
X-OriginalArrivalTime: 12 Aug 2008 14:47:46.0017 (UTC) FILETIME=[6203ED10:01C8FC8A]
X-Nokia-AV: Clean
Cc: 'Adam Langley' <agl@imperialviolet.org>, andre.zuquete@ua.pt, tcpm@ietf.org
Subject: Re: [tcpm] SYN/ACK Payloads, draft 01
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: <https://www.ietf.org/mailman/private/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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

On 2008-8-12, at 16:44, ext Sergio Freire wrote:
> Sergio: Well I don't think that is exactly correct. Looking athttp://www.iana.org/assignments/tcp-parameters/ 
>  and RFC3692 and RFC4727, we can see that the reserved kind values  
> are 253 and 254. These two are used for testing purposes as RFC3692  
> (I think for general testing purposes, not for a specific purpose).  
> So, a new option would have to be assigned to specify a way of  
> extending the available space for TCP options. In a first phase I  
> guess 253 or 254 could be used for that since they are "generic", if  
> what I've said earlier is correct.

If you look at the URL you posted, you'll see this bit: "Registration  
Procedures: IESG Approval or Standards Action"

That means that you MUST obtain a number through one of these two  
procedures (see RFC5226). You MUST NOT simply grab an unassigned one.

Adam is correct that for limited experimentation, you should use 253  
or 254, as per RFC4727. To go beyond that, you MUST register an option  
number, either via IESG Approval or a Standards Action.

Lars
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm