Re: [quicwg/base-drafts] Avoid data corruption with wrapped Largest Reference. (#2261)

Bence Béky <notifications@github.com> Mon, 31 December 2018 02:01 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B473127598 for <quic-issues@ietfa.amsl.com>; Sun, 30 Dec 2018 18:01:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.086
X-Spam-Level:
X-Spam-Status: No, score=-7.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 1GaQuujbVniW for <quic-issues@ietfa.amsl.com>; Sun, 30 Dec 2018 18:01:26 -0800 (PST)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4200612008A for <quic-issues@ietf.org>; Sun, 30 Dec 2018 18:01:26 -0800 (PST)
Date: Sun, 30 Dec 2018 18:01:25 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1546221685; bh=K2yt5rpRgxJRNN8sPiZEpdq4FZyW48mpXSLIOLa5i60=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=QHhtO9mv3YOVRSqrHttjkr0Obq3FkNLS60lAAiO/vpik1P3snhNYrMRQB8nTQsy9I na5Ip0AuGjW/OWOdCpICdGC9tJm6TLvdB5qbP9DmxIut88pJXvdiLeUFBrx2tp58ia kYs0Wt3rwXc97IUf9ck6ob+1S1KD0NfH6XPq9FoA=
From: Bence Béky <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abb47968633c66789fb2da5a024e64c6bb0238d3cc92cf0000000118413a7592a169ce177f2f28@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2261/c450601057@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2261@github.com>
References: <quicwg/base-drafts/pull/2261@github.com>
Subject: Re: [quicwg/base-drafts] Avoid data corruption with wrapped Largest Reference. (#2261)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c2978756bb22_6afd3facd56d45b856942f"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: bencebeky
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/AyF_iA41ap4nmpeXsIqoKKYNxYc>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Dec 2018 02:01:28 -0000

> You should really create a new issue for these things. Because this comment relates only to the issue, not the proposed fix. I haven't read the proposed changes, though I will if you think that there is a fix in there that is worth keeping after this.
> 
> Anyhow, the example is invalid here:
> 
> > another encoder implementation starts by adding 10 unique entries
> 
> Because:
> 
> > The encoder MUST NOT evict a dynamic table entry unless it has first been acknowledged by the decoder.
> 
> And you can only ever fit 5 entries in that table.

That's exactly the issue: "it has first been acknowledged by the decoder" is ambigous. "Acknowledged" is being used throughout the text with two different meanings, most often to refer to references, not insertions. The ban on evicting an entry the insertion of which has not been acknowledged, that you are quoting, only occurs once out of four different locations talking about when an entry can be evicted. The other three places clearly only ban evicting an entry with unacknowledged references (note the use of the same word), giving the impression that acknowledgement of the insertion is not necessary before eviction.

Since the design is correct if you read it right, but wording is not as clear as I think it should be, I consider this issue editorial. The change I propose in this PR is meant to be an improvement on clarity.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2261#issuecomment-450601057