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

William Allen Simpson <william.allen.simpson@gmail.com> Thu, 01 April 2010 19:07 UTC

Return-Path: <william.allen.simpson@gmail.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 AA0673A69B2 for <tcpm@core3.amsl.com>; Thu, 1 Apr 2010 12:07:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.307
X-Spam-Level:
X-Spam-Status: No, score=0.307 tagged_above=-999 required=5 tests=[AWL=-0.824, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13]
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 WZo0ddHaWDDE for <tcpm@core3.amsl.com>; Thu, 1 Apr 2010 12:07:07 -0700 (PDT)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id DCD583A6988 for <tcpm@ietf.org>; Thu, 1 Apr 2010 12:07:07 -0700 (PDT)
Received: by pwi10 with SMTP id 10so1333285pwi.31 for <tcpm@ietf.org>; Thu, 01 Apr 2010 12:07:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=s4MwXp6MxLvnLkMcBd8uV+zcMkY2e3ScwQhXybAsj30=; b=v41Z/YZDXmspYnd4kEut9J7x5y2M+gfRhtayTGsUQRjKafaKZuEq17N8/ke9LqBBrh k5DEihPWDcHsP+WpifzvZFcapLlJVeMNRwCTCLEuhg5l6NxRHYtTWWQjFu1tOhQF5ewB tEIF7P8bCjaIZz3G+dbYRiGhB1fAJVpjuYZDo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=T/hNyX0S2MbUBNpSjlHZAwLy16tgnIlmA6v0qhYvM7qCXfw3qycw1XBQ/MT9w7OZUP DzhJbRCvXCsuTmy5Ix6Wsi/ZPmUUaQYTDAHZX8lLmX2sCgUCFPqVwZxd444rWuv/bGT+ jRA9+z+RhuWVotD8wuuGnuX1JmH7JAolM8EE4=
Received: by 10.114.188.3 with SMTP id l3mr1761486waf.150.1270148858208; Thu, 01 Apr 2010 12:07:38 -0700 (PDT)
Received: from Wastrel.local (c-68-40-195-221.hsd1.mi.comcast.net [68.40.195.221]) by mx.google.com with ESMTPS id 20sm242363iwn.13.2010.04.01.12.07.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 01 Apr 2010 12:07:36 -0700 (PDT)
Message-ID: <4BB4EEF7.9030503@gmail.com>
Date: Thu, 01 Apr 2010 15:07:35 -0400
From: William Allen Simpson <william.allen.simpson@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: tcpm@ietf.org
References: <201004011207.OAA28159@TR-Sys.de> <21169863-7EB5-4A36-AEAD-59A8AA543BAF@nokia.com>
In-Reply-To: <21169863-7EB5-4A36-AEAD-59A8AA543BAF@nokia.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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 19:07:08 -0000

On 4/1/10 9:49 AM, Lars Eggert wrote:
> no. If we allocate them for shared use, people will just use them and ship code using them, like they did in the past. Nothing is gained.
>
Both agree and disagree with Lars.

We *do* need a bigger range, but it probably should have been done more
like we did with PPP.  (1 code point, followed by a 3 byte OUI.)

Then, it would be less of a problem for shipping code.  But it's too late
now.  Do that with 255, instead.


> We don't need to assign a range for this - the IESG can *already* assign TCP option numbers for Experimental uses. The tcpct draft was written exactly to ask for such an assignment.
>
The IESG can already *approve* TCP option numbers (not assign).  The IESG
is a functionary body, not an assignment body.  We deliberately split the
responsibilities long ago.

Note that the IESG does not "architect", it doesn't "design", nor does it
*evaluate* designs.  It is merely a coordinating body.

Actually, the TCPCT draft was written outside the IETF, circa late August
last year.  A big chunk of it was published in December.

The internet-draft was posted, as a last gasp of futility, because IANA
didn't do its job.  IANA records assignments.  It does not evaluate
designs.  In this case, IANA was supposed to forward the formal request
to IESG for approval.  That didn't happen.

So, the work flow (as documented) is supposed to be:
  1) IANA receives request.
  2) promptly forwarded to IESG (1 working day maximum).
  3) IESG takes action at its next meeting (14 calendar days maximum).
  4) If there's not enough information (*not* a problem in this case),
     then ask for more details....

If IANA and IESG merely followed the rules as written, maybe fewer folks
would throw up their hands and run away screaming.


> See above for why the timeout doesn't work.
>
It's not the timeout that doesn't work, it's the recycling.  But product
cycles are typically about 3 years.  It's not that hard to look at
packets and determine that things are no longer in use.