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

Alfred Hönes <ah@TR-Sys.de> Thu, 01 April 2010 12:19 UTC

Return-Path: <A.Hoenes@TR-Sys.de>
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 5099C3A700F for <tcpm@core3.amsl.com>; Thu, 1 Apr 2010 05:19:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -93.93
X-Spam-Level:
X-Spam-Status: No, score=-93.93 tagged_above=-999 required=5 tests=[AWL=0.489, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, J_CHICKENPOX_61=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
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 LHIs8FDb3ORM for <tcpm@core3.amsl.com>; Thu, 1 Apr 2010 05:19:17 -0700 (PDT)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id D19F83A7C01 for <tcpm@ietf.org>; Thu, 1 Apr 2010 05:07:52 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA104413674; Thu, 1 Apr 2010 14:07:54 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id OAA28159; Thu, 1 Apr 2010 14:07:49 +0200 (MESZ)
From: Alfred Hönes <ah@TR-Sys.de>
Message-Id: <201004011207.OAA28159@TR-Sys.de>
To: rs@netapp.com
Date: Thu, 01 Apr 2010 14:07:48 +0200
In-Reply-To: <5FDC413D5FA246468C200652D63E627A08144911@LDCMVEXC1-PRD.hq.netapp.com> from "Scheffenegger, Richard" at Apr "1, " 2010 "06:47:09" am
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: 7bit
Cc: 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 12:19:18 -0000

> Hi Alfred et al,
>
> Out of curiousity, does anyone know about the to-be assigned option
> number(s ?) for RFC 5690 (AckCC http://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?
>
> 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
     participants?
     (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,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| 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:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+