IETF Logo Mail Archive

Re: [tcpinc] AD review of tcp-eno

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Thu, 27 July 2017 16:58 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255C7131C8F for <tcpinc@ietfa.amsl.com>; Thu, 27 Jul 2017 09:58:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyo6cbsfC8qF for <tcpinc@ietfa.amsl.com>; Thu, 27 Jul 2017 09:58:16 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 509291316C3 for <tcpinc@ietf.org>; Thu, 27 Jul 2017 09:58:16 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=tKsvjJ1u31Xwt7aR3ebLOK7dSYtlja70G/h22X15MLq542TgbMV4fL9nAee8goliZCweWWy+N6dRbqD94DBkLhkvVSUQE0yDpKpOzy11hI5uIEcc9UGcLjfUpVHQKz75tk0dKldYk/00BjRrF2cU+vKSIEDOdED+bNvDbu8QG7Y=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 21506 invoked from network); 27 Jul 2017 18:58:14 +0200
Received: from pd9e11f0f.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (217.225.31.15) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 27 Jul 2017 18:58:14 +0200
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <68220a4f-01dd-61dc-0e68-8c9fc68587bf@isi.edu>
Date: Thu, 27 Jul 2017 18:58:13 +0200
Cc: draft-ietf-tcpinc-tcpeno.all@ietf.org, tcpinc <tcpinc@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <60D21DFE-CC3D-41F0-B9EC-EFF224F85EFE@kuehlewind.net>
References: <55B07DA5-E274-4720-A919-83483094B9A0@tik.ee.ethz.ch> <80C705CD-8A24-49A9-A1B8-6FA7B2162941@kuehlewind.net> <baad59c7-03cb-738a-e1b9-185931fe96a2@isi.edu> <E855DFC2-1D60-4FF5-B67A-3E2DE4B44541@kuehlewind.net> <68220a4f-01dd-61dc-0e68-8c9fc68587bf@isi.edu>
To: Joe Touch <touch@isi.edu>
X-Mailer: Apple Mail (2.3273)
X-PPP-Message-ID: <20170727165814.20476.3079@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/r1N3c-EFaZv14wB4nnYu8Hz-rEk>
Subject: Re: [tcpinc] AD review of tcp-eno
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <tcpinc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpinc/>
List-Post: <mailto:tcpinc@ietf.org>
List-Help: <mailto:tcpinc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jul 2017 16:58:18 -0000

Hi Joe,

replying separately to separate topics:

> Am 27.07.2017 um 17:40 schrieb Joe Touch <touch@isi.edu>:
> 
> I have raised concerns with this practice in other cases, so I'll raise
> it here. The whole point of experimental is for these cases. The TCP
> option space is littered with failed experiments, and should not be --
> that is exactly what the mechanism in RFC6994 is intended for.

Yes, this is true. However in practice we use the experimental option for experimentation during draft status and have often assigned the code point at publication time of the RFC. 

In case of tcpinc/tcpeno I think this is qualified because there is agreement that this extension is value to TCP. This experiment is rather on figuring out if the specification is correct and comprehensive.

However, if you want to have this discussion in more general term, it should happen on the tcpm list instead.

Mirja

v2.23.0 | Report a Bug | By Email