Re: [EToSat] Re-chartering for extension work

Lars Eggert <lars@eggert.org> Wed, 18 December 2019 06:33 UTC

Return-Path: <lars@eggert.org>
X-Original-To: etosat@ietfa.amsl.com
Delivered-To: etosat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402D31200C7; Tue, 17 Dec 2019 22:33:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 odISBFVHlHyG; Tue, 17 Dec 2019 22:32:58 -0800 (PST)
Received: from vs22.mail.saunalahti.fi (vs22.mail.saunalahti.fi [193.64.193.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 519521200A3; Tue, 17 Dec 2019 22:32:58 -0800 (PST)
Received: from vs22.mail.saunalahti.fi (localhost [127.0.0.1]) by vs22.mail.saunalahti.fi (Postfix) with ESMTP id 9E436203E1; Wed, 18 Dec 2019 08:32:54 +0200 (EET)
Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by vs22.mail.saunalahti.fi (Postfix) with ESMTP id 933332023D; Wed, 18 Dec 2019 08:32:54 +0200 (EET)
Received: from eggert.org (unknown [62.248.255.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: eggert@elisanet.fi) by gw03.mail.saunalahti.fi (Postfix) with ESMTPSA id 092472001E; Wed, 18 Dec 2019 08:32:47 +0200 (EET)
Received: from slate.eggert.org (Slate.eggert.org [172.19.235.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by eggert.org (Postfix) with ESMTPSA id 2AB9AA70274; Wed, 18 Dec 2019 08:32:41 +0200 (EET)
From: Lars Eggert <lars@eggert.org>
Message-Id: <B291D840-11BC-428A-BA5B-509408610F17@eggert.org>
Content-Type: multipart/signed; boundary="Apple-Mail=_2BD33182-FF04-4F46-ABFD-AA9791CF6B52"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Date: Wed, 18 Dec 2019 08:32:40 +0200
In-Reply-To: <F3B0A07CFD358240926B78A680E166FF1ED2D685@TW-MBX-P03.cnesnet.ad.cnes.fr>
Cc: Mark Nottingham <mnot@mnot.net>, Gorry Fairhust <gorry@erg.abdn.ac.uk>, "etosat@ietf.org" <etosat@ietf.org>, IETF QUIC WG <quic@ietf.org>, "emile.stephan@orange.com" <emile.stephan@orange.com>
To: Kuhn Nicolas <Nicolas.Kuhn@cnes.fr>
References: <A56547B6-2E3B-4ABE-8C9B-BA9ACC489FB2@mnot.net> <F3B0A07CFD358240926B78A680E166FF1ED2D685@TW-MBX-P03.cnesnet.ad.cnes.fr>
X-MailScanner-ID: 2AB9AA70274.A3D48
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/etosat/hrXpEZP_ymfdEsk1NilwPEuXHt0>
Subject: Re: [EToSat] Re-chartering for extension work
X-BeenThere: etosat@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "The EToSat list is a non-WG mailing list used to discuss performance implications of running encrypted transports such as QUIC over satellite." <etosat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/etosat>, <mailto:etosat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/etosat/>
List-Post: <mailto:etosat@ietf.org>
List-Help: <mailto:etosat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/etosat>, <mailto:etosat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Dec 2019 06:33:00 -0000

Hi,

On 2019-12-17, at 19:27, Kuhn Nicolas <Nicolas.Kuhn@cnes.fr> wrote:
> We have updated draft-kuhn-quic-0rtt-bdp-05 as an extension of QUIC.
> We propose to include it in the re-chartering discussion.

all the extensions included in the recharter we are discussing here have been reviewed by the WG and are actually under adoption at the moment.

I agree that the satellite use case is important, but neither the problem nor the proposed solution is at the same stage, so I wouldn't want to include it in the current recharter.

(Same goes for pretty much *any* other extension, FWIW.)

Lars