Re: [quicwg/base-drafts] WGLC review nits for Recovery (#3877)

[ianswett <[e-mail]>]

@ianswett approved this pull request.

Thanks for this PR, it LG, but I have some suggestions(mostly to existing text) and comments.

> @@ -430,13 +430,13 @@ thresholds to minimize recovery latency.
 
 The RECOMMENDED initial value for the packet reordering threshold
 (kPacketThreshold) is 3, based on best practices for TCP loss detection
-{{?RFC5681}} {{?RFC6675}}.  Implementations SHOULD NOT use a packet threshold
-less than 3, to keep in line with TCP {{?RFC5681}}.
+({{?RFC5681}}, {{?RFC6675}}).  Implementations SHOULD NOT use a packet threshold
+less than 3, to keep in line with TCP ({{?RFC5681}}).

Maybe "In order to remain similar to TCP, implementations SHOULD NOT use a packet threshold less than 3."?

> @@ -587,7 +587,7 @@ received from the client, because packets sent on PTO count against the
 anti-amplification limit. Note that the server could fail to validate the
 client's address even if 0-RTT is accepted.
 
-Since the server could be blocked until more packets are received from the
+Since the server could be blocked until more bytes are received from the

In this case, I prefer packets, since that infers that there are bytes received intended for the specific connection.

> @@ -711,18 +711,18 @@ before Initial packets, early 0-RTT packets will be declared lost, but that
 is expected to be infrequent.
 
 It is expected that keys are discarded after packets encrypted with them would
-be acknowledged or declared lost.  Initial secrets however might be destroyed
-sooner, as soon as handshake keys are available; see Section 4.11.1 of
-{{QUIC-TLS}}.
+be acknowledged or declared lost.  However, Initial secrets are destroyed as

```suggestion
be acknowledged or declared lost.  However, Initial secrets are discarded as
```

> @@ -711,18 +710,18 @@ before Initial packets, early 0-RTT packets will be declared lost, but that
 is expected to be infrequent.
 
 It is expected that keys are discarded after packets encrypted with them would
-be acknowledged or declared lost.  Initial secrets however might be destroyed

We could add a MUST, but there's no reason given the TLS draft has a MUST, unless we're trying to move the TLS references to informational rather than normative?

> +soon as handshake keys are available to both client and server; see Section
+4.11.1 of {{QUIC-TLS}}.

```suggestion
soon as handshake keys are proven to be available to both client and server;
see Section 4.11.1 of {{QUIC-TLS}}.
```

-- 
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/3877#pullrequestreview-449453013