Re: [quicwg/base-drafts] editorial: This sentence was hard to parse for me (recovery) (#3383)

Martin Thomson <notifications@github.com> Wed, 22 January 2020 22:37 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 48B0612004F for <quic-issues@ietfa.amsl.com>; Wed, 22 Jan 2020 14:37:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Level:
X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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 Pmf0iUxazRZJ for <quic-issues@ietfa.amsl.com>; Wed, 22 Jan 2020 14:37:04 -0800 (PST)
Received: from out-3.smtp.github.com (out-3.smtp.github.com [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04AB612001A for <quic-issues@ietf.org>; Wed, 22 Jan 2020 14:37:04 -0800 (PST)
Received: from github-lowworker-c5134a3.ac4-iad.github.net (github-lowworker-c5134a3.ac4-iad.github.net [10.52.23.55]) by smtp.github.com (Postfix) with ESMTP id 3FC682C0B0B for <quic-issues@ietf.org>; Wed, 22 Jan 2020 14:37:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1579732623; bh=/GPHwMFSmVBPVXufA93gbXwTNJHrpaVa3vt/qrxe7M8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=IBVdoU49pP93led/I/aC3k1qr+4J04kfbyjzL41v6WwhSXd5susE3aoyOexxZlYSa KevhUZ3iaFxA5eWx/zYZSuMqyOpnRJfIW/QL1xbita6jbWNlsk0uR09QEeAHKh6C5O XzO+uoaVR+InI99GET5jOSil6mTgXhmf6gntBynA=
Date: Wed, 22 Jan 2020 14:37:03 -0800
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3NWGKAK3HW2RXEMWV4GYAQ7EVBNHHCCABNRQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3383/review/346952994@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3383@github.com>
References: <quicwg/base-drafts/pull/3383@github.com>
Subject: Re: [quicwg/base-drafts] editorial: This sentence was hard to parse for me (recovery) (#3383)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e28ce8f2f71d_7acc3fb5916cd9609294"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/o7cIlU8avIGxxddqMPinLMSmJvQ>
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: Wed, 22 Jan 2020 22:37:05 -0000

martinthomson approved this pull request.

This is a great improvement, thanks.

One additional suggestion (for existing text) below.

> @@ -272,9 +272,10 @@ SHOULD NOT be used to update RTT estimates if it does not newly acknowledge the
 largest acknowledged packet.
 
 An RTT sample MUST NOT be generated on receiving an ACK frame that does not
-newly acknowledge at least one ack-eliciting packet.  A peer does not send an
-ACK frame on receiving only non-ack-eliciting packets, so an ACK frame that is
-subsequently sent can include an arbitrarily large Ack Delay field.  Ignoring
+newly acknowledge at least one ack-eliciting packet. A peer usually does not
+send an ACK frame when only non-ack-eliciting packets are received. Therefore
+an ACK frame that only contains acknowledgements for non-ack-eliciting packets
+can subsequently include an arbitrarily large Ack Delay value.  Ignoring

```suggestion
could include an arbitrarily large Ack Delay value.  Ignoring
```

-- 
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/3383#pullrequestreview-346952994