Re: [tcpm] IANA TCP options registry ...

Lars Eggert <lars.eggert@nokia.com> Thu, 01 April 2010 06:26 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 276313A6950 for <tcpm@core3.amsl.com>; Wed, 31 Mar 2010 23:26:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.936
X-Spam-Level:
X-Spam-Status: No, score=-4.936 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_61=0.6, 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 rwq86DFtefPm for <tcpm@core3.amsl.com>; Wed, 31 Mar 2010 23:26:01 -0700 (PDT)
Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 9DF1D3A6885 for <tcpm@ietf.org>; Wed, 31 Mar 2010 23:26:01 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o316QNgX000728; Thu, 1 Apr 2010 01:26:32 -0500
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 09:26:30 +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 09:26:30 +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 o316QRFR001701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Apr 2010 09:26:27 +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-74--261799666; protocol="application/pkcs7-signature"; micalg=sha1
From: Lars Eggert <lars.eggert@nokia.com>
In-Reply-To: <5FDC413D5FA246468C200652D63E627A08144911@LDCMVEXC1-PRD.hq.netapp.com>
Date: Thu, 1 Apr 2010 09:26:16 +0300
Message-Id: <74EC24B3-8ACF-4C62-9D0C-163CBF911B1B@nokia.com>
References: <201003072316.AAA29042@TR-Sys.de> <5FDC413D5FA246468C200652D63E627A08144911@LDCMVEXC1-PRD.hq.netapp.com>
To: "Scheffenegger, Richard" <rs@netapp.com>
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 09:26:17 +0300 (EEST)
X-OriginalArrivalTime: 01 Apr 2010 06:26:30.0308 (UTC) FILETIME=[441BAE40:01CAD164]
X-Nokia-AV: Clean
Cc: =?iso-8859-1?Q?Alfred_H=CEnes?= <ah@TR-Sys.de>, "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] IANA TCP options registry ...
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 06:26:03 -0000

Hi,

On 2010-4-1, at 8:47, Scheffenegger, Richard wrote:
> Out of curiousity, does anyone know about the to-be assigned option number(s ?) for RFC 5690 (AckCChttp://tools.ietf.org/html/rfc5690).
> 
> Are there two option numbers proposed for that RFC, or will a single option (with the length field being the necessary denominator between AckCC control permitted and AckCC Ratio) suffice?

Section 10 is pretty clear, in that RFC5690 is for limited experimentation only at this time and hence no separate option numbers will be assigned. Experimenters are supposed to use the normal TCP option numbers set aside for general experimentation (253/254) when playing with this proposal:

   No IANA action is needed at this time.  If this document was advanced
   as Experimental or Proposed Standard, then IANA would allocate the
   option numbers for the two TCP options, the ACK Congestion Control
   Permitted option, and the ACK Ratio option.  In such a case, the
   following two lines would be added to the TCP Option Numbers registry
   (maintained by IANA -- http://www.iana.org):

        Kind   Length   Meaning                             Reference
        ----   ------   ---------------------------------   -----------
        TBD1       2    ACK Congestion Control Permitted    [RFCXXXX]
        TBD2       3    ACK Ratio                           [RFCXXXX]

   In the absence of TCP option numbers allocated by IANA, experimenters
   may use the TCP Option Numbers set aside for Experimentation in RFC
   4727 [RFC4727].  As stressed in Section 1 of RFC 3692 [RFC3692], the
   TCP Option Numbers in the experimental range are intended for
   experimentation and testing and not for wide or general deployments;
   these option numbers could be in use by other experimentors for other
   purposes.

Lars