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 | +------------------------+--------------------------------------------+
- Re: [tcpm] IANA TCP options registry ... Scheffenegger, Richard
- Re: [tcpm] IANA TCP options registry ... Alfred Hönes
- Re: [tcpm] IANA TCP options registry ... Alfred Hönes
- Re: [tcpm] IANA TCP options registry ... Christian Huitema
- Re: [tcpm] IANA TCP options registry ... Joe Touch
- Re: [tcpm] IANA TCP options registry ... William Allen Simpson
- Re: [tcpm] IANA TCP options registry ... policy a… William Allen Simpson
- Re: [tcpm] IANA TCP options registry ... Lars Eggert
- Re: [tcpm] IANA TCP options registry ... Alexander Zimmermann
- Re: [tcpm] IANA TCP options registry ... policy a… Alfred Hönes
- Re: [tcpm] IANA TCP options registry ... William Allen Simpson
- Re: [tcpm] IANA TCP options registry ... policy a… Scheffenegger, Richard
- Re: [tcpm] IANA TCP options registry ... policy a… L.Wood
- Re: [tcpm] IANA TCP options registry ... Lars Eggert
- Re: [tcpm] IANA TCP options registry ... Lars Eggert
- Re: [tcpm] IANA TCP options registry ... policy a… Lars Eggert
- Re: [tcpm] IANA TCP options registry ... Alfred Hönes
- Re: [tcpm] IANA TCP options registry ... William Allen Simpson
- Re: [tcpm] IANA TCP options registry ... William Allen Simpson
- [tcpm] IANA TCP options registry ... RFC Editor
- Re: [tcpm] IANA TCP options registry ... policy a… Lars Eggert