Subject: [quicwg/base-drafts] Tidy up reference style (#4820)

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Jan 2021 20:00:28 -0800

to make RFC Editor diffs smaller
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/4820

-- Commit Summary --

  * Tidy up reference style

-- File Changes --

    M draft-ietf-quic-http.md (212)
    M draft-ietf-quic-qpack.md (29)
    M draft-ietf-quic-recovery.md (115)
    M draft-ietf-quic-tls.md (109)
    M draft-ietf-quic-transport.md (173)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/4820.patch
https://github.com/quicwg/base-drafts/pull/4820.diff

-- 
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/4820

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Jan 2021 20:07:56 -0800

@martinthomson commented on this pull request.

Can you share the tool that you used to make these changes?  This PR is impossible to review, but I would be happier reviewing the tool.  A careful description of any manual steps might suffice.

-- 
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/4820#pullrequestreview-577971638

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Jan 2021 20:10:07 -0800

> @@ -388,8 +391,8 @@ Therefore, when adjusting an RTT sample using peer-reported acknowledgment
 delays, an endpoint:
 
 - MAY ignore the acknowledgment delay for Initial packets, since these
-  acknowledgments are not delayed by the peer (Section 13.2.1 of
-  {{QUIC-TRANSPORT}});
+  acknowledgments are not delayed by the peer ( {{Section 13.2.1 of

```suggestion
  acknowledgments are not delayed by the peer ({{Section 13.2.1 of
```
Hmm, this is clearly a change that was applied manually.

-- 
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/4820#pullrequestreview-577972273

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Jan 2021 20:14:36 -0800

@mnot pushed 1 commit.

fa4979a7bb42db9fc7cede9fbff87d507dd09815  fix spacing nits

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4820/files/e9f421e75d2c0c33dcbad057dbdae8994b370be0..fa4979a7bb42db9fc7cede9fbff87d507dd09815

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Jan 2021 20:20:04 -0800

@mnot pushed 1 commit.

7963266425d12b1130369964b73d2d6ead1f2d31  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4820/files/fa4979a7bb42db9fc7cede9fbff87d507dd09815..7963266425d12b1130369964b73d2d6ead1f2d31

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Jan 2021 20:31:19 -0800

@mnot pushed 1 commit.

93513e6162a66b8e92c983b8ec47adb561b81fa1  Fix transport

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4820/files/7963266425d12b1130369964b73d2d6ead1f2d31..93513e6162a66b8e92c983b8ec47adb561b81fa1

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 Jan 2021 04:33:07 +0000 (UTC)

These are manual; if only there were a tool...

Diffs in the `.txt` are all very small, and in each case reflects correction of an existing error or slight adjustment to accommodate limitations in XML (in one case); happy to suppy (CI is broken because of tools.ietf.org).

-- 
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/4820#issuecomment-768792615

---

From: Martin Thomson <[email-masked]>
Date: Thu, 28 Jan 2021 00:54:13 -0800

I just uploaded this to a branch on this repository so that a diff is generated in CI (assuming that I have a little more luck in getting a build to stick).  The changes should be visible at https://quicwg.org/base-drafts/mnot-tidy-refs/ if CI ever passes.  Which of course it has not at this point...

-- 
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/4820#issuecomment-768900582

---

From: Mike Bishop <[email-masked]>
Date: Thu, 28 Jan 2021 07:41:03 -0800

Seems to be working again; I fixed a lint problem, and diffs are now at https://quicwg.org/base-drafts/mnot-tidy-refs/

-- 
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/4820#issuecomment-769172408

---

From: Mike Bishop <[email-masked]>
Date: Thu, 28 Jan 2021 07:48:37 -0800

@MikeBishop approved this pull request.

Thanks for doing this, Mark.  I hadn't seen that @cabo had added this functionality to the tools, and I like that it puts the right references in the resulting HTML and XML.  I've reviewed the text diffs, and basically all the changes in output fix minor editorial things that are improvements anyway.

> @@ -4359,7 +4363,7 @@ Endpoints could limit the content of PMTU probes to PING and PADDING frames,
 since packets that are larger than the current maximum datagram size are more
 likely to be dropped by the network.  Loss of a QUIC packet that is carried in a
 PMTU probe is therefore not a reliable indication of congestion and SHOULD NOT
-trigger a congestion control reaction; see Section 3, Bullet 7 of {{!DPLPMTUD}}.
+trigger a congestion control reaction; see {{Section 3 of DPLPMTUD}}, Bullet 7.

```suggestion
trigger a congestion control reaction; see Bullet 7 in {{Section 3 of DPLPMTUD}}.
```
This feels more natural in the output, but either is probably fine.

-- 
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/4820#pullrequestreview-578466694

---

From: Mike Bishop <[email-masked]>
Date: Thu, 28 Jan 2021 07:49:12 -0800

@MikeBishop pushed 1 commit.

cc049209b1a7e82682c90812cb0ee61ebae9d1c8  Rewrap

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4820/files/93513e6162a66b8e92c983b8ec47adb561b81fa1..cc049209b1a7e82682c90812cb0ee61ebae9d1c8

---

From: Sean Turner <[email-masked]>
Date: Thu, 28 Jan 2021 08:43:58 -0800

@seanturner commented on this pull request.

 HPACK defines string literals to begin on a byte boundary.  They begin with a
 single bit flag, denoted as 'H' in this document (indicating whether the string
 is Huffman-coded), followed by the Length encoded as a 7-bit prefix integer, and
 finally Length bytes of data. When Huffman encoding is enabled, the Huffman
-table from Appendix B of [RFC7541] is used without modification and Length
+table from {{Section B of RFC7541}} is used without modification and Length

Shouldn't this be: {{Appendix B of RFC7541}}

-- 
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/4820#pullrequestreview-578530435

---

From: Sean Turner <[email-masked]>
Date: Thu, 28 Jan 2021 08:46:26 -0800

> @@ -707,7 +709,7 @@ Session resumption allows servers to link activity on the original connection
 with the resumed connection, which might be a privacy issue for clients.
 Clients can choose not to enable resumption to avoid creating this correlation.
 Clients SHOULD NOT reuse tickets as that allows entities other than the server
-to correlate connections; see Section C.4 of {{!TLS13}}.
+to correlate connections; see {{Section C.4 of TLS13}}.

{{Appendix C.4 of TLS13}}

-- 
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/4820#pullrequestreview-578532856

---

From: Sean Turner <[email-masked]>
Date: Thu, 28 Jan 2021 08:48:47 -0800

> @@ -4019,8 +4023,8 @@ acknowledged. This includes packets that are acknowledged after being declared
 lost, which can happen in the presence of network reordering. Doing so requires
 senders to retain information about packets after they are declared lost. A
 sender can discard this information after a period of time elapses that
-adequately allows for reordering, such as a PTO (Section 6.2 of
-{{QUIC-RECOVERY}}), or on other events, such as reaching a memory limit.
+adequately allows for reordering, such as a PTO ( {{Section 6.2 of

({{Section 6.2

-- 
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/4820#pullrequestreview-578535199

---

From: Sean Turner <[email-masked]>
Date: Thu, 28 Jan 2021 08:50:48 -0800

>  addresses.  This corresponds to the maximum datagram size.

 ### DPLPMTUD and Initial Connectivity
 
 From the perspective of DPLPMTUD, QUIC is an acknowledged Packetization Layer
-(PL). A QUIC sender can therefore enter the DPLPMTUD BASE state (Section 5.2 of
-{{!DPLPMTUD}}) when the QUIC connection handshake has been completed.
+(PL). A QUIC sender can therefore enter the DPLPMTUD BASE state ( {{Section 5.2

({{Section 5.2

-- 
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/4820#pullrequestreview-578537183

---

From: Sean Turner <[email-masked]>
Date: Thu, 28 Jan 2021 08:51:42 -0800

> @@ -6555,7 +6558,7 @@ considered separately.
 ### Handshake {#handshake-properties}
 
 The QUIC handshake incorporates the TLS 1.3 handshake and inherits the
-cryptographic properties described in Appendix E.1 of {{?TLS13=RFC8446}}. Many
+cryptographic properties described in Appendix E.1 of {{TLS13}}. Many

{{Appendix E.1 of TLS13}}

-- 
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/4820#pullrequestreview-578538074

---

From: ianswett <[email-masked]>
Date: Thu, 28 Jan 2021 09:08:57 -0800

@ianswett approved this pull request.

Thanks for doing this, recovery LGTM

-- 
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/4820#pullrequestreview-578554844

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 28 Jan 2021 12:03:56 -0800

@janaiyengar commented on this pull request.

Thanks for the work, @mnot! Apologies for the number of comments, they're all consistency fixes though, so they aren't much work.

```suggestion
table from {{Appendix B of RFC7541}} is used without modification and Length
```

> +RTT samples and peer-reported host delays (see {{Section 13.2 of
+QUIC-TRANSPORT}}) to generate a statistical description of the network path's

```suggestion
RTT samples and peer-reported host delays ({{Section 13.2 of
QUIC-TRANSPORT}}) to generate a statistical description of the network path's
```

>  for each connection is adequate to quickly recover from a single packet loss.
 An endpoint that always retransmits packets in response to receiving packets
 that it cannot process risks creating an infinite exchange of packets.
 
-Endpoints can also use coalesced packets (see Section 12.2 of
-{{QUIC-TRANSPORT}}) to ensure that each datagram elicits at least one
-acknowledgment. For example, a client can coalesce an Initial packet
-containing PING and PADDING frames with a 0-RTT data packet and a server can
-coalesce an Initial packet containing a PING frame with one or more packets in
-its first flight.
+Endpoints can also use coalesced packets (see {{Section 12.2 of

```suggestion
Endpoints can also use coalesced packets ({{Section 12.2 of
```

> @@ -768,13 +771,13 @@ initial RTT estimate.
 ## Discarding Keys and Packet State {#discarding-packets}
 
 When Initial and Handshake packet protection keys are discarded
-(see Section 4.9 of {{QUIC-TLS}}), all packets that were sent with those keys
+(see {{Section 4.9 of QUIC-TLS}}), all packets that were sent with those keys

```suggestion
({{Section 4.9 of QUIC-TLS}}), all packets that were sent with those keys
```

> @@ -620,7 +622,7 @@ Server Name Identification (SNI) or Application Layer Protocol Negotiation
 If the ClientHello spans multiple Initial packets, such servers would need to
 buffer the first received fragments, which could consume excessive resources if
 the client's address has not yet been validated.  To avoid this, servers MAY
-use the Retry feature (see Section 8.1 of {{QUIC-TRANSPORT}}) to only buffer
+use the Retry feature (see {{Section 8.1 of QUIC-TRANSPORT}}) to only buffer

```suggestion
use the Retry feature ({{Section 8.1 of QUIC-TRANSPORT}}) to only buffer
```

```suggestion
to correlate connections; see {{Appendix C.4 of TLS13}}.
```

> @@ -804,19 +806,19 @@ requirements for determining whether to accept or reject early data.
 
 ## HelloRetryRequest
 
-The HelloRetryRequest message (see Section 4.1.4 of {{!TLS13}}) can be used to
+The HelloRetryRequest message (see {{Section 4.1.4 of TLS13}}) can be used to

```suggestion
The HelloRetryRequest message ({{Section 4.1.4 of TLS13}}) can be used to
```

> @@ -943,15 +945,15 @@ QUIC derives packet protection keys in the same way that TLS derives record
 protection keys.
 
 Each encryption level has separate secret values for protection of packets sent
-in each direction.  These traffic secrets are derived by TLS (see Section 7.1 of
-{{!TLS13}}) and are used by QUIC for all encryption levels except the Initial
-encryption level.  The secrets for the Initial encryption level are computed
+in each direction. These traffic secrets are derived by TLS (see {{Section 7.1

```suggestion
in each direction. These traffic secrets are derived by TLS ({{Section 7.1
```

> @@ -983,11 +985,10 @@ Initial packets apply the packet protection process, but use a secret derived
 from the Destination Connection ID field from the client's first Initial
 packet.
 
-This secret is determined by using HKDF-Extract (see Section 2.2 of
-{{!HKDF=RFC5869}}) with a salt of 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a
-and a IKM of the Destination Connection ID field. This produces an intermediate
-pseudorandom key (PRK) that is used to derive two separate secrets for sending
-and receiving.
+This secret is determined by using HKDF-Extract (see {{Section 2.2 of HKDF}})

```suggestion
This secret is determined by using HKDF-Extract ({{Section 2.2 of HKDF}})
```

> @@ -1811,8 +1812,8 @@ negotiation.  TLS uses Application Layer Protocol Negotiation
 is used for agreeing on an application protocol, endpoints MUST use ALPN for
 this purpose.
 
-When using ALPN, endpoints MUST immediately close a connection (see Section
-10.2 of {{QUIC-TRANSPORT}}) with a no_application_protocol TLS alert (QUIC error
+When using ALPN, endpoints MUST immediately close a connection (see {{Section

```suggestion
When using ALPN, endpoints MUST immediately close a connection ({{Section
```

> @@ -1963,12 +1964,12 @@ A small ClientHello that results in a large block of handshake messages from a
 server can be used in packet reflection attacks to amplify the traffic generated
 by an attacker.
 
-QUIC includes three defenses against this attack. First, the packet containing a
-ClientHello MUST be padded to a minimum size. Second, if responding to an
-unverified source address, the server is forbidden to send more than three times
-as many bytes as the number of bytes it has received (see Section 8.1 of
-{{QUIC-TRANSPORT}}). Finally, because acknowledgments of Handshake packets are
-authenticated, a blind attacker cannot forge them.  Put together, these defenses
+QUIC includes three defenses against this attack. First, the packet containing
+a ClientHello MUST be padded to a minimum size. Second, if responding to an
+unverified source address, the server is forbidden to send more than three
+times as many bytes as the number of bytes it has received (see {{Section 8.1

```suggestion
times as many bytes as the number of bytes it has received ({{Section 8.1
```

> @@ -1956,11 +1960,11 @@ least 64 bits of entropy.
 
 For the client, the value of the Destination Connection ID field in its first
 Initial packet allows it to validate the server address as a part of
-successfully processing any packet.  Initial packets from the server are
-protected with keys that are derived from this value (see Section 5.2 of
-{{QUIC-TLS}}). Alternatively, the value is echoed by the server in Version
+successfully processing any packet. Initial packets from the server are
+protected with keys that are derived from this value (see {{Section 5.2 of

```suggestion
protected with keys that are derived from this value ({{Section 5.2 of
```

> @@ -2969,7 +2973,7 @@ transmission of any packets on this connection.
 When sending CONNECTION_CLOSE, the goal is to ensure that the peer will process
 the frame.  Generally, this means sending the frame in a packet with the highest
 level of packet protection to avoid the packet being discarded.  After the
-handshake is confirmed (see Section 4.1.2 of {{QUIC-TLS}}), an endpoint MUST
+handshake is confirmed (see {{Section 4.1.2 of QUIC-TLS}}), an endpoint MUST

```suggestion
handshake is confirmed ({{Section 4.1.2 of QUIC-TLS}}), an endpoint MUST
```

```suggestion
adequately allows for reordering, such as a PTO ({{Section 6.2 of
```

>    that ECN validation has failed.
 
 If an endpoint has cause to expect that IP packets with an ECT codepoint might
 be dropped by a faulty network element, the endpoint could set an ECT codepoint
 for only the first ten outgoing packets on a path, or for a period of three
-PTOs (see Section 6.2 of {{QUIC-RECOVERY}}). If all packets marked with non-zero
+PTOs (see {{Section 6.2 of QUIC-RECOVERY}}). If all packets marked with non-zero

```suggestion
PTOs ({{Section 6.2 of QUIC-RECOVERY}}). If all packets marked with non-zero
```

 

```suggestion
(PL). A QUIC sender can therefore enter the DPLPMTUD BASE state ({{Section 5.2
```

> @@ -4779,8 +4783,8 @@ The first packet sent by a client always includes a CRYPTO frame that contains
 the start or all of the first cryptographic handshake message.  The first
 CRYPTO frame sent always begins at an offset of 0; see {{handshake}}.
 
-Note that if the server sends a TLS HelloRetryRequest (see Section 4.7 of
-{{QUIC-TLS}}), the client will send another series of Initial packets.  These
+Note that if the server sends a TLS HelloRetryRequest (see {{Section 4.7 of

```suggestion
Note that if the server sends a TLS HelloRetryRequest ({{Section 4.7 of
```

> @@ -4793,8 +4797,8 @@ first Handshake packet.  A server stops sending and processing Initial packets
 when it receives its first Handshake packet.  Though packets might still be in
 flight or awaiting acknowledgment, no further Initial packets need to be
 exchanged beyond this point.  Initial packet protection keys are discarded (see
-Section 4.9.1 of {{QUIC-TLS}}) along with any loss recovery and congestion
-control state; see Section 6.4 of {{QUIC-RECOVERY}}.
+{{Section 4.9.1 of QUIC-TLS}}) along with any loss recovery and congestion
+control state; see {{Section 6.4 of QUIC-RECOVERY}}.

```suggestion
control state ({{Section 6.4 of QUIC-RECOVERY}}).
```

>  exchanged beyond this point.  Initial packet protection keys are discarded (see
-Section 4.9.1 of {{QUIC-TLS}}) along with any loss recovery and congestion
-control state; see Section 6.4 of {{QUIC-RECOVERY}}.
+{{Section 4.9.1 of QUIC-TLS}}) along with any loss recovery and congestion

remove "see"

```suggestion
cryptographic properties described in {{Appendix E.1 of TLS13}}. Many
```

-- 
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/4820#pullrequestreview-578588911

---

From: Mike Bishop <[email-masked]>
Date: Thu, 28 Jan 2021 12:09:46 -0800

@MikeBishop commented on this pull request.

kramdown-rfc2629 doesn't currently recognize Appendix on the input side, but will produce "Appendix" on the output.  What Mark has is correct.

-- 
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/4820#discussion_r566375839

---

From: Mike Bishop <[email-masked]>
Date: Thu, 28 Jan 2021 12:10:25 -0800

Same.

-- 
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/4820#discussion_r566376151

---

From: Mike Bishop <[email-masked]>
Date: Thu, 28 Jan 2021 12:13:31 -0800

```suggestion
cryptographic properties described in {{Section E.1 of TLS13}}. Many
```

-- 
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/4820#discussion_r566377695

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 Jan 2021 13:46:10 -0800

@mnot pushed 1 commit.

457e5c8d13096c3c80a31eabfd54c72dbf3c7d64  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4820/files/cc049209b1a7e82682c90812cb0ee61ebae9d1c8..457e5c8d13096c3c80a31eabfd54c72dbf3c7d64

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 Jan 2021 13:47:26 -0800

@mnot pushed 1 commit.

f90dcc5832356c268e9490a48c663e77ad694069  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4820/files/457e5c8d13096c3c80a31eabfd54c72dbf3c7d64..f90dcc5832356c268e9490a48c663e77ad694069

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 Jan 2021 13:49:12 -0800

@mnot pushed 1 commit.

03291484ce4ec604f3bf2936eb899cd9a9907a10  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4820/files/f90dcc5832356c268e9490a48c663e77ad694069..03291484ce4ec604f3bf2936eb899cd9a9907a10

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 Jan 2021 13:52:44 -0800

@mnot commented on this pull request.

No; kramdown-rfc2629 will do the right thing.

-- 
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/4820#discussion_r566431854

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 Jan 2021 13:56:23 -0800

@janaiyengar I'd strongly prefer to keep this PR focused on behind-the-scenes tidying, rather than making an editorial wording choice. Beyond keeping the PR focused, doing this piecemeal is going to miss a large number of instances of "see..." because the changes represented here are only where a specific section is called out; you'd do much better to adjust that language consistently after this PR is applied (when you can do a search for "see {{ and it should consistently show all instances, whether or not there's a section being referenced).

If that's sensible to everyone, I think this is ready; tell me if I missed one of the comments.

-- 
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/4820#issuecomment-769425264

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 28 Jan 2021 15:53:46 -0800

@mnot: Fair enough. This LGTM.

-- 
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/4820#issuecomment-769475458

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 28 Jan 2021 15:56:18 -0800

@janaiyengar approved this pull request.

@mart

-- 
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/4820#pullrequestreview-578839363

---

From: Martin Thomson <[email-masked]>
Date: Thu, 28 Jan 2021 16:53:31 -0800

Here are the diffs, since tools is failing so badly (I plan to work around that, but that will take some time).

https://gist.github.com/martinthomson/44906649598b56dd80c32268bb0f8a3a

I've spotted one problem there already, but it does look good so far.

-- 
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/4820#issuecomment-769497429

---

From: Martin Thomson <[email-masked]>
Date: Thu, 28 Jan 2021 17:00:24 -0800

This is the only change that I am going to take over what is here.

-- 
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/4820#discussion_r566510270

---

From: Martin Thomson <[email-masked]>
Date: Thu, 28 Jan 2021 17:00:53 -0800

@martinthomson pushed 1 commit.

49c7e54bde1585123f7e742b3c28a1cdad372626  Bullet X in Section Y of [Z]

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4820/files/03291484ce4ec604f3bf2936eb899cd9a9907a10..49c7e54bde1585123f7e742b3c28a1cdad372626

---

From: Martin Thomson <[email-masked]>
Date: Thu, 28 Jan 2021 17:01:13 -0800

@martinthomson approved this pull request.

-- 
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/4820#pullrequestreview-578864854

---

From: Sean Turner <[email-masked]>
Date: Sun, 31 Jan 2021 20:15:47 -0800

@seanturner approved this pull request.

-- 
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/4820#pullrequestreview-580003314