IETF Logo Mail Archive

Re: Spin bit discussion - where we're at

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 22 November 2017 10:01 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C150127137 for <quic@ietfa.amsl.com>; Wed, 22 Nov 2017 02:01:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 mnZxsXgmsf-q for <quic@ietfa.amsl.com>; Wed, 22 Nov 2017 02:01:52 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DC41120227 for <quic@ietf.org>; Wed, 22 Nov 2017 02:01:52 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 71D25BE55; Wed, 22 Nov 2017 10:01:50 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obaP-BXpJL6m; Wed, 22 Nov 2017 10:01:50 +0000 (GMT)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2E1D8BE53; Wed, 22 Nov 2017 10:01:50 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1511344910; bh=hm6YYCQeZeq+8DQSFvgbqPdDELOrN8vZrdK/EPgX5aM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=tfg+vnplhkQqWn/8Nsj8c82mDqbfhR8D0g1o/pUWYs4v0XisvQPQUBACXwTPP24Os 0ASgsIbSemW4CXYp1zu+6hDx8KYA+6h8tW7G8NgZAkihxUTInOVcAZ/ZpI6ezUs1A8 Erbv6Il640bfc6ZcU4Z5Ru4o9km5mosQOh2oJX5M=
Subject: Re: Spin bit discussion - where we're at
To: "Brian Trammell (IETF)" <ietf@trammell.ch>, Mark Nottingham <mnot@mnot.net>
Cc: QUIC WG <quic@ietf.org>, Lars Eggert <lars@netapp.com>
References: <AFEE7BBA-E5DC-4064-AA19-33921EAF4C01@mnot.net> <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <fd09b775-4c0e-9d99-e49c-421212f2e5e4@cs.tcd.ie>
Date: Wed, 22 Nov 2017 10:01:49 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="Wlftsn3P25DFpD8jXt9wTtwQrHSSLX7xc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Wv0M4a-WTn6SFyALexrSNWA2upE>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Nov 2017 10:01:55 -0000

Just on this one aspect...

On 22/11/17 09:14, Brian Trammell (IETF) wrote:
> The request for a privacy considerations section for a single
> protocol feature seems odd to me at best, and prejudicial at worst.
> Where is the privacy considerations analysis for other features, for
> instance, various header compression schemes? 
I agree that asking that there be a privacy considerations section
in RFCs for every bit in every protocol would be OTT. But that was
not how I interpreted Mark's mail.

What I thought was being requested and what I do think is reasonable
is to document a privacy analysis for any quic protocol bits that are
visible to the path. Whether or not some or all of that text ends up
in some RFC is another day's work.

Cheers,
S.

v2.23.0 | Report a Bug | By Email