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

"Sergio Freire" <etfreire@ua.pt> Tue, 12 August 2008 15:52 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 B2A8F3A69E4; Tue, 12 Aug 2008 08:52:51 -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 062553A69E4 for <tcpm@core3.amsl.com>; Tue, 12 Aug 2008 08:52:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 G30s0CPYaNlN for <tcpm@core3.amsl.com>; Tue, 12 Aug 2008 08:52:48 -0700 (PDT)
Received: from cgpmail.ua.pt (frontend-1.servers.ua.pt [193.136.173.2]) by core3.amsl.com (Postfix) with ESMTP id 0A69628C0FA for <tcpm@ietf.org>; Tue, 12 Aug 2008 08:52:47 -0700 (PDT)
Received: from [194.65.138.120] (account etfreire@ua.pt HELO portsfreire) by frontend1.cgpmail.ua.pt (CommuniGate Pro SMTP 5.1.13) with ESMTPSA id 118356316; Tue, 12 Aug 2008 16:52:48 +0100
From: Sergio Freire <etfreire@ua.pt>
To: 'Lars Eggert' <lars.eggert@nokia.com>
References: <396556a20808111035s2b974233o1e9d3671e82e3350@mail.gmail.com> <000001c8fbfe$0dba0960$292e1c20$@pt> <396556a20808111617n622aceabn62db0d55b25ae712@mail.gmail.com> <000301c8fc81$8e02d470$aa087d50$@pt> <D26754AE-6FF0-4F5A-A05D-2DD996E22168@nokia.com>
In-Reply-To: <D26754AE-6FF0-4F5A-A05D-2DD996E22168@nokia.com>
Date: Tue, 12 Aug 2008 16:52:46 +0100
Message-ID: <000401c8fc93$776578f0$66306ad0$@pt>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acj8inw7hI505TsMTauxRltXZD5/TQACBDlQ
Content-Language: pt
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-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

Hi Lars,
Of course, I know that but thanks for clarifying :)
We used a value just for experimentation purposes only.
What Adam was saying is that TCP option kind values 254 and 255 were
reserved to specify a length indicator, that's what I understood. But I
think he meant 253 and 254. Anyway, these kind values seem to not be
reserved for a specific purposed... instead, they are reserved for
experimentation purposes. Also, just to clarify this. :)
Regards,
Sergio



-----Original Message-----
From: Lars Eggert [mailto:lars.eggert@nokia.com] 
Sent: terça-feira, 12 de Agosto de 2008 15:48
To: ext Sergio Freire
Cc: 'Adam Langley'; andre.zuquete@ua.pt; tcpm@ietf.org
Subject: Re: [tcpm] SYN/ACK Payloads, draft 01

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