Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt

Bernard Aboba <bernard.aboba@gmail.com> Thu, 07 November 2019 20:06 UTC

Return-Path: <bernard.aboba@gmail.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72BBC1208C2; Thu, 7 Nov 2019 12:06:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 dxgVxh0ZgGkg; Thu, 7 Nov 2019 12:06:12 -0800 (PST)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EC51120255; Thu, 7 Nov 2019 12:06:11 -0800 (PST)
Received: by mail-lj1-x229.google.com with SMTP id t5so3706598ljk.0; Thu, 07 Nov 2019 12:06:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9y7HqqlCW1QXhEBr/F6UnNbID2hR5pc0UGz+VM1VhqE=; b=IF1NMHKZagEAnNHbU9I23QmJ0uEnaoyiQnlU2x1E3Xm53Zm4sv12ucSJPnubyf6FyJ 24s6DLLNyscqcPeIHt1GdkdyrZDQ34+vpOieH0iT5Wan914KqvMDg//xn5GOQWl37VVx oLI242QGTo30vv4ZX1oBIYTbAAFRvMAk51TlPBW0SQ3hyKPFWzcrONMuSf9T7V/dC+7X rPX2FVbG04Zs2Ff3m5/nUdqb0JeXdOkSpa5Xuw90lUTrsgzOlqTYll1lUpL4c2ogqQ2v oo9YzjWupdxxQD64PV4fBKcqd6Pwje9kNekmOlx3pvjdHZgq2E6PNhifQdby0Kd/V3xd JPGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9y7HqqlCW1QXhEBr/F6UnNbID2hR5pc0UGz+VM1VhqE=; b=WRGqDZnZVaEYZRYWtZR5JBdImyWnC/s2Z19rLr0HcGxGZuPj5b7A6a4n9wzJ/H0ZD4 ZgYyjxPJeEa7c2j5/5E0SuyXQn3EJUKLEdHrCUl2l/N/HAvLSf0BCcQRwadKnlhqXgzb H6e4fjyrnZPCMh4oyAozWvE+CvKTxW3x88y7GjJUXiYERt/zbimBc2E6rtFWwMqMfE9E Qv+ibj04a+Fz9vTxbq5EdqroSiwX0Cqps24y66chYcWBwUotQTfckUmdr+feR+4uvoM9 Md152zJDzADZJqGdHzFjP+qDrly8TXgp60wS5B7a0f45btrZF6ngR1zNQ0vsb3DyRIEB UPeA==
X-Gm-Message-State: APjAAAXWoDtN5Qvp8nO3rb8pmLjAMqzVMywzOkiChZqZNudQgbYpyhZE qD31THlj0jAkUAvFAFVLZliHLF8vdzTNDUAJtGU=
X-Google-Smtp-Source: APXvYqzpHZox5cYKjuHWl03/GvE+2jcuJxqJj4IBXtre8Cqh3OAfwd3RIfumS/uvoxrK5rpgadsDgEMQ0i9Gv8Gp5qQ=
X-Received: by 2002:a05:651c:111a:: with SMTP id d26mr3759126ljo.168.1573157169530; Thu, 07 Nov 2019 12:06:09 -0800 (PST)
MIME-Version: 1.0
References: <67CE4313-A4C2-4CC7-972E-CB465D47B7FE@ericsson.com> <998B7C3E-54D8-40AC-BF91-901390CF70C5@strayalpha.com> <CAPDSy+5rvaXgEGZ7_V4pRdmBss7Hf1XmaGbiXGZceQu9hjjRTQ@mail.gmail.com> <118e630a-3f04-4aa9-8c1f-8083194865e4@www.fastmail.com> <9EC2E60F-6044-4135-A802-1665028E6075@ericsson.com> <54B33418-28D8-4176-A2EE-29FF27E5CE44@csperkins.org> <8dd558db-6f22-487f-a714-9f0ba71e74dc@www.fastmail.com>
In-Reply-To: <8dd558db-6f22-487f-a714-9f0ba71e74dc@www.fastmail.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Thu, 07 Nov 2019 12:05:58 -0800
Message-ID: <CAOW+2dt6hw0pnT_KUkJQ_GrK6cjNfcUJi-Zfzt5CWiOXFadX+w@mail.gmail.com>
To: Martin Thomson <mt@lowentropy.net>
Cc: Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org>, tsvwg IETF list <tsvwg@ietf.org>, "saag@ietf.org" <saag@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000440da90596c73241"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/RyL1FvrCfApxfatdWAP0Q_r5QVs>
Subject: Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Nov 2019 20:06:14 -0000

Martin said:

"To take the example of capacity planning, I had a great conversation about
18 months ago with Lee Howard about what that might look like in the
presence of more opaque data flows between endpoints.  I don't think that
we reached a specific conclusion, but it was refreshing to talk about the
actual problem and not get bogged down in the detail of specific
techniques.  Though the discussion touched on many existing and potential
methods, our focus never left the important question of what the goals were
and how there might be some shared interest in achieving that goal."

[BA] Indeed, it would be very useful for there to be an IETF document that
covered the manageability problem (including capacity planning) from a
variety of perspectives, including that of the endpoints and application
service providers.  Unfortunately, draft-ietf-quic-manageability is not
(yet) that document.

On Wed, Nov 6, 2019 at 6:16 PM Martin Thomson <mt@lowentropy.net> wrote:

> On Wed, Nov 6, 2019, at 20:58, Colin Perkins wrote:
> > It certainly wasn’t my intent with this draft to say that all these
> > practices should be kept; rather to stimulate the discussion about what
> > should be preserved, what it’s necessary to find alternatives for; etc.
> > If this doesn’t come across clearly in the draft. we should fix it.
>
> Thanks Colin,
>
> I didn't start with that expectation and the introduction does a fine job
> of setting this out.  However the draft makes some very strong statements
> in the conclusion and - in a few places - the body that leave very little
> room for interpretation.
>
> I'm happy to help identify specific cases, but it seemed to be fairly
> consistent throughout.  For the bulk of the document, perhaps the right
> thing to do is take another pass with a critical eye.  I don't know what to
> do about the conclusions section though.
>
> I just want to say that while I appreciate the effort taken to document
> techniques, I'm not entirely convinced that it is the only way forward.
> Discussion of existing practice can distract from the underlying needs.
>
> To take the example of capacity planning, I had a great conversation about
> 18 months ago with Lee Howard about what that might look like in the
> presence of more opaque data flows between endpoints.  I don't think that
> we reached a specific conclusion, but it was refreshing to talk about the
> actual problem and not get bogged down in the detail of specific
> techniques.  Though the discussion touched on many existing and potential
> methods, our focus never left the important question of what the goals were
> and how there might be some shared interest in achieving that goal.
>
> Being able to focus on the underlying requirements like that can be hard,
> but my sense is that this is where we'll need to reach before anything
> meaningful will happen.  I have to confess, despite enduring the spin bit
> debate, I find the fact that I have still trouble articulating exactly what
> requirements that mechanism addresses to be concerning.
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>