IETF Logo Mail Archive

Re: [Pearg] Adoption call for "Randomized Response Mechanisms in RRT Measurements for HTTP/3"

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 09 November 2020 01:48 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: pearg@ietfa.amsl.com
Delivered-To: pearg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843A73A0F2E for <pearg@ietfa.amsl.com>; Sun, 8 Nov 2020 17:48:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, 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 (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 EGRwImDO6uoX for <pearg@ietfa.amsl.com>; Sun, 8 Nov 2020 17:48:15 -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 7FE6E3A1082 for <pearg@irtf.org>; Sun, 8 Nov 2020 17:48:15 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2709BBE55; Mon, 9 Nov 2020 01:48:13 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
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 jQmU5MCvNiJi; Mon, 9 Nov 2020 01:48:11 +0000 (GMT)
Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 644EFBE51; Mon, 9 Nov 2020 01:48:11 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1604886491; bh=i0AibC5DE0IvBbLMqs8+C0hG9S5O+NEwJjc14BSbI3U=; h=Subject:To:References:From:Date:In-Reply-To:From; b=mRji2MR1Wwa9fWB2f1t3iSdr4MUeA66cNJrfj5hx744fNiG1ZNcrQL625iz1+MZAS MzXEp0WVgJ2chhMVqjrJd7ktujmz9JACVZZ6VrRp8kJri+uwBQHRs7CCgajR6eaSru D1RV9Idxfztjcnb6Qv0bM0ArrAT+O9pYorgWKj30=
To: Christian Huitema <huitema@huitema.net>, amelia.ietf@andersdotter.cc, Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org>, Christopher Wood <caw@heapingbits.net>, "pearg@irtf.org" <pearg@irtf.org>
References: <33ba4995-ea2d-45d8-9b01-05ea9b8ddbce@www.fastmail.com> <F27FD790-74CA-44CC-98FB-ED3B24E17B6D@ericsson.com> <D76F769D-C147-4EE9-8639-0881DD82F135@ericsson.com> <bf7cade8-116b-77bc-efce-4b332ec785cc@andersdotter.cc> <44bed321-40c5-a4a0-646d-6ba5516cf396@huitema.net>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Message-ID: <6e694386-59c1-64dc-16ce-5e019bc7b534@cs.tcd.ie>
Date: Mon, 09 Nov 2020 01:48:10 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.2
MIME-Version: 1.0
In-Reply-To: <44bed321-40c5-a4a0-646d-6ba5516cf396@huitema.net>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="ti91oH9l8RFhuFrBWiZGA696N12PIpdHR"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pearg/ws5LLBpWJ0I56cWYSkIKYra1wOo>
Subject: Re: [Pearg] Adoption call for "Randomized Response Mechanisms in RRT Measurements for HTTP/3"
X-BeenThere: pearg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhancements and Assessment Proposed RG <pearg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/pearg>, <mailto:pearg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pearg/>
List-Post: <mailto:pearg@irtf.org>
List-Help: <mailto:pearg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/pearg>, <mailto:pearg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Nov 2020 01:48:17 -0000

Hiya,

On 09/11/2020 01:19, Christian Huitema wrote:
> There is a narrow and arcane issue with applying padding...

I figure there could be a useful RFC written describing
the circumstances when to pad with zero and when not. A
bit boring, yes, but would save some time for protocol
developers later on, as this question comes up over and
over.

I'm not sure if generalising beyond that might be useful
but wouldn't rule it out, e.g. to scope a draft at "how
and when to pad with what" or similar,

Cheers,
S.

PS: Before anyone asks: sorry, not volunteering myself
right now, just due to workload ;-)

v2.23.0 | Report a Bug | By Email