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

"Scheffenegger, Richard" <> Thu, 01 April 2010 12:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B9B73A6D36 for <>; Thu, 1 Apr 2010 05:53:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.062
X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_61=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CfDHxFTaWfFz for <>; Thu, 1 Apr 2010 05:53:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EA46E3A6CC0 for <>; Thu, 1 Apr 2010 05:41:36 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.51,348,1267430400"; d="scan'208";a="148419845"
Received: from ([]) by with ESMTP; 01 Apr 2010 05:42:07 -0700
Received: from ( []) by (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o31Cg7SL010846; Thu, 1 Apr 2010 05:42:07 -0700 (PDT)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Apr 2010 13:42:07 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 1 Apr 2010 13:42:05 +0100
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [tcpm] IANA TCP options registry ... policy amendments?
Thread-Index: AcrRlBCERjtZXwXAS9KGxj1IaQNHkgAA9XQg
From: "Scheffenegger, Richard" <>
To: =?iso-8859-1?Q?Alfred_H=CEnes?= <>
X-OriginalArrivalTime: 01 Apr 2010 12:42:07.0531 (UTC) FILETIME=[BD56FFB0:01CAD198]
Subject: Re: [tcpm] IANA TCP options registry ... policy amendments?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Apr 2010 12:53:41 -0000

I'd opt for option #3 - having time-limited experiment range, and clearly stating these opting in I-D or Informational RFCs would help getting interoperability tests deployed...

Cleaning up the IANA registry every 2 years shouldn't be too much of a burden (actually, if within those 2 years no other options were requested for experiments, keep them active until recycled / standards-track RFC emerges...

Or, if a useful addition surfaces, promote the "expirimental" Option to fixed, and put a previously unallocated one to the expirimental code point pool. Pulling once-implemented codepoints out of commercial stacks is also a pain...

AckCC and DCTCP seem to have some merit together, to get them both a properly defined code point each.

Thanks Alfred! 

Richard Scheffenegger

-----Original Message-----
From: Alfred HÎnes [] 
Sent: Donnerstag, 01. April 2010 14:08
To: Scheffenegger, Richard
Subject: Re: [tcpm] IANA TCP options registry ... policy amendments?

> Hi Alfred et al,
> Out of curiousity, does anyone know about the to-be assigned option 
> number(s ?) for RFC 5690 (AckCC
> 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?
> Best regards,
> Richard Scheffenegger
> Field Escalation Engineer
> NetApp Global Support
> ...

Lars already has pointed to the very clear words in RFC 5690.

I understand that this is ugly for the actual participants in experiments, but this all is based on Section 9.3 of BCP 37, RFC 2780, published 10 years ago.  With that RFC, the previous liberal assignment policy for TCP Option Kind values has been changed radically to require Standards Action or IESG Approval.

I do not want to argue in favor or against that decision, but I really want to emphasize that this decision has been half-hearted, leaving the traces of previous, mostly undocumented experiments in the registry forever with fixed code points.

Given the current interest in new TCP options, TCPM should reconsider the above decisions.  Leaving old experiments in the registry and only admitting two code points for experiments looks discriminating for new experiments.  Given the really scarce space in the TCP header for options, subtyping seems to be a poor tradeoff.

As you know, I'm already engaged in transforming my previous results of collecting more facts and evidence about TCP options into an I-D that will aim at amending the IANA registry.

Thus the following questions arise:

(1)  Should we take this opportunity to add more experimental
     code points for TCP Option Kinds ?

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

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

Thoughts?  Opinions?

Kind regards,


| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:                     |