Re: [tcpinc] AD review of tcp-eno

David Mazieres <> Fri, 28 July 2017 20:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E52AC12EA7C; Fri, 28 Jul 2017 13:21:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fmzxOxYIX1Pl; Fri, 28 Jul 2017 13:21:50 -0700 (PDT)
Received: from ( [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9EE55131C91; Fri, 28 Jul 2017 13:21:50 -0700 (PDT)
Received: from (localhost []) by (8.15.2/8.15.2) with ESMTP id v6SKLonj002683; Fri, 28 Jul 2017 13:21:50 -0700 (PDT)
Received: (from dm@localhost) by (8.15.2/8.15.2/Submit) id v6SKLonP063757; Fri, 28 Jul 2017 13:21:50 -0700 (PDT)
From: David Mazieres <>
To: Kyle Rose <>, "Mirja Kuehlewind (IETF)" <>
Cc:, tcpinc <>
In-Reply-To: <>
References: <> <> <> <> <>
Date: Fri, 28 Jul 2017 13:21:50 -0700
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [tcpinc] AD review of tcp-eno
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 28 Jul 2017 20:21:52 -0000

Kyle Rose <> writes:

> Does it make sense to allocate a few TEP IDs (e.g., 0x7c-0x7f) as explicit
> "for testing purposes: not for production use" IDs that implementors can
> use in testing? Another alternative is an explicit ExID-like mechanism, but
> that seems far too heavy-weight for something like ENO. A range like this
> would at least offer implementors a no-effort way to do their own
> development and testing without poisoning other TEP IDs.

The document already reserves 0x20 for experimental use.  I'm a little
hesitant to go allocating the top end of the space, because in the
unlikely event that ENO is so successful we project running out of code
points, we might want to use the low two bits of 0x7c-0x7f or 0x78-0x7f
as the first three bits of a 10- or 11-bit extended TEP Id.  Is one
experimental TEP ID not enough?

The intention with 0x20 is eventually to specify an ExID-like mechanism,
but I think maybe we felt it was premature to do so in this document.
We could also add vaguer language about how users of 0x20 should start
options with two or more identifier bytes to leave open the possibility
of interoperating with other experiments.