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

William Allen Simpson <> Thu, 01 April 2010 16:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4AF383A69FD for <>; Thu, 1 Apr 2010 09:52:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.213
X-Spam-Status: No, score=0.213 tagged_above=-999 required=5 tests=[AWL=-1.218, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EWjZ5LOX0ZQv for <>; Thu, 1 Apr 2010 09:52:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5E5103A67B4 for <>; Thu, 1 Apr 2010 09:52:53 -0700 (PDT)
Received: by pwi10 with SMTP id 10so1200516pwi.31 for <>; Thu, 01 Apr 2010 09:53:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=251HKBERcEeosGSqdIfwoLmnWOv0NEhd/FurpY40HTw=; b=d04g75fACYVyD+AbnZvhfO8UGvX1p5Jr/3Oz4zj+KxxxmcTLeg7wk72rQNhPMJ5Jj7 LC4Tk3liMQFTox2gLmuEwRCrZEakAjWRR38xZmAjw362pxe91wMoCwSHVwyLoB05y/bb CFbAzsBarMTk/u0TJPAXGEc+MA2NdpAMp+Tjg=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=yGdSKC6jEsVBORA94wFcvAdOWuBimqPv7wyHlTNE8RJhLsfsFlQuHdZzpRhrHqfBNF tzToGcAe6lU6BzaSgGA0+CP/s/07UO6ya8e8wknfCXiut8IMcf2fGSJ9RiECcgXZfNA5 Pl+2w18ptucjwveMQlmuj9Rru6vsrfswduErk=
Received: by with SMTP id d6mr726114rvi.175.1270140803288; Thu, 01 Apr 2010 09:53:23 -0700 (PDT)
Received: from Wastrel.local ( []) by with ESMTPS id 20sm158223iwn.9.2010. (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 01 Apr 2010 09:53:22 -0700 (PDT)
Message-ID: <>
Date: Thu, 01 Apr 2010 12:53:21 -0400
From: William Allen Simpson <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Alfred � <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [tcpm] IANA TCP options registry ...
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 16:52:54 -0000

On 4/1/10 10:01 AM, Alfred � wrote:
> Obviously both exceptions quoted above are not proper matches for your
> case, and so I still do not see the procedural rule on which you have
> based your expectation of exceptional treatment.
> Or did I miss something?
Reminder: by that time, earlier Linux code had already been posted for
over a year, incorrectly using option 255.

As noted in my IANA application:

"This will have widespread testing starting on Monday, November 30th ...
with the December Usenix ;login: issue publication."

"There aren't enough experimental options to go around.  I'm already
using 253, and Cisco is apparently shipping a test with 254."

> Sorry: In this case, avoidance of IETF WGs strikes back.
[eyes rolling]  The last time I sent a draft through an IETF WG
(RFC-4419), it took roughly 6 years to be published.  Long after
there were multiple interoperable implementations.

If they have a deadline, or are planning on getting anything shipped,
nobody in their right mind goes through an IETF WG anymore.  Especially
not this one....

> I do not want to argue on the final point here, but it looks like in
> this case the IETF (an the IESG) is simply eating their own doggy-food,
> and as shown above, this has nothing to do with ossification of the
> institutions tasked with the execution of the procedures set by the
> IETF.  If the taste of the doggy-food is perceived as being bad, we
> should better try to modify it (i.e. the rule in RFC 2780 -- see my
> previous posting on this thread), and not merely complain about it.
> It is generally seen that for major protocols where experiments
> in closed lab environments do not suffice to gain siginificant
> experience before standardization, some rules set by the IETF
> for IANA policy are too restrictive.  The wave of RFCs and drafts
> seen during the last couple of years that aim at making additions
> to IETF protocols easier is a clear indication that in some Areas
> of the IETF the value of experiments and running code is gaining
> back momentum.  For TCP and TLS, that's not the case, for instance.
> It's ours to request and drive change for the rules if they hurt.
Been there, done that, have the t-shirt (worn on special occasions)!

   We reject: kings, presidents and voting.
   We believe in: rough consensus and running code.

Sorry, but I've already gone through all that (POISED, POISSON), and we
established pretty clear standards of promptness.

But it's good to know "that in some Areas of the IETF the value of
experiments and running code is gaining back momentum."

Thanks for your feedback!